<div dir="ltr">The Debian Linux variant for the Raspberry Pi (Raspbian) is still 32 bit for both the Pi 3 and 4, so I would think 32 bit ports would run on both.<div>The Raspberry Pi 4 has a Quad Core A72, 1 to 4 Gigabytes of LPDDR4 SDRAM, Gigabit ethernet, USB 3, Wi-fi and bluetooth. I have not looked into it enough to see what UARTs it uses.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On 08/01/2020 00:24, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> Hello Alan,<br>
> <br>
> I pushed the patches mentioned further below. So the raspberry BSP<br>
> should now work again for all raspberry 1 and 2 on the official master<br>
> branch. Note that the<br>
> <br>
> kernel_address=0x200000<br>
> <br>
> is still necessary.<br>
> <br>
> <br>
> This is awesome work. What about the Pi 3 and and Pi 4? I think Niteesh<br>
> has the Pi 3 working so that leaves the 4. Any idea?<br>
> <br>
> --joel<br>
> <br>
<br>
As far as I followed his work Niteesh had some minimal version working<br>
with the mini UART and thought about trying the existing NS16550 (after<br>
I suggested that one). But I haven't seen a patch yet. So currently even<br>
if some basic stuff runs there will be no console.<br>
<br>
Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have any<br>
experience with aarch64. Therefore I'm not sure whether we can safely<br>
use them with 32Bit fallback. It seems to work to some extend but<br>
according to<br>
<br>
<a href="https://en.wikipedia.org/wiki/ARM_architecture#AArch64" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/ARM_architecture#AArch64</a><br>
<br>
"ARMv8-A allows 32-bit applications to be executed in<br>
a 64-bit OS, and a 32-bit OS to be under the control<br>
of a 64-bit hypervisor."<br>
<br>
So I'm not sure in which situations we will run into problems. Maybe on<br>
interrupts?<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Best regards<br>
> <br>
> Christian<br>
> <br>
> On 06/01/2020 11:10, Christian Mauderer wrote:<br>
> > Hello Alan,<br>
> ><br>
> > thanks for your very detailed tests.<br>
> ><br>
> > On 05/01/2020 23:42, Alan Cudmore wrote:<br>
> >> I finally found the time to try the latest RTEMS head on my<br>
> collection<br>
> >> of Raspberry Pi models.<br>
> >> The last time I tried to run RTEMS on a Pi, I had trouble with the<br>
> >> current version of the Raspberry Pi Firmware, so I had to go back<br>
> to a<br>
> >> specific tag on the Rasberry Pi firmware repository to get RTEMS to<br>
> >> work. This time, the head of the firmware repository seems to<br>
> work (at<br>
> >> least on the single core models)<br>
> >><br>
> >> To keep things simple, I'm just going address the single core models<br>
> >> here, I can follow up after I finish testing the Raspberry Pi 2.<br>
> >><br>
> >> Test Setup:<br>
> >> I used the <a href="http://git.rtems.org" rel="noreferrer" target="_blank">git.rtems.org</a> <<a href="http://git.rtems.org" rel="noreferrer" target="_blank">http://git.rtems.org</a>><br>
> <<a href="http://git.rtems.org" rel="noreferrer" target="_blank">http://git.rtems.org</a>> rtems master from Jan 03<br>
> >> 2020.<br>
> >> I used the Raspberry Pi firmware from the same date.<br>
> >> The firmware can be found here:<br>
> >> <a href="https://github.com/raspberrypi/firmware/tree/master/boot" rel="noreferrer" target="_blank">https://github.com/raspberrypi/firmware/tree/master/boot</a><br>
> >> To boot an RTEMS image, you can copy all files from the above "boot"<br>
> >> directory on a DOS formatted SD/MicroSD card along with the RTEMS<br>
> image<br>
> >> (more about that in a minute).<br>
> >> On the SD card, I deleted the "dtb" files, as well as the overlay<br>
> >> directory. I dont think these are necessary to boot an RTEMS image.<br>
> >><br>
> >> I built a new arm-rtems5 toolchain using the RSB tool (head from the<br>
> >> same date) and built the "raspberrypi" BSP. After a quick test<br>
> failed, I<br>
> >> reviewed the latest mailing list posts, and ended up applying the<br>
> linker<br>
> >> script patch:<br>
> >> <a href="https://lists.rtems.org/pipermail/devel/2019-December/056551.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056551.html</a><br>
> ><br>
> > I don't think that we will apply that patch. It moves code in an area<br>
> > that is protected against access to catch null pointer accesses later.<br>
> > This increases the image size.<br>
> ><br>
> > The alternative is to add the line<br>
> ><br>
> > kernel_address=0x200000<br>
> ><br>
> > to the config.txt of the raspberry SD image. Niteesh is in the process<br>
> > of documenting this:<br>
> ><br>
> > <a href="https://lists.rtems.org/pipermail/devel/2020-January/056796.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-January/056796.html</a><br>
> ><br>
> >><br>
> >> After applying this patch and rebuilding, a few RTEMS samples<br>
> seemed to<br>
> >> work fine on the Raspberry Pi Zero Models 1.2 and 1.3 (no<br>
> wireless). I<br>
> >> ran hello.exe, ticker.exe, and unlimited.exe<br>
> >><br>
> >> The above images must be prepared using the following command:<br>
> >> $ arm-rtems5-objcopy -Obinary ticker.exe kernel.img<br>
> >> Then I copied kernel.img over the linux kernel on the SD card.<br>
> >><br>
> >> For all of these tests, I found this serial to USB board to be very<br>
> >> useful in my tests:<br>
> >> <a href="https://www.adafruit.com/product/3589" rel="noreferrer" target="_blank">https://www.adafruit.com/product/3589</a><br>
> >> It can power the pi through the USB cable and has a power switch<br>
> as well.<br>
> >><br>
> >> After the Pi Zero models, I tried my remaining older single core<br>
> models:<br>
> >> 1. Raspberry Pi Model B ( Original single core model with 512MB<br>
> of RAM<br>
> >> and 26 pin GPIO header)<br>
> >> 2. Raspberry Pi Model B+ (Updated Single core model with 512MB of RAM<br>
> >> and 40 pin GPIO header)<br>
> >> 3. Raspberry Pi Model A+ (Smaller form factor single core model with<br>
> >> 256MB of RAM and 40 pin GPIO header)<br>
> >> (Note this model has been updated to now have 512MB of RAM)<br>
> >><br>
> >> All three of the above models had the same exception that has been<br>
> >> discussed on the mailing list:<br>
> >> <a href="https://lists.rtems.org/pipermail/devel/2019-December/056556.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056556.html</a><br>
> ><br>
> > I addressed that issue in the following patch set:<br>
> ><br>
> > <a href="https://lists.rtems.org/pipermail/devel/2019-December/056623.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056623.html</a><br>
> > <a href="https://lists.rtems.org/pipermail/devel/2019-December/056622.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056622.html</a><br>
> > <a href="https://lists.rtems.org/pipermail/devel/2019-December/056624.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-December/056624.html</a><br>
> ><br>
> > I'll push it in the next days together with patches regarding the<br>
> > console from Niteesh. I just gave it some more time for review during<br>
> > the public holidays.<br>
> ><br>
> > Basically it addresses the issues that you describe below.<br>
> ><br>
> >><br>
> >> All of these single core models are supposed to be compatible, and<br>
> >> should run the same RTEMS image given the same memory configuration.<br>
> >> Since the previous message was discussing the bspgetworkarea.c<br>
> changes,<br>
> >> I made a couple of changes:<br>
> >> - Reverted to the generic bspgetworkarea.c file, and changed the<br>
> memory<br>
> >> size from 256MB to 128MB ( same as the 4.11 release ).<br>
> >> With these changes, the same RTEMS images worked on all single<br>
> core models:<br>
> >> - RPi Zero 1.2 and 1.3<br>
> >> - RPi Model B<br>
> >> - RPi Model B+<br>
> >> - RPi Model A+<br>
> >><br>
> >> Findings:<br>
> >> 1. The code that identifies the models in bspstart.c does not account<br>
> >> for the older models:<br>
> >><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspstart.c</a><br>
> >> The RPi Model B, B+, and A+ that I have all use the older<br>
> revision which<br>
> >> is not in the table in bspstart.c. I think we can fix this by<br>
> adding the<br>
> >> older revision codes in the table, but I think this code is<br>
> mostly cosmetic.<br>
> >><br>
> <a href="https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md" rel="noreferrer" target="_blank">https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md</a><br>
> >><br>
> >> 2. I think the code that determines the memory size in<br>
> bspgetworkarea.c<br>
> >> is not correct:<br>
> >><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c</a><br>
> >> a) The mask for the memory size field should probably be 0x7<br>
> rather<br>
> >> than 0xf. The 0xF picks up the "new revision" field of the word.<br>
> >> <br>
> >><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n70</a><br>
> >> b) I'm not sure if the rpi_mem array is correct. The values<br>
> are used<br>
> >> in address size calculations, but the values seem to be in Kilobytes,<br>
> >> not Megabytes. Maybe I'm not catching a shift that is done on<br>
> these values.<br>
> >> <br>
> >><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n73</a><br>
> >> c) I'm not sure that the numbers all add up. Line 80 computes the<br>
> >> ram_end value by adding the Work Area start to the total size of the<br>
> >> RAM. I think this will overrun the end of the RAM.<br>
> >> <br>
> >><br>
> <a href="https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/raspberrypi/start/bspgetworkarea.c#n80</a><br>
> >> d) I would like to look at the relationship between the ram_end<br>
> >> calculation and the ram_size given in the autoconfigure setting (<br>
> >> currently at 256MiB). Are the MMU settings done based on the hard<br>
> coded<br>
> >> linker script value that may conflict with the sizes set here?<br>
> >> e) the code may not work for the older models that do not<br>
> have the<br>
> >> updated revision fields.<br>
> >><br>
> >> If the intent is to cover the different raspberry pi memory sizes<br>
> >> automatically, then we can probably rework this code to work for<br>
> all models.<br>
> >> We may be able to use the following rationale to simplify the<br>
> memory logic:<br>
> >> 1. All of the current production single core raspberry Pi models have<br>
> >> 512MB of RAM. Do we need to worry about out of production 256MiB<br>
> models?<br>
> >> I have an older A+ model with 256MiB, but I am unlikely to use it for<br>
> >> anything serious. I would rather use a Raspberry Pi Zero instead.<br>
> Given<br>
> >> that, we could assume that the "raspberrypi" BSP has 512 MiB of RAM.<br>
> >> This would only require the calculation of how much memory is<br>
> devoted to<br>
> >> the GPU.<br>
> >><br>
> >> 2. All of the Raspberry Pi 2 models have 1 Gigabyte of RAM, so the<br>
> >> raspberrypi2 BSP can safely assume 1 gigabyte. <br>
> >><br>
> >> We could also use the specific revision code register (old and<br>
> new) to<br>
> >> set the RAM size, since that should be accurate.<br>
> >><br>
> >> Anyway, that is what I have so far on the single core models. I would<br>
> >> like to take a look at the Pi 2 next. Note that the Pi 2 is a<br>
> Quad A7,<br>
> >> that is considered "legacy" but it is still in production. The latest<br>
> >> Raspberry Pi 2 has been switched to a Quad core A53, so it is now<br>
> very<br>
> >> similar to the Raspberry Pi 3 without the Wireless/Bluetooth<br>
> module. I<br>
> >> dont have a Raspberry Pi 2 with an A53.<br>
> >><br>
> >> There are quite a few newer models as well, so it's probably worth a<br>
> >> discussion of what we really want to support. My personal<br>
> preferences:<br>
> >> - Of the single core models, I would be happy with Raspberry Pi Zero<br>
> >> (and possibly Zero W) support. These are are very inexpensive and<br>
> >> available worldwide. It may be the least expensive non-simulator<br>
> RTEMS<br>
> >> target board available.<br>
> >> - I would like one multi-core model as an inexpensive SMP target<br>
> to work<br>
> >> with and learn RTEMS SMP details. Again, my focus is on low cost and<br>
> >> wide availability.<br>
> ><br>
> > In the ideal case: All models.<br>
> > In the real case: It's unfunded. Therefore we take the ones that<br>
> someone<br>
> > is ready to add and maintain during free time.<br>
> ><br>
> > Beneath that I think it's more a question which models should be in<br>
> > which BSP variant.<br>
> ><br>
> > The `raspberry` variant uses the following CPU_CFLAGS:<br>
> ><br>
> > CPU_CFLAGS = -mcpu=arm1176jzf-s<br>
> ><br>
> > The `raspberry2` variant uses the following CPU_CFLAGS:<br>
> ><br>
> > CPU_CFLAGS = -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard<br>
> > -mtune=cortex-a7<br>
> ><br>
> > Maybe we will need a variant in the future for an aarch64 support when<br>
> > the core is supported in RTEMS somewhen. Currently I hope that we can<br>
> > just fall back to 32 Bit mode for the newer models.<br>
> ><br>
> > So the variants will end up with only a different core. It should be<br>
> > possible to handle other differences by parsing the FDT. Niteesh<br>
> already<br>
> > started that with the console.<br>
> ><br>
> >><br>
> >> Thanks for you attention, and happy new year!<br>
> ><br>
> > A happy new year to you too.<br>
> ><br>
> > Best regards<br>
> ><br>
> > Christian<br>
> ><br>
> >> Alan<br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> devel mailing list<br>
> >> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> >><br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> ><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>