* Xenomai OpenEmbedded cross compile test applications
2008-12-18 17:58 ` Gilles Chanteperdrix
@ 2008-12-19 15:16 ` Charlton, John
-1 siblings, 0 replies; 6+ messages in thread
From: Charlton, John @ 2008-12-19 15:16 UTC (permalink / raw)
To: Xenomai help; +Cc: openembedded-devel@lists.openembedded.org
Using the cross compile environment for OpenEmbedded i686 angstrom of xenomai-2.4.4 described below I built the xenomai test application trivial-periodic in xenomai-2.4.4/examples/native. I copied the executable to the target system. Since there is no /etc/ld.so.conf.d directory in the OE root file system, I made one and put the xenomai library path in the xenomai.conf file. The xenomai.conf file just has the one directory: /usr/local/lib which does not even exist in the target file system. I modified xenomai.conf to: /usr/xenomai/lib where the xenomai library files are actually located. I also copied xenomai.conf to /etc and set LD_LIBRARY_PATH=/usr/xenomai/lib.
When I execute the trivail-periodic application on the target (NANO-7240) the console hangs and nothing happens. I also ran trivial-periodic on a non cross compiled laptop build of xenomai and it runs as expected displaying the times on the console output. I login to the target using ssh and it is alive. The trivial-periodic process shows up in the ps list as:
3077 root Z [trivial-periodi]
So it is a zombie. I can kill it with kill -9 3077 and that releases the console.
Any help on this issue is welcome.
Also, how do I run the xenomai/src/testsuite applications in a target (non build) environment?
Background:
I have applied the xenomai 2.4.4 patch to kernel 2.6.25.11. I built the kernel and installed it on a ext2 flash partition and it boots on the target system. The /proc/xenomai directory shows up so xenomai seems to be running. I built the xenomai user mode with the following commands:
Set the following:
export XENOMAI_ROOT=/home/us075929/projects/oe/xenomai-2.4.4
export XENOMAI_BUILD=/home/us075929/projects/oe/build-xenomai-2.4.4
cd $XENOMAI_BUILD
$XENOMAI_ROOT/configure --disable-x86-tsc --host=i686-angstrom-linux
I am not sure what tsc refers to. The only two parameters in my kernal configuration that come up are 'time stamp counter' and 'touch screen device support' both of which are disabled. Since TSC is enabled by default and strong binding I disabled it in the xenomai configuration.
The xenomai configure goes smoothly. I then install xenomai user support to a staging directory as follows:
export DESTDIR=/home/us075929/projects/oe/staging-linux-2.6.25.11
cd $XENOMAI_BUILD
make install
The $DESTDIR/dev and $DESDIR/usr/xenomai are installed as expected. I copy those directories to the target root file system, boot the target and run the trivial-periodic application as described above.
--John
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Xenomai-help] Xenomai OpenEmbedded cross compile test applications
@ 2008-12-19 15:16 ` Charlton, John
0 siblings, 0 replies; 6+ messages in thread
From: Charlton, John @ 2008-12-19 15:16 UTC (permalink / raw)
To: Xenomai help; +Cc: openembedded-devel@domain.hid
Using the cross compile environment for OpenEmbedded i686 angstrom of xenomai-2.4.4 described below I built the xenomai test application trivial-periodic in xenomai-2.4.4/examples/native. I copied the executable to the target system. Since there is no /etc/ld.so.conf.d directory in the OE root file system, I made one and put the xenomai library path in the xenomai.conf file. The xenomai.conf file just has the one directory: /usr/local/lib which does not even exist in the target file system. I modified xenomai.conf to: /usr/xenomai/lib where the xenomai library files are actually located. I also copied xenomai.conf to /etc and set LD_LIBRARY_PATH=/usr/xenomai/lib.
When I execute the trivail-periodic application on the target (NANO-7240) the console hangs and nothing happens. I also ran trivial-periodic on a non cross compiled laptop build of xenomai and it runs as expected displaying the times on the console output. I login to the target using ssh and it is alive. The trivial-periodic process shows up in the ps list as:
3077 root Z [trivial-periodi]
So it is a zombie. I can kill it with kill -9 3077 and that releases the console.
Any help on this issue is welcome.
Also, how do I run the xenomai/src/testsuite applications in a target (non build) environment?
Background:
I have applied the xenomai 2.4.4 patch to kernel 2.6.25.11. I built the kernel and installed it on a ext2 flash partition and it boots on the target system. The /proc/xenomai directory shows up so xenomai seems to be running. I built the xenomai user mode with the following commands:
Set the following:
export XENOMAI_ROOT=/home/us075929/projects/oe/xenomai-2.4.4
export XENOMAI_BUILD=/home/us075929/projects/oe/build-xenomai-2.4.4
cd $XENOMAI_BUILD
$XENOMAI_ROOT/configure --disable-x86-tsc --host=i686-angstrom-linux
I am not sure what tsc refers to. The only two parameters in my kernal configuration that come up are 'time stamp counter' and 'touch screen device support' both of which are disabled. Since TSC is enabled by default and strong binding I disabled it in the xenomai configuration.
The xenomai configure goes smoothly. I then install xenomai user support to a staging directory as follows:
export DESTDIR=/home/us075929/projects/oe/staging-linux-2.6.25.11
cd $XENOMAI_BUILD
make install
The $DESTDIR/dev and $DESDIR/usr/xenomai are installed as expected. I copy those directories to the target root file system, boot the target and run the trivial-periodic application as described above.
--John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] Xenomai OpenEmbedded cross compile test applications
2008-12-19 15:16 ` [Xenomai-help] " Charlton, John
(?)
@ 2008-12-19 15:34 ` Jan Kiszka
-1 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2008-12-19 15:34 UTC (permalink / raw)
To: Charlton, John; +Cc: openembedded-devel@domain.hid, Xenomai help
Charlton, John wrote:
> Using the cross compile environment for OpenEmbedded i686 angstrom of xenomai-2.4.4 described below I built the xenomai test application trivial-periodic in xenomai-2.4.4/examples/native. I copied the executable to the target system. Since there is no /etc/ld.so.conf.d directory in the OE root file system, I made one and put the xenomai library path in the xenomai.conf file. The xenomai.conf file just has the one directory: /usr/local/lib which does not even exist in the target file system. I modified xenomai.conf to: /usr/xenomai/lib where the xenomai library files are actually located. I also copied xenomai.conf to /etc and set LD_LIBRARY_PATH=/usr/xenomai/lib.
>
> When I execute the trivail-periodic application on the target (NANO-7240) the console hangs and nothing happens. I also ran trivial-periodic on a non cross compiled laptop build of xenomai and it runs as expected displaying the times on the console output. I login to the target using ssh and it is alive. The trivial-periodic process shows up in the ps list as:
> 3077 root Z [trivial-periodi]
> So it is a zombie. I can kill it with kill -9 3077 and that releases the console.
> Any help on this issue is welcome.
>
> Also, how do I run the xenomai/src/testsuite applications in a target (non build) environment?
>
> Background:
> I have applied the xenomai 2.4.4 patch to kernel 2.6.25.11. I built the kernel and installed it on a ext2 flash partition and it boots on the target system. The /proc/xenomai directory shows up so xenomai seems to be running. I built the xenomai user mode with the following commands:
>
> Set the following:
> export XENOMAI_ROOT=/home/us075929/projects/oe/xenomai-2.4.4
> export XENOMAI_BUILD=/home/us075929/projects/oe/build-xenomai-2.4.4
>
> cd $XENOMAI_BUILD
> $XENOMAI_ROOT/configure --disable-x86-tsc --host=i686-angstrom-linux
>
> I am not sure what tsc refers to. The only two parameters in my kernal configuration that come up are 'time stamp counter' and 'touch screen device support' both of which are disabled. Since TSC is enabled by default and strong binding I disabled it in the xenomai configuration.
So you are most probably using a suboptimal, maybe even incorrect
.config for your target. It will surely support TSC (time stamp counter,
see also the Xenomai installation readme), you just have to adopt the
CPU type settings according to your target's CPU. What CPU type is it?
If unsure, select at least CONFIG_M586_TSC.
>
> The xenomai configure goes smoothly. I then install xenomai user support to a staging directory as follows:
>
> export DESTDIR=/home/us075929/projects/oe/staging-linux-2.6.25.11
>
> cd $XENOMAI_BUILD
> make install
>
> The $DESTDIR/dev and $DESDIR/usr/xenomai are installed as expected. I copy those directories to the target root file system, boot the target and run the trivial-periodic application as described above.
>
> --John
If problems persist, please post your .config.
BTW, the stable Xenomai release is 2.4.6.1...
Jan
PS: Please don't start new threads by replying to old ones.
--
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 6+ messages in thread
* [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
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 --
[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
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
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.