Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Don Mahurin]

On Sat, Mar 21, 2015 at 6:21 AM, Gilles Chanteperdrix
<gilles.chanteperdrix at xenomai.org
<http://www.xenomai.org/mailman/listinfo/xenomai>> wrote:
>* On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
*>>* On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
*>>* > Gilles - Thank you for sharing the link and updating us with
your schedule.
*>>* >
*>>* > I just started to port the I-pipe and Xenomai-3 code for supporting
*>>* > the ARMv8 architecture. Based on my limited understanding of Xenomai,
*>>* > it appears that the following changes are required in order to get
*>>* > Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
*>>* >
*>>* > 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
*>>* > code: arch/arm64/boot, arch/arm64/kernel, etc.
*>>* > 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
*>>* > 3). In vendor kernel tree, add I-pipe support to platform-specific
*>>* > device tree: arm(64)/boot/dts/qcom
*>>* > 4). In vendor kernel tree, add I-pipe support to SoC and platform
*>>* > dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
*>>* > drivers/clocksource(?)
*>>* > 5). In xenomai-3 tree, support arm64 in Cobalt kernel:
kernel/cobalt/arch/arm64
*>>* >
*>>* > Do you (and anyone else who's working on ARMv8) see any critical
*>>* > modules missing from my list?
*>>>>* No, but the contrary, there is no reason to touch boot, kernel, mm.
*>>* Also, I would do things step by step. First get irq interception
*>* working, then timer interception, at that point I would test with
*>* rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
*>* get SMP specific stuff working, like IPI interception working, test
*>* with rtdm tasks again, testing on the various cores. Then finally
*>* add fault/syscall interception, and test with default latency test.
*>>* I would use xenomai 3.x for testing, it will avoid quite a few
*>* complicated things (kernel-space tasks without task_struct, hybrid
*>* context switch), and we could leave it at that and decide that
*

Another basic question regarding this porting effort:

Before any arm64 specific changes or platform specific changes, would
just merging the i-pipe patch/tree (merging ipipe-3.10 into the vendor
kernel for instance) be expected to boot, with CONFIG_IPIPE not set?
Or will that lead to undefined results?

-Don Mahurin

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Thu, Mar 26, 2015 at 03:58:12PM -0700, Don Mahurin wrote:
> On Sat, Mar 21, 2015 at 6:21 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix at xenomai.org
> <http://www.xenomai.org/mailman/listinfo/xenomai>> wrote:
> >* On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
> *>>* On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
> *>>* > Gilles - Thank you for sharing the link and updating us with
> your schedule.
> *>>* >
> *>>* > I just started to port the I-pipe and Xenomai-3 code for supporting
> *>>* > the ARMv8 architecture. Based on my limited understanding of Xenomai,
> *>>* > it appears that the following changes are required in order to get
> *>>* > Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
> *>>* >
> *>>* > 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
> *>>* > code: arch/arm64/boot, arch/arm64/kernel, etc.
> *>>* > 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
> *>>* > 3). In vendor kernel tree, add I-pipe support to platform-specific
> *>>* > device tree: arm(64)/boot/dts/qcom
> *>>* > 4). In vendor kernel tree, add I-pipe support to SoC and platform
> *>>* > dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
> *>>* > drivers/clocksource(?)
> *>>* > 5). In xenomai-3 tree, support arm64 in Cobalt kernel:
> kernel/cobalt/arch/arm64
> *>>* >
> *>>* > Do you (and anyone else who's working on ARMv8) see any critical
> *>>* > modules missing from my list?
> *>>>>* No, but the contrary, there is no reason to touch boot, kernel, mm.
> *>>* Also, I would do things step by step. First get irq interception
> *>* working, then timer interception, at that point I would test with
> *>* rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
> *>* get SMP specific stuff working, like IPI interception working, test
> *>* with rtdm tasks again, testing on the various cores. Then finally
> *>* add fault/syscall interception, and test with default latency test.
> *>>* I would use xenomai 3.x for testing, it will avoid quite a few
> *>* complicated things (kernel-space tasks without task_struct, hybrid
> *>* context switch), and we could leave it at that and decide that
> *
> 
> Another basic question regarding this porting effort:
> 
> Before any arm64 specific changes or platform specific changes, would
> just merging the i-pipe patch/tree (merging ipipe-3.10 into the vendor
> kernel for instance) be expected to boot, with CONFIG_IPIPE not set?
> Or will that lead to undefined results?

The results are defined: it will not compile.

-- 
					    Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Don Mahurin]

