RTEMS on ARMv8

[Sebastian Huber]

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.

-- 
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.