Problem running RTEMS on raspberrypi3

[Christian Mauderer]

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