[U-Boot] Hanging in kmalloc of nand_scan_tail() function
Scott Wood
scottwood at freescale.com
Mon Nov 15 18:42:22 CET 2010
On Sat, 13 Nov 2010 11:43:23 +0800
terry <gliumailenator at gmail.com> wrote:
> and the following is part of malloc after disassembled, you can find the
> detailed content of malloc in the attachment malloc.dis file(I'm not
> sure which part could be useful,so I attached whole malloc).
>
> 61 33f8fb84: 9a000004 bls 33f8fb9c <malloc+0xf8>
> 62 33f8fb88: e59f352c ldr r3, [pc, #1324] ; 33f900bc <malloc
> +0x618>
> 63 33f8fb8c: e1520003 cmp r2, r3
> 64 33f8fb90: 91a0392a lsrls r3, sl, #18
> 65 33f8fb94: 83a0207e movhi r2, #126 ; 0x7e
> 66 33f8fb98: 9283207c addls r2, r3, #124 ; 0x7c
> 67 33f8fb9c: e59f3514 ldr r3, [pc, #1300] ; 33f900b8 <malloc
> +0x614>
> 68 33f8fba0: e0834182 add r4, r3, r2, lsl #3
> 69 33f8fba4: e594000c ldr r0, [r4, #12]
> 70 33f8fba8: ea000012 b 33f8fbf8 <malloc+0x154>
> 71 33f8fbac: e5903004 ldr r3, [r0, #4]
> 72 33f8fbb0: e3c33003 bic r3, r3, #3 ; 0x3 //it seems that
> exception occurs here
> 73 33f8fbb4: e06a1003 rsb r1, sl, r3
This is the instruction that it faulted on -- but it's not a memory
access instruction. Could it be an asynchronous data abort (more like
a machine check)? It's been a while since I've done ARM stuff.
/me googles "ARM exceptions"
Hmm, data aborts record PC+8 rather than PC? Who comes up with this
stuff? :-P
Could you look up the line number information for 0x33f8fbac?
From the full-function disasm, I'd expect ip to equal r0 at this point
-- but they don't in the dump.
-scott
More information about the U-Boot
mailing list