On Thu, Mar 26, 2015 at 4:05 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Thu, Mar 26, 2015 at 03:58:12PM -0700, Don Mahurin wrote:
> > On Sat, Mar 21, 2015 at 6:21 AM, Gilles Chanteperdrix
> > <gilles.chanteperdrix at xenomai.org
> > <http://www.xenomai.org/mailman/listinfo/xenomai>> wrote:
> > >* On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
> > *>>* On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
> > *>>* > Gilles - Thank you for sharing the link and updating us with
> > your schedule.
> > *>>* >
> > *>>* > I just started to port the I-pipe and Xenomai-3 code for
> supporting
> > *>>* > the ARMv8 architecture. Based on my limited understanding of
> Xenomai,
> > *>>* > it appears that the following changes are required in order to get
> > *>>* > Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm
> msm8994):
> > *>>* >
> > *>>* > 1). In vendor kernel tree, add I-pipe support to arm64 generic
> arch
> > *>>* > code: arch/arm64/boot, arch/arm64/kernel, etc.
> > *>>* > 2). In vendor kernel tree, add I-pipe support to arm64 MMU:
> arch/arm64/mm
> > *>>* > 3). In vendor kernel tree, add I-pipe support to platform-specific
> > *>>* > device tree: arm(64)/boot/dts/qcom
> > *>>* > 4). In vendor kernel tree, add I-pipe support to SoC and platform
> > *>>* > dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
> > *>>* > drivers/clocksource(?)
> > *>>* > 5). In xenomai-3 tree, support arm64 in Cobalt kernel:
> > kernel/cobalt/arch/arm64
> > *>>* >
> > *>>* > Do you (and anyone else who's working on ARMv8) see any critical
> > *>>* > modules missing from my list?
> > *>>>>* No, but the contrary, there is no reason to touch boot, kernel,
> mm.
> > *>>* Also, I would do things step by step. First get irq interception
> > *>* working, then timer interception, at that point I would test with
> > *>* rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
> > *>* get SMP specific stuff working, like IPI interception working, test
> > *>* with rtdm tasks again, testing on the various cores. Then finally
> > *>* add fault/syscall interception, and test with default latency test.
> > *>>* I would use xenomai 3.x for testing, it will avoid quite a few
> > *>* complicated things (kernel-space tasks without task_struct, hybrid
> > *>* context switch), and we could leave it at that and decide that
> > *
> >
> > Another basic question regarding this porting effort:
> >
> > Before any arm64 specific changes or platform specific changes, would
> > just merging the i-pipe patch/tree (merging ipipe-3.10 into the vendor
> > kernel for instance) be expected to boot, with CONFIG_IPIPE not set?
> > Or will that lead to undefined results?
>
> The results are defined: it will not compile.
>

It compiles, but will not boot. Though it fails early such that there are
no kernel messages.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Lennart Sorensen]

On Thu, Mar 26, 2015 at 03:58:12PM -0700, Don Mahurin wrote:
> Another basic question regarding this porting effort:
> 
> Before any arm64 specific changes or platform specific changes, would
> just merging the i-pipe patch/tree (merging ipipe-3.10 into the vendor
> kernel for instance) be expected to boot, with CONFIG_IPIPE not set?
> Or will that lead to undefined results?

I have yet to ever have a kernel with ipipe patches applied that could
be compiled with CONFIG_IPIPE disabled.  I always have to remove the
ipipe and xenomai patches if I want to test without them.  I imagine
that for some architectures with some kernel versions it had worked,
but it seems in general it doesn't.  It just isn't a priority to test
that configuration I suspect.

-- 
Len Sorensen

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Thu, Mar 26, 2015 at 08:13:31PM -0400, Lennart Sorensen wrote:
> On Thu, Mar 26, 2015 at 03:58:12PM -0700, Don Mahurin wrote:
> > Another basic question regarding this porting effort:
> > 
> > Before any arm64 specific changes or platform specific changes, would
> > just merging the i-pipe patch/tree (merging ipipe-3.10 into the vendor
> > kernel for instance) be expected to boot, with CONFIG_IPIPE not set?
> > Or will that lead to undefined results?
> 
> I have yet to ever have a kernel with ipipe patches applied that could
> be compiled with CONFIG_IPIPE disabled.  I always have to remove the
> ipipe and xenomai patches if I want to test without them.  I imagine
> that for some architectures with some kernel versions it had worked,
> but it seems in general it doesn't.  It just isn't a priority to test
> that configuration I suspect.

Normally, this is a configuration which is supported and tested. It
may happen that a patch is released without having tested it on all
platforms I guess, so, if you find a problem with that, please send
a report. Or a patch, because such problems are usually not hard to
fix.

-- 
					    Gilles.

[Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Gilles,

Do you mind to share the maker of the ARMv8 board which you are
working on, as indicated in the posting below?

Thanks,
Hongfei

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Mon Feb 16 21:44:38 CET 2015

On Mon, Feb 16, 2015 at 12:15:41PM -0800, Gary Gitelson wrote:
> Hi,
>
>     There is an excellent guide for porting Xenomai to other ARM-based SOCs.
> But this seems to assume that they are 32-bit ARM SOCs, based on ARMv7 or
> lower.  Is there active work, or a guide or assistance, on porting to SOCs
> based on ARMv8 architectures (specifically, in my case, the Qualcomm
> MSM8994).

No, everything needs to be done for armv8.

>  I assume that almost everything in the arch/arm portion of the
> kernel would need to exist in the arch/arm64 subtree, but I am not sure
> exactly what is involved here.
>     Any assistance, or leads on existing work, would be much appreciated.

Linaro donated an ARMv8 board, I will start working on the I-pipe
port soon, but can not promise it will be finished rapidly.

-- 
   Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Fri, Mar 20, 2015 at 09:45:59AM -0700, Hongfei Cheng wrote:
> Gilles,
> 
> Do you mind to share the maker of the ARMv8 board which you are
> working on, as indicated in the posting below?

https://www.96boards.org/products/hikey/

But I have not started working on it, and will not start before a
few weeks.

-- 
					    Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Gilles - Thank you for sharing the link and updating us with your schedule.

I just started to port the I-pipe and Xenomai-3 code for supporting
the ARMv8 architecture. Based on my limited understanding of Xenomai,
it appears that the following changes are required in order to get
Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):

1). In vendor kernel tree, add I-pipe support to arm64 generic arch
code: arch/arm64/boot, arch/arm64/kernel, etc.
2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
3). In vendor kernel tree, add I-pipe support to platform-specific
device tree: arm(64)/boot/dts/qcom
4). In vendor kernel tree, add I-pipe support to SoC and platform
dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
drivers/clocksource(?)
5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64

Do you (and anyone else who's working on ARMv8) see any critical
modules missing from my list?

Thanks!
Hongfei

On Fri, Mar 20, 2015 at 11:13 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Fri, Mar 20, 2015 at 09:45:59AM -0700, Hongfei Cheng wrote:
>> Gilles,
>>
>> Do you mind to share the maker of the ARMv8 board which you are
>> working on, as indicated in the posting below?
>
> https://www.96boards.org/products/hikey/
>
> But I have not started working on it, and will not start before a
> few weeks.
>
> --
>                                             Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
> Gilles - Thank you for sharing the link and updating us with your schedule.
> 
> I just started to port the I-pipe and Xenomai-3 code for supporting
> the ARMv8 architecture. Based on my limited understanding of Xenomai,
> it appears that the following changes are required in order to get
> Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
> 
> 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
> code: arch/arm64/boot, arch/arm64/kernel, etc.
> 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
> 3). In vendor kernel tree, add I-pipe support to platform-specific
> device tree: arm(64)/boot/dts/qcom
> 4). In vendor kernel tree, add I-pipe support to SoC and platform
> dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
> drivers/clocksource(?)
> 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64
> 
> Do you (and anyone else who's working on ARMv8) see any critical
> modules missing from my list?

No, but the contrary, there is no reason to touch boot, kernel, mm.

-- 
					    Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
> On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
> > Gilles - Thank you for sharing the link and updating us with your schedule.
> > 
> > I just started to port the I-pipe and Xenomai-3 code for supporting
> > the ARMv8 architecture. Based on my limited understanding of Xenomai,
> > it appears that the following changes are required in order to get
> > Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
> > 
> > 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
> > code: arch/arm64/boot, arch/arm64/kernel, etc.
> > 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
> > 3). In vendor kernel tree, add I-pipe support to platform-specific
> > device tree: arm(64)/boot/dts/qcom
> > 4). In vendor kernel tree, add I-pipe support to SoC and platform
> > dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
> > drivers/clocksource(?)
> > 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64
> > 
> > Do you (and anyone else who's working on ARMv8) see any critical
> > modules missing from my list?
> 
> No, but the contrary, there is no reason to touch boot, kernel, mm.

Also, I would do things step by step. First get irq interception
working, then timer interception, at that point I would test with
rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
get SMP specific stuff working, like IPI interception working, test
with rtdm tasks again, testing on the various cores. Then finally
add fault/syscall interception, and test with default latency test.

I would use xenomai 3.x for testing, it will avoid quite a few
complicated things (kernel-space tasks without task_struct, hybrid
context switch), and we could leave it at that and decide that
xenomai 2.6 will never support armv8.

-- 
					    Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Thank you for the terrific info and timely advice. I'll proceed as you
suggested and report back progress regularly.

Hongfei

On Sat, Mar 21, 2015 at 6:21 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
>> On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
>> > Gilles - Thank you for sharing the link and updating us with your schedule.
>> >
>> > I just started to port the I-pipe and Xenomai-3 code for supporting
>> > the ARMv8 architecture. Based on my limited understanding of Xenomai,
>> > it appears that the following changes are required in order to get
>> > Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
>> >
>> > 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
>> > code: arch/arm64/boot, arch/arm64/kernel, etc.
>> > 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
>> > 3). In vendor kernel tree, add I-pipe support to platform-specific
>> > device tree: arm(64)/boot/dts/qcom
>> > 4). In vendor kernel tree, add I-pipe support to SoC and platform
>> > dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
>> > drivers/clocksource(?)
>> > 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64
>> >
>> > Do you (and anyone else who's working on ARMv8) see any critical
>> > modules missing from my list?
>>
>> No, but the contrary, there is no reason to touch boot, kernel, mm.
>
> Also, I would do things step by step. First get irq interception
> working, then timer interception, at that point I would test with
> rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
> get SMP specific stuff working, like IPI interception working, test
> with rtdm tasks again, testing on the various cores. Then finally
> add fault/syscall interception, and test with default latency test.
>
> I would use xenomai 3.x for testing, it will avoid quite a few
> complicated things (kernel-space tasks without task_struct, hybrid
> context switch), and we could leave it at that and decide that
> xenomai 2.6 will never support armv8.
>
> --
>                                             Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Jan Kiszka]

On 2015-03-23 07:01, Hongfei Cheng wrote:
> Thank you for the terrific info and timely advice. I'll proceed as you
> suggested and report back progress regularly.

Another tip: it can we useful to do early bring-up on QEMU basis. It is
already in a pretty decent state regarding aarch64, Linaro is hacking on
it, and vendors like Xilinx do their virtual prototyping on that basis
as well (in the latter case for the upcoming MPSoC). Probably - I didn't
try it out myself yet, only planning to do these days - the gdb
interface also works fine, thus will give you source level debugging.

Jan

> 
> Hongfei
> 
> On Sat, Mar 21, 2015 at 6:21 AM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
>>> On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
>>>> Gilles - Thank you for sharing the link and updating us with your schedule.
>>>>
>>>> I just started to port the I-pipe and Xenomai-3 code for supporting
>>>> the ARMv8 architecture. Based on my limited understanding of Xenomai,
>>>> it appears that the following changes are required in order to get
>>>> Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
>>>>
>>>> 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
>>>> code: arch/arm64/boot, arch/arm64/kernel, etc.
>>>> 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
>>>> 3). In vendor kernel tree, add I-pipe support to platform-specific
>>>> device tree: arm(64)/boot/dts/qcom
>>>> 4). In vendor kernel tree, add I-pipe support to SoC and platform
>>>> dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
>>>> drivers/clocksource(?)
>>>> 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64
>>>>
>>>> Do you (and anyone else who's working on ARMv8) see any critical
>>>> modules missing from my list?
>>>
>>> No, but the contrary, there is no reason to touch boot, kernel, mm.
>>
>> Also, I would do things step by step. First get irq interception
>> working, then timer interception, at that point I would test with
>> rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
>> get SMP specific stuff working, like IPI interception working, test
>> with rtdm tasks again, testing on the various cores. Then finally
>> add fault/syscall interception, and test with default latency test.
>>
>> I would use xenomai 3.x for testing, it will avoid quite a few
>> complicated things (kernel-space tasks without task_struct, hybrid
>> context switch), and we could leave it at that and decide that
>> xenomai 2.6 will never support armv8.
>>
>> --
>>                                             Gilles.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150323/48c7ea9c/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Mon, Mar 23, 2015 at 10:03:06AM +0100, Jan Kiszka wrote:
> On 2015-03-23 07:01, Hongfei Cheng wrote:
> > Thank you for the terrific info and timely advice. I'll proceed as you
> > suggested and report back progress regularly.
> 
> Another tip: it can we useful to do early bring-up on QEMU basis. It is
> already in a pretty decent state regarding aarch64, Linaro is hacking on
> it, and vendors like Xilinx do their virtual prototyping on that basis
> as well (in the latter case for the upcoming MPSoC). Probably - I didn't
> try it out myself yet, only planning to do these days - the gdb
> interface also works fine, thus will give you source level debugging.

I would not recommend that, as it adds the debug tools and emulator
bugs, and removes some real silicon bugs, as well as adding the
temptation to rely too much on the debug tools and not see the
forest for the tree. If you really really want to use gdb, I would
rather recommend JTAG (but it still has some of the issues of QEMU).

Besides, developing on real hardware is much less painful on embedded
hardware than on x86 hardware because: 

- embedded hardware usually has a serial console, which makes things
real easy (when everything fails, you can output characters to the
serial console in a brute force polling manner) 

- embedded hardware usually does not take forever to initialize its
firmware (no BIOS with stupid timeouts waiting for not unplugged
peripherals). Typically, u-boot is slower to execute in qemu than on
real hardware (if you want to execute u-boot in qemu).

So, your mileage may vary.

Something I also forgot to mention is the FPU support: keep that for
the end but you will need it to run the latency test. So, I would
recommend compiling an integer-only simplified latency test to
validate the fault/syscall interception. Then add FPU support.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150323/818dd0a5/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Jan Kiszka]

