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, g...@snapgear.com
Modified for M5307 by Dave Miller, dmil...@intellistor.com
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
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
_______________________________________________
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
