[EXTERNAL] Re: Problem running RTEMS on raspberrypi3

Cudmore, Alan P. (GSFC-5820) alan.p.cudmore at nasa.gov
Wed Dec 18 18:08:38 UTC 2019


I’ll see if I can try out my older RPIs (1 , 2 , and zero) over the next couple of weeks.
Alan

From: Niteesh <gsnb.gn at gmail.com>
Date: Wednesday, December 18, 2019 at 1:06 PM
To: Christian Mauderer <list at c-mauderer.de>, Alan Cudmore <alan.p.cudmore at nasa.gov>
Cc: "rtems-devel at rtems.org" <devel at rtems.org>
Subject: [EXTERNAL] Re: Problem running RTEMS on raspberrypi3

Yes, I did try that but still, it doesn't work.  I don't have any other pi's with me, maybe let's wait for someone to try it out on any older models.

On Wed, Dec 18, 2019 at 2:06 AM Christian Mauderer <list at c-mauderer.de<mailto:list at c-mauderer.de>> wrote:
That handler doesn't look like an RTEMS handler. So it failed at a very
early stage.

Did you try a go 0x200000 instead? Normally the first vector is a reset
vector which jumps to the right start address. The jump can have a mode
with it. So if you directly jump to 0x200080 the core might is in a
wrong mode.