On 2015-03-23 10:53, Gilles Chanteperdrix wrote:
> On Mon, Mar 23, 2015 at 10:03:06AM +0100, Jan Kiszka wrote:
>> On 2015-03-23 07:01, Hongfei Cheng wrote:
>>> Thank you for the terrific info and timely advice. I'll proceed as you
>>> suggested and report back progress regularly.
>>
>> Another tip: it can we useful to do early bring-up on QEMU basis. It is
>> already in a pretty decent state regarding aarch64, Linaro is hacking on
>> it, and vendors like Xilinx do their virtual prototyping on that basis
>> as well (in the latter case for the upcoming MPSoC). Probably - I didn't
>> try it out myself yet, only planning to do these days - the gdb
>> interface also works fine, thus will give you source level debugging.
> 
> I would not recommend that, as it adds the debug tools and emulator
> bugs, and removes some real silicon bugs, as well as adding the
> temptation to rely too much on the debug tools and not see the
> forest for the tree. If you really really want to use gdb, I would
> rather recommend JTAG (but it still has some of the issues of QEMU).

Sure, there are always specific aspects that require real hw - e.g. when
in doubt about an emulated behavior or when you need to validate
timings. But for an initial architecture port, specifically to a pretty
much unified one like AARCH64, emulation remains handier.

> 
> Besides, developing on real hardware is much less painful on embedded
> hardware than on x86 hardware because: 
> 
> - embedded hardware usually has a serial console, which makes things
> real easy (when everything fails, you can output characters to the
> serial console in a brute force polling manner) 

So do all my PC targets. But already the output of a physical console
slows things down so much that an emulated UART (without speed
limitation) pays off.

> 
> - embedded hardware usually does not take forever to initialize its
> firmware (no BIOS with stupid timeouts waiting for not unplugged
> peripherals). Typically, u-boot is slower to execute in qemu than on
> real hardware (if you want to execute u-boot in qemu).

There is generally no need for a boot loader (unless that is your
development target), you just boot the kernel directly.

There is a trend in industry towards virtual targets. That's because you
can do much more (and much earlier) with emulation than with real hw,
and handling is much easier (no wiring, no physical reset, free
replication of setups etc.).

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150323/8742ff3f/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Mon, Mar 23, 2015 at 03:00:15PM +0100, Jan Kiszka wrote:
> On 2015-03-23 10:53, Gilles Chanteperdrix wrote:
> > On Mon, Mar 23, 2015 at 10:03:06AM +0100, Jan Kiszka wrote:
> >> On 2015-03-23 07:01, Hongfei Cheng wrote:
> >>> Thank you for the terrific info and timely advice. I'll proceed as you
> >>> suggested and report back progress regularly.
> >>
> >> Another tip: it can we useful to do early bring-up on QEMU basis. It is
> >> already in a pretty decent state regarding aarch64, Linaro is hacking on
> >> it, and vendors like Xilinx do their virtual prototyping on that basis
> >> as well (in the latter case for the upcoming MPSoC). Probably - I didn't
> >> try it out myself yet, only planning to do these days - the gdb
> >> interface also works fine, thus will give you source level debugging.
> > 
> > I would not recommend that, as it adds the debug tools and emulator
> > bugs, and removes some real silicon bugs, as well as adding the
> > temptation to rely too much on the debug tools and not see the
> > forest for the tree. If you really really want to use gdb, I would
> > rather recommend JTAG (but it still has some of the issues of QEMU).
> 
> Sure, there are always specific aspects that require real hw - e.g. when
> in doubt about an emulated behavior or when you need to validate
> timings.

Or when you want to use a register that is not implemented in the
emulator.

> But for an initial architecture port, specifically to a pretty
> much unified one like AARCH64, emulation remains handier.
> 
> > 
> > Besides, developing on real hardware is much less painful on embedded
> > hardware than on x86 hardware because: 
> > 
> > - embedded hardware usually has a serial console, which makes things
> > real easy (when everything fails, you can output characters to the
> > serial console in a brute force polling manner) 
> 
> So do all my PC targets. But already the output of a physical console
> slows things down so much that an emulated UART (without speed
> limitation) pays off.

Recent embedded hardware use DMA for serial output, so the serial
output has little to no impact on the code execution unless you have
as much output as the UART bit rate. Unless of course you are using
the brute force polling, but this is something you usually do when
the system is in so bad a shape that the speed does not matter.

> 
> > 
> > - embedded hardware usually does not take forever to initialize its
> > firmware (no BIOS with stupid timeoeuts waiting for not unplugged
> > peripherals). Typically, u-boot is slower to execute in qemu than on
> > real hardware (if you want to execute u-boot in qemu).
> 
> There is generally no need for a boot loader (unless that is your
> development target), you just boot the kernel directly.

Then you are relying on yet another code which is different from
what will run on real hardware. Even more risks of bugs, even more
differences between real environment and emulated environment,
etc...

