Problem running RTEMS on raspberrypi3

Sun Dec 15 18:46:12 UTC 2019

On Sun, Dec 15, 2019 at 10:15 PM Christian Mauderer <list at 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191216/7b6ca9eb/attachment.html>