[Xenomai] init failed code -19 on Cyclone V SoC

[Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

Hello,

I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and the 
corresponding ipipe patch to work on an ARM SoC.
The device in question is a MitySoM module which is based on the Cyclone V
from Altera and contains a dual core ARM Cortex A9.

I have followed the "Porting Xenomai dual kernel to a new ARM SoC" 
guide. Even though Linux boots without any  problems, Xenomai is not 
working.

The output of dmesg | grep -E 'Xenomai|I-pipe' is the following:

[    0.000000] I-pipe, 200.000 MHz timer
[    0.123073] I-pipe, 200.000 MHz timer
[    0.249682] [Xenomai] scheduling class idle registered.
[    0.249689] [Xenomai] scheduling class rt registered.
[    0.249758] I-pipe: high-resolution clock not working
[    0.249789] [Xenomai] init failed, code -19

Which seems to indicate a problem with the timer.

On my device tree (which is already upstream) the smp_twd timer seems to 
be properly registered (socfpga.dtsi):

timer@fffec600 {
	compatible = "arm,cortex-a9-twd-timer";
	reg = <0xfffec600 0x100>;
	interrupts = <1 13 0xf04>;
	clocks = <&mpu_periph_clk>;
};

I have also disabled CONFIG_CPU_FREQ, CONFIG_CPU_IDLE, 
CONFIG_CC_STACKPROTECTOR, CONFIG_KGDB as well as hibernation
and sleep support and I have enabled CONFIG_IPIPE_ARM_KUSER_TSC
(it doesn't compile without it, anyway, so I am sure the symbol is
selected).
I have as well enabled the "High Resolution Timer Support" on the Kernel.

As I am rather new to Xenomai, I am clueless of where the problem lies.
I had no problems setting it up on x86 systems, but on SoCs this seems
to be a totally different business...

If anybody has some idea of how I can solve this, I would be greatly 
appreciated.

Thanks,

Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lopes, Alexandre wrote:
> Hello,
>
> I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and the
> corresponding ipipe patch to work on an ARM SoC.
> The device in question is a MitySoM module which is based on the Cyclone V
> from Altera and contains a dual core ARM Cortex A9.
>
> I have followed the "Porting Xenomai dual kernel to a new ARM SoC"
> guide. Even though Linux boots without any  problems, Xenomai is not
> working.
>
> The output of dmesg | grep -E 'Xenomai|I-pipe' is the following:
>
> [    0.000000] I-pipe, 200.000 MHz timer
> [    0.123073] I-pipe, 200.000 MHz timer
> [    0.249682] [Xenomai] scheduling class idle registered.
> [    0.249689] [Xenomai] scheduling class rt registered.
> [    0.249758] I-pipe: high-resolution clock not working
> [    0.249789] [Xenomai] init failed, code -19
>
> Which seems to indicate a problem with the timer.

Nope. clock != timer.

On Cortex A9, the hardware timer used as clock is the "global timer"
normally. So, with recent kernels, you need the proper data in the device
tree, and to enable the device in the kernel configuration. Look at what
the I-pipe patch does for OMAP4 and IMX-6.

Alternatively, if the SOC you use proposes another hardware timer that can
be used as clocksource, you can use that as clock for Xenomai too.

In the porting guide, the clock is called a "high-resolution counter",
simply follow the instructions for the "not cortex A9" case, if you do
not want to use the I-pipe cortex A9 default clocksource.

-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lowell Gilbert]

"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> writes:

> Lopes, Alexandre wrote:
>> Hello,
>>
>> I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and the
>> corresponding ipipe patch to work on an ARM SoC.
>> The device in question is a MitySoM module which is based on the Cyclone V
>> from Altera and contains a dual core ARM Cortex A9.
>>
>> I have followed the "Porting Xenomai dual kernel to a new ARM SoC"
>> guide. Even though Linux boots without any  problems, Xenomai is not
>> working.
>>
>> The output of dmesg | grep -E 'Xenomai|I-pipe' is the following:
>>
>> [    0.000000] I-pipe, 200.000 MHz timer
>> [    0.123073] I-pipe, 200.000 MHz timer
>> [    0.249682] [Xenomai] scheduling class idle registered.
>> [    0.249689] [Xenomai] scheduling class rt registered.
>> [    0.249758] I-pipe: high-resolution clock not working
>> [    0.249789] [Xenomai] init failed, code -19
>>
>> Which seems to indicate a problem with the timer.
>
> Nope. clock != timer.
>
> On Cortex A9, the hardware timer used as clock is the "global timer"
> normally. So, with recent kernels, you need the proper data in the device
> tree, and to enable the device in the kernel configuration. Look at what
> the I-pipe patch does for OMAP4 and IMX-6.

>> timer@fffec600 {
>> 	compatible = "arm,cortex-a9-twd-timer";
>> 	reg = <0xfffec600 0x100>;
>> 	interrupts = <1 13 0xf04>;
>> 	clocks = <&mpu_periph_clk>;
>> };

