RTEMS on ARMv8

Jeff Kubascik Jeff.Kubascik at dornerworks.com
Tue Apr 2 12:15:30 UTC 2019


On 4/2/2019 2:35 AM, Sebastian Huber wrote:
> On 02/04/2019 08:13, Sebastian Huber wrote:
>> On 01/04/2019 16:08, Jeff Kubascik wrote:
>>> On 4/1/2019 9:45 AM, Joel Sherrill wrote:
>>>> On Mon, Apr 1, 2019 at 7:54 AM Jeff Kubascik
>>>> <Jeff.Kubascik at dornerworks.com
>>>> <mailto:Jeff.Kubascik at dornerworks.com>> wrote:
>>>>
>>>>      On 3/28/2019 8:00 AM, Sebastian Huber wrote:
>>>>      > Hello Jeff,
>>>>      >
>>>>      > On 27/03/2019 19:11, Jeff Kubascik wrote:
>>>>      >> Hello,
>>>>      >>
>>>>      >> I am interested in porting RTEMS to run as a Xen guest on
>>>> our distro for the
>>>>      >> Xilinx Zynq UltraScale+ MPSoC. The MPSoC has an ARM
>>>> Cortex-A53 processor,
>>>>      which
>>>>      >> is based on the ARMv8 architecture.
>>>>      >>
>>>>      >> I have noticed that RTEMS already runs on a few Zynq 7000
>>>> boards.
>>>>      However, those
>>>>      >> are using the Cortex-A9 processor, which is based on the
>>>> ARMv7 architecture.
>>>>      >> Looking at the source code, I didn't see any ARMv8 cpu code.
>>>>      >>
>>>>      >> I was curious if there has been any work done to port RTEMS
>>>> to an ARMv8 based
>>>>      >> platform?
>>>>      >
>>>>      > AArch64 is a completely new architecture port. I think nobody
>>>> is working
>>>>      > on that. We may work on AArch32 support for the Zynq
>>>> UltraScale+ this year:
>>>>      >
>>>>      > http://devel.rtems.org/ticket/3682
>>>>      >
>>>>      > --
>>>>      > Sebastian Huber, embedded brains GmbH
>>>>      >
>>>>      > Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>>      > Phone   : +49 89 189 47 41-16
>>>>      > Fax     : +49 89 189 47 41-09
>>>>      > E-Mail  : sebastian.huber at embedded-brains.de
>>>>      <mailto:sebastian.huber at embedded-brains.de>
>>>>      > PGP     : Public key available on request.
>>>>      >
>>>>      > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
>>>> des EHUG.
>>>>      >
>>>>
>>>>      Sebastian,
>>>>
>>>>      We were able to hack up the xilinx-zynq BSP to get it running
>>>> on the Ultra96 in
>>>>      AArch32 mode. Surprisingly, it didn't require too many code
>>>> changes. Our key
>>>>      findings were
>>>>
>>>>      - Set the CP15BEN bit in the SCTLR register to enable legacy
>>>> memory barrier
>>>>      system instructions. This is used in the arm-cp15 cache
>>>> operations.
>>>>      - Clear the TRE bit in the SCTLR register to disable TEX remap.
>>>> This was causing
>>>>      the page table attributes to show up as strongly ordered,
>>>> resulting in an
>>>>      unaligned memory exceptions in the newlib memcpy.
>>>>      - Update peripheral addresses, IRQs, clock rates to match the
>>>> MPSoC.
>>>>      - Update the MMU peripheral region mappings.
>>>>      - Change the system clock source to clock-generic-timer.
>>>>      - Change the cache implementation to cache-cp15.
>>>>
>>>>      With the above changes, we are able to run all the applications
>>>> under the
>>>>      testsuites/samples directory on the Ultra96 via JTAG boot.
>>>>
>>>>      Over the weekend, I started putting together a new
>>>> xilinx-zynqmp BSP layer to
>>>>      support the Xilinx UltraScale+ MPSoC platform, including the
>>>> Ultra96 development
>>>>      board. If the RTEMS community is interested in these patches,
>>>> we are looking to
>>>>      submit them later in the week.
>>>>
>>>>
>>>> Cool! Sounds of interest.
>>>>
>>>> This sounds like it would be a variant on the existing xilinx 32-bit
>>>> BSP. Right?
>>>> Most of the code is unchanged but some conditionals.
>>>>
>>>> Were there changes outside the BSP?
>>>>
>>>> If strictly BSP, then it needs a name and then could be a variant of
>>>> the existing
>>>> BSP. That basically boils down to a config/*.cfg file with the BSP
>>>> variant name,
>>>> some mods to configure.ac <http://configure.ac> to give you an
>>>> automake variable
>>>> to switch the timer
>>>> to clock-generic-time in the Makefile.am, and something to trip the
>>>> various ifdef's
>>>> on.
>>>>
>>>> Then some instructions in the Users Guide on how you ran it.
>>>>
>>>> Of course, that's if I am understanding the magnitude of the change.
>>>>
>>>>
>>>>      -Jeff Kubascik
>>>>      _______________________________________________
>>>>      devel mailing list
>>>>      devel at rtems.org <mailto:devel at rtems.org>
>>>>      http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>> Yes, all the changes are located inside the BSP layer. However, the
>>> Zynq 7000
>>> and the Zynq UltraScale+ MPSoC are notably different platforms,
>>> enough that I
>>> believe to warrant a new BSP layer.
>>>
>>> Differences include
>>> - System addresses are completely different
>>> - Interrupt numbers are completely different
>>> - Cortex-A53 versus Cortex-A9 - this is why I had to change the timer
>>> and cache
>>> implementations
>>> - With the MPSoC, power and reset control is performed by a separate
>>> PMU processor
>>>
>>> There is still some overlap, for instance both platforms use the same
>>> UART
>>> controllers. I'm thinking this could be brought out to
>>> bsps/arm/shared/serial.
>>
>> Yes, this sounds more like a new BSP. Copy and paste should be avoided
>> with a code move to bsps/shared and bsps/arm/shared.
>>
> 
> Using the device tree instead of hard-coded addresses is also an option
> I would consider.
> 
> --
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 

The device tree approach would be preferable as we would like to eventually port
RTEMS to our Xen hypervisor distribution for the MPSoC. The Xen toolstack
dynamically generates a device tree based on the virtual machine configuration;
having RTEMS parse this would make things easier.

How capable is the device tree support in RTEMS? I did notice some device tree
code in the IMX BSP layer, but it appeared to reference fixed nodes. Does RTEMS
perform driver probing based on the device tree?

-Jeff Kubascik



More information about the devel mailing list