One clue for the Raspberry Pi 2 SMP problem: The regular samples work (hello.exe, ticker.exe, unlimited.exe) If I add #define CONFIGURE_MAXIMUM_PROCESSORS 4 to the init.c for hello, it does not work.
On Mon, Jan 20, 2020 at 11:52 AM Alan Cudmore <alan.cudm...@gmail.com> wrote: > Sorry for duplicate or incorrectly formatted messages. I need to setup an > e-mail client to just send plain text. . See my replies below: > > > > *From: *Christian Mauderer <l...@c-mauderer.de> > *Sent: *Sunday, January 19, 2020 2:49 PM > *To: *Alan Cudmore <alan.cudm...@gmail.com>; Christian Mauderer > <christian.maude...@embedded-brains.de>; gsnb...@gmail.com > *Cc: *rtems-de...@rtems.org <devel@rtems.org> > *Subject: *Re: Raspberry Pi test report > > > > On 19/01/2020 20:42, Alan Cudmore wrote: > > > I tried the latest RTEMS master on my collection of single core RPis and > > > they all worked. I used the kernel_address=0x200000 option in the > > > config.txt file. > > > The BSP did not identify the RPi Model B (26 pin GPIO header) or the RPi > > > Model A+ (1.1) since they use the older device ID register format. It's > > > probably a simple patch to identify these older models. Is it worth it, > > > given that they are not sold anymore? > > > > It's most likely only a wrong output. The memory size should be correct > > now. But nonetheless it's a bug and we currently mainly support the 1 > > and 2. Therefore I would say it's worth a fix. Do you want to add one? > > > > I can work on a fix to identify the older models. > > > > > > > > I also tried some simple tests on the RPi 2 (v 1.1) and they worked. > > > However the SMP tests seem to crash on the RPi 2. > > > Does anyone know if the RPi 2 SMP works on the latest master? I know it > > > has worked in the past. > > > > I didn't test it. Do you have some details? > > > > I’m just starting to troubleshoot, but I build the raspberrypi2 BSP with > –enable-smp. > > A few of the samples like ticker.exe and unlimited.exe work. > > But when I try smp01.exe, I don’t see any output past the model > Identification that is printed by the BSP: > > RTEMS RPi 2B 1.1 (1GB) [00a21041] > > > > 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!) > > > > Is the ticker.exe demo built differently than smp01.exe? These are both > under the same build with the same configure options. > > I will try to continue my troubleshooting a little later. > > > > > > > I wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model > > > is being phased out anyway. > > > > Again: Still a lot of boards around. And quite possible that the older > > ones that are phased out of some Linux applications are used now for > > RTEMS stuff. So I'm not a fan of removing the support. > > > > 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. > > > > > > > > It looks like there is progress being made on the RPi 3. The mini uart > > > support may also work on the RPi Zero W, since it has the same > > > wireless/bluetooth model as the 3. I can try the Pi 3 out whenever it is > > > ready. > > > Thanks for all of the recent RPI updates! > > > > Please give a special thanks to Niteesh. He does most of the current > > raspberry work. And thank you for the repeated testing. > > > > Absolutely! Niteesh’s work to allow RTEMS to work on the Raspberry Pi 3 is > very much appreciated! > > > > Thanks, > > Alan > > > > Best regards > > > > Christian > > > > > Alan > > > > > > > > > > > > On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore <alan.cudm...@gmail.com > > > <mailto:alan.cudm...@gmail.com>> wrote: > > > > > > 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. > > > 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. > > > > > > On Wed, Jan 8, 2020 at 1:18 AM Christian Mauderer > > > <christian.maude...@embedded-brains.de > > > <mailto:christian.maude...@embedded-brains.de>> wrote: > > > > > > On 08/01/2020 00:24, Joel Sherrill wrote: > > > > > > > > > > > > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > wrote: > > > > > > > > Hello Alan, > > > > > > > > I pushed the patches mentioned further below. So the > > > raspberry BSP > > > > should now work again for all raspberry 1 and 2 on the > > > official master > > > > branch. Note that the > > > > > > > > kernel_address=0x200000 > > > > > > > > is still necessary. > > > > > > > > > > > > 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? > > > > > > > > --joel > > > > > > > > > > As far as I followed his work Niteesh had some minimal version > > > working > > > with the mini UART and thought about trying the existing NS16550 > > > (after > > > I suggested that one). But I haven't seen a patch yet. So > > > currently even > > > if some basic stuff runs there will be no console. > > > > > > Beneath that: Pi 3 and Pi 4 are both 64Bit cores. I don't have > any > > > experience with aarch64. Therefore I'm not sure whether we can > > > safely > > > use them with 32Bit fallback. It seems to work to some extend but > > > according to > > > > > > https://en.wikipedia.org/wiki/ARM_architecture#AArch64 > > > > > > "ARMv8-A allows 32-bit applications to be executed in > > > a 64-bit OS, and a 32-bit OS to be under the control > > > of a 64-bit hypervisor." > > > > > > So I'm not sure in which situations we will run into problems. > > > Maybe on > > > interrupts? > > > > > > Best regards > > > > > > Christian > > > > > > > > > > > Best regards > > > > > > > > Christian > > > > > > > > On 06/01/2020 11:10, Christian Mauderer wrote: > > > > > Hello Alan, > > > > > > > > > > thanks for your very detailed tests. > > > > > > > > > > On 05/01/2020 23:42, Alan Cudmore wrote: > > > > >> 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 <http://git.rtems.org> > > > <http://git.rtems.org> > > > > <http://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 > > > > > > > > > > I don't think that we will apply that patch. It moves > > > code in an area > > > > > that is protected against access to catch null pointer > > > accesses later. > > > > > This increases the image size. > > > > > > > > > > The alternative is to add the line > > > > > > > > > > kernel_address=0x200000 > > > > > > > > > > to the config.txt of the raspberry SD image. Niteesh is > > > in the process > > > > > of documenting this: > > > > > > > > > > > > > > https://lists.rtems.org/pipermail/devel/2020-January/056796.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 > > > > > > > > > > I addressed that issue in the following patch set: > > > > > > > > > > > > > > https://lists.rtems.org/pipermail/devel/2019-December/056623.html > > > > > > > > > https://lists.rtems.org/pipermail/devel/2019-December/056622.html > > > > > > > > > https://lists.rtems.org/pipermail/devel/2019-December/056624.html > > > > > > > > > > I'll push it in the next days together with patches > > > regarding the > > > > > console from Niteesh. I just gave it some more time for > > > review during > > > > > the public holidays. > > > > > > > > > > Basically it addresses the issues that you describe > below. > > > > > > > > > >> > > > > >> 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. > > > > > > > > > > In the ideal case: All models. > > > > > In the real case: It's unfunded. Therefore we take the > > > ones that > > > > someone > > > > > is ready to add and maintain during free time. > > > > > > > > > > Beneath that I think it's more a question which models > > > should be in > > > > > which BSP variant. > > > > > > > > > > The `raspberry` variant uses the following CPU_CFLAGS: > > > > > > > > > > CPU_CFLAGS = -mcpu=arm1176jzf-s > > > > > > > > > > The `raspberry2` variant uses the following CPU_CFLAGS: > > > > > > > > > > CPU_CFLAGS = -march=armv7-a -mthumb -mfpu=neon > > > -mfloat-abi=hard > > > > > -mtune=cortex-a7 > > > > > > > > > > Maybe we will need a variant in the future for an > > > aarch64 support when > > > > > the core is supported in RTEMS somewhen. Currently I > > > hope that we can > > > > > just fall back to 32 Bit mode for the newer models. > > > > > > > > > > So the variants will end up with only a different core. > > > It should be > > > > > possible to handle other differences by parsing the FDT. > > > Niteesh > > > > already > > > > > started that with the console. > > > > > > > > > >> > > > > >> Thanks for you attention, and happy new year! > > > > > > > > > > A happy new year to you too. > > > > > > > > > > Best regards > > > > > > > > > > Christian > > > > > > > > > >> Alan > > > > >> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> devel mailing list > > > > >> devel@rtems.org <mailto:devel@rtems.org> > > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > > >> http://lists.rtems.org/mailman/listinfo/devel > > > > >> > > > > > _______________________________________________ > > > > > devel mailing list > > > > > devel@rtems.org <mailto:devel@rtems.org> > > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > _______________________________________________ > > > > devel mailing list > > > > devel@rtems.org <mailto:devel@rtems.org> > > > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > > > > _______________________________________________ > > > > devel mailing list > > > > devel@rtems.org <mailto:devel@rtems.org> > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > > -- > > > -------------------------------------------- > > > embedded brains GmbH > > > Herr Christian Mauderer > > > Dornierstr. 4 > > > D-82178 Puchheim > > > Germany > > > email: christian.maude...@embedded-brains.de > > > <mailto:christian.maude...@embedded-brains.de> > > > Phone: +49-89-18 94 741 - 18 > > > Fax: +49-89-18 94 741 - 08 > > > PGP: Public key available on request. > > > > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des > > > EHUG. > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org <mailto:devel@rtems.org> > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > _______________________________________________ > > > devel mailing list > > > devel@rtems.org > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
