[Xenomai] Xenomai on Udoo Neo

[Xenomai] Xenomai on Udoo Neo

[mfinkbei]

Hi,

I am writing to request some Details about the Xenomai using for an Udoo 
Neo.
In my currently Thesis I'm working for the first time with an real-time 
System.
One objective therefore is to install Xenomai 3 on the Udoo Neo board 
with an iMX6 multicore Processor.
For the board exist a Linux-Version on the base of the Linux kernel 
3.14.56.
For this kernel Version there no i-pipe patch available. This is why I 
was looking for differences in the affected Files of the kernel 3.14.44 
and 3.14.56 and Change the i-pipe-patch when there are differences.
Afterwards, I was able to patch the Udoo Neo Kernel, to make the config, 
the bzImage and the modules and Install it from an Computer with 
Linux-OS to the SD-Card as described in the Documentation.
At that time of the Installation I kept on working with the Udoo Neo 
Board. For Configuring and building the ARM libraries I use the commands
./scripts/bootstrap
sudo ../configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a" 
--with-core=cobalt --enable-smp

After the make install Command I wanted to test the Installation with
dmesg | grep -i xenomai
where I get the Output

[    0.147853] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class idle 
registered.
[    0.147865] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class rt 
registered.
[    0.148004] [^[[01;31m^[[KXenomai^[[m^[[K] init failed, code -19

  the full dmesg output in this time frame is

[    0.146610] Bus freq driver module loaded
[    0.147489] futex hash table entries: 256 (order: 2, 16384 bytes)
[    0.147909] [Xenomai] scheduling class idle registered.
[    0.147921] [Xenomai] scheduling class rt registered.
[    0.148021] I-pipe: high-resolution clock not working
[    0.148063] [Xenomai] init failed, code -19
[    0.155688] VFS: Disk quotas dquot_6.5.2
[    0.155999] Dquot-cache hash table entries: 1024 (order 0, 4096 
bytes)

In the Archive of this mailing list I could find posts with similar 
Problems, where the user have to Change the Frequency scaling in the 
defconfig data.
But when I tried to disable the Frequency scaling with "make 
menuconfig", the kernel of Udoo can't compile.

I hope someone will have an idea to find a solution for this Problem.


Melanie
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: udoo_neo_defconfig
URL: <http://xenomai.org/pipermail/xenomai/attachments/20160523/1ce893f7/attachment.ksh>

Re: [Xenomai] Xenomai on Udoo Neo

[Gilles Chanteperdrix]

On Mon, May 23, 2016 at 09:49:18AM +0200, mfinkbei wrote:
> Hi,

Hi,

> 
> I am writing to request some Details about the Xenomai using for an Udoo 
> Neo.
> In my currently Thesis I'm working for the first time with an real-time 
> System.
> One objective therefore is to install Xenomai 3 on the Udoo Neo board 
> with an iMX6 multicore Processor.
> For the board exist a Linux-Version on the base of the Linux kernel 
> 3.14.56.
> For this kernel Version there no i-pipe patch available. This is why I 
> was looking for differences in the affected Files of the kernel 3.14.44 
> and 3.14.56 and Change the i-pipe-patch when there are differences.
> Afterwards, I was able to patch the Udoo Neo Kernel, to make the config, 
> the bzImage and the modules and Install it from an Computer with 
> Linux-OS to the SD-Card as described in the Documentation.
> At that time of the Installation I kept on working with the Udoo Neo 
> Board. For Configuring and building the ARM libraries I use the commands
> ./scripts/bootstrap
> sudo ../configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a" 
> --with-core=cobalt --enable-smp
> 
> After the make install Command I wanted to test the Installation with
> dmesg | grep -i xenomai
> where I get the Output
> 
> [    0.147853] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class idle 
> registered.
> [    0.147865] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class rt 
> registered.
> [    0.148004] [^[[01;31m^[[KXenomai^[[m^[[K] init failed, code -19
> 
>   the full dmesg output in this time frame is
> 
> [    0.146610] Bus freq driver module loaded
> [    0.147489] futex hash table entries: 256 (order: 2, 16384 bytes)
> [    0.147909] [Xenomai] scheduling class idle registered.
> [    0.147921] [Xenomai] scheduling class rt registered.
> [    0.148021] I-pipe: high-resolution clock not working

Xenomai on cortex a9 uses the global timer as its high resolution
clock source. AFAICT, you have not enabled the global timer in the
kernel configuration, so you simply need to enable it.

Also note that board-specific kernels drivers have generally a lower
quality than the mainline kernel, because they are not reviewed by
the Linux kernel community. So, rather than working with
board-specific kernel, it is advised to cleanup the board specific
drivers you need and submit them to the mainline kernel, so as to
get reviewed, which improves the drivers quality. And when it is
done, you no longer need the board-specific kernel.

Regards.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai on Udoo Neo

[mfinkbei]

Am 2016-05-23 09:59, schrieb Gilles Chanteperdrix:
> On Mon, May 23, 2016 at 09:49:18AM +0200, mfinkbei wrote:
>> Hi,
> 
> Hi,
> 
>> 
>> I am writing to request some Details about the Xenomai using for an 
>> Udoo
>> Neo.
>> In my currently Thesis I'm working for the first time with an 
>> real-time
>> System.
>> One objective therefore is to install Xenomai 3 on the Udoo Neo board
>> with an iMX6 multicore Processor.
>> For the board exist a Linux-Version on the base of the Linux kernel
>> 3.14.56.
>> For this kernel Version there no i-pipe patch available. This is why I
>> was looking for differences in the affected Files of the kernel 
>> 3.14.44
>> and 3.14.56 and Change the i-pipe-patch when there are differences.
>> Afterwards, I was able to patch the Udoo Neo Kernel, to make the 
>> config,
>> the bzImage and the modules and Install it from an Computer with
>> Linux-OS to the SD-Card as described in the Documentation.
>> At that time of the Installation I kept on working with the Udoo Neo
>> Board. For Configuring and building the ARM libraries I use the 
>> commands
>> ./scripts/bootstrap
>> sudo ../configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a"
>> --with-core=cobalt --enable-smp
>> 
>> After the make install Command I wanted to test the Installation with
>> dmesg | grep -i xenomai
>> where I get the Output
>> 
>> [    0.147853] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class idle
>> registered.
>> [    0.147865] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class rt
>> registered.
>> [    0.148004] [^[[01;31m^[[KXenomai^[[m^[[K] init failed, code -19
>> 
>>   the full dmesg output in this time frame is
>> 
>> [    0.146610] Bus freq driver module loaded
>> [    0.147489] futex hash table entries: 256 (order: 2, 16384 bytes)
>> [    0.147909] [Xenomai] scheduling class idle registered.
>> [    0.147921] [Xenomai] scheduling class rt registered.
>> [    0.148021] I-pipe: high-resolution clock not working
> 
> Xenomai on cortex a9 uses the global timer as its high resolution
> clock source. AFAICT, you have not enabled the global timer in the
> kernel configuration, so you simply need to enable it.
> 
> Also note that board-specific kernels drivers have generally a lower
> quality than the mainline kernel, because they are not reviewed by
> the Linux kernel community. So, rather than working with
> board-specific kernel, it is advised to cleanup the board specific
> drivers you need and submit them to the mainline kernel, so as to
> get reviewed, which improves the drivers quality. And when it is
> done, you no longer need the board-specific kernel.
> 
> Regards.

Thank you for your answer.
The CONFIG_ARM_GLOBAL_TIMER is already enabled.
I also noticed that a mainline kernel would be better, especially for 
newbies in Xenomai.
But the main scope of my master thesis includes the work with that 
developing board and the multicore Processor. The realisation of an 
real-time-system for the A9 Processor is just necessary for my work. I'm 
not familiar with the driver development, so it's not possible for me, 
to fix the problems there in reasonable time.
I've recognized, that the drivers have a lower quality and didn't 
support the frequency scaling switch. For this reason I'm searching for 
a possibility to install Xenomai with enabled frequency scaling and then 
disabling the frequency scaling outside the kernel.

Regards
Melanie

Re: [Xenomai] Xenomai on Udoo Neo

[Gilles Chanteperdrix]

On Tue, May 24, 2016 at 03:28:08PM +0200, mfinkbei wrote:
> Am 2016-05-23 09:59, schrieb Gilles Chanteperdrix:
> > On Mon, May 23, 2016 at 09:49:18AM +0200, mfinkbei wrote:
> >> Hi,
> > 
> > Hi,
> > 
> >> 
> >> I am writing to request some Details about the Xenomai using for an 
> >> Udoo
> >> Neo.
> >> In my currently Thesis I'm working for the first time with an 
> >> real-time
> >> System.
> >> One objective therefore is to install Xenomai 3 on the Udoo Neo board
> >> with an iMX6 multicore Processor.
> >> For the board exist a Linux-Version on the base of the Linux kernel
> >> 3.14.56.
> >> For this kernel Version there no i-pipe patch available. This is why I
> >> was looking for differences in the affected Files of the kernel 
> >> 3.14.44
> >> and 3.14.56 and Change the i-pipe-patch when there are differences.
> >> Afterwards, I was able to patch the Udoo Neo Kernel, to make the 
> >> config,
> >> the bzImage and the modules and Install it from an Computer with
> >> Linux-OS to the SD-Card as described in the Documentation.
> >> At that time of the Installation I kept on working with the Udoo Neo
> >> Board. For Configuring and building the ARM libraries I use the 
> >> commands
> >> ./scripts/bootstrap
> >> sudo ../configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a"
> >> --with-core=cobalt --enable-smp
> >> 
> >> After the make install Command I wanted to test the Installation with
> >> dmesg | grep -i xenomai
> >> where I get the Output
> >> 
> >> [    0.147853] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class idle
> >> registered.
> >> [    0.147865] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class rt
> >> registered.
> >> [    0.148004] [^[[01;31m^[[KXenomai^[[m^[[K] init failed, code -19
> >> 
> >>   the full dmesg output in this time frame is
> >> 
> >> [    0.146610] Bus freq driver module loaded
> >> [    0.147489] futex hash table entries: 256 (order: 2, 16384 bytes)
> >> [    0.147909] [Xenomai] scheduling class idle registered.
> >> [    0.147921] [Xenomai] scheduling class rt registered.
> >> [    0.148021] I-pipe: high-resolution clock not working
> > 
> > Xenomai on cortex a9 uses the global timer as its high resolution
> > clock source. AFAICT, you have not enabled the global timer in the
> > kernel configuration, so you simply need to enable it.
> > 
> > Also note that board-specific kernels drivers have generally a lower
> > quality than the mainline kernel, because they are not reviewed by
> > the Linux kernel community. So, rather than working with
> > board-specific kernel, it is advised to cleanup the board specific
> > drivers you need and submit them to the mainline kernel, so as to
> > get reviewed, which improves the drivers quality. And when it is
> > done, you no longer need the board-specific kernel.
> > 
> > Regards.
> 
> Thank you for your answer.
> The CONFIG_ARM_GLOBAL_TIMER is already enabled.

Not in the kernel configuration you have sent to this list and that
is available here:
https://xenomai.org/pipermail/xenomai/attachments/20160523/1ce893f7/attachment.ksh

> I also noticed that a mainline kernel would be better, especially for 
> newbies in Xenomai.
> But the main scope of my master thesis includes the work with that 
> developing board and the multicore Processor. The realisation of an 
> real-time-system for the A9 Processor is just necessary for my work. I'm 
> not familiar with the driver development, so it's not possible for me, 
> to fix the problems there in reasonable time.
> I've recognized, that the drivers have a lower quality and didn't 
> support the frequency scaling switch. For this reason I'm searching for 
> a possibility to install Xenomai with enabled frequency scaling and then 
> disabling the frequency scaling outside the kernel.

Enabling frequency scaling should not prevent Xenomai from starting.
The issue you have is unrelated to frequency scaling.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai on Udoo Neo

[mfinkbei]

On Tue, May 24, 2016 at 05:13:16PM +0200, mfinkbei wrote:
> Am 2016-05-24 15:53, schrieb Gilles Chanteperdrix:
> > On Tue, May 24, 2016 at 03:28:08PM +0200, mfinkbei wrote:
> >> Am 2016-05-23 09:59, schrieb Gilles Chanteperdrix:
> >> > On Mon, May 23, 2016 at 09:49:18AM +0200, mfinkbei wrote:
> >> >> Hi,
> >> >
> >> > Hi,
> >> >
> >> >>
> >> >> I am writing to request some Details about the Xenomai using for an
> >> >> Udoo
> >> >> Neo.
> >> >> In my currently Thesis I'm working for the first time with an
> >> >> real-time
> >> >> System.
> >> >> One objective therefore is to install Xenomai 3 on the Udoo Neo board
> >> >> with an iMX6 multicore Processor.
> >> >> For the board exist a Linux-Version on the base of the Linux kernel
> >> >> 3.14.56.
> >> >> For this kernel Version there no i-pipe patch available. This is why I
> >> >> was looking for differences in the affected Files of the kernel
> >> >> 3.14.44
> >> >> and 3.14.56 and Change the i-pipe-patch when there are differences.
> >> >> Afterwards, I was able to patch the Udoo Neo Kernel, to make the
> >> >> config,
> >> >> the bzImage and the modules and Install it from an Computer with
> >> >> Linux-OS to the SD-Card as described in the Documentation.
> >> >> At that time of the Installation I kept on working with the Udoo Neo
> >> >> Board. For Configuring and building the ARM libraries I use the
> >> >> commands
> >> >> ./scripts/bootstrap
> >> >> sudo ../configure CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a"
> >> >> --with-core=cobalt --enable-smp
> >> >>
> >> >> After the make install Command I wanted to test the Installation with
> >> >> dmesg | grep -i xenomai
> >> >> where I get the Output
> >> >>
> >> >> [    0.147853] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class idle
> >> >> registered.
> >> >> [    0.147865] [^[[01;31m^[[KXenomai^[[m^[[K] scheduling class rt
> >> >> registered.
> >> >> [    0.148004] [^[[01;31m^[[KXenomai^[[m^[[K] init failed, code -19
> >> >>
> >> >>   the full dmesg output in this time frame is
> >> >>
> >> >> [    0.146610] Bus freq driver module loaded
> >> >> [    0.147489] futex hash table entries: 256 (order: 2, 16384 bytes)
> >> >> [    0.147909] [Xenomai] scheduling class idle registered.
> >> >> [    0.147921] [Xenomai] scheduling class rt registered.
> >> >> [    0.148021] I-pipe: high-resolution clock not working
> >> >
> >> > Xenomai on cortex a9 uses the global timer as its high resolution
> >> > clock source. AFAICT, you have not enabled the global timer in the
> >> > kernel configuration, so you simply need to enable it.
> >> >
> >> > Also note that board-specific kernels drivers have generally a lower
> >> > quality than the mainline kernel, because they are not reviewed by
> >> > the Linux kernel community. So, rather than working with
> >> > board-specific kernel, it is advised to cleanup the board specific
> >> > drivers you need and submit them to the mainline kernel, so as to
> >> > get reviewed, which improves the drivers quality. And when it is
> >> > done, you no longer need the board-specific kernel.
> >> >
> >> > Regards.
> >>
> >> Thank you for your answer.
> >> The CONFIG_ARM_GLOBAL_TIMER is already enabled.
> >
> > Not in the kernel configuration you have sent to this list and that
> > is available here:
> > https://xenomai.org/pipermail/xenomai/attachments/20160523/1ce893f7/attachment.ksh
> >
> >> I also noticed that a mainline kernel would be better, especially for
> >> newbies in Xenomai.
> >> But the main scope of my master thesis includes the work with that
> >> developing board and the multicore Processor. The realisation of an
> >> real-time-system for the A9 Processor is just necessary for my work.
> >> I'm
> >> not familiar with the driver development, so it's not possible for me,
> >> to fix the problems there in reasonable time.
> >> I've recognized, that the drivers have a lower quality and didn't
> >> support the frequency scaling switch. For this reason I'm searching
> >> for
> >> a possibility to install Xenomai with enabled frequency scaling and
> >> then
> >> disabling the frequency scaling outside the kernel.
> >
> > Enabling frequency scaling should not prevent Xenomai from starting.
> > The issue you have is unrelated to frequency scaling.
> 
> But the contents of dmesg are the same as when CONFIG_ARM_GLOBAL_TIMER
> is enabled in the .config file.
> Do you know some other strategies to detect and correct the cause of 
> the
> error message?

Yes. Get the clock source properly registered. What version of the
I-pipe patch are you using? The problem might be that you use a
custom device tree file which does not include the mx6 device tree
include file which declares everything necessary for the global
timer. Or that the kernel fork you use use another device tree file.


-- 
					    Gilles.
https://click-hack.org

I adapted the I-pipe patch 3.14.44 to the kernel 3.14.56. The files, 
which will be changed in the patch for kernel 3.14.44 have just little 
differences.

Melanie

Re: [Xenomai] Xenomai on Udoo Neo

[Gilles Chanteperdrix]

On Tue, May 24, 2016 at 05:48:48PM +0200, mfinkbei wrote:
> I adapted the I-pipe patch 3.14.44 to the kernel 3.14.56.

There is more than one version of the I-pipe patch for 3.14.44,
actually there are 7. Which one of the 7 are you using?
You can find the history of I-pipe patches for 3.14.44 here:
https://xenomai.org//downloads/ipipe/v3.x/arm/older/

> The files, 
> which will be changed in the patch for kernel 3.14.44 have just little 
> differences.

My point is: the I-pipe patch, provided that you are using
the last version, patches some device tree files, but these may not
be the device tree files you use with your kernel fork.

To be completely specific I am referring to the following hunk:
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..bf84723 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -106,6 +106,13 @@
 			clocks = <&clks 15>;
 		};
 
+		timer@00a00200 {
+			compatible = "arm,cortex-a9-global-timer";
+			reg = <0x00a00200 0x20>;
+			interrupts = <1 11 0xf01>;
+			clocks = <&clks 15>;
+		};
+

Does the device tree file you use include this file?

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai on Udoo Neo

[mfinkbei]

On Tue, May 24, 2016 at 05:48:48PM +0200, mfinkbei wrote:
> I adapted the I-pipe patch 3.14.44 to the kernel 3.14.56.

There is more than one version of the I-pipe patch for 3.14.44,
actually there are 7. Which one of the 7 are you using?
You can find the history of I-pipe patches for 3.14.44 here:
https://xenomai.org//downloads/ipipe/v3.x/arm/older/

> The files,
> which will be changed in the patch for kernel 3.14.44 have just little
> differences.

My point is: the I-pipe patch, provided that you are using
the last version, patches some device tree files, but these may not
be the device tree files you use with your kernel fork.

To be completely specific I am referring to the following hunk:
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi 
b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..bf84723 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -106,6 +106,13 @@
  			clocks = <&clks 15>;
  		};

+		timer@00a00200 {
+			compatible = "arm,cortex-a9-global-timer";
+			reg = <0x00a00200 0x20>;
+			interrupts = <1 11 0xf01>;
+			clocks = <&clks 15>;
+		};
+

Does the device tree file you use include this file?

-- 
					    Gilles.
https://click-hack.org

I  used the ipipe-core-3.14.44-arm-16.patch.
The hunk that you reffering to was defined as followed:

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi 
b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..bf84723 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -132,6 +132,13 @@
  			clocks = <&clks IMX6QDL_CLK_TWD>;
  		};

+		timer@00a00200 {
+			compatible = "arm,cortex-a9-global-timer";
+			reg = <0x00a00200 0x20>;
+			interrupts = <1 11 0xf01>;
+			clocks = <&clks IMX6QDL_CLK_TWD>;
+		};
+
  		L2: l2-cache@00a02000 {
  			compatible = "arm,pl310-cache";
  			reg = <0x00a02000 0x1000>;

Melanie

Re: [Xenomai] Xenomai on Udoo Neo

[Gilles Chanteperdrix]

On Tue, May 24, 2016 at 07:47:23PM +0200, mfinkbei wrote:
> On Tue, May 24, 2016 at 05:48:48PM +0200, mfinkbei wrote:
> > I adapted the I-pipe patch 3.14.44 to the kernel 3.14.56.
> 
> There is more than one version of the I-pipe patch for 3.14.44,
> actually there are 7. Which one of the 7 are you using?
> You can find the history of I-pipe patches for 3.14.44 here:
> https://xenomai.org//downloads/ipipe/v3.x/arm/older/
> 
> > The files,
> > which will be changed in the patch for kernel 3.14.44 have just little
> > differences.
> 
> My point is: the I-pipe patch, provided that you are using
> the last version, patches some device tree files, but these may not
> be the device tree files you use with your kernel fork.
> 
> To be completely specific I am referring to the following hunk:
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi 
> b/arch/arm/boot/dts/imx6qdl.dtsi
> index fb28b2e..bf84723 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -106,6 +106,13 @@
>   			clocks = <&clks 15>;
>   		};
> 
> +		timer@00a00200 {
> +			compatible = "arm,cortex-a9-global-timer";
> +			reg = <0x00a00200 0x20>;
> +			interrupts = <1 11 0xf01>;
> +			clocks = <&clks 15>;
> +		};
> +
> 
> Does the device tree file you use include this file?
> 
> -- 
> 					    Gilles.
> https://click-hack.org

When you answer a mail, it is customary to strip the signature. Most
civilized mail user agent do this for you. In fact, it is even
customary to only keep the part of the mails which are relevant for
your answer (but very few people do that nowadays).


> 
> I  used the ipipe-core-3.14.44-arm-16.patch.
> The hunk that you reffering to was defined as followed:
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi 
> b/arch/arm/boot/dts/imx6qdl.dtsi
> index fb28b2e..bf84723 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -132,6 +132,13 @@
>   			clocks = <&clks IMX6QDL_CLK_TWD>;
>   		};
> 
> +		timer@00a00200 {
> +			compatible = "arm,cortex-a9-global-timer";
> +			reg = <0x00a00200 0x20>;
> +			interrupts = <1 11 0xf01>;
> +			clocks = <&clks IMX6QDL_CLK_TWD>;
> +		};
> +
>   		L2: l2-cache@00a02000 {
>   			compatible = "arm,pl310-cache";
>   			reg = <0x00a02000 0x1000>;

No, the file
https://xenomai.org//downloads/ipipe/v3.x/arm/older/ipipe-core-3.14.44-arm-16.patch
does not contain this hunk. So, if the patch you are using contains
this hunk, you are not using ipipe-core-3.14.44-arm-16.patch.

Anyway, I can find the hunk a patch contains, downloading the patch
from the server. This is not what I am asking you. The question I
have been trying to ask three times and to which I can not find the
answer because I do not have the sources you use is: does the device
tree file you use include imx6ql.dtsi?

When you do not understand a question, I prefer you to tell me,
rather than giving a random answer. This is very irritating.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai on Udoo Neo

[mfinkbei]

Am 2016-05-24 20:02, schrieb Gilles Chanteperdrix:
> 
> No, the file
> https://xenomai.org//downloads/ipipe/v3.x/arm/older/ipipe-core-3.14.44-arm-16.patch
> does not contain this hunk. So, if the patch you are using contains
> this hunk, you are not using ipipe-core-3.14.44-arm-16.patch.
> 
> Anyway, I can find the hunk a patch contains, downloading the patch
> from the server. This is not what I am asking you. The question I
> have been trying to ask three times and to which I can not find the
> answer because I do not have the sources you use is: does the device
> tree file you use include imx6ql.dtsi?
> 
> When you do not understand a question, I prefer you to tell me,
> rather than giving a random answer. This is very irritating.

I apologize for the misunderstanding.

The imx6qdl.dtsi file is being included into the imx6q- .dts files.
Those dts files are converted to dtb files using make (see 'Compile 
Device Tree' below).
The resulting dtb files are copied on the boot partition of the SD card 
afterwards (see rest of description below).

Here the concerning part of the documentation to the Udoo Neo board:

Compile Device Trees
ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make dtbs -j5


Compile the modules
ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make modules -j5


Copy the kernel to the SD card

You can overwrite the kernel on a UDOObuntu SD card with the following 
commands:
BOOT_PARTITION=/path/to/boot-partition
ROOT_PARTITION=/path/to/root-partition

cp arch/arm/boot/zImage $BOOT_PARTITION
cp arch/arm/boot/dts/*.dtb $BOOT_PARTITION/dts
ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make firmware_install 
modules_install INSTALL_MOD_PATH=$ROOT_PARTITION

In addition to that I insert before the last make the following:
cp .config /boot/config-3.14.56-udooneo-02013-gabdce68
cp System.map /boot/System.map-3.14.56-udooneo-02013-gabdce68


So as far as I understood an found out the imx6qdl.dtsi file should used 
in the device tree.
Am I right here?

Re: [Xenomai] Xenomai on Udoo Neo

[Gilles Chanteperdrix]

On Wed, May 25, 2016 at 12:03:44PM +0200, mfinkbei wrote:
> Am 2016-05-24 20:02, schrieb Gilles Chanteperdrix:
> > 
> > No, the file
> > https://xenomai.org//downloads/ipipe/v3.x/arm/older/ipipe-core-3.14.44-arm-16.patch
> > does not contain this hunk. So, if the patch you are using contains
> > this hunk, you are not using ipipe-core-3.14.44-arm-16.patch.
> > 
> > Anyway, I can find the hunk a patch contains, downloading the patch
> > from the server. This is not what I am asking you. The question I
> > have been trying to ask three times and to which I can not find the
> > answer because I do not have the sources you use is: does the device
> > tree file you use include imx6ql.dtsi?
> > 
> > When you do not understand a question, I prefer you to tell me,
> > rather than giving a random answer. This is very irritating.
> 
> I apologize for the misunderstanding.
> 
> The imx6qdl.dtsi file is being included into the imx6q- .dts files.
> Those dts files are converted to dtb files using make (see 'Compile 
> Device Tree' below).
> The resulting dtb files are copied on the boot partition of the SD card 
> afterwards (see rest of description below).
> 
> Here the concerning part of the documentation to the Udoo Neo board:
> 
> Compile Device Trees
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make dtbs -j5
> 
> 
> Compile the modules
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make modules -j5
> 
> 
> Copy the kernel to the SD card
> 
> You can overwrite the kernel on a UDOObuntu SD card with the following 
> commands:
> BOOT_PARTITION=/path/to/boot-partition
> ROOT_PARTITION=/path/to/root-partition
> 
> cp arch/arm/boot/zImage $BOOT_PARTITION
> cp arch/arm/boot/dts/*.dtb $BOOT_PARTITION/dts
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make firmware_install 
> modules_install INSTALL_MOD_PATH=$ROOT_PARTITION
> 
> In addition to that I insert before the last make the following:
> cp .config /boot/config-3.14.56-udooneo-02013-gabdce68
> cp System.map /boot/System.map-3.14.56-udooneo-02013-gabdce68
> 
> 
> So as far as I understood an found out the imx6qdl.dtsi file should used 
> in the device tree.
> Am I right here?

Basically what you showed here does not show what particular dts
your device uses, since all the dtbs are copied. So, no, you do not
know yet if the dtb your device actually loads contains the
declaration of the global timer.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai on Udoo Neo

[mfinkbei]

Am 2016-05-25 12:11, schrieb Gilles Chanteperdrix:
> 
> Basically what you showed here does not show what particular dts
> your device uses, since all the dtbs are copied. So, no, you do not
> know yet if the dtb your device actually loads contains the
> declaration of the global timer.

You were right.
With the command cat /proc/device-tree/compatible I have found out that 
the file imx6sx is used in the device tree instead of imx6qdl.
After I declared the timer in the imx6sx.dtsi file Xenomai was running.
Thank you for your help, Gilles.