[Xenomai] Xenomai ported to ARMv8 NXP QorIQ SDK?

[Xenomai] Xenomai ported to ARMv8 NXP QorIQ SDK?

[Tracy Smith]

 Has Xenomai been ported to ARMv8?  Or, in particular the NXP/Freescale
QorIQ family of products SDK 1.0 or 2.0, for example the LS1021?

We are using the LS1043 SDK 2.0, which is a new product and wanted to see
if we could download, compile, and bring-up xenomai for evaluation
alongside the 4.1.8 PREEMPT_RT kernel in the NXP SDK 2.0.   Or, will this
require porting it over?



The kernel comes from 4.1.8 stable branch in the community with AArch64 and
ARM extensions. Four core 64 bit ARMv8 Cortex-A53 1.6 GHz.  I didn’t see
any indication for this family nor the ARMv8 on the Xenomai website below.
thx, Tracy

Re: [Xenomai] Xenomai ported to ARMv8 NXP QorIQ SDK?

[Philippe Gerum]

On 07/27/2016 04:23 PM, Tracy Smith wrote:
>  Has Xenomai been ported to ARMv8?  Or, in particular the NXP/Freescale
> QorIQ family of products SDK 1.0 or 2.0, for example the LS1021?
>

It has been ported to LS1021A already (over Linux 3.14 IIRC).

> We are using the LS1043 SDK 2.0, which is a new product and wanted to see
> if we could download, compile, and bring-up xenomai for evaluation
> alongside the 4.1.8 PREEMPT_RT kernel in the NXP SDK 2.0.   Or, will this
> require porting it over?
> 

This will require backporting the interrupt pipeline patch Xenomai uses
from mainline 4.1.18 to 4.1.8+rt, which will include a few easy fixups
for merging with -rt.

-- 
Philippe.

Re: [Xenomai] Xenomai ported to ARMv8 NXP QorIQ SDK?

[Tracy Smith]

 The Xenomai 3 Mercury core does not require I-Pipe and can even run on the
kernel with no real-time support, correct?

http://xenomai.org/installing-xenomai-3-x/#Installing_the_Mercury_core

So the simplest route would be to take it and integrate Xenomai 3.0 Mercury
core into the NXP SDK and build.

I-Pipe for ARMv8 has not been released yet so backporting it from mainline
4.1.18 to 4.1.8+rt may not be so simple, do you agree?

One of our engineers had to do it to get  Xenomai 2 running on Raspberry Pi
for a custom distro and it wasn't that trivial.


On Wed, Jul 27, 2016 at 10:24 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 07/27/2016 04:23 PM, Tracy Smith wrote:
> >  Has Xenomai been ported to ARMv8?  Or, in particular the NXP/Freescale
> > QorIQ family of products SDK 1.0 or 2.0, for example the LS1021?
> >
>
> It has been ported to LS1021A already (over Linux 3.14 IIRC).
>
> > We are using the LS1043 SDK 2.0, which is a new product and wanted to see
> > if we could download, compile, and bring-up xenomai for evaluation
> > alongside the 4.1.8 PREEMPT_RT kernel in the NXP SDK 2.0.   Or, will this
> > require porting it over?
> >
>
> This will require backporting the interrupt pipeline patch Xenomai uses
> from mainline 4.1.18 to 4.1.8+rt, which will include a few easy fixups
> for merging with -rt.
>
> --
> Philippe.
>

Re: [Xenomai] Xenomai ported to ARMv8 NXP QorIQ SDK?

[Philippe Gerum]

On 07/28/2016 11:40 PM, Tracy Smith wrote:
> The Xenomai 3 Mercury core does not require I-Pipe and can even run on
> the kernel with no real-time support, correct?
> 
> http://xenomai.org/installing-xenomai-3-x/#Installing_the_Mercury_core
> 

Correct.

> 
> So the simplest route would be to take it and integrate Xenomai 3.0
> Mercury core into the NXP SDK and build.
>

Using Xenomai/mercury only makes sense if you need to run an RTOS
emulator (vxworks, psos) or the alchemy API, and can cope with higher
latencies than those obtained with a dual kernel system.

The simplest route for plain POSIX-based applications with no strict
real-time requirements is to leave Xenomai aside, unless you plan for
switching to a dual kernel system (using POSIX or whatever API) over
Xenomai/cobalt at some point.

> I-Pipe for ARMv8 has not been released yet so backporting it from
> mainline 4.1.18 to 4.1.8+rt may not be so simple, do you agree?
>

Not trivial, but manageable for people familiar with Xenomai in dual
kernel mode.

> One of our engineers had to do it to get  Xenomai 2 running on Raspberry
> Pi for a custom distro and it wasn't that trivial.
> 

I can't comment, I don't know which issues popped up, and how familiar
your engineer was with dual kernel systems and specifically with the
I-pipe when starting this task.

-- 
Philippe.