<div dir="ltr">I finally found the time to try the latest RTEMS head on my collection of Raspberry Pi models.<div>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)</div><div><br></div><div>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.</div><div><br></div><div>Test Setup:</div><div>I used the <a href="http://git.rtems.org">git.rtems.org</a> rtems master from Jan 03 2020.</div><div>I used the Raspberry Pi firmware from the same date.</div><div>The firmware can be found here:</div><div><a href="https://github.com/raspberrypi/firmware/tree/master/boot">https://github.com/raspberrypi/firmware/tree/master/boot</a></div><div>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).</div><div>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.</div><div><br></div><div>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:</div><div><a href="https://lists.rtems.org/pipermail/devel/2019-December/056551.html">https://lists.rtems.org/pipermail/devel/2019-December/056551.html</a><br></div><div><br></div><div>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</div><div><br></div><div>The above images must be prepared using the following command:</div><div>$ arm-rtems5-objcopy -Obinary ticker.exe kernel.img</div><div>Then I copied kernel.img over the linux kernel on the SD card.</div><div><br></div><div>For all of these tests, I found this serial to USB board to be very useful in my tests:</div><div><a href="https://www.adafruit.com/product/3589">https://www.adafruit.com/product/3589</a><br></div><div>It can power the pi through the USB cable and has a power switch as well.</div><div><br></div><div>After the Pi Zero models, I tried my remaining older single core models:</div><div>1. Raspberry Pi Model B ( Original single core model with 512MB of RAM and 26 pin GPIO header)</div><div>2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM and 40 pin GPIO header)</div><div>3. Raspberry Pi Model A+ (Smaller form factor single core model with 256MB of RAM and 40 pin GPIO header)</div><div>   (Note this model has been updated to now have 512MB of RAM)</div><div><br></div><div>All three of the above models had the same exception that has been discussed on the mailing list:</div><div><a href="https://lists.rtems.org/pipermail/devel/2019-December/056556.html">https://lists.rtems.org/pipermail/devel/2019-December/056556.html</a><br></div><div><br></div><div>All of these single core models are supposed to be compatible, and should run the same RTEMS image given the same memory configuration.</div><div>Since the previous message was discussing the bspgetworkarea.c changes, I made a couple of changes:</div><div>- Reverted to the generic bspgetworkarea.c file, and changed the memory size from 256MB to 128MB ( same as the 4.11 release ).</div><div>With these changes, the same RTEMS images worked on all single core models:</div><div>- RPi Zero 1.2 and 1.3</div><div>- RPi Model B</div><div>- RPi Model B+</div><div>- RPi Model A+</div><div><br></div><div>Findings:</div><div>1. The code that identifies the models in bspstart.c does not account for the older models:</div><div><a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c</a><br></div><div>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.</div><div><a href="https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md">https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md</a><br></div><div><br></div><div>2. I think the code that determines the memory size in bspgetworkarea.c is not correct:</div><div><a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c</a><br></div><div>    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.</div><div>       <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70</a></div><div>    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.</div><div>       <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73</a></div><div>    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.</div><div>     <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80</a></div><div>    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?</div><div>    e) the code may not work for the older models that do not have the updated revision fields.</div><div><br></div><div>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.</div><div>We may be able to use the following rationale to simplify the memory logic:</div><div>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.</div><div><br></div><div>2. All of the Raspberry Pi 2 models have 1 Gigabyte of RAM, so the raspberrypi2 BSP can safely assume 1 gigabyte. </div><div><br></div><div>We could also use the specific revision code register (old and new) to set the RAM size, since that should be accurate.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div>- 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.</div><div>- 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.</div><div><br></div><div>Thanks for you attention, and happy new year!</div><div>Alan</div><div><br></div><div><br></div></div>