Re: [Xenomai-core] [Xenomai-help] XUM - Xenomai User's Meeting
Am Dienstag 21 Juli 2009 16.05:12 schrieb Wolfgang Denk: [Sorry if you recieved this twice; I posted this information before in the Xenomai groups as a reply in thread RT_PREEMPT patch and other things..., but this did not catch some of the potentially interested eyes, so here it goes again.] We at DENX are trying to organize something like a Xenomai User's Meeting at this year's Real-Time Linux Workshop (September 28 to 30, in Dresden, Germany). Excellent idea. I will try to come. .. Best regards and thanks for your iniative. -- Niklaus Giger Wieshoschet 6 CH-8753 Mollis +41 (0)55 612 20 54 P +41 (0)55 618 64 68 G ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] zombie thread would not die
Hi I successfully ported our basic IO library to Xenomai with the vxWorks skin running on our PPC405GPr based HCU4 (which was accepted into Linux 2.6.28). I just added support for one external interrrupt (occurring every millisecond) and two CAN interrupts (not yet currently activated). Now my program starts up, recognizes the HW but stops sometimes after 5 seconds, sometimes after 30 seconds. Always with a zombie message. Can anyboy tell me, where the error is or what I have to check? I am using svn://svn.gna.org/svn/xenomai/trunk (Revision 4662). uname -a gives Linux hcu4 2.6.28.5-dirty #12 Sun Mar 1 13:45:44 CET 2009 ppc ppc ppc GNU/Linux cat /proc/ipipe/version 2.4-04 cat /proc/interrupts CPU0 16:220 UIC Level serial 17: 7971 UIC Level MAL TX EOB 18: 12537 UIC Level MAL RX EOB 19: 0 UIC Level CAN1 20: 0 UIC Level CAN2 21: 0 UIC Level MAL SERR 22: 0 UIC Level MAL TX DE 23: 0 UIC Level MAL RX DE 24: 0 UIC Level EMAC 25: 0 UIC Level CPLD BAD: 0 Xenomai: fatal: zombie thread iTsk_25 (c18e3e20) would not die... CPU PIDPRI TIMEOUT STAT NAME 0 0 231 000200080 ROOT 0 1032 211(45) 100100184 root 0 1034 231(25) 000100380 tUtilLog 0 1036 246(10) 000100182 tBBprio 0 1039 216(40) 000100182 BSysThreadPool0 0 1040 216(40) 000100182 BSysThreadPool1 0 1041 216(40) 000100182 BSysThreadPool2 0 1042 216(40) 000100182 BSysThreadPool3 0 1043 216(40) 000100182 BSysThreadPool4 0 1044 216(40) 000100182 BSysThreadPool5 0 1045 216(40) 000100182 BSysThreadPool6 0 1046 216(40) 000100182 BSysThreadPool7 0 1047 216(40) 000100182 BSysThreadPool8 0 1048 216(40) 000100182 BSysThreadPool9 0 1049 254(2) 200100186 tBBmsec Master time base: clock=273984265688 Call Trace: [c1a8de50] [c0006c7c] show_stack+0x44/0x16c (unreliable) [c1a8de90] [c00584d8] __xnpod_schedule+0x444/0x634 [c1a8dee0] [c00546b8] xnintr_clock_handler+0x1c4/0x1d8 [c1a8df10] [c004f844] __ipipe_dispatch_wired_nocheck+0x80/0xf4 [c1a8df30] [c0008a74] __ipipe_grab_timer+0x78/0xd4 [c1a8df40] [c0010244] __ipipe_ret_from_except+0x0/0xc Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] vxWorks.skin: Error in taskActivate
Hi While testing my application I found an error in the vxWorks skin. When calling it on my PPC405 system I found that taskInit does not mimick exactly the behaviour. As the WIND_TDB in xenomai/vxworks is just an integer one has to add an ifdef if one wants to use this function properly E.g. I added the following switch in my code status = taskInit (tcb_base,..mor parameters); #ifdef RUNNING_XENOMAI_VXWORKS_SKIN status = taskActivate(*(int *)tcb_base); #else status = taskActivate((int)tcb_base); #endif Is my interpretation correct? Shouldn't this behaviour be documented under doc/skins/vxworks-skin.txt? My proposal is: Index: doc/txt/vxworks-skin.txt === --- doc/txt/vxworks-skin.txt(Revision 4311) +++ doc/txt/vxworks-skin.txt(Arbeitskopie) @@ -13,7 +13,7 @@ The VxWorks (R) emulation module currently mimicks the following services: -taskSpawn, taskInit, taskActivate, taskDelete, taskDeleteForce, taskSuspend, +taskSpawn, taskInit, taskActivate, taskDelete, taskDeleteForce, taskSuspend, taskResume, taskPrioritySet, taskPriorityGet, taskLock, taskUnlock, taskIdSelf, taskSafe, taskUnsafe, taskDelay, taskIdVerify, taskTcb, taskRestart @@ -52,6 +52,12 @@ - taskInit gives a default name if NULL was passed as argument. +- taskInit stores in WIND_TCB pointed by *pTcb a integer, which can be used + in the subsequent call to taskActivate. E.g. change your code from + status = taskActivate((int)pTcb); + to + status = taskActivate(*(int *)pTcb); + - For the moment, the status member of task control blocks is never updated to reflect the status of a task. Best regards Niklaus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] solo/vxWorks: add rngLib (with testsuite)
Am Sonntag 26 Oktober 2008 17.02:08 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
I just found the time to prepare a patch for a substitute for the vxWorks
rngLib library I have written quite some time ago.
..
Thank you for your review. Attached a corrected version of my patch.
But there a some more points, which I would like to discuss.
Fair enough, but we would have to pin all VxWorks tasks to the same CPU on
SMP systems; otherwise, out-of-order memory accesses would kill that code.
Can you do it this?
I am not familiar with this kind of problem as I am still running single
processor boards. But I am quite sure that our next board will have two (or
more) processore cores sitting on it. Though I have quite an interest in
providing a correct solution.
I am not familiar with vxWorks-SMP and therefore I am not sure whether it is a
good idea to pin all vxWorks tasks to one CPU or whether the user should be
able to select the tasks he wants. E.g. you might want only the reader and the
writer of a ring or list on one CPU and other ones to other CPU(s).
..
vxworks/Makefile.in | 18 -
vxworks/rngLib.c| 152
+++ vxworks/rngLib.h|
34 ++
Something must be missing here. vxworks/rngLib.h should contain internal
definitions, used by the ring buffer implementation code, and that is
correct in your code. However, include/vxworks/rngLib.h should provide the
interface to applications; it seems we are missing such a file.
Sorry, I forgot to do git add include/vxworks/rngLib.h, which is attached now
and which provides the (opaque) interface to the vxWorks users.
Since we don't want to export the innards of a ring buffer implementation
to applications, the interface header should only define the opaque ring
buffer handle type (i.e. typedef intptr_t RING_ID), and the RNG routine
prototypes.
..
Please use the linux-c coding style, basically KR + preposterously large
indent tabs (8 chars)
Thank you for code snippets for emacs and ident (did put it into my notes as
it is not the first time I have to deal with such problems).
Emacs can be taught this way:
(defun linux-c-mode ()
C mode with adjusted defaults for use with Xenomai.
(interactive)
(c-mode)
(c-set-style KR)
(setq tab-width 8)
(setq indent-tabs-mode t)
(setq c-basic-offset 8))
Indent will reformat almost properly with (-T should be used to teach
indent about the known non-standard types as well):
$ indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs -cp1
+ ring_mem = malloc( sizeof(RING_DESCRIPTOR*) + nbytes);
The sizeof() argument is wrong. Out-of-bound memory writes are knocking at
the door.
Thanks for catching this error. The following code should be correct.
ring_mem = xnmalloc(sizeof(RING_DESCRIPTOR) + nbytes + 1);
I need 1 additional byte to be able to use only the read/write-position. This
allows that the reader only modifies the readPosition and ther writer only
the writePosition.
Also, please use xnmalloc(). This call will pull memory from the allocator
selected at built time for the SOLO stack, either TLSF, or standard
malloc(). --enable-malloc is false by default (i.e. TLSF enabled).
+ if ( ring_mem == 0) { errno = errnoSet(S_memLib_NOT_ENOUGH_MEMORY);
return 0; } +
Ack.
Please compare pointers to NULL (and return null pointers the same way),
that gives a better hint about the pointerness of the data involved.
Ack.
+ ring = (RING_DESCRIPTOR *) ring_mem;
Cast is useless; let's remove visual clutter as much as we can. Actually,
ring_mem is useless as well; you could optimally work only using the ring
variable directly. Reducing the number of variable hops allows people to
work late at night with half a brain.
Ack.
+ ring-magic = WIND_RING_MAGIC;
+ ring-bufSize = nbytes;
+ ring-readPos = 0;
+ ring-writePos = 0;
Nitpicking alert: line-feed please. It is visually easier to locate the
main return value.
Ack.
+ return (RING_ID) ring_mem;
+}
+
+
+void rngDelete(RING_ID ring_id)
+{
+ RING_DESCRIPTOR *ring = (RING_DESCRIPTOR *) ring_id;
+ if (ring-magic != WIND_RING_MAGIC) return;
Ack.
KR
+ ring-magic = 0;
+ free(ring);
xnfree() is the converse call for xnmalloc().
Ack.
..
linefeed please. Splitting declarations and pure executable statements
makes it easier for the eyes as well.
Ack.
+ if (ring-magic != WIND_RING_MAGIC) return -ENOSYS;
Mm, I guess VxWorks is not even checking there, right? If it does not, then
I would rather raise an assertion when a bad magic is detected, that would
only trigger with --enable-debug/--enable-assert.
It is true, that vxWorks does not use a magic.
What is your prefered way to raise an exception?
+ for (j=0; j maxbytes; j++)
+ {
+ if ((ring-readPos) % (ring-bufSize + 1) == savedWritePos)
ring-readPos should never be out of bounds anyway. Do we
[Xenomai-core] [PATCH] solo/vxWorks: add rngLib (with testsuite)
Hi I just found the time to prepare a patch for a substitute for the vxWorks rngLib library I have written quite some time ago. The remark from the vxWorks description applies here too In particular, ring buffers by themselves provide no task synchronization or mutual exclusion. (http://www.slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/ref/rngLib.html) Therefore this library is only good were there is exactly one writer an one reader envolved. It would be nice if it could find a place in the xenomai-solo. I am willing to address any criticism/nitpicking needed to get it into a good shape. Best regards Signed-off-by: Niklaus Giger [EMAIL PROTECTED] --- include/vxworks/Makefile.am |1 + include/vxworks/Makefile.in |1 + vxworks/Makefile.am |2 + vxworks/Makefile.in | 18 - vxworks/rngLib.c| 152 +++ vxworks/rngLib.h| 34 ++ vxworks/testsuite/Makefile |2 +- vxworks/testsuite/rng-1.c | 118 + 8 files changed, 323 insertions(+), 5 deletions(-) create mode 100644 vxworks/rngLib.c create mode 100644 vxworks/rngLib.h create mode 100644 vxworks/testsuite/rng-1.c diff --git a/include/vxworks/Makefile.am b/include/vxworks/Makefile.am index 06dcab2..0c20861 100644 --- a/include/vxworks/Makefile.am +++ b/include/vxworks/Makefile.am @@ -7,6 +7,7 @@ includesub_HEADERS =\ lstLib.h\ memPartLib.h\ msgQLib.h \ + rngLib.h\ semLib.h\ sysLib.h\ taskInfo.h \ diff --git a/include/vxworks/Makefile.in b/include/vxworks/Makefile.in index 0fdc3c4..ad10fd1 100644 --- a/include/vxworks/Makefile.in +++ b/include/vxworks/Makefile.in @@ -205,6 +205,7 @@ includesub_HEADERS = \ lstLib.h\ memPartLib.h\ msgQLib.h \ + rngLib.h\ semLib.h\ sysLib.h\ taskInfo.h \ diff --git a/vxworks/Makefile.am b/vxworks/Makefile.am index 08e7cc8..a64141e 100644 --- a/vxworks/Makefile.am +++ b/vxworks/Makefile.am @@ -11,6 +11,8 @@ libvxworks_la_SOURCES = \ memPartLib.h\ msgQLib.c \ msgQLib.h \ + rngLib.c\ + rngLib.h\ semLib.c\ semLib.h\ taskLib.c \ diff --git a/vxworks/Makefile.in b/vxworks/Makefile.in index b8d0ce7..2d08bbd 100644 --- a/vxworks/Makefile.in +++ b/vxworks/Makefile.in @@ -57,10 +57,10 @@ libvxworks_la_LIBADD = am_libvxworks_la_OBJECTS = libvxworks_la-errnoLib.lo \ libvxworks_la-intLib.lo libvxworks_la-kernelLib.lo \ libvxworks_la-lstLib.lo libvxworks_la-memPartLib.lo \ - libvxworks_la-msgQLib.lo libvxworks_la-semLib.lo \ - libvxworks_la-taskLib.lo libvxworks_la-taskInfo.lo \ - libvxworks_la-tickLib.lo libvxworks_la-wdLib.lo \ - libvxworks_la-sysLib.lo + libvxworks_la-msgQLib.lo libvxworks_la-rngLib.lo \ + libvxworks_la-semLib.lo libvxworks_la-taskLib.lo \ + libvxworks_la-taskInfo.lo libvxworks_la-tickLib.lo \ + libvxworks_la-wdLib.lo libvxworks_la-sysLib.lo libvxworks_la_OBJECTS = $(am_libvxworks_la_OBJECTS) libvxworks_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ @@ -232,6 +232,8 @@ libvxworks_la_SOURCES = \ memPartLib.h\ msgQLib.c \ msgQLib.h \ + rngLib.c\ + rngLib.h\ semLib.c\ semLib.h\ taskLib.c \ @@ -324,6 +326,7 @@ distclean-compile: @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ [EMAIL PROTECTED]@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @AMDEP_TRUE@@am__include@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ @@ -394,6 +397,13 @@ libvxworks_la-msgQLib.lo: msgQLib.c @AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ @am__fastdepCC_FALSE@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libvxworks_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o libvxworks_la-msgQLib.lo `test -f 'msgQLib.c' || echo '$(srcdir)/'`msgQLib.c +libvxworks_la-rngLib.lo: rngLib.c [EMAIL PROTECTED]@ $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(libvxworks_la_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT libvxworks_la-rngLib.lo -MD -MP -MF $(DEPDIR)/libvxworks_la-rngLib.Tpo -c -o
[Xenomai-core] [PATCH] vxWorks/lstLib: Check for nil-pointer
Here some trivial fixes with their respective tests to handle the case of nil
pointers corrrectly.
Signed-off-by: Niklaus Giger [EMAIL PROTECTED]
---
include/vxworks/lstLib.h |6 +++---
vxworks/lstLib.c |4 +++-
vxworks/testsuite/lst-1.c | 17 +++--
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/include/vxworks/lstLib.h b/include/vxworks/lstLib.h
index b78c2c3..38f0598 100644
--- a/include/vxworks/lstLib.h
+++ b/include/vxworks/lstLib.h
@@ -65,7 +65,7 @@ static inline void lstDelete(LIST *l, NODE *n)
static inline NODE *lstFirst(LIST *l)
{
- if (list_empty(l-list))
+ if (l == NULL || list_empty(l-list))
return NULL;
return list_first_entry(l-list, struct NODE, link);
@@ -75,7 +75,7 @@ static inline NODE *lstGet(LIST *l)
{
struct NODE *n;
- if (list_empty(l-list))
+ if (l == NULL || list_empty(l-list))
return NULL;
n = list_pop_entry(l-list, struct NODE, link);
@@ -100,7 +100,7 @@ static inline void lstInsert(LIST *l, NODE *nprev, NODE *n)
static inline NODE *lstLast(LIST *l)
{
- if (list_empty(l-list))
+ if (l == NULL || list_empty(l-list))
return NULL;
return list_last_entry(l-list, struct NODE, link);
diff --git a/vxworks/lstLib.c b/vxworks/lstLib.c
index 58358f0..56880b4 100644
--- a/vxworks/lstLib.c
+++ b/vxworks/lstLib.c
@@ -44,7 +44,7 @@ NODE *lstNth(LIST *l, int nodenum)
struct holder *holder;
int nth;
- if (nodenum = 0)
+ if (l == 0 || nodenum = 0)
return NULL;
if (nodenum = l-count 2) { /* nodenum is 1-based. */
@@ -89,6 +89,8 @@ int lstFind(LIST *l, NODE *n)
{
struct holder *holder;
int nth = 1;
+ if (l == 0)
+ return ERROR;
list_for_each(holder, l-list) {
if (holder == n-link)
diff --git a/vxworks/testsuite/lst-1.c b/vxworks/testsuite/lst-1.c
index 8b42692..d95d8b8 100644
--- a/vxworks/testsuite/lst-1.c
+++ b/vxworks/testsuite/lst-1.c
@@ -12,16 +12,15 @@ void rootTask(long a0, long a1, long a2, long a3, long a4,
{
NODE first, second, third, fourth;
LIST list;
- int ret;
traceobj_enter(trobj);
-/*
- traceobj_assert(trobj, 0 == lstNth (0, 1));
- traceobj_assert(trobj, 0 == lstFirst(0));
- traceobj_assert(trobj, 0 == lstLast(0));
-*/
- lstInit(list);
+ traceobj_assert(trobj, 0 == lstNth (0, 1));
+ traceobj_assert(trobj, 0 == lstFirst(0));
+ traceobj_assert(trobj, 0 == lstLast(0));
+ traceobj_assert(trobj, 0 == lstGet(0));
+
+ lstInit(list);
traceobj_assert(trobj, 0 == lstCount(list));
traceobj_assert(trobj, NULL == lstFirst(list));
traceobj_assert(trobj, 0 == lstNth(list, 0));
@@ -41,7 +40,7 @@ void rootTask(long a0, long a1, long a2, long a3, long a4,
traceobj_assert(trobj, 2 == lstCount(list));
traceobj_assert(trobj, first == lstFirst(list));
traceobj_assert(trobj, second == lstLast(list));
- traceobj_assert(trobj, NULL == lstPrevious(first)); // breaks here
under xenomai-solo
+ traceobj_assert(trobj, NULL == lstPrevious(first));
traceobj_assert(trobj, 0 == lstNth(list, 0));
traceobj_assert(trobj, first == lstNth(list, 1));
traceobj_assert(trobj, second == lstNth(list, 2));
@@ -127,8 +126,6 @@ void rootTask(long a0, long a1, long a2, long a3, long a4,
traceobj_assert(trobj, 0 == lstNth(list, 4));
traceobj_assert(trobj, 0 == lstNth(list, 5));
- traceobj_assert(trobj, ret == OK);
-
traceobj_exit(trobj);
}
--
1.6.0.2
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Updated ksrc/skins/native/snippet/user_irq.c
Hi
While I struggled to test the Xenomai interrupt handling on my PPC405 system,
I finally found at least a nice example to see that a few things are indeed
working fine.
I attach the modified user_irq.c, which I used to add a custom interrupt
handling routine to the ethernet receive interrupt and propagating it
afterwards to the Linux kernel.
I think it is quite a neat example and should be able to run on a variety of
platforms if the user selects an appropriate IRQ.
Is the attached patch good enough or did I made any mistakes?
Best regards
--
NIklaus Giger
Index: ksrc/skins/native/snippets/user_irq.c
===
--- ksrc/skins/native/snippets/user_irq.c (Revision 4192)
+++ ksrc/skins/native/snippets/user_irq.c (Arbeitskopie)
@@ -1,57 +1,111 @@
+/*
+ * (c) 2008 Niklaus Giger, [EMAIL PROTECTED]
+ *
+ * A small example which shows how to use the native xenomai skin to
+ * catch an interrupt and forward it afterwards to the Linux kernel.
+ *
+ * Take some care to choose the interrupt you want to use.
+ * Use one, which shows up in /proc/interrupts and which has quite few
+ * occurences. E.g. I did choose 18 as my /proc/interrupts looked like
+ * CPU0
+ * 16:194 UIC Level serial
+ * 17: 7932 UIC Level MAL TX EOB
+ * 18: 12895 UIC Level MAL RX EOB
+ * After running the interrupt service routine we will forward the interrupt to
+ * the linux kernel. Therefore no harm should be done by intercepting it.
+ *
+ */
+#define IRQ_NR18
+
#include sys/mman.h
#include native/task.h
#include native/intr.h
+#include unistd.h
+#include stdlib.h
-#define IRQ_NUMBER 7 /* Intercept interrupt #7 */
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
+void cleanup (void);
+
RT_INTR intr_desc;
-
RT_TASK server_desc;
+static int counter;
+
void irq_server (void *cookie)
-
{
-for (;;) {
+ int j;
+ for (;;) {
- /* Wait for the next interrupt on channel #7. */
- err = rt_intr_wait(intr_desc,TM_INFINITE);
-
- if (!err) {
- /* Process interrupt. */
- }
-}
+ /* Wait for the next interrupt. */
+ j = rt_intr_wait(intr_desc,TM_INFINITE);
+ if (j == -EIDRM) {
+ printf(%s: interrupt descriptor deleted. Exit?\n,
+__FUNCTION__);
+ return;
+ }
+ if (j0) {
+ printf(%s: error %d occured. We will exit\n,
+__FUNCTION__, j);
+ return;
+ }
+ /* j is the nr of times the interrupt occured */
+ counter+= j;
+ /* Process interrupt.
+ * Do you have any LED where you can see your progress ?
+ *sysLedSet(counter);
+ */
+ }
}
int main (int argc, char *argv[])
-
{
-int err;
+ int err;
+ atexit(cleanup);
+ mlockall(MCL_CURRENT|MCL_FUTURE);
-mlockall(MCL_CURRENT|MCL_FUTURE);
-
-/* ... */
-
-err = rt_intr_create(intr_desc,MyIrq,IRQ_NUMBER,0);
-
-/* ... */
-
-err = rt_task_create(server_desc,
- MyIrqServer,
- TASK_STKSZ,
- TASK_PRIO,
- TASK_MODE);
-if (!err)
- rt_task_start(server_desc,irq_server,NULL);
-
-/* ... */
+ /* Do not forget to pass I_PROPAGATE as the last parameter
+ * or your Linux will hang or not function properly.
+ * You have be warned!!
+ */
+ err = rt_intr_create(intr_desc,myIrq,IRQ_NR, I_PROPAGATE);
+ if (err == -ENOSYS) {
+ printf(%s: rt_intr_create returned ENOSYS\n, __FUNCTION__);
+ printf(Did your forget to set CONFIG_XENO_OPT_NATIVE_INTR\n);
+ printf(in the kernel config under:\n);
+ printf(Real-Time Subsystem..Interfaces..Native-API..\n);
+ return 2;
+ }
+ if (err) {
+ printf(%s: rt_intr_create failed with error %d\n,
+ __FUNCTION__, err);
+ return 2;
+ }
+ err = rt_task_create(server_desc,
+MyIrqServer,
+TASK_STKSZ,
+TASK_PRIO,
+TASK_MODE);
+ if (err) {
+ printf(%s: rt_task_create failed with error %d\n,
+ __FUNCTION__, err);
+ return 2;
+ }
+ printf(ISR test program: Started successfully the irq task\n);
+ printf(Please generate some interrupts on IRQ %d.\n,
+ IRQ_NR);
+ printf(Number of interrupts serviced will be shown in 10 seconds.\n);
+ err = rt_task_start(server_desc,irq_server, 0xbeef);
+ sleep(10); /* or do you prefer pause() to wait for Ctrl-C ? */
+ printf(All okay. Did see %d interrupts\n, counter);
+ return 0;
}
void cleanup (void)
-
{
-rt_intr_delete(intr_desc);
-rt_task_delete(server_desc);
+ rt_intr_delete(intr_desc);
+ rt_task_delete(server_desc);
+ printf(Cleaning up. Did see %d interrupts\n, counter);
}
/*
* (c) 2008 Niklaus Giger, [EMAIL PROTECTED]
*
* A small example which shows how to use the native xenomai skin to
* catch an interrupt and forward it afterwards to the Linux kernel.
*
* Take some care to choose the interrupt you want to use.
* Use one, which shows up in /proc/interrupts and which has quite few
* occurences. E.g. I did choose 18 as my /proc/interrupts looked like
* CPU0
* 16:194 UIC
Re: [Xenomai-core] Problems using rt_intr_wait on PowerPC
Hi
I still could not figure out, what is going wrong. It seem that no
interrupt is coming through. I would appreciate if anybody could take
a look at the attached program.
Since yesterday I fixed the following two errors:
rt_intr_create returned ENOSYS, as CONFIG_XENO_OPT_NATIVE_INTR was
not enabled.
Secondly I erronously ignored the -EIDRM return value from rt_intr_wait.
I am puzzled that (as seen on this input) that rt_intr_enable returns ENODEV.
It seems that is used to check the validity include/asm-powerpc/wrappers.h
but I cannot figure out the reason why it fails.
main: counter1 0 errors 0 irq_number 25
main: rt_intr_create returns 0 ENOSYS ist 38
main: rt_task_create returns 0
main: before enabling interrupts
enableInt: rt_intr_enable failed -19 ENODEV 19
irq_server: Starting. intrDesc 0x10048184 cookie 0xbeef
main: rt_task_start returns 0
enableInt: rt_intr_enable failed -19 ENODEV 19
main: counter 0 errors 0 done
irq_server: deleted interrupt object descriptor -43
cleanup: counter 0 errors 0 done
What I see however in /proc/interrupts that my interrupt 25
does not show up, e.g.
cat /proc/interrupts
CPU0
16: 2371 UIC Level serial
17: 8996 UIC Level MAL TX EOB
18: 14879 UIC Level MAL RX EOB
19: 0 UIC Level MAL SERR
20: 0 UIC Level MAL TX DE
21: 0 UIC Level MAL RX DE
22: 0 UIC Level EMAC
BAD: 0
I am a little bit confused about what I have to do to get my interrupt
handler working.
Best regards
Am Sonntag 28 September 2008 23.21:24 schrieb Niklaus Giger:
Hi
Based on the user_irq.c I created a simple test program for my PPC405GPr
board.
We have a FPGA which generates an interrupt every millisecond.
It seems to work as simple test (fire it once and assure that it
sets the interrupt-bit).
When I connect it to the irq_server however (letting the main task
sleep 1 second) I get around 2321964 error and not a single OK from
rt_intr_wait.
Also my debug LED flicker very fast.
Th
The FPGA is connected to the External Interrupt 0, which has the number 25.
I think that I either got the polarity/level/edge register wrong or
I am playing with the wrong interrupt.
Could anybody tell me, whether I used the correct interrupt number?
Does Linux somewhere overwrite the values for the UIC polarity/level, etc
settings written by U-Boot (e.g. for my board in board_early_init_f)
Any hints are welcome.
Best regards
--
NIklaus Giger
#include sys/mman.h
#include native/task.h
#include native/intr.h
#include bsp_def.h
#include unistd.h
#include stdlib.h
#define TASK_PRIO 99 /* Highest RT priority */
#define TASK_MODE 0 /* No flags */
#define TASK_STKSZ 0 /* Stack size (use default one) */
RT_INTR intr_desc;
RT_TASK server_desc;
static int counter, errCounter;
int s_tickResetValue = TICK_INT_ENABLE | TICK_INT_RESET | TICK_START | TICK_INTERVAL_1000_US;
int s_tickEnableValue = TICK_INT_ENABLE | TICK_START | TICK_INTERVAL_1000_US;
void cleanup (void);
void enableInt()
{
int err;
sys_set_tick_control_register_value(TICK_INT_RESET);
sys_set_tick_control_register_value(s_tickResetValue);
sys_set_tick_control_register_value(s_tickEnableValue);
err = rt_intr_enable(intr_desc);
printf(%s: rt_intr_enable failed %d ENODEV %d\n, __FUNCTION__, err, ENODEV);
}
void irq_server (void *cookie)
{
int err;
printf(%s: Starting. intrDesc %p cookie %p\n, __FUNCTION__, intr_desc, cookie);
for (;;) {
/* Wait for the next interrupt on channel #7. */
err = rt_intr_wait(intr_desc,TM_INFINITE);
if (err == -EIDRM) { printf(%s: deleted interrupt object descriptor %d\n, __FUNCTION__, err); return; }
if (err) errCounter++;
else {
/* Process interrupt. */
counter++;
sys_set_tick_control_register_value(s_tickResetValue);
sys_set_tick_control_register_value(s_tickEnableValue);
}
sysLedSet((errCounter+counter)/1000);
if ((counter + errCounter) 80)
{
printf(%s: Done. counter1 %d errors %d\n, __FUNCTION__, counter, errCounter);
return;
}
}
}
int main (int argc, char *argv[])
{
int err;
int irq_number;
atexit(cleanup);
mlockall(MCL_CURRENT|MCL_FUTURE);
bsp_init();
irq_number = sys_get_imc_interrupt_vector(IMC_BUS_INTERRUPT_0);
counter = 0;
errCounter = 0;
sysLedSet(3);
printf(%s: counter1 %d errors %d irq_number %d\n, __FUNCTION__, counter, errCounter,irq_number);
err = rt_intr_create(intr_desc,Ext Int 0,irq_number, 0);
printf(%s: rt_intr_create returns %d ENOSYS ist %d\n, __FUNCTION__, err, ENOSYS);
if (err) {
printf(%s: rt_intr_create failed %d ENOSYS ist %d\n, __FUNCTION__, err, ENOSYS);
printErrno(-err);
return 2;
}
err = rt_task_create(server_desc,
MyIrqServer,
TASK_STKSZ,
TASK_PRIO,
TASK_MODE);
printf(%s: rt_task_create returns %d\n, __FUNCTION__, err);
if (err) {
printf(%s: rt_task_create failed %d\n, __FUNCTION__, err);
printErrno(-err
[Xenomai-core] Problems using rt_intr_wait on PowerPC
Hi Based on the user_irq.c I created a simple test program for my PPC405GPr board. We have a FPGA which generates an interrupt every millisecond. It seems to work as simple test (fire it once and assure that it sets the interrupt-bit). When I connect it to the irq_server however (letting the main task sleep 1 second) I get around 2321964 error and not a single OK from rt_intr_wait. Also my debug LED flicker very fast. The FPGA is connected to the External Interrupt 0, which has the number 25. I think that I either got the polarity/level/edge register wrong or I am playing with the wrong interrupt. Could anybody tell me, whether I used the correct interrupt number? Does Linux somewhere overwrite the values for the UIC polarity/level, etc settings written by U-Boot (e.g. for my board in board_early_init_f) Any hints are welcome. Best regards -- NIklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] xenomai-solo-vxWorks: Calling sem Give twice on a binary semaphore should not return an er ror
Hi
Thanks a lot. This patch does indeed fix my problem.
Best regards
Niklaus
Am Montag 22 September 2008 16.49:01 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
Examining errors in my big testsuite I discovered that giving a second
time a binary semaphore xenomai returns an error where vxWorks reports
OK.
Thanks for reporting. That patch should fix this issue:
diff --git a/vxworks/semLib.c b/vxworks/semLib.c
index 62f9326..6467354 100644
--- a/vxworks/semLib.c
+++ b/vxworks/semLib.c
@@ -104,8 +104,11 @@ static STATUS xsem_give(struct wind_sem *sem)
if (syncobj_lock(sem-u.xsem.sobj, syns))
return S_objLib_OBJ_ID_ERROR;
- if (sem-u.xsem.value = sem-u.xsem.maxvalue)
- ret = S_semLib_INVALID_OPERATION;
+ if (sem-u.xsem.value = sem-u.xsem.maxvalue) {
+ if (sem-u.xsem.maxvalue == INT_MAX)
+ /* No wrap around. */
+ ret = S_semLib_INVALID_OPERATION;
+ }
else if (++sem-u.xsem.value = 0)
syncobj_post(sem-u.xsem.sobj);
See the attached test case.
sudo ../../bin/BSys/mak/xeno_vx-solo/debug/tst
assert passed at testTask line 65
assert passed at testTask line 66
assert failed at testTask line 67
testTask done
Xenomai/SOLO: failed to remove registry mount point /mnt/xenomai/4569
(errno=16)
Best regards
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
NIklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Adding some .gitignore
After a ./configure in my git clone, git status cluttered my screen withe a lot of uninteresting files. In order to get rid of them I created the attached .gitignore files. Signed-off-by: Niklaus Giger [EMAIL PROTECTED] --- .gitignore | 47 ++ base/.gitignore |8 +++ config/.gitignore|9 include/.gitignore |8 +++ include/psos/.gitignore |8 +++ include/vxworks/.gitignore |8 +++ include/xenomai/.gitignore |8 +++ psos/.gitignore |8 +++ scripts/.gitignore |9 vxworks/.gitignore |8 +++ vxworks/testsuite/.gitignore | 10 + 11 files changed, 131 insertions(+), 0 deletions(-) create mode 100644 .gitignore create mode 100644 base/.gitignore create mode 100644 config/.gitignore create mode 100644 include/.gitignore create mode 100644 include/psos/.gitignore create mode 100644 include/vxworks/.gitignore create mode 100644 include/xenomai/.gitignore create mode 100644 psos/.gitignore create mode 100644 scripts/.gitignore create mode 100644 vxworks/.gitignore create mode 100644 vxworks/testsuite/.gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..af911eb --- /dev/null +++ b/.gitignore @@ -0,0 +1,47 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Normal rules +# + +*.rej +*.orig +*.a +*.o +*~ +*.la +*.lo + +# +# Top-level generic files +# + +# +# Generated files +# +/conf2* +*.depend +.deps +.libs +*.lineno +libtool +config.log +/Makefile +stamp-h1 +xeno_config.h +config.status + +# for output of format-patch +00* + +# stgit generated dirs +patches-* + +# quilt's files +patches +series + +# cscope files +cscope.* diff --git a/base/.gitignore b/base/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/base/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/config/.gitignore b/config/.gitignore new file mode 100644 index 000..e96352c --- /dev/null +++ b/config/.gitignore @@ -0,0 +1,9 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile +*.lineno diff --git a/include/.gitignore b/include/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/include/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/include/psos/.gitignore b/include/psos/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/include/psos/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/include/vxworks/.gitignore b/include/vxworks/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/include/vxworks/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/include/xenomai/.gitignore b/include/xenomai/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/include/xenomai/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/psos/.gitignore b/psos/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/psos/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile diff --git a/scripts/.gitignore b/scripts/.gitignore new file mode 100644 index 000..d618ccb --- /dev/null +++ b/scripts/.gitignore @@ -0,0 +1,9 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files +# +/Makefile +xeno-config diff --git a/vxworks/.gitignore b/vxworks/.gitignore new file mode 100644 index 000..13daaa8 --- /dev/null +++ b/vxworks/.gitignore @@ -0,0 +1,8 @@ +# +# NOTE! Don't add files that are generated in specific +# subdirectories here. Add them in the .gitignore file +# in that subdirectory instead. +# +# Generated files
[Xenomai-core] [PATCH] vxworks: Adding tests for lstLib
While testing I found that the behaviour of lstLib is not mimicked
correctly by Xenomai-Solo.
I wrote a simple testsuite which passed all assertions on my
vxWorks 6.6 system. It compiles under xxWorks and xenomai-solo.
I do not object, if you remove the conditional __SOLO__. Personally I
appreciate if I am able to run my testsuits without manual changes under
xenomai-solo and vxworks.
At the moment they fail miserably under xenomai-solo.
It does not test splitting/merging lists.
Signed-off-by: Niklaus Giger [EMAIL PROTECTED]
---
vxworks/testsuite/Makefile |2 +-
vxworks/testsuite/lst-1.c | 190
2 files changed, 191 insertions(+), 1 deletions(-)
create mode 100644 vxworks/testsuite/lst-1.c
diff --git a/vxworks/testsuite/Makefile b/vxworks/testsuite/Makefile
index 4967151..d1ce203 100644
--- a/vxworks/testsuite/Makefile
+++ b/vxworks/testsuite/Makefile
@@ -5,7 +5,7 @@ ifeq ($(prefix),)
$(error Please add xenomai-install-path/bin to your PATH variable)
endif
-TESTS := task-1 task-2 msgQ-1 msgQ-2 msgQ-3 wd-1 sem-1 sem-2 sem-3 sem-4
+TESTS := task-1 task-2 msgQ-1 msgQ-2 msgQ-3 wd-1 sem-1 sem-2 sem-3 sem-4
lst-1
CFLAGS := $(shell $(XENO_CONFIG) --cflags) -g
LDFLAGS := -lvxworks $(shell $(XENO_CONFIG) --ldflags)
diff --git a/vxworks/testsuite/lst-1.c b/vxworks/testsuite/lst-1.c
new file mode 100644
index 000..2b19511
--- /dev/null
+++ b/vxworks/testsuite/lst-1.c
@@ -0,0 +1,190 @@
+#ifdef __SOLO__
+#include stdio.h
+#include stdlib.h
+#include xenomai/traceobj.h
+#include vxworks/errnoLib.h
+#include vxworks/taskLib.h
+#include vxworks/lstLib.h
+
+static struct traceobj trobj;
+
+static int tseq[] = {
+ 10, 11, 12, 13, 20,
+ 1, 14, 15, 2, 3, 4,
+ 5, 6, 7, 8, 16, 17, 18,
+ 9, 21, 19
+};
+#else
+#include stdio.h
+#include unistd.h
+#include stdlib.h
+#include errnoLib.h
+#include taskLib.h
+#include semLib.h
+
+#define traceobj_init(a, b, c)
+#define traceobj_enter(trobj)
+#define traceobj_exit(trobj)
+#define traceobj_join(trobj)
+
+static int nrPassed;
+
+#define traceobj_assert(obj, cond) \
+ if (cond) nrPassed ++; \
+ else printf(assert failed at %s line %d\n, __FUNCTION__, __LINE__);\
+
+#define traceobj_mark(a, b)
+#define traceobj_verify(a, b, c)
+#endif
+
+void rootTask(long a0, long a1, long a2, long a3, long a4,
+ long a5, long a6, long a7, long a8, long a9)
+{
+ int ret;
+
+ traceobj_enter(trobj);
+
+ traceobj_mark(trobj, 1);
+
+LIST list;
+NODE first, second, third, fourth;
+traceobj_assert(trobj, 0 == lstNth (0, 1));
+/*
+traceobj_assert(trobj, 0 == lstFirst(0));
+traceobj_assert(trobj, 0 == lstLast(0));
+ */
+lstInit(list);
+traceobj_assert(trobj, 0 == lstCount(list));
+traceobj_assert(trobj, 0 == lstFirst(list));
+traceobj_assert(trobj, 0 == lstNth (list, 0));
+traceobj_assert(trobj, 0 == lstNth (list, 1));
+
+lstAdd(list, first);
+traceobj_assert(trobj, 1 == lstCount(list));
+traceobj_assert(trobj, first == lstFirst(list));
+traceobj_assert(trobj, first == lstLast(list));
+traceobj_assert(trobj, 0 == lstPrevious (first));
+traceobj_assert(trobj, 0 == lstNext (first));
+traceobj_assert(trobj, 0 == lstNth (list, 0));
+traceobj_assert(trobj, first == lstNth (list, 1));
+traceobj_assert(trobj, 0 == lstNth (list, 2));
+
+lstAdd(list, second);
+traceobj_assert(trobj, 2 == lstCount(list));
+traceobj_assert(trobj, first == lstFirst(list));
+traceobj_assert(trobj, second == lstLast(list));
+traceobj_assert(trobj, 0 == lstPrevious (first)); // breaks here under
xenomai-solo
+traceobj_assert(trobj, 0 == lstNth (list, 0));
+traceobj_assert(trobj, first == lstNth (list, 1));
+traceobj_assert(trobj, second == lstNth (list, 2));
+traceobj_assert(trobj, 0 == lstNth (list, 3));
+
+lstAdd(list, third);
+traceobj_assert(trobj, 3 == lstCount(list));
+traceobj_assert(trobj, 0 == lstPrevious (first));
+traceobj_assert(trobj, third == lstLast(list));
+traceobj_assert(trobj, 0 == lstNth (list, 0));
+traceobj_assert(trobj, first == lstNth (list, 1));
+traceobj_assert(trobj, second == lstNth (list, 2));
+traceobj_assert(trobj, third == lstNth (list, 3));
+traceobj_assert(trobj, 0 == lstNth (list, 4));
+
+lstAdd(list, fourth);
+traceobj_assert(trobj, 4 == lstCount(list));
+traceobj_assert(trobj, 0 == lstPrevious (first));
+traceobj_assert(trobj, fourth == lstLast(list));
+traceobj_assert(trobj, 0 == lstNth (list, 0));
+traceobj_assert(trobj, first == lstNth (list, 1));
+traceobj_assert(trobj, second == lstNth (list, 2));
+traceobj_assert(trobj, third == lstNth (list, 3));
+traceobj_assert(trobj, fourth == lstNth (list, 4));
+traceobj_assert(trobj, 0 == lstNth (list, 5));
+
+lstDelete(list, third);
+traceobj_assert(trobj, 3 == lstCount(list));
+traceobj_assert(trobj, 0 == lstPrevious
[Xenomai-core] xenomai-solo-vxWorks: Calling semGive twice on a binary semaphore should not return an error
Hi
Examining errors in my big testsuite I discovered that giving a second
time a binary semaphore xenomai returns an error where vxWorks reports OK.
See the attached test case.
sudo ../../bin/BSys/mak/xeno_vx-solo/debug/tst
assert passed at testTask line 65
assert passed at testTask line 66
assert failed at testTask line 67
testTask done
Xenomai/SOLO: failed to remove registry mount point /mnt/xenomai/4569
(errno=16)
Best regards
--
NIklaus Giger
#include stdio.h
#include unistd.h
#include stdlib.h
#define assert(cond) \
if (!cond) printf(assert failed at %s line %d\n, __FUNCTION__, __LINE__); \
else printf(assert passed at %s line %d\n, __FUNCTION__, __LINE__);
#if defined(__SOLO__) || defined(_WRS_VXWORKS_MAJOR)
// #include vxWorks.h
#include semLib.h
#include taskLib.h
#include tickLib.h
#include kernelLib.h
#include errnoLib.h
void testTask(long a1, long a2, long a3, long a4, long a5,
long a6, long a7, long a8, long a9, long a10);
bool finished;
extern C void task1(long int, long int, long int, long int, long int, long int, long int, long int, long int, long int)
{
assert(1);
taskDelay(30);
assert(2);
finished = true;
}
#endif
/**
* Main functions
*/
#if defined(PLAT_VXWORKS) || defined(_WRS_VXWORKS_MAJOR)
extern C int tSysMain(const char* arg)
{
const char* argv[2];
argv[0] = undefined;
argv[1] = arg;
int argc = sizeof(argv) / sizeof(char*);
#else
int main(int argc, char *const argv[])
{
#endif
#ifdef __SOLO__
kernelInit(testTask, argc, argv);
while(!finished) { sleep(1); }
exit(0);
}
void testTask(long a1, long a2, long a3, long a4, long a5,
long a6, long a7, long a8, long a9, long a10)
{
int argc=0; char *const argv[]={0};
#endif
// Initialisierung
SEM_ID testBSem1 = semBCreate (0, SEM_EMPTY);
assert(semTake(testBSem1, 10) == ERROR); // Empty
assert(semGive(testBSem1) == OK);
assert(semGive(testBSem1) == OK);// wie VxWorks
printf(%s done\n, __FUNCTION__);
#ifdef __SOLO__
finished = true;
return;
#else
return 0;
#endif
}
// ___
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] xenomai-solo vxWorks: know whether a task is safe or not
Hi
For various reasons we were forced to examine under vxWorks 5.5 the private
WIND_TCB safeCnt field to determine whether a task was safe or not.
With the attached patch I try to add a taskIsSafe procedure to xenomai-solo.
It is probably not free from race condition, as I do not know how to access
a pthread_mutex.
Would such (may be improved) patch find its way into the official trunk?
Best regards
--
NIklaus Giger
diff --git a/include/vxworks/taskInfo.h b/include/vxworks/taskInfo.h
index 61315d5..27b3cc6 100644
--- a/include/vxworks/taskInfo.h
+++ b/include/vxworks/taskInfo.h
@@ -50,6 +50,8 @@ TASK_ID taskNameToId(const char *name);
TASK_ID taskIdDefault(TASK_ID task_id);
+BOOL taskIsSafe(TASK_ID task_id);
+
BOOL taskIsReady(TASK_ID task_id);
BOOL taskIsSuspended (TASK_ID task_id);
diff --git a/vxworks/taskLib.c b/vxworks/taskLib.c
index f6253b2..7dd52ae 100644
--- a/vxworks/taskLib.c
+++ b/vxworks/taskLib.c
@@ -595,7 +595,7 @@ STATUS taskSafe(void)
}
pthread_mutex_lock(current-safelock);
-
+ current-safeCnt = 1;
return OK;
}
@@ -615,11 +615,24 @@ STATUS taskUnsafe(void)
return ERROR;
}
+ current-safeCnt = 0;
pthread_mutex_unlock(current-safelock);
return OK;
}
+BOOL taskIsSafe(TASK_ID tid)
+{
+ struct wind_task *task = find_wind_task(tid);
+
+ if (task == NULL) {
+ errno = S_objLib_OBJ_ID_ERROR;
+ return ERROR;
+ }
+
+ return (task-safeCnt 0);
+}
+
STATUS taskIdVerify(TASK_ID tid)
{
struct wind_task *task = find_wind_task(tid);
diff --git a/vxworks/taskLib.h b/vxworks/taskLib.h
index 299d059..f743270 100644
--- a/vxworks/taskLib.h
+++ b/vxworks/taskLib.h
@@ -42,6 +42,7 @@ struct wind_task_args {
struct wind_task {
pthread_mutex_t safelock;
+ int safeCnt;
sem_t barrier;
struct WIND_TCB *tcb;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] SOLO: Too limited priorities for vxWorks threads
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range
[-2..0]
looking at the code I found at taskLib.c
263 {
264 if (wind_prio 0 || wind_prio 255) /* In theory. */
265 return S_taskLib_ILLEGAL_PRIORITY;
266
267 if (wind_prio = threadobj_max_prio - 1) /* In practice. */
268 panic(current implementation restricts VxWorks
269 priority levels to range [%d..0],
270 threadobj_max_prio - 2);
271 return OK;
Therefore I seem to have only the option of priority 0 which is way too limited.
I took a look at vxworks/testsuite/task-1.c and found that it spawns a task
with priority 70. Calling make check compiled a few more files but did not run
any checks.
After calling make in vxworks/testsuite and callling ./task-1 I got the same
error.
I am running the (unpatched) Debian kernel 2.6.24-1-686, as I just wanted to
run some test without requiring any realtime behaviour. Reading
http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=blob;f=README
I found the sentence SOLO may also be used with non-PREEMPT_RT kernels, likely
for basic debugging tasks which do not involve strict real-time requirements
and concluded therefore that I should be able to use for my test a normal
kernel.
As glibc I use the Debian lenny version 2.7-10.
Best regards
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads
Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi
I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to
range [-2..0]
looking at the code I found at taskLib.c
263 {
264 if (wind_prio 0 || wind_prio 255) /* In theory. */
265 return S_taskLib_ILLEGAL_PRIORITY;
266
267 if (wind_prio = threadobj_max_prio - 1) /* In practice. */
268 panic(current implementation restricts VxWorks
269 priority levels to range [%d..0],
270 threadobj_max_prio - 2);
271 return OK;
Therefore I seem to have only the option of priority 0 which is way too
limited.
The SOLO version is purely Linux native, so you only get what the underlying
kernel provides you, including in terms of available priority scales. Since RT
threads are members of the SCHED_FIFO class, you get 99 priority levels,
unless
you patch the vanilla kernel to handle more. The way to solve this properly
for
SOLO is to write a patch against PREEMPT_RT that allows wider priority scales,
and to get it merged upstream.
Sorry, but you did not get my point. I tried to call it with priority 50, which
should be in this range, which I verified with gdb
(gdb) info stack
#0 panic (fmt=0xb7eebb90 current implementation restricts VxWorkspriority
levels to range [%d..0]) at panic.c:45
#1 0xb7eea1ac in check_task_priority (wind_prio=50) at taskLib.c:268
#2 0xb7eea1d9 in __taskInit (task=0x9eda0e0, tcb=0x9eda10c, name=0xbfc43760
BSysAsyncTimerMgrThread, prio=50, flags=0,
entry=0x81281c4 BSysOsWrapperThread_callback(int), stacksize=51200) at
taskLib.c:284
...
I am happy with the rang 0.99 and also will no run any latency tests, as
xenomai-SOLO is for me at the moment just a test bed to check for compiler
error etc, as at the moment I have no running powerpc kernel for my PPC440
target.
Best regards
--
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Errors running simulator test tmq
Hi Since quite some time there is a error running the simulator test: The daily build reports (e.g. http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/80/steps/check_sim/logs/stdio) Will call tmq Xenomai/sim: real-time nucleus v2.5-devel (Flying In A Blue Dream) loaded. starting POSIX services. Xenoscope: lt-tmq: fatal in MvmIrq (time=40838.314452): test interrupted by watchdog. I have no ideas why the builds after each check-in give me also errors like (e.g. http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/170/steps/check_sim/logs/stdio) vxworks-trestart:: starting VxWorks services. vxworks-t010726-2:: starting VxWorks services. vxworks-t010820-1:: starting VxWorks services. vxworks-t010823-2:: starting VxWorks services. I will investigate this problem later Best regard Niklaus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Errors building tarball
Hi My HCU3 daily build (which is the only one to build a tarball) reports the following error when running distcheck (see http://ngiger.dyndns.org/buildbot/builders/hcu3_f/builds/75/steps/tarball/logs/stdio): /home/buildbot/slave/hcu3_f/xenomai/configure successfull Exec in /home/buildbot/slave/hcu3_f/build_dist: make SUDO=false distcheck make: *** No rule to make target `debian/xenomai.postinst', needed by `distdir'. Stop. make SUDO=false distcheck failed Commands were rm -rf /home/buildbot/slave/hcu3_f/build_dist /home/buildbot/slave/hcu3_f/xenomai/configure make SUDO=false distcheck Best regards Niklaus ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Still an error in the simulator for v2.3.x
Hi Philippe fixed the error I reported in less than 6 minutes. Wonderful work! But my buildbot machines are a lot slower and take almost one hour for all builds. But now the simulator gives on the v2.3 branch again one of (rather silly and easily corrected errors) like this: Some problems were reported in: vxworks-t010823-2:../../../../xenomai/sim/skins/vxworks/testsuite/t010823-2.c:163: Expected sequence: SEQ(Test2,2004); got SEQ(Test2,1954) vxworks-t010823-2: ../../../../xenomai/sim/skins/vxworks/testsuite/t010823-2.c:166, test finished: 1 failures/ 33 tests For Details look at http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/29/steps/check_sim/logs/stdio and http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/29 The other builds for the 2.3.x branch are okay. The failures from i386 and tqm will be fixed by correcting the buildbot configuration. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot: Error building sim on branch 2.3
Hi Thanks everybody for helping to clean up the errors! I have a lot more successful build now than three days ago. As soon as I have some more time to spend on the buildbot. I will try to cleanup the remaining failures which are probably more problems with the buildbot setup than in the xenomai source. But the sim has a regression (only in the 2.3 branch) as shown in http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/26 http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/26/steps/make_sim/logs/stdio building the simulator failed with: make[1]: Entering directory `/var/buildbot/slave/sim_q/build/nucleus' ../gcic/gcic -DHAVE_CONFIG_H -I. -I../include -I../../xenomai/sim/nucleus -D__IN_XENO__ --gcic-backend=/var/buildbot/test/bin/sim/libexec/gcic --kernel-code -I../../xenomai/sim/nucleus/../include -I../../xenomai/sim/../include -g -MT heap.o -MD -MP -MF .deps/heap.Tpo -c -o heap.o ../../xenomai/sim/../ksrc/nucleus/heap.c ../../xenomai/sim/../ksrc/nucleus/heap.c: In function `xnheap_alloc': ../../xenomai/sim/../ksrc/nucleus/heap.c:491: `CONFIG_XENO_OPT_DEBUG_NUCLEUS' undeclared (first use in this function) ../../xenomai/sim/../ksrc/nucleus/heap.c:491: (Each undeclared identifier is reported only once ../../xenomai/sim/../ksrc/nucleus/heap.c:491: for each function it appears in.) ../../xenomai/sim/../ksrc/nucleus/heap.c: In function `xnheap_test_and_free': ../../xenomai/sim/../ksrc/nucleus/heap.c:698: `CONFIG_XENO_OPT_DEBUG_NUCLEUS' undeclared (first use in this function) make[1]: *** [heap.o] Fehler 1 make[1]: Leaving directory `/var/buildbot/slave/sim_q/build/nucleus' The build #27 for the v.2.4 branch completed successfully as shown in http://ngiger.dyndns.org/buildbot/builders/sim_q/builds/27. No problems with the trunk neither as shown in http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/4 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot is back (and reporting errors)
Hi Am Sonntag, 23. Dezember 2007 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Are you sure these errors are related to Xenomai, do not you get the same errors if you build the kernel without Xenomai enabled ? Also, you should tell us which versions of Linux you used, and post a link to the kernel configuration. I tweaked the buildbot to also produce a link to the config used. Is it better for you if I post only the link to a failed build like http://ngiger.dyndns.org/buildbot/builders/tqm_f/builds/ or http://ngiger.dyndns.org/buildbot/builders/ppc_q/builds/22 There you can by clicking on the link go to the stdio of the failing step to the standard output. You find also in the same step (or for the tqm case in the step before) a link to 'config'. On the same page you get also info about the revision and branch used of the Xenomai tree. With the link to 'cmd2run' you get info about which linux version the buildbot uses. Aggregating all this information into one single page would demand quite some effort. I am at this moment not sure whether it is worth the effort, but once running the tests on my board is incorporated into the buildbot, I will take another look at this challenge. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot is back (and reporting errors)
Am Sonntag, 23. Dezember 2007 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: a) The simulator fails in two tests with the vxworks skins. In http://ngiger.dyndns.org/buildbot/builders/sim_f/builds/1/steps/check_sim/logs/stdio you will find at the end the lines Some problems were reported in: vxworks-t010726-1:: vxworks-t010823-2:: Going back one finds: starting VxWorks services. Xenoscope: lt-t010823-2: fatal in MvmIrq (time=3718.974563): test interrupted by watchdog. and starting VxWorks services. Xenoscope: lt-t010726-1: fatal in MvmIrq (time=3718.974820): test interrupted by watchdog. The problem is that the root task priority is 0, and that now, 0 is a priority with a special meaning. However, VxWorks priority range is from 0 to 255, not from 1 to 255. Usually only the excTask runs with priority 0 on a vxWorks system. I would therefore suggest that we forbid starting a vxworks task with priority 0. If a error is returned and this exception is documented in the doc/txt/vxworks-skin.txt I could live with it without any problems. Thanks anyway for your explanation. -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot: sim fails ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined
Hi Since February 12 building the sim fails with if ../gcic/gcic -DHAVE_CONFIG_H -I. -I. -I../include -D__IN_XENO__ --gcic-backend=/var/buildbot/bin/sim/libexec/gcic --kernel-code -I./../include -I../../include -g -MT pod.o -MD -MP -MF .deps/pod.Tpo -c -o pod.o ../../ksrc/nucleus/pod.c; \ then mv -f .deps/pod.Tpo .deps/pod.Po; else rm -f .deps/pod.Tpo; exit 1; fi ../../ksrc/nucleus/pod.c:59: warning: parameter names (without types) in function declaration ../../ksrc/nucleus/pod.c:59: warning: data definition has no type or storage class ../../ksrc/nucleus/pod.c: In function `xnpod_suspend_thread': ../../ksrc/nucleus/pod.c:1440: label `unlock_and_exit' used but not defined make[1]: *** [pod.o] Fehler 1 make[1]: Leaving directory `/var/buildbot/slave/sim_f/build/sim/nucleus' For details look at: http://ngiger.dyndns.org/buildbot-full/sim_f/builds/98/step-make_sim/1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] buildbot: how to setup for ppc with 2.6.19 kernel?
Hi Compiling ppc fails for me with 2.6.19 kernels. ( I compile on a Pegasos PPC 601 Debian Linux). If I use ARCH=ppc then I get the following error: CHK include/linux/version.h CHK include/linux/utsrelease.h CHK include/linux/compile.h gcc: include/asm/byteorder.h: No such file or directory gcc: no input files CC arch/ppc/xenomai/hal.o arch/ppc/xenomai/hal.c: In function 'rthal_arch_init': arch/ppc/xenomai/hal.c:353: error: invalid type argument of '-' make[1]: *** [arch/ppc/xenomai/hal.o] Fehler 1 Trying to use ARCH=powerpc fails already while configuring the kernel like this: make ARCH=powerpc menuconfig HOSTCC scripts/kconfig/mconf.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf arch/powerpc/Kconfig init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to undefined symbol 'IPIPE' # # configuration written to .config # And a make gives me make ARCH=powerpc menuconfig HOSTCC scripts/kconfig/mconf.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf arch/powerpc/Kconfig init/Kconfig:564:warning: 'select' used by config symbol 'XENOMAI' refer to undefined symbol 'IPIPE' # # configuration written to .config # What is wrong? Did I miss something in my setup? Wrong config? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot: uses 2.6.19 kernel. Sim has a problem
Hi After spending a week skiing I discovered that I had to update the buildbot to use the 2.6.19 kernels everywhere. Seems to work. I also found that since February 2 I get the following error message g++ -DHAVE_CONFIG_H -I. -I. -I../include -fno-exceptions -D__XENO_SIM__ -I./.. -O2 -MT libmvm_la-thread.lo -MD -MP -MF .deps/libmvm_la-thread.Tpo -c thread.cc -fPIC -DPIC -o .libs/libmvm_la-thread.o thread.cc:66: error: 'int MvmThread::globalTrace' is not a static member of 'class MvmThread' make[1]: *** [libmvm_la-thread.lo] Fehler 1 For details look at http://ngiger.dyndns.org/buildbot-full/sim_f/builds/86/step-make_sim/1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] PPC405: DMA-problem solved!
(Forgot to cc @xenomai-core this e-mail sent yesterday to Jan) Am Samstag, 20. Januar 2007 09:04 schrieben Sie: Niklaus Giger wrote: .. This demo is about how to use the driver API (/wrt interrupts) + how to do PPC4xx-specific DMA. So my suggestion: examples/rtdm/driver-api/dma-ppc4xx.c Agreed. See new version in the attached patch. In any case, we need to resolve the arch dependency somehow. I guess it will currently not fly when I kick the full build in examples/ for a non-PPC platform. Any *simple* way to catch this? Would also be applicable to the heartbeat-x86 example then, though this will not cause build troubles. Is my proposed solution in the Makefile okay for you? How do you kick your full build? Does it still work now? .. + * The following patches must be applied to your kernel to fix bugs Which kernel? I guess this issue will not persist forever. + * http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025697.html + * http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025700.html + * + * Beware! + * The kernel option PPC4xx DMA must be activated for this test. Please provide the full CONFIG_OPTION_NAME here. Fixed. .. Why do we have a compiler warning here, why not a comment? Fixed. +#warning flush_dcache_all is a performance killer, but I do not know at the +#warning moment how to flush only the parts needed Can we resolve this? Wolfgang? + flush_dcache_all(); /* from arch/ppc/kernel/misc.S */ I think we cannot fix this, as it is probably a weakness of the port to PPC4xx. I tried various procedures *dcache* procedure which all lead to kernel oops. I changed the comment a little to reflect the change. I looked also at dma_alloc_coherent, but this need a driver structure which I do not have in this example. I have no time at this moment to really dig deeper into the 4xx-DMA problems. But I might be forced to do it later once I get hands on our new PPC440EPx based board later (around March/April this year). I remember spending quite a few hours on this problem years ago on our first PPC403GA board (but running vxWorks). .. This demo will go to trunk, thus rtdm_irq_enable is no longer needed. Didn't know. Fixed. .. Disabling is typically not needed, unless it is the only way to silence the IRQ source. Keep in mind that this disabling would be fatal if the IRQ happened to be shared (though unusual on PPC, AFAIK). Thanks for catching this error. Fixed. .. +install:: $(APPLICATIONS) + cp $(APPLICATIONS) $(EXEC_PREFIX)/ + NACK. I'd rather like to keep the makefile focused (the next step would be to add uninstall, then ...). Added a comment on top of the Makefile about how to call it for cross compiling. I changed the target to modules_install, but still think that this is useful for my use, eg. without it I have no direct way to access the kernel module from my NFS-mounted rootfs when I want to run a test on my target board. Another solution would be to add an example script to cross compile like the following (tested) snippet make \ -C /usr/src/linux-2.6.19.1 \ KSRC=/usr/src/linux-2.6.19.1 \ ARCH=ppc \ O=/usr/src/build-hcu3-2.6.19.1 \ INSTALL_MOD_PATH=/home/hcu/rootfs/niklaus_2.6.19 \ CROSS_COMPILE=ppc_4xx- \ PATH=/opt/eldk/4_0/usr/bin:$PATH \ SUBDIRS=`pwd` \ modules modules_install Thanks for your careful review. Best regards --- Niklaus Giger Index: examples/rtdm/driver-api/dma-ppc4xx.c === --- examples/rtdm/driver-api/dma-ppc4xx.c (Revision 0) +++ examples/rtdm/driver-api/dma-ppc4xx.c (Revision 0) @@ -0,0 +1,169 @@ +/* * Written by Niklaus Giger [EMAIL PROTECTED] + * + * 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 the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + + * + * This is an example howto write a Xenomai kernel module which handles a + * HW interrupt. The example is PPC4xx specific (testd on a PPC405 board) + * Probably also works on a PPC44x (not yet tested, needs a different irq?). + * + * Beware! + * The following patches had to be applied against the 2.6.19.2 linux kernel + * to fix bugs in arch/ppc/syslib/ppc4xx_dma.c + * http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025697.html + * http://ozlabs.org
Re: [Xenomai-core] PPC405: DMA-problem solved!
Am Donnerstag, 18. Januar 2007 09:31 schrieb Wolfgang Grandegger:
Niklaus Giger wrote:
Hi
I tried to simply an example program how to use interrupts
with Xenomai (see attached Makefile dma_4xx_int_module.c).
The interrupt part of the example works, but the DMA transfer (memory to
memory) using the OnChipMemory fails. I think I must somewhere specify
that the src/dst adressed should not be cached, but I do not know how to
do it.
consistant_alloc() should help. It's used in the kernel in various
places, e.g. in drivers/net/ibm_emac.
Thank you for your tips.
After fixing two bugs in arch/ppc/syslib/ppc4xx_dma.c. See
* http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025697.html
* http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025700.html
my example code worked (tested with DMA channel 0 and DMA channel 3).
..
Interrupt code is ported to RTDM.
@Jan: Can the attached patch be applied?
Best regards
--
Niklaus Giger
Index: examples/rtdm/pp4xx_interrupt/dma_4xx_int_module.c
===
--- examples/rtdm/pp4xx_interrupt/dma_4xx_int_module.c (Revision 0)
+++ examples/rtdm/pp4xx_interrupt/dma_4xx_int_module.c (Revision 0)
@@ -0,0 +1,167 @@
+/* * Written by Niklaus Giger [EMAIL PROTECTED]
+ *
+ * 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 the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+
+ *
+ * This is an example howto write a Xenomai kernel module which handles a
+ * HW interrupt. The example is PPC4xx specific (testd on a PPC405 board)
+ * Probably also works on a PPC44x (not yet tested, needs a different irq?).
+ *
+ * Beware!
+ * The following patches must be applied to your kernel to fix bugs
+ * http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025697.html
+ * http://ozlabs.org/pipermail/linuxppc-embedded/2007-January/025700.html
+ *
+ * Beware!
+ * The kernel option PPC4xx DMA must be activated for this test.
+ *
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/io.h
+#include asm/ppc4xx_dma.h
+
+#include rtdm/rtdm_driver.h
+#include rtdm/rtdm.h
+rtdm_irq_t irq_handle;
+
+MODULE_DESCRIPTION(PPC4xx DMA3 interrupt demo);
+MODULE_AUTHOR([EMAIL PROTECTED]);
+MODULE_LICENSE(GPL);
+
+#define DMA_NR 3
+int irq = DMA_NR + 5; /* DMA-x interrupt line on PPC405GPr */
+
+#define TEST_STRING Could we use a DMA + interrupt to copy a string?
+#define TEST_STRING2 Should be overwritten.
+#define STRING_SIZE 128
+
+char *SRC;
+char *DST;
+
+static ppc_dma_ch_t p_init;
+
+#define show_irq(irq) { \
+ printk(%32s: IRQ %2d uipr 0x%08x uier 0x%08x uisr 0x%08x\n, \
+ __FUNCTION__, irq, \
+ mfdcr(DCRN_UIC_PR(UIC0)), mfdcr(DCRN_UIC_ER(UIC0)), \
+ mfdcr(DCRN_UIC_SR(UIC0)));\
+ printk(%32s: residue %d status 0x08%x cntrl 0x%08x\n,__FUNCTION__,\
+ ppc4xx_get_dma_residue(DMA_NR),\
+ ppc4xx_get_dma_status(),\
+ mfdcr(DCRN_DMACR0 + (DMA_NR * 0x8))); \
+ printk(src at %p is %s\ndst at %p is %s\n, (char *)SRC, \
+ SRC, DST[0], DST[0]); }
+
+void dma_mem_to_mem(void *src, void *dst, unsigned int length,
+ unsigned int use_interrupt)
+{
+#warning Do not use dma_mem_to_mem for OnChipMemory! It will not work.
+ int res = 0;
+ memset((char *)p_init, sizeof(p_init), 0);
+ p_init.polarity = 0;
+ p_init.pwidth = PW_8;
+ res = ppc4xx_init_dma_channel(DMA_NR, p_init);
+ if (res) {
+ printk(%32s: nit_dma_channel return %d %d bytes dest %p\n,
+ __FUNCTION__, res, length, dst);
+ }
+ res = ppc4xx_clr_dma_status(DMA_NR);
+ if (res) {
+ printk(%32s: ppc4xx_clr_dma_status %d\n, __FUNCTION__, res);
+ }
+#warning flush_dcache_all is a performance killer, but I do not know at the
+#warning moment how to flush only the parts needed
+ flush_dcache_all(); /* from arch/ppc/kernel/misc.S */
+
+ ppc4xx_set_dma_mode(DMA_NR, DMA_MODE_MM);
+ ppc4xx_set_src_addr(DMA_NR, virt_to_bus(src));
+ ppc4xx_set_dst_addr(DMA_NR, virt_to_bus(dst));
+ ppc4xx_set_dma_count(DMA_NR, length);
+ ppc4xx_enable_dma(DMA_NR);
+ if (use_interrupt) {
+ res = ppc4xx_enable_dma_interrupt(DMA_NR);
+ } else {
+ res = ppc4xx_disable_dma_interrupt(DMA_NR);
+ }
+ if (res) {
+ printk(%32s: en/disable_dma_interrupt %d return %d per %d\n,
+ __FUNCTION__, use_interrupt, res,
+ ppc4xx_get_peripheral_width(DMA_NR
Re: [Xenomai-core] Nocow patch.
Am Mittwoch, 10. Januar 2007 19:05 schrieb Gilles Chanteperdrix: Hi, .. This was run on x86, but need further testing before inclusion. I wanted to give it a try on my PPC board. But trying to apply it (on a Linxu 2.6.19.1 kernel patched with ksrc/arch/powerpc/patches/adeos-ipipe-2.6.19-ppc-1.5-01.patch gave me the error Hunk #1 succeeded at 652 (offset -2 lines). patching file include/asm-i386/pgalloc.h Reversed (or previously applied) patch detected! Assume -R? [n] Same problem with ioremap.c. Is there a problem or did I apply it against the wrong kernel? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot update
Hi In the last weeks before Christmas I was integrating the new features of the Buildbot 0.7.5 release into the Xenomai buildbot. I would like to thank Brian Warner (maintainer of Buildbot) for integrating my suggestions into the buildbot framework. The changes were: * In December 2006 I upgraded to buildbot 0.7.5 and used the new features SVNPoller to eliminate the svn_watcher.py script. There are cases, where SVNPoll breaks the buildbot if it does not get a correct answer from the SVN-repository, then I have to restart the master manually and the intermediate revisions are lost. * The FileUpload and FileDownload in buildbot 0.7.6 allowed me also to centralise all configs and scripts on the master. * Changed the hcu3 builder (PPC405 based boards) using ELDK 4.0 on a MacMini running GNU/Debian Linux. (before they were located on a PowerBook G4). * As suggested my Jan and Gilles I switched one of the builders to generate first a tarball. An example of this build may be found at: http://ngiger.dyndns.org/buildbot-full/hcu3_f/builds/55 * As requested by rpm he will receive an email each time the buildbot found an error building one of its targets. If somebody else wants to receive these emails, he can drop me an email. Unfortunately there are sometimes false positives because of - Unavailability/errors in my infrastructure (the systems are shared for other uses too - Changes in the buildbot setup, as I have different machines to test my setup and the buildbot master As always you may consult the documentation at http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.pdf All the buildbot configuration files are stored in the SVN repository http://ngiger.dyndns.org/svn/admin/hcu3_linux/doc/buildbot Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Recommendation for ARM/blackfin based buildbot test machine
Hi Can anybody recommend a cheap (Anything below 200 US$ will probably fit into our family budget) ARM system, where I could test the ARM port of Xenomai? E.g. could I buy a LinkSys NSLU2 (around 100 Euros)? It seems that at least Debian is quite popular on it. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot detects failure in recent build
Hi Philippe It seems that your revision 1978 or 1979 broke building PSOS+ on ppc and PPC405. See e.g. http://ngiger.dyndns.org/buildbot/hcu3_q/builds/97/step-mk_kernel/1 which complains about CC [M] kernel/xenomai/skins/psos+/syscall.o kernel/xenomai/skins/psos+/syscall.c: In function '__rn_create': kernel/xenomai/skins/psos+/syscall.c:1083: error: 'psosrn_t' undeclared (first use in this function) kernel/xenomai/skins/psos+/syscall.c:1083: error: (Each undeclared identifier is reported only once kernel/xenomai/skins/psos+/syscall.c:1083: error: for each function it appears in.) kernel/xenomai/skins/psos+/syscall.c:1083: error: 'rn' undeclared (first use in this function) kernel/xenomai/skins/psos+/syscall.c:1084: warning: ISO C90 forbids mixed declarations and code kernel/xenomai/skins/psos+/syscall.c:1112: error: parse error before ')' token kernel/xenomai/skins/psos+/syscall.c: In function '__rn_delete': ... Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot detects failure in recent build
Am Samstag, 23. Dezember 2006 19:53 schrieb Philippe Gerum: On Sat, 2006-12-23 at 19:31 +0100, Niklaus Giger wrote: Hi Philippe It seems that your revision 1978 or 1979 broke building PSOS+ on ppc and PPC405. Fixed, thanks. Btw, could you ask the buildbot to spam me gently each time a commit wrecks the Xenomai boat? It would be easier for me than tracking the WEB interface status. TIA, Sorry for a (wrong positive) mail from my test installation. You should receive an email on build failures. I changed the buildbot setup so that failures while running the test on my CPU-board are only flagged as warnings, as they were often reporting failures in my setup. As my PPC405 board is also used for may other development work, it is sometimes unavailable for the buildbot and the buildbot would also flag this as an error. The sim is reporting error since quite a few weeks, but Gilles never fixed this error (which is probably just an expectation or a time value which has varied a little bit): Some problems were reported in: vxworks-t010823-2:t010823-2.c:163: Expected sequence: SEQ(Test2,2004); got SEQ(Test2,1999) vxworks-t010823-2: t010823-2.c:166, test finished: 1 failures/ 33 tests If you want I could also made a failure in this buildstep be considered only a warning. If you receive too many emails just let me know and I will try to improve this situation. Joyeux noël Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Patches: README.install examples/common for cross-compiling
Am Freitag, 22. Dezember 2006 08:45 schrieb Wolfgang Grandegger: Hi Niklaus, Niklaus Giger wrote: Hi After switching my development environment to a MacMini and using the ELDK 4.0 I discovered that my examples for building using a cross-compiler for my PPC405 target were not correct. (Maybe a few of my previous problems were caused by not correctly specifying the target ARCH.) Also I would like to adapt and document the examples/common/Makefile to the needs for cross-compiling (KSRC/XENOCONFIG/DESTDIR useage). Also I added a target install to copy the generated application to $(DESTDIR)/usr/xenomai. Hm, I don't have examples/common/Makefile in my SVN Xenomai tree. And Added by revision 1970 only. Makefile came from Jan for my example hw_direct_io. /usr/xenomai should be the configurable. Does the attached patch look better for you (using EXEC_PREFIX) ? Best regards -- Niklaus Giger Index: examples/common/Makefile === --- examples/common/Makefile (Revision 1980) +++ examples/common/Makefile (Arbeitskopie) @@ -3,9 +3,9 @@ ### List of applications to be build APPLICATIONS = hw_direct_io -### Note: to override the search path for the xeno-config script, use make XENO=... +### Note: to override the search path for the xeno-config script, use make XENOCONFIG=... +### Note: if you installed it into a non standard place add DESTDIR=/path/to/installed/xenomai - ### List of modules to be build MODULES = @@ -14,6 +14,8 @@ ### Note: to override the kernel source path, use make KSRC=... +# default place to install the resulting binaries +EXEC_PREFIX := $(DESTDIR)/usr/xenomai/bin ## USER SPACE BUILD (no change required normally) ## @@ -24,7 +26,9 @@ ### Sanity check ifeq ($(XENOCONFIG),) all:: - @echo Invoke make like this: \make XENO=/path/to/xeno-config\ + @echo Invoke make like this: \make XENOCONFIG=/path/to/xeno-config\ + @echo add KSRC=.. to override the default kernel source at /lib/modules/$(shell uname -r)/build + @echo add DESTDIR=/path/to/installed/xenomai if you installed it into a non standard place @echo endif @@ -40,6 +44,9 @@ clean:: $(RM) $(APPLICATIONS) *.o +install:: $(APPLICATIONS) + cp $(APPLICATIONS) $(EXEC_PREFIX)/ + endif @@ -80,3 +87,4 @@ $(RM) -R .tmp* endif + ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Patches: README.install
Am Donnerstag, 21. Dezember 2006 23:40 schrieb Wolfgang Denk: Dear Niklaus, Dear Wolfgang Thanks your for spotting my errors. I should have rechecked this patch before submitting it, as it was based on a outdated script. Please review the attached patch again which is based on a script which actually ran and produced a running kernel. I would also thanks you for providing the ELDK. It was really a lot easier to setup the ELDK once I switched from my PPC PowerBook to a MacMini. I can really recommend it. The only addition to the ELDK I made to run xeno-test was to copy my Debian /usr/bin/which to the rootfs. .. Best regards -- Niklaus Giger Index: README.INSTALL === --- README.INSTALL (Revision 1980) +++ README.INSTALL (Arbeitskopie) @@ -192,6 +192,12 @@ from the cross-compilation tools prefix, you will have to manually pass the name of all compilation tools on configure command line. +If you want to avoid to build your own cross compiler, you might if find +easier to use ELDK (see http://www.denx.de/wiki/DULG/ELDK). It includes +the GNU cross development tools, such as the compilers, binutils, gdb, +etc., and a number of pre-built target tools and libraries necessary +to provide some functionality on the target system. + See sections 2.2, 2.3 and 2.4 for examples. 1.4 Building the Linux kernel in the user-space support build tree @@ -276,19 +282,22 @@ - A typical cross-compilation setup, in order to build Xenomai for a -PowerPC-405-based system: +PowerPC-405-based system. Here we use an ELDK cross-compiler and a +2.6.14 kernel. -$ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ - --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ +$ $xenomai_root/scripts/prepare-kernel.sh --arch=ppc \ + --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.5-*.patch \ --linux=$linux_tree $ cd $linux_tree -$ mkdir ../build-powerpc-405-2.6.14 -$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +$ build_root /path/to/eldk +$ mkdir $build_root +$ make ARCH=ppc CROSS_COMPILE=ppc_4xx- O=$build_root xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules -# then install as needed -$ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-linux --host=powerpc-405-linux-gnu +$ make ARCH=ppc CROSS_COMPILE=ppc_4xx- O=$build_root bzImage modules \ + modules_install +$ cd $build_root +$ $xenomai_root/configure --build=i686-linux --host=ppc CC=ppc_4xx-gcc \ + CXX=ppc_4xx-g++ LD=ppc_4xx-ld $ make install 2.3 Building for the IPF ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Patches: README.install examples/common for cross-compiling
Hi After switching my development environment to a MacMini and using the ELDK 4.0 I discovered that my examples for building using a cross-compiler for my PPC405 target were not correct. (Maybe a few of my previous problems were caused by not correctly specifying the target ARCH.) Also I would like to adapt and document the examples/common/Makefile to the needs for cross-compiling (KSRC/XENOCONFIG/DESTDIR useage). Also I added a target install to copy the generated application to $(DESTDIR)/usr/xenomai. Could someone please commit these (or a improved version of it) patches? Thanks in advance -- Niklaus Giger Index: examples/common/Makefile === --- examples/common/Makefile (Revision 1970) +++ examples/common/Makefile (Arbeitskopie) @@ -3,9 +3,9 @@ ### List of applications to be build APPLICATIONS = hw_direct_io -### Note: to override the search path for the xeno-config script, use make XENO=... +### Note: to override the search path for the xeno-config script, use make XENOCONFIG=... +### Note: if you installed it into a non standard place add DESTDIR=/path/to/installed/xenomai - ### List of modules to be build MODULES = @@ -24,7 +24,9 @@ ### Sanity check ifeq ($(XENOCONFIG),) all:: - @echo Invoke make like this: \make XENO=/path/to/xeno-config\ + @echo Invoke make like this: \make XENOCONFIG=/path/to/xeno-config\ + @echo add KSRC=.. to override the default kernel source at /lib/modules/$(shell uname -r)/build + @echo add DESTDIR=/path/to/installed/xenomai if you installed it into a non standard place @echo endif @@ -40,6 +42,9 @@ clean:: $(RM) $(APPLICATIONS) *.o +install: $(APPLICATIONS) + cp $(APPLICATIONS) $(DESTDIR)/usr/xenomai/bin + endif @@ -80,3 +85,4 @@ $(RM) -R .tmp* endif + Index: README.INSTALL === --- README.INSTALL (Revision 1957) +++ README.INSTALL (Arbeitskopie) @@ -276,19 +276,20 @@ - A typical cross-compilation setup, in order to build Xenomai for a -PowerPC-405-based system: +PowerPC-405-based system (assuming an ELDK cross-compiler and a 2.6.14 kernel) $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ mkdir ../build-powerpc-405-2.6.14 -$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +$ build_root /path/to/build-powerpc-405-2.6.14 +$ mkdir $build_root +$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=$build_root xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +$ make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- O=$build_root bzImage modules # then install as needed -$ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-linux --host=powerpc-405-linux-gnu +$ cd $build_root +$ $xenomai_root/configure --build=i686-linux --host=powerpc-405-linux-gnu CC=ppc_4xx-gcc CXX=ppc_4xx-g++ LD=ppc_4xx-ld $ make install 2.3 Building for the IPF ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot: Failure building Xenomai kernel for TQM860
Am Freitag, 8. Dezember 2006 13:43 schrieb Jan Kiszka: Wolfgang Grandegger wrote: Hi Niklaus, I just compiled my Linux 2.4 kernel for TQM860L with the latest revision of Xenomai and I cannot reproduce your problem. In you linker path there are no Xenomai objects. How does it come? Do you use --arch=ppc with prepare_kernel (--arch=powerpc is not valid any more for the ppc tree). The problem pops up with CONFIG_XENO_OPT_SCALABLE_SCHED. The definition of xnlogerr is not visible to queue.h, namely to the inline function getmlq. Here is possible solution at XENO_ASSERT level. Jan Why didn't you apply your patch? It solved my problem and I don't see any risk why you shouldn't apply it and didn't see any objections on this mailing list. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot: Failure building Xenomai kernel for TQM860
Am Freitag, 8. Dezember 2006 13:40 schrieb Wolfgang Grandegger: Hi Niklaus, I just compiled my Linux 2.4 kernel for TQM860L with the latest revision of Xenomai and I cannot reproduce your problem. In you linker path there are no Xenomai objects. How does it come? Do you use --arch=ppc with prepare_kernel (--arch=powerpc is not valid any more for the ppc tree). As seen in http://ngiger.dyndns.org:8011/tqm_f/builds/30/step-prep_bb/0 Exec in /var/buildbot/slave/tqm_f/xenomai: scripts/prepare-kernel.sh --arch=ppc --adeos=ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-*.patch --linux=/var/buildbot/slave/tqm_f/linux Then in http://ngiger.dyndns.org:8011/tqm_f/builds/30/step-cfg_kernel/0 /var/buildbot/scripts/configure.sh /var/buildbot/configs/TQM860L_defconfig CROSS_COMPILE=powerpc-860-linux-gnu- ARCH=ppc and finally the build with make --jobs=4 uImage modules The http logs also show all environment variables (e.g. CROSS_COMPILE, PATH). You can navigate between the different builds and buildsteps on http://ngiger.dyndns.org:8011/. I tried to make all steps transparent to the observer, to enable them to verify themselves all the build step. If you are unable to reach this site please tell me so. I updated my apache2 server and since this time the proxy/reverse proxy form http://ngiger.dyndns.org/buildbot to http://ngiger.dyndns.org:8011/ does not work anymore (but that is another problem I am investigating). I did not change my Buildbot master setup since December 4. The prepare_slave.rb was updated on December 3 I updated today the TQM860L_defconfig to enable more CAN drivers etc, but that didn't change the error. Build 28 (revision 1920) completed without any problem on December 6, and the build on December 7 (revision 1930). All these build are full build, meaning that all the build directories get removed before starting the prepare_kernel.sh Did you also clean rebuild? Is there somewhere a missing include? I see that include/xenomai/nucleus/pod.h has #define xnlogerr(fmt,args...) xnarch_logerr(fmt , ##args But grep finds xnlogerr in the following object files kernel/xenomai/nucleus/xeno_nucleus.o. kernel/xenomai/nucleus/built-in.o. Wolfgang. Niklaus Giger wrote: Hi I get an error building the TQM860 image (2.4 based kernel). Last successful build was with revision 1920 (didn't build between). Log is available under http://ngiger.dyndns.org:8011/tqm_f/builds/30/step-mk_kernel/1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Unresolved symbol xnheap_usable_size since r1846 (PPC/vxworks only)
Hi Philippe Since your revision 1846 Sanitize size-related heap macros I cannot get link anymore the Linux kernel for PPC405 and vxworks. Others targets link without problems See http://ngiger.dyndns.org/buildbot/hcu3_vx_q/builds/11/step-mk_kernel/1 which reports: LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o: In function `__heap_read_proc': kernel/xenomai/skins/vrtx/heap.c:38: undefined reference to `xnheap_usable_size' make: *** [.tmp_vmlinux1] Fehler 1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot: Errors building rtnet since at least r1834
Hi Unfortunately I cannot say since when this build is broken, as I had to reinstall the buildbot on my main server. But this particular build target should not have been affected. (Same compiler, same build slave, same scripts) But since at November 12 I get the following errors in my builds: See http://ngiger.dyndns.org/buildbot-full/tqm_f/builds/0/step-mk_RTnet/1 libtool: link: warning: library `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was moved. libtool: link: warning: library `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved. libtool: link: warning: library `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was moved. libtool: link: warning: library `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved. Has anybody a hint, what the reason could be? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] r1827 seems to have broken PPC with vxworks skin
Hi Philippe Your commit 1827 Make rthal_thread_switch() return the last current task pointer as expected by the vanilla switch code seems to trigger a failure in my PPC405 vxworks setup. See http://ngiger.dyndns.org/buildbot/hcu3_vx_q/builds/2/step-xenotest/0 where I got the following error on startup: I-pipe: Domain Xenomai registered. Xenomai: hal/powerpc started. Xenomai: real-time nucleus v2.3-rc1 (Baroque) loaded. Xenomai: starting native API services. Xenomai: starting RTDM services. Oops: kernel access of bad area, sig: 11 [#1] NIP: C0063384 LR: C0062168 SP: C02CBF50 REGS: c02cbea0 TRAP: 0300Not tainted MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 0004, DSISR: TASK = c02c0b40[1] 'swapper' THREAD: c02ca000 Last syscall: 120 GPR00: 0001 C02CBF50 C02C0B40 C0328320 0080 0120 GPR08: C0328240 C022DF80 C020 01FFBB00 GPR16: 01FFF7C8 0080 01FF595C 007FFF00 00200040 C01B GPR24: C02CBF98 C023 0007 0080 8000 C0328324 C0328364 NIP [c0063384] vrtx_get_id+0x40/0x12c LR [c0062168] sc_hcreate+0xa4/0x248 Call trace: [c0062168] sc_hcreate+0xa4/0x248 [c006258c] vrtxheap_init+0x60/0xec [c0063264] __vrtx_skin_init+0x48/0xd4 [c000245c] init+0x8c/0x254 [c0005d0c] kernel_thread+0x44/0x60 Kernel panic - not syncing: Attempted to kill init! As usual you may find the exact .config in http://ngiger.dyndns.org/buildbot/hcu3_vx_q/builds/2/step-cfg_kernel/0 I am migrating my whole buildbot setup to use ELDK 4.0 as my cross-compile environment. xeno-test does not work yet as there are some differences between the denx environment and my old home made setup, which I could not yet resolve. But this problem seems to be in a earlier state of the startup and I just wanted to inform you about it. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Cannot compile sim with make --jobs=4
Hi Gilles I just noticied that compiling the simulator with make --jobs=4 clean all check led errors like: /bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -o libmvmutils.la -rpath /usr/xenomai/lib -version-info 1:0:0 libmvmutils_la-clock.lo libmvmutils_la-elf.lo libmvmutils_la-hash++.lo libmvmutils_la-interface.lo libmvmutils_la-list++.lo libmvmutils_la-object.lo libmvmutils_la-statobj.lo libmvmutils_la-string++.lo libmvmutils_la-tclist++.lo libmvmutils_la-utils.lo libtool: link: `libmvmutils_la-clock.lo' is not a valid libtool object No big deal, I just reverted to the default make --jobs=1, but just wanted you let it know. BTW. I still get the errors: Some problems were reported in: vxworks/testsuite/t010823-2.c:163: Expected sequence: SEQ(Test2,2004); got SEQ(Test2,1999) vxworks/testsuite/t010823-2.c:166, test finished: 1 failures/ 33 tests Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot finds unresolved symbols `xnarch_atomic_xchg'
Am Dienstag, 31. Oktober 2006 08:51 schrieb Wolfgang Grandegger: Hi Niklaus, Niklaus Giger wrote: Hi I see the following failure since revision 1771. e.g. http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56/step-mk_kernel/1 kernel/built-in.o: In function `xnintr_irq_handler': intr.c:(.text+0x34334): undefined reference to `xnarch_atomic_xchg' intr.c:(.text+0x34424): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_schedule': (.text+0x38470): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_schedule_runnable': (.text+0x39f28): undefined reference to `xnarch_atomic_xchg' kernel/built-in.o: In function `xnpod_init': (.text+0x3a770): undefined reference to `xnarch_atomic_xchg' make: *** [.tmp_vmlinux1] Fehler 1 I lost track somehow. What version of the Linux kernel, ADEOS-IPIPE and Xenomai are you using? Usually, quite a recent one. My main target is a custom PPC405 target, running U-Boot, Linux 2.6.14, adeos-ipipe-2.6.14-ppc-1.5-01.patch. When I refer to the buildbot (acontinuos integration tool), I mean the the buildbot master, running at http://ngiger.dyndns.org/buildbot/ . It tracks the most recent svn version of the buildbot and builds them for various target (simulator, ppc405 posix, pp405 vxworks, tqm_q with rtnet, ppc60x). Each build contains (if one looks at the different build steps) all the relevant information (kernel, ipipe-version, .config) etc. For details of the above mention build go to: http://ngiger.dyndns.org/buildbot-full/ppc_f/builds/56 and following the different build logs pointed by the stio links. Documentation about the xenomai buildbot can be found at: http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.pdf Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as ppc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make simple, then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS-c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Again the same question. What versions of kernel, ADEOS-IPIPE and Xenomai are you using.I have some problems to get the kernel booted with the VxWorks skin emulation. I understood, that I must build the Native and POSIX skin as modules and enable the periodic timer support with a resonable frequency. I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches (attached) for my system, the attached .config, adeos-ipipe-2.6.14-ppc-1.5-01.patch. I have vxworks built-in to enforce that the timers get initialized into the periodic mode. Best regards -- Niklaus Giger .config.bz2 Description: BZip2 compressed data hcu3-2.6.14.patch.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as ppc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger: Niklaus Giger wrote: Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger: Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi My impression from our last discussion was that your toolchain is somehow broken as I was unable to reproduce your problems on (almost) the same hardware I think I really have to reactivate my old Walnut board to have common platform to test with Wolfgang Grandegger. It would make more sense to use the ELDK4 for comparison. I don't think it depends on the hardware. As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no MacOsX (he discovered widelands and was quite happy), I had a platform where I could install the CD with ELDK 4.0, which I had laying around. After some setting up of my environment and tweaking my scripts to work with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set. up with a nice environment and rootfs with much more precompiled programs than I had ever before. Debugging on the platform is now as good as on my PowerBook. My situation is now as follows: - ELDK 4.0 installed on Debian Etch MacMini - Using ELD 4.0 rootfs ppc_4xx - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc (but NOT adding any -mcpu=40x flag to the compiler) The trap 0 in /proc/xenomai/fault seems to count on each invocation of simple 0: 51(Data or instruction access) gdb however no does not show anything abnormal, as it says now This GDB was configured as ppc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /bin/simple [Thread debugging using libthread_db enabled] [New Thread 805422032 (LWP 639)] root_thread_init 4[New Thread 805455088 (LWP 642)] Program exited normally. (gdb) quit Though I am still puzzled. Could you please send me your Makefile or the compile command to make simple, then I would give it a try on my setup. Here are the commands ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS -c -o simple.o simple.c ppc_4xx-gcc -o simple simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread -lvxworks Thanks for your help. Will be busy till tomorrow evening. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot failure for sim since r1758
Hi Philippe Thanks for fixing the compilation issue, but there is now a small error running the testsuite, see at the end of http://ngiger.dyndns.org/buildbot/sim_q/builds/140/step-check_sim/0 Some problems were reported in: vxworks/testsuite/t010823-2.c:163: Expected sequence: SEQ(Test2,2004); got SEQ(Test2,1999) vxworks/testsuite/t010823-2.c:166, test finished: 1 failures/ 33 tests I think that usually Gilles just corrected it by changing the expected value. But I am not sure about it. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum: On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote: Hi While trying to make a small demo app for Xenomai's registry I stumbled about the following bug of the vxWorks skin. taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the output of the attached demo gives: reg_demo ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception #1025 This is the same issue that you raised back then, and that we did not fix yet: https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html #1025 looks like being an ISI exception due to some unmapped memory being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being part of the problem/solution; could you check whether this error still occurs when this option is disabled in the nucleus? I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error went away. -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
Hi
While trying to make a small demo app for Xenomai's registry I stumbled
about the following bug of the vxWorks skin.
taskSuspend provokes (sometimes) a switch to the secondary mode, e.g.
the
output of the attached demo gives:
reg_demo
~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
#1025
This is the same issue that you raised back then, and that we did not
fix yet:
https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
#1025 looks like being an ISI exception due to some unmapped memory
being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
part of the problem/solution; could you check whether this error still
occurs when this option is disabled in the nucleus?
I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error
went away.
Actually I think the problem did not go away, as I did see that
in /proc/xenomai/faults the following error is incremented when I call the
attache simple program.
TRAP CPU0
0:5(Data or instruction access)
(Btw which exception is it attached on a PPC405 system?)
Here is the stack trace of the simplified example attached as seen by the BDI
with a hardware breakpoint at 0x300
#0 0x0300 in ?? ()
No symbol table info available.
#1 0x100b8c48 in ?? ()
No symbol table info available.
#2 0x100b8c48 in ?? ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb)
Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
(gdb) bt full
#0 xnpod_fault_handler (fltinfo=0xc1839e18)
at
/mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
thread = (xnthread_t *) 0xc0214f40
#1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
No locals.
#2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
fltinfo = {exception = 0, regs = 0xc1839f50}
#3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
No locals.
#4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
start_domain = (struct ipipe_domain *) 0xc0214f40
this_domain = (struct ipipe_domain *) 0xc0214f40
evhand = (ipipe_event_handler_t) 0xc0048e90 xnpod_trap_fault+100
pos = (struct list_head *) 0xc0214f40
npos = (struct list_head *) 0xc01c6540
flags = 167984
propagate = 1
#5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
error_code=0)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
vma = (struct vm_area_struct *) 0xff86120
mm = (struct mm_struct *) 0xc0200260
info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136,
_sifields = {_pad = {0, -1048338784, -1048338608,
-1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
-1070595192, -1048338752, -1073422700,
0, 1, -1048338704,
-1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896,
167984, 0, 16384, -1071880896, -1048338640, -1073479988,
0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
_overrun = -1048338784,
_pad =
0xc1839e94
Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224,
_sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
= -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid =
0, _uid = 3246628512, _status = -1048338608,
_utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0},
_sigpoll = {_band = 0, _fd = -1048338784}}}
code = 196609
is_write = 0
__func__ = do_page_fault
#6 0xc0003258 in handle_page_fault ()
No locals.
(gdb)
But I think it has something to do with my toolchain/compiler or my root file
system setup. I just found out, that compiling it with the same gcc 3.4
compiler for my PowerBook and linking it statically the error got away.
I think I really have to reactivate my old Walnut board to have common
platform to test with Wolfgang Grandegger.
Best regards
--
Niklaus Giger
/*
* Copyright (C) 2006 Niklaus Giger [EMAIL PROTECTED].
*
* VxWorks is a registered trademark of Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published
Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks
Am Samstag, 28. Oktober 2006 20:00 schrieb Philippe Gerum:
On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the
error went away.
Actually I think the problem did not go away, as I did see that
in /proc/xenomai/faults the following error is incremented when I call
the attache simple program.
TRAP CPU0
0:5(Data or instruction access)
(Btw which exception is it attached on a PPC405 system?)
0x400, e.g. page fault.
Here is the stack trace of the simplified example attached as seen by the
BDI with a hardware breakpoint at 0x300
#0 0x0300 in ?? ()
No symbol table info available.
#1 0x100b8c48 in ?? ()
No symbol table info available.
#2 0x100b8c48 in ?? ()
No symbol table info available.
Previous frame inner to this frame (corrupt stack?)
(gdb)
Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me
(gdb) bt full
#0 xnpod_fault_handler (fltinfo=0xc1839e18)
at
/mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/syst
em.h:200 thread = (xnthread_t *) 0xc0214f40
#1 0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18)
at
/mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:290
7 No locals.
#2 0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039,
data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
fltinfo = {exception = 0, regs = 0xc1839f50}
#3 0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f,
data=0xc1839f50)
at
/mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385 No
locals.
#4 0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
start_domain = (struct ipipe_domain *) 0xc0214f40
this_domain = (struct ipipe_domain *) 0xc0214f40
evhand = (ipipe_event_handler_t) 0xc0048e90
xnpod_trap_fault+100 pos = (struct list_head *) 0xc0214f40
npos = (struct list_head *) 0xc01c6540
flags = 167984
propagate = 1
#5 0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224,
error_code=0)
at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
vma = (struct vm_area_struct *) 0xff86120
mm = (struct mm_struct *) 0xc0200260
info = {si_signo = 1, si_errno = -1071644672, si_code =
-1071579136, _sifields = {_pad = {0, -1048338784, -1048338608,
-1071554848, -1070595192, -1048338768, -1073423884, -1048338608,
-1070595192, -1048338752, -1073422700, 0, 1, -1048338704,
-1073418440, -1071710208, 14, 1, -1071733764, -1071710208,
-1071880896, 167984, 0, 16384, -1071880896, -1048338640, -1073479988,
0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0,
_overrun = -1048338784,
_pad =
0xc1839e94
Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ
\004Þ\224, _sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private
= -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld =
{_pid = 0, _uid = 3246628512, _status = -1048338608,
_utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr =
0x0}, _sigpoll = {_band = 0, _fd = -1048338784}}}
code = 196609
is_write = 0
__func__ = do_page_fault
#6 0xc0003258 in handle_page_fault ()
No locals.
(gdb)
But I think it has something to do with my toolchain/compiler or my root
file system setup. I just found out, that compiling it with the same gcc
3.4 compiler for my PowerBook and linking it statically the error got
away.
I tried to reproduce the issue on a lite5200 here, to no avail. I'm
using gcc 4.0 from Denx's ELDK 4.0, but I've never had such problem when
using gcc 3.3.3 from ELDK 3.1 either.
I wonder if something fishy is not happening with the code gcc generates
to emit syscalls in some place of the library support.
Could be. I have only a gdbserver running on the PPC405 system. I compiled
again without ld -static. Then I do the following:
This GDB was configured as powerpc-linux-gnu...Using host libthread_db
library /lib/tls/libthread_db.so.1.
(gdb) set solib-absolute-prefix /mnt/data.ng/hcu/rootfs
(gdb) dir /mnt/data.ng/hcu/rootfs
Source directories searched: /mnt/data.ng/hcu/rootfs:$cdir:$cwd
(gdb) target remote 172.25.1.5:2345
Remote debugging using 172.25.1.5:2345
0x3000fa18 in ?? ()
(gdb) cont
Continuing.
[New thread 16384]
Program received signal SIGILL, Illegal instruction.
[Switching to thread 16384]
0x3000ca1c in _dl_name_match_p () from /mnt/data.ng/hcu/rootfs/lib/ld.so.1
(gdb) bt fu
#0 0x3000ca1c in _dl_name_match_p () from
/mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
#1 0x30008878 in do_lookup_x () from /mnt
[Xenomai-core] Buildbot failure for sim since r1758
Hi I get the following error on my buildbot: (see http://ngiger.dyndns.org/buildbot/sim_q/builds/133/step-make_sim/1) make[1]: Entering directory `/var/buildbot/slave/sim_q/build/sim/adapter' if g++ -DHAVE_CONFIG_H -I. -I. -I../include -D__XENO_SIM__ -fno-exceptions -I./.. -I./../../include-O2 -MT adapter.o -MD -MP -MF .deps/adapter.Tpo -c -o adapter.o adapter.cc; \ then mv -f .deps/adapter.Tpo .deps/adapter.Po; else rm -f .deps/adapter.Tpo; exit 1; fi In Datei, eingefügt von ./../../include/nucleus/pod.h:34, von adapter.cc:23: ./../../include/nucleus/thread.h:108:26: Fehler: nucleus/stat.h: Datei oder Verzeichnis nicht gefunden ./../../include/nucleus/thread.h:164: Fehler: »xnstat_counter_t« bezeichnet keinen Typ ./../../include/nucleus/thread.h:165: Fehler: »xnstat_counter_t« bezeichnet keinen Typ ./../../include/nucleus/thread.h:166: Fehler: »xnstat_counter_t« bezeichnet keinen Typ ./../../include/nucleus/thread.h:167: Fehler: »xnstat_runtime_t« bezeichnet keinen Typ ./../../include/nucleus/intr.h:65: Fehler: »xnstat_counter_t« bezeichnet keinen Typ ./../../include/nucleus/intr.h:66: Fehler: »xnstat_runtime_t« bezeichnet keinen Typ ./../../include/nucleus/intr.h:67: Fehler: »RTHAL_NR_CPUS« wurde in diesem Gültigkeitsbereich nicht definiert make[1]: *** [adapter.o] Fehler 1 make[1]: Leaving directory `/var/buildbot/slave/sim_q/build/sim/adapter' make: *** [all-recursive] Fehler 1 program finished with exit code 2 Starting with a virgen check out didn't cure the problem see: http://ngiger.dyndns.org/buildbot/sim_q/builds/139/step-make_sim/1 Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Suggestions for the vxWorks skins
Hi
As I am trying to debug startup failures of a thirs party C++-library, I
stumbled about the fact that the /proc/xenomai/registry/ only listed
semaphores and not tasks.
My co-workers would appreciate to have some equivalents to vxWorks i
or semShow routines, as they come often very handy to debug problems, I was
thinking about how to improve the situation.
One approach could be:
a) Instead of calling semShow for each semaphore
do cat /proc/xenomai/registry/semaphores/*. The information therein is
already useful. The attached patch only modifies the output to include the
name of the semaphore. In the future it would be nice to show also the owner
of a mutex.
b) The i procedure of vxworks could be replaced
by cat /proc/xenomai/registry/tasks/*.
With the attached patch I just show the name of the task.
If nobody opposes I would like to extend the interface to provide at least the
same information as under vxWorks (entrypoint, priority, status, program
counter, errno, delay).
Would it be difficult/desirable to include the amount of free stack space?
Would it be difficult/desirable to include the name of the vxworks semaphores
a vx task is holding? Together with point a) one could easyly detect lock
ups.
Best regards
--
Niklaus Giger
Index: ksrc/skins/vxworks/semLib.c
===
--- ksrc/skins/vxworks/semLib.c (Revision 1738)
+++ ksrc/skins/vxworks/semLib.c (Arbeitskopie)
@@ -49,7 +49,7 @@
xnlock_get_irqsave(nklock, s);
- p += sprintf(p, type=%s:value=%u\n, sem-vtbl-type, sem-count);
+ p += sprintf(p, %s:type=%s:value=%u\n, sem-name, sem-vtbl-type, sem-count);
if (xnsynch_nsleepers(sem-synchbase) == 0) {
xnpholder_t *holder;
Index: ksrc/skins/vxworks/taskLib.c
===
--- ksrc/skins/vxworks/taskLib.c (Revision 1738)
+++ ksrc/skins/vxworks/taskLib.c (Arbeitskopie)
@@ -30,6 +30,56 @@
static void wind_task_delete_hook(xnthread_t *xnthread);
static void wind_task_trampoline(void *cookie);
+#ifdef CONFIG_XENO_EXPORT_REGISTRY
+
+static int task_read_proc(char *page,
+ char **start,
+ off_t off, int count, int *eof, void *data)
+{
+ wind_task_t *task = (wind_task_t *)data;
+ char *p = page;
+ int len;
+ spl_t s;
+
+ xnlock_get_irqsave(nklock, s); /* TODO is this necessary ?? */
+
+ p += sprintf(p, %s:\n, task-name);
+
+ xnlock_put_irqrestore(nklock, s);
+
+ len = (p - page) - off;
+ if (len = off + count)
+ *eof = 1;
+ *start = page + off;
+ if (len count)
+ len = count;
+ if (len 0)
+ len = 0;
+
+ return len;
+}
+
+extern xnptree_t __vxworks_ptree;
+
+static xnpnode_t task_pnode = {
+
+ .dir = NULL,
+ .type = tasks,
+ .entries = 0,
+ .read_proc = task_read_proc,
+ .write_proc = NULL,
+ .root = __vxworks_ptree,
+};
+
+#elif defined(CONFIG_XENO_OPT_REGISTRY)
+
+static xnpnode_t task_pnode = {
+
+ .type = tasks
+};
+
+#endif /* CONFIG_XENO_EXPORT_REGISTRY */
+
void wind_task_init(void)
{
initq(wind_tasks_q);
@@ -152,7 +202,7 @@
#ifdef CONFIG_XENO_OPT_REGISTRY
if (xnregistry_enter(pTcb-name,
- pTcb, xnthread_handle(pTcb-threadbase), NULL)) {
+ pTcb, xnthread_handle(pTcb-threadbase), task_pnode)) {
wind_errnoset(S_objLib_OBJ_ID_ERROR);
taskDeleteForce((TASK_ID) pTcb);
return ERROR;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Mittwoch, 27. September 2006 20:19 schrieb Wolfgang Grandegger: .. I'm now a bit puzzled why a FP exception occurs. What happens if you disable MATH_EMULATION in your kernel (that's what I normally have). It will try the latency test on my Walnut-Board with CONFIG_XENO_OPT_DEBUG asap. I'm unable to reproduce the problem of our Sycamore board with Linux 2.6.14: Can I you send me (maybe offline) your .config. I will also rebuild my rootfs from scratch. At work I have also a walnut board where I could run the tests. CPU: AMCC PowerPC 405GPr Rev. B at 333.333 MHz (PLB=133, OPB=66, EBC=66 MHz) Internal PCI arbiter enabled, PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: Sycamore - AMCC PPC405GPr Evaluation Board Thanks for trying to reproduce the problem. -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Dienstag, 26. September 2006 16:21 schrieb Philippe Gerum:
On Mon, 2006-09-25 at 22:29 +0200, Niklaus Giger wrote:
Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum:
On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote:
Niklaus Giger wrote:
..
Is the output of lines like Xenomai: Switching display-3238 to
secondary mode after exception #1025 from user-space at 0x100033c4
(pid 3240) harmless or the result of a activated
CONFIG_XENO_OPT_DEBUG.. option?
A known hw issue seems to exist with the 405GP (revD), which causes the
ESR to be incorrectly set upon FPU emulation trap, which would in turn
cause the spurious exception to be relayed to the nucleus by Adeos. The
patch below is _not_ the final fix, but rather a way to check if this
message is indeed related to the FPU emulation on your board. Does it
silence the exception without breaking the box?
--- arch/ppc/kernel/traps.c~ 2006-09-25 17:10:48.0 +0200
+++ arch/ppc/kernel/traps.c 2006-09-26 16:14:30.0 +0200
@@ -638,9 +638,6 @@
unsigned int reason = get_reason(regs);
extern int do_mathemu(struct pt_regs *regs);
- if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
- return;
-
#ifdef CONFIG_MATH_EMULATION
/* (reason REASON_ILLEGAL) would be the obvious thing here,
* but there seems to be a hardware bug on the 405GP (RevD)
@@ -655,6 +652,9 @@
}
#endif /* CONFIG_MATH_EMULATION */
+ if (ipipe_trap_notify(IPIPE_TRAP_PCE,regs))
+ return;
+
if (reason REASON_FP) {
/* IEEE FP exception */
int code = 0;
Tried your patch against adeos-ipipe 1.3. But I still get the same behaviour.
Here is my proc/cpuinfo.
$ cat /proc/cpuinfo
processor : 0
cpu : 405GPr
clock : 400MHz
revision: 9.81 (pvr 5091 0951)
bogomips: 398.33
machine : Netstal HCU3
plb bus clock : 133MHz
U-Boot printed the following info:
CPU: AMCC PowerPC 405GPr Rev. B at 400 MHz (PLB=133, OPB=33, EBC=33 MHz)
, PCI sync clock at 33 MHz 16 kB I-Cache 16 kB D-Cache
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Dienstag, 26. September 2006 18:28 schrieb Wolfgang Grandegger: Philippe Gerum wrote: On Tue, 2006-09-26 at 16:56 +0200, gilles.chanteperdrix wrote: OK, but in general, soft-float emulation should be used on systems without FPU and this is even more important for real-time. This is a tool chain issue. Niklaus, what tool chain are you using? In my .config I have MATH_EMULATION=y The toolchain is gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu built using Dan Kegel crosstool (Version 0.42 if I remember exactly). Shall I switch to another one? -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Here is the stack with adeos-ipipe 1.3 after applying your patch (gdb) info stack #0 xnpod_fault_handler (fltinfo=0xc1489e18) at kernel/xenomai/nucleus/pod.c:216 #1 0xc004bad4 in xnpod_trap_fault (fltinfo=0x73) at kernel/xenomai/nucleus/pod.c:2907 #2 0xc0043ee8 in xnarch_trap_fault (event=115, domid=0, data=0xc01a9435) at include/asm/xenomai/bits/init.h:46 #3 0xc012dc38 in exception_event (event=3223286668, ipd=0x0, data=0xc01a9435) at arch/ppc/xenomai/hal.c:385 #4 0xc003fe18 in __ipipe_dispatch_event (event=0, data=0xc1489f50) at kernel/ipipe/core.c:665 #5 0xc000aecc in do_page_fault (regs=0xc1489f50, address=268448708, error_code=0) at include/linux/ipipe.h:445 #6 0xc0003258 in handle_page_fault () Previous frame inner to this frame (corrupt stack?) (gdb) Hope it helps you -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem with periodic timer on PPC40x solved
Am Montag, 25. September 2006 17:57 schrieb Philippe Gerum: On Sun, 2006-09-24 at 23:07 +0200, Wolfgang Grandegger wrote: Niklaus Giger wrote: .. Ok, we can go for the lazy fix here, since this code is poised to disappear anyway. I've merged a variant of the above we already use for the ARM port, which scales down the period to microseconds instead of losing precision on the count of timebase ticks per jiffy. - ticks = ns * tb_ticks_per_jiffy / (10 / HZ); + ticks = (ns / 1000) * tb_ticks_per_jiffy / (100 / HZ); Thanks for finding this solution. I tried to understand mulhwu and mulhwu_scale_factor but couldn't figure out a correct solution in a short time. The buildbot cannot presently power on and off my PPC405 target board, as the my power outlet switching device is broken and has been sent back for a remplacement. I did however run some tests manually and have the following questions about the output: Why do I get negative values for latenciy values? Is the output of lines like Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) harmless or the result of a activated CONFIG_XENO_OPT_DEBUG.. option? Mon Sep 25 20:20:33 UTC 2006 running: ./run -- -T 5 -t2 # latency * * * Type ^C to stop this application. * Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0x100033c4 (pid 3240) == 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| -5.108| -4.754| -0.905| 0| -5.108| -0.905 RTD| -4.963| -4.871| 1.155| 0| -5.108| 1.155 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfda9638 (pid 3240) RTD| -4.963| -4.758| 16.020| 0| -5.108| 16.020 RTD| -6.313| -4.861| 10.980| 0| -6.313| 16.020 Xenomai: Switching display-3238 to secondary mode after exception #1025 from user-space at 0xfe7c1c4 (pid 3240) ---|||||- RTS| -6.313| -4.811| 16.020| 0|00:00:05/00:00:05 Xenomai: stopping RTDM services. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problem with periodic timer on PPC40x identified
Hi
Finally I got some time to debug the whole problem with my BDI.
I see that in hal.c thal_set_local_cpu_timer the PIT is loaded with a value of
568 which is far too low, as the PIT is running at 400 MHz. So it will
trigger an interrupt every 1,4 microsecond and therefore overload the system.
I am not sure about the time units stored in __ipipe_decr_ticks. I tried to
use 400 as my board is running at 400 MHz.
A quick breakpoint in ppc4xx_calibrate_decr in the file
arch/syslib/ppc4xx_setup.c verified that bdinfo has the correct value of
400'000'000 as frequency.
In hal.c and ipipe-core are two occurences of
mtspr(SPRN_PIT, __ipipe_decr_ticks);
which I replaced by the above computed constant
mtspr(SPRN_PIT, __ipipe_decr_ticks * 400);
Now the the board comes up, but calling in the vxworks skin
taskDelay(sysClkRateGet()*10) delays me only about 5 seconds and not 10 as
expected.
I have one possible explanation that the value of 568 is the result of a
implicit truncation to 32 bits in ipipe_tune_timer. tb_ticks_per_jiffy is
160, sysClkRate is 1. Therefore a maximal delay of 1 ms = 1000*1000
ns leads to 1000*1000*16000 = 0x25'40BE'4000.
If would be nice if somebode could shed some light on this issue.
My preliminary patch looked like this, but I am sure that we need quite a
different solution.
+++ ksrc/arch/powerpc/hal.c (Arbeitskopie)
@@ -81,7 +81,9 @@
*/
static void rthal_set_local_cpu_timer(void)
{
+#ifndef CONFIG_40x
long ticks;
+#endif
rthal_declare_cpuid;
rthal_load_cpuid();
@@ -90,7 +92,7 @@
#ifdef CONFIG_40x
/* Enable and set auto-reload. */
mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-mtspr(SPRN_PIT, __ipipe_decr_ticks);
+mtspr(SPRN_PIT, __ipipe_decr_ticks * 400); /* TODO: How do we get this
value from the board info */
#else /* !CONFIG_40x */
ticks = (long)(__ipipe_decr_next[cpuid] - __ipipe_read_timebase());
set_dec(ticks 0 ? ticks : 0);
Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
===
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
(Revision
1650)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.4-00.patch
(Arbeitskopie)
@@ -3581,7 +3581,8 @@
+#ifdef CONFIG_40x
+ /* Enable and set auto-reload. */
+ mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_ARE);
-+ mtspr(SPRN_PIT, __ipipe_decr_ticks);
++ mtspr(SPRN_PIT, __ipipe_decr_ticks * 400 ); /* TODO: How do we get this
value from the board info */
+
+#else /* !CONFIG_40x */
+ __ipipe_decr_next[cpuid] = __ipipe_read_timebase() + __ipipe_decr_ticks;
+ set_dec(__ipipe_decr_ticks);
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Odd behaviour of vxworks
Am Sonntag, 17. September 2006 19:06 schrieb Philippe Gerum: On Fri, 2006-09-15 at 21:44 +0200, Niklaus Giger wrote: Hi .. Maybe the example is misleading in that respect; the patch below makes the behaviour constant among all environments: Thanks for your explanation and the fix. But I still have the second deviation from the behaviour under vxWorks and the skin behaviour under the xenomai simulator: semGive returns -1 with an errno of 1441896 = S_semLib_INVALID_OPERATION. See the output here: __xeno_user_init: semMCreate 134 taskId 133 __xeno_user_init: semTake 134 status 0 0 taskId 133 __xeno_user_init: semGive 134 status -1 1441896 taskId 133 consumer_task: task 136 ConsumerTask producer_task: task SEM_DELETE_SAFE 137 ProducerTask Do you have an explanation for this difference? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Best way to determine sudo in xeno-load?
Hi
Since the last checkin in xeno-load.in by gpm on the 17 of July my PPC HCU3
target does not run the xeno-tests correctly.
E.g. in http://ngiger.dyndns.org/buildbot/hcu3_q/builds/26/step-xenotest/0
you find lines like
/usr/xenomai/bin/xeno-load: /usr/xenomai/bin/xeno-load: 249: sudo: not found
My earlier solution was:
if test -n `which sudo`; then
sudo=`which sudo`
fi
This was corrected by Gilles to
if test -n `which sudo 2/dev/null`; then
sudo=`which sudo`
elif test -n `type -t sudo 2/dev/null`; then
sudo=sudo
fi
Unfortunately my busybox version 1.1.3 behaves like this:
~ $ type -t sudo 2/dev/null
-t: not found
sudo: not found
Whereas my bash shell on my Debian system answers like this:
$ type -t sudo
file
Therefore I propose to change it like this:
if test -n `which sudo 2/dev/null`; then
sudo=`which sudo`
elif `type -t sudo 2/dev/null` = 'file'; then
sudo=sudo
else
sudo=
fi
echo sudo cmd is now $sudo
Which gives me in Debian's bash the following output:
sudo cmd is now /usr/bin/sudo
and running under the busybox
/usr/xenomai/bin/xeno-load: /usr/xenomai/bin/xeno-load: 59: -t: not found
sudo: not found: not found
sudo cmd is now
which is ugly, but at least does the job correctly.
Or is Gilles patch based on yet another use-case. If this is the case, please
let me know.
Also, the test has to be moved up before the first use of the sudo command.
If nobody comes up with a better solution, I would ask somebody to apply the
attached patch, which implements both ideas.
Best regards
--
Niklaus Giger
Index: xeno-load.in
===
--- xeno-load.in (Revision 1561)
+++ xeno-load.in (Arbeitskopie)
@@ -82,6 +82,15 @@
eval $user_moddir
+if test -n `which sudo 2/dev/null`; then
+ sudo=`which sudo`
+elif `type -t sudo 2/dev/null` = 'file'; then
+ sudo=sudo
+else
+ sudo=
+fi
+echo sudo cmd is now $sudo
+
if `$sudo $modprobe -nq xeno_nucleus /dev/null 21`; then
target_deps=${target_deps}nucleus+
else
@@ -94,12 +103,6 @@
test $verbose = 1 echo Running $target_name from $run_info_file
-if test -n `which sudo 2/dev/null`; then
- sudo=`which sudo`
-elif test -n `type -t sudo 2/dev/null`; then
- sudo=sudo
-fi
-
if test \! x$target_mesg = x; then
case $target_mesg in
control_c)
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Best way to determine sudo in xeno-load?
Am Mittwoch, 6. September 2006 23:08 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Hi Since the last checkin in xeno-load.in by gpm on the 17 of July my PPC HCU3 target does not run the xeno-tests correctly. E.g. in http://ngiger.dyndns.org/buildbot/hcu3_q/builds/26/step-xenotest/0 you find lines like /usr/xenomai/bin/xeno-load: /usr/xenomai/bin/xeno-load: 249: sudo: not found My earlier solution was: if test -n `which sudo`; then sudo=`which sudo` fi This was corrected by Gilles to if test -n `which sudo 2/dev/null`; then sudo=`which sudo` elif test -n `type -t sudo 2/dev/null`; then sudo=sudo fi Unfortunately my busybox version 1.1.3 behaves like this: ~ $ type -t sudo 2/dev/null -t: not found sudo: not found What about: if type sudo /dev/null 21; then sudo=sudo fi Works fine for me under bash and busybox. Thanks -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot reorganisation
Hi
I refactored the whole buildbot quite a lot. The following changes are worth
mentioning and were applied last saturday morning:
- upgraded to buildbot 0.7.4 (required to for better warning/logs)
- to speed up builds during the day reorganised the buildbot to
- quick builds which only calls svn update, run 2 minutes after a checkin.
Found at the usual place http://ngiger.dyndns.org/buildbot/
They should be finished normally 20 to 30 minutes after a checkin.
- full builds at 1 AM in the night, takes about 2 hours. Found at
http://ngiger.dyndns.org/buildbot-full/
- Using the AnyBranchScheduler to permit builds of branches/v2.2.2, in order
to catch failures like the one reported yesterday v2.2.x broken (r1534).
Here I am not totally sure whether everything will work as intended, but I
will have a close look on it.
- Reworked documentation, see
http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.{pdf|lyx}
- Warnings (if any) during compilations are found in the HTML log file of
a compile step, e.g. build
http://ngiger.dyndns.org/buildbot/hcu3_vx_q/builds/0
leads to
http://ngiger.dyndns.org/buildbot/hcu3_vx_q/builds/0/step-mk_kernel/2
I hope, that Gilles is satisfied, if not, please propose a better layout.
- During build time it should be possible to watch warnings coming in
realtime. But beware, that if the slave and master run on the same machine,
this will be really slow, for reasons still unknown to me.
- Added a help script extract_script.rb, which allows me to extract all
the steps run a build. Handy for debugging.
- Added a robots.txt to avoid incoming traffic on my machine. Everything robot
is no disallow to search anything under the buildbot/.
- Corrected test_sim.rb to output segmentation errors, check for error status
of all called test programs.
Buildbot has the very nice feature to be able to run a lot of steps
B E F O R E checking in the changes. See
http://buildbot.sourceforge.net/manual-0.7.4.html#try
If any of the committers would like to test the feature, I would love to add
this feature to the buildbot and would do all the necessary to give him the
necessary privilege on the buildmaster. I never tested this feature yet, but
would invest the necessary time if you drop me note that you are interested.
TODO:
- investigate why the sim segfaults on ppc
- why does the hcu3 test run with the quick but not the full build.
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot: Small glitch in simulator
Hi http://ngiger.dyndns.org/buildbot/sim/builds/18/step-check_sim/0 reports a small error in the simulator. Some problems were reported in: posix-tmq:: starting POSIX services. vxworks-t010823-2:t010823-2.c:163: Expected sequence: SEQ(Test2,2003); got SEQ(Test2,2004) vxworks-t010823-2: t010823-2.c:166, test finished: 1 failures/ 33 tests program finished with exit code 3 -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot reorgnized and will get prettier in the future
Hi everybody I invested quite a few hours to clean up my buildbot setup, as there were a lot of hacks going into it during the last few months which had reduced considerably its readability. The changes are now: - Work based on the Debian package 0.7.3 of buildbot - Documentation reworked/completed. It may be downloaded from: http://ngiger.dyndns.org/xenomai-data/xeno_buildbot.pdf - master.cfg reworked - clearer parameter passing to subscripts - prepared for debugging (simple way to skip steps, handy if only the last script of a 1 hour compilation run fails) - merged hacks for RTnet, DENX-2.4 kernel into xenoSteps procedure - scripts reworked, install*.sh merged into a single ruby script install.rb - Some work as I would like to make the installation directory may be specified per through /path/buitbot/slave/builder/instDef.rb and no more in master.cfg (using installPattern). At the moment both must match. As always the whole buildbot documentation and all scripts (except some which contain passwords) may be downloaded from: http://ngiger.dyndns.org/svn/admin/hcu3_linux/doc/buildbot/ Yesterday builbot 0.7.4 was released. I will try to switch to it and add the following improvements: - cleaning up installPattern in master.cfg - Prettier HTML output using a CSS. - Adding a readable HTML output of the simulator errors - May be use Debian init.d script to start/stop the daemons Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill
Hi All my PPC based compilation fail with something like ccache gcc -rdynamic -o .libs/rtcanconfig rtcanconfig.o -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/native -L/mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so -Wl,--rpath -Wl,/usr/xenomai/lib /mnt/data.ng/buildslave/buildbot/quick-ppc/build/ppc/src/skins/rtdm/.libs/librtdm.so: undefined reference to `pthread_kill' http://ngiger.dyndns.org/buildbot/ppc/builds/229/step-mk_xeno/0 Is this only a PPC problem? It appears first with build 226, which referred to revisions 1433 and 1434. Details see http://ngiger.dyndns.org/buildbot/ppc/builds/226 Jan, could you please have a look at the error, as it seems to me that you reduced the lib dependencies a little bit too much? Jan BTW, I also switched the RTNet svn to the new location. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot cannot compile xenoma: rtcanconfig refences pthread_kill
Am Dienstag, 15. August 2006 20:14 schrieb Jan Kiszka: Niklaus Giger wrote: Hi All my PPC based compilation fail with something like ... Things start to work again, but other issues pop up now. o The installation step of xenomai on the tqm860 is broken. For that reason RTnet fails to configure. Please have a look, Niklaus. I had noticed this just before the compile issues popped up. I will have a look, but the whole buildbot system is quite complex and confuses sometimes even its creator. o The simulator fails in both the posix and vxworks part: http://ngiger.dyndns.org/buildbot/sim/builds/258/step-check_sim/0 I reported the error vxworks-t010823-2:t010823-2.c:163: Expected sequence: SEQ(Test2,2009); got SEQ(Test2,2003) some time ago. Looks like a minor issue to me, as the simulator has its own internal timing. But I always prefer that Gilles fixes these kind of errors. Could anyone have a look? The other errors in the POSIX skin are new and need to be looked at. o The run test on the hcu_vx seems to cause a hang after the nucleus being loaded: http://ngiger.dyndns.org/buildbot/hcu_vx/builds/128/step-xeno-test/0 This is a long standing problem, where Philippe needs to get hand on a PPC40x system to find the error. I tried to give it a look hcu3 is fine, a rebuild of ppc is currently pending. hcu3 is the most important target (at least for me), as it is the only target which runs xeno-test. A few remarks and wishes: o Some list of the characteristics of those systems would be nice, just to gain overview what the differences are. I will try to fix my documentation. But from the beginning I wanted to introduce as much variance as possible in the different buildings, therefore I intentionally used different gcc versions, cross-compiling vs native, only xenomai vs xenomai+RTnet, POSIX vs VXWORKS, everything built-in vs everything as a module. Looking at all the different log files (I know that this is time consuming) usually gives me quite a few of the answers. o Maybe it's useful to strip the kernel configs of some systems (non-related drivers etc.) to reduce the turn-around time. I was thinking about it, but it is only the ppc build which takes a long time to build and I am running usually a specific build of this kernel to assure me that Xenomai is working all right in a real environment. Roundtrip time could also be improved if more buildbot slave were added. Though if anybody has a spare machine running all the time which could support the load of Xenomai builds, I would be glad to help integrate another slaves into my buildbot system. It would be also possible to add specific slave for anybody who wants to be assured that the Xenomai trunk continues to work for his specific board and build environment. o Some kind of allyesconfig for Xenomai would be nice. 2.4 doesn't seem to have this, but maybe one can derive that from a 2.6 .config, grab all XENO-related switches, and append them to the 2.4 .config. This way new stuff like the CAN stack now would get included faster. A allyesconfig is not possible as e.g. VXWORKS and the POSIX-skin have mutually exclusive requirements for the timing system (periodic vs aperiodic). If you want some specific CONFIG set please drop me a note. On final remark I can only repeat over and over again: Your buildbot is really great stuff! It significantly reduces the round-trip time for detecting and fixing (often trivial) build issues as long as there are not yet millions of Xenomai users updating their SVN checkout every day ;) Thanks for the compliment. As long as everybody on the mailing list responds so well to my complaints that something is broken, I will remain motivated to invest my time. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Buildbot running again. rtnet does not compile, small error in sim testsuite.
Hi Back from my vacation I discovered that the buildbot did not run during my absence as I had added a (debugging) printf some time before vacation. This printf did not harm as long as the session was alive. But before leaving I cleanup my desktop and bang the xenomai repository watcher got killed. Sorry! I fixed the error and now the buildbot is running again. RTnet seems to have a compile problem: see http://ngiger.dyndns.org/buildbot/tqm860/builds/227/step-mk_RTnet/0 In file included from rtnet_ifs.c:30: ../../../stack/include/rtnet.h:29:23: rtdm/rtdm.h: No such file or directory rtnet_ifs.c: In function `main': .. The timing behaviour seems to have changed a little bit as the simulator testsuite reports in: http://ngiger.dyndns.org/buildbot/sim/builds/213/step-check_sim/0 vxworks-t010823-2:t010823-2.c:163: Expected sequence: SEQ(Test2,2009); got SEQ(Test2,2002) vxworks-t010823-2: t010823-2.c:166, test finished: 1 failures/ 33 tests Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Improved xeno-test: Ready for checkin
Hi
Here is my patch for improved versions of xeno-info/load/config/test
as well as a Ruby test script for the maintainers.
The modified scripts pass the test for most options to xeno-test. The only
exception is -v for verbose. As I have no clue how/what this option should
do I left it as is.
The modifications are:
- busybox supported
- The load jobs (dd) are killed correctly
- two new lines for my buildbot xeno-test started and xeno-test finished
- the options -m / -L are no more silent, but echo also on the standard out.
If the old behaviour is preferred, it would be simple to restore it. But
the actual behaviour is easier to debug and fits better into the buildbot
logs.
The tests under the busybox are not as good as with a normal shell, but work
good enough with my buildbot. I will try to integrate them later into the
Ruby test script.
Attached are also all log files of my testruns, if you want to verify that
everything work as expected. A manual inspection of all logfiles did not
reveal anymore hidden bugs to me (after quite a few runs to improve my test
cases -).
After generating all logs, the testscript resumed the results like this:
Thu Jun 22 23:31:34 CEST 2006: 14 PASSED: 0 seconds. opts -M
[EMAIL PROTECTED] - returned 0 Writing tst to
/mnt/data.ng/hcu/kernel/xenomai-head/scripts/test/logs/xeno-test.store Thu
Jun 22 23:31:34 CEST 2006: 9 PASSED: -N marker:
[markertest-2.6.14-1252M-ppc-060622.232920] Thu Jun 22 23:31:34 CEST
2006: 8 PASSED: -L: [/tmp/test-2.6.14-1252M-ppc-060622.232417,
/tmp/test-2.6.14-1252M-ppc-060622.232452,
..
/tmp/test-2.6.14-1252M-ppc-2006-marker-06-marker,
/tmp/test-2.6.14-1252M-ppc-060622.233100] running all Checks
CHK 10 FAILED opts -v could not find xeno-test: finished
searched in
/mnt/data.ng/hcu/kernel/xenomai-head/scripts/test/logs/test_xeno_test.log.1
0 CHK 10 FAILED, could not find xeno-test: finished in
/mnt/data.ng/hcu/kernel/xenomai-head/scripts/test/logs/test_xeno_test.log.1
0 completed all Checks
Unless you spot any error in my tests, I will not improve my scripts nor the
xeno-test scripts in the near future. Also I would appreciate go know whether
the error is already present in the current version of xeno-test.
As rc3 is still not out, I do not see any reason not to check in this patch.
But I would like to see this happen soon, as I will not be able to fix errors
after next Wednesday.
Best regards
--
Niklaus Giger
Index: scripts/xeno-config.in
===
--- scripts/xeno-config.in (Revision 1254)
+++ scripts/xeno-config.in (Arbeitskopie)
@@ -1,4 +1,4 @@
-#! /bin/bash
+#! /bin/sh
staging=${DESTDIR}
prefix=@prefix@
Index: scripts/xeno-info
===
--- scripts/xeno-info (Revision 1254)
+++ scripts/xeno-info (Arbeitskopie)
@@ -1,31 +1,46 @@
-#!/bin/sh
+#! /bin/sh
#
# This file has been lifted 'as is' from linux/scripts/ver_linux.
-#
+# Adapted to be run also under the BusyBox. If you want to test it under the BusyBox use
+# busybox sh xeno-info
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:$PATH
echo 'If some fields are empty or look unusual you may have an old version.'
echo 'Compare to the current minimal requirements in Documentation/Changes.'
echo ' '
+withBusybox=0
+if sh --help 21| grep -q BusyBox; then
+withBusybox=1;
+# else running a real /bin/sh (bash) shell
+fi
+
+if test $withBusybox -eq 1; then busybox | grep -i BusyBox v ; fi
+
uname -a
echo ' '
+if test -n `which gcc` ; then
gcc --version 21| head -n 1 | grep -v gcc | awk \
'NR==1{print Gnu C , $1}'
gcc --version 21| grep gcc | awk \
'NR==1{print Gnu C , $3}'
+fi
+if test -n `which gcc` ; then
make --version 21 | awk -F, '{print $1}' | awk \
'/GNU Make/{print Gnu make ,$NF}'
+fi
ld -v 21 | awk -F\) '{print $1}' | awk \
'/BFD/{print binutils ,$NF}'
+if test 0 -eq $withBusybox ; then
fdformat --version | awk -F\- '{print util-linux, $NF}'
mount --version | awk -F\- '{print mount , $NF}'
+fi
depmod -V 21 | awk 'NR==1 {print module-init-tools ,$NF}'
@@ -50,21 +65,26 @@
isdnctrl 21 | grep version | awk \
'NR==1{print isdn4k-utils , $NF}'
+if test -n `which ldd` ; then
ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed \
-e 's/\.so$//' | awk -F'[.-]' '{print Linux C Library \
$(NF-2).$(NF-1).$NF}'
ldd -v /dev/null 21 ldd -v || ldd --version |head -n1 | awk \
'NR==1{print Dynamic linker (ldd) , $NF}'
+fi
ls -l /usr/lib/lib{g,stdc}++.so 2/dev/null | awk -F. \
'{print Linux C++ Library $4.$5.$6}'
+if test 0 -eq $withBusybox ; then
ps --version 21 | awk 'NR==1{print Procps, $NF}'
+fi
ifconfig --version 21 | grep tools | awk \
'NR==1{print Net-tools , $NF}'
+if test 0 -eq $withBusybox ; then
# Kbd
[Xenomai-core] Buildbot progress: runs xeno-test on one board
Hi
I just managed to put my newest version of the buildbot online. The following
new features are present:
- Updated to buildbot 0.7.3.
- Generate a file localversion in the build directory which contains the
svn revision number (using the new got_revision property in buildbot 0.7.3)
- For my embedded target HCU I build now two variants:
a) hcu3: with APERIODIC timer and the skins native, uvm, posix, psos
(as modules)
b) hcu_vx: with PERIODIC timer and the skins native, vrtx and vxworks
(built-in). This variant has known startup problems, see:
http://ngiger.dyndns.org/buildbot/hcu_vx/builds/7/step-xeno-test/0
- After compiling and installing the new kernel, modules and xenomai into
a nfs-root on the server, the last step calls a Ruby script. It patches
xeno-* to use my busybox variants. Then it powers the target on, waits till
it is ready, logs in. and calls xeno-test. Logs are not yet mailed to
xenomai-data, as there are still some unresolved problems with this
particular board.
An example output may be found going to:
http://ngiger.dyndns.org/buildbot/hcu3/builds/101/step-xeno-test/0
I hope this will generate a few more visit to the buildbot to verify whether
your changes broke something or not.
Specifying this test is done by the following Ruby code snippet:
# DefaultTTY = /dev/ttyUSB0
# DefaultPM = [172.25.1.211, 2]
def runTest(device=DefaultTTY, pmIp = DefaultPM )
res = false
checkXenoTestPatch
pm211 = PowerModule.new(pmIp[0], pmIp[1])
scc = File.open(device, w+)
CommDevice::setHCU3(scc)
hcu3 = RmtTstRunner.new(scc, pm211, LogName)
hcu3_steps =
[ TestStep.new(U-Boot, 5, nil),# Wait till
U-Boot is awake
TestStep.new(main_loop, 10, nil),# Wait till
U-Boot
loads kernel
TestStep.new(Transferring control to Linux, 10), # U-Boots job is
finished now
TestStep.new(Linux version, 5, nil), # Linux is alive!
TestStep.new(Freeing unused kernel memo, 10, nil), # Linux init
finished
TestStep.new(Willkommen, 10, nil),
TestStep.new(login, 5, root),
TestStep.new(/usr/xenomai/bin $, 5, cd /usr/xenomai/bin),
TestStep.new(xeno-test: started, 5, ./xeno-test -T #{XenoRunTime}),
TestStep.new(xeno-test: finished, (30 + XenoRunTime)*NrXenoTests, nil)
]
res = hcu3.runTest(hcu3_steps)
hcu3.power.power(false)
puts #{Time.now.strftime(%H:%M:%S)}: Running xeno-test reported #{res}.
Will dump output
system cat #{LogName}
return res
end
end
If you are interested in more details, take a look at
http://ngiger.dyndns.org/xenomai-date. The API of the used Ruby code is found
at http://ngiger.dyndns.org/xenomai-data/doc
All the sources (and the a little bit outdated documentation of the buildbot
setup) can be checkedout via
http://ngiger.dyndns.org/svn/admin/hcu3_linux/doc/buildbot/.
Next steps will be documentation cleanup, improving xeno-test and adding a x86
slave. (I just receveived an old x86-pc box, which I hope to make it boot via
NFS.) But do not expect a lot of progress in the next 6 weeks as in 10 day I
will leave for a 3 week vacation to Korea.
I am just puzzled that during the test, I get
cat: /proc/xenomai/sched: No such process
Sat Jun 17 21:48:53 UTC 2006
running: cat /proc/xenomai/stat
cat: /proc/xenomai/stat: No such process
Why do I get this answer? (xeno-test calls cat only for existing files?)
Best regards
--
Niklaus Giger
___
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
Am Mittwoch, 14. Juni 2006 15:23 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Is it okay to submit such a patch, which mixes a different test cases or shall I submit the patches in smaller pieces? Should the test that I put into the procedure msgDuringInt better be inlined? Or should I add a new file for these tests? I think it is a good idea to add some more tests to the message queues tests. I also agree with the idea of documenting the differences instead of being bug compatible. However, I would apply a few cosmetic changes to the patch before including it. Comments follow, please tell me if you agree with these changes. -TEST_ASSERT(taskIdVerify(0) == ERROR errno == S_objLib_OBJ_ID_ERROR); +errno = 0; +TEST_ASSERT(taskIdVerify(0) == ERROR errno == 0); This is weird, it means that taskIdVerify does not set errno when passed a null argument, but returns ERROR. Anyway, and this goes for all other checks, I do not like errno = 0. If errno is not set, let us not check it. Okay. That's probably safer. +errno = 0; +TEST_ASSERT(taskIdVerify(malloc(20)) == ERROR errno == S_objLib_OBJ_ID_ERROR); You should memset the new malloced block (or use calloc instead of malloc), in order to be sure that it is invalid. And free it after use. I didn't bother about the memory leak, as the testsuite was not meant to live a long time. And it kept the changes smaller. But I would never accept this kind of code in a production system. So we better clean it up. +TEST_ASSERT_OK(rc); +TEST_ASSERT(errno == 0); There is no guarantee that the syscalls will not set errno when returning OK. I would remove every TEST_ASSERT(errno == 0). Agreed. +TEST_ASSERT(rc == ERROR); +TEST_ASSERT(errno == S_msgQLib_NON_ZERO_TIMEOUT_AT_INT_LEVEL); Here, and in several other places, I would use only one assert, as it is done in other tests. Fine for me. Just while developing test cases it was more convenient to know exactly which condition lead to an error. +errno = 0; qid = msgQCreate(NMESSAGES,sizeof(int),0x); -TEST_ASSERT(qid == 0 errno == S_msgQLib_INVALID_QUEUE_TYPE); +TEST_ASSERT(qid != 0 errno == 0); +if (qid) msgQDelete(qid); Here, it appears that vxworks and xenomai vxworks skin are incompatible, changing the test code will make the test fail for xenomai. Would not it be a better idea to document this difference ? After all, users code is supposed to never use erroneous arguments, and if it does, it is better to learn it when porting code to xenomai than to keep ignoring it silently. Agreed. Do you agree with the following sentence for vxworks-skin.txt? Passing a argument to options with non defined bits for msgQCreate will return 0 under the xenomai skin. VxWorks returns a valid msqId. -rc = msgQSend(qid,(char *)message_list[0],0,WAIT_FOREVER,MSG_PRI_NORMAL); +errno = 0; +rc = msgQSend(qid,(char *)message_list[0],2*message_list[0], WAIT_FOREVER,MSG_PRI_NORMAL); TEST_ASSERT(rc == ERROR errno == S_msgQLib_INVALID_MSG_LENGTH); Accepting null length messages may be a feature, does a receiver receive the null length message with vxworks ? I will check and give you an answer about this later (probably before Friday evening). -rc = msgQReceive(qid,(char *)msg,0,NO_WAIT); -TEST_ASSERT(rc == ERROR errno == S_msgQLib_INVALID_MSG_LENGTH); Null length message again, does this work with the real vxworks ? Same here. +rc = msgQNumMsgs(qid); You do not use this value. Missing TEST_ASSERT ? No. Bad cleanup before sending. I had some redundant tests after this position. Just kill this line. You may either check in a modified version of this patch or wait till I send you one which incorporates your suggestions. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Breakage in trunk
Hi I noticed that, eg. http://ngiger.dyndns.org/buildbot/hcu3/builds/80/step-mk_xeno/0 there are build failures. It tells me Making install in vrtx make[4]: Entering directory `/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx' make[4]: *** No rule to make target `event.c', needed by `libvrtx_la-event.lo'. Stop. Last successfull build for hcu3 was with Revision: 1195 tqm860 still failes as shown in http://ngiger.dyndns.org/buildbot/tqm860/builds/97/step-mk_kernel/0 with gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -I/home/buildslave/buildbot/quick-tqm860/build/linuxppc_2_4_devel-2006-04-06-1735/arch/ppc -o scripts/split-include scripts/split-include.c make: *** No rule to make target `include/linux/autoconf.h', needed by `include/config/MARKER'. Stop. Could someone looking at these failures, please? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up
Hi Philippe I redid my testing wit revision 1188 (+ modification from me for the xeno-test). The lockup at startup is still there if CONFIG_XENO_OPT_TIMING_PERIOD != 0 and if the skins native, posix, rtdm, uvm and skins skins are compiled in. Timing settings was always CONFIG_XENO_OPT_TIMING_PERIODIC=y. Linux version 2.6.14-1188M-hcu3 ([EMAIL PROTECTED]) (gcc version 3.4.4) #4 Sun Jun 11 19:45:36 CEST 2006 HCU3 Netstal Maschinen AG with U-Boot 1.1.2. Built 1 zonelists Kernel command line: console=ttyS0,9600 root=/dev/nfs rw nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off panic=30 PID hash table entries: 256 (order: 8, 4096 bytes) I-pipe 1.3-03: pipeline enabled. Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 29884k available (1740k kernel code, 608k data, 92k init, 0k highmem) Mount-cache hash table entries: 512 softlockup thread 0 started up. NET: Registered protocol family 16 I-pipe: Domain Xenomai registered. Xenomai: hal/powerpc started. Xenomai: real-time nucleus v2.2-rc2 (Engines Of Creation) loaded. Xenomai: starting native API services. Xenomai: starting POSIX services. Xenomai: starting RTDM services. Xenomai: starting UVM services. Xenomai: incompatible timer mode (aperiodic found, need periodic). Xenomai: VxWorks skin init failed, code -16. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled .. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Revision 1182 broke compiling PPC
Hi Philippe Your change seems to be broken (at least on PPC). In http://ngiger.dyndns.org/buildbot/hcu3/builds/71/step-mk_xeno/0 you will notice near the end gcc -DHAVE_CONFIG_H -I. -I../../../../../build/xenomai/src/skins/vrtx -I../../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__IN_XENO__ -Wstrict-prototypes -I../../../../../build/xenomai/include -MT libvrtx_la-task.lo -MD -MP -MF .deps/libvrtx_la-task.Tpo -c ../../../../../build/xenomai/src/skins/vrtx/task.c -fPIC -DPIC -o .libs/libvrtx_la-task.o ../../../../../build/xenomai/src/skins/vrtx/task.c:250:21: error: macro XENOMAI_SKINCALL1 requires 3 arguments, but only 2 given ../../../../../build/xenomai/src/skins/vrtx/task.c: In function 'sc_delay': ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: 'XENOMAI_SKINCALL1' undeclared (first use in this function) ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: (Each undeclared identifier is reported only once ../../../../../build/xenomai/src/skins/vrtx/task.c:249: error: for each function it appears in.) make[4]: *** [libvrtx_la-task.lo] Error 1 make[4]: Leaving directory `/mnt/data.ng/buildslave/buildbot/quick-hcu3/build/hcu/src/skins/vrtx' Could you please take a look at it? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Porting xeno-{info|load|test} to a busybox system
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.
Did so, and here comes the result: :)
Thanks a lot for your prompt feedback.
..
This may become fragile (and it already is on my hacked system). The
reason: plans exist to allow compiling bb into multiple binaries again,
thus sh will not be linked to busybox, but to ash e.g.
Sure. It was just my first idea. But your proposed solution is better and
already
..
When using this variant, I get the following messages:
/bin/xeno-test: /bin/xeno-test: 177: zgrep: not found
What about zcat | grep instead? Moreover, I failed to find a zgrep bb
applet. Did you copy that stuff on your box?
Sorry. As I had segmentation faults, my run did not get so far/or I missed
this error. Running it manually I confirmed your bug and the proposed
solution works for me, too. Integrated in the new version (attached) of the
patch.
/bin/xeno-test: /bin/xeno-test: 264: getopts: not found
getopts is off by default in bb. Is this essential for xeno-test? Then
you should state this requirement somewhere.
I checked out BusyBox 1.13, run make defconfig, changed the cross-compiler
and install path. But I verified that a make defconfig on the 1.00 version
had # CONFIG_ASH_GETOPTS is not set.
Could you try the attached patch using busybox with CONFIG_ASH_GETOPTS=y?
/bin/xeno-test: shift: 267: Illegal number: -1
I guess this comes from the missing getopts...
Regarding workload: I typically run the cache calibrator [1] in a look,
together with some I/O load (hard disk where available, flood ping). The
loop looks like
while true; do calibrator box-MHz 8M /tmp/; done
box-MHz should be derivable from /proc/cpuinfo with some scripting. We
may just check if an inclusion of the calibrator source code is possible
(license terms...).
Didn't know this tool. But I think this is another suggestion to improve
xeno-test.
Lacking time right now, otherwise I would have hacked further to make
the test run. This test could be quite interesting for us here to
quickly check our processing boxes' hardware and to test new Xenomai
versions for elementary regressions when upgrading production systems
(fortunately only their CF-cards). Looking forward!
Nice to hear that. So could you please give my patch a second try with a
modified busybox?
--
Niklaus Giger
Index: scripts/xeno-config.in
===
--- scripts/xeno-config.in (Revision 1137)
+++ scripts/xeno-config.in (Arbeitskopie)
@@ -1,4 +1,4 @@
-#! /bin/bash
+#! /bin/sh
staging=${DESTDIR}
prefix=@prefix@
Index: scripts/xeno-info
===
--- scripts/xeno-info (Revision 1137)
+++ scripts/xeno-info (Arbeitskopie)
@@ -1,31 +1,46 @@
-#!/bin/sh
+#! /bin/sh
#
# This file has been lifted 'as is' from linux/scripts/ver_linux.
-#
+# Adapted to be run also under the BusyBox. If you want to test it under the BusyBox use
+# busybox sh xeno-info
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:$PATH
echo 'If some fields are empty or look unusual you may have an old version.'
echo 'Compare to the current minimal requirements in Documentation/Changes.'
echo ' '
+withBusybox=0
+if sh --help 21| grep -q BusyBox; then
+withBusybox=1;
+# else running a real /bin/sh (bash) shell
+fi
+
+if test $withBusybox -eq 1; then busybox | grep -i BusyBox v ; fi
+
uname -a
echo ' '
+if test -n `which gcc` ; then
gcc --version 21| head -n 1 | grep -v gcc | awk \
'NR==1{print Gnu C , $1}'
gcc --version 21| grep gcc | awk \
'NR==1{print Gnu C , $3}'
+fi
+if test -n `which gcc` ; then
make --version 21 | awk -F, '{print $1}' | awk \
'/GNU Make/{print Gnu make ,$NF}'
+fi
ld -v 21 | awk -F\) '{print $1}' | awk \
'/BFD/{print binutils ,$NF}'
+if test 0 -eq $withBusybox ; then
fdformat --version | awk -F\- '{print util-linux, $NF}'
mount --version | awk -F\- '{print mount , $NF}'
+fi
depmod -V 21 | awk 'NR==1 {print module-init-tools ,$NF}'
@@ -50,21 +65,26 @@
isdnctrl 21 | grep version | awk \
'NR==1{print isdn4k-utils , $NF}'
+if test -n `which ldd` ; then
ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed \
-e 's/\.so$//' | awk -F'[.-]' '{print Linux C Library \
$(NF-2).$(NF-1).$NF}'
ldd -v /dev/null 21 ldd -v || ldd --version |head -n1 | awk \
'NR==1{print Dynamic linker (ldd) , $NF}'
+fi
ls -l /usr/lib/lib{g,stdc}++.so 2/dev/null | awk -F. \
'{print Linux C++ Library $4.$5.$6}'
+if test 0 -eq $withBusybox ; then
ps --version 21 | awk 'NR==1{print Procps, $NF}'
+fi
ifconfig --version 21 | grep tools | awk \
'NR==1{print Net
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Freitag, 26. Mai 2006 19:49 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.) Automatic re-building does not work for the simulator. So, in case of segmentation fault, try: make clean all check Yes, I noticed this as I was looking for a compile of thread.cc. Therefore I did a clean rebuild (but a little bit different than your receipt). After rebuilding using make clean all check under sim and sim/skin/posix/testsuite, I still get the same failure. Regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Porting xeno-{info|load|test} to a busybox system
Hi
For my embedded target system I installed BusyBox as it was the easiest way to
get a small GNU/Linux system to boot into a working shell. (But it takes less
than 16 seconds from power on till the the familiar login: prompt.)
But I ran into the problem, that the xeno-*-applications did not run under the
busybox environment. Here are some comment on my proposed changes.
1) To make a shell work under the busybox I had to specify #! /bin/sh instead
of #! /bin/bash.
2) To make the run I run the xeno-*-applications on my Debian GNU/Linux
PowerBook
either as:
$ xeno-info
or as
$ busybox sh xeno-info
3) Once all tests passed on my PowerBook, I switched to the embedded PPC405GPr
board using a recent busybox (version 1.1.3).
This exposed some more not supported errors, eg.
fdformat: unrecognized option `--version'
Also on an embedded system a lot of the usual utilites like gcc, make, etc are
not present. Therefore I checked for their existence with expressions like
`which make`
4) As the BSD utility script is not present on my embedded system,
xeno-test -L does not work.
5) The busybox shell does not know arrays. Also for unknown reasons the
dd_jobs variable got not updated outside of the function generate_loads.
Therefore I added a killall dd in the cleanup.
6) trap CHLD did not work under the BusyBox. Also (to be sure) called
cleanup_load manually before exit.
7) Id did not ident the not busybox parts in xeno-info. This makes the patch
smaller and more readable, but should probably be corrected before applying
it.
8) Using `dirname $0` relative paths to make xeno-test work also if not called
in /usr/xenomai/bin
9) Changing the e-mail address to [EMAIL PROTECTED] is also included.
Checking the changes between running xeno-test (as bash or as busybox) and the
old one did not reveal any significant changes. On my PPC405 system I could
not complete this test as there segmentation faults running the invidual
tests.
I would appreciate if these changes (or similar) could go -- after a review --
into the trunk (not necessarily before 2.2). I am specially interested in Jim
Cromie's opinion.
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.
These changes are a precondition to make the buildbot run xeno-test on the
only board where I can easily and automatically switch the power off and on,
without risking a family crisis.
Best regards
--
Niklaus Giger
Index: scripts/xeno-config.in
===
--- scripts/xeno-config.in (Revision 1135)
+++ scripts/xeno-config.in (Arbeitskopie)
@@ -1,4 +1,4 @@
-#! /bin/bash
+#! /bin/sh
staging=${DESTDIR}
prefix=@prefix@
Index: scripts/xeno-info
===
--- scripts/xeno-info (Revision 1135)
+++ scripts/xeno-info (Arbeitskopie)
@@ -1,31 +1,51 @@
-#!/bin/sh
+#! /bin/sh
#
# This file has been lifted 'as is' from linux/scripts/ver_linux.
-#
+# Adapted to be run also under the BusyBox. If you want to test it under the BusyBox use
+# busybox sh xeno-info
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:$PATH
echo 'If some fields are empty or look unusual you may have an old version.'
echo 'Compare to the current minimal requirements in Documentation/Changes.'
echo ' '
+withBusybox=0
+if test -L $SHELL ; then # is sh a logical link to busybox
+exeName=`ls -l $SHELL|cut -d\ -f2`
+if test `basename $exeName` = busybox; then
+ withBusybox=1; else echo 2.3
+fi
+elif test -n $_ -a `basename $_` = busybox; then
+withBusybox=1;
+# else running a real /bin/sh (bash) shell
+fi
+
+if test $withBusybox -eq 1; then busybox | grep -i BusyBox v ; fi
+
uname -a
echo ' '
+if test -n `which gcc` ; then
gcc --version 21| head -n 1 | grep -v gcc | awk \
'NR==1{print Gnu C , $1}'
gcc --version 21| grep gcc | awk \
'NR==1{print Gnu C , $3}'
+fi
+if test -n `which gcc` ; then
make --version 21 | awk -F, '{print $1}' | awk \
'/GNU Make/{print Gnu make ,$NF}'
+fi
ld -v 21 | awk -F\) '{print $1}' | awk \
'/BFD/{print binutils ,$NF}'
+if test 0 -eq $withBusybox ; then
fdformat --version | awk -F\- '{print util-linux, $NF}'
mount --version | awk -F\- '{print mount , $NF}'
+fi
depmod -V 21 | awk 'NR==1 {print module-init-tools ,$NF}'
@@ -50,21 +70,26 @@
isdnctrl 21 | grep version | awk \
'NR==1{print isdn4k-utils , $NF}'
+if test -n `which ldd` ; then
ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed \
-e 's/\.so$//' | awk -F'[.-]' '{print Linux C Library \
$(NF-2).$(NF-1).$NF}'
ldd -v /dev/null 21 ldd -v || ldd --version |head -n1 | awk \
'NR==1{print Dynamic linker (ldd) , $NF}'
+fi
ls -l /usr/lib/lib{g,stdc}++.so 2/dev/null | awk -F. \
'{print
[Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up
Hi everybody Philippe Gerum wrote: Here is the second release candidate for the v2.2 branch. Short log follows: Sorry for reporting so late. But as my tests did not yet include starting up my board I did not notice that changes (probably between 2006-05-10 19:30 and 2006-05-11 20:31) made my board unbootable. The board hangs after emitting (Engines Of Creation) loaded. output is: ocp: exit arch: exit Linux version 2.6.14hcu3 ([EMAIL PROTECTED]) (gcc version 3.4.4) #17 Tue May 16 19:24:07 CEST 2006 HCU3 Netstal Maschinen AG with U-Boot 1.1.2. Built 1 zonelists Kernel command line: console=ttyS0,9600 root=/dev/nfs rw nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off panic=30 PID hash table entries: 256 (order: 8, 4096 bytes) I-pipe 1.3-02: pipeline enabled. Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 29756k available (1856k kernel code, 604k data, 100k init, 0k highmem) Mount-cache hash table entries: 512 softlockup thread 0 started up. NET: Registered protocol family 16 TIMER IRQ is 32 I-pipe: Domain Xenomai registered. Xenomai: hal/powerpc started. Xenomai: real-time nucleus v2.2-rc1 (Engines Of Creation) loaded. I have no ideas why, as my PowerBook is running fine with an actual Xenomai based kernel. But I now that the timer architecture for the PPC40x family is quite different to the PPC en general. Any ideas where to begin debugging? I am familiar whith the timer/interrupt architecture of the PPC405 but a hint would be welcome. I will take my BDI debugger from Abatron home to have a look where the processor hangs, but will not have time till tomorrow or Wednesday to dig into this problem. Best regards Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up
Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum: Niklaus Giger wrote: Hi everybody Philippe Gerum wrote: Here is the second release candidate for the v2.2 branch. Short log follows: ... Could you try building all skins as modules with only the nucleus statically built into the kernel? I'd like to know whether the lockup occurs when one of the skin attempts to initialize, or if the problem is in the early Xenomai bootstrap. TIA, Okay. With the following .config XENOMAI settings my target starts up without any problem till the login: CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y CONFIG_XENO_OPT_SECURITY_ACCESS=y CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=128 # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_PIPELINE_HEAD=y CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set CONFIG_XENO_OPT_WATCHDOG=y CONFIG_XENO_OPT_TIMING_PERIODIC=y CONFIG_XENO_OPT_TIMING_PERIOD=100 CONFIG_XENO_OPT_TIMING_TIMERLAT=0 CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_SHIRQ_LEVEL is not set # CONFIG_XENO_OPT_SHIRQ_EDGE is not set # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_SKIN_NATIVE=m # CONFIG_XENO_OPT_NATIVE_PIPE is not set CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y CONFIG_XENO_OPT_NATIVE_INTR=y CONFIG_XENO_SKIN_POSIX=m # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set CONFIG_XENO_SKIN_VXWORKS=m CONFIG_XENO_SKIN_RTAI=m CONFIG_XENO_OPT_RTAI_SEM=y CONFIG_XENO_OPT_RTAI_SHM=y CONFIG_XENO_SKIN_RTDM=m CONFIG_XENO_OPT_RTDM_FILDES=128 CONFIG_XENO_SKIN_UVM=m # CONFIG_XENO_DRIVERS_16550A is not set CONFIG_XENO_DRIVERS_TIMERBENCH=m Diff to my old .config is: 4c4 # Mon May 22 18:02:59 2006 --- # Sun May 21 00:23:12 2006 74a75,76 CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 113,114c115,117 CONFIG_XENO_SKIN_NATIVE=m # CONFIG_XENO_OPT_NATIVE_PIPE is not set --- CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 125c128 CONFIG_XENO_SKIN_POSIX=m --- CONFIG_XENO_SKIN_POSIX=y 129,133c132,137 CONFIG_XENO_SKIN_VXWORKS=m CONFIG_XENO_SKIN_RTAI=m CONFIG_XENO_OPT_RTAI_SEM=y CONFIG_XENO_OPT_RTAI_SHM=y CONFIG_XENO_SKIN_RTDM=m --- CONFIG_XENO_SKIN_VXWORKS=y # # RTAI emulator unavailable, disable native API or build it as module # CONFIG_XENO_SKIN_RTDM=y 135c139 CONFIG_XENO_SKIN_UVM=m --- CONFIG_XENO_SKIN_UVM=y 141c145 CONFIG_XENO_DRIVERS_TIMERBENCH=m --- CONFIG_XENO_DRIVERS_TIMERBENCH=y Thanks a lot for your help -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up
Hi
Am Montag, 22. Mai 2006 18:47 schrieb Philippe Gerum:
Niklaus Giger wrote:
Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum:
Niklaus Giger wrote:
Hi everybody
Philippe Gerum wrote:
Here is the second release candidate for the v2.2 branch. Short log
follows:
...
Could you try building all skins as modules with only the nucleus
statically built into the kernel? I'd like to know whether the lockup
occurs when one of the skin attempts to initialize, or if the problem is
in the early Xenomai bootstrap. TIA,
Okay. With the following .config XENOMAI settings my target starts up
without any problem till the login:
Does the board still boot with only the native skin enabled statically?
No. It does not.
If it does not, wild guess: does the following patch prevent the lockup
in the latter case?
--- pod.c~2006-05-15 15:03:52.0 +0200
+++ pod.c 2006-05-22 18:45:21.0 +0200
@@ -509,12 +509,14 @@
xnarch_notify_ready();
+#if 0
err = xnpod_reset_timer();
if (err) {
xnpod_shutdown(XNPOD_FATAL_EXIT);
return err;
}
+#endif
return 0;
}
Excellent wild guess! With this patch I get my target up and running. First
test is with only the native skin worked. Then I restore my original .config,
touched it and rebuilt. Still boots without any problems.
Thanks a lot for your help.
Best regards
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: Here is the second release candidate for the v2.2 branch. Short log follows: Could you please apply the patch below to make xeno-test send e-mails to [EMAIL PROTECTED] I am unsure whether setting sentby='[EMAIL PROTECTED]' is a good idea. Or is this a way to accept e-mails from unkown senders? In any way I think it would be nice if one could accept xeno-test messages from unsubscribed senders. I really would like to collect some real data. Thanks in advance. Niklaus Giger Index: scripts/xeno-test.in === --- scripts/xeno-test.in(Revision 1135) +++ scripts/xeno-test.in(Arbeitskopie) @@ -19,7 +19,7 @@ name can be full or relative pathname -v verbose -M email sends output to given addr - -m sends output to [EMAIL PROTECTED] + -m sends output to [EMAIL PROTECTED] -U url uploads output to given URL # following options are passed thru to latency @@ -167,7 +167,7 @@ logprefix=/tmp/# someplace usually there prepost= # command to run pre, and post test (ex ntpq -p) -email='[EMAIL PROTECTED]' # until formalized +email='[EMAIL PROTECTED]' sentby='[EMAIL PROTECTED]' url= sendit=# send it by m-mail, u-url ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai v2.2-rc2
Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum: Here is the second release candidate for the v2.2 branch. Short log The trunks builds fine on my four targets on http://ngiger.dyndns.org/buildbot/ I have however still the following errors running the posix simulators (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). All others posix and vxworks test pass. The output is: Some problems were reported in: posix-tthread:tthread.c:141: Expected sequence: SEQ(slicer1,1); got SEQ(slicer1,4) posix-tthread:tthread.c:142: Expected sequence: SEQ(slicer2,1); got SEQ(slicer2,4) posix-tthread:tthread.c:143: Expected sequence: SEQ(slicer1,1); got SEQ(root,1) posix-tthread:tthread.c:144: Expected sequence: SEQ(slicer2,1); reached end of recorded sequence. posix-tthread:tthread.c:145: Expected sequence: SEQ(slicer1,1); reached end of recorded sequence. posix-tthread:tthread.c:146: Expected sequence: SEQ(slicer2,1); reached end of recorded sequence. posix-tthread:tthread.c:147: Expected sequence: SEQ(slicer1,1); reached end of recorded sequence. posix-tthread:tthread.c:148: Expected sequence: SEQ(slicer2,1); reached end of recorded sequence. posix-tthread:tthread.c:149: Expected sequence: SEQ(root,1); reached end of recorded sequence. posix-tthread:tthread.c:153, test finished: 9 failures/ 46 tests I have however no time to try to fix them, as I am investing more time into making xeno-test run automatically on my PPC 405GPr target board. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Patch for better error messages in posix testsuite
Hi
If one greps the output of the posix testsuite failures does not show
up cleanly as the assertions are terminated by a line feed.
Please apply the following patch which fixes this problem
Index: sim/skins/posix/testsuite/xntest.c
===
--- sim/skins/posix/testsuite/xntest.c (Revision 1103)
+++ sim/skins/posix/testsuite/xntest.c (Arbeitskopie)
@@ -91,7 +91,7 @@
++tests;
if(!status) {
++test_failures;
-xnarch_printf(%s:%d: TEST %s failed.\n, file, line, assertion);
+xnarch_printf(%s:%d: TEST failed: %s\n, file, line, assertion);
} else
xnarch_printf(%s:%d TEST passed.\n, file, line);
xnlock_put_irqrestore(test_lock, s);
Thanks in advance
--
Niklaus Giger
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Kernel panic on rmmod xeno_vxworks
Am Mittwoch, 10. Mai 2006 23:24 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: Hi I compiled and started my test with a recent xenomai/trunk (revision 1068). I booted into single user mode, did a modprobe xeno_vxworks (no problem) and then a rmmod xeno_vxworks and got as response on my PowerBook only Kernel panic: -not syncing: Aiee, killing interrupt handler. Also when I try to run ksrc/skins/vxworks/demos/satch (after a make std) I get the following info (using gdb): (gdb) run Starting program: /mnt/data.ng/hcu/kernel/xenomai-head/ksrc/skins/vxworks/demos/satch [Thread debugging using libthread_db enabled] [New Thread 805415264 (LWP 4168)] [New Thread 805434592 (LWP 4171)] [New Thread 805450976 (LWP 4172)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805434592 (LWP 4171)] 0x0fe76094 in vfprintf () from /lib/tls/libc.so.6 (gdb) info stack #0 0x0fe76094 in vfprintf () from /lib/tls/libc.so.6 #1 0x0fe7e760 in printf () from /lib/tls/libc.so.6 #2 0x10001a6c in consumer_task (a0=269287424, a1=268894208, a2=269477288, a3=0, a4=0, a5=0, a6=269482760, a7=805474048, a8=2144297840, a9=268064096) at satch.c:99 #3 0x0ffa7714 in wind_task_trampoline (cookie=0x7fcf632c) at /mnt/data.ng/hcu/kernel/xenomai-head/src/skins/vxworks/taskLib.c:99 #4 0x0ffd08e8 in start_thread () from /lib/tls/libpthread.so.0 #5 0x0ffd08e8 in start_thread () from /lib/tls/libpthread.so.0 Previous frame inner to this frame (corrupt stack?) I observed such an error when the stack size is to small, I guess vfprintf uses alloca. This fixed my problem. Task crashes with 18 kB stack, but not with 20 kB. Therefore I propose 24 kB to have some margine for the future. Please apply the following patch: Index: ksrc/skins/vxworks/demos/satch.c === --- ksrc/skins/vxworks/demos/satch.c(Revision 1068) +++ ksrc/skins/vxworks/demos/satch.c(Arbeitskopie) @@ -21,10 +21,10 @@ #include vxworks/vxworks.h #define CONSUMER_TASK_PRI115 -#define CONSUMER_STACK_SIZE 8192 +#define CONSUMER_STACK_SIZE 24*1024 #define PRODUCER_TASK_PRI110 -#define PRODUCER_STACK_SIZE 8192 +#define PRODUCER_STACK_SIZE 24*1024 #define CONSUMER_WAIT 150 #define PRODUCER_TRIG 40 Thanks in advance. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Errors running sim testsuite for vxWorks
Hi Running the sim testsuite vxworks (revision 1078) (using the attached script) I get the following a few failures and memory corruption: trestart.c:46, taskSpawn(nop, 19, 0, 32768, nopTask, 0,0,0,0,0,0,0,0,0,0) != ERROR *** glibc detected *** malloc(): memory corruption: 0x100bf000 *** t010726-1.log:t010726-1.c:106, test finished: 4 failures/ 15 tests t010726-2.log:t010726-2.c:224, test finished: 0 failures/ 82 tests t010728.log:t010728.c:119, test finished: 0 failures/ 4 tests t010820-1.log:t010820-1.c:90, test finished: 0 failures/ 23 tests t010820-2.log:t010820-2.c:81, test finished: 0 failures/ 11 tests t010823-1.log:t010823-1.c:114, test finished: 0 failures/ 16 tests t010823-2.log:t010823-2.c:166, test finished: 1 failures/ 33 tests Is this normal or a powerpc specific error of the Xenomai simulator? How do I debug trestart as it is not a fully linked executable? Is it normal that a make check only works, if one builds the simulator inside the source code? Thanks for any suggestion. Best regards -- Niklaus Giger test_sim Description: application/shellscript ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RFC: Integrate Xenomai's simulator's testsuite into the buildbot
Hi I would like to integrate the output of the Xenomai's simulator's testsuite into my buildbot system at htttp://ngiger.dyndns.org/ As I work with a PowerPC system I am still chasing some bugs (Thanks a lot to Gilles for his help). I am interested to know whether an output like the attached (12-log-check-sim-log.bz2) produced with my ruby script (attached test_sim.rb) is a good idea. Look at the end to get a summary of the failed/passed tests. (I have no idea, why the output to standard error like segmentation fault does not show up instead of the starting POSIX services.). So please tell me if you would like to have some more information in the log. I would appreciate to be able to integrate the same testsuites as part of the regression test of all target that use a posix or vxworks skin. I am however no specialist in the autotools. Would it be difficult to adapt the Makefile's to have the same targets sim, std and uvm like in the ksrc/skins/x/demos? Are there any other ideas what to test with the simulator? (I do not want to to test xenoscope unless somebody can point me to free tool where it is easy to setup some interactive tests.) To test the distcheck target is still on my todo list, but with a lower priority. Thanks in advance for all comments. Best regards -- Niklaus Giger test_sim.rb Description: application/ruby 12-log-check_sim-log.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Kernel panic on rmmod xeno_vxworks
Hi I compiled and started my test with a recent xenomai/trunk (revision 1068). I booted into single user mode, did a modprobe xeno_vxworks (no problem) and then a rmmod xeno_vxworks and got as response on my PowerBook only Kernel panic: -not syncing: Aiee, killing interrupt handler. Also when I try to run ksrc/skins/vxworks/demos/satch (after a make std) I get the following info (using gdb): (gdb) run Starting program: /mnt/data.ng/hcu/kernel/xenomai-head/ksrc/skins/vxworks/demos/satch [Thread debugging using libthread_db enabled] [New Thread 805415264 (LWP 4168)] [New Thread 805434592 (LWP 4171)] [New Thread 805450976 (LWP 4172)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805434592 (LWP 4171)] 0x0fe76094 in vfprintf () from /lib/tls/libc.so.6 (gdb) info stack #0 0x0fe76094 in vfprintf () from /lib/tls/libc.so.6 #1 0x0fe7e760 in printf () from /lib/tls/libc.so.6 #2 0x10001a6c in consumer_task (a0=269287424, a1=268894208, a2=269477288, a3=0, a4=0, a5=0, a6=269482760, a7=805474048, a8=2144297840, a9=268064096) at satch.c:99 #3 0x0ffa7714 in wind_task_trampoline (cookie=0x7fcf632c) at /mnt/data.ng/hcu/kernel/xenomai-head/src/skins/vxworks/taskLib.c:99 #4 0x0ffd08e8 in start_thread () from /lib/tls/libpthread.so.0 #5 0x0ffd08e8 in start_thread () from /lib/tls/libpthread.so.0 Previous frame inner to this frame (corrupt stack?) The XENOMAI-parts of my config are: grep XENO /boot/config-2.6.14 CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y CONFIG_XENO_OPT_SECURITY_ACCESS=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=128 # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_PIPELINE_HEAD=y CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set CONFIG_XENO_OPT_WATCHDOG=y CONFIG_XENO_OPT_TIMING_PERIODIC=y CONFIG_XENO_OPT_TIMING_PERIOD=100 CONFIG_XENO_OPT_TIMING_TIMERLAT=0 CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_SHIRQ_LEVEL is not set # CONFIG_XENO_OPT_SHIRQ_EDGE is not set CONFIG_XENO_HW_FPU=y CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y # CONFIG_XENO_OPT_NATIVE_INTR is not set # CONFIG_XENO_SKIN_POSIX is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set CONFIG_XENO_SKIN_VXWORKS=m CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_OPT_RTDM_FILDES=128 CONFIG_XENO_SKIN_UVM=m # CONFIG_XENO_DRIVERS_16550A is not set CONFIG_XENO_DRIVERS_TIMERBENCH=m Any help would be appreciated. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Running vxworks testsuite under vxWorks
Hi
I am trying to run the vxworks testsuite on my PPC405 vxworks target.
Using the attached patched I manage to run a few of them. I have the
following questions:
Could a patch along these proposed changes be accepted? Where does it
need improvements/changes?
Some remarks about the patch:
- include/nucleus/queue.h needed for xntest. is #ifdef __XENO__ correct?
- made tests less verbose by removing xnarch_printf in xntest_assert.
I would prefer a silent method where each test only emits a summary
and a option to run generate verbose output in case of problems.
- static inline caused problem with Tornado 2.2.1 (gcc 2.96)
Some questions:
The tests do not clean up. Should I add a call to __xeno_user_exit in
xntest_finish and add cleanup code into each __xeno_user_exit?
Best regards
Niklaus Giger
begin 666 vx_test.patch
[EMAIL PROTECTED](EN8VQU94O;G5C;5UR]Q=65U92YH#0H]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]#0HM+2T@:6YC;'5D92]N=6-L975S+W%U975E+F@)*%)E=FES
M:6]N(#$P,#4I#0HK*RL@:6YC;'5D92]N=6-L975S+W%U975E+F@)*$%R8F5I
M='-K;W!I92D-D!`(TR,2PW(LR,2PQ,!`0`T*([EMAIL PROTECTED]
M3E5#3$554U]1545515](B`C95F:6YE(%]814Y/7TY50TQ%55-?455%545?
M2`H@BLC:[EMAIL PROTECTED]/7U\*(-I;F-L=61E(#QN=6-L975S+W1Y5S
[EMAIL PROTECTED]BLC96YD:68**PH@(VEN8VQU94@/YU8VQE=7,O8V]R92YH/@H@B`O
M*B!87-I8R!E;5M96YT(AO;1EB`J+PI);F1E#H@VEM+W-K:6YS+W9X
M=V]R:W,O=5S='-U:71E+WAN=5S=YC#0H]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]#0HM+2T@VEM+W-K:6YS+W9X=V]R:W,O=5S='-U:71E+WAN=5S=YC
M2A2979IVEO;B`Q,#`U*0T**RLK('-I;2]S:VENR]V'=OFMS+W1EW1S
M=6ET92]X;G1EW0N8PDH07)B96ETVMO[EMAIL PROTECTED]@*S$X+#(X
M($!`#0H@(H*(`J+PH@BLC:[EMAIL PROTECTED]/7U\*(-I;F-L=61E(#QN
M=6-L975S+WAE;F]M86DN:#X**R-E;'-EBMT7!E95F(EN=!A=]M:6-?
M9FQA9W-?=#L**W1Y5D968@:6YT('AN=EM97)?=#L**W1Y5D968@:6YT
M('AN;]C:U]T.PHK='EP961E9B!I;G0@W!L7W0[BLC95F:6YE(%A.05)#
M2%],3T-+7U5.3$]#2T5$(#`**R-I;F-L=61E(#QS=')I;FN:#X**R-I;F-L
M=61E(#QL;V=,:6(N:#X**PHK(V1E9FEN92!I;FQI;F4@BLC:6YC;'5D92`\
M;G5C;5UR]Q=65U92YH/@HK(W5N95F(EN;EN90HKBLC95F:6YE('AN
M]D7V9A=%L*%R9RD@;]G37-G*%R9RP@(#$L(#(L(#,L(#0L(#4L(#8I
M(`HK(V1E9FEN92!X;FUA;QO8R!M86QL;V,**R-D969I;F4@YFF5E(9R
M964**R-D969I;F4@YL;V-K7V=E=%]IG%S879E*%R9S$L(%R9S(IBLC
M95F:6YE('AN;]C:U]P=71?:7)QF5S=]R92AAFQ+!AFR*0HK(V1E
M9FEN92!X;G1HF5A9%]N86UE('1AVM.86UEBLC96YD:68*(-I;F-L=61E
M()X;G1EW0N:(*(-I;F-L=61E(#QS=1AFN:#X*(`I`0`M-#4L-B`K
M-C8L.2!`0`T*('-T871I8R!I;[EMAIL PROTECTED]5S=',[B`*(`HK(VEF;F1E9B!?7UA%
M3D]?7PHK(V1E9FEN92!I;FQI;F4**R-E;[EMAIL PROTECTED]@B!S=%T:6,@:6YL:6YE
M('AN:]L9[EMAIL PROTECTED]'1A:6QQ(AX;[EMAIL PROTECTED];]T*2![B`@
M(`@YH;VQD97)?=`J:]L95R(#T@7-L;W0M/FAE860N;%S=#L*0$`@
M+38P+#@[EMAIL PROTECTED]@0$`-B`@(`@F5T=7)N(@H(7-T[EMAIL
PROTECTED]'P@(7-TC(I
M(#\@W1R,2$]W1R,B`Z('-TF-MAS='(Q+!S='(R*2D[B!]B`*+7-T
M871I8R!V;VED(EN=5RG5P=%]T97-T(AV;VED(ID=6UM2D**W-T871I
M8R!I;FQI;[EMAIL PROTECTED]!I;G1EG)U'1?=5S=`H=F]I9`J9'5M;7DIB![
MB`@(!X;G!O9%]F871A;@B=5S=!I;G1EG)U'1E9!B2!W871C:1O
M9RY;B([EMAIL PROTECTED]`M-S(L.`K.38L,[EMAIL PROTECTED]B`@(`@W!L7W0@SL*
M(`H@(`@('AN;]C:U]G971?:7)Q[EMAIL PROTECTED]5S=%]L;V-K+!S*3L**R-I
M9F1E9B!?7UA%3D]?7PH@(`@('AN=EM97)?:6YI=@F=V%T8VAD;VL(EN
M=5RG5P=%]T97-T+`P*3L*(`@(!X;G1I;65R7W-T87)T*9W871C:1O
M9RP@YP;V1?;G,R=EC:W,H=5S=%]T:6UE;W5T(H@,3`P,#`P,%5,3DL
M(%A.7TE.1DE.251%*3L**R-E;[EMAIL PROTECTED]@B`@(`@:6YI='$H)FUAFMS7W$I
M.PH@(`@('1EW1S/3`[D!`(TQ.3`L-2`K,[EMAIL PROTECTED]B`*(`@(!X
M;F%R8VA?')I;G1F*(ESHE9[EMAIL PROTECTED]5S=!F:6YIVAE9#H@)[EMAIL
PROTECTED];'5R
M97,O(5D('1EW1S7XB+`H@(`@(`@(`@(`@(`@([EMAIL PROTECTED]@;EN
[EMAIL PROTECTED]5S=%]F86EL=7)E[EMAIL
PROTECTED]5S=',I.PHM(`@('AN]D7V9A=%L*).
M;W)[EMAIL PROTECTED]Y;B(I.PHK(`@('AN87)C:%]PFEN=8H(DYOFUA;!E
MET+EQN(BD[B!]DEN95X.B!S:6TOVMI;G,O=GAW;W)KR]T97-TW5I
M=4O=GAW;W)K[EMAIL PROTECTED]CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T-BTM
M+2!S:6TOVMI;G,O=GAW;W)KR]T97-TW5I=4O=GAW;W)KU]T97-T+F@)
M*%)E=FES:6]N(#$P,#4I#0HK*RL@VEM+W-K:6YS+W9X=V]R:W,O=5S='-U
M:71E+W9X=V]R:W-?=5S=YH2A!F)E:71S:V]P:64I#0I`0`M,C$L-R`K
M,C$L,[EMAIL PROTECTED]B`C:69N95F('=X=V]R:W-?=5S=%]HB`C95F:6YE('=X
M=V]R:W-?=5S=%]HB`**R-I9F1E9B!?7UA%3D]?7PH@(VEN8VQU94@/'9X
M=V]R:W,O=GAW;W)KRYH/@HK(V5LV4**R-I;F-L=61E(#QV'=O[EMAIL PROTECTED]
MBLC96YD:68*(-I;F-L=61E(#QX;G1EW0N:#X*(`H@(V1E9FEN92!415-4
M7T%34T525%]/2RAE'!R*2`@(`@(`@(`@(`@(`@(`@(`@(`@(`@
M(`@(`@([EMAIL PROTECTED]('-I;2]S:VENR]V'=OFMS+W1EW1S=6ET92]-
M86ME9FEL92YW:6X-CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T-BTM+2!S:6TO
MVMI;G,O=GAW;W)KR]T97-TW5I=4O36%K969I;4N=VEN2A2979IVEO
M;B`P*0T**RLK('-I;2]S:VENR]V'=OFMS+W1EW1S=6ET92]-86ME9FEL
M92YW:6X)*%)E=FES:6]N(#`I#0I`0`M,PP(LQ+#,Q($!`#0HK(R!.:6ML
M875S($=I9V5R+`R.XP-[EMAIL PROTECTED],@36%K969I;4N=VEN('1O(=E;F5R
M871E('1H92!V'=OFMS('1E[EMAIL PROTECTED],@=6YD97(@=VEN9]WR!A(=I
M=F5N('1AF=E=`T**R,-BLC(%EO=2!M=7-T(%D87!T(ET('1O('EO=7(@
M=%R9V5T(%N9!C86QL(9IG-T('-O;65T:EN9R!Y;W5R('1OE9AG,N
M8F%T(QI:V4-BLC($,Z7%!R;V
[Xenomai-core] [RFC] collecting xenomai statistics
Hi Following a suggestion from Philippe Gerum I propose to collect and prepare like this: a) Make it easy to collect information add -s/-c option to xeno-test, help text would look like -s send output of xeno-test to [EMAIL PROTECTED] -c name if -s, send also kernel config file to [EMAIL PROTECTED] (May be patch xeno-config to emit also the revision of the svn checkout?) b) Setup an e-mail account [EMAIL PROTECTED] c) Add a archiver which generates daily a gzipped tar file of all messages ever sent to [EMAIL PROTECTED] (e.g. of its mbox). Make it available somewhere on the internet. d) Write a converter the raw messages into more suitable representation, eg. a MySQL-DB, a spreadsheet format. Extract the raw message and kernel config and store the publicly accessible on the internet. The DB/spreadsheet will contain pointers (URLs) to the raw message/kernel config. e) Write viewers which present interesting statistics. E.g. X/HTML pages to present a ordered (by architecture, board, version, etc) view of the available results. I would like to advance like this: I am not interested in step a), as it is easy for me just to write a trivial script to sent the xeno-test output to any address. Also adding the revision of svn checkout is not very difficult. For point b+c) I am lacking the necessary rights, but it easy for me to setup a similar account for my tests here. But I would appreciate, if somebody of the core team would help me to get this work done. For point d+e) I will (after a week of vacation with my son) invest some work. But I would be very interested in knowing exactly which kind of information the core developers are interested in. How should it be presented? In tabular form? Graphs, which ones? And kind of feedback will be evaluated and integrated. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] BuildBot progress for sim, tqm860 with RTnet
Hi I was busy improving the buildbot setup and achieved the following: - added build slave for simulator - added a buildbot for a TQM860L with Denx PPC 2.4 kernel. Cannot yet build the RTnet code. - patched buildbot to show names for shell build steps instead of the commands - Hacked buildbot to improve the displayed names of the build step (e.g. configure_xenomai instead of configure 2. I will look at Philippe's idea about collecting xenomai statistics later, because it demands more time and effort to implement. The following details are probably only of interest for people interested in TQM860 and/or RTnet. My setup for the TQM860 was the following: - Got Dan Kegel crosstool 0.42 - Compiled/installed the demo-ppc860 (gcc-3.4.1-glibc-2.3.3) - Used linuxppc_2_4_devel-2006-04-06-1735.tar.bz whith a TQM860L_defconfig plus XENOMAI extensions - Got RTnet trunk via SVN Could the interested parties please comment, whether this is a good combination or whether they prefer something different? If you follow the logs you are able to see each step and configuration option (except building the crosstool). configure rtnet fails with the following message: checking for RT-extension... /home/buildslave/bin/linuxppc_2_4_devel-2006-04-06-1735 (Xenomai 2.0.x) checking for Xenomai version... configure: error: *** Unsupported Xenomai version 2.1.50 in /home/buildslave/bin/linuxppc_2_4_devel-2006-04-06-1735 Is the error correct? Or should I build only against Xenomai 2.0? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Proposal to use buildbot for Xenomai
Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka: Niklaus Giger wrote: Hi everybody .. This is a really great idea! Of course, I already have another test candidate in mind: RTnet 8). Specifically the PPC environment would be interesting, as our buildbot (sorry, Wolfgang G. ;) ) is typically very busy so that build regressions are sometimes only detected with delay on that platform. Is it also possible to explicitly trigger an update and rebuild? Yes of course. Just select a buildslave (e.g. ppc or hcu3 - http://ngiger.dyndns.org/buildbot/hcu3) and you may manually trigger it. I intentionally left this facility open for everybody to test it. But it would of course be possible to restrict it only to a few selected developers. If you want, I can help you to setup the master.cfg for a rtnet buildbot. But also for Xenomai I would see this as a very useful tool, e.g. for 2.4 build tests (I must confess I only test sporadically against this kernel). I will add one. Could you please e-mail me (privately if you want) a working config (ppc, no cross compiling if possible). Or do you want to add a build slave under your control? .. Is there no reset button you could control via a master station, e.g. by attaching some cheap electronic to a parallel or serial port? There is a reset button, but then you have it running and consuming electricity all the times. I just remember that DENX once had or still have a remote PPC test-lab running. I CC'ed Wolfgang, maybe he could comment on this if and how it could be used. I would be willing to setup a buildbot for the u-boot, too, as my board boots with a very outdated version of u-boot. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] VxWorks skin improvement
Am Donnerstag, 16. März 2006 14:53 schrieb Philippe Gerum:
I'm currently working on extending the VxWorks skin so that it is going to
be callable from user-space directly, without needing the UVM environment.
This will also make its functional extension easier in the future,
especially with respect to bsp-related services.
While I'm at it, I'd also like to polish a few corner cases, so that we
have the closest possible emulation of the original RTOS services.
Unfortunately, the VxWorks documentation is rather terse on some
behavioural aspects, and I have no VxWorks target at hand to test and check
them. Therefore, I definitely need help from people reading this list who
also happen to be VxWorks users, for providing the following missing bits
of information:
- How does taskName() behave when passed a null task id? Is it equivalent
to specifying taskIdSelf(), or does it lead to a NULL error return?
It behaves like taskName(taskIdSelf()). see vx_skin.c.
Output was
- vx_skin_test_1
myTaskName is 0xf40500 tShell
value = 31 = 0x1f
- How does msgQSend() behave when passed an invalid message priority, i.e.
neither MSG_PRI_NORMAL nor MSG_PRI_URGENT?
It doesn't care (see pMsgQue.cpp).
Output was
- test_init
task1 started
endTime 1834779057842028544
startTime 1832156649595338752
diff 2622408246689792 2622408246689 microSecs per run 26224082466
task1 nrQuestions 100 nrAnswers 100 nrSwitches 100
value = 0 = 0x0
- How does taskInit() behave when passed an invalid set of task options?
Are the invalid flags ignored, or does the routine return an error status?
All invalid bits arg ignored, no error returned. see vx_skin.c.
Output was:
- vx_skin_test_2
taskInit status is 0
taskOptionGet returns 0 is -1
value = 31 = 0x1f
If you happen to have a VxWorks target at hand regardless of the
architecture, and are willing to help improving the behavioural correctness
of the VxWorks skin, then your input will be most welcome.
Hope this help. Please feel free to ask for more tests.
What about a vxWorks test suite? I would like to contribute to it. (At least
as soon as I have a working Xenomai environment again.) And I would be much
more confident to recommend Xenomai if it had test suites for its various
skins. I hope to be able to make some contributions once I get approval to
put a few of our internal test routines available under a free license.
Best regards
Niklaus Giger
/*
* Copyright (C) 2005 Niklaus Giger [EMAIL PROTECTED].
*
* vxWorks is a registered trademark of Wind River Systems, Inc.
*
* 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 the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
* Hopefully this program lets you compare the relative performance of
* taskSwitches and message passing between an original vxWorks image and
* a xenomai based port.
*/
#ifdef XENOMAI
#include xeno_config.h
#include vxworks/vxworks.h
#include xenomai/timer.h
MODULE_LICENSE(GPL);
#else
#include vxWorks.h
#include stdio.h
#include msgQLib.h
#include taskLib.h
#include sysLib.h
#include arch/ppc/vxPpcLib.h
#define xnprintf printf
#define taskExit exit
#define RTIME UINT64
RTIME rt_timer_tsc();
RTIME rt_timer_tsc()
{
UINT32 low, high;
UINT64 res;
vxTimeBaseGet (low, high);
res = (UINT64) low + ((UINT64) high)32;
return res;
}
#endif
#define TASK_PRI115
#define STACK_SIZE 8192
MSG_Q_ID question_qid, answer_qid;
int producer_tid,
consumer_tid,
test_tid;
static int nrQuestions;
static int nrAnswers;
static int nrSwitches;
void reportState(const char *where)
{
xnprintf(%s nrQuestions %d nrAnswers %d nrSwitches %d\n,
where, nrQuestions, nrAnswers, nrSwitches);
}
#define NR_RUNS 100
void task1 (int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, int a8, int a9)
{
int msg;
int sz;
int j;
RTIME diff, startTime, endTime;
xnprintf(task1 started\n);
startTime = rt_timer_tsc();
for (j=0; jNR_RUNS; j++)
{
// taskDelay(sysClkRateGet()/2);
// startTime = rt_timer_tsc();
msg = nrQuestions;
msgQSend(question_qid,
(char *)msg,sizeof(msg),WAIT_FOREVER,MSG_PRI_NORMAL);
++nrQuestions;
if ( (sz = msgQReceive(answer_qid,
(char *)msg,sizeof(msg),WAIT_FOREVER)) == ERROR)
{
reportState(__func__
[Xenomai-core] Problem booting xenomai r662 on PowerPc
Hi After a couple of month I try to recompile xenomai and now neither my Powerbook nor my PPC405 build start up. I accepted all default values which showed up done in a make oldconfig (e.g. All I get is: ## Transferring control to Linux (at address ) ... id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem ocp: exit The xeno-part of my config is: CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_REGISTRY=y CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_SYS_HEAPSZ=128 # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set CONFIG_XENO_OPT_WATCHDOG=y CONFIG_XENO_OPT_TIMING_PERIODIC=y CONFIG_XENO_OPT_TIMING_PERIOD=0 CONFIG_XENO_OPT_TIMING_TIMERLAT=0 CONFIG_XENO_OPT_TIMING_SCHEDLAT=0 # CONFIG_XENO_OPT_SCALABLE_SCHED is not set CONFIG_XENO_OPT_TIMER_LIST=y # CONFIG_XENO_OPT_TIMER_HEAP is not set # CONFIG_XENO_OPT_SHIRQ_LEVEL is not set # CONFIG_XENO_OPT_SHIRQ_EDGE is not set # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y CONFIG_XENO_OPT_NATIVE_INTR=y # CONFIG_XENO_SKIN_POSIX is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_SKIN_UVM=y # CONFIG_XENO_DRIVERS_16550A is not set # CONFIG_XENO_DRIVERS_TIMERBENCH is not set DOes anybody have a clue? Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems generating vxworks/koan in two step: cc and link
Am Donnerstag, 19. Januar 2006 23:15 schrieb Gilles Chanteperdrix: Niklaus Giger wrote: ld -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative -e __xeno_skin_init /home/hcu/project/bb/3_1_x/work/xeno/koan.o Now I get the following error output ld: warning: cannot find entry symbol __xeno_skin_init; defaulting to 12a0 /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `TaskTest':koan.c: (.text+0xbc): undefined reference to `semTake' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `CreateTask':koan.c: (.text+0x124): undefined reference to `taskSpawn' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `usrClock':koan.c: (.text+0x1c8): undefined reference to `semGive' :koan.c:(.text+0x1f0): undefined reference to `tickAnnounce' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `koan_sysClkInit':koan.c:(.text+0x224): undefined reference to `semBCreate' :koan.c:(.text+0x23c): undefined reference to `sysClkConnect' :koan.c:(.text+0x240): undefined reference to `sysClkEnable' /home/hcu/project/bb/3_1_x/work/xeno/koan.o: In function `__xeno_user_exit':koan.c:(.text+0x2c0): undefined reference to `taskDelete' What is wrong with my split? What happens if you try : cc -u __xeno_skin_init -o koan -L/usr/xenomai/lib -luvm -lnucleus -lpthread -lvxworks -lnative /home/hcu/project/bb/3_1_x/work/xeno/koan.o -u seems to be a link-time option. Thanks for the tip. This fixes my problem. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] libvxworks not built
Hi I am at revision 464 of the xenomai trunk and wanted to build UVM for vxworks. The following libraries built fine: libuvm.a libpsos.a libuitron.a libvrtx.a libnucleus.a but the library I am most intrested in is missing? Does anybody has any clue? The XENO-parts of my .config are: CONFIG_XENOMAI=y CONFIG_XENO_OPT_NUCLEUS=y CONFIG_XENO_OPT_PERVASIVE=y CONFIG_XENO_OPT_PIPE=y CONFIG_XENO_OPT_PIPE_NRDEV=32 CONFIG_XENO_OPT_SYS_HEAPSZ=128 # CONFIG_XENO_OPT_ISHIELD is not set CONFIG_XENO_OPT_STATS=y # CONFIG_XENO_OPT_DEBUG is not set CONFIG_XENO_OPT_WATCHDOG=y # CONFIG_XENO_OPT_SCALABLE_SCHED is not set # CONFIG_XENO_HW_FPU is not set CONFIG_XENO_HW_PERIODIC_TIMER=y CONFIG_XENO_HW_TIMER_LATENCY=0 CONFIG_XENO_HW_SCHED_LATENCY=0 CONFIG_XENO_SKIN_NATIVE=y CONFIG_XENO_OPT_NATIVE_REGISTRY=y CONFIG_XENO_OPT_NATIVE_REGISTRY_NRSLOTS=512 CONFIG_XENO_OPT_NATIVE_PIPE=y CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096 CONFIG_XENO_OPT_NATIVE_SEM=y CONFIG_XENO_OPT_NATIVE_EVENT=y CONFIG_XENO_OPT_NATIVE_MUTEX=y CONFIG_XENO_OPT_NATIVE_COND=y CONFIG_XENO_OPT_NATIVE_QUEUE=y CONFIG_XENO_OPT_NATIVE_HEAP=y CONFIG_XENO_OPT_NATIVE_ALARM=y CONFIG_XENO_OPT_NATIVE_MPS=y CONFIG_XENO_OPT_NATIVE_INTR=y # CONFIG_XENO_SKIN_POSIX is not set # CONFIG_XENO_SKIN_PSOS is not set # CONFIG_XENO_SKIN_UITRON is not set # CONFIG_XENO_SKIN_VRTX is not set # CONFIG_XENO_SKIN_VXWORKS is not set # CONFIG_XENO_SKIN_RTAI is not set CONFIG_XENO_SKIN_RTDM=y CONFIG_XENO_SKIN_UVM=y # CONFIG_XENO_DRIVERS_16550A is not set # CONFIG_XENO_DRIVERS_TIMERBENCH is not set The I configured xenomai like this /mnt/data.ng/hcu/kernel/xenomai/configure --prefix=/usr --enable-uvm --build=powerpc --host=powerpc-405-linux-gnu CFLAGS=-g PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/mnt/data.ng/hcu/tools/gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu/bin and let it build with DESTDIR=/mnt/data.ng/hcu/rootfs -k install PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/mnt/data.ng/hcu/tools/gcc-3.4.4-glibc-2.3.5/powerpc-405-linux-gnu/bin install Best regards -- Niklaus Giger
Re: [Xenomai-core] Two patches for the documentation
Am Sonntag, 8. Januar 2006 11.53 schrieb Philippe Gerum: Niklaus Giger wrote: Hi ... Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + Why? xenoscope is not even able to open a window as apparently it goes somewhere into a recursion. I do not know however how to debug it. gdb /usr/xenomai/bin/xenoscope GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Starting program: /usr/xenomai/bin/xenoscope [Thread debugging using libthread_db enabled] [New Thread 805421056 (LWP 25333)] [New Thread 813860064 (LWP 25336)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805421056 (LWP 25333)] 0x0f80c2e8 in strchr () from /lib/tls/libc.so.6 (gdb) info stack #0 0x0f80c2e8 in strchr () from /lib/tls/libc.so.6 #1 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #2 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #3 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 #4 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 .. #63 0x0fef3958 in TkpGetFontFamilies () from /usr/lib/libtk8.4.so.0 Previous frame inner to this frame (corrupt stack?) Best regards -- Niklaus Giger
[Xenomai-core] Two patches for the documentation
Hi xeno.sim.patch contains some clarification on how to build the xenoscope. (GCC 3.4 worked for me on a x86 system, but with a lot of warnings, that fwritable is deprecated) xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. It worked for me without any problems for my board. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Best regards -- Niklaus Giger Index: README.INSTALL === --- README.INSTALL (Revision 392) +++ README.INSTALL (Arbeitskopie) @@ -150,20 +150,22 @@ needed, but if you do not use it, configure emit a warning, which may be confusing. +The easiest way to build a GNU cross-compiler might involve using Dan Kegel +crosstools found at http://kegel.com/crosstool. + Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC -architecture may be named powerpc-linux-gcc. +architecture may be named powerpc-405-linux-gnu-gcc. -When this prefix contains the name of the architecture, you may pass this prefix -to the --host option of configure. For example, if you type : -configure --host=powerpc-linux - -configure will automatically use powerpc-linux- as a prefix too all compilation +configure will automatically use powerpc-405-linux-gnu- as a prefix too all compilation tools names and deduce the architecture name. If configure is unable to deduce the architecture name from this prefix, you will have to manually pass the name of all compilation tools on configure command line. As in: -configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +It might be a good idea to put all the output into a differen build directory +as to build from from linux source several targets. For each target add +O=../build-target to each make invocation. +configure CROSS_COMPILE=powerpc-405-linux-gnu- For more details: http://sourceware.org/autobook/autobook/autobook_264.html#SEC264 @@ -204,16 +206,18 @@ 2.2 Building for the PowerPC architecture A typical cross-compilation setup, in order to build Xenomai for a -82xx-based system: +PowerPC-405-based system: $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ make xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make bzImage modules # then install as needed +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +# select the kernel and Xenomai options +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +# then install as needed $ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +$ $xenomai_root/configure CROSS_COMPILE=powerpc-405-linux-gnu- $ make install 2.3 Building for the IPF Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + +You will need the libelf, libpng, tcl8.x/tk8.x and tix81 _development packages_ in order to build the simulator and its companion tools. For instance, on Debian systems, you will need to install libelfg0-dev, libpng2-dev, tcl8.3-dev, tk8.3-dev and tix41-dev (any ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Problems cross-compiling for PPC405
Hi I just upgraded to revision 392 of xenomai and got the following error trying to compile the linux 2.6.14 kernel CC kernel/xenomai/nucleus/heap.o /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1017:1: pasting , and args does not give a valid preprocessing token /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c: In function `xnheap_mount': /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: `args' undeclared (first use in this function) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: (Each undeclared identifier is reported only once /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: for each function it appears in.) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: warning: too many arguments for format make[4]: *** [kernel/xenomai/nucleus/heap.o] Fehler 1 make[3]: *** [kernel/xenomai/nucleus] Fehler 2 make[2]: *** [kernel/xenomai] Fehler 2 make[1]: *** [kernel] Fehler 2 I am using GCC 3.4.4. Best regards -- Niklaus Giger ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Two patches for the documentation
Hi xeno.sim.patch contains some clarification on how to build the xenoscope. (GCC 3.4 worked for me on a x86 system, but with a lot of warnings, that fwritable is deprecated) xeno.patch is a shorter way how to cross-compile using the CROSS_COMPILE variable. It worked for me without any problems for my board. Also contains a hint to use O=../a-build-dir to compile the linux kernel. Best regards -- Niklaus Giger Index: README.INSTALL === --- README.INSTALL (Revision 392) +++ README.INSTALL (Arbeitskopie) @@ -150,20 +150,22 @@ needed, but if you do not use it, configure emit a warning, which may be confusing. +The easiest way to build a GNU cross-compiler might involve using Dan Kegel +crosstools found at http://kegel.com/crosstool. + Since cross-compiling requires specific tools, such tools are generally prefixed with the host architecture name; for example, a compiler for the power PC -architecture may be named powerpc-linux-gcc. +architecture may be named powerpc-405-linux-gnu-gcc. -When this prefix contains the name of the architecture, you may pass this prefix -to the --host option of configure. For example, if you type : -configure --host=powerpc-linux - -configure will automatically use powerpc-linux- as a prefix too all compilation +configure will automatically use powerpc-405-linux-gnu- as a prefix too all compilation tools names and deduce the architecture name. If configure is unable to deduce the architecture name from this prefix, you will have to manually pass the name of all compilation tools on configure command line. As in: -configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +It might be a good idea to put all the output into a differen build directory +as to build from from linux source several targets. For each target add +O=../build-target to each make invocation. +configure CROSS_COMPILE=powerpc-405-linux-gnu- For more details: http://sourceware.org/autobook/autobook/autobook_264.html#SEC264 @@ -204,16 +206,18 @@ 2.2 Building for the PowerPC architecture A typical cross-compilation setup, in order to build Xenomai for a -82xx-based system: +PowerPC-405-based system: $ $xenomai_root/scripts/prepare-kernel.sh --arch=powerpc \ --adeos=$xenomai_root/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-X.Y-ZZ.patch \ --linux=$linux_tree $ cd $linux_tree -$ make xconfig/gconfig/menuconfig # select the kernel and Xenomai options -$ make bzImage modules # then install as needed +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 xconfig/gconfig/menuconfig +# select the kernel and Xenomai options +$ make CROSS_COMPILE=powerpc-405-linux-gnu- O=../build-powerpc-405-2.6.14 bzImage modules +# then install as needed $ mkdir $build_root cd $build_root -$ $xenomai_root/configure --build=i686-pc-linux-gnu --host=powerpc-unknown-linux-gnu CC=ppc_82xx-gcc CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld +$ $xenomai_root/configure CROSS_COMPILE=powerpc-405-linux-gnu- $ make install 2.3 Building for the IPF Index: sim/README === --- sim/README (Revision 392) +++ sim/README (Arbeitskopie) @@ -28,7 +28,11 @@ Building the simulator == -You will need the libelf, libpng, tcl8.x/tk8.x and tix41 _development +The simulator does not build with GCC 4.0 or later. + +Currently it does not work on PowerPC systems. + +You will need the libelf, libpng, tcl8.x/tk8.x and tix81 _development packages_ in order to build the simulator and its companion tools. For instance, on Debian systems, you will need to install libelfg0-dev, libpng2-dev, tcl8.3-dev, tk8.3-dev and tix41-dev (any
[Xenomai-core] Problems cross-compiling for PPC405
Hi I just upgraded to revision 392 of xenomai and got the following error trying to compile the linux 2.6.14 kernel CC kernel/xenomai/nucleus/heap.o /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1017:1: pasting , and args does not give a valid preprocessing token /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c: In function `xnheap_mount': /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: `args' undeclared (first use in this function) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: (Each undeclared identifier is reported only once /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: error: for each function it appears in.) /mnt/data.ng/hcu/kernel/linux-2.6.14/kernel/xenomai/nucleus/heap.c:1015: warning: too many arguments for format make[4]: *** [kernel/xenomai/nucleus/heap.o] Fehler 1 make[3]: *** [kernel/xenomai/nucleus] Fehler 2 make[2]: *** [kernel/xenomai] Fehler 2 make[1]: *** [kernel] Fehler 2 I am using GCC 3.4.4. Best regards -- Niklaus Giger
