Raspberry Pi test report
Christian Mauderer
list at c-mauderer.de
Sun Jan 19 19:49:22 UTC 2020
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 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 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.
>
> 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.
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
>
More information about the devel
mailing list