RTEMS on ARMv8

[Sebastian Huber]

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.