Hi Steve,
On 01/16/2013 03:53 PM, Steve deRosier wrote:
Thanks to all that replied.
I'm still not 100% there, but finally got further. Greg, I should've
just coded up the UART output like you suggested, but I had already
started using a GPIO pin I could easily access and hooked it up to my
oscope. I did the same as you suggested, and popped it into head.S and
confirmed that u-boot was at least jumpping into the kernel. Then I
used code similar to:
*((volatile u8 *)0x4010000B) = (u8)(0x01);
mdelay(10);
*((volatile u8 *)0x4010000B) = (u8)(0x00);
and used that in the C startup code to trace through. Eventually I
figured out it was getting stuck on my RTC driver (on my
platform_driver_register() call), commented that out, and it got far
enough to put stuff out the console. Then it oopsed. This was durring
the second mtd map operation (I've got two flash chips on this thing):
Is the newer u-boot not setting up the SoC chip selects the same?
Might explain why its accessing devices that is giving you trouble.
Regards
Greg
----
.
.
.
Flash external probe(0xff400000,4194304,2): 400000 at ff400000
bad frame format: 00000000
Modules linked in:
PC: [<00133650>] cfi_qry_mode_on+0x8fe/0xf3e
SR: 2008 SP: 0183be58 a2: 0027a8f4
d0: 00000002 d1: ff400000 d2: 00000000 d3: 00000008
d4: 0000f0f0 d5: 00000002 a0: ff400000 a1: 0183bf6c
Process swapper (pid: 1, task=0183c000)
Frame format=4 eff addr=0024c92f pc=00000000
Stack from 0183be94:
0183bf32 00000001 00000002 00000001 0183bf32 0027a8f4 00000000
00131c36
00000000 0027a8f4 0183bf32 0024c92f 0000004c 0183bf32 00000001
00000002
00000001 0027a8f4 0027a664 0012b4cc 000f3acc 00131b2e 0013a9d2
0027a8f4
00000000 00000000 0183bf32 0024c92f 0000004c 68000000 0027a8f4
01f6523a
01f3cf70 00131ab0 0027a66c 0012b4cc 001d7a1c 00131b2e 0027a57c
00270000
00000000 00000002 00000001 00000000 00000000 00000000 00000000
00000000
Call Trace: [<00131c36>] cfi_probe_chip+0x3c/0xaee
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<000f3acc>] memset+0x0/0x7c
[<00131b2e>] do_map_probe+0x0/0xb6
[<0013a9d2>] mtd_do_chip_probe+0x8e/0x3d8
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<00131ab0>] get_mtd_chip_driver+0x0/0x7e
[<0012b4cc>] mtd_device_parse_register+0x0/0xc8
[<001d7a1c>] printk+0x0/0x18
[<00131b2e>] do_map_probe+0x0/0xb6
[<00131bf4>] cfi_probe+0x10/0x16
[<00131b52>] do_map_probe+0x24/0xb6
[<001d7a1c>] printk+0x0/0x18
[<0028f9b4>] m5235_mtd_init+0xb8/0x16e
[<0024c92f>] packet_seq_ops+0x59fc9/0x65b86
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<000200c8>] do_one_initcall+0x0/0x1d8
[<000201d8>] do_one_initcall+0x110/0x1d8
[<000200c8>] do_one_initcall+0x0/0x1d8
[<0028666a>] kernel_init+0x82/0x106
[<0028f8fc>] m5235_mtd_init+0x0/0x16e
[<002865e8>] kernel_init+0x0/0x106
[<00020a3a>] kernel_thread+0x2a/0x3c
Code: 4cd7 1cfc 4fef 0024 4e75 2041 d1c2 3084 <6000> f7f0 2204 2e05 e989
e78c e3af 8a87 2205 e9a9 8a81 6000 f832 2041 d1c3 1085
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill init!
----
So, I'm out of the woods so to speak, but not quite there yet. What I'm
totally flummoxed by is the fact that these drivers (indeed, the whole
kernel and the stuff in userspace) works just fine booted from the old
u-boot, but crap out from the new u-boot. Clearly I've done something
wrong here, but I'm not sure what or how. Based on behavior, I'm going
to be taking a very close look at the RAM allocations and stack space.
Though the stack pointer above is within my address space (32M, starting
at 0, so 0x00000000 to 0x02000000). Mayhaps I'm running over my stack,
hence a "bad frame format: 00000000"? Not 100% sure of that particular
message, got to look that up.
Anyway, this is as far as I got today, tomorrow I'm going to be
examining the oops in detail and figure out why/what's going on.
I can't immagine what the difference between the old u-boot and the new
one would be that could cause the kernel to work in former case but
totally crash in the latter. I'm open to suggestions.
Thanks,
- Steve
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