I believe that this *is* the global clock, and the settings are correct
(although I wonder about it not having an interrupt-parent, which I get
from Altera's hardware tools).

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lowell Gilbert wrote:
> "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> writes:
>
>> Lopes, Alexandre wrote:
>>> Hello,
>>>
>>> I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and
>>> the
>>> corresponding ipipe patch to work on an ARM SoC.
>>> The device in question is a MitySoM module which is based on the
>>> Cyclone V
>>> from Altera and contains a dual core ARM Cortex A9.
>>>
>>> I have followed the "Porting Xenomai dual kernel to a new ARM SoC"
>>> guide. Even though Linux boots without any  problems, Xenomai is not
>>> working.
>>>
>>> The output of dmesg | grep -E 'Xenomai|I-pipe' is the following:
>>>
>>> [    0.000000] I-pipe, 200.000 MHz timer
>>> [    0.123073] I-pipe, 200.000 MHz timer
>>> [    0.249682] [Xenomai] scheduling class idle registered.
>>> [    0.249689] [Xenomai] scheduling class rt registered.
>>> [    0.249758] I-pipe: high-resolution clock not working
>>> [    0.249789] [Xenomai] init failed, code -19
>>>
>>> Which seems to indicate a problem with the timer.
>>
>> Nope. clock != timer.
>>
>> On Cortex A9, the hardware timer used as clock is the "global timer"
>> normally. So, with recent kernels, you need the proper data in the
>> device
>> tree, and to enable the device in the kernel configuration. Look at what
>> the I-pipe patch does for OMAP4 and IMX-6.
>
>>> timer@fffec600 {
>>> 	compatible = "arm,cortex-a9-twd-timer";
>>> 	reg = <0xfffec600 0x100>;
>>> 	interrupts = <1 13 0xf04>;
>>> 	clocks = <&mpu_periph_clk>;
>>> };
>
> I believe that this *is* the global clock, and the settings are correct
> (although I wonder about it not having an interrupt-parent, which I get
> from Altera's hardware tools).
>

No. twd is the "timer watchdog", i.e. the cpu local timers.

The "global timer" by contrast is global to all cores.

The global timer register address is the address of the twd timer plus or
minus 0x400, I never remember.

The <mpu_periph_clk> is a clock, in the hardware sense, which indeed gets
the twds and global timer ticking (at cpufreq / 2). But this has nothing
to do with what the software calls a "clock". What the software calls a
clock is what Linux calls a clocksource, a counter that gives the current
time (usually since the boot-up).

-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lowell Gilbert wrote:
> "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> writes:
>
>> Lopes, Alexandre wrote:
>>> Hello,
>>>
>>> I am trying to get Xenomai 3.0 rc4 with the 3.18.12 Linux Kernel and
>>> the
>>> corresponding ipipe patch to work on an ARM SoC.
>>> The device in question is a MitySoM module which is based on the
>>> Cyclone V
>>> from Altera and contains a dual core ARM Cortex A9.
>>>
>>> I have followed the "Porting Xenomai dual kernel to a new ARM SoC"
>>> guide. Even though Linux boots without any  problems, Xenomai is not
>>> working.
>>>
>>> The output of dmesg | grep -E 'Xenomai|I-pipe' is the following:
>>>
>>> [    0.000000] I-pipe, 200.000 MHz timer
>>> [    0.123073] I-pipe, 200.000 MHz timer
>>> [    0.249682] [Xenomai] scheduling class idle registered.
>>> [    0.249689] [Xenomai] scheduling class rt registered.
>>> [    0.249758] I-pipe: high-resolution clock not working
>>> [    0.249789] [Xenomai] init failed, code -19
>>>
>>> Which seems to indicate a problem with the timer.
>>
>> Nope. clock != timer.
>>
>> On Cortex A9, the hardware timer used as clock is the "global timer"
>> normally. So, with recent kernels, you need the proper data in the
>> device
>> tree, and to enable the device in the kernel configuration. Look at what
>> the I-pipe patch does for OMAP4 and IMX-6.
>
>>> timer@fffec600 {
>>> 	compatible = "arm,cortex-a9-twd-timer";
>>> 	reg = <0xfffec600 0x100>;
>>> 	interrupts = <1 13 0xf04>;
>>> 	clocks = <&mpu_periph_clk>;
>>> };
>
> I believe that this *is* the global clock, and the settings are correct
> (although I wonder about it not having an interrupt-parent, which I get
> from Altera's hardware tools).
>

Note that the mail you are replying to is talking about "global timer",
not "global clock".

-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

>>
>> Nope. clock != timer.
>>
>> On Cortex A9, the hardware timer used as clock is the "global timer"
>> normally. So, with recent kernels, you need the proper data in the 
>> device tree, and to enable the device in the kernel configuration. 
>> Look at what the I-pipe patch does for OMAP4 and IMX-6.
>
>>> timer@fffec600 {
>>> 	compatible = "arm,cortex-a9-twd-timer";
>>> 	reg = <0xfffec600 0x100>;
>>> 	interrupts = <1 13 0xf04>;
>>> 	clocks = <&mpu_periph_clk>;
>>> };
>
> I believe that this *is* the global clock, and the settings are 
> correct (although I wonder about it not having an interrupt-parent, 
> which I get from Altera's hardware tools).
>

> Note that the mail you are replying to is talking about "global timer", not "global clock".
>
> -- 
>                     Gilles.

Hi Gilles,

I just want to thank you for pointing me in the right direction.
The problem was indeed the due to the global timer not being registered.
After registering it with
timer@fffec200 {
	compatible = "arm,cortex-a9-global-timer";
	reg = <0xfffec200 0x20>;
	interrupts = <1 11 0xf04>;
	clocks = <&mpu_periph_clk>;
};

and making sure that ARM_GLOBAL_TIMER symbol was defined (which already was),
Xenomai seems to boot correctly:

[    0.000000] I-pipe, 200.000 MHz timer
[    0.000021] I-pipe, 200.000 MHz clocksource, wrap in 21474 ms
[    0.123218] I-pipe, 200.000 MHz timer
[    0.249832] [Xenomai] scheduling class idle registered.
[    0.249838] [Xenomai] scheduling class rt registered.
[    0.249968] I-pipe: head domain Xenomai registered.
[    0.251282] [Xenomai] Cobalt v3.0-rc4 (Exact Zero)

Thanks!


@Lowell: Like Gilles mentioned, there are several timers in the 
Cortex A9. At address PERIPH_BASE_ADDR + 0x200 you have the global timer 
registers and at PERIPH_BASE_ADDR + 0x600 you have the private timer and 
watchdog timer registers (on a per core basis). On the Altera socfpga systems
the base address is, in this case, 0xfffec000. Unfortunately Altera didn’t
register the global timer, at least not on the upstream Kernels.

Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lowell Gilbert]

>> Note that the mail you are replying to is talking about "global timer", not "global clock".
>>
>> -- 
>>                     Gilles.

Oops. Sorry; and thanks.

"Lopes, Alexandre" <alexandre.lopes.ext@zeiss.com> writes:

> @Lowell: Like Gilles mentioned, there are several timers in the 
> Cortex A9. At address PERIPH_BASE_ADDR + 0x200 you have the global timer 
> registers and at PERIPH_BASE_ADDR + 0x600 you have the private timer and 
> watchdog timer registers (on a per core basis). On the Altera socfpga systems
> the base address is, in this case, 0xfffec000. 

The Cyclone V has a timer block external to the Cortex A9 as well, if I
remember correctly.

>                                                Unfortunately Altera didn’t
> register the global timer, at least not on the upstream Kernels.

I would expect it to come from Qsys, in the sopcinfo file, but
apparently at some point I added it to my board info file instead.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lopes, Alexandre wrote:
> @Lowell: Like Gilles mentioned, there are several timers in the
> Cortex A9. At address PERIPH_BASE_ADDR + 0x200 you have the global timer
> registers and at PERIPH_BASE_ADDR + 0x600 you have the private timer and
> watchdog timer registers (on a per core basis). On the Altera socfpga
> systems
> the base address is, in this case, 0xfffec000. Unfortunately Altera
> didn’t
> register the global timer, at least not on the upstream Kernels.

The Linux mainline code refuses to start the global timer with old
revisions of the cortex A9 core which global timer is not exactly the same
as with newer revisions (there is a difference in what condition triggers
the timer interrupt which make it possible for the old revisions timer to
not receive an interrupt if the programmed delay is too short, whereas it
can not happen with newer versions). So, the SOCs in mainline based on
such old versions do not even bother to declare the global timer registers
in the DT.

The I-pipe clock source does not care about the timer, it only needs the
free running counter, and actually has been using it long before the arm
global timer driver was merged. This free running counter works fine in
both cases (and has an unparalleled resolution and latency, which makes it
interesting for emulating a tsc), so, I have patched up the global timer
code to keep the clocksource even with old revisions and only skip the
clockevent device registration, so that we can add the global timer
register declarations in DT and have the clocksource without the timer.
But this is a hack, really, it means that we have to add the DT data in
the I-pipe patch, and this is going to byte us when mainline decides to
restructure the global timer support.

The proper fix is to submit a patch to mainline that agrees both parties,
namely implement a different clockevent callback for the old revisions
that test for short delays and return -ETIME to let the clockevent system
handle it. Then submit the DT data to make the ARM global timer available
for the SOCs we need, and move all this out of the I-pipe patch.


-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

-----Ursprüngliche Nachricht-----
Von: Lowell Gilbert [mailto:kludge@be-well.ilk.org] 
Gesendet: Donnerstag, 11. Juni 2015 19:30
An: Lopes, Alexandre
Cc: Gilles Chanteperdrix; Lowell Gilbert; xenomai@xenomai.org
Betreff: Re: AW: [Xenomai] init failed code -19 on Cyclone V SoC

> The Cyclone V has a timer block external to the Cortex A9 as well, if I 
remember correctly.

Yes, you're right. There are four external timers available, which could 
also be used in this case and are already registered on the DTS:

timer0: timer0@ffc08000 {
	compatible = "snps,dw-apb-timer";
	interrupts = <0 167 4>;
	reg = <0xffc08000 0x1000>;
	clocks = <&l4_sp_clk>;
	clock-names = "timer";
};

timer1: timer1@ffc09000 {
	compatible = "snps,dw-apb-timer";
	interrupts = <0 168 4>;
	reg = <0xffc09000 0x1000>;
	clocks = <&l4_sp_clk>;
	clock-names = "timer";
};

timer2: timer2@ffd00000 {
	compatible = "snps,dw-apb-timer";
	interrupts = <0 169 4>;
	reg = <0xffd00000 0x1000>;
	clocks = <&osc1>;
	clock-names = "timer";
};

timer3: timer3@ffd01000 {
	compatible = "snps,dw-apb-timer";
	interrupts = <0 170 4>;
	reg = <0xffd01000 0x1000>;
	clocks = <&osc1>;
	clock-names = "timer";
};


> I would expect it to come from Qsys, in the sopcinfo file, but 
apparently at some point I added it to my board info file instead.

It also doesn't seem to be in DTS contained in the vendor specific Kernel 
(available from the RocketBoards website), so if you have it, it makes 
sense that you added it yourself.

Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

> -----Ursprüngliche Nachricht-----
> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Gesendet: Donnerstag, 11. Juni 2015 19:35
> An: Lopes, Alexandre
> Cc: Gilles Chanteperdrix; Lowell Gilbert; xenomai@xenomai.org
> Betreff: Re: AW: [Xenomai] init failed code -19 on Cyclone V SoC
> 
> The Linux mainline code refuses to start the global timer with old
> revisions of the cortex A9 core which global timer is not exactly the same
> as with newer revisions (there is a difference in what condition triggers
> the timer interrupt which make it possible for the old revisions timer to
> not receive an interrupt if the programmed delay is too short, whereas it
> can not happen with newer versions). So, the SOCs in mainline based on
> such old versions do not even bother to declare the global timer registers
> in the DT.
> 

I see. I've noticed the DTS for the Zynq-7000 does have a node for the
global timer. Since I believe the Cyclone V and the Zynq-7000 use identical
Cortex A9 revisions, the reason might then be that Altera never pushed for it
(supported by the fact that they don't use it even in their vendor-specific
Kernel, like I replied to Lowell)

> The I-pipe clock source does not care about the timer, it only needs the
> free running counter, and actually has been using it long before the arm
> global timer driver was merged. This free running counter works fine in
> both cases (and has an unparalleled resolution and latency, which makes it
> interesting for emulating a tsc), so, I have patched up the global timer
> code to keep the clocksource even with old revisions and only skip the
> clockevent device registration, so that we can add the global timer
> register declarations in DT and have the clocksource without the timer.
> But this is a hack, really, it means that we have to add the DT data in
> the I-pipe patch, and this is going to byte us when mainline decides to
> restructure the global timer support.

Right, adding the DTS nodes in the I-pipe patch sounds far from ideal.
In any case, since that's how it's being done atm, here's a patch which 
should work on any of the Altera's Cortex A9 based SoCs (Cyclone and Arria):

==================================================================

From fe7c1fff5a404daa284f2fc0253c44c689beeb54 Mon Sep 17 00:00:00 2001
From: Alexandre Lopes <alexandre.lopes.ext@zeiss.com>
Date: Fri, 12 Jun 2015 15:02:53 +0200
Subject: [PATCH] DT Cortex A9 global timer for Altera SoCs

---
 arch/arm/boot/dts/socfpga.dtsi |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 4472fd9..2507455 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -647,6 +647,15 @@
                        clocks = <&mpu_periph_clk>;
                };

+               /* Global timer */
+               timer@fffec200 {
+                       compatible = "arm,cortex-a9-global-timer";
+                       reg = <0xfffec200 0x20>;
+                       interrupts = <1 11 0xf04>;
+                       clocks = <&mpu_periph_clk>;
+               };
+
+
                timer0: timer0@ffc08000 {
                        compatible = "snps,dw-apb-timer";
                        interrupts = <0 167 4>;
-- 
1.7.9.5

==================================================================

Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lopes, Alexandre wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Gesendet: Donnerstag, 11. Juni 2015 19:35
>> An: Lopes, Alexandre
>> Cc: Gilles Chanteperdrix; Lowell Gilbert; xenomai@xenomai.org
>> Betreff: Re: AW: [Xenomai] init failed code -19 on Cyclone V SoC
>>
>> The Linux mainline code refuses to start the global timer with old
>> revisions of the cortex A9 core which global timer is not exactly the
>> same
>> as with newer revisions (there is a difference in what condition
>> triggers
>> the timer interrupt which make it possible for the old revisions timer
>> to
>> not receive an interrupt if the programmed delay is too short, whereas
>> it
>> can not happen with newer versions). So, the SOCs in mainline based on
>> such old versions do not even bother to declare the global timer
>> registers
>> in the DT.
>>
>
> I see. I've noticed the DTS for the Zynq-7000 does have a node for the
> global timer. Since I believe the Cyclone V and the Zynq-7000 use
> identical
> Cortex A9 revisions, the reason might then be that Altera never pushed for
> it
> (supported by the fact that they don't use it even in their
> vendor-specific
> Kernel, like I replied to Lowell)

Show me the beginning of your kernel boot log, it should allow us to see
what revision of cortex A9 you are using, and verify whether this version
is rejected by the global timer driver. We do not need to "believe" anything
we can verify.


-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

> Show me the beginning of your kernel boot log, it should allow us to see
> what revision of cortex A9 you are using, and verify whether this version
> is rejected by the global timer driver. 

Here's the output of /proc/cpuinfo (equally good, I guess)

processor       : 0
model name      : ARMv7 Processor rev 0 (v7l)
BogoMIPS        : 1594.16
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x3
CPU part        : 0xc09
CPU revision    : 0


We do not need to "believe"
> anything we can verify.
> 

Fair enough, but  I can't verify atm which exact revisions the Zynq-7000 
family uses, and I do know the node is upstream, so unless someone can
tell me which revisions it uses, I have no other choice.



Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lopes, Alexandre wrote:
>> Show me the beginning of your kernel boot log, it should allow us to
>> see
>> what revision of cortex A9 you are using, and verify whether this
>> version
>> is rejected by the global timer driver.
>
> Here's the output of /proc/cpuinfo (equally good, I guess)

Well, no, the boot log contains a 32 bits identifier printed in
hexadecimal which is easy to decode...

>
> processor       : 0
> model name      : ARMv7 Processor rev 0 (v7l)
> BogoMIPS        : 1594.16
> Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls
> vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x3
> CPU part        : 0xc09
> CPU revision    : 0

This seems to be extracted from the same ID, but we no longer see what
comes in what order. So, maybe your core revision is an r3p0, or maybe
not.


>
>
> We do not need to "believe"
>> anything we can verify.
>>
>
> Fair enough, but  I can't verify atm which exact revisions the Zynq-7000
> family uses, and I do know the node is upstream, so unless someone can
> tell me which revisions it uses, I have no other choice.

We do not really care what Zynq use, our concern is with the processor you
use. If indeed it is an r3p0, then the mainline arm global timer should
work with it, since it checks for revisions earlier than r2p0 and you can
submit the DT patch (not forgetting the information about irq, necessary
to use the timer) to the mainline kernel.

-- 
                    Gilles.

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Lopes, Alexandre]

> Well, no, the boot log contains a 32 bits identifier printed in
> hexadecimal which is easy to decode...

Okay, my bad then. Here it is (I thought the cpuinfo info was more useful)

[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d

Alexandre

Re: [Xenomai] init failed code -19 on Cyclone V SoC

[Gilles Chanteperdrix]

Lopes, Alexandre wrote:
>> Well, no, the boot log contains a 32 bits identifier printed in
>> hexadecimal which is easy to decode...
>
> Okay, my bad then. Here it is (I thought the cpuinfo info was more
> useful)
>
> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7),
> cr=10c5387d

Ok, that is r3p0. Now we are sure.

-- 
                    Gilles.