Raspberry Pi test report
Alan Cudmore
alan.cudmore at gmail.com
Mon Jan 20 17:03:00 UTC 2020
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.cudmore at 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 <list at c-mauderer.de>
> *Sent: *Sunday, January 19, 2020 2:49 PM
> *To: *Alan Cudmore <alan.cudmore at gmail.com>; Christian Mauderer
> <christian.mauderer at embedded-brains.de>; gsnb.gn at gmail.com
> *Cc: *rtems-devel at rtems.org <devel at 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.cudmore at gmail.com
>
> > <mailto:alan.cudmore at 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.mauderer at embedded-brains.de
>
> > <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> >
>
> > On 08/01/2020 00:24, Joel Sherrill wrote:
>
> > >
>
> > >
>
> > > On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer
>
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
>
> > > <mailto:list at c-mauderer.de <mailto:list at 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 at rtems.org <mailto:devel at rtems.org>
>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>
> > > >> http://lists.rtems.org/mailman/listinfo/devel
>
> > > >>
>
> > > > _______________________________________________
>
> > > > devel mailing list
>
> > > > devel at rtems.org <mailto:devel at rtems.org>
>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>
> > > > http://lists.rtems.org/mailman/listinfo/devel
>
> > > >
>
> > > _______________________________________________
>
> > > devel mailing list
>
> > > devel at rtems.org <mailto:devel at rtems.org>
>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>
> > > http://lists.rtems.org/mailman/listinfo/devel
>
> > >
>
> > >
>
> > > _______________________________________________
>
> > > devel mailing list
>
> > > devel at rtems.org <mailto:devel at rtems.org>
>
> > > http://lists.rtems.org/mailman/listinfo/devel
>
> > >
>
> >
>
> > --
>
> > --------------------------------------------
>
> > embedded brains GmbH
>
> > Herr Christian Mauderer
>
> > Dornierstr. 4
>
> > D-82178 Puchheim
>
> > Germany
>
> > email: christian.mauderer at embedded-brains.de
>
> > <mailto:christian.mauderer at 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 at rtems.org <mailto:devel at rtems.org>
>
> > http://lists.rtems.org/mailman/listinfo/devel
>
> >
>
> >
>
> > _______________________________________________
>
> > devel mailing list
>
> > devel at rtems.org
>
> > http://lists.rtems.org/mailman/listinfo/devel
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200120/86673c5d/attachment-0001.html>
More information about the devel
mailing list