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...@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 <l...@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...@gmail.com >> > <mailto:gsnb...@gmail.com>> wrote: >> > >> > On Mon, Dec 16, 2019 at 2:36 AM Christian Mauderer >> > <l...@c-mauderer.de <mailto:l...@c-mauderer.de>> wrote: >> > >> > >> > >> > On 15/12/2019 21:29, Niteesh wrote: >> > > >> > > >> > > On Mon, Dec 16, 2019 at 12:53 AM Christian Mauderer >> > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> >> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> >> wrote: >> > > >> > > On 15/12/2019 19:46, Niteesh wrote: >> > > > >> > > > >> > > > On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer >> > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> >> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> >> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> >> > <mailto:l...@c-mauderer.de <mailto:l...@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 >> (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 >> > > > >> > > > 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. >> > > > > >> > > > >> > > >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
