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>> 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 > > > 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. 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. > > 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). > > *** 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. > > > > 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
