Raspberry Pi test report

Tue Jan 7 23:24:27 UTC 2020

On Tue, Jan 7, 2020 at 12:42 PM Christian Mauderer <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

>
> 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> 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
> >> http://lists.rtems.org/mailman/listinfo/devel
> >>
> > _______________________________________________
> > devel mailing list
> > 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/20200107/f85bb84d/attachment-0001.html>