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
[email protected]
Tel.: + 55 11
8494-5676
Embedded
Software
Services
www.phiinnovations.com
Escritórios::
São Paulo
Campinas
<<attachment: logo.gif>>
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
