<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>This is awesome work. What about the Pi 3 and and Pi 4? I think Niteesh has the Pi 3 working so that leaves the 4. Any idea?</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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 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 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 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>> 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 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 failed, I<br>
>> reviewed the latest mailing list posts, and ended up applying the 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 seemed to<br>
>> work fine on the Raspberry Pi Zero Models 1.2 and 1.3 (no 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 as well.<br>
>><br>
>> After the Pi Zero models, I tried my remaining older single core models:<br>
>> 1. Raspberry Pi Model B ( Original single core model with 512MB 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 changes,<br>
>> I made a couple of changes:<br>
>> - Reverted to the generic bspgetworkarea.c file, and changed the 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 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>
>> <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 revision which<br>
>> is not in the table in bspstart.c. I think we can fix this by adding the<br>
>> older revision codes in the table, but I think this code is mostly cosmetic.<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 bspgetworkarea.c<br>
>> is not correct:<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 rather<br>
>> than 0xf. The 0xF picks up the "new revision" field of the word.<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 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 these values.<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>
>> <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 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 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 all models.<br>
>> We may be able to use the following rationale to simplify the 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 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. 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 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 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 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 very<br>
>> similar to the Raspberry Pi 3 without the Wireless/Bluetooth 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 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 RTEMS<br>
>> target board available.<br>
>> - I would like one multi-core model as an inexpensive SMP target 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 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 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><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><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><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>