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