Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

2006-06-11 Thread Niklaus Giger 
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] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

2006-05-22 Thread Niklaus Giger 
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

2006-05-22 Thread Philippe Gerum 

Niklaus Giger wrote:

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.


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,

--

Philippe.


___
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

2006-05-22 Thread Niklaus Giger 
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

2006-05-22 Thread 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? 
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;
 }

--

Philippe.

___
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

2006-05-22 Thread Niklaus Giger 
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] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

2006-05-22 Thread Philippe Gerum 

Niklaus Giger wrote:

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.




Ok, relatively good news. Now I need to find why starting the timer 
early breaks the system...



Thanks a lot for your help.

Best regards




--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core