[Xenomai] Fwd: Kernel Compilation Problems

[Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

By way of introduction, I am one of the LinuxCNC developers, but
pretty new to kernel patching.

Let me first say that what I am trying to do is something I knew would
be difficult.

I am trying to build a Xenomai kernel for the Udoo board. I have
compiled and run the kernel from the Udoo github repository (3.0.35) ,
and I have compiled a  Xenomai kernel based on the tagged archive on
the Freescale archive (3.0.43, if I recall correctly) recommended in
the Xenomai README. This did not
boot the Udoo.

I have been trying to combine the two together.

The xenomai patch for the arm/mxc patch is actually in three parts,
there is a pre-patch which seems to put the kernel in a state where
the main patch can take, and a post patch to put things back as they
were before compilation.

With a bit of hand-fettling I made the pre-patch take, and then the
main xenomai patch took cleanly. I then had to hand-apply a few bits
of the post patch, and then tried to compile.

I think that I am close to a compilable situation, but there are a
couple of persistent compile errors that I simply can't squash.

 CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
drivers/built-in.o: In function `fec_enet_init':
bufp.c:(.text.unlikely+0x209c): undefined reference to `dma_alloc_noncacheable'
sound/built-in.o: In function `imx_pcm_preallocate_dma_buffer.constprop.8':
last.c:(.text+0x37320): undefined reference to `dma_alloc_writethrough'
last.c:(.text+0x37370): undefined reference to `dma_alloc_writethrough'
sound/built-in.o: In function `imx_soc_platform_probe':
last.c:(.devinit.text+0x528): undefined reference to `dma_alloc_noncacheable'
make: *** [.tmp_vmlinux1] Error 1

Note that bufp.c is symlinked out of the kernel tree into the xenomai
tree. (by the xeno patch) and does not contain a fec_enet_init
function, nor a call to dma_alloc_noncacheable.
fec_enet_init exists in drivers/net/fec.c and does have a call to
dma_alloc_noncacheable, but also #includes dma-mapping.h. (though
dma_alloc_noncacheable is actually in
arch/arm/include/asm/dma-mapping.h which is conditionally #included in
<linux/dma-mapping.h>

I am pretty sure that there really isn't any function anywhere called
"`imx_pcm_preallocate_dma_buffer.constprop.8"

I wonder if anyone can point me in the right direction? Help
interpreting the error codes would be a start, for example which code
"bufp.c:(.text.unlikely+0x209c):" is really pointing at.


--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/16/2014 04:41 PM, Andy Pugh wrote:
> By way of introduction, I am one of the LinuxCNC developers, but
> pretty new to kernel patching.
> 
> Let me first say that what I am trying to do is something I knew would
> be difficult.
> 
> I am trying to build a Xenomai kernel for the Udoo board. I have
> compiled and run the kernel from the Udoo github repository (3.0.35) ,
> and I have compiled a  Xenomai kernel based on the tagged archive on
> the Freescale archive (3.0.43, if I recall correctly) recommended in
> the Xenomai README. This did not
> boot the Udoo.
> 
> I have been trying to combine the two together.
> 
> The xenomai patch for the arm/mxc patch is actually in three parts,
> there is a pre-patch which seems to put the kernel in a state where
> the main patch can take, and a post patch to put things back as they
> were before compilation.
> 
> With a bit of hand-fettling I made the pre-patch take, and then the
> main xenomai patch took cleanly. I then had to hand-apply a few bits
> of the post patch, and then tried to compile.
> 
> I think that I am close to a compilable situation, but there are a
> couple of persistent compile errors that I simply can't squash.

The pre- and post- patches are for the freescale tree. If the Udoo tree
is not based on the freescale tree, there is no reason to add the pre
and post patches. You are probably better off following the I-pipe
porting guide, and add support for the imx6 yourself, looking into the
post patch for some details. Unfortunately 3.0 is too recent for the old
porting guide to apply completely, and too old for the new porting
guide, but with some patience, this should work.

The old:
http://www.xenomai.org/index.php/I-pipe:ArmPorting

The new:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting



> 
>  CC      init/version.o
>   LD      init/built-in.o
>   LD      .tmp_vmlinux1
> drivers/built-in.o: In function `fec_enet_init':
> bufp.c:(.text.unlikely+0x209c): undefined reference to `dma_alloc_noncacheable'
> sound/built-in.o: In function `imx_pcm_preallocate_dma_buffer.constprop.8':
> last.c:(.text+0x37320): undefined reference to `dma_alloc_writethrough'
> last.c:(.text+0x37370): undefined reference to `dma_alloc_writethrough'
> sound/built-in.o: In function `imx_soc_platform_probe':
> last.c:(.devinit.text+0x528): undefined reference to `dma_alloc_noncacheable'
> make: *** [.tmp_vmlinux1] Error 1
> 
> Note that bufp.c is symlinked out of the kernel tree into the xenomai
> tree. (by the xeno patch) and does not contain a fec_enet_init
> function, nor a call to dma_alloc_noncacheable.
> fec_enet_init exists in drivers/net/fec.c and does have a call to
> dma_alloc_noncacheable, but also #includes dma-mapping.h. (though
> dma_alloc_noncacheable is actually in
> arch/arm/include/asm/dma-mapping.h which is conditionally #included in
> <linux/dma-mapping.h>
> 
> I am pretty sure that there really isn't any function anywhere called
> "`imx_pcm_preallocate_dma_buffer.constprop.8"

The real function is probably imx_pcm_preallocate_dma_buffer, the
.constprop.8 postfix would be added by the compiler (constant
propagation?). This all looks like a configuration issue. Does the
unpatched kernel, with exactly the same configuration, compile correctly?

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 16 January 2014 22:43, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

>
> The pre- and post- patches are for the freescale tree. If the Udoo tree
> is not based on the freescale tree, there is no reason to add the pre
> and post patches.


I think it must have been at some point. The main adeos patch "took"
cleanly after forcing the ..pre.patch, and not at all without it.


> You are probably better off following the I-pipe
> porting guide, and add support for the imx6 yourself


Unfortunately that is probably rather outside my skill level, but I might
return to that if my current plan fails (which is making a patch of all the
changes in the Udoo github, and seeing if those will apply to my working
xenomai/arm kernel

>
> > I am pretty sure that there really isn't any function anywhere called
> > "`imx_pcm_preallocate_dma_buffer.constprop.8"
>

Does the
>  unpatched kernel, with exactly the same configuration, compile correctly?
>

Yes it does, which is why it seemed like a promising starting-point.


-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

> On 16 January 2014 22:43, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>
>> Does the
>> unpatched kernel, with exactly the same configuration, compile correctly?

I had a feeling that I was very close, so I commented out the two
calls each to the troublesome functions, figuring that for the
time-being I would live without hdmi-audio and fec ethernet.

After that, the patched Udoo git repository kernel did compile, and
boots the board. I need to figure out how to tidy up the kernel string
(all changes _are_ committed).

How does this look?


[    1.397848] I-pipe: Domain Xenomai registered.
[    1.402368] Xenomai: hal/arm started.
[    1.406363] Xenomai: scheduling class idle registered.
[    1.411520] Xenomai: scheduling class rt registered.
[    1.424750] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
[    1.431387] Xenomai: debug mode enabled.
[    1.435777] Xenomai: starting native API services
[    1.440587] Xenomai: starting POSIX services.
[    1.445072] Xenomai: starting RTDM services.

andypugh@udoo:~/git/Kernel_Unico$ ls /proc/xenomai/

acct  affinity  apc  faults  heap  interfaces  irq  latency  lock
registry  rtdm  sched  schedclasses  stat  timebases  timer  timerstat
 version

And the testsuite:

andypugh@udoo:~/git/Xenomai$ uname -a

Linux udoo 3.0.35-Xenomai-g58cf7fe-dirty #13 SMP PREEMPT Fri Jan 17
03:26:53 UTC 2014 armv7l armv7l armv7l GNU/Linux

andypugh@udoo:~/git/Xenomai$ sudo xeno-regression-test -l
"/usr/lib/xenomai/testsuite/dohell -m /tmp 100" -t 2

Started child 9158: /bin/bash
/usr/lib/xenomai/testsuite/xeno-test-run-wrapper
/usr/bin/xeno-regression-test -t 2

++ echo 0
++ /usr/lib/xenomai/testsuite/arith
mul: 0x79364d93, shft: 26
integ: 30, frac: 0x4d9364d9364d9364
signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 45.615 ns, rejected 0/10000
inlined llimd: 0x79364d9364d9362f: 1727.421 ns, rejected 2/10000
inlined llmulshft: 0x79364d92ffffffe1: 32.735 ns, rejected 0/10000
inlined nodiv_llimd: 0x79364d9364d9362f: 45.375 ns, rejected 0/10000
out of line calibration: 0x0000000000000000: 48.075 ns, rejected 0/10000
out of line llimd: 0x79364d9364d9362f: 1788.676 ns, rejected 2/10000
out of line llmulshft: 0x79364d92ffffffe1: 27.764 ns, rejected 0/10000
out of line nodiv_llimd: 0x79364d9364d9362f: 40.441 ns, rejected 0/10000
signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 45.565 ns, rejected 0/10000
inlined llimd: 0x86c9b26c9b26c9d1: 1743.871 ns, rejected 1/10000
inlined llmulshft: 0xd45d172d0000001e: 22.707 ns, rejected 0/10000
inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 50.464 ns, rejected 0/10000
out of line calibration: 0x0000000000000000: 70.583 ns, rejected 0/10000
out of line llimd: 0x86c9b26c9b26c9d1: 1751.943 ns, rejected 2/10000
out of line llmulshft: 0xd45d172d0000001e: 10.312 ns, rejected 0/10000
out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 30.519 ns, rejected 0/10000

unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
inline calibration: 0x0000000000000000: 45.570 ns, rejected 0/10000
inlined nodiv_ullimd: 0x79364d9364d9362f: 42.910 ns, rejected 0/10000
out of line calibration: 0x0000000000000000: 48.037 ns, rejected 0/10000
out of line nodiv_ullimd: 0x79364d9364d9362f: 40.478 ns, rejected 0/10000
++ /usr/lib/xenomai/testsuite/clocktest -C 42 -T 30
== Tested clock: 42 (CLOCK_HOST_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------- --------------
  0                  1.3            0.024          0            0.0
  1                  1.0            0.040          0            0.0
  2                  0.6           -0.046          0            0.0
  3                  1.2            0.046          0            0.0

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/17/2014 09:44 PM, Andy Pugh wrote:
>> On 16 January 2014 22:43, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> Does the
>>> unpatched kernel, with exactly the same configuration, compile correctly?
> 
> I had a feeling that I was very close, so I commented out the two
> calls each to the troublesome functions, figuring that for the
> time-being I would live without hdmi-audio and fec ethernet.
> 
> After that, the patched Udoo git repository kernel did compile, and
> boots the board. I need to figure out how to tidy up the kernel string
> (all changes _are_ committed).
> 
> How does this look?
> 
> 
> [    1.397848] I-pipe: Domain Xenomai registered.
> [    1.402368] Xenomai: hal/arm started.
> [    1.406363] Xenomai: scheduling class idle registered.
> [    1.411520] Xenomai: scheduling class rt registered.
> [    1.424750] Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
> [    1.431387] Xenomai: debug mode enabled.
> [    1.435777] Xenomai: starting native API services
> [    1.440587] Xenomai: starting POSIX services.
> [    1.445072] Xenomai: starting RTDM services.
> 
> andypugh@udoo:~/git/Kernel_Unico$ ls /proc/xenomai/
> 
> acct  affinity  apc  faults  heap  interfaces  irq  latency  lock
> registry  rtdm  sched  schedclasses  stat  timebases  timer  timerstat
>  version
> 
> And the testsuite:
> 
> andypugh@udoo:~/git/Xenomai$ uname -a
> 
> Linux udoo 3.0.35-Xenomai-g58cf7fe-dirty #13 SMP PREEMPT Fri Jan 17
> 03:26:53 UTC 2014 armv7l armv7l armv7l GNU/Linux
> 
> andypugh@udoo:~/git/Xenomai$ sudo xeno-regression-test -l
> "/usr/lib/xenomai/testsuite/dohell -m /tmp 100" -t 2
> 
> Started child 9158: /bin/bash
> /usr/lib/xenomai/testsuite/xeno-test-run-wrapper
> /usr/bin/xeno-regression-test -t 2
> 
> ++ echo 0
> ++ /usr/lib/xenomai/testsuite/arith
> mul: 0x79364d93, shft: 26
> integ: 30, frac: 0x4d9364d9364d9364
> signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 45.615 ns, rejected 0/10000
> inlined llimd: 0x79364d9364d9362f: 1727.421 ns, rejected 2/10000
> inlined llmulshft: 0x79364d92ffffffe1: 32.735 ns, rejected 0/10000
> inlined nodiv_llimd: 0x79364d9364d9362f: 45.375 ns, rejected 0/10000
> out of line calibration: 0x0000000000000000: 48.075 ns, rejected 0/10000
> out of line llimd: 0x79364d9364d9362f: 1788.676 ns, rejected 2/10000
> out of line llmulshft: 0x79364d92ffffffe1: 27.764 ns, rejected 0/10000
> out of line nodiv_llimd: 0x79364d9364d9362f: 40.441 ns, rejected 0/10000
> signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 45.565 ns, rejected 0/10000
> inlined llimd: 0x86c9b26c9b26c9d1: 1743.871 ns, rejected 1/10000
> inlined llmulshft: 0xd45d172d0000001e: 22.707 ns, rejected 0/10000
> inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 50.464 ns, rejected 0/10000
> out of line calibration: 0x0000000000000000: 70.583 ns, rejected 0/10000
> out of line llimd: 0x86c9b26c9b26c9d1: 1751.943 ns, rejected 2/10000
> out of line llmulshft: 0xd45d172d0000001e: 10.312 ns, rejected 0/10000
> out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 30.519 ns, rejected 0/10000
> 
> unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000
> inline calibration: 0x0000000000000000: 45.570 ns, rejected 0/10000
> inlined nodiv_ullimd: 0x79364d9364d9362f: 42.910 ns, rejected 0/10000
> out of line calibration: 0x0000000000000000: 48.037 ns, rejected 0/10000
> out of line nodiv_ullimd: 0x79364d9364d9362f: 40.478 ns, rejected 0/10000
> ++ /usr/lib/xenomai/testsuite/clocktest -C 42 -T 30
> == Tested clock: 42 (CLOCK_HOST_REALTIME)
> CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
> --- -------------------- ---------------- ---------- --------------
>   0                  1.3            0.024          0            0.0
>   1                  1.0            0.040          0            0.0
>   2                  0.6           -0.046          0            0.0
>   3                  1.2            0.046          0            0.0
> 

It looks ok, you should run xeno-test instead of xeno-regression-test,
and see if you get acceptable latencies.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 17 January 2014 12:53, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> It looks ok, you should run xeno-test instead of xeno-regression-test,
> and see if you get acceptable latencies.


Unfortunately not. Opening a web browser pushed latency up to > 1000 uS.


RTD|      8.313|     15.106|     28.199|       0|     0|      4.249|     31.477
RTD|      7.989|     15.181|     29.255|       0|     0|      4.249|     31.477
RTD|      3.722|     14.727|     32.093|       0|     0|      3.722|     32.093
RTD|      4.484|     16.202|    401.648|       0|     0|      3.722|    401.648
RTD|      8.078|     19.323|     57.929|       0|     0|      3.722|    401.648
RTD|      4.191|     16.343|     31.941|       0|     0|      3.722|    401.648
RTD|      7.169|     16.787|     41.795|       0|     0|      3.722|    401.648
RTD|      8.707|     16.669|     39.275|       0|     0|      3.722|    401.648
RTD|      4.636|     17.320|     37.303|       0|     0|      3.722|    401.648
RTD|      8.406|     17.563|     59.111|       0|     0|      3.722|    401.648
RTD|      9.330|     17.797|     33.752|       0|     0|      3.722|    401.648
RTD|      8.282|     18.666|     46.007|       0|     0|      3.722|    401.648
RTD|      3.891|     17.876|     37.727|       0|     0|      3.722|    401.648
RTD|      9.146|     18.017|     46.752|       0|     0|      3.722|    401.648
RTD|      8.560|     19.330|     48.441|       0|     0|      3.722|    401.648
RTD|      3.909|     19.694|    314.227|       0|     0|      3.722|    401.648
RTD|      4.891|     20.189|    220.487|       0|     0|      3.722|    401.648
RTD|      4.255|     22.742|    755.479|       0|     0|      3.722|    755.479
RTD|      3.661|     16.012|     30.378|       0|     0|      3.661|    755.479
RTD|      3.828|     21.252|    646.782|       0|     0|      3.661|    755.479
RTD|      3.800|     16.906|     34.547|       0|     0|      3.661|    755.479
RTD|      6.424|     16.856|     33.719|       0|     0|      3.661|    755.479
RTD|      8.373|     23.015|    662.608|       0|     0|      3.661|    755.479
RTD|      3.654|     17.161|     33.628|       0|     0|      3.654|    755.479
RTD|      4.378|     20.598|   1260.792|       1|     0|      3.654|   1260.792


-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/18/2014 08:49 PM, Andy Pugh wrote:
> On 17 January 2014 12:53, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> It looks ok, you should run xeno-test instead of xeno-regression-test,
>> and see if you get acceptable latencies.
> 
> 
> Unfortunately not. Opening a web browser pushed latency up to > 1000 uS.

It is an imx6, right? Could you try ton run the X server without
acceleration (using the fbdev driver)?

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 18 January 2014 12:43, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> It is an imx6, right? Could you try ton run the X server without
> acceleration (using the fbdev driver)?

That does look a lot more promising:

RTT|  00:00:43  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      6.404|     13.219|     42.202|       0|     0|      1.709|     44.921
RTD|      3.856|     14.416|     46.916|       0|     0|      1.709|     46.916
RTD|      3.765|     15.383|     36.954|       0|     0|      1.709|     46.916
RTD|      2.939|     15.292|     40.489|       0|     0|      1.709|     46.916
RTD|      2.886|     15.669|     75.785|       0|     0|      1.709|     75.785
RTD|      3.679|     15.752|     42.689|       0|     0|      1.709|     75.785
RTD|      4.585|     17.161|     47.861|       0|     0|      1.709|     75.785
RTD|      4.590|     16.749|     46.838|       0|     0|      1.709|     75.785
RTD|      3.343|     14.154|     28.101|       0|     0|      1.709|     75.785
RTD|      3.323|     16.641|     48.358|       0|     0|      1.709|     75.785

The 75uS was the point where I opened a web browser. Running glxgears
seemed to have no effect at all

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/18/2014 11:31 PM, Andy Pugh wrote:
> On 18 January 2014 12:43, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> It is an imx6, right? Could you try ton run the X server without
>> acceleration (using the fbdev driver)?
> 
> That does look a lot more promising:
> 
> RTT|  00:00:43  (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD|      6.404|     13.219|     42.202|       0|     0|      1.709|     44.921
> RTD|      3.856|     14.416|     46.916|       0|     0|      1.709|     46.916
> RTD|      3.765|     15.383|     36.954|       0|     0|      1.709|     46.916
> RTD|      2.939|     15.292|     40.489|       0|     0|      1.709|     46.916
> RTD|      2.886|     15.669|     75.785|       0|     0|      1.709|     75.785
> RTD|      3.679|     15.752|     42.689|       0|     0|      1.709|     75.785
> RTD|      4.585|     17.161|     47.861|       0|     0|      1.709|     75.785
> RTD|      4.590|     16.749|     46.838|       0|     0|      1.709|     75.785
> RTD|      3.343|     14.154|     28.101|       0|     0|      1.709|     75.785
> RTD|      3.323|     16.641|     48.358|       0|     0|      1.709|     75.785
> 
> The 75uS was the point where I opened a web browser. Running glxgears
> seemed to have no effect at all

75uS still looks like a lot for a cortex A9, how many cores does it have?

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 18 January 2014 15:24, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> 75uS still looks like a lot for a cortex A9, how many cores does it have?

4 cores.

With RTAI there is something to be gained from running the realtime
threads on a dedicated core. Does that work with Xenomai too?
(The only reason I haven't tried it is that it is a grub option, and I
don't think the Udoo board is using grub)

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Paul]

On Saturday 18 January 2014, Andy Pugh wrote:
> (The only reason I haven't tried it is that it is a grub option, and
> I don't think the Udoo board is using grub)

isolcpus is not a "grub option", it is a kernel argument passed by the 
boot manager. For most ARM systems, this will be u-boot, in which case 
I'd suggest you go and read the section on bootargs in the u-boot 
manual.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/18/2014 11:31 PM, Andy Pugh wrote:
> On 18 January 2014 12:43, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> It is an imx6, right? Could you try ton run the X server without
>> acceleration (using the fbdev driver)?
> 
> That does look a lot more promising:
> 
> RTT|  00:00:43  (periodic user-mode task, 1000 us period, priority 99)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD|      6.404|     13.219|     42.202|       0|     0|      1.709|     44.921
> RTD|      3.856|     14.416|     46.916|       0|     0|      1.709|     46.916
> RTD|      3.765|     15.383|     36.954|       0|     0|      1.709|     46.916
> RTD|      2.939|     15.292|     40.489|       0|     0|      1.709|     46.916
> RTD|      2.886|     15.669|     75.785|       0|     0|      1.709|     75.785
> RTD|      3.679|     15.752|     42.689|       0|     0|      1.709|     75.785
> RTD|      4.585|     17.161|     47.861|       0|     0|      1.709|     75.785
> RTD|      4.590|     16.749|     46.838|       0|     0|      1.709|     75.785
> RTD|      3.343|     14.154|     28.101|       0|     0|      1.709|     75.785
> RTD|      3.323|     16.641|     48.358|       0|     0|      1.709|     75.785
> 
> The 75uS was the point where I opened a web browser. Running glxgears
> seemed to have no effect at all
> 
BTW, you should wait a bit more than 43 seconds to hope having a good 
approximation of the worst case. Using LTP is recommended.

Could you try the following patch to see if it improves anything?

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d9cb476..fe177c8 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -41,7 +41,7 @@ static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
 {
 	/* wait for cache operation by line or way to complete */
 	while (readl_relaxed(reg) & mask)
-		;
+		cpu_relax();
 }
 
 #ifdef CONFIG_CACHE_PL310
@@ -136,6 +136,7 @@ static void __l2x0_flush_all(void)
 	debug_writel(0x00);
 }
 
+#ifndef CONFIG_IPIPE
 static void l2x0_flush_all(void)
 {
 	unsigned long flags;
@@ -145,6 +146,51 @@ static void l2x0_flush_all(void)
 	__l2x0_flush_all();
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
+#else
+static void l2x0_clean_line_idx(unsigned line, unsigned way)
+{
+	void __iomem *base = l2x0_base;
+
+	writel_relaxed((way << 28) | (line << 5), base + L2X0_CLEAN_LINE_IDX);
+	cache_wait(base + L2X0_CLEAN_LINE_IDX, 1);
+}
+
+static void l2x0_flush_way(unsigned way, unsigned len, unsigned lines)
+{
+	unsigned long flags;
+	unsigned line, i;
+	
+	for (line = 0; line < lines; line += len ) {
+		spin_lock_irqsave(&l2x0_lock, flags);
+		debug_writel(0x03);
+		for (i = 0; i < len && line + i < lines; i++)
+			l2x0_clean_line_idx(line + i, way);
+		cache_sync();
+		debug_writel(0x00);
+		spin_unlock_irqrestore(&l2x0_lock, flags);
+	}
+
+	spin_lock_irqsave(&l2x0_lock, flags);
+	debug_writel(0x03);
+	writel_relaxed((1 << way), l2x0_base + L2X0_CLEAN_WAY);
+	cache_wait_way(l2x0_base + L2X0_CLEAN_WAY, (1 << way));
+	cache_sync();
+	debug_writel(0x00);
+	spin_unlock_irqrestore(&l2x0_lock, flags);
+}
+
+static void l2x0_flush_all(void)
+{
+	unsigned lines, len, way, ways;
+
+	ways = fls(l2x0_way_mask);
+	lines = l2x0_size / (ways * CACHE_LINE_SIZE);
+	len = L2X0_SPINLOCK_LEN / CACHE_LINE_SIZE;
+
+	for (way = 0; way < ways; way++)
+		l2x0_flush_way(way, len, lines);
+}
+#endif
 
 static void l2x0_clean_all(void)
 {


-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/19/2014 01:33 PM, Gilles Chanteperdrix wrote:
> On 01/18/2014 11:31 PM, Andy Pugh wrote:
>> On 18 January 2014 12:43, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> It is an imx6, right? Could you try ton run the X server without
>>> acceleration (using the fbdev driver)?
>>
>> That does look a lot more promising:
>>
>> RTT|  00:00:43  (periodic user-mode task, 1000 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>> RTD|      6.404|     13.219|     42.202|       0|     0|      1.709|     44.921
>> RTD|      3.856|     14.416|     46.916|       0|     0|      1.709|     46.916
>> RTD|      3.765|     15.383|     36.954|       0|     0|      1.709|     46.916
>> RTD|      2.939|     15.292|     40.489|       0|     0|      1.709|     46.916
>> RTD|      2.886|     15.669|     75.785|       0|     0|      1.709|     75.785
>> RTD|      3.679|     15.752|     42.689|       0|     0|      1.709|     75.785
>> RTD|      4.585|     17.161|     47.861|       0|     0|      1.709|     75.785
>> RTD|      4.590|     16.749|     46.838|       0|     0|      1.709|     75.785
>> RTD|      3.343|     14.154|     28.101|       0|     0|      1.709|     75.785
>> RTD|      3.323|     16.641|     48.358|       0|     0|      1.709|     75.785
>>
>> The 75uS was the point where I opened a web browser. Running glxgears
>> seemed to have no effect at all
>>
> BTW, you should wait a bit more than 43 seconds to hope having a good 
> approximation of the worst case. Using LTP is recommended.
> 
> Could you try the following patch to see if it improves anything?

Sorry, wrong patch version. Please try this one instead:

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d9cb476..1e2c52d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -41,7 +41,7 @@ static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
 {
 	/* wait for cache operation by line or way to complete */
 	while (readl_relaxed(reg) & mask)
-		;
+		cpu_relax();
 }
 
 #ifdef CONFIG_CACHE_PL310
@@ -136,6 +136,7 @@ static void __l2x0_flush_all(void)
 	debug_writel(0x00);
 }
 
+#ifndef CONFIG_IPIPE
 static void l2x0_flush_all(void)
 {
 	unsigned long flags;
@@ -157,6 +158,81 @@ static void l2x0_clean_all(void)
 	cache_sync();
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
+#else
+static void l2x0_clean_inv_line_idx(unsigned line, unsigned way)
+{
+	void __iomem *base = l2x0_base;
+
+	writel_relaxed((way << 28) | (line << 5), 
+		base + L2X0_CLEAN_INV_LINE_IDX);
+	cache_wait(base + L2X0_CLEAN_INV_LINE_IDX, 1);
+}
+
+static void l2x0_flush_way(unsigned way, unsigned len, unsigned lines)
+{
+	unsigned long flags;
+	unsigned line, i;
+	
+	for (line = 0; line < lines; line += len ) {
+		spin_lock_irqsave(&l2x0_lock, flags);
+		debug_writel(0x03);
+		for (i = 0; i < len && line + i < lines; i++)
+			l2x0_clean_inv_line_idx(line + i, way);
+		cache_sync();
+		debug_writel(0x00);
+		spin_unlock_irqrestore(&l2x0_lock, flags);
+	}
+}
+
+static void l2x0_flush_all(void)
+{
+	unsigned lines, len, way, ways;
+
+	ways = fls(l2x0_way_mask);
+	lines = l2x0_size / (ways * CACHE_LINE_SIZE);
+	len = L2X0_SPINLOCK_LEN / CACHE_LINE_SIZE;
+
+	for (way = 0; way < ways; way++)
+		l2x0_flush_way(way, len, lines);
+}
+
+static void l2x0_clean_line_idx(unsigned line, unsigned way)
+{
+	void __iomem *base = l2x0_base;
+
+	writel_relaxed((way << 28) | (line << 5), 
+		base + L2X0_CLEAN_LINE_IDX);
+	cache_wait(base + L2X0_CLEAN_LINE_IDX, 1);
+}
+
+static void l2x0_clean_way(unsigned way, unsigned len, unsigned lines)
+{
+	unsigned long flags;
+	unsigned line, i;
+	
+	for (line = 0; line < lines; line += len ) {
+		spin_lock_irqsave(&l2x0_lock, flags);
+		debug_writel(0x03);
+		for (i = 0; i < len && line + i < lines; i++)
+			l2x0_clean_line_idx(line + i, way);
+		cache_sync();
+		debug_writel(0x00);
+		spin_unlock_irqrestore(&l2x0_lock, flags);
+	}
+}
+
+static void l2x0_clean_all(void)
+{
+	unsigned lines, len, way, ways;
+
+	ways = fls(l2x0_way_mask);
+	lines = l2x0_size / (ways * CACHE_LINE_SIZE);
+	len = L2X0_SPINLOCK_LEN / CACHE_LINE_SIZE;
+
+	for (way = 0; way < ways; way++)
+		l2x0_clean_way(way, len, lines);
+}
+#endif
 
 static void l2x0_inv_all(void)
 {
-- 
1.7.10.4



-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 19 January 2014 13:42, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

>> Could you try the following patch to see if it improves anything?
>
> Sorry, wrong patch version. Please try this one instead:

The patch appears to reduce the latency to about 60uS.

I thought that setenv isolcpus=0 had had an effect, as I opened
Firefox and didn't see max latency increase over the 45uS it was at,
but then opening Chromium too pushed it up to 60uS.

Does Xenomai automatically choose the isolated CPU, or is some config needed?

In fact, how do I tell that I have an isolated CPU?

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 01:05 AM, Andy Pugh wrote:
> On 19 January 2014 13:42, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>>> Could you try the following patch to see if it improves anything?
>>
>> Sorry, wrong patch version. Please try this one instead:
> 
> The patch appears to reduce the latency to about 60uS.
> 
> I thought that setenv isolcpus=0 had had an effect, as I opened
> Firefox and didn't see max latency increase over the 45uS it was at,
> but then opening Chromium too pushed it up to 60uS.
> 
> Does Xenomai automatically choose the isolated CPU, or is some config needed?
> 
> In fact, how do I tell that I have an isolated CPU?

Use the xeno_hal.supported_cpus parameter, it is a bitfield, so 1 is for
cpu 0.

There is more we can do to improve performances on imx6:
- enable more features in the L2 cache auxiliary control register (the
value of this register is passed to the l2x0_init function, and
currently imx6 passes all 0)
- use the L2 cache "lockdown by master" feature, to reserve several
cache ways to the core where xenomai runs.

l2x0_init prints the value of the auxiliary control register at boot,
could you show me the boot logs you get to see which bits exactly are
already enabled?

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 31 January 2014 09:24, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> Use the xeno_hal.supported_cpus parameter, it is a bitfield, so 1 is for
> cpu 0.

I have tried this, but I am not sure how to tell if it is working.

The Udoo board seems a bit strange. The only way I have found to use
setenv is to connect via a serial terminal and interrupt the boot
sequence. At that point setenv / printenv work (this is also what is
suggested in the Udoo docs).
printenv shows:

boot_fdt=try
bootargs=isolcpus=0
bootcmd=mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript;
then run bootscript; else if run loaduimage; then run mmcboot; else
run netboot; fi; fi; else run netboot; fi

and

update_sd_firmware_filename=u-boot.imx
xeno_hal.supported_cpus=1
Environment size: 2097/8188 bytes

However dmesg contains:

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 227328
[    0.000000] Kernel command line: console=ttymxc1,115200
root=/dev/mmcblk0p1 rootwait rw fbmem=24M
video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)

and cat /proc/cmdline returns:

andypugh@udoo:~$ cat /proc/cmdline
console=ttymxc1,115200 root=/dev/mmcblk0p1 rootwait rw fbmem=24M
video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32

So I suspect that there is more to adding to the kernel command line
than a simple "setenv" in this case. (I also suspect that this is a
question for the Udoo forums rather than Xenomai)

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 06:48 PM, Andy Pugh wrote:
> On 31 January 2014 09:24, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>
>> Use the xeno_hal.supported_cpus parameter, it is a bitfield, so 1 is for
>> cpu 0.
>
> I have tried this, but I am not sure how to tell if it is working.
>
> The Udoo board seems a bit strange. The only way I have found to use
> setenv is to connect via a serial terminal and interrupt the boot
> sequence. At that point setenv / printenv work (this is also what is
> suggested in the Udoo docs).
> printenv shows:
>
> boot_fdt=try
> bootargs=isolcpus=0
> bootcmd=mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript;
> then run bootscript; else if run loaduimage; then run mmcboot; else
> run netboot; fi; fi; else run netboot; fi
>
> and
>
> update_sd_firmware_filename=u-boot.imx
> xeno_hal.supported_cpus=1
> Environment size: 2097/8188 bytes
>
> However dmesg contains:
>
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 227328
> [    0.000000] Kernel command line: console=ttymxc1,115200
> root=/dev/mmcblk0p1 rootwait rw fbmem=24M
> video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
>
> and cat /proc/cmdline returns:
>
> andypugh@udoo:~$ cat /proc/cmdline
> console=ttymxc1,115200 root=/dev/mmcblk0p1 rootwait rw fbmem=24M
> video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32
>
> So I suspect that there is more to adding to the kernel command line
> than a simple "setenv" in this case. (I also suspect that this is a
> question for the Udoo forums rather than Xenomai)
>

xeno_hal.supported_cpus=1 is a kernel argument, thus it should be added 
to the boot arguments, like isolcpus. Since you do not see isolcpus on 
the kernel command line, I guess the loadbootcscript, bootscript, 
loaduimage, mmcboot or netboot script overrides the boot arguments. If 
you are booting from SD card, maybe you can find the script on the SD 
card itself?

I am afraid this is off-topic on this mailing list.

-- 
					    Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 31 January 2014 18:00, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> I am afraid this is off-topic on this mailing list.

OK, thanks.

I will just say that, having figured out how to set the command line
parameters (I needed a serial terminal that did actual terminal
emulation, and I needed to edit a non-standard environment file) I
seem to be able to isolate a CPU, but xeno-test fails when I also add
the supported_cpus parameter (it runs fine without the parameter):

andypugh@udoo:~$ xeno-test

Started child 3840: /bin/bash
/usr/lib/xenomai/testsuite/xeno-test-run-wrapper /usr/bin/xeno-test

++ echo 0

/usr/bin/xeno-test: line 43: /proc/xenomai/latency: Permission denied

++ :

++ /usr/lib/xenomai/testsuite/arith

mul: 0x79364d93, shft: 26

integ: 30, frac: 0x4d9364d9364d9364


signed positive operation: 0x03ffffffffffffff * 1000000000 / 33000000

inline calibration: 0x0000000000000000: 45.470 ns, rejected 1/10000

inlined llimd: 0x79364d9364d9362f: 1727.408 ns, rejected 2/10000

inlined llmulshft: 0x79364d92ffffffe1: 32.817 ns, rejected 0/10000

inlined nodiv_llimd: 0x79364d9364d9362f: 45.453 ns, rejected 0/10000

out of line calibration: 0x0000000000000000: 47.993 ns, rejected 0/10000

out of line llimd: 0x79364d9364d9362f: 1778.918 ns, rejected 3/10000

out of line llmulshft: 0x79364d92ffffffe1: 27.894 ns, rejected 0/10000

out of line nodiv_llimd: 0x79364d9364d9362f: 40.399 ns, rejected 0/10000


signed negative operation: 0xfc00000000000001 * 1000000000 / 33000000

inline calibration: 0x0000000000000000: 45.458 ns, rejected 0/10000

inlined llimd: 0x86c9b26c9b26c9d1: 1750.968 ns, rejected 3/10000

inlined llmulshft: 0xd45d172d0000001e: 22.732 ns, rejected 0/10000

inlined nodiv_llimd: 0x86c9b26c9b26c9d1: 50.516 ns, rejected 0/10000

out of line calibration: 0x0000000000000000: 70.571 ns, rejected 1/10000

out of line llimd: 0x86c9b26c9b26c9d1: 1740.908 ns, rejected 1/10000

out of line llmulshft: 0xd45d172d0000001e: 10.245 ns, rejected 0/10000

out of line nodiv_llimd: 0x86c9b26c9b26c9d1: 30.462 ns, rejected 0/10000


unsigned operation: 0x03ffffffffffffff * 1000000000 / 33000000

inline calibration: 0x0000000000000000: 45.460 ns, rejected 0/10000

inlined nodiv_ullimd: 0x79364d9364d9362f: 42.926 ns, rejected 0/10000

out of line calibration: 0x0000000000000000: 47.993 ns, rejected 0/10000

out of line nodiv_ullimd: 0x79364d9364d9362f: 40.411 ns, rejected 0/10000

++ /usr/lib/xenomai/testsuite/clocktest -C 42 -T 30

Xenomai Posix skin init: pthread_setschedparam: Invalid argument

++ /usr/lib/xenomai/testsuite/clocktest -T 30

Xenomai Posix skin init: pthread_setschedparam: Invalid argument



-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 09:15 PM, Andy Pugh wrote:
> On 31 January 2014 18:00, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> I am afraid this is off-topic on this mailing list.
> 
> OK, thanks.
> 
> I will just say that, having figured out how to set the command line
> parameters (I needed a serial terminal that did actual terminal
> emulation, and I needed to edit a non-standard environment file) I
> seem to be able to isolate a CPU, but xeno-test fails when I also add
> the supported_cpus parameter (it runs fine without the parameter):
> 
> andypugh@udoo:~$ xeno-test

Ok, let us forget about xeno-test, could you try latency -c 0 (if 0 is
the supported cpu).

What do the kernel log say? Has xenomai started correctly?

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 31 January 2014 20:19, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> latency -c 0

I thought at first that there was a huge improvement, as it was idling
at 7uS (less than half the previous idle) .
However, opening a couple of web browsers pushed it up to 44uS.

I think I will move my attention to getting LinuxCNC running on the
board now, it looks like Xenomai is working.

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 10:03 PM, Andy Pugh wrote:
> On 31 January 2014 20:19, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> latency -c 0
> 
> I thought at first that there was a huge improvement, as it was idling
> at 7uS (less than half the previous idle) .
> However, opening a couple of web browsers pushed it up to 44uS.
> 
> I think I will move my attention to getting LinuxCNC running on the
> board now, it looks like Xenomai is working.
> 
Ok, I am still interested by your kernel logs though, to see whether we
can improve the latencies by using the cache auxiliary configuration
register. You may want to lockdown some L2 cache ways for CPU0 as well,
in order to avoid the non-realtime cores to interfere with the real-time
core cache.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 31 January 2014 21:07, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> Ok, I am still interested by your kernel logs though, to see whether we
> can improve the latencies by using the cache auxiliary configuration
> register.

Is this what you need, or do you need Xenomai actually active?

http://pastebin.com/PSKwQH3A


-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 11:58 PM, Andy Pugh wrote:
> On 31 January 2014 21:07, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Ok, I am still interested by your kernel logs though, to see whether we
>> can improve the latencies by using the cache auxiliary configuration
>> register.
> 
> Is this what you need, or do you need Xenomai actually active?
> 
> http://pastebin.com/PSKwQH3A
> 
> 
That is all I needed, thanks.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 11:58 PM, Andy Pugh wrote:
> On 31 January 2014 21:07, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Ok, I am still interested by your kernel logs though, to see whether we
>> can improve the latencies by using the cache auxiliary configuration
>> register.
> 
> Is this what you need, or do you need Xenomai actually active?
> 
> http://pastebin.com/PSKwQH3A

Could you try and apply the following patch?

When you are booted, try dmesg | grep AUX_CTRL, then run a latency test
and see if latency has improved?

Regards.

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index bfa706ff..bd3c8ce 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -61,7 +61,7 @@
 #define L2X0_CACHE_ID_PART_L210		(1 << 6)
 #define L2X0_CACHE_ID_PART_L310		(3 << 6)
 
-#define L2X0_AUX_CTRL_MASK			0xc0000fff
+#define L2X0_AUX_CTRL_MASK			0xc00007ff
 #define L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT	16
 #define L2X0_AUX_CTRL_WAY_SIZE_SHIFT		17
 #define L2X0_AUX_CTRL_WAY_SIZE_MASK		(0x7 << 17)
diff --git a/arch/arm/mach-mx6/mm.c b/arch/arm/mach-mx6/mm.c
index 3cf6b22..cec64b6 100644
--- a/arch/arm/mach-mx6/mm.c
+++ b/arch/arm/mach-mx6/mm.c
@@ -97,7 +97,7 @@ void __init mx6_map_io(void)
 #ifdef CONFIG_CACHE_L2X0
 int mxc_init_l2x0(void)
 {
-	unsigned int val;
+	unsigned int val, aux_ctrl;
 
 	#define IOMUXC_GPR11_L2CACHE_AS_OCRAM 0x00000002
 
@@ -114,12 +114,34 @@ int mxc_init_l2x0(void)
 	val = readl(IO_ADDRESS(L2_BASE_ADDR + L2X0_PREFETCH_CTRL));
 	val |= 0x40800000;
 	writel(val, IO_ADDRESS(L2_BASE_ADDR + L2X0_PREFETCH_CTRL));
+#ifndef CONFIG_IPIPE
 	val = readl(IO_ADDRESS(L2_BASE_ADDR + L2X0_POWER_CTRL));
 	val |= L2X0_DYNAMIC_CLK_GATING_EN;
 	val |= L2X0_STNDBY_MODE_EN;
 	writel(val, IO_ADDRESS(L2_BASE_ADDR + L2X0_POWER_CTRL));
+#endif
+
+	aux_ctrl = ((1 << L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT) |
+		(0x1 << L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT) |
+		(0x1 << L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT) |
+		(1 << L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
+		(1 << L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) |
+		(1 << L2X0_AUX_CTRL_EARLY_BRESP_SHIFT) |
+		(1 << 11));
+
+	l2x0_init(IO_ADDRESS(L2_BASE_ADDR), aux_ctrl, L2X0_AUX_CTRL_MASK);
+
+#ifdef CONFIG_IPIPE
+	writel_relaxed(0xEEEE, l2x0_base + 0x900);
+	writel_relaxed(0xEEEE, l2x0_base + 0x904);	
+	writel_relaxed(0xDDDD, l2x0_base + 0x908);
+	writel_relaxed(0xDDDD, l2x0_base + 0x90C);	
+	writel_relaxed(0xBBBB, l2x0_base + 0x910);
+	writel_relaxed(0xBBBB, l2x0_base + 0x914);	
+	writel_relaxed(0x7777, l2x0_base + 0x918);
+	writel_relaxed(0x7777, l2x0_base + 0x91C);	
+#endif
 
-	l2x0_init(IO_ADDRESS(L2_BASE_ADDR), 0x0, ~0x00000000);
 	return 0;
 }
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 1e2c52d..27550b3 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -421,6 +421,9 @@ void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 		writel_relaxed(1, l2x0_base + L2X0_CTRL);
 	}
 
+	/* Re-read it in case some bits are reserved. */
+	aux = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
+
 	outer_cache.inv_range = l2x0_inv_range;
 	outer_cache.clean_range = l2x0_clean_range;
 	outer_cache.flush_range = l2x0_flush_range;



-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 02/01/2014 02:39 PM, Gilles Chanteperdrix wrote:
> On 01/31/2014 11:58 PM, Andy Pugh wrote:
>> On 31 January 2014 21:07, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> Ok, I am still interested by your kernel logs though, to see whether we
>>> can improve the latencies by using the cache auxiliary configuration
>>> register.
>>
>> Is this what you need, or do you need Xenomai actually active?
>>
>> http://pastebin.com/PSKwQH3A
> 
> Could you try and apply the following patch?

Sorry, wrong patch again, please try:

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index bfa706ff..bd3c8ce 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -61,7 +61,7 @@
 #define L2X0_CACHE_ID_PART_L210		(1 << 6)
 #define L2X0_CACHE_ID_PART_L310		(3 << 6)
 
-#define L2X0_AUX_CTRL_MASK			0xc0000fff
+#define L2X0_AUX_CTRL_MASK			0xc00007ff
 #define L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT	16
 #define L2X0_AUX_CTRL_WAY_SIZE_SHIFT		17
 #define L2X0_AUX_CTRL_WAY_SIZE_MASK		(0x7 << 17)
diff --git a/arch/arm/mach-mx6/mm.c b/arch/arm/mach-mx6/mm.c
index 3cf6b22..185c4a9 100644
--- a/arch/arm/mach-mx6/mm.c
+++ b/arch/arm/mach-mx6/mm.c
@@ -97,7 +97,8 @@ void __init mx6_map_io(void)
 #ifdef CONFIG_CACHE_L2X0
 int mxc_init_l2x0(void)
 {
-	unsigned int val;
+	unsigned int val, aux_ctrl;
+	void __iomem *l2x0_base;
 
 	#define IOMUXC_GPR11_L2CACHE_AS_OCRAM 0x00000002
 
@@ -114,12 +115,37 @@ int mxc_init_l2x0(void)
 	val = readl(IO_ADDRESS(L2_BASE_ADDR + L2X0_PREFETCH_CTRL));
 	val |= 0x40800000;
 	writel(val, IO_ADDRESS(L2_BASE_ADDR + L2X0_PREFETCH_CTRL));
+#ifndef CONFIG_IPIPE
 	val = readl(IO_ADDRESS(L2_BASE_ADDR + L2X0_POWER_CTRL));
 	val |= L2X0_DYNAMIC_CLK_GATING_EN;
 	val |= L2X0_STNDBY_MODE_EN;
 	writel(val, IO_ADDRESS(L2_BASE_ADDR + L2X0_POWER_CTRL));
+#endif
+
+	aux_ctrl = ((1 << L2X0_AUX_CTRL_ASSOCIATIVITY_SHIFT) |
+		(0x1 << L2X0_AUX_CTRL_NS_LOCKDOWN_SHIFT) |
+		(0x1 << L2X0_AUX_CTRL_NS_INT_CTRL_SHIFT) |
+		(1 << L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
+		(1 << L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) |
+		(1 << L2X0_AUX_CTRL_EARLY_BRESP_SHIFT) |
+		(1 << 11));
+
+	l2x0_base = IO_ADDRESS(L2_BASE_ADDR);
+
+	l2x0_init(l2x0_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
+
+#ifdef CONFIG_IPIPE
+	{
+	writel_relaxed(0xEEEE, l2x0_base + 0x900);
+	writel_relaxed(0xEEEE, l2x0_base + 0x904);	
+	writel_relaxed(0xDDDD, l2x0_base + 0x908);
+	writel_relaxed(0xDDDD, l2x0_base + 0x90C);	
+	writel_relaxed(0xBBBB, l2x0_base + 0x910);
+	writel_relaxed(0xBBBB, l2x0_base + 0x914);	
+	writel_relaxed(0x7777, l2x0_base + 0x918);
+	writel_relaxed(0x7777, l2x0_base + 0x91C);	
+#endif
 
-	l2x0_init(IO_ADDRESS(L2_BASE_ADDR), 0x0, ~0x00000000);
 	return 0;
 }
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 1e2c52d..27550b3 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -421,6 +421,9 @@ void l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 		writel_relaxed(1, l2x0_base + L2X0_CTRL);
 	}
 
+	/* Re-read it in case some bits are reserved. */
+	aux = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
+
 	outer_cache.inv_range = l2x0_inv_range;
 	outer_cache.clean_range = l2x0_clean_range;
 	outer_cache.flush_range = l2x0_flush_range;

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 1 February 2014 13:49, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
>
>>> http://pastebin.com/PSKwQH3A
>>
>> Could you try and apply the following patch?
>
> Sorry, wrong patch again, please try:

Sorry, but my mail software is not playing nice with patches (gmail
simply doesn't save to text, and the "real" mailer seems to do odd
things too.
Is it possible that you could attach the patch as an attachment?

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 02/02/2014 10:53 PM, Andy Pugh wrote:
> On 1 February 2014 13:49, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>>>> http://pastebin.com/PSKwQH3A
>>>
>>> Could you try and apply the following patch?
>>
>> Sorry, wrong patch again, please try:
> 
> Sorry, but my mail software is not playing nice with patches (gmail
> simply doesn't save to text, and the "real" mailer seems to do odd
> things too.
> Is it possible that you could attach the patch as an attachment?
> 
Available here:

http://sisyphus.hd.free.fr/~gilles/mx6.patch

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 02/02/2014 10:59 PM, Gilles Chanteperdrix wrote:
> On 02/02/2014 10:53 PM, Andy Pugh wrote:
>> On 1 February 2014 13:49, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>
>>>>> http://pastebin.com/PSKwQH3A
>>>>
>>>> Could you try and apply the following patch?
>>>
>>> Sorry, wrong patch again, please try:
>>
>> Sorry, but my mail software is not playing nice with patches (gmail
>> simply doesn't save to text, and the "real" mailer seems to do odd
>> things too.
>> Is it possible that you could attach the patch as an attachment?
>>
> Available here:
> 
> http://sisyphus.hd.free.fr/~gilles/mx6.patch
> 
Please try again, the patch could not compile for mx6. It should be
fixed now.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

>>>>> Could you try and apply the following patch?


Not necessarily due to the patch, but first reboot was:



[    0.000000] Initializing cgroup subsys cpu

[    0.000000] Linux version 3.0.35-Xenomai-g7cce9fa-dirty
(andypugh@udoo) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
#17 SMP PREEMPT Sun Feb 2 23:51:15 UTC 2014

[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d

[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Machine: SECO i.Mx6 UDOO Board

[    0.000000] Kernel ver: v. 112

[    0.000000] Memory policy: ECC disabled, Data cache writealloc

[    0.000000] CPU identified as i.MX6Q, silicon rev 1.2

[    0.000000] PERCPU: Embedded 10 pages/cpu @8c008000 s16704 r8192
d16064 u40960

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 227328

[    0.000000] Kernel command line: console=ttymxc1,115200
root=/dev/mmcblk0p1 rootwait rw fbmem=24M
video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32 isolcpus=3
xeno_hal.supported_cpus=8

[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)

[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

[    0.000000] Memory: 640MB 256MB = 896MB total

[    0.000000] Memory: 895084k/895084k available, 153492k reserved, 0K highmem

[    0.000000] Virtual kernel memory layout:

[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[    0.000000]     DMA     : 0xf4600000 - 0xffe00000   ( 184 MB)

[    0.000000]     vmalloc : 0xc0800000 - 0xf2000000   ( 792 MB)

[    0.000000]     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)

[    0.000000]     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)

[    0.000000]     modules : 0x7f000000 - 0x7fe00000   (  14 MB)

[    0.000000]       .init : 0x80008000 - 0x8003d000   ( 212 kB)

[    0.000000]       .text : 0x8003d000 - 0x80c01b18   (12051 kB)

[    0.000000]       .data : 0x80c02000 - 0x80c6f480   ( 438 kB)

[    0.000000]        .bss : 0x80c6f4a4 - 0x80cee2a0   ( 508 kB)

[    0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0,
CPUs=4, Nodes=1

[    0.000000] Preemptible hierarchical RCU implementation.

[    0.000000] NR_IRQS:624

[    0.000000] MXC GPIO hardware

[    0.000000] sched_clock: 32 bits at 3000kHz, resolution 333ns,
wraps every 1431655ms

[    0.000000] arm_max_freq=1GHz

[    0.000000] MXC_Early serial console at MMIO 0x21e8000 (options '115200')

[    0.000000] bootconsole [ttymxc1] enabled

[    0.000000] I-pipe 1.18-13: pipeline enabled.

[    0.000000] Console: colour dummy device 80x30

[    0.230711] Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)

[    0.319069] pid_max: default: 32768 minimum: 301

[    0.324038] Mount-cache hash table entries: 512

[    0.329474] Initializing cgroup subsys cpuacct

[    0.333988] Initializing cgroup subsys devices

[    0.338451] Initializing cgroup subsys freezer

[    0.342948] Initializing cgroup subsys blkio

[    0.347298] CPU: Testing write buffer coherency: ok

[    0.352421] I-pipe, 396.000 MHz timer

[    0.356166] I-pipe, 396.000 MHz clocksource

[    0.360416] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver,
7 counters available

[    0.466819] CPU1: Booted secondary processor

[    0.596831] CPU2: Booted secondary processor

[    0.726868] CPU3: Booted secondary processor

[    0.816237] Brought up 4 CPUs

[    0.832073] SMP: Total of 4 processors activated (6324.22 BogoMIPS).

[    0.838961] devtmpfs: initialized

[    0.862022] print_constraints: dummy:

[    0.865994] NET: Registered protocol family 16

[    0.875471] print_constraints: vddpu: 725 <--> 1300 mV at 1150 mV fast normal

[    0.883099] print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV
fast normal

[    0.890884] print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV
fast normal

[    0.898626] print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV
fast normal

[    0.906454] print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV
fast normal

[    0.914128] print_constraints: vdd3p0: 2625 <--> 3400 mV at 3000 mV
fast normal

[    0.923481]

[    0.923488] > UDOO quad

[    0.927288] > rev C Called set_gpios_direction

[    0.931949] Test and set gpios directions and values by Gionji
feat. Ekirei test

[    0.967109] Resetting ethernet physical layer.

[    1.013860] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.

[    1.020702] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint
single-step.

[    1.028069] hw-breakpoint: maximum watchpoint size is 4 bytes.

[    1.033947] L310 cache controller enabled

[    1.036215] Internal error: Oops - bad syscall: 80c1cae0 [#1] PREEMPT SMP

[    1.036237] U








And then the second was (oddly) different, but not more succesful:







[    0.000000] Initializing cgroup subsys cpu

[    0.000000] Linux version 3.0.35-Xenomai-g7cce9fa-dirty
(andypugh@udoo) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) )
#17 SMP PREEMPT Sun Feb 2 23:51:15 UTC 2014

[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d

[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

[    0.000000] Machine: SECO i.Mx6 UDOO Board

[    0.000000] Kernel ver: v. 112

[    0.000000] Memory policy: ECC disabled, Data cache writealloc

[    0.000000] CPU identified as i.MX6Q, silicon rev 1.2

[    0.000000] PERCPU: Embedded 10 pages/cpu @8c008000 s16704 r8192
d16064 u40960

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 227328

[    0.000000] Kernel command line: console=ttymxc1,115200
root=/dev/mmcblk0p1 rootwait rw fbmem=24M
video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32 isolcpus=3
xeno_hal.supported_cpus=8

[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)

[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

[    0.000000] Memory: 640MB 256MB = 896MB total

[    0.000000] Memory: 895084k/895084k available, 153492k reserved, 0K highmem

[    0.000000] Virtual kernel memory layout:

[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)

[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)

[    0.000000]     DMA     : 0xf4600000 - 0xffe00000   ( 184 MB)

[    0.000000]     vmalloc : 0xc0800000 - 0xf2000000   ( 792 MB)

[    0.000000]     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)

[    0.000000]     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)

[    0.000000]     modules : 0x7f000000 - 0x7fe00000   (  14 MB)

[    0.000000]       .init : 0x80008000 - 0x8003d000   ( 212 kB)

[    0.000000]       .text : 0x8003d000 - 0x80c01b18   (12051 kB)

[    0.000000]       .data : 0x80c02000 - 0x80c6f480   ( 438 kB)

[    0.000000]        .bss : 0x80c6f4a4 - 0x80cee2a0   ( 508 kB)

[    0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0,
CPUs=4, Nodes=1

[    0.000000] Preemptible hierarchical RCU implementation.

[    0.000000] NR_IRQS:624

[    0.000000] MXC GPIO hardware

[    0.000000] sched_clock: 32 bits at 3000kHz, resolution 333ns,
wraps every 1431655ms

[    0.000000] arm_max_freq=1GHz

[    0.000000] MXC_Early serial console at MMIO 0x21e8000 (options '115200')

[    0.000000] bootconsole [ttymxc1] enabled

[    0.000000] I-pipe 1.18-13: pipeline enabled.

[    0.000000] Console: colour dummy device 80x30

[    0.230714] Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280)

[    0.319071] pid_max: default: 32768 minimum: 301

[    0.324038] Mount-cache hash table entries: 512

[    0.329470] Initializing cgroup subsys cpuacct

[    0.333987] Initializing cgroup subsys devices

[    0.338448] Initializing cgroup subsys freezer

[    0.342946] Initializing cgroup subsys blkio

[    0.347294] CPU: Testing write buffer coherency: ok

[    0.352416] I-pipe, 396.000 MHz timer

[    0.356163] I-pipe, 396.000 MHz clocksource

[    0.360412] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver,
7 counters available

[    0.466810] CPU1: Booted secondary processor

[    0.596827] CPU2: Booted secondary processor

[    0.726861] CPU3: Booted secondary processor

[    0.816232] Brought up 4 CPUs

[    0.832067] SMP: Total of 4 processors activated (6324.22 BogoMIPS).

[    0.838976] devtmpfs: initialized

[    0.862135] print_constraints: dummy:

[    0.866106] NET: Registered protocol family 16

[    0.875593] print_constraints: vddpu: 725 <--> 1300 mV at 1150 mV fast normal

[    0.883222] print_constraints: vddcore: 725 <--> 1300 mV at 1150 mV
fast normal

[    0.891005] print_constraints: vddsoc: 725 <--> 1300 mV at 1200 mV
fast normal

[    0.898753] print_constraints: vdd2p5: 2000 <--> 2775 mV at 2400 mV
fast normal

[    0.906629] print_constraints: vdd1p1: 800 <--> 1400 mV at 1100 mV
fast normal

[    0.914306] print_constraints: vdd3p0: 2625 <--> 3400 mV at 3000 mV
fast normal

[    0.923666]

[    0.923673] > UDOO quad

[    0.927473] > rev C Called set_gpios_direction

[    0.932136] Test and set gpios directions and values by Gionji
feat. Ekirei test

[    0.967019] Resetting ethernet physical layer.

[    1.013832] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.

[    1.020676] hw-breakpoint: 1 breakpoint(s) reserved for watchpoint
single-step.

[    1.028043] hw-breakpoint: maximum watchpoint size is 4 bytes.

[    1.033923] L310 cache controller enabled

[    1.036208] Unable to handle kernel NULL pointer dereference at
virtual address 00000000

[



Now, where did I leave that bootable kernel?

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 02/03/2014 01:25 AM, Andy Pugh wrote:
>>>>>> Could you try and apply the following patch?
> 
> 
> Not necessarily due to the patch, but first reboot was:
> 
> (...)
>
> Now, where did I leave that bootable kernel?
> 

The issue you have seems clearly related to the cache initialization,
it happens a little after the cache initialization. So, the patch is
probably the culprit.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 02/03/2014 01:25 AM, Andy Pugh wrote:
> Now, where did I leave that bootable kernel?
> 

Hi Andy.

Another imx6 user reported that disabling the cache "write-allocate" did
improve performances tremendously, I just tried on omap4, and latencies
seem to improve. So, this looks like the solution.

The patch you will find here:
http://sisyphus.hd.free.fr/~gilles/mx6.patch

Disables "write-allocate" for imx6 using the L2 cache controller
auxiliary register bits 23 and 24.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

On 4 February 2014 21:38, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:

> The patch you will find here:
> http://sisyphus.hd.free.fr/~gilles/mx6.patch

It's too late to try it now (I need to get the board booting again
first) but I should be able to get back to it on Thursday

-- 
atp

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 09:15 PM, Andy Pugh wrote:
> I will just say that, having figured out how to set the command line
> parameters (I needed a serial terminal that did actual terminal
> emulation, and I needed to edit a non-standard environment file)

U-boot is the de-factor standard for booting Linux on anything else than
an x86. So, the effort is probably not a complete waste: you will not
have to learn how to use U-boot for the next embedded board. Besides,
U-boot is well documented.

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Lennart Sorensen]

On Fri, Jan 31, 2014 at 09:21:09PM +0100, Gilles Chanteperdrix wrote:
> U-boot is the de-factor standard for booting Linux on anything else than
> an x86. So, the effort is probably not a complete waste: you will not
> have to learn how to use U-boot for the next embedded board. Besides,
> U-boot is well documented.

grub2 is used on a fair number of systems other than x86 too.

For embedded systems u-boot is very common though.

-- 
Len Sorensen

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Gilles Chanteperdrix]

On 01/31/2014 09:46 PM, Lennart Sorensen wrote:
> On Fri, Jan 31, 2014 at 09:21:09PM +0100, Gilles Chanteperdrix wrote:
>> U-boot is the de-factor standard for booting Linux on anything else than
>> an x86. So, the effort is probably not a complete waste: you will not
>> have to learn how to use U-boot for the next embedded board. Besides,
>> U-boot is well documented.
> 
> grub2 is used on a fair number of systems other than x86 too.
> 
> For embedded systems u-boot is very common though.

I stand corrected, I should have said "U-boot is the de-facto standard
for booting Linux on embedded boards".

-- 
                                                                Gilles.

Re: [Xenomai] Fwd: Kernel Compilation Problems

[Andy Pugh]

I am skiing all this week, I will try the patch on my return, thanks.

On 19 January 2014 13:33, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 01/18/2014 11:31 PM, Andy Pugh wrote:
>> On 18 January 2014 12:43, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>
>>> It is an imx6, right? Could you try ton run the X server without
>>> acceleration (using the fbdev driver)?
>>
>> That does look a lot more promising:
>>
>> RTT|  00:00:43  (periodic user-mode task, 1000 us period, priority 99)
>> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
>> RTD|      6.404|     13.219|     42.202|       0|     0|      1.709|     44.921
>> RTD|      3.856|     14.416|     46.916|       0|     0|      1.709|     46.916
>> RTD|      3.765|     15.383|     36.954|       0|     0|      1.709|     46.916
>> RTD|      2.939|     15.292|     40.489|       0|     0|      1.709|     46.916
>> RTD|      2.886|     15.669|     75.785|       0|     0|      1.709|     75.785
>> RTD|      3.679|     15.752|     42.689|       0|     0|      1.709|     75.785
>> RTD|      4.585|     17.161|     47.861|       0|     0|      1.709|     75.785
>> RTD|      4.590|     16.749|     46.838|       0|     0|      1.709|     75.785
>> RTD|      3.343|     14.154|     28.101|       0|     0|      1.709|     75.785
>> RTD|      3.323|     16.641|     48.358|       0|     0|      1.709|     75.785
>>
>> The 75uS was the point where I opened a web browser. Running glxgears
>> seemed to have no effect at all
>>
> BTW, you should wait a bit more than 43 seconds to hope having a good
> approximation of the worst case. Using LTP is recommended.
>
> Could you try the following patch to see if it improves anything?
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index d9cb476..fe177c8 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -41,7 +41,7 @@ static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
>  {
>         /* wait for cache operation by line or way to complete */
>         while (readl_relaxed(reg) & mask)
> -               ;
> +               cpu_relax();
>  }
>
>  #ifdef CONFIG_CACHE_PL310
> @@ -136,6 +136,7 @@ static void __l2x0_flush_all(void)
>         debug_writel(0x00);
>  }
>
> +#ifndef CONFIG_IPIPE
>  static void l2x0_flush_all(void)
>  {
>         unsigned long flags;
> @@ -145,6 +146,51 @@ static void l2x0_flush_all(void)
>         __l2x0_flush_all();
>         spin_unlock_irqrestore(&l2x0_lock, flags);
>  }
> +#else
> +static void l2x0_clean_line_idx(unsigned line, unsigned way)
> +{
> +       void __iomem *base = l2x0_base;
> +
> +       writel_relaxed((way << 28) | (line << 5), base + L2X0_CLEAN_LINE_IDX);
> +       cache_wait(base + L2X0_CLEAN_LINE_IDX, 1);
> +}
> +
> +static void l2x0_flush_way(unsigned way, unsigned len, unsigned lines)
> +{
> +       unsigned long flags;
> +       unsigned line, i;
> +
> +       for (line = 0; line < lines; line += len ) {
> +               spin_lock_irqsave(&l2x0_lock, flags);
> +               debug_writel(0x03);
> +               for (i = 0; i < len && line + i < lines; i++)
> +                       l2x0_clean_line_idx(line + i, way);
> +               cache_sync();
> +               debug_writel(0x00);
> +               spin_unlock_irqrestore(&l2x0_lock, flags);
> +       }
> +
> +       spin_lock_irqsave(&l2x0_lock, flags);
> +       debug_writel(0x03);
> +       writel_relaxed((1 << way), l2x0_base + L2X0_CLEAN_WAY);
> +       cache_wait_way(l2x0_base + L2X0_CLEAN_WAY, (1 << way));
> +       cache_sync();
> +       debug_writel(0x00);
> +       spin_unlock_irqrestore(&l2x0_lock, flags);
> +}
> +
> +static void l2x0_flush_all(void)
> +{
> +       unsigned lines, len, way, ways;
> +
> +       ways = fls(l2x0_way_mask);
> +       lines = l2x0_size / (ways * CACHE_LINE_SIZE);
> +       len = L2X0_SPINLOCK_LEN / CACHE_LINE_SIZE;
> +
> +       for (way = 0; way < ways; way++)
> +               l2x0_flush_way(way, len, lines);
> +}
> +#endif
>
>  static void l2x0_clean_all(void)
>  {
>
>
> --
>                                                                 Gilles.



-- 
atp