Re: Coldfire uClinux boot with u-boot

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
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev