Raspberry Pi test report

Mon Jan 6 10:10:57 UTC 2020

Hello Alan,

thanks for your very detailed tests.

On 05/01/2020 23:42, Alan Cudmore wrote:
> I finally found the time to try the latest RTEMS head on my collection
> of Raspberry Pi models.
> The last time I tried to run RTEMS on a Pi, I had trouble with the
> current version of the Raspberry Pi Firmware, so I had to go back to a
> specific tag on the Rasberry Pi firmware repository to get RTEMS to
> work. This time, the head of the firmware repository seems to work (at
> least on the single core models)
> 
> To keep things simple, I'm just going address the single core models
> here, I can follow up after I finish testing the Raspberry Pi 2.
> 
> Test Setup:
> I used the git.rtems.org <http://git.rtems.org> rtems master from Jan 03
> 2020.
> I used the Raspberry Pi firmware from the same date.
> The firmware can be found here:
> https://github.com/raspberrypi/firmware/tree/master/boot
> To boot an RTEMS image, you can copy all files from the above "boot"
> directory on a DOS formatted SD/MicroSD card along with the RTEMS image
> (more about that in a minute).
> On the SD card, I deleted the "dtb" files, as well as the overlay
> directory. I dont think these are necessary to boot an RTEMS image.
> 
> I built a new arm-rtems5 toolchain using the RSB tool (head from the
> same date) and built the "raspberrypi" BSP. After a quick test failed, I
> reviewed the latest mailing list posts, and ended up applying the linker
> script patch:
> https://lists.rtems.org/pipermail/devel/2019-December/056551.html

I don't think that we will apply that patch. It moves code in an area
that is protected against access to catch null pointer accesses later.
This increases the image size.

The alternative is to add the line

    kernel_address=0x200000

to the config.txt of the raspberry SD image. Niteesh is in the process
of documenting this:

    https://lists.rtems.org/pipermail/devel/2020-January/056796.html

> 
> After applying this patch and rebuilding, a few RTEMS samples seemed to
> work fine on the Raspberry Pi Zero Models 1.2 and 1.3 (no wireless). I
> ran hello.exe, ticker.exe, and unlimited.exe
> 
> The above images must be prepared using the following command:
> $ arm-rtems5-objcopy -Obinary ticker.exe kernel.img
> Then I copied kernel.img over the linux kernel on the SD card.
> 
> For all of these tests, I found this serial to USB board to be very
> useful in my tests:
> https://www.adafruit.com/product/3589
> It can power the pi through the USB cable and has a power switch as well.
> 
> After the Pi Zero models, I tried my remaining older single core models:
> 1. Raspberry Pi Model B ( Original single core model with 512MB of RAM
> and 26 pin GPIO header)
> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM
> and 40 pin GPIO header)
> 3. Raspberry Pi Model A+ (Smaller form factor single core model with
> 256MB of RAM and 40 pin GPIO header)
>    (Note this model has been updated to now have 512MB of RAM)
> 
> All three of the above models had the same exception that has been
> discussed on the mailing list:
> https://lists.rtems.org/pipermail/devel/2019-December/056556.html

I addressed that issue in the following patch set:

    https://lists.rtems.org/pipermail/devel/2019-December/056623.html
    https://lists.rtems.org/pipermail/devel/2019-December/056622.html
    https://lists.rtems.org/pipermail/devel/2019-December/056624.html

I'll push it in the next days together with patches regarding the
console from Niteesh. I just gave it some more time for review during
the public holidays.

Basically it addresses the issues that you describe below.

