RTEMS on ARMv8
Jeff Kubascik
Jeff.Kubascik at dornerworks.com
Mon Apr 1 14:08:53 UTC 2019
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.
-Jeff Kubascik
More information about the devel
mailing list