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 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. > 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? > 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 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 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