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