Re: RTEMS on ARMv8

[Gedare Bloom]

On Tue, Apr 2, 2019 at 8:34 AM Joel Sherrill  wrote:
>
>
>
> On Tue, Apr 2, 2019, 7:21 AM Sebastian Huber 
>  wrote:
>>
>> On 02/04/2019 14:15, Jeff Kubascik wrote:
>> > 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?
>>
>> The device tree support in RTEMS is quite rudimentary. However, in the
>> BSP you don't need much. You just have to deal with the interrupt
>> controller, the clock driver and an UART driver. Maybe also I2C and SPI,
>> but these are simple things. The more complex drivers are in libbsd
>> (USB, MMC/SDCard, Ethernet). Here we have the device tree support from
>> FreeBSD. It is not as good as the device tree support from Linux
>> especially if it comes down to pins and clocks since this is a real mess
>> usually.
>
>
> Neither of us mentioned licence. We do not accept GPL code in RTEMS because 
> it is statically linked with applications and this would result in 
> applications needing to follow the GPL requirements.
>
> The 2 paragraph BSD license is not the preferred license. The historical 
> RTEMS license is GPLv2 with a linking exclusion. It was based on the GCC 
> runtimes.
>

2-BSD is NOW the preferred license.

> --joel
>>
>>
>> --
>> 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.
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

On 4/2/2019 8:34 AM, Joel Sherrill wrote:
> On Tue, Apr 2, 2019, 7:21 AM Sebastian Huber 
>  > wrote:
> 
> On 02/04/2019 14:15, Jeff Kubascik wrote:
> > 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?
> 
> The device tree support in RTEMS is quite rudimentary. However, in the
> BSP you don't need much. You just have to deal with the interrupt
> controller, the clock driver and an UART driver. Maybe also I2C and SPI,
> but these are simple things. The more complex drivers are in libbsd
> (USB, MMC/SDCard, Ethernet). Here we have the device tree support from
> FreeBSD. It is not as good as the device tree support from Linux
> especially if it comes down to pins and clocks since this is a real mess
> usually.
> 
> 
> Neither of us mentioned licence. We do not accept GPL code in RTEMS because it
> is statically linked with applications and this would result in applications
> needing to follow the GPL requirements.
> 
> The 2 paragraph BSD license is not the preferred license. The historical RTEMS
> license is GPLv2 with a linking exclusion. It was based on the GCC runtimes.
> 
> --joel
> 
> 
> -- 
> 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.
> 

That is good information to know. My plan is to use the RTEMS license for the
MPSoC BSP to keep things simple.

However, the Xen support could be tricky, as the majority of the kernel and
library code is GPLv2. We have ported other operating systems to Xen in the
past, and from what I remember, the Xen headers that were copied into the guest
OS code do have a MIT license.

-Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Joel Sherrill]

On Tue, Apr 2, 2019, 7:21 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 02/04/2019 14:15, Jeff Kubascik wrote:
> > 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?
>
> The device tree support in RTEMS is quite rudimentary. However, in the
> BSP you don't need much. You just have to deal with the interrupt
> controller, the clock driver and an UART driver. Maybe also I2C and SPI,
> but these are simple things. The more complex drivers are in libbsd
> (USB, MMC/SDCard, Ethernet). Here we have the device tree support from
> FreeBSD. It is not as good as the device tree support from Linux
> especially if it comes down to pins and clocks since this is a real mess
> usually.
>

Neither of us mentioned licence. We do not accept GPL code in RTEMS because
it is statically linked with applications and this would result in
applications needing to follow the GPL requirements.

The 2 paragraph BSD license is not the preferred license. The historical
RTEMS license is GPLv2 with a linking exclusion. It was based on the GCC
runtimes.

--joel

>
> --
> 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.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Sebastian Huber]

On 02/04/2019 14:15, Jeff Kubascik wrote:

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?


The device tree support in RTEMS is quite rudimentary. However, in the 
BSP you don't need much. You just have to deal with the interrupt 
controller, the clock driver and an UART driver. Maybe also I2C and SPI, 
but these are simple things. The more complex drivers are in libbsd 
(USB, MMC/SDCard, Ethernet). Here we have the device tree support from 
FreeBSD. It is not as good as the device tree support from Linux 
especially if it comes down to pins and clocks since this is a real mess 
usually.


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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

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

Re: 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 

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

_

Re: 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 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
 
 > 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  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 
 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.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

On 4/1/2019 9:45 AM, Joel Sherrill wrote:
> On Mon, Apr 1, 2019 at 7:54 AM Jeff Kubascik  > 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
> 
> > 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  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 
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Joel Sherrill]

On Mon, Apr 1, 2019 at 7:54 AM Jeff Kubascik 
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
> > 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 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
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Jeff Kubascik]

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

-Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS on ARMv8

[Sebastian Huber]

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
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS on ARMv8

[Jeff Kubascik]

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?

Thanks!

--Jeff Kubascik
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel