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.kubas...@dornerworks.com >>>> <mailto:jeff.kubas...@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.hu...@embedded-brains.de >>>> <mailto:sebastian.hu...@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@rtems.org <mailto:devel@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.hu...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