> 
> There is a trend in industry towards virtual targets. That's because you
> can do much more (and much earlier) with emulation than with real hw,
> and handling is much easier (no wiring, no physical reset, free
> replication of setups etc.).

Being a trend does not mean this is a good idea. I still believe a
lot of people using JTAG or gdb tend to see symptoms rather than
real issue and misinterpret them.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150323/9e85b4f1/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Jan Kiszka]

On 2015-03-23 16:25, Gilles Chanteperdrix wrote:
> On Mon, Mar 23, 2015 at 03:00:15PM +0100, Jan Kiszka wrote:
>> There is a trend in industry towards virtual targets. That's because you
>> can do much more (and much earlier) with emulation than with real hw,
>> and handling is much easier (no wiring, no physical reset, free
>> replication of setups etc.).
> 
> Being a trend does not mean this is a good idea. I still believe a
> lot of people using JTAG or gdb tend to see symptoms rather than
> real issue and misinterpret them.

Yeah, real developers don't use debuggers or similar tools. Linus made a
similar statement some decade ago. He was wrong with this generalization
as well - one reason why we have kgdb upstream now. Debugging done right
is interactive code reading and model checking.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150324/c0fb5812/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Tue, Mar 24, 2015 at 03:40:07PM +0100, Jan Kiszka wrote:
> On 2015-03-23 16:25, Gilles Chanteperdrix wrote:
> > On Mon, Mar 23, 2015 at 03:00:15PM +0100, Jan Kiszka wrote:
> >> There is a trend in industry towards virtual targets. That's because you
> >> can do much more (and much earlier) with emulation than with real hw,
> >> and handling is much easier (no wiring, no physical reset, free
> >> replication of setups etc.).
> > 
> > Being a trend does not mean this is a good idea. I still believe a
> > lot of people using JTAG or gdb tend to see symptoms rather than
> > real issue and misinterpret them.
> 
> Yeah, real developers don't use debuggers or similar tools. Linus made a
> similar statement some decade ago. He was wrong

That is your opinion. Maybe he simply got fed up with that stupid
debate and simply gave up knowing that he would never use such
tools. Who knows ?

> with this generalization
> as well - one reason why we have kgdb upstream now. Debugging done right
> is interactive code reading and model checking.

Except that real world tool are always buggy, so when you see
something, you waste time wondering if it is a tool bug or artefact
or a real bug. And I am not only talking about free software, I have
used expensive symbolic debug tools connected to JTAG, it was as
buggy as the rest.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150324/5ad62f7b/attachment.sig>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Thank you all again for the clear and prompt responses, along with
the informative discussions.

A follow-up question to the kernel module(s) requiring changes for
supporting I-pipe for Aarch64/arm64: After enabling I-pipe (but with
xenomai-3 disabled) in the kernel with the ipipe-core patch for
Aarch32/arm, building the Aarch64 kernel image shows clear dependency on
I-pipe specific code in arch/arm64/kernel. This observation appears
to deviate from Gilles' earlier advice -- "there is no reason to touch
boot, kernel, mm".

Since the Aarch64 code in arch/arm64/kernel differs quite a bit from the
Aarch32 code in arch/arm/kernel, porting the ipipe-core code from
arch/arm/kernel to arch/arm64/kernel will require significant amount of
work. I'd appreciate if anyone can affirm or refute the need to touch
arch/arm64/kernel for Aarch64/arm64, before I go too far and veer off the
road.

Thanks!
Hongfei


On Tue, Mar 24, 2015 at 8:27 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Tue, Mar 24, 2015 at 03:40:07PM +0100, Jan Kiszka wrote:
> > On 2015-03-23 16:25, Gilles Chanteperdrix wrote:
> > > On Mon, Mar 23, 2015 at 03:00:15PM +0100, Jan Kiszka wrote:
> > >> There is a trend in industry towards virtual targets. That's because
> you
> > >> can do much more (and much earlier) with emulation than with real hw,
> > >> and handling is much easier (no wiring, no physical reset, free
> > >> replication of setups etc.).
> > >
> > > Being a trend does not mean this is a good idea. I still believe a
> > > lot of people using JTAG or gdb tend to see symptoms rather than
> > > real issue and misinterpret them.
> >
> > Yeah, real developers don't use debuggers or similar tools. Linus made a
> > similar statement some decade ago. He was wrong
>
> That is your opinion. Maybe he simply got fed up with that stupid
> debate and simply gave up knowing that he would never use such
> tools. Who knows ?
>
> > with this generalization
> > as well - one reason why we have kgdb upstream now. Debugging done right
> > is interactive code reading and model checking.
>
> Except that real world tool are always buggy, so when you see
> something, you waste time wondering if it is a tool bug or artefact
> or a real bug. And I am not only talking about free software, I have
> used expensive symbolic debug tools connected to JTAG, it was as
> buggy as the rest.
>
> --
>                                             Gilles.
>

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Thu, Apr 02, 2015 at 01:12:11AM -0700, Hongfei Cheng wrote:
> Thank you all again for the clear and prompt responses, along with
> the informative discussions.
> 
> A follow-up question to the kernel module(s) requiring changes for
> supporting I-pipe for Aarch64/arm64: After enabling I-pipe (but with
> xenomai-3 disabled) in the kernel with the ipipe-core patch for
> Aarch32/arm, building the Aarch64 kernel image shows clear dependency on
> I-pipe specific code in arch/arm64/kernel. This observation appears
> to deviate from Gilles' earlier advice -- "there is no reason to touch
> boot, kernel, mm".
> 
> Since the Aarch64 code in arch/arm64/kernel differs quite a bit from the
> Aarch32 code in arch/arm/kernel, porting the ipipe-core code from
> arch/arm/kernel to arch/arm64/kernel will require significant amount of
> work. I'd appreciate if anyone can affirm or refute the need to touch
> arch/arm64/kernel for Aarch64/arm64, before I go too far and veer off the
> road.

