Hello Gilles,

Thanks for your advice, now I could continue the porting.

After implementing the tips and tricks number 1, I could see again the
boot messages. The trace is the following:

<6>Xenomai: hal/arm
started.                                                    
<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad Moon)
loaded.                   
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000000 
<1>pgd =
c0004000                                                               
<1>[00000000]
*pgd=00000000                                                     
Internal error: Oops: 5 [#1]
PREEMPT                                            
Modules linked
in:                                                              
CPU: 0    Not tainted  (2.6.29-rc8-davinci1
#23)                                
PC is at __ipipe_mach_get_tsc
+0x28/0x64                                         
LR is at xnarch_get_cpu_time
+0x10/0x18                                          
pc : [<c0037514>]    lr : [<c0077d24>]    psr:
20000013                         
sp : c1c17e68  ip : c1c17e78  fp :
c1c17e74                                     
r10: c03e0f90  r9 : 00000000  r8 :
c03b95e8                                     
r7 : c03b95e8  r6 : 00000001  r5 : 00000000  r4 :
97a862f8                      
r3 : 00000001  r2 : 00000000  r1 : 00000000  r0 :
97a862f8                      
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment
kernel             
Control: 0005317f  Table: c0004000  DAC:
00000017                               
Process swapper (pid: 1, stack limit =
0xc1c16268)                              
Stack: (0xc1c17e68 to
0xc1c18000)                                               
7e60:                   c1c17e84 c1c17e78 c0077d24 c00374fc c1c17eb4
c1c17e88   
7e80: c007a62c c0077d24 00000000 00000000 c1c17eb4 c1c17ea0 00000000
c03e0f90   
7ea0: 00000001 c03e0fc8 c1c17f34 c1c17eb8 c007a9d4 c007a584 00500080
00000000   
7ec0: 00000000 0000011c 736f685b 69742d74 5d72656d 019bfc00 c0014348
c035fc94   
7ee0: 00000000 00000000 544f4f52 c1c17e00 c02d5d14 c0043a5c c1c17f1c
c1c17f2c   
7f00: c0075664 c03e0f58 00000000 c03e2ccc c03e2cd8 c03e2ce4 c03e2cf0
c03e2cfc   
7f20: 00000000 c03e2c80 c1c17f5c c1c17f38 c0083710 c007a700 c0024acc
00000000   
7f40: 00000000 c0083658 00000001 00000000 c1c17fd4 c1c17f60 c002d464
c0083668   
7f60: 00000000 c035c631 c03dc160 000000db c1c33000 00000000 00000000
00000000   
7f80: c1c17fac c1c17f90 c0106158 c0105e38 00000000 c1c33180 c1c17fc4
c03dc160   
7fa0: c1c17fc4 c1c17fb0 c0070f60 c01060e8 c0024978 c0024acc 00000000
00000000   
7fc0: 00000000 00000000 c1c17ff4 c1c17fd8 c00085a4 c002d418 00000000
00000001   
7fe0: 00000000 00000000 00000000 c1c17ff8 c0046638 c000852c fffdf7ff
ffeffedf   
Backtrace:                                                                      
[<c00374ec>] (__ipipe_mach_get_tsc+0x0/0x64) from [<c0077d24>]
(xnarch_get_cpu_)
[<c0077d14>] (xnarch_get_cpu_time+0x0/0x18) from [<c007a62c>]
(xnpod_enable_tim)
[<c007a574>] (xnpod_enable_timesource+0x0/0x17c) from [<c007a9d4>]
(xnpod_init+)
 r7:c03e0fc8 r6:00000001 r5:c03e0f90
r4:00000000                                
[<c007a6f0>] (xnpod_init+0x0/0x35c) from [<c0083710>]
(__native_skin_init+0xb8/)
[<c0083658>] (__native_skin_init+0x0/0x278) from [<c002d464>]
(do_one_initcall+)
[<c002d408>] (do_one_initcall+0x0/0x1a4) from [<c00085a4>] (kernel_init
+0x88/0x)
 r8:00000000 r7:00000000 r6:00000000 r5:00000000
r4:c0024acc                    
[<c000851c>] (kernel_init+0x0/0xfc) from [<c0046638>] (do_exit
+0x0/0x7e8)       

r4:00000000                                                                    
Code: 03a02000 03a03000 0a00000a e5922000
(e892000c)                            
<4>---[ end trace
da227214a82491b7 ]---                                         
<0>Kernel panic - not syncing: Attempted to kill
init!                          

Looking at the code (and perform some analysis) I saw that the call that
is crashing the kernel is:

 __asm__("ldmia %1, %M0\n":
	    "=r"(result.full): "r"(local_tsc), "m"(*local_tsc));

And looking into the implementation of this function for other
platforms, I can see that it is the same instruction, without
difference.

In my implementation (port for the TI OMAP L-138 processor), I have
CONFIG_GENERIC_CLOCKEVENTS and CONFIG_GENERIC_TIME.

Could you please give me some advice about how to solve this issue?

Thank you for all your help.

Flavio

On Qui, 2009-12-31 at 16:41 +0100, Gilles Chanteperdrix wrote:

> Flavio de Castro Alves Filho wrote:
> > Hello,
> >  
> > I am currently working on the port of Xenomai for the TI OMAP L-138
> > processor (DaVinci platform). I didn't finish yet. As soon as I finish,
> > I will send the patch, and I intend to do so next week.
> >  
> > I followed the instructions from Xenomai's wiki page. Until now, I am
> > able to boot my ported kernel with the I-Pipe feature. When I build the
> > kernel with Xenomai feature, the kernel stops to boot.
> >  
> > I have some questions:
> >  
> > 1) How is the better way to debug the boot process? When my kernel stops
> > booting, after the message "Uncompressing .........." the boot halts. I
> > don't know what is going on and I don't know what to do in order to
> > follow the processes internally. Both debuggers (kernel and i-ipipe) are
> > enabled in the kernel configuration.
> 
> This is tips and tricks number 1:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting#Tips_and_tricks.
> 
> >  
> > 2) How tested the code must be done in order to send you a patch? Is
> > there any minimal set of tests that I should perform just before sending
> > you a patch for revision?
> 
> The validation tool I use is LTP. You can check that LTP returns the
> same results with a vanilla kernel, and with the Xenomai patched kernel
> when running LTP while a latency test is running. Unfortunately, to run
> ltp on low-end arms, I had to make a few local changes. Which means I am
> using an out-dated, patched version of LTP:
> http://sisyphus.hd.free.fr/~gilles/ltp-20081130-patched.tar.bz2
> 










Flavio de
Castro Alves
Filho
flavio.alves@domain.hid

Tel.: + 55 11
8494-5676
Embedded
Software
Services

www.phiinnovations.com











Escritórios::
São Paulo
Campinas