<div dir="ltr">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<div>post the instructions. The steps that I followed are:</div><div>1. arm-rtems5-objcopy -Obinary hello.exe kernel.img</div><div>2. copied the kernel image to sd card and modified the config.txt to load the kernel img.</div><div>No success in following these steps. </div><div>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.</div><div>but RTEMS has a start address of 0x200080.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2019 at 7:51 PM 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">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 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 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>>> 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>>> 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>>>> wrote:<br>
> ><br>
> > On 15/12/2019 19:46, Niteesh wrote:<br>
> > ><br>
> > ><br>
> > > On Sun, Dec 15, 2019 at 10:15 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>><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>>>>> wrote:<br>
> > ><br>
> > > Hello Niteesh,<br>
> > ><br>
> > > On 15/12/2019 09:05, Niteesh wrote:<br>
> > > > I am trying to get RTEMS examples running on the<br>
> RPI3, the<br>
> > RPI3 is<br>
> > > > similar to RPI2 so the examples built for RPI2 should<br>
> > technically<br>
> > > run on<br>
> > > > the RPi3.But they don't :(, I am really sure of<br>
> what is causing<br>
> > > the problem.<br>
> > ><br>
> > > Note that there are at least two different versions<br>
> of the<br>
> > RPi3 which<br>
> > > use different chips. The original RPi3 which uses a<br>
> BCM2837<br>
> > (same like<br>
> > > later versions of RPi2) and the RPi3+ which uses a<br>
> BCM2837B0.<br>
> > Broadcom<br>
> > > is always quite sparse with documentation 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 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 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>
> 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 kernel img.<br>
> > ><br>
> > > It's a bit odd that the Bootloader doesn't use some<br>
> image<br>
> > format like<br>
> > > U-Boot but if that's the case for Raspberry, that's OK.<br>
> > ><br>
> > > Do you want me to try U-Boot, I was planning 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 with RTEMS?<br>
> ><br>
> > The manual that you linked uses the default 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 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 continue's<br>
> it's execution.<br>
> ><br>
> <br>
> I don't wanted to suggest to use an extra U-Boot. I was just not<br>
> sure<br>
> whether the stage 3 loader is an U-Boot. Your approach sounds<br>
> fine so far.<br>
> <br>
> > <br>
> ><br>
> > PS: You answered that further below. You are using the<br>
> stage 3 loader.<br>
> ><br>
> > ><br>
> > > > I did try running it on<br>
> > > > Qemu but it doesn't always work, sometimes it gives<br>
> > weird output.<br>
> > ><br>
> > > How did you run it on Qemu? Did you build 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 relevant for<br>
> your current<br>
> > problem. So if you don't have some manual just ignore the<br>
> question.<br>
> ><br>
> > ><br>
> > > I ran qemu along with GDB to find what was 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 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 () at<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 () 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 () 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 () at<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 CPU cores.<br>
> GDB shows them<br>
> > as threads. Most likely it wouldn't be able to detect the<br>
> RTEMS threads.<br>
> ><br>
> > It's a bit odd that they are all pointing to start.S:153.<br>
> That's the<br>
> > entry point for the program. It looks like not even one<br>
> instruction has<br>
> > been executed yet.<br>
> ><br>
> > I took this output before executing the program, 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 BSP reset<br>
> function<br>
> > this is<br>
> > > when the program crashes, the other threads 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 needed.<br>
> The one core<br>
> > doing the initialization work hits an exception somewhere<br>
> and calls the<br>
> > exception handler which calls the bsp reset function.<br>
> ><br>
> > The executing thread is NULL is a sign that it 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 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 what the<br>
> processor is doing<br>
> > there. You could try to set a breakpoint on the address<br>
> 0x00100fc4 and<br>
> > take a look at why the processor is there with a "bt"<br>
> (backtrace).<br>
> ><br>
> > When I re-run it again, it now stops at a different 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 threads<br>
> ><br>
> > (gdb) info threads <br>
> <br>
> > <br>
> <br>
> > <br>
> > Target Id Frame<br>
> > 1 Thread 1.1 (CPU#0 [running]) arm_ccsidr_get_line_power<br>
> > (ccsidr=<optimized out>)<br>
> > at<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>
> /home/niteesh/development/rtems/kernel/rtems/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h:1162<br>
> > 3 Thread 1.3 (CPU#2 [running]) arm_ccsidr_get_line_power<br>
> > (ccsidr=<optimized out>)<br>
> > at<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 (level_and_inst_dat=0)<br>
> > at<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 same time.<br>
> <br>
> Some of the initialization is done on all cores. Some isn't. I<br>
> took a<br>
> look at the initialization and it seems that I was wrong: There<br>
> is no<br>
> wait loop. All processors are running through the initialization<br>
> process. Some just skip parts. The part where they really start to<br>
> differ is in bsp_start_hook_0.<br>
> <br>
> > I> googled about just running one thread or CPU as you said at<br>
> a time and<br>
> > used "*set scheduler-locking on" *on doing this I 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>
> ../../../../../../../../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>
> ../../../../../../../../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>
> ../../../../../../../../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>
> ../../../../../../../../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 simulator and the<br>
> real<br>
> hardware. I'm not sure how well tested the SMP code is 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 that you hit it<br>
> with your rpi3 too. Maybe it would be good to try a single core<br>
> version<br>
> of the BSP. I assume you have configured with "--enable-smp"?<br>
> Can you<br>
> try to build without it?<br>
> <br>
> I built 2 versions with SMP enabled and disabled, the one we are<br>
> talking about is the SMP disabled version, I ran<br>
> the example with SMP enabled, still, the error's are similar, I only<br>
> difference is, in the disabled one, there are only 4 or less panic's<br>
> (maybe corresponding to 4 cpu's) but the other one has a 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 told me it seems<br>
> that the hardware is very similar so that we won't hit this<br>
> point soon.<br>
> Or do you already see differences that would make it necessary.<br>
> <br>
> I haven't had a look at the details but it could also 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 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 (#3784), you<br>
> mentioned about hardcoded values and initialization functions, can<br>
> you explain more about what exactly do the initialization functions<br>
> do? Do they assign a function to a particular pin, like in raspi<br>
> the pins are multiplexed for various functions, so do the<br>
> initialization functions assign those pins to a particular function?<br>
> <br>
> And also please explain how does the initialization of the 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>
> > 5.0.0.c6d8589bb00a9d2a5a094c68c90290df1dc44807-modified<br>
> > > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB<br>
> > > 83fa79314dd87c0a8c78fd642b2cea3138be8dd6, Newlib<br>
> 3e24fbf6f)<br>
> > > executing thread is NULL<br>
> > ><br>
> > > > The steps that I followed are:<br>
> > > > 1. Created a bootable SD card using 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 kernel (boots in<br>
> > aarch32 bit<br>
> > > mode).<br>
> > > > I am still not able to wrap my head around the RPI<br>
> bsp build<br>
> > process.<br>
> > > > This is what I understood as of now, correct me if<br>
> I am wrong. <br>
> > > > Both RPi and Rpi2 are based on the same BSP, they just<br>
> > differ in the<br>
> > > > peripheral offsets, hardcoded checks are 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 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 programs -<br>
> responsible<br>
> > where the<br>
> > > memory regions are that can be used for 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 to have<br>
> the start<br>
> > section at<br>
> > > > address 0x200000, I also loaded it in GDB and the<br>
> start<br>
> > address is<br>
> > > > *Start address 0x200080,*<br>
> > ><br>
> > > I agree with that. The different start in GDB is<br>
> most likely<br>
> > because<br>
> > > there is a vector table in front (at least if the<br>
> Broadcom chip is<br>
> > > similar to a lot of other processors that I have<br>
> encountered).<br>
> > ><br>
> > > Does that mean that you have a debugger connected to the<br>
> > raspberry? Can<br>
> > > you load code with it? If yes: Is the bootloader<br>
> executed<br>
> > before you<br>
> > > load your code? Otherwise the SDRAM might isn't<br>
> initialized yet.<br>
> > ><br>
> > > I don't have a debugger connected to it. I 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 0x8000 Is<br>
> this causing<br>
> > > the problem?<br>
> > ><br>
> > > I assume that you used some internal RAM 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 boot process is<br>
> > exactly the<br>
> > > same as how it boot's a normal raspbian or any other linux<br>
> > > distro, I just to replace the linux kernel with my own<br>
> kernel. <br>
> ><br>
> > Sounds reasonable. Does the bootloader print anything<br>
> where it puts the<br>
> > kernel image? Maybe the start address changed during the<br>
> raspberry<br>
> > versions.<br>
> ><br>
> > the default kernel load address is 0x8000 in 32bit 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? From the linker<br>
> command file it seems quite clear that RTEMS is build 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>
</blockquote></div>