Re: [Xenomai-core] Porting xeno-{info|load|test} to a busybox system
Jim Cromie wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Jim Cromie wrote:
Niklaus Giger wrote:
Am Freitag, 26. Mai 2006 15:52 schrieb Jan Kiszka:
Niklaus Giger wrote:...
If anybody has a working target with a Xenomai + BusyBox
combination and
would be willing to test drive my changes, I would appreciate a
feedback
enormously.
I hope this isnt waiting on my 'approval'.
I think its a great idea, and has been on my (way too stagnant) list
for
a while.
Your work has at least urged me to install busybox on my xeno-box. ;-)
My only concern is whether we've sufficiently distinguished the issues:
1 - ash vs bash
Its not entirely clear to me which flavors of sh busybox has:
ash / dash / not-bash
I gather u worked with ash, and it seems most valuable sh features
work there just fine ( shell-functions, even 'job-control' of a
fashion)
2 - busybox 'executables' only
I coded in a lot of 'full linux' gimme's, like zgrep, script, etc.
Niklaus has repaired many of these. I think a more thorough cleanup is
possible,
esp if things like 'script' are jettisoned for a simpler
shell-functions
or helper scripts.
This all implies a re-write, which is on my list...
(esp the job-control testing and repair)
Just stumbled over this again while cleaning up my mailbox. What's the
status? Waiting for improvements, or waiting for /someone/ to type svn
ci (and improve the topics above later)?
It's queued for now, waiting for a combined ack to merge the current
patch from JimC and Niklaus.
AFAIC, Niklaus is in the lead atm.
Im trying to get some GPIO stuff ready for -mm.
( I'll post separately on this ..)
I ran his changes once, I dont even remember what it did.
(which suggests that it didnt explode ;-)
IMO, take it when Niklaus says its ready.
I have some local changes here, but Ill work them into shape after
Niks changes go in (maybe much later :-(
We should probly confer on the longer-term issues too.
- a rational option-pass-thru, or a means to avoid doing so.
if we assume OPTS_${TOOLNAME} exists, we could
grab it out of env, and pass it into the benchmark prog.
- would require no prog mods, but gives us complete control
- would play nicer than assuming -T has meaning for all progs.
Would this fit with an automated test 'bot? Niklaus?
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] use vmalloc'ed trace buffer
Jan Kiszka wrote: Hi Philippe, here is the cleaned up and configurable version of my vmalloc hack for the I-pipe tracer. As it has a slight performance impact to use virtual memory for the trace buffer (running "hackbench 10" in parallel to "latency -p 100" on a 266 MHz P-MMX: 227 vs. 244 s hackbench runtime), I left this option off by default. If there is any kind of CONFIG combination that cries for default on, we can easily add it. Ack. Merged in my tree, thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: RE : New patch for Freescale i.MX21 (csb535fs)
ROSSIER Daniel wrote: Hi Philippe, We have performed some test with the patch and everything is OK. Ok. Will merge as is. We got the same latencies than before; we're now investigating what is the cause of some occasional peaks to 40-50 us. Daniel Message d'origine De: Philippe Gerum [mailto:[EMAIL PROTECTED] Date: lun. 05.06.2006 13:46 À: ROSSIER Daniel Cc: xenomai-core@gna.org Objet : Re: New patch for Freescale i.MX21 (csb535fs) Hi, Here is a candidate Adeos patch for the imx21 board. It applies on top of 2.6.14 + generic IMX21 patch + vanilla Adeos 2.6.14-1.3-04 patch. Since I don't have this hw at hand, It would be nice that you try this patch on your board when time allows and let me know if everything works as expected. TIA, -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: While we are at it, #define current ipipe_safe_current() /* ? */ Nope, there is the need for some special changes. If you refer to the cache flushing issue, then it would be better to actually check for foreign stacks explicitely, so that you could substitute current globally: -if (CACHE_FLUSH_IS_SAFE && current->mm && -addr < TASK_SIZE) +if (CACHE_FLUSH_IS_SAFE && !testbit(IPIPE_NOSTACK_FLAG, + &ipipe_percpu_domain[cpuid]->cpudata[cpuid].status) && +current->mm && addr < TASK_SIZE) Right - on first sight. I tried to redefine current, but the ipipe_safe_current macro requires that symbol itself, ugh. Turning ipipe_safe_current into a static inline doesn't work due to circular dependencies on linux/sched.h. So I guess it's best to keep it as it is (though kgdb-ipipe.patch would have become really cute). Ack. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> While we are at it, >>> #define current ipipe_safe_current() /* ? */ >> >> >> Nope, there is the need for some special changes. >> > > If you refer to the cache flushing issue, then it would be better to > actually check for foreign stacks explicitely, so that you could > substitute current globally: > > -if (CACHE_FLUSH_IS_SAFE && current->mm && > -addr < TASK_SIZE) > +if (CACHE_FLUSH_IS_SAFE && !testbit(IPIPE_NOSTACK_FLAG, > + &ipipe_percpu_domain[cpuid]->cpudata[cpuid].status) && > +current->mm && addr < TASK_SIZE) > Right - on first sight. I tried to redefine current, but the ipipe_safe_current macro requires that symbol itself, ugh. Turning ipipe_safe_current into a static inline doesn't work due to circular dependencies on linux/sched.h. So I guess it's best to keep it as it is (though kgdb-ipipe.patch would have become really cute). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: gcc-4.1 warnings in switchtest
Jan Kiszka wrote: > Hi Gilles, > > I'm seeing this with gcc-4.1: > > src/testsuite/switchtest/switch.c: In function 'main': > src/testsuite/switchtest/switch.c:620: warning: 'params.swt.flags' is > used uninitialized in this function > src/testsuite/switchtest/switch.c:620: warning: 'params.swt.index' is > used uninitialized in this function > src/testsuite/switchtest/switch.c:620: warning: 'params.thread' is used > uninitialized in this function > > Real issues or just finickiness? No, the compiler is right, but it has no consequence, the values of the swt structure are overriden by an ioctl later on. Anyway, I can set all this to zero to please the compiler. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Some new test cases for the vxWorks skin
Hi
Here the reworked patch.
vxWorks supports empty messages. Only one at a time can be received.
Test log of running t010726-2 under vxWorks and the simulator are below:
(vxWorks target)
0x1e268a8 (root): t010726-2.c:180: TEST failed: qid == 0 && errno ==
S_msgQLib_INVALID_QUEUE_TYPE
0x1e268a8 (): task deadt010726-2.c:337 Correct sequence: SEQ("root",1)
0x1e268a8 (): task deadt010726-2.c:338 Correct sequence: SEQ("Peer",2)
0x1e268a8 (): task deadt010726-2.c:339 Correct sequence:
SEQ("root",10)
0x1e268a8 (): task deadt010726-2.c:340 Correct sequence: SEQ("Peer",2)
0x1e268a8 (): task deadt010726-2.c:341 Correct sequence: SEQ("root",8)
0x1e268a8 (): task deadt010726-2.c:342 Correct sequence:
SEQ("Peer",14)
0x1e268a8 (): task deadt010726-2.c:343 Correct sequence: SEQ("root",6)
0x1e268a8 (): task deadt010726-2.c:348, test finished: 1 failures/ 111
tests
(Xenomai sim)
starting VxWorks services.
t010726-2.c:196: TEST failed: qid != 0
t010726-2.c:199: TEST failed: rc == 0
t010726-2.c:201: TEST failed: rc == OK
t010726-2.c:203: TEST failed: rc == 1
t010726-2.c:205: TEST failed: rc == OK
t010726-2.c:207: TEST failed: rc == 2
t010726-2.c:209: TEST failed: rc== OK
Error code 3997697: S_objLib_OBJ_ID_ERROR
t010726-2.c:211: TEST failed: rc == 1
t010726-2.c:213: TEST failed: rc== OK
Error code 3997697: S_objLib_OBJ_ID_ERROR
t010726-2.c:215: TEST failed: rc == 0
t010726-2.c:220: TEST failed: rc == 2
t010726-2.c:222: TEST failed: rc== OK
Error code 3997697: S_objLib_OBJ_ID_ERROR
t010726-2.c:224: TEST failed: rc == 1
t010726-2.c:227: TEST failed: rc == OK
t010726-2.c:278: TEST failed: rc== OK
Error code 4259841: S_msgQLib_INVALID_MSG_LENGTH
t010726-2.c:284: TEST failed: rc == ERROR && errno == S_objLib_OBJ_UNAVAILABLE
Xenoscope: lt-t010726-2: fatal in MvmIrq (time=3658.732701):
Best regards
--
Niklaus Giger
Index: sim/skins/vxworks/testsuite/t010823-1.c
===
--- sim/skins/vxworks/testsuite/t010823-1.c (Revision 1206)
+++ sim/skins/vxworks/testsuite/t010823-1.c (Arbeitskopie)
@@ -70,7 +70,7 @@
TEST_ASSERT(pTcb != NULL);
#ifdef VXWORKS
-pstackBase = (char *) malloc(stackSize) + stacksize;
+pstackBase = (char *) malloc(stackSize) + stackSize;
#endif
TEST_ASSERT(taskInit(&peerTcb,
@@ -100,7 +100,10 @@
TEST_MARK();
-TEST_ASSERT(taskIdVerify(0) == ERROR && errno == S_objLib_OBJ_ID_ERROR);
+errno = 0;
+TEST_ASSERT(taskIdVerify(0) == ERROR && errno == 0);
+errno = 0;
+TEST_ASSERT(taskIdVerify(malloc(20)) == ERROR && errno == S_objLib_OBJ_ID_ERROR);
TEST_ASSERT_OK(taskIdVerify((TASK_ID)&peerTcb));
Index: sim/skins/vxworks/testsuite/t010726-2.c
===
--- sim/skins/vxworks/testsuite/t010726-2.c (Revision 1206)
+++ sim/skins/vxworks/testsuite/t010726-2.c (Arbeitskopie)
@@ -17,7 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
- * Description: Testing VxWorks services:
+ * Description: Testing VxWorks services (task to task and int to task):
* - msgQCreate
* - msgQDelete
* - msgQNumMsgs
@@ -47,6 +47,67 @@
#define NMESSAGES (sizeof(message_list) / sizeof(message_list[0]))
+static WDOG_ID wid;
+
+static int int2taskQid ;
+
+void msgDuringInt (long arg)
+
+{
+int qid = 0, rc = 0, msg = 0;
+TEST_ASSERT(intContext());
+TEST_MARK();
+
+qid = msgQCreate(NMESSAGES,sizeof(int),MSG_Q_FIFO);
+TEST_ASSERT(qid == 0 && errno == S_intLib_NOT_ISR_CALLABLE);
+
+errno = 0;
+rc = msgQNumMsgs(int2taskQid);
+TEST_ASSERT(rc == 0);
+
+errno = 0;
+rc = msgQReceive(int2taskQid,(char *)&msg,sizeof(msg), 0);
+TEST_ASSERT(rc == ERROR && errno == S_intLib_NOT_ISR_CALLABLE);
+msg = 0xaffe;
+
+errno = 0;
+rc = msgQSend(int2taskQid,(char *)&msg,sizeof(int),0, MSG_PRI_NORMAL);
+TEST_ASSERT_OK(rc);
+
+errno = 0;
+rc = msgQSend(int2taskQid,(char *)&msg,sizeof(int),WAIT_FOREVER, MSG_PRI_NORMAL);
+TEST_ASSERT(rc == ERROR && errno == S_msgQLib_NON_ZERO_TIMEOUT_AT_INT_LEVEL);
+TEST_MARK();
+}
+
+void testMsqInterrupt()
+{
+ int nmsg = 0, qid, rc, msg = 0;
+ int2taskQid = msgQCreate(NMESSAGES,sizeof(int),MSG_Q_FIFO);
+ TEST_ASSERT(int2taskQid != 0);
+
+ wid = wdCreate();
+
+ TEST_ASSERT(wid != 0);
+
+ TEST_ASSERT_OK(wdStart(wid,1,msgDuringInt,0x25262728));
+
+ TEST_MARK();
+
+ TEST_ASSERT_OK(taskDelay(2));
+ TEST_ASSERT_OK(wdCancel(wid));
+ TEST_ASSERT_OK(wdDelete(wid));
+
+ TEST_MARK();
+
+ errno = 0;
+ rc = msgQReceive(int2taskQid,(char *)&msg,sizeof(msg), 0);
+ TEST_ASSERT(rc == sizeof(msg) && msg == 0xaffe);
+
+ TEST_MARK();
+
+}
+
void peerTask (long a0, long a1, long a2, long a3, long a4,
long a5, long a6, long a7, long a8, long a9)
{
@@ -105,6 +166,7 @@
{
int nmsg = 0, qid, rc, msg = 0;
WIND_TCB *pTcb;
+cha
[Xenomai-core] [PATCH] use vmalloc'ed trace buffer
Hi Philippe,
here is the cleaned up and configurable version of my vmalloc hack for
the I-pipe tracer.
As it has a slight performance impact to use virtual memory for the
trace buffer (running "hackbench 10" in parallel to "latency -p 100" on
a 266 MHz P-MMX: 227 vs. 244 s hackbench runtime), I left this option
off by default. If there is any kind of CONFIG combination that cries
for default on, we can easily add it.
Jan
Index: linux-2.6.16.1/kernel/ipipe/Kconfig
===
--- linux-2.6.16.1.orig/kernel/ipipe/Kconfig
+++ linux-2.6.16.1/kernel/ipipe/Kconfig
@@ -34,3 +34,12 @@ config IPIPE_TRACE_SHIFT
---help---
The number of trace points to hold tracing data for each
trace path, as a power of 2.
+
+config IPIPE_TRACE_VMALLOC
+ bool "Use vmalloc'ed trace buffer"
+ depends on IPIPE_TRACE
+ ---help---
+ Instead of reserving static kernel data, the required buffer
+ is allocated via vmalloc during boot-up when this option is
+ enabled. This can help to start systems that are low on memory,
+ but it slightly degrades overall performance.
Index: linux-2.6.16.1/kernel/ipipe/tracer.c
===
--- linux-2.6.16.1.orig/kernel/ipipe/tracer.c
+++ linux-2.6.16.1/kernel/ipipe/tracer.c
@@ -2,7 +2,7 @@
* kernel/ipipe/tracer.c
*
* Copyright (C) 2005 Luotao Fu.
- * 2005 Jan Kiszka.
+ * 2005, 2006 Jan Kiszka.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -86,7 +87,13 @@ enum ipipe_trace_type
};
-int ipipe_trace_enable = 1;
+#ifdef CONFIG_IPIPE_TRACE_VMALLOC
+#define IPIPE_DEFAULT_TRACE_STATE 0
+
+static struct ipipe_trace_path *trace_paths[NR_CPUS];
+
+#else /* !CONFIG_IPIPE_TRACE_VMALLOC */
+#define IPIPE_DEFAULT_TRACE_STATE 1
static struct ipipe_trace_path trace_paths[NR_CPUS][IPIPE_TRACE_PATHS] =
{ [0 ... NR_CPUS-1] =
@@ -94,6 +101,10 @@ static struct ipipe_trace_path trace_pat
{ .begin = -1, .end = -1 }
}
};
+#endif /* CONFIG_IPIPE_TRACE_VMALLOC */
+
+int ipipe_trace_enable = IPIPE_DEFAULT_TRACE_STATE;
+
static int active_path[NR_CPUS] =
{ [0 ... NR_CPUS-1] = IPIPE_DEFAULT_ACTIVE };
static int max_path[NR_CPUS] =
@@ -1097,10 +1108,30 @@ __ipipe_create_trace_proc_val(struct pro
}
}
-void __init __ipipe_init_trace_proc(void)
+void __init __ipipe_init_tracer(void)
{
struct proc_dir_entry *trace_dir;
struct proc_dir_entry *entry;
+#ifdef CONFIG_IPIPE_TRACE_VMALLOC
+ int cpu, path;
+
+ for (cpu = 0; cpu < NR_CPUS; cpu++) {
+ trace_paths[cpu] = vmalloc(
+ sizeof(struct ipipe_trace_path) * IPIPE_TRACE_PATHS);
+ if (!trace_paths) {
+ printk(KERN_ERR "I-pipe: "
+ "insufficient memory for trace buffer.\n");
+ return;
+ }
+ memset(trace_paths[cpu], 0,
+ sizeof(struct ipipe_trace_path) * IPIPE_TRACE_PATHS);
+ for (path = 0; path < IPIPE_TRACE_PATHS; path++) {
+ trace_paths[cpu][path].begin = -1;
+ trace_paths[cpu][path].end = -1;
+ }
+ }
+ ipipe_trace_enable = 1;
+#endif /* CONFIG_IPIPE_TRACE_VMALLOC */
trace_dir = create_proc_entry("trace", S_IFDIR, ipipe_proc_root);
Index: linux-2.6.16.1/include/linux/ipipe.h
===
--- linux-2.6.16.1.orig/include/linux/ipipe.h
+++ linux-2.6.16.1/include/linux/ipipe.h
@@ -329,9 +329,9 @@ void ipipe_init(void);
void ipipe_init_proc(void);
#ifdef CONFIG_IPIPE_TRACE
-void __ipipe_init_trace_proc(void);
+void __ipipe_init_tracer(void);
#else /* !CONFIG_IPIPE_TRACE */
-#define __ipipe_init_trace_proc() do { } while(0)
+#define __ipipe_init_tracer() do { } while(0)
#endif /* CONFIG_IPIPE_TRACE */
#else /* !CONFIG_PROC_FS */
Index: linux-2.6.16.1/kernel/ipipe/core.c
===
--- linux-2.6.16.1.orig/kernel/ipipe/core.c
+++ linux-2.6.16.1/kernel/ipipe/core.c
@@ -1012,8 +1012,9 @@ void ipipe_init_proc(void)
{
ipipe_proc_root = create_proc_entry("ipipe",S_IFDIR, 0);
create_proc_read_entry("version",0444,ipipe_proc_root,&__ipipe_version_info_proc,NULL);
- __ipipe_init_trace_proc();
__ipipe_add_domain_proc(ipipe_root_domain);
+
+ __ipipe_init_tracer();
}
#endif /* CONFIG_PROC_FS */
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://
[Xenomai-core] gcc-4.1 warnings in switchtest
Hi Gilles, I'm seeing this with gcc-4.1: src/testsuite/switchtest/switch.c: In function 'main': src/testsuite/switchtest/switch.c:620: warning: 'params.swt.flags' is used uninitialized in this function src/testsuite/switchtest/switch.c:620: warning: 'params.swt.index' is used uninitialized in this function src/testsuite/switchtest/switch.c:620: warning: 'params.thread' is used uninitialized in this function Real issues or just finickiness? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: GPIO and RTDM
Jim Cromie wrote: > > hi Jan, everyone, > > Ive worked up a patchset to add a GPIO driver for the chip on my mobo. > I adapted an existing one, drivers/char/scx200_gpio, > and created drivers/char/pc8736x_gpio > > When doing this, I _oversimplified_ my problem by disregarding RTDM, > and Im hoping I can just _retrofit_ as needed. From a short glance at scx200_gpio: the only minor difference between registering and handling a Linux GPIO char-device and doing the same under RTDM will be the different naming. RTDM has no direct support for major/minor identification, it uses clear-text names for its devices. So you would have to create the device names on your own. Well, and some locking might be required (full preemptibility!), but this seems to apply to the Linux driver as well under certain kernel configs. But I wonder if it is clever for GPIO devices with a significant number of I/O lines to create a device node for each and every bit! Consider the usage scenario where you want to talk to some n-bit bus using GPIO lines. Would you like to open n devices and issue n writes just to put some n-bit value on that bus? At this chance: Did you have a look at the comedi interface as well? It typically covers far more complexes data acquisition devices, but it should also be usable for simple digital I/O interfaces. Moreover, comedi is available for Linux for quite a while, and a RTDM port is on the way. If comedi means too much overhead for trivial I/O line manipulation, I would welcome any suggestion for a generic GPIO device profile - both mappable on RTDM and normal Linux character devices! > > the chip is on an ISA bus, a user-space C program can read the pins at > (this) rate: > > Wed Jun 14 13:24:13 MDT 2006 > Linux soekris 2.6.17-rc6-gpio-sk #4 Sun Jun 11 20:43:10 MDT 2006 i586 > GNU/Linux > opened /dev/gpio-17, for 1 loops, 100 samples > read 100 samples in 7.8434 sec, rate: 127494.9460 samples/sec > opened /dev/led, for 1 loops, 100 samples > read 100 samples in 5.4116 sec, rate: 184788.5056 samples/sec > > (obviously speed isnt latency, but theres some correlation ..) > > I dont actually have a Real Question, to I'll throw out a placeholder - > > What are the top 3-5 things to do or look at > in order to check the compatibility of my patches with RTDM ? > > > > > Separately.. > > In this GPIO work, I concluded that I needed to add a sysfs interface > to my driver, in order to better fit with LKML expectations. Err, sorry for not seeing this immediately even after (cross-)reading your second mail, but what will the sysfs interface be for? Information, configuration? Do you see concrete usage scenarios for this? > > What I did so far works, and seems to hang together coherently, but > insofar as it > is the 1st time (to my knowledge) that a uniform treatment has been tried, > I might have painted myself / all-of-us into a corner. > > Hopefully not, but you folks have a keener perception of these things. > Ill send shortly. > > tia > jimc Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
