Quoth chris brooke:
> Thanks for your previous help. I've now got my system to boot up
> partially before I get a "bad frame format: 00000000".
>
> I'm using the 2.6.19 kernel on a custom 5272 board. I do not have
> RAM at location 0.
>
> What is the significance of this message?
> What is it trying to tell me (bus trap error etc. or what)?
> Does the 00000000 have any significance (eg the address it is trying
> to access)?
> How do I go about isolating/fixing this problem?
I'm not sure exactly what it means (it's got something to do with the
stack, I think), but it almost always seems to mean that something has
just tried to access through a null pointer.
The first thing to check is to make sure you've set the base of RAM
correctly (most of the stuff is in head.S and can usually be customised
via the kernel config, but there's also one in
linux-2.6.x/include/asm/page_offset.h, and there might be a couple more
I've forgotten about).
> bad frame format: 00000000
> PC: [<01b2d6ea>]
> SR: 2014 SP: 01c62f40 a2: 01e2ec00
> d0: ffffffff d1: 0000006b d2: 00000000 d3: 01a42396
> d4: 00000000 d5: 00000004 a0: 01b091e2 a1: 01c435e0
> Process swapper (pid: 1, stackpage=01c62bf0)
> Stack from 01c62f40:
> 0000006b 00000000 01a42396 00000000 00000004 01b091e2
> 01c435e0 01e2ec00 ffffffff ffffffff 00000000 4c082014
> 01b2d6ea 00000000 00000b00 00000000 00000004 01e2ec00
> 01b301c8 01a27e74 01c62000 01c62fd0 01b2daec 01e2ec00
> 00000000 00000000 01b301c8 01a27e74 01c62000 01a20142
> 01b22fc8 00000b00 01076756 01f7fffc 0108ff94 01b22ff8
> 00000001 00000b00 00000000 00000004 00000000 01a200be 00000b00
> 00000000 00000078 00000000 01a20c56 00000000
What you should do with this is to load up System.map and track down
which function the PC is in. You can then use
m68k-{elf,uclinux}-objdump to dump the assembly for that function from
the compiled kernel and work out exactly which instruction it was on,
which should give you some clues. Failing that, look through the stack
for other addresses that look like code or data symbols and try to work
out what it was up to.
Or alternatively if you have a BDM available then you can use that to
debug the kernel directly.
_______________________________________________
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
