Re: Coldfire uClinux boot with u-boot
Angelo Dureghello <[email protected]>
| Newsgroups | gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Steve,
don't know if it can be of any help, i am running successfully last
u-boot (git pull yesterday) on a mcf5307:
There was also an issue for the coldfire family (can't check if it was
on your version now), that all the functions related to UART's in u-boot
was executing from the flash (bad relocation to ram), and has been
found/fixed by me 15 days ago.
U-Boot 2013.01-rc3-00100-gdf3ad6c-dirty (Jan 16 2013 - 00:07:29)
CPU: Freescale Coldfire MCF5307 at 90 MHz
Board: AMCORE v.001(alpha)
DRAM: 16 MiB
Flash: 4 MiB
Hit any key to stop autoboot: 0
## Booting kernel from Legacy Image at ffc20000 ...
Image Name: Linux 2.6
Image Type: M68K Linux Kernel Image (uncompressed)
Data Size: 2468868 Bytes = 2.4 MiB
Load Address: 00020000
Entry Point: 00020000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Linux version 2.6.36.2 (angelo@angel3) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012
...
You also are oopsin'g on flash cfi detection. Are you using a custom
board or a commercial one ?
Regards,
Angelo
What u-boot version are you
uClinux/COLDFIRE(m5307)
COLDFIRE port done by Greg Ungerer, [email protected]
Modified for M5307 by Dave Miller, [email protected]
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line: root=/dev/mtdblock3 rootfstype=romfs init=/bin/init
video=amcorefb console=tty0 console=ttyS0,115200n8
PID hash table entries: 64 (order: -4, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 13632k/16384k RAM, (1709k kernel code, 195k data)
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
On 16/01/2013 06:53, 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):
> ----
> .
> .
> .
> 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
_______________________________________________
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