On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer <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. > > 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? > > 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. 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 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*" *** 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). > > 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. > > > 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