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
Sent: Sunday, January 19, 2020 2:49 PM
To: Alan Cudmore; Christian Mauderer; gsnb...@gmail.com
Cc: rtems-de...@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

Reply via email to