> 
> All of these single core models are supposed to be compatible, and
> should run the same RTEMS image given the same memory configuration.
> Since the previous message was discussing the bspgetworkarea.c changes,
> I made a couple of changes:
> - Reverted to the generic bspgetworkarea.c file, and changed the memory
> size from 256MB to 128MB ( same as the 4.11 release ).
> With these changes, the same RTEMS images worked on all single core models:
> - RPi Zero 1.2 and 1.3
> - RPi Model B
> - RPi Model B+
> - RPi Model A+
> 
> Findings:
> 1. The code that identifies the models in bspstart.c does not account
> for the older models:
> https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c
> The RPi Model B, B+, and A+ that I have all use the older revision which
> is not in the table in bspstart.c. I think we can fix this by adding the
> older revision codes in the table, but I think this code is mostly cosmetic.
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
> 
> 2. I think the code that determines the memory size in bspgetworkarea.c
> is not correct:
> https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c
>     a) The mask for the memory size field should probably be 0x7 rather
> than 0xf. The 0xF picks up the "new revision" field of the word.
>      
>  https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70
>     b) I'm not sure if the rpi_mem array is correct. The values are used
> in address size calculations, but the values seem to be in Kilobytes,
> not Megabytes. Maybe I'm not catching a shift that is done on these values.
>      
>  https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73
>     c) I'm not sure that the numbers all add up. Line 80 computes the
> ram_end value by adding the Work Area start to the total size of the
> RAM. I think this will overrun the end of the RAM.
>    
>  https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80
>     d) I would like to look at the relationship between the ram_end
> calculation and the ram_size given in the autoconfigure setting (
> currently at 256MiB). Are the MMU settings done based on the hard coded
> linker script value that may conflict with the sizes set here?
>     e) the code may not work for the older models that do not have the
> updated revision fields.
> 
> If the intent is to cover the different raspberry pi memory sizes
> automatically, then we can probably rework this code to work for all models.
> We may be able to use the following rationale to simplify the memory logic:
> 1. All of the current production single core raspberry Pi models have
> 512MB of RAM. Do we need to worry about out of production 256MiB models?
> I have an older A+ model with 256MiB, but I am unlikely to use it for
> anything serious. I would rather use a Raspberry Pi Zero instead. Given
> that, we could assume that the "raspberrypi" BSP has 512 MiB of RAM.
> This would only require the calculation of how much memory is devoted to
> the GPU.
> 
> 2. All of the Raspberry Pi 2 models have 1 Gigabyte of RAM, so the
> raspberrypi2 BSP can safely assume 1 gigabyte. 
> 
> We could also use the specific revision code register (old and new) to
> set the RAM size, since that should be accurate.
> 
> Anyway, that is what I have so far on the single core models. I would
> like to take a look at the Pi 2 next. Note that the Pi 2 is a Quad A7,
> that is considered "legacy" but it is still in production. The latest
> Raspberry Pi 2 has been switched to a Quad core A53, so it is now very
> similar to the Raspberry Pi 3 without the Wireless/Bluetooth module. I
> dont have a Raspberry Pi 2 with an A53.
> 
> There are quite a few newer models as well, so it's probably worth a
> discussion of what we really want to support. My personal preferences:
> - Of the single core models, I would be happy with Raspberry Pi Zero
> (and possibly Zero W) support. These are are very inexpensive and
> available worldwide. It may be the least expensive non-simulator RTEMS
> target board available.
> - I would like one multi-core model as an inexpensive SMP target to work
> with and learn RTEMS SMP details. Again, my focus is on low cost and
> wide availability.

In the ideal case: All models.
In the real case: It's unfunded. Therefore we take the ones that someone
is ready to add and maintain during free time.

Beneath that I think it's more a question which models should be in
which BSP variant.

The `raspberry` variant uses the following CPU_CFLAGS:

    CPU_CFLAGS = -mcpu=arm1176jzf-s

The `raspberry2` variant uses the following CPU_CFLAGS:

    CPU_CFLAGS = -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard
-mtune=cortex-a7

Maybe we will need a variant in the future for an aarch64 support when
the core is supported in RTEMS somewhen. Currently I hope that we can
just fall back to 32 Bit mode for the newer models.

So the variants will end up with only a different core. It should be
possible to handle other differences by parsing the FDT. Niteesh already
started that with the console.

> 
> Thanks for you attention, and happy new year!

A happy new year to you too.

Best regards

Christian

> Alan
> 
> 
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 