[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