On 16/12/2019 15:54, Niteesh wrote:
> What about using U-boot? I just tried running my own bare metal example
> using u-boot and it works fine.
> The 3rd stage bootloader start the u-boot and I was able to interact
> with it through serial. and then I used
> fatload mmc 0 0x8000 kernel.img ; go 0x8000
> to load and run the img. I tried the same for rtems
> fatload mmc 0 0x200000 rtems_kernel.img ; go 0x200080
> but this result's in a
>
>     ## Starting application at 0x00200080 ...
>     "Synchronous Abort" handler, esr 0x02000000
>     elr: ffffffffc1d29080 lr : 00000000000838b0 (reloc)
>     elr: 0000000000200080 lr : 000000003e55a8b0
>     x0 : 0000000000000001 x1 : 000000003e15e6c8
>     x2 : 000000003e15e6c8 x3 : 0000000000200080
>     x4 : 0000000000000000 x5 : 0000000000000000
>     x6 : 0000000000c0c0c0 x7 : 000000000000000f
>     x8 : 00000000ffffffd0 x9 : 0000000000000008
>     x10: 0000000000000010 x11: 000000003e159cc0
>     x12: 0000000000000000 x13: 0000000000000200
>     x14: 0000000000000005 x15: 0000000000000008
>     x16: 0000000000000000 x17: 0000000000000020
>     x18: 000000003e152de0 x19: 000000003e15e6c8
>     x20: 0000000000000002 x21: 0000000000200080
>     x22: 000000003e15e6c0 x23: 0000000000000002
>     x24: 000000003e5d4d44 x25: 0000000000000000
>     x26: 0000000000000000 x27: 0000000000000000
>     x28: 000000003e1567e0 x29: 000000003e152b20
>
>     Code: 0020b048 0020b048 0020b048 0020b048 (e1a05001)
>     Resetting CPU ...
>
>
> On Mon, Dec 16, 2019 at 8:11 PM Niteesh <gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com>
> <mailto:gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com>>> wrote:
>
>     But I am not able to boot using the 3 stage bootloader. Can someone
>     try booting any examples on raspi3 or other newer models? If it's
>     work's please
>     post the instructions. The steps that I followed are:
>     1. arm-rtems5-objcopy -Obinary hello.exe kernel.img
>     2. copied the kernel image to sd card and modified the config.txt to
>     load the kernel img.
>     No success in following these steps.
>     I think this is maybe because of the different start addresses. The
>     default kernel load address for raspberry pi is 0x8000 in 32bit mode
>     and 0x80000 in 64bit mode.
>     but RTEMS has a start address of 0x200080.
>
>
>     On Mon, Dec 16, 2019 at 7:51 PM Christian Mauderer
>     <list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>> wrote:
>
>         I think I have guided you to a wrong path here. I mentioned U-Boot
>         because it is often used on a lot of evaluation boards. In the
>         raspberry
>         case it seems that the stage 3 loader is something different. But
>         everything should work with that stage 3 loader. I don't think that
>         U-Boot is necessary.
>
>         On 16/12/2019 14:01, Niteesh wrote:
>         > I got uboot running on my raspi3. But I can't figure out to
>         load and run
>         > a custom kernel. Can you explain the steps or point me to some
>         > reference.
>         > On Mon, Dec 16, 2019 at 5:13 PM Niteesh <gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com>
>         <mailto:gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com>>
>         > <mailto:gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com<mailto:gsnb.gn at gmail.com>>>> wrote:
>         >
>         >     On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer
>         >     <list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>> wrote:
>         >
>         >
>         >
>         >         On 15/12/2019 21:29, Niteesh wrote:
>         >         >
>         >         >
>         >         > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer
>         >         <list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>
>         >         > <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>>> wrote:
>         >         >
>         >         >     On 15/12/2019 19:46, Niteesh wrote:
>         >         >     >
>         >         >     >
>         >         >     > On Sun, Dec 15, 2019 at 10:15 PM Christian
>         Mauderer
>         >         >     <list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>
>         >         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>>
>         >         >     > <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>
>         >         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>
>         <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de<mailto:list at c-mauderer.de>>>>>> wrote:
>         >         >     >
>         >         >     >     Hello Niteesh,
>         >         >     >
>         >         >     >     On 15/12/2019 09:05, Niteesh wrote:
>         >         >     >     > I am trying to get RTEMS examples
>         running on the
>         >         RPI3, the
>         >         >     RPI3 is
>         >         >     >     > similar to RPI2 so the examples built
>         for RPI2 should
>         >         >     technically
>         >         >     >     run on
>         >         >     >     > the RPi3.But they don't :(, I am really
>         sure of
>         >         what is causing
>         >         >     >     the problem.
>         >         >     >
>         >         >     >     Note that there are at least two different
>         versions
>         >         of the
>         >         >     RPi3 which
>         >         >     >     use different chips. The original RPi3
>         which uses a
>         >         BCM2837
>         >         >     (same like
>         >         >     >     later versions of RPi2) and the RPi3+
>         which uses a
>         >         BCM2837B0.
>         >         >     Broadcom
>         >         >     >     is always quite sparse with documentation
>         so it's
>         >         not easy to
>         >         >     tell the
>         >         >     >     differences. Which one do you have?
>         >         >     >
>         >         >     > I have Rpi3 model b v1.2 which uses BCM2837
>         SOC, in my
>         >         bare-metal
>         >         >     > programming I used the
>         >         >     > 2835 doc as a reference because the only major
>         >         difference these
>         >         >     two SOC
>         >         >     > is the peripheral base address
>         >         >     > offset. But this is arm cpu is also capable of
>         >         executing in 64bit
>         >         >     mode.
>         >         >
>         >         >     OK. Did you check, whether the offset is
>         correct? In the
>         >         raspberrypi.h
>         >         >     in RTEMS there is the following define:
>         >         >
>         >         >     #if (BSP_IS_RPI2 == 1)
>         >         >        #define RPI_PERIPHERAL_BASE      0x3F000000
>         >         >     #else
>         >         >        #define RPI_PERIPHERAL_BASE      0x20000000
>         >         >     #endif
>         >         >
>         >         > The offsets are right.
>         >
>         >         Good.
>         >
>         >         >
>         >         >     >
>         >         >     >     > I followed the steps
>         >         >     >     >
>         >         >     >
>         >         >
>         >
>            from http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__alanstechnotes.blogspot.com_2013_03_running-2Dyour-2Dfirst-2Drtems-2Dprogram-2Don.html&d=DwMGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=Dj1p3ROFaQ16w58VFDVx6fw1I7dHf5UEdIpcnZ-azMw&s=hcWvkg9RzJdYbVw5C1YWu_N7KHoTAy-Kh_gd519Q1jQ&e=> (modified
>         >         >     >     > commands to use rtems5) to build the
>         kernel img.
>         >         >     >
>         >         >     >     It's a bit odd that the Bootloader doesn't
>         use some
>         >         image
>         >         >     format like
>         >         >     >     U-Boot but if that's the case for
>         Raspberry, that's OK.
>         >         >     >
>         >         >     > Do you want me to try U-Boot, I was planning
>         to use it
>         >         for my
>         >         >     bare-metal
>         >         >     > stuff because copying the kernel
>         >         >     > to SD-card was a real pain. Will it even work
>         with RTEMS?
>         >         >
>         >         >     The manual that you linked uses the default
>         Raspberry
>         >         bootloader. I'm
>         >         >     not sure whether it's an U-Boot. If you skip the
>         >         bootloader entirely,
>         >         >     your SDRAM might isn't initialized.
>         >         >
>         >         > The manual uses the default bootloader. I don't
>         think we have
>         >         to worry
>         >         > about the SDRAM initialization
>         >         > because all of that is taken care of by the GPU.
>         >
>         >         Sounds OK.
>         >
>         >         > When using Uboot, the
>         >         > GPU will load the uboot image and
>         >         > pass the control to the CPU. And then the uboot
>         continue's
>         >         it's execution.
>         >         >
>         >
>         >         I don't wanted to suggest to use an extra U-Boot. I
>         was just not
>         >         sure
>         >         whether the stage 3 loader is an U-Boot. Your approach
>         sounds
>         >         fine so far.
>         >
>         >         >
>         >         >
>         >         >     PS: You answered that further below. You are
>         using the
>         >         stage 3 loader.
>         >         >
>         >         >     >
>         >         >     >     > I did try running it on
>         >         >     >     > Qemu but it doesn't always work,
>         sometimes it gives
>         >         >     weird output.
>         >         >     >
>         >         >     >     How did you run it on Qemu? Did you build
>         some image
>         >         for that too?
>         >         >     >
>         >         >     > qemu-system-arm -M raspi2 -m 1G -kernel hello.exe
>         >         -serial mon:stdio
>         >         >     > -nographic
>         >         >     > *
>         >         >     > *
>         >         >     > *
>         >         >     > qemu-system-aarch64: GLib: g_mapped_file_unref:
>         >         assertion 'file !=
>         >         >     NULL'
>         >         >     > failed *I get this error
>         >         >     > while trying to emulate raspi3.
>         >         >
>         >         >     That sounds like a problem with Qemu. Is there some
>         >         official test image
>         >         >     for rpi3 on qemu? Note that this isn't really
>         relevant for
>         >         your current
>         >         >     problem. So if you don't have some manual just
>         ignore the
>         >         question.
>         >         >
>         >         >     >
>         >         >     > I ran qemu along with GDB to find what was
>         causing the
>         >         wrong output. I
>         >         >     > am really not sure if this is right,
>         >         >     > I still have a lot to learn, but my
>         assumption's using
>         >         GDB are as
>         >         >     follows.
>         >         >     > There are 4 active thread which run the same code.
>         >         >     >
>         >         >     >     (gdb) info thread
>         >         >     >       Id   Target Id                    Frame
>         >         >     >     * 1    Thread 1.1 (CPU#0 [running]) _start
>         () at
>         >         >     >
>         >         >
>         >
>            ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >     >       2    Thread 1.2 (CPU#1 [running]) _start
>         () at
>         >         >     >
>         >         >
>         >
>            ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >     >       3    Thread 1.3 (CPU#2 [running]) _start
>         () at
>         >         >     >
>         >         >
>         >
>            ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >     >       4    Thread 1.4 (CPU#3 [running]) _start
>         () at
>         >         >     >
>         >         >
>         >
>            ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >
>         >         >     In this case that are not threads but it's the
>         CPU cores.
>         >         GDB shows them
>         >         >     as threads. Most likely it wouldn't be able to
>         detect the
>         >         RTEMS threads.
>         >         >
>         >         >     It's a bit odd that they are all pointing to
>         start.S:153.
>         >         That's the
>         >         >     entry point for the program. It looks like not
>         even one
>         >         instruction has
>         >         >     been executed yet.
>         >         >
>         >         > I took this output before executing the program,
>         that the
>         >         reason why not
>         >         > even a single instruction has been
>         >         > executed yet.
>         >
>         >         OK.
>         >
>         >         >
>         >         >     >
>         >         >     > After some time one of the thread call's the
>         BSP reset
>         >         function
>         >         >     this is
>         >         >     > when the program crashes, the other threads
>         complain
>         >         "*executing
>         >         >     thread
>         >         >     > is NULL*"
>         >         >
>         >         >     I would rather assume that one core tries to do the
>         >         initialization while
>         >         >     the others hang in a endless loop till they are
>         needed.
>         >         The one core
>         >         >     doing the initialization work hits an exception
>         somewhere
>         >         and calls the
>         >         >     exception handler which calls the bsp reset
>         function.
>         >         >
>         >         >     The executing thread is NULL is a sign that it
>         happens
>         >         somewhere during
>         >         >     initialization when the RTEMS threading hasn't been
>         >         started yet.
>         >         >
>         >         >     The PC has an odd value. The linker command file
>         tells
>         >         that there is a
>         >         >     RAM_MMU at 0x00100000. It only puts a
>         >         bsp_translation_table there but
>         >         >     there shouldn't be any code. So I don't know
>         what the
>         >         processor is doing
>         >         >     there. You could try to set a breakpoint on the
>         address
>         >         0x00100fc4 and
>         >         >     take a look at why the processor is there with a
>         "bt"
>         >         (backtrace).
>         >         >
>         >         > When I re-run it again, it now stops at a different
>         address.
>         >         As you said
>         >         > that the other cores are put
>         >         > in an endless loop, I don't think that's is happening. I
>         >         single stepped
>         >         > the instruction and later at some point checked the
>         threads
>         >         >
>         >         >     (gdb) info threads
>
>         >
>         >         >
>
>         >
>         >         >
>
>         >         >         Target Id                    Frame
>         >         >       1    Thread 1.1 (CPU#0 [running])
>         arm_ccsidr_get_line_power
>         >         >     (ccsidr=<optimized out>)
>         >         >         at
>         >         >
>         >
>           /home/niteesh/development/rtems/kernel/rtems/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h:850
>         >         >       2    Thread 1.2 (CPU#1 [running])
>         >         arm_cp15_cache_invalidate_level
>         >         >     (inst_data_fl=0, level=1)
>         >         >        at
>         >         >
>         >
>           /home/niteesh/development/rtems/kernel/rtems/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h:1162
>         >         >      3    Thread 1.3 (CPU#2 [running])
>         arm_ccsidr_get_line_power
>         >         >     (ccsidr=<optimized out>)
>         >         >        at
>         >         >
>         >
>           /home/niteesh/development/rtems/kernel/rtems/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h:850
>         >         >     * 4    Thread 1.4 (CPU#3 [running])
>         >         >     arm_cp15_get_cache_size_id_for_level
>         (level_and_inst_dat=0)
>         >         >         at
>         >         >
>         >
>           /home/niteesh/development/rtems/kernel/rtems/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h:936
>         >         >     (gdb)
>         >         >
>         >         > They all are executing different instructions at the
>         same time.
>         >
>         >         Some of the initialization is done on all cores. Some
>         isn't. I
>         >         took a
>         >         look at the initialization and it seems that I was
>         wrong: There
>         >         is no
>         >         wait loop. All processors are running through the
>         initialization
>         >         process. Some just skip parts. The part where they
>         really start to
>         >         differ is in bsp_start_hook_0.
>         >
>         >         > I> googled about just running one thread or CPU as
>         you said at
>         >         a time and
>         >         > used "*set scheduler-locking on" *on doing this I
>         always get
>         >         the right
>         >         > output.
>         >         >
>         >         >     (gdb) info threads
>         >         >       Id   Target Id                    Frame
>         >         >     * 1    Thread 1.1 (CPU#0 [running]) bsp_reset ()
>         >         >         at
>         >         >
>         >
>           ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/raspberrypi/start/bspreset.c:18
>         >         >       2    Thread 1.2 (CPU#1 [running]) _start ()
>         >         >         at
>         >         >
>         >
>           ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >       3    Thread 1.3 (CPU#2 [running]) _start ()
>         >         >         at
>         >         >
>         >
>           ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >       4    Thread 1.4 (CPU#3 [running]) _start ()
>         >         >         at
>         >         >
>         >
>           ../../../../../../../../rtems/c/src/lib/libbsp/arm/raspberrypi/../../../../../../bsps/arm/shared/start/start.S:153
>         >         >     (gdb)
>         >         >
>         >         > The above command allow's only a single thread to run.
>         >
>         >         Maybe there is a timing difference between the
>         simulator and the
>         >         real
>         >         hardware. I'm not sure how well tested the SMP code is
>         on the
>         >         Raspberry.
>         >         There can be a hidden bug.
>         >
>         >         Just a guess: If there is a bug it could be possible
>         that you hit it
>         >         with your rpi3 too. Maybe it would be good to try a
>         single core
>         >         version
>         >         of the BSP. I assume you have configured with
>         "--enable-smp"?
>         >         Can you
>         >         try to build without it?
>         >
>         >     I built 2 versions with SMP enabled and disabled, the one
>         we are
>         >     talking about is the SMP disabled version, I ran
>         >     the example with SMP enabled, still, the error's are
>         similar, I only
>         >     difference is, in the disabled one, there are only 4 or
>         less panic's
>         >     (maybe corresponding to 4 cpu's) but the other one has a
>         higher
>         >     number of panics.
>         >
>         >         > Won't it be a good idea to make a separate BSP for rpi3?
>         >
>         >         As soon as it is necessary: Sure. But from what you
>         told me it seems
>         >         that the hardware is very similar so that we won't hit
>         this
>         >         point soon.
>         >         Or do you already see differences that would make it
>         necessary.
>         >
>         >         I haven't had a look at the details but it could also
>         be possible to
>         >         unify the BSPs and entirely remove the rpi2 variant if the
>         >         information
>         >         from the flattened device tree are used.
>         >
>         >     Can you explain how FDT work in RTEMS. Can you mention
>         some BSP's
>         >     which use FDT so I can use them as a reference to learn.
>         >     I previously took a look at the beagle FDT project
>         (#3784), you
>         >     mentioned about hardcoded values and initialization
>         functions, can
>         >     you explain more about what exactly do the initialization
>         functions
>         >     do? Do they assign a function to a particular pin, like in
>         raspi
>         >     the pins are multiplexed for various functions, so do the
>         >     initialization functions assign those pins to a particular
>         function?
>         >
>         >     And also please explain how does the initialization of the
>         system
>         >     happen from the DT file.
>         >
>         >         >
>         >         >     >     *** FATAL ***
>         >         >     >     fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>         >         >     >
>         >         >     >     R0   = 0x400005e6 R8  = 0x00000000
>         >         >     >     R1   = 0x00000001 R9  = 0x00000000
>         >         >     >     R2   = 0xbffffa1a R10 = 0x00000000
>         >         >     >     R3   = 0x00000000 R11 = 0x00000000
>         >         >     >     R4   = 0x002001db R12 = 0x00000000
>         >         >     >     R5   = 0x00000000 SP  = 0x00300bd0
>         >         >     >     R6   = 0x00000000 LR  = 0x00100fc4
>         >         >     >     R7   = 0x00000000 PC  = 0x00100fc4
>         >         >     >     CPSR = 0x000001d3 VEC = 0x00000002
>         >         >     >     FPEXC = 0x40000000
>         >         >     >     FPSCR = 0x00000000
>         >         >     >     D00 = 0x0000000000000000
>         >         >     >     D01 = 0x0000000000000000
>         >         >     >     D02 = 0x0000000000000000
>         >         >     >     D03 = 0x0000000000000000
>         >         >     >     D04 = 0x0000000000000000
>         >         >     >     D05 = 0x0000000000000000
>         >         >     >     D06 = 0x0000000000000000
>         >         >     >     D07 = 0x0000000000000000
>         >         >     >     D08 = 0x0000000000000000
>         >         >     >     D09 = 0x0000000000000000
>         >         >     >     D10 = 0x0000000000000000
>         >         >     >     D11 = 0x0000000000000000
>         >         >     >     D12 = 0x0000000000000000
>         >         >     >     D13 = 0x0000000000000000
>         >         >     >     D14 = 0x0000000000000000
>         >         >     >     D15 = 0x0000000000000000
>         >         >     >     D16 = 0x0000000000000000
>         >         >     >     D17 = 0x0000000000000010
>         >         >     >     D18 = 0x0000000000000000
>         >         >     >     D19 = 0x0000000000000000
>         >         >     >     D20 = 0x0000000000000000
>         >         >     >     D21 = 0x0000000000000000
>         >         >     >     D22 = 0x0000000000000000
>         >         >     >     D23 = 0x0000000000000000
>         >         >     >     D24 = 0x0000000000000000
>         >         >     >     D25 = 0x0000000000000000
>         >         >     >     D26 = 0x0000000000000000
>         >         >     >     D27 = 0x0000000000000000
>         >         >     >     D28 = 0x0000000000000000
>         >         >     >     D29 = 0x0000000000000000
>         >         >     >     D30 = 0x0000000000000000
>         >         >     >     D31 = 0x0000000000000000
>         >         >     >     RTEMS version:
>         >         >
>          5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807-modified
>         >         >     >     RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB
>         >         >     >     83fa79314dd87c0a8c78fd642b2cea3138be8dd6,
>         Newlib
>         >         3e24fbf6f)
>         >         >     >     executing thread is NULL
>         >         >     >
>         >         >     >     > The steps that I followed are:
>         >         >     >     > 1. Created a bootable SD card using
>         raspbian.
>         >         >     >     > 2. Replaced the kernel.img file with RTEMS
>         >         kernel.img file and
>         >         >     >     modified
>         >         >     >     > the config.txt to boot from the RTEMs
>         kernel (boots in
>         >         >     aarch32 bit
>         >         >     >     mode).
>         >         >     >     > I am still not able to wrap my head
>         around the RPI
>         >         bsp build
>         >         >     process.
>         >         >     >     > This is what I understood as of now,
>         correct me if
>         >         I am wrong.
>         >         >     >     > Both RPi and Rpi2 are based on the same
>         BSP, they just
>         >         >     differ in the
>         >         >     >     > peripheral offsets, hardcoded checks are
>         used to
>         >         select the
>         >         >     right
>         >         >     >     offset
>         >         >     >     > at the time of compiling
>         >         >     >
>         >         >     >     >From what I know of the Raspberry BSPs
>         that is correct.
>         >         >     >
>         >         >     >     > and the linkercmd file is responsible for
>         >         >     >     > building the final executable file.
>         >         >     >
>         >         >     >     The linkercmd file is - like for all
>         programs -
>         >         responsible
>         >         >     where the
>         >         >     >     memory regions are that can be used for
>         code or
>         >         data. So you
>         >         >     could more
>         >         >     >     or less explain it like you did.
>         >         >     >
>         >         >     >     > I looked at the linker script, it seem's
>         to have
>         >         the start
>         >         >     section at
>         >         >     >     > address 0x200000, I also loaded it in
>         GDB and the
>         >         start
>         >         >     address is
>         >         >     >     > *Start address 0x200080,*
>         >         >     >
>         >         >     >     I agree with that. The different start in
>         GDB is
>         >         most likely
>         >         >     because
>         >         >     >     there is a vector table in front (at least
>         if the
>         >         Broadcom chip is
>         >         >     >     similar to a lot of other processors that
>         I have
>         >         encountered).
>         >         >     >
>         >         >     >     Does that mean that you have a debugger
>         connected to the
>         >         >     raspberry? Can
>         >         >     >     you load code with it? If yes: Is the
>         bootloader
>         >         executed
>         >         >     before you
>         >         >     >     load your code? Otherwise the SDRAM might
>         isn't
>         >         initialized yet.
>         >         >     >
>         >         >     > I don't have a debugger connected to it. I
>         from what I
>         >         have SDRAM is
>         >         >     > initialized by the 3 stage bootloader(start.elf).
>         >         >
>         >         >     That should be OK and it answers my question above.
>         >         >
>         >         >     >
>         >         >     >     > I did some bare metal programming on RPI3
>         >         >     >     > there I had the start section at address
>         0x8000 Is
>         >         this causing
>         >         >     >     the problem?
>         >         >     >
>         >         >     >     I assume that you used some internal RAM
>         when you
>         >         did bare metal
>         >         >     >     programming. You maybe even skipped one or two
>         >         bootloader
>         >         >     stages. From a
>         >         >     >     quick look Raspberry has a quite complex boot
>         >         process with at
>         >         >     least
>         >         >     >     three bootloaders:
>         >         >     http://lions-wing.net/maker/raspberry-1/boot.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__lions-2Dwing.net_maker_raspberry-2D1_boot.html&d=DwMGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=Dj1p3ROFaQ16w58VFDVx6fw1I7dHf5UEdIpcnZ-azMw&s=k2cybXQYT8lHupn3mVt63WKOQDNmTuNg6YrMo1NBWYM&e=>
>         >         >     >
>         >         >     > I don't think I have skipped any stages. The
>         boot process is
>         >         >     exactly the
>         >         >     > same as how it boot's a normal raspbian or any
>         other linux
>         >         >     > distro, I just to replace the linux kernel
>         with my own
>         >         kernel.
>         >         >
>         >         >     Sounds reasonable. Does the bootloader print
>         anything
>         >         where it puts the
>         >         >     kernel image? Maybe the start address changed
>         during the
>         >         raspberry
>         >         >     versions.
>         >         >
>         >         > the default kernel load address is 0x8000 in 32bit
>         mode and
>         >         0x80000 in
>         >         > 64bit mode I have no idea about the raspberry 1,
>         >         > but the load address is same for rpi2 and 3.
>         >
>         >         That sounds odd. Do you have a memory map somewhere?
>         From the linker
>         >         command file it seems quite clear that RTEMS is build
>         for a
>         >         0x200000.
>         >
>         >         >
>         >         >     >
>         >         >     >
>         >         >     >     > I have no idea on how to debug this, any
>         >         suggestion on how
>         >         >     to start
>         >         >     >     > would be really helpfull.
>         >         >     >     >
>         >         >     >
>         >         >
>         >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191218/95e813af/attachment-0001.html>


More information about the devel mailing list