Raspberry Pi test report

[Alan Cudmore]

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

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

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.

Thanks for you attention, and happy new year!
Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200105/262ffeef/attachment.html>