Raspberry Pi test report
Alan Cudmore
alan.cudmore at gmail.com
Sun Jan 19 19:42:40 UTC 2020
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?
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 wouldn't mind dropping the Pi 2 once the Pi 3 is working.. The model is
being phased out anyway.
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!
Alan
On Wed, Jan 8, 2020 at 10:26 AM Alan Cudmore <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> 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>> 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> 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>
>> > >> 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
>> > >
>> > _______________________________________________
>> > 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
>> >
>>
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: 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
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200119/c7641084/attachment-0001.html>
More information about the devel
mailing list