[okl4-developer] oklinux on gta01
Geoffrey Lee
glee at ok-labs.com
Sat May 24 00:02:34 EST 2008
On Fri, May 23, 2008 at 08:34:57PM +0800, Tsai Tung-Chieh wrote:
> Dear Geoffrey,
>
> I edit qemu source, put it at a higher address (0x31000000 or 0x32000000).
> It fixed the original problem, but has a new problem :
Hi Tung-Chieh
Just to make sure, have you modified the okl4 and oklinux source
code in any way?
-gl
>
>
>
> OKL4 - (provider: Open Kernel Labs) built on May 22 2008 10:42:25
> using gcc version 3.4.4.
> device_enable_impl: done
> Linux version 2.6.23-arm (tctsai at tctsai-desktop) (gcc version 3.4.4)
> #19 Thu May 22 19:46:11 CST 2008
> Kernel memory ranges:
> 0: 0x00d00000-0x020ff000 (5119 pages)
> total 5119 pages
> end: 0
> Built 6 zonelists in Zone order. Total pages: 6096
> Kernel command line: igms_name=ramdisk root=/dev/igms0
> PID hash table entries: 128 (order: 7, 512 bytes)
> dummy_timer_init: initializing.
> console [l4con0] enabled
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 20204k/24600k available (1361k kernel code, 4372k reserved,
> 322k data, 76k init)
> Found timer server (tid: 0000c001, handle: 1)
> vtimer: init done (handle: 1, owner: 1c001, mask: 1)
> Requesting timer: 10000000
> Mount-cache hash table entries: 512
> ptrace_break_init unimplemented
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 1024 (order: 1, 8192 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> TCP reno registered
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: module loaded
> igms0: unknown partition table
> Iguana ramdisk driver initialized
> kobject_add failed for ttyS0 with -EEXIST, don't try to register
> things with the same name in the same directory.
> This architecture does not implement dump_stack()
> Iguana virtual serial driver v1.0
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> VFS: Mounted root (ext2 filesystem) readonly.
> vserial: init done (handle: 0, owner: 1c001, mask: 2)
> Kernel panic - not syncing: No init found. Try passing init= option to kernel.
>
>
>
> I think these two problem are not relative, since I have the same problem when
> running oklinux on gumstix(simulating by skyeye V1.2). Would you please give me
> some advice about this situation ? Thanks.
>
> --
> Best Regards,
> Tsai Tung-Chieh
>
>
> On Fri, May 23, 2008 at 12:11 AM, Geoffrey Lee <glee at ok-labs.com> wrote:
> > On Fri, May 23, 2008 at 12:00:47AM +0800, Tsai Tung-Chieh wrote:
> >
> > Hi Tung-Chieh
> >
> > It seems that your stack pointer register is corrupted, this
> > should not happen. Newer QEMU versions for the OpenMoko
> > loads the binary at 0x30100000, while the program gets decoded
> > starting at 0x30000000, which only leaves 1MB before the ELF decode
> > will run over the ELF binary.
> >
> > Can you try editing the QEMU source so that the binary
> > gets put at a higher address (say, 0x31000000), and see
> > if that fixes the problem for you?
> >
> > -gl
> >
> >
> >> Dear Geoffrey,
> >>
> >> Thanks your advice, I put it below :
> >>
> >> 00108978 <__sys_entry>:
> >> 108978: e52de004 str lr, [sp, #-4]!
> >> 10897c: e59f2018 ldr r2, [pc, #24] ; 10899c <.text+0x899c>
> >> 108980: e1a03000 mov r3, r0
> >> 108984: e590101c ldr r1, [r0, #28]
> >> 108988: e5823000 str r3, [r2]
> >> 10898c: e5900018 ldr r0, [r0, #24]
> >> 108990: eb000003 bl 1089a4 <__malloc_init>
> >> 108994: e49de004 ldr lr, [sp], #4
> >> 108998: eaffeb3f b 10369c <main>
> >> 10899c: 0011458c andeqs r4, r1, ip, lsl #11
> >>
> >> I also put the whole result on :
> >> http://tsaitungchieh.googlepages.com/iguana_server.objdump
> >>
> >>
> >> Best Regards,
> >> Tsai Tung-Chieh
> >>
> >> On Thu, May 22, 2008 at 11:13 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
> >> > On Thu, May 22, 2008 at 08:14:55PM +0800, Tsai Tung-Chieh wrote:
> >> >
> >> > Hi Tung-Chieh
> >> >
> >> >
> >> >> Dear Geoffrey,
> >> >>
> >> >> Sorry I'm not sure how to get the objdump and target function,
> >> >> would you please give me some advice about how to get these
> >> >> information. However, I put the memdump below, hope it's useful.
> >> >> Thanks.
> >> >
> >> > You can obtain a disassembly output with the following command:
> >> >
> >> > arm-linux-objdump -dp -S build_gta01/iguana_server/bin/ig_server
> >> >
> >> > This will give you assembly output instead of raw opcodes, as well
> >> > as which function that fault occurred in.
> >> >
> >> > -gl
> >> >
> >> >
> >> >>
> >> >> Best Regards,
> >> >> Tsai Tung-Chieh
> >> >>
> >> >> > memdump
> >> >> Dump address [0x1089]: 00108800
> >> >> 00108800 22822008 e3510010 21a01221 22822004 . ."..Q� !..!. ."
> >> >> 00108810 e3510004 82822003 908220a1 e1a00230 ..Q�. .. � ..0..
> >> >> 00108820 e1a0f00e e52de004 eb000034 e3a00000 .�.�.�-� 4..�...
> >> >> 00108830 e49df004 e2512001 3a00002c 11500001 .�.�. Q� ,..:..P.
> >> >> 00108840 03a00000 81110002 00000002 91a0f00e ........ .....
> >> >> 00108850 e3a02000 e3510201 31510000 31a01201 . .�..Q� ..Q1...1
> >> >> 00108860 32822004 3afffffa e3510102 31510000 . .2���: ..Q�..Q1
> >> >> 00108870 31a01081 32822001 3afffffa e2522003 ...1. .2 ���:. R
> >> >> 00108880 ba00000e e1500001 20400001 e15000a1 ...�..P� ..@ �.P
> >> >> 00108890 204000a1 e1500121 20400121 e15001a1 �.@ !.P� !.@ �.P
> >> >> 001088a0 204001a1 e3500001 e1a01221 a2522004 �.@ ..P� !..�. R�
> >> >> 001088b0 aafffff3 e3120003 13300000 0a00000a ����...� ..0.....
> >> >> 001088c0 e3720002 ba000006 0a000002 e1500001 ..r�...� ......P
> >> >> 001088d0 20400001 e1a010a1 e1500001 20400001 ..@ �..� ..P�..@
> >> >> 001088e0 e1a010a1 e1500001 20400001 e1a0f00e �..�..P� ..@ .
> >> >> 001088f0 e52de004 eb000001 e3a00000 e49df004 .�-�...� ...�.
> >> >> Continue? (Continue/Quit) [continue]: continue
> >> >> 00108900 e92d4002 ef900014 e3700ffa 28bd8002 . at -�...� �.p�..�(
> >> >> 00108910 e3a01008 ef900025 e8bd8002 e52da004 ...�%..� ..��..-
> >> >> 00108920 e59fa044 e3500801 e08fa00a 2a00000a D..�..P� ...�...*
> >> >> 00108930 e35000ff 83a0c008 93a0c000 e59f302c �.P�.... ....,0.
> >> >> 00108940 e79a2003 e1a01c30 e7d20001 e080000c . .�0..� ...�...
> >> >> 00108950 e2600020 e8bd0400 e1a0f00e e3500401 .`�..�� .�.�..P
> >> >> 00108960 23a0c018 33a0c010 eafffff3 0000bb34 ...#...3 ����4�..
> >> >> 00108970 0000000c eafffffe e52de004 e59f2018 ....���� .�-�. .
> >> >> 00108980 e1a03000 e590101c e5823000 e5900018 .0.�...� .0.�...
> >> >> 00108990 eb000003 e49de004 eaffeb3f 0011458c ...�.�.� ?���.E..
> >> >> 001089a0 eaffeb3d e0601001 e2811001 e1a011a1 =���..`� ...��..
> >> >> 001089b0 e5801004 e2800008 ea000058 e92d4070 ...�...� X..�p at -
> >> >> 001089c0 e24dd008 e1a06000 eb000792 e3a04001 ..M�.`.� ...�. at .
> >> >> 001089d0 e1a05014 eb00078f e1a04014 e08651a5 .P.�...� . at .��Q.
> >> >> 001089e0 e1a041a4 e2455001 e2644000 e0056004 �A.�.PE� . at d�.`.
> >> >> 001089f0 e1a00186 e28d1004 e1a0200d ebffed47 ...�...� . .�G��
> >> >> Continue? (Continue/Quit) [continue]: continue
> >> >> 00108a00 e3500000 0a000007 e59d3000 e59d0004 ..P�.... .0.�...
> >> >> 00108a10 e1a031a3 e5803004 e2800008 eb00003f �1.�.0.� ...�?..
> >> >> 00108a20 e59f3008 e5930000 e28dd008 e8bd8070 .0.�...� ...�p.�
> >> >> 00108a30 001144d8 e52de004 e1a0e000 e59f0020 .D...�-� .�.� ..
> >> >> 00108a40 e24dd008 e1a0c002 e5900000 e1a0200e ..M�...� ...�. .
> >> >> 00108a50 e88d000a e59f100c e1a0300c eb000027 ...�...� .0.�'..
> >> >> 00108a60 ebffffc3 0011438c 0010c14c e92d4ff0 .���.C.. L...�O-
> >> >> 00108a70 e59db024 e3a07000 e1a05002 e1570002 $�.�.p.� .P.�..W
> >> >> 00108a80 e1a09000 e1a0a001 e1a08003 2a00000f ...�...� ...�...*
> >> >> 00108a90 e0873005 e1a040a3 e026a498 e1a00009 .0.��@.� .�&�...
> >> >> 00108aa0 e1a01006 e1a0e00f e1a0f00b e3500000 ...�.�.� .�.�..P
> >> >> 00108ab0 b1a05004 ba000003 1a000001 e1a00006 .P.�...� .......
> >> >> 00108ac0 e8bd8ff0 e2847001 e1570005 eaffffee �.��.p.� ..W����
> >> >> 00108ad0 e3a00000 e8bd8ff0 e92d4010 e0040091 ...��.�� . at -�...
> >> >> 00108ae0 e1a00004 eb00003f e1a02004 e2504000 ...�?..� . .�. at P
> >> >> 00108af0 e3a01000 1b000074 e1a00004 e8bd8010 ...�t... ...�..�
> >> >> Continue? (Continue/Quit) [continue]:
> >> >>
> >> >> On Thu, May 22, 2008 at 7:02 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
> >> >> > On Thu, May 22, 2008 at 04:48:40PM +0800, Tsai Tung-Chieh wrote:
> >> >> >
> >> >> > Hi Tung-Chieh
> >> >> >
> >> >> > Can you please give us a objdump disassembly output of the instructions
> >> >> > around the faulting instruction pointer at 0x108978, as well as
> >> >> > what function this fault is in?
> >> >> >
> >> >> > -gl
> >> >> >
> >> >
> >> > --
> >> >
> >> >
> >
> > --
> >
> >
--
More information about the Developer
mailing list