* [Xenomai-help] Xenomai on Gumstix (ARM XScale PXA270)
@ 2008-12-18 16:31 Felipe Brandão Cavalcanti
2008-12-18 16:48 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Felipe Brandão Cavalcanti @ 2008-12-18 16:31 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 15433 bytes --]
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.
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).
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
PS: Here is the full output of xeno-test:
root@domain.hid$ ./xeno-test
xeno-test: started
withBusybox is 1
xeno-test: running tests
Thu Jan 1 00:11:36 UTC 1970
running: ./xeno-config --verbose
xeno-config --verbose
--version="2.4.6.1"
--cc="arm-angstrom-linux-gnueabi-gcc -march=armv5te -mtune=xscale"
--arch="arm"
--prefix="/usr/xenomai"
--xeno-cflags="-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
-D__XENO__"
--xeno-ldflags="-L/usr/xenomai/lib -lpthread "
--posix-cflags="-I/usr/xenomai/include -I/usr/xenomai/include/posix
-D_GNU_SOURCE -D_REENTRANT -D__XENO__"
--posix-ldflags="-Wl,@/usr/xenomai/lib/posix.wrappers
-L/usr/xenomai/lib -lpthread_rt -lpthread -lrt "
--library-dir="/usr/xenomai/lib"
Thu Jan 1 00:11:37 UTC 1970
running: ./xeno-info
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
BusyBox v1.2.1 (2008.11.24-12:06+0000) multi-call binary
Linux gumstix-custom-verdex 2.6.24 #1 Tue Dec 16 16:27:25 BRST 2008 armv5tel
unknown
*** glibc detected *** which: free(): invalid next size (fast): 0x000c4078
***
Aborted
*** glibc detected *** which: free(): invalid next size (fast): 0x000c4078
***
Aborted
module-init-tools 3.2.2
*** glibc detected *** which: free(): invalid next size (fast): 0x000c4078
***
Aborted
Modules Loaded i2c_dev i2c_pxa i2c_core sd_mod scsi_mod proc_gpio
ohci_hcd usbcore
Thu Jan 1 00:11:38 UTC 1970
running: cat /proc/cpuinfo
Processor : XScale-PXA270 rev 7 (v5l)
BogoMIPS : 622.59
Features : swp half thumb fastmult edsp iwmmxt
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part : 0x411
CPU revision : 7
Cache type : undefined 5
Cache clean : undefined 5
Cache lockdown : undefined 5
Cache format : Harvard
I size : 32768
I assoc : 32
I line length : 32
I sets : 32
D size : 32768
D assoc : 32
D line length : 32
D sets : 32
Hardware : The Gumstix Platform
Revision : 0000
Serial : ffff0015c906b7c0
Thu Jan 1 00:11:38 UTC 1970
running: md5sum /proc/cpuinfo # cpuinfo fingerprint
4816913f154157d105065311be5e8cc1 /proc/cpuinfo
Thu Jan 1 00:11:38 UTC 1970
running: cat /proc/ipipe/Linux
+----- Handling ([A]ccepted, [G]rabbed, [W]ired, [D]iscarded)
|+---- Sticky
||+--- Locked
|||+-- Exclusive
||||+- Virtual
[IRQ] |||||
0: A....
1: A....
2: A....
3: A....
4: A....
5: A....
6: A....
7: A....
8: A....
9: A....
10: A....
11: A....
12: A....
13: A....
14: A....
15: A....
16: A....
17: A....
18: A....
19: A....
20: A....
21: A....
22: A....
23: A....
24: A....
25: A....
26: A....
27: A....
28: A....
29: A....
30: A....
31: A....
32: A....
33: A....
34: A....
35: A....
36: A....
37: A....
38: A....
39: A....
40: A....
41: A....
42: A....
43: A....
44: A....
45: A....
46: A....
47: A....
48: A....
49: A....
50: A....
51: A....
52: A....
53: A....
54: A....
55: A....
56: A....
57: A....
58: A....
59: A....
60: A....
61: A....
62: A....
63: A....
64: A....
65: A....
66: A....
67: A....
68: A....
69: A....
70: A....
71: A....
72: A....
73: A....
74: A....
75: A....
76: A....
77: A....
78: A....
79: A....
80: A....
81: A....
82: A....
83: A....
84: A....
85: A....
86: A....
87: A....
88: A....
89: A....
90: A....
91: A....
92: A....
93: A....
94: A....
95: A....
96: A....
97: A....
98: A....
99: A....
100: A....
101: A....
102: A....
103: A....
104: A....
105: A....
106: A....
107: A....
108: A....
109: A....
110: A....
111: A....
112: A....
113: A....
114: A....
115: A....
116: A....
117: A....
118: A....
119: A....
120: A....
121: A....
122: A....
123: A....
124: A....
125: A....
126: A....
127: A....
128: A....
129: A....
130: A....
131: A....
132: A....
133: A....
134: A....
135: A....
136: A....
137: A....
138: A....
139: A....
140: A....
141: A....
142: A....
143: A....
144: A....
145: A....
146: A....
147: A....
148: A....
149: A....
150: A....
151: A....
152: A....
153: A....
154: A....
155: A....
156: A....
157: A....
158: A....
159: A....
160: A....
161: A....
162: A....
163: A....
164: A....
165: A....
166: A....
167: A....
168: A....
169: A....
170: A....
171: A....
172: A....
173: A....
174: A....
175: A....
176: A....
177: A....
178: A....
179: A....
180: A....
181: A....
182: A....
183: A....
184: A....
185: A....
186: A....
187: A....
188: A....
189: A....
190: A....
191: A....
192: G...V
193: G...V
195: G...V
[Domain info]
id=0x00000000
priority=100
Thu Jan 1 00:11:38 UTC 1970
running: cat /proc/ipipe/Xenomai
+----- Handling ([A]ccepted, [G]rabbed, [W]ired, [D]iscarded)
|+---- Sticky
||+--- Locked
|||+-- Exclusive
||||+- Virtual
[IRQ] |||||
26: W..X.
194: W...V
[Domain info]
id=0x58454e4f
priority=topmost
Thu Jan 1 00:11:38 UTC 1970
running: cat /proc/ipipe/version
1.9-01
Thu Jan 1 00:11:38 UTC 1970
running: generate_loads 1
dd workload started, pids 618 stored in /var/lock/xeno-test.484.pids
Thu Jan 1 00:11:38 UTC 1970
running: cat /proc/interrupts
CPU0
3: 2 SC ohci_hcd:usb1
6: 0 SC pxa_i2c-i2c.1
18: 0 SC pxa_i2c-i2c.0
22: 1757 SC FFUART
25: 0 SC DMA
26: 70586 SC ost0
Err: 0
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/loadavg
0.16 0.03 0.01 2/27 630
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/meminfo
MemTotal: 127988 kB
MemFree: 117624 kB
Buffers: 0 kB
Cached: 5916 kB
SwapCached: 0 kB
Active: 4208 kB
Inactive: 2832 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 1144 kB
Mapped: 1344 kB
Slab: 1912 kB
SReclaimable: 388 kB
SUnreclaim: 1524 kB
PageTables: 148 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 63992 kB
Committed_AS: 4776 kB
VmallocTotal: 516096 kB
VmallocUsed: 66096 kB
VmallocChunk: 442364 kB
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/xenomai/affinity
00000001
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/xenomai/apc
APC CPU0
0: 0 (pipe_wakeup)
1: 22 (lostage_handler)
2: 0 (registry_export)
3: 0 (pse51_lostage_handler)
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/xenomai/faults
TRAP CPU0
0: 0 (Data or instruction access)
1: 0 (Section fault)
2: 0 (Generic data abort)
3: 0 (Unknown exception)
4: 0 (Instruction breakpoint)
5: 0 (Floating point exception)
6: 0 (VFP Floating point exception)
7: 0 (Undefined instruction)
8: 0 (Unaligned access exception)
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/xenomai/hal
1.9-01
Thu Jan 1 00:11:39 UTC 1970
running: cat /proc/xenomai/heap
size=129536:used=96:pagesz=512 (main heap)
size=32256:used=0:pagesz=512 (stack pool)
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/irq
IRQ CPU0
26: 278473 [timer]
194: 27 [virtual]
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/latency
9538
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/sched
CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME
0 0 -1 0 0 master R ROOT
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/stat
CPU PID MSW CSW PF STAT %CPU NAME
0 0 0 129987 0 00500080 99.4 ROOT
0 0 0 278517 0 00000000 0.3 IRQ26: [timer]
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/timebases
NAME RESOLUTION JIFFIES STATUS
master 1 n/a enabled,set
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/timer
status=on:setup=307:clock=2290928995:timerdev=osmr0:clockdev=oscr0
Thu Jan 1 00:11:40 UTC 1970
running: cat /proc/xenomai/version
2.4.6
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/interfaces/native
0
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/interfaces/posix
0
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/interfaces/rtai
0
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/interfaces/rtdm
0
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/interfaces/sys
0
Thu Jan 1 00:11:41 UTC 1970
running: cat /proc/xenomai/rtdm/fildes
total=128:open=0:free=128
Mem: 10608K used, 117380K free, 0K shrd, 0K buff, 5920K cached
Load average: 0.31 0.07 0.02 (Status: S=sleeping R=running, W=waiting)
PID USER STATUS RSS PPID %CPU %MEM COMMAND
618 root R 448 1 96.0 0.3 dd
752 root R 756 751 3.8 0.5 top
434 root S 940 1 0.0 0.7 ntpd
475 root S 940 1 0.0 0.7 sh
484 root S 708 475 0.0 0.5 xeno-test
442 root S 592 1 0.0 0.4 klogd
425 root S 572 1 0.0 0.4 dropbear
Thu Jan 1 00:11:43 UTC 1970
running: ./run -- -sh -T 120 -t0 # latency
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
--
*º¤., ¸¸,.¤º*¨*¤., ¸¸,.¤º*¨*
Cavalkaf (aka Felipe) <cavalkaf@domain.hid>
AIM: Cavalkaf | MSN: cavalkaf2@domain.hid
Check out <http://www.flickr.com/photos/rbcav2003/>
[-- Attachment #2: Type: text/html, Size: 27993 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Xenomai-help] Xenomai on Gumstix (ARM XScale PXA270)
2008-12-18 16:31 [Xenomai-help] Xenomai on Gumstix (ARM XScale PXA270) Felipe Brandão Cavalcanti
@ 2008-12-18 16:48 ` Gilles Chanteperdrix
[not found] ` <8b216e9e0812180943v1ecc3fcasb45732cd9a58cde2@domain.hid>
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2008-12-18 16:48 UTC (permalink / raw)
To: Felipe Brandão Cavalcanti; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <8b216e9e0812180831n6ebf4ff1gcb990864ba112eab@mail.gmail.com>]
end of thread, other threads:[~2008-12-19 15:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-18 16:31 [Xenomai-help] Xenomai on Gumstix (ARM XScale PXA270) Felipe Brandão Cavalcanti
2008-12-18 16:48 ` Gilles Chanteperdrix
[not found] ` <8b216e9e0812180943v1ecc3fcasb45732cd9a58cde2@domain.hid>
2008-12-18 17:58 ` Gilles Chanteperdrix
[not found] <8b216e9e0812180831n6ebf4ff1gcb990864ba112eab@mail.gmail.com>
[not found] ` <494A7ED0.8090008@xenomai.org>
[not found] ` <8b216e9e0812180943v1ecc3fcasb45732cd9a58cde2@mail.gmail.com>
[not found] ` <494A8F3E.9090906@xenomai.org>
2008-12-19 15:16 ` Xenomai OpenEmbedded cross compile test applications Charlton, John
2008-12-19 15:16 ` [Xenomai-help] " Charlton, John
2008-12-19 15:34 ` Jan Kiszka
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.