Speaking in directory/files is meaningless, what matters is what you
change. I think I have given you a list of what to change already.
If some files to change are in the kernel directory, then OK, I was
wrong.

-- 
					    Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Thank you, Gilles, for the clarification.

Our immediate goal is to enable/port the minimum ipipe-core code for
Aarch64 so we can successfully build an image with ipipe enabled. We
can then start to work on irq interception, timer interception, etc.
By then we should be able to ask I-pipe specific questions for the
arm64 port.

Thanks again,
Hongfei

On Thu, Apr 2, 2015 at 2:04 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Thu, Apr 02, 2015 at 01:12:11AM -0700, Hongfei Cheng wrote:
>> Thank you all again for the clear and prompt responses, along with
>> the informative discussions.
>>
>> A follow-up question to the kernel module(s) requiring changes for
>> supporting I-pipe for Aarch64/arm64: After enabling I-pipe (but with
>> xenomai-3 disabled) in the kernel with the ipipe-core patch for
>> Aarch32/arm, building the Aarch64 kernel image shows clear dependency on
>> I-pipe specific code in arch/arm64/kernel. This observation appears
>> to deviate from Gilles' earlier advice -- "there is no reason to touch
>> boot, kernel, mm".
>>
>> Since the Aarch64 code in arch/arm64/kernel differs quite a bit from the
>> Aarch32 code in arch/arm/kernel, porting the ipipe-core code from
>> arch/arm/kernel to arch/arm64/kernel will require significant amount of
>> work. I'd appreciate if anyone can affirm or refute the need to touch
>> arch/arm64/kernel for Aarch64/arm64, before I go too far and veer off the
>> road.
>
> Speaking in directory/files is meaningless, what matters is what you
> change. I think I have given you a list of what to change already.
> If some files to change are in the kernel directory, then OK, I was
> wrong.
>
> --
>                                             Gilles.

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Jorge Ramirez Ortiz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/21/2015 09:21 AM, Gilles Chanteperdrix wrote:
> On Sat, Mar 21, 2015 at 02:11:11PM +0100, Gilles Chanteperdrix wrote:
>> On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
>>> Gilles - Thank you for sharing the link and updating us with your schedule.
>>>
>>> I just started to port the I-pipe and Xenomai-3 code for supporting
>>> the ARMv8 architecture. Based on my limited understanding of Xenomai,
>>> it appears that the following changes are required in order to get
>>> Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
>>>
>>> 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
>>> code: arch/arm64/boot, arch/arm64/kernel, etc.
>>> 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
>>> 3). In vendor kernel tree, add I-pipe support to platform-specific
>>> device tree: arm(64)/boot/dts/qcom
>>> 4). In vendor kernel tree, add I-pipe support to SoC and platform
>>> dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
>>> drivers/clocksource(?)
>>> 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/ar
m64
>>>
>>> Do you (and anyone else who's working on ARMv8) see any critical
>>> modules missing from my list?
>>
>> No, but the contrary, there is no reason to touch boot, kernel, mm.
> 
> Also, I would do things step by step. First get irq interception
> working, then timer interception, at that point I would test with
> rtdm kernel tasks only (without CONFIG_SMP). Then add CONFIG_SMP and
> get SMP specific stuff working, like IPI interception working, test
> with rtdm tasks again, testing on the various cores. Then finally
> add fault/syscall interception, and test with default latency test.
> 
> I would use xenomai 3.x for testing, it will avoid quite a few
> complicated things (kernel-space tasks without task_struct, hybrid
> context switch), and we could leave it at that and decide that
> xenomai 2.6 will never support armv8.


the vendor tree for the 96Board platforms is hosted in github
https://github.com/96boards/linux

hikey and hikey-{feature} branches run 3.18 kernels.
hikey-mainline-rebase tracks mainline.

At the moment we mainly support HiKey but more boards will be coming rapidly
(one from Qualcomm before the summer)
HiKey runs Debian and Android - UEFI support is on going.

I will gladly create a Xenomai integration branch on the Hikey repo if it helps
the development.





> 

- -- 
jro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVD/4XAAoJECDcy2IJkagRk0QH/3fId1BWLIr0ZSR8TB3OTF/L
+hz/JyI/48rKdPbOVn6Cxyi+oizbhOIjzZPGgufO/wpbia99UvOFHmWUkURiC2+6
B8uB3aAlgS/I6VUhV3miMYuZBbEUAc+m4+W3Ob5Nq+5YJWha5bSNNbMBfnwvB3Of
0EjkK/sLKa+lVtDRokmqA5bAejfLlYaWL87OcQU1s8sr326lsPn3ohDw5X7GwTsJ
VD2EiVFg5HnjX7dnt2YRzhsguopPsz40wO/WmHTkr4xrjR1+hgTQd+9VybUWn94K
QqLqbDGauCXQqgmZZf4Z/AI+REnW3hiooiPj9DxCU30XYR3K3rm1NHlCjnNenJQ=
=U2Tu
-----END PGP SIGNATURE-----

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Hongfei Cheng]

