Re: [Xenomai-help] Xenomai on Gumstix (ARM XScale PXA270)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Felipe Brandão Cavalcanti wrote:
> Hi,
> 
> I am currently trying to get Xenomai running on the gumstix plataform (
> http://www.gumstix.com/), which is a *very* small linux board based on the
> PXA270 ARM XScale (I am using a Verdex board). However, I did run into a few
> problems during the procedure (the user space portion locks up!)
> 
> I followed the instructions on the README file, and patched the kernel with
> the proper Adeos patch using the command:
> ./prepare-kernel.sh
> --linux=/home/felipe/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.24-r1/linux-2.6.24/
> --adeos=/home/felipe/gumstix/adeos-ipipe-2.6.24-arm-1.9-01.patch --arch=arm
> 
> I did the standart kernel configuration procedure afterwards, and did
> configure the Xenomai options. The kernel did boot fine, and I can confirm
> that Adeos is running (I have /proc/xenomai and some messages during the
> boot process).
> 
> My problem is with the user space portion of Xenomai. I compiled it using
> the usual cross-compiling procedure:
> ./configure --enable-arm-mach=pxa3xx --host=arm-linux
> make
> make install
> However, the "make install" command runs on a fakeroot, than gets packaged
> and transfered to the embedded plataform (the Gumstix). Basically, the
> package contains the stuff on /dev and on /usr/xenomai.
> 
> Basically, when I try to run xeno-test, the whole systems locks up (I have
> to hard-reset) when it gets to the latency test.
> When I run ./latency, it also freezes up.

Known issue. The default period of the latency test is 100us which is
much to small for an ARM. Try latency -p 1000. I believe xeno-test also
has a -p option passed to latency.

> 
> However, when I try ./latency -t 1 and ./latency -t 2 (testing the kernel
> latency, IIRC), it runs fine. My guess is that the problems is with the
> user-space instalation procedure (somehow it is not being correctly
> installed?).
> 
> My other question is regarding the latencies I should be getting (they do
> seem quite high.) Here is the output from my latency tests:
> root@domain.hid$ ./latency -t 2
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       0.307|       0.925|      10.153|       0|       0.307|
> 10.153
> RTD|       0.613|       0.988|     145.229|       1|       0.307|
> 145.229
> RTD|      -3.695|       0.962|      78.767|       1|      -3.695|
> 145.229
> RTD|       0.612|       0.969|      80.920|       1|      -3.695|
> 145.229
> RTD|      -4.003|       0.962|      77.535|       1|      -4.003|
> 145.229
> \x16RTD|      -1.850|       0.970|      80.919|       1|      -4.003|
> 145.229
> ---|------------|------------|------------|--------|-------------------------
> RTS|      -4.003|       0.962|     145.229|       1|    00:00:08/00:00:08
> root@domain.hid$ ./latency -t 1
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel periodic task, 100 us period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       4.921|       8.581|      23.383|       0|       4.921|
> 23.383
> RTD|       4.921|       8.662|     135.998|       5|       4.921|
> 135.998
> RTD|       4.920|       8.692|     173.228|       9|       4.920|
> 173.228
> RTD|       4.919|       8.658|     173.843|      12|       4.919|
> 173.843
> RTD|       4.919|       8.640|     171.689|      15|       4.919|
> 173.843
> RTD|       4.918|       8.676|     171.380|      21|       4.918|
> 173.843
> RTD|       4.917|       8.642|     171.379|      24|       4.917|
> 173.843
> RTD|       4.916|       8.684|     174.763|      29|       4.916|
> 174.763
> RTD|       4.916|       8.640|     175.070|      32|       4.916|
> 175.070
> RTD|       4.915|       8.651|     169.839|      36|       4.915|
> 175.070
> RTD|       4.914|       8.638|     172.915|      39|       4.914|
> 175.070
> RTD|       4.914|       8.702|     170.145|      47|
> 4.914---|------------|------------|------------|--------|-------------------------
> RTS|       4.914|       8.655|     175.070|      47|    00:00:12/00:00:12
> 
> The worst latency seem to be arround 175, which is not very good (comparing
> it to an X86 processor). Is this normal or is there some kernel
> configuration option which I can use to improve on this? (I am running it
> with a farly custom config file, so some undeserible options might be
> enabled).

There are a few answers to this question:
- we know of a way to improve the pure interrupt latency, it consists in
switching contexts with interrupts on (the idea was taken from linux) it
is currently implemented in trunk, but unfortunately not in the stable
branch;
- you can improve the context switch time (which results in better
user-space latency) by using the ARM FCSE, the option is available on
the latest Adeos patch for linux 2.6.26 and reduces the context switch
time of about 100us.

Note however that even with this two optimizations, 100us is still too
hard for an ARM, but you will observe overruns instead of a lockup.

> 
> BTW, for the curious, I am using this in order to control a humanoid robot
> (Bioloid) - I am doing research on humanoid robots, and the idea is to use
> embedded linux for the control portion of the project. I am a student at the
> LARA research lab in the University of Brasília, Brazil.
> 
> Thank you very much for any help,
>             -Felipe B Cavalcanti
>             LARA - Laboratory of Robotics and Automation
>             UnB - University of Brasília, Brazil

That is interesting.

Regards.

-- 
                                                 Gilles.