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