Thank you for the updates, I will try out the latest on my collection of
Raspberry Pis and report back.
Alan
On 1/7/20, 1:47 PM, "devel on behalf of Christian Mauderer"
<devel-boun...@rtems.org on behalf of 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.
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
<https://urldefense.proofpoint.com/v2/url?u=http-3A__git.rtems.org&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=dwL4jUSPWUSC9CNoxKBminRmNg54lN3HIh3ieWbHjHY&e=
> rtems master from Jan 03
>> 2020.
>> I used the Raspberry Pi firmware from the same date.
>> The firmware can be found here:
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_firmware_tree_master_boot&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=PTx9y7REtCqICcxlngPx3cPtokUsZviH9R58ebNv6vo&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056551.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=flUH8jUi8ixjtv4XbduImKPMiy6XvlyAxh7I0mBsv6Y&e=
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2020-2DJanuary_056796.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=WQsPX2PnRA6i0f7Vh3IjAg3xqfh0yuqMQc7qQ3PH5Og&e=
>
>>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.adafruit.com_product_3589&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=ID9UkEyd1TRcGUrZYw4RgFCGNP5qxxlwbVqwIvp_K9I&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056556.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=5rxK9skSleKJRecsBIIIvxmJvjUfvnBBQEj8RKksTUk&e=
>
> I addressed that issue in the following patch set:
>
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056623.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=iXLeip_E4QfXHjwpf3dwHDWyJ3pEeqvqgKLtdw9IKfc&e=
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056622.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=YScHkulPGgtU634q0v2N2YSgPRIvso7xoFT08QTuKqo&e=
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.rtems.org_pipermail_devel_2019-2DDecember_056624.html&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=EF7di1PVEQ-rEdDdkyTNbRguUcYuzrZEkgnhLDrxJng&e=
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_bsps_arm_raspberrypi_start_bspstart.c&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=sNkLErYOaD5FE2NNSYnRVpiwHfuydEUhQ5p2BAKUCTg&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.raspberrypi.org_documentation_hardware_raspberrypi_revision-2Dcodes_README.md&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=84SjKUbmchcnQYABnz7X3C0mF7tDySgSPWc6DzdccOg&e=
>>
>> 2. I think the code that determines the memory size in bspgetworkarea.c
>> is not correct:
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_bsps_arm_raspberrypi_start_bspgetworkarea.c&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=4JQsl6gHJWxNa3qY0wZndvaQURBcyOtnVtZPM8JIx5w&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_bsps_arm_raspberrypi_start_bspgetworkarea.c-23n70&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=edMylXDmeEK_nek4fuyG2B1ebVS_25u1htjrbyAc-Wc&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_bsps_arm_raspberrypi_start_bspgetworkarea.c-23n73&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=iD0vDSw7lgjzeVeSgxZ9ZJRqloCA_U5RDPFNk6ppnJ0&e=
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_bsps_arm_raspberrypi_start_bspgetworkarea.c-23n80&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=fYoOOtqQjUePKHfKCsUYthfzpovIQAC3eSCat-Zcy0I&e=
>> 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
>>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=UEoShSHrf12BRPV01a53F4mUinNx6AjXoF4TXwMcJhM&e=
>>
> _______________________________________________
> devel mailing list
> devel@rtems.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=UEoShSHrf12BRPV01a53F4mUinNx6AjXoF4TXwMcJhM&e=
>
_______________________________________________
devel mailing list
devel@rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIGaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=wy1BGg4ZiW4w68tOY86-Ycg9NuG7njg6WWHANSWIvxk&s=UEoShSHrf12BRPV01a53F4mUinNx6AjXoF4TXwMcJhM&e=
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