Yes, I'll cross out /arch/arm64/boot and arch/mm from my todo list.

Do you mean the existing I-pipe code changes made to linux kernel
module arch/arm/kernel do not apply to arch/arm64/kernel (for arm64)?
I saw some I-pipe code in arch/arm/kernel dealing with interrupt,
which made me wonder if similar code might have been needed in
arch/arm64/kernel. I'll be glad to cross this one out too.

Thanks!
Hongfei

On Sat, Mar 21, 2015 at 6:11 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Fri, Mar 20, 2015 at 05:06:36PM -0700, Hongfei Cheng wrote:
>> Gilles - Thank you for sharing the link and updating us with your schedule.
>>
>> I just started to port the I-pipe and Xenomai-3 code for supporting
>> the ARMv8 architecture. Based on my limited understanding of Xenomai,
>> it appears that the following changes are required in order to get
>> Xenomai-3 running on the ARMv8 SoC we plan to use (Qualcomm msm8994):
>>
>> 1). In vendor kernel tree, add I-pipe support to arm64 generic arch
>> code: arch/arm64/boot, arch/arm64/kernel, etc.
>> 2). In vendor kernel tree, add I-pipe support to arm64 MMU: arch/arm64/mm
>> 3). In vendor kernel tree, add I-pipe support to platform-specific
>> device tree: arm(64)/boot/dts/qcom
>> 4). In vendor kernel tree, add I-pipe support to SoC and platform
>> dependent drivers for arm64: drivers/gpio, drivers/irqchip(?),
>> drivers/clocksource(?)
>> 5). In xenomai-3 tree, support arm64 in Cobalt kernel: kernel/cobalt/arch/arm64
>>
>> Do you (and anyone else who's working on ARMv8) see any critical
>> modules missing from my list?
>
> No, but the contrary, there is no reason to touch boot, kernel, mm.
>
> --
>                                             Gilles.

[Xenomai] ARMv8 (ARM64) port of Xenomai

[Gary Gitelson]

Hi,

     There is an excellent guide for porting Xenomai to other ARM-based 
SOCs.  But this seems to assume that they are 32-bit ARM SOCs, based on 
ARMv7 or lower.  Is there active work, or a guide or assistance, on 
porting to SOCs based on ARMv8 architectures (specifically, in my case, 
the Qualcomm MSM8994).  I assume that almost everything in the arch/arm 
portion of the kernel would need to exist in the arch/arm64 subtree, but 
I am not sure exactly what is involved here.
     Any assistance, or leads on existing work, would be much appreciated.

Thanks,
Gary

Re: [Xenomai] ARMv8 (ARM64) port of Xenomai

[Gilles Chanteperdrix]

On Mon, Feb 16, 2015 at 12:15:41PM -0800, Gary Gitelson wrote:
> Hi,
> 
>     There is an excellent guide for porting Xenomai to other ARM-based SOCs.
> But this seems to assume that they are 32-bit ARM SOCs, based on ARMv7 or
> lower.  Is there active work, or a guide or assistance, on porting to SOCs
> based on ARMv8 architectures (specifically, in my case, the Qualcomm
> MSM8994).

No, everything needs to be done for armv8.

>  I assume that almost everything in the arch/arm portion of the
> kernel would need to exist in the arch/arm64 subtree, but I am not sure
> exactly what is involved here.
>     Any assistance, or leads on existing work, would be much appreciated.

Linaro donated an ARMv8 board, I will start working on the I-pipe
port soon, but can not promise it will be finished rapidly.

-- 
					    Gilles.