[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[J.Hwan.Kim]

Hi, everyone

I'm using U-boot 2009-03.
U-boot hangs in nand_init() function.
I found the routine kmalloc in nand_scan_tail() cause U-boot reset.


int nand_scan_tail(struct mtd_info *mtd)
{
    int i;
    struct nand_chip *chip = mtd->priv;

    if (!(chip->options & NAND_OWN_BUFFERS)) {
        chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL);   
    }

    if (!chip->buffers)
        return -ENOMEM;
              ........


U-boot displays message as follows :

NAND:  data abort
pc : [<31f902b4>]\0x09   lr : [<31fa084c>]
sp : 31f5bee0  ip : 00000076\0x09 fp : 00000000
r10: 00001188  r9 : 00020000\0x09 r8 : 31f5bfdc
r7 : 00000001  r6 : 00000000\0x09 r5 : 31fa42b8  r4 : 31fa4364
r3 : 31fa052c  r2 : 00000064\0x09 r1 : 00000063  r0 : ffffffff
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


Where the malloc function is defined?
Why the kmalloc() hangs the u-boot?
Is there any configuation definition needed?

Thanks in advance.

Regards,
J.Hwan Kim

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Scott Wood]

On Fri, Sep 18, 2009 at 01:17:48PM +0900, J.Hwan.Kim wrote:
> Hi, everyone
> 
> I'm using U-boot 2009-03.
> U-boot hangs in nand_init() function.
> I found the routine kmalloc in nand_scan_tail() cause U-boot reset.
> 
> 
> int nand_scan_tail(struct mtd_info *mtd)
> {
>     int i;
>     struct nand_chip *chip = mtd->priv;
> 
>     if (!(chip->options & NAND_OWN_BUFFERS)) {
>         chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL);   
>     }
> 
>     if (!chip->buffers)
>         return -ENOMEM;
>               ........
> 
> 
> U-boot displays message as follows :
> 
> NAND:  data abort
> pc : [<31f902b4>]\0x09   lr : [<31fa084c>]
> sp : 31f5bee0  ip : 00000076\0x09 fp : 00000000
> r10: 00001188  r9 : 00020000\0x09 r8 : 31f5bfdc
> r7 : 00000001  r6 : 00000000\0x09 r5 : 31fa42b8  r4 : 31fa4364
> r3 : 31fa052c  r2 : 00000064\0x09 r1 : 00000063  r0 : ffffffff
> Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> 
> Where the malloc function is defined?
> Why the kmalloc() hangs the u-boot?
> Is there any configuation definition needed?

What specific source lines do 0x31f902b4 and 0x31fa0840 correspond to,
and can you disassemble the former?

-Scott

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Scott Wood]

On Sat, 13 Nov 2010 11:43:23 +0800
terry <gliumailenator@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

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Kumar Gala]

On Nov 14, 2010, at 7:18 AM, terry wrote:

> ? 2010-11-13?? 10:24 -0600?Kumar Gala???
>> On Nov 12, 2010, at 9:43 PM, terry wrote:
>> 
>>>>> 
>>>>> by the way,I cann't find the prototype of malloc in the whole project,it
>>>>> seems that it is encapsulated in some libs.
>>>> 
>>>> It's in common/malloc.c.  There's weird preprocessor renaming going on,
>>>> so it's called mALLOc in that file, but it shows up as malloc in the
>>>> binary.
>>> Thanks very much for your carefully instruction.
>>> 
>>>> 
>>>> -Scott
>>>> 
>>> 
>> 
>> I haven't been following this thread, but just debugging a malloc/nand "corruption" issue myself.  I'm going to start a new thread on the subject since its more related to malloc.  However can you try the following and see what happens:
>> 
>> diff --git a/include/malloc.h b/include/malloc.h
> 
> I'm sorry, but I cann't understand you clearly. what do you mean by
> writting this? compare two different versions? if so, which two version?
> 
>> index 3e145ad..19f0f0b 100644
>> --- a/include/malloc.h
>> +++ b/include/malloc.h
>> @@ -850,7 +850,7 @@ extern Void_t*     sbrk();
>> #endif
>> 
>> #ifndef MORECORE_CLEARS
>> -#define MORECORE_CLEARS 1
>> +#define MORECORE_CLEARS 0
>> #endif
>> 
>> #endif /* INTERNAL_LINUX_C_LIB */
> I read the malloc.h file in u-boot-2010.09. it's content like below:
> #ifdef INTERNAL_LINUX_C_LIB
> 819 
> 820 #if __STD_C
> 821 
> 822 Void_t * __default_morecore_init (ptrdiff_t);
> 823 Void_t *(*__morecore)(ptrdiff_t) = __default_morecore_init;
> 824 
> 825 #else
> 826 
> 827 Void_t * __default_morecore_init ();
> 828 Void_t *(*__morecore)() = __default_morecore_init;
> 829 
> 830 #endif /* __STD_C */
> 831 
> 832 #define MORECORE (*__morecore)
> 833 #define MORECORE_FAILURE 0
> 834 #define MORECORE_CLEARS 1
> 
> #else /* INTERNAL_LINUX_C_LIB */
> 837 
> 838 #if __STD_C
> 839 extern Void_t*     sbrk(ptrdiff_t);
> 840 #else
> 841 extern Void_t*     sbrk();
> 842 #endif
> 843 
> 844 #ifndef MORECORE
> 845 #define MORECORE sbrk
> 846 #endif
> 847 
> 848 #ifndef MORECORE_FAILURE
> 849 #define MORECORE_FAILURE -1
> 850 #endif
> 851 
> 852 #ifndef MORECORE_CLEARS
> 853 #define MORECORE_CLEARS 1
> 854 #endif
> 855 
> 856 #endif /* INTERNAL_LINUX_C_LIB */
> Do you mean that I should change MORECORE_CLEARS from 1 to 0?

Yes, I was asking you to modify include/malloc.h to change MORECORE_CLEARS from 1 to 0 and see if that helps your issue.  You need to modify the one on lines 853.

- k

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[terry]

? 2010-11-13?? 10:24 -0600?Kumar Gala???
> On Nov 12, 2010, at 9:43 PM, terry wrote:
> 
> >>> 
> >>> by the way,I cann't find the prototype of malloc in the whole project,it
> >>> seems that it is encapsulated in some libs.
> >> 
> >> It's in common/malloc.c.  There's weird preprocessor renaming going on,
> >> so it's called mALLOc in that file, but it shows up as malloc in the
> >> binary.
> > Thanks very much for your carefully instruction.
> > 
> >> 
> >> -Scott
> >> 
> > 
> 
> I haven't been following this thread, but just debugging a malloc/nand "corruption" issue myself.  I'm going to start a new thread on the subject since its more related to malloc.  However can you try the following and see what happens:
> 
> diff --git a/include/malloc.h b/include/malloc.h

I'm sorry, but I cann't understand you clearly. what do you mean by
writting this? compare two different versions? if so, which two version?

> index 3e145ad..19f0f0b 100644
> --- a/include/malloc.h
> +++ b/include/malloc.h
> @@ -850,7 +850,7 @@ extern Void_t*     sbrk();
>  #endif
>  
>  #ifndef MORECORE_CLEARS
> -#define MORECORE_CLEARS 1
> +#define MORECORE_CLEARS 0
>  #endif
>  
>  #endif /* INTERNAL_LINUX_C_LIB */
I read the malloc.h file in u-boot-2010.09. it's content like below:
#ifdef INTERNAL_LINUX_C_LIB
819 
820 #if __STD_C
821 
822 Void_t * __default_morecore_init (ptrdiff_t);
823 Void_t *(*__morecore)(ptrdiff_t) = __default_morecore_init;
824 
825 #else
826 
827 Void_t * __default_morecore_init ();
828 Void_t *(*__morecore)() = __default_morecore_init;
829 
830 #endif /* __STD_C */
831 
832 #define MORECORE (*__morecore)
833 #define MORECORE_FAILURE 0
834 #define MORECORE_CLEARS 1

#else /* INTERNAL_LINUX_C_LIB */
837 
838 #if __STD_C
839 extern Void_t*     sbrk(ptrdiff_t);
840 #else
841 extern Void_t*     sbrk();
842 #endif
843 
844 #ifndef MORECORE
845 #define MORECORE sbrk
846 #endif
847 
848 #ifndef MORECORE_FAILURE
849 #define MORECORE_FAILURE -1
850 #endif
851 
852 #ifndef MORECORE_CLEARS
853 #define MORECORE_CLEARS 1
854 #endif
855 
856 #endif /* INTERNAL_LINUX_C_LIB */
Do you mean that I should change MORECORE_CLEARS from 1 to 0?
-- 
Best regards,
terry

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Kumar Gala]

On Nov 12, 2010, at 9:43 PM, terry wrote:

>>> 
>>> by the way,I cann't find the prototype of malloc in the whole project,it
>>> seems that it is encapsulated in some libs.
>> 
>> It's in common/malloc.c.  There's weird preprocessor renaming going on,
>> so it's called mALLOc in that file, but it shows up as malloc in the
>> binary.
> Thanks very much for your carefully instruction.
> 
>> 
>> -Scott
>> 
> 

I haven't been following this thread, but just debugging a malloc/nand "corruption" issue myself.  I'm going to start a new thread on the subject since its more related to malloc.  However can you try the following and see what happens:

diff --git a/include/malloc.h b/include/malloc.h
index 3e145ad..19f0f0b 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -850,7 +850,7 @@ extern Void_t*     sbrk();
 #endif
 
 #ifndef MORECORE_CLEARS
-#define MORECORE_CLEARS 1
+#define MORECORE_CLEARS 0
 #endif
 
 #endif /* INTERNAL_LINUX_C_LIB */

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[terry]

? 2010-11-12?? 11:19 -0600?Scott Wood???
> On Fri, 12 Nov 2010 20:45:18 +0800
> terry <gliumailenator@gmail.com> wrote:
> 
> > Dear Scott,
> > 	I have disassemble the nand_base.o file,because i know the problem
> > happened here.
> 
> Why not disassemble the whole u-boot?
> 
> Then you'll get malloc as well, and the addresses will be closer to
> what shows up in the dump.
> 
> > Do you think it's useful for your analysis?
> 
> Can you disassemble malloc?  That's where it actually crashed.

following is part of result that I disassemble the whole u-boot.

33f85f50 <nand_scan_tail>:
  6487 33f85f50:   e92d4070    push    {r4, r5, r6, lr}
  6488 33f85f54:   e590509c    ldr r5, [r0, #156]
  6489 33f85f58:   e595304c    ldr r3, [r5, #76]
  6490 33f85f5c:   e3130701    tst r3, #262144 ; 0x40000
  6491 33f85f60:   e1a06000    mov r6, r0
  6492 33f85f64:   1a000002    bne 33f85f74 <nand_scan_tail+0x24>
  6493 33f85f68:   e59f04ec    ldr r0, [pc, #1260] ; 33f8645c
<nand_scan_tail+0x       50c>// value seen below.
  6494 33f85f6c:   eb0026cc    bl  33f8faa4 <malloc>
  6495 33f85f70:   e58500dc    str r0, [r5, #220]
  6496 33f85f74:   e59510dc    ldr r1, [r5, #220]
  6497 33f85f78:   e3510000    cmp r1, #0  ; 0x0
  6498 33f85f7c:   03e0000b    mvneq   r0, #11 ; 0xb
  6499 33f85f80:   08bd8070    popeq   {r4, r5, r6, pc}

value of pc + 1260:
33f8645c:   0000128e    .word   0x0000128e

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
 74 33f8fbb8:   e351000f    cmp r1, #15 ; 0xf
 75 33f8fbbc:   c2422001    subgt   r2, r2, #1  ; 0x1
 76 33f8fbc0:   ca00000e    bgt 33f8fc00 <malloc+0x15c>
 77 33f8fbc4:   e3510000    cmp r1, #0  ; 0x0
 78 33f8fbc8:   e590c00c    ldr ip, [r0, #12]
 79 33f8fbcc:   ba000008    blt 33f8fbf4 <malloc+0x150>
 80 33f8fbd0:   e0803003    add r3, r0, r3
 81 33f8fbd4:   e5932004    ldr r2, [r3, #4]
 82 33f8fbd8:   e5901008    ldr r1, [r0, #8]

> > 00001a4c <nand_scan_tail>:
> >  1749     1a4c:   e92d4070    push    {r4, r5, r6, lr}
> >  1750     1a50:   e590509c    ldr r5, [r0, #156]
> >  1751     1a54:   e595304c    ldr r3, [r5, #76]
> >  1752     1a58:   e3130701    tst r3, #262144 ; 0x40000
> >  1753     1a5c:   e1a06000    mov r6, r0
> >  1754     1a60:   1a000002    bne 1a70 <nand_scan_tail+0x24>
> >  1755     1a64:   e59f04ec    ldr r0, [pc, #1260] ; 1f58 <nand_scan_tail
> > +0x50c>
> >  1756     1a68:   ebfffffe    bl  0 <malloc>
> 
> What's the value at PC+1260?
It's "1f58:   0000128e    .word   0x0000128e"
> 
> > by the way,I cann't find the prototype of malloc in the whole project,it
> > seems that it is encapsulated in some libs.
> 
> It's in common/malloc.c.  There's weird preprocessor renaming going on,
> so it's called mALLOc in that file, but it shows up as malloc in the
> binary.
Thanks very much for your carefully instruction.

> 
> -Scott
> 

-- 
Best regards,
terry
-------------- next part --------------
33f8faa0 <cfree>:
33f8faa0:	eaffff6f 	b	33f8f864 <free>

33f8faa4 <malloc>:
33f8faa4:	e59f2608 	ldr	r2, [pc, #1544]	; 33f900b4 <malloc+0x610>
33f8faa8:	e5923004 	ldr	r3, [r2, #4]
33f8faac:	e3530000 	cmp	r3, #0	; 0x0
33f8fab0:	e92d47f0 	push	{r4, r5, r6, r7, r8, r9, sl, lr}
33f8fab4:	1a000002 	bne	33f8fac4 <malloc+0x20>
33f8fab8:	e5923008 	ldr	r3, [r2, #8]
33f8fabc:	e3530000 	cmp	r3, #0	; 0x0
33f8fac0:	0a000178 	beq	33f900a8 <malloc+0x604>
33f8fac4:	e3500000 	cmp	r0, #0	; 0x0
33f8fac8:	ba000176 	blt	33f900a8 <malloc+0x604>
33f8facc:	e280000b 	add	r0, r0, #11	; 0xb
33f8fad0:	e3500016 	cmp	r0, #22	; 0x16
33f8fad4:	d3a0a010 	movle	sl, #16	; 0x10
33f8fad8:	da000002 	ble	33f8fae8 <malloc+0x44>
33f8fadc:	e3c0a007 	bic	sl, r0, #7	; 0x7
33f8fae0:	e35a0f7e 	cmp	sl, #504	; 0x1f8
33f8fae4:	2a000015 	bcs	33f8fb40 <malloc+0x9c>
33f8fae8:	e59f35c8 	ldr	r3, [pc, #1480]	; 33f900b8 <malloc+0x614>
33f8faec:	e1a021aa 	lsr	r2, sl, #3
33f8faf0:	e0833182 	add	r3, r3, r2, lsl #3
33f8faf4:	e593c00c 	ldr	ip, [r3, #12]
33f8faf8:	e15c0003 	cmp	ip, r3
33f8fafc:	1a000004 	bne	33f8fb14 <malloc+0x70>
33f8fb00:	e28c3008 	add	r3, ip, #8	; 0x8
33f8fb04:	e593c00c 	ldr	ip, [r3, #12]
33f8fb08:	e15c0003 	cmp	ip, r3
33f8fb0c:	02827002 	addeq	r7, r2, #2	; 0x2
33f8fb10:	0a00003b 	beq	33f8fc04 <malloc+0x160>
33f8fb14:	e59c3004 	ldr	r3, [ip, #4]
33f8fb18:	e3c33003 	bic	r3, r3, #3	; 0x3
33f8fb1c:	e08c3003 	add	r3, ip, r3
33f8fb20:	e5932004 	ldr	r2, [r3, #4]
33f8fb24:	e59c000c 	ldr	r0, [ip, #12]
33f8fb28:	e59c1008 	ldr	r1, [ip, #8]
33f8fb2c:	e3822001 	orr	r2, r2, #1	; 0x1
33f8fb30:	e5801008 	str	r1, [r0, #8]
33f8fb34:	e5832004 	str	r2, [r3, #4]
33f8fb38:	e581000c 	str	r0, [r1, #12]
33f8fb3c:	ea00004c 	b	33f8fc74 <malloc+0x1d0>
33f8fb40:	e1b024aa 	lsrs	r2, sl, #9
33f8fb44:	01a021aa 	lsreq	r2, sl, #3
33f8fb48:	0a000013 	beq	33f8fb9c <malloc+0xf8>
33f8fb4c:	e3520004 	cmp	r2, #4	; 0x4
33f8fb50:	91a0332a 	lsrls	r3, sl, #6
33f8fb54:	92832038 	addls	r2, r3, #56	; 0x38
33f8fb58:	9a00000f 	bls	33f8fb9c <malloc+0xf8>
33f8fb5c:	e3520014 	cmp	r2, #20	; 0x14
33f8fb60:	9282205b 	addls	r2, r2, #91	; 0x5b
33f8fb64:	9a00000c 	bls	33f8fb9c <malloc+0xf8>
33f8fb68:	e3520054 	cmp	r2, #84	; 0x54
33f8fb6c:	91a0362a 	lsrls	r3, sl, #12
33f8fb70:	9283206e 	addls	r2, r3, #110	; 0x6e
33f8fb74:	9a000008 	bls	33f8fb9c <malloc+0xf8>
33f8fb78:	e3520f55 	cmp	r2, #340	; 0x154
33f8fb7c:	91a037aa 	lsrls	r3, sl, #15
33f8fb80:	92832077 	addls	r2, r3, #119	; 0x77
33f8fb84:	9a000004 	bls	33f8fb9c <malloc+0xf8>
33f8fb88:	e59f352c 	ldr	r3, [pc, #1324]	; 33f900bc <malloc+0x618>
33f8fb8c:	e1520003 	cmp	r2, r3
33f8fb90:	91a0392a 	lsrls	r3, sl, #18
33f8fb94:	83a0207e 	movhi	r2, #126	; 0x7e
33f8fb98:	9283207c 	addls	r2, r3, #124	; 0x7c
33f8fb9c:	e59f3514 	ldr	r3, [pc, #1300]	; 33f900b8 <malloc+0x614>
33f8fba0:	e0834182 	add	r4, r3, r2, lsl #3
33f8fba4:	e594000c 	ldr	r0, [r4, #12]
33f8fba8:	ea000012 	b	33f8fbf8 <malloc+0x154>
33f8fbac:	e5903004 	ldr	r3, [r0, #4]
33f8fbb0:	e3c33003 	bic	r3, r3, #3	; 0x3
33f8fbb4:	e06a1003 	rsb	r1, sl, r3
33f8fbb8:	e351000f 	cmp	r1, #15	; 0xf
33f8fbbc:	c2422001 	subgt	r2, r2, #1	; 0x1
33f8fbc0:	ca00000e 	bgt	33f8fc00 <malloc+0x15c>
33f8fbc4:	e3510000 	cmp	r1, #0	; 0x0
33f8fbc8:	e590c00c 	ldr	ip, [r0, #12]
33f8fbcc:	ba000008 	blt	33f8fbf4 <malloc+0x150>
33f8fbd0:	e0803003 	add	r3, r0, r3
33f8fbd4:	e5932004 	ldr	r2, [r3, #4]
33f8fbd8:	e5901008 	ldr	r1, [r0, #8]
33f8fbdc:	e3822001 	orr	r2, r2, #1	; 0x1
33f8fbe0:	e58c1008 	str	r1, [ip, #8]
33f8fbe4:	e5832004 	str	r2, [r3, #4]
33f8fbe8:	e581c00c 	str	ip, [r1, #12]
33f8fbec:	e2805008 	add	r5, r0, #8	; 0x8
33f8fbf0:	ea00012d 	b	33f900ac <malloc+0x608>
33f8fbf4:	e1a0000c 	mov	r0, ip
33f8fbf8:	e1500004 	cmp	r0, r4
33f8fbfc:	1affffea 	bne	33f8fbac <malloc+0x108>
33f8fc00:	e2827001 	add	r7, r2, #1	; 0x1
33f8fc04:	e59f54ac 	ldr	r5, [pc, #1196]	; 33f900b8 <malloc+0x614>
33f8fc08:	e2859008 	add	r9, r5, #8	; 0x8
33f8fc0c:	e599c008 	ldr	ip, [r9, #8]
33f8fc10:	e15c0009 	cmp	ip, r9
33f8fc14:	0a000056 	beq	33f8fd74 <malloc+0x2d0>
33f8fc18:	e59c3004 	ldr	r3, [ip, #4]
33f8fc1c:	e3c34003 	bic	r4, r3, #3	; 0x3
33f8fc20:	e06a0004 	rsb	r0, sl, r4
33f8fc24:	e350000f 	cmp	r0, #15	; 0xf
33f8fc28:	da000009 	ble	33f8fc54 <malloc+0x1b0>
33f8fc2c:	e08c200a 	add	r2, ip, sl
33f8fc30:	e38a3001 	orr	r3, sl, #1	; 0x1
33f8fc34:	e3801001 	orr	r1, r0, #1	; 0x1
33f8fc38:	e58c3004 	str	r3, [ip, #4]
33f8fc3c:	e589200c 	str	r2, [r9, #12]
33f8fc40:	e5892008 	str	r2, [r9, #8]
33f8fc44:	e7820000 	str	r0, [r2, r0]
33f8fc48:	e9820202 	stmib	r2, {r1, r9}
33f8fc4c:	e582900c 	str	r9, [r2, #12]
33f8fc50:	ea000007 	b	33f8fc74 <malloc+0x1d0>
33f8fc54:	e3500000 	cmp	r0, #0	; 0x0
33f8fc58:	e589900c 	str	r9, [r9, #12]
33f8fc5c:	e5899008 	str	r9, [r9, #8]
33f8fc60:	ba000005 	blt	33f8fc7c <malloc+0x1d8>
33f8fc64:	e08c2004 	add	r2, ip, r4
33f8fc68:	e5923004 	ldr	r3, [r2, #4]
33f8fc6c:	e3833001 	orr	r3, r3, #1	; 0x1
33f8fc70:	e5823004 	str	r3, [r2, #4]
33f8fc74:	e28c5008 	add	r5, ip, #8	; 0x8
33f8fc78:	ea00010b 	b	33f900ac <malloc+0x608>
33f8fc7c:	e3540c02 	cmp	r4, #512	; 0x200
33f8fc80:	2a00000c 	bcs	33f8fcb8 <malloc+0x214>
33f8fc84:	e5953004 	ldr	r3, [r5, #4]
33f8fc88:	e1a011a4 	lsr	r1, r4, #3
33f8fc8c:	e1a00141 	asr	r0, r1, #2
33f8fc90:	e3a02001 	mov	r2, #1	; 0x1
33f8fc94:	e1833012 	orr	r3, r3, r2, lsl r0
33f8fc98:	e5853004 	str	r3, [r5, #4]
33f8fc9c:	e0851181 	add	r1, r5, r1, lsl #3
33f8fca0:	e5913008 	ldr	r3, [r1, #8]
33f8fca4:	e58c100c 	str	r1, [ip, #12]
33f8fca8:	e58c3008 	str	r3, [ip, #8]
33f8fcac:	e583c00c 	str	ip, [r3, #12]
33f8fcb0:	e581c008 	str	ip, [r1, #8]
33f8fcb4:	ea00002e 	b	33f8fd74 <malloc+0x2d0>
33f8fcb8:	e1a014a4 	lsr	r1, r4, #9
33f8fcbc:	e3510004 	cmp	r1, #4	; 0x4
33f8fcc0:	91a03324 	lsrls	r3, r4, #6
33f8fcc4:	92831038 	addls	r1, r3, #56	; 0x38
33f8fcc8:	9a00000f 	bls	33f8fd0c <malloc+0x268>
33f8fccc:	e3510014 	cmp	r1, #20	; 0x14
33f8fcd0:	9281105b 	addls	r1, r1, #91	; 0x5b
33f8fcd4:	9a00000c 	bls	33f8fd0c <malloc+0x268>
33f8fcd8:	e3510054 	cmp	r1, #84	; 0x54
33f8fcdc:	91a03624 	lsrls	r3, r4, #12
33f8fce0:	9283106e 	addls	r1, r3, #110	; 0x6e
33f8fce4:	9a000008 	bls	33f8fd0c <malloc+0x268>
33f8fce8:	e3510f55 	cmp	r1, #340	; 0x154
33f8fcec:	91a037a4 	lsrls	r3, r4, #15
33f8fcf0:	92831077 	addls	r1, r3, #119	; 0x77
33f8fcf4:	9a000004 	bls	33f8fd0c <malloc+0x268>
33f8fcf8:	e59f33bc 	ldr	r3, [pc, #956]	; 33f900bc <malloc+0x618>
33f8fcfc:	e1510003 	cmp	r1, r3
33f8fd00:	91a03924 	lsrls	r3, r4, #18
33f8fd04:	83a0107e 	movhi	r1, #126	; 0x7e
33f8fd08:	9283107c 	addls	r1, r3, #124	; 0x7c
33f8fd0c:	e59f63a4 	ldr	r6, [pc, #932]	; 33f900b8 <malloc+0x614>
33f8fd10:	e0865181 	add	r5, r6, r1, lsl #3
33f8fd14:	e5950008 	ldr	r0, [r5, #8]
33f8fd18:	e1500005 	cmp	r0, r5
33f8fd1c:	11a02000 	movne	r2, r0
33f8fd20:	1a000009 	bne	33f8fd4c <malloc+0x2a8>
33f8fd24:	e5963004 	ldr	r3, [r6, #4]
33f8fd28:	e1a01141 	asr	r1, r1, #2
33f8fd2c:	e3a02001 	mov	r2, #1	; 0x1
33f8fd30:	e1833112 	orr	r3, r3, r2, lsl r1
33f8fd34:	e5863004 	str	r3, [r6, #4]
33f8fd38:	e1a03000 	mov	r3, r0
33f8fd3c:	ea000008 	b	33f8fd64 <malloc+0x2c0>
33f8fd40:	e5922008 	ldr	r2, [r2, #8]
33f8fd44:	e1520005 	cmp	r2, r5
33f8fd48:	0a000003 	beq	33f8fd5c <malloc+0x2b8>
33f8fd4c:	e5923004 	ldr	r3, [r2, #4]
33f8fd50:	e3c33003 	bic	r3, r3, #3	; 0x3
33f8fd54:	e1540003 	cmp	r4, r3
33f8fd58:	3afffff8 	bcc	33f8fd40 <malloc+0x29c>
33f8fd5c:	e592300c 	ldr	r3, [r2, #12]
33f8fd60:	e1a00002 	mov	r0, r2
33f8fd64:	e58c300c 	str	r3, [ip, #12]
33f8fd68:	e58c0008 	str	r0, [ip, #8]
33f8fd6c:	e580c00c 	str	ip, [r0, #12]
33f8fd70:	e583c008 	str	ip, [r3, #8]
33f8fd74:	e1a03147 	asr	r3, r7, #2
33f8fd78:	e3a02001 	mov	r2, #1	; 0x1
33f8fd7c:	e1a00312 	lsl	r0, r2, r3
33f8fd80:	e59f3330 	ldr	r3, [pc, #816]	; 33f900b8 <malloc+0x614>
33f8fd84:	e5932004 	ldr	r2, [r3, #4]
33f8fd88:	e1500002 	cmp	r0, r2
33f8fd8c:	8a00004f 	bhi	33f8fed0 <malloc+0x42c>
33f8fd90:	e1100002 	tst	r0, r2
33f8fd94:	03c73003 	biceq	r3, r7, #3	; 0x3
33f8fd98:	02837004 	addeq	r7, r3, #4	; 0x4
33f8fd9c:	0a000001 	beq	33f8fda8 <malloc+0x304>
33f8fda0:	ea000003 	b	33f8fdb4 <malloc+0x310>
33f8fda4:	e2877004 	add	r7, r7, #4	; 0x4
33f8fda8:	e1a00080 	lsl	r0, r0, #1
33f8fdac:	e1100002 	tst	r0, r2
33f8fdb0:	0afffffb 	beq	33f8fda4 <malloc+0x300>
33f8fdb4:	e59f32fc 	ldr	r3, [pc, #764]	; 33f900b8 <malloc+0x614>
33f8fdb8:	e0831187 	add	r1, r3, r7, lsl #3
33f8fdbc:	e1a05007 	mov	r5, r7
33f8fdc0:	e1a02001 	mov	r2, r1
33f8fdc4:	e592400c 	ldr	r4, [r2, #12]
33f8fdc8:	ea000020 	b	33f8fe50 <malloc+0x3ac>
33f8fdcc:	e5943004 	ldr	r3, [r4, #4]
33f8fdd0:	e3c33003 	bic	r3, r3, #3	; 0x3
33f8fdd4:	e06a6003 	rsb	r6, sl, r3
33f8fdd8:	e356000f 	cmp	r6, #15	; 0xf
33f8fddc:	da00000e 	ble	33f8fe1c <malloc+0x378>
33f8fde0:	e1a05004 	mov	r5, r4
33f8fde4:	e594c00c 	ldr	ip, [r4, #12]
33f8fde8:	e5b50008 	ldr	r0, [r5, #8]!
33f8fdec:	e084300a 	add	r3, r4, sl
33f8fdf0:	e38a1001 	orr	r1, sl, #1	; 0x1
33f8fdf4:	e3862001 	orr	r2, r6, #1	; 0x1
33f8fdf8:	e58c0008 	str	r0, [ip, #8]
33f8fdfc:	e580c00c 	str	ip, [r0, #12]
33f8fe00:	e5841004 	str	r1, [r4, #4]
33f8fe04:	e5893008 	str	r3, [r9, #8]
33f8fe08:	e589300c 	str	r3, [r9, #12]
33f8fe0c:	e7836006 	str	r6, [r3, r6]
33f8fe10:	e9830204 	stmib	r3, {r2, r9}
33f8fe14:	e583900c 	str	r9, [r3, #12]
33f8fe18:	ea0000a3 	b	33f900ac <malloc+0x608>
33f8fe1c:	e3560000 	cmp	r6, #0	; 0x0
33f8fe20:	e594c00c 	ldr	ip, [r4, #12]
33f8fe24:	ba000008 	blt	33f8fe4c <malloc+0x3a8>
33f8fe28:	e0843003 	add	r3, r4, r3
33f8fe2c:	e5932004 	ldr	r2, [r3, #4]
33f8fe30:	e1a05004 	mov	r5, r4
33f8fe34:	e5b51008 	ldr	r1, [r5, #8]!
33f8fe38:	e3822001 	orr	r2, r2, #1	; 0x1
33f8fe3c:	e5832004 	str	r2, [r3, #4]
33f8fe40:	e58c1008 	str	r1, [ip, #8]
33f8fe44:	e581c00c 	str	ip, [r1, #12]
33f8fe48:	ea000097 	b	33f900ac <malloc+0x608>
33f8fe4c:	e1a0400c 	mov	r4, ip
33f8fe50:	e1540002 	cmp	r4, r2
33f8fe54:	1affffdc 	bne	33f8fdcc <malloc+0x328>
33f8fe58:	e2855001 	add	r5, r5, #1	; 0x1
33f8fe5c:	e3150003 	tst	r5, #3	; 0x3
33f8fe60:	12822008 	addne	r2, r2, #8	; 0x8
33f8fe64:	1affffd6 	bne	33f8fdc4 <malloc+0x320>
33f8fe68:	e1a03007 	mov	r3, r7
33f8fe6c:	e3130003 	tst	r3, #3	; 0x3
33f8fe70:	e1a02001 	mov	r2, r1
33f8fe74:	e2433001 	sub	r3, r3, #1	; 0x1
33f8fe78:	059f2238 	ldreq	r2, [pc, #568]	; 33f900b8 <malloc+0x614>
33f8fe7c:	05923004 	ldreq	r3, [r2, #4]
33f8fe80:	01c33000 	biceq	r3, r3, r0
33f8fe84:	05823004 	streq	r3, [r2, #4]
33f8fe88:	0a000002 	beq	33f8fe98 <malloc+0x3f4>
33f8fe8c:	e4121008 	ldr	r1, [r2], #-8
33f8fe90:	e1510002 	cmp	r1, r2
33f8fe94:	0afffff4 	beq	33f8fe6c <malloc+0x3c8>
33f8fe98:	e59f3218 	ldr	r3, [pc, #536]	; 33f900b8 <malloc+0x614>
33f8fe9c:	e5933004 	ldr	r3, [r3, #4]
33f8fea0:	e1a00080 	lsl	r0, r0, #1
33f8fea4:	e1500003 	cmp	r0, r3
33f8fea8:	8a000008 	bhi	33f8fed0 <malloc+0x42c>
33f8feac:	e3500000 	cmp	r0, #0	; 0x0
33f8feb0:	0a000006 	beq	33f8fed0 <malloc+0x42c>
33f8feb4:	e1a07005 	mov	r7, r5
33f8feb8:	ea000001 	b	33f8fec4 <malloc+0x420>
33f8febc:	e2877004 	add	r7, r7, #4	; 0x4
33f8fec0:	e1a00080 	lsl	r0, r0, #1
33f8fec4:	e1100003 	tst	r0, r3
33f8fec8:	1affffb9 	bne	33f8fdb4 <malloc+0x310>
33f8fecc:	eafffffa 	b	33f8febc <malloc+0x418>
33f8fed0:	e59f21e0 	ldr	r2, [pc, #480]	; 33f900b8 <malloc+0x614>
33f8fed4:	e5926008 	ldr	r6, [r2, #8]
33f8fed8:	e5963004 	ldr	r3, [r6, #4]
33f8fedc:	e3c37003 	bic	r7, r3, #3	; 0x3
33f8fee0:	e06a0007 	rsb	r0, sl, r7
33f8fee4:	e350000f 	cmp	r0, #15	; 0xf
33f8fee8:	ca000064 	bgt	33f90080 <malloc+0x5dc>
33f8feec:	e59f31c0 	ldr	r3, [pc, #448]	; 33f900b4 <malloc+0x610>
33f8fef0:	e5933034 	ldr	r3, [r3, #52]
33f8fef4:	e5929408 	ldr	r9, [r2, #1032]
33f8fef8:	e2833010 	add	r3, r3, #16	; 0x10
33f8fefc:	e3790001 	cmn	r9, #1	; 0x1
33f8ff00:	e083500a 	add	r5, r3, sl
33f8ff04:	12853eff 	addne	r3, r5, #4080	; 0xff0
33f8ff08:	1283300f 	addne	r3, r3, #15	; 0xf
33f8ff0c:	13c35eff 	bicne	r5, r3, #4080	; 0xff0
33f8ff10:	13c5500f 	bicne	r5, r5, #15	; 0xf
33f8ff14:	e1a00005 	mov	r0, r5
33f8ff18:	ebfffe11 	bl	33f8f764 <sbrk>
33f8ff1c:	e3700001 	cmn	r0, #1	; 0x1
33f8ff20:	e1a04000 	mov	r4, r0
33f8ff24:	0a00004e 	beq	33f90064 <malloc+0x5c0>
33f8ff28:	e0862007 	add	r2, r6, r7
33f8ff2c:	e1500002 	cmp	r0, r2
33f8ff30:	2a000002 	bcs	33f8ff40 <malloc+0x49c>
33f8ff34:	e59f317c 	ldr	r3, [pc, #380]	; 33f900b8 <malloc+0x614>
33f8ff38:	e1560003 	cmp	r6, r3
33f8ff3c:	1a000048 	bne	33f90064 <malloc+0x5c0>
33f8ff40:	e59f116c 	ldr	r1, [pc, #364]	; 33f900b4 <malloc+0x610>
33f8ff44:	e591300c 	ldr	r3, [r1, #12]
33f8ff48:	e1540002 	cmp	r4, r2
33f8ff4c:	e0853003 	add	r3, r5, r3
33f8ff50:	e581300c 	str	r3, [r1, #12]
33f8ff54:	1a000005 	bne	33f8ff70 <malloc+0x4cc>
33f8ff58:	e59f2158 	ldr	r2, [pc, #344]	; 33f900b8 <malloc+0x614>
33f8ff5c:	e0853007 	add	r3, r5, r7
33f8ff60:	e5922008 	ldr	r2, [r2, #8]
33f8ff64:	e3833001 	orr	r3, r3, #1	; 0x1
33f8ff68:	e5823004 	str	r3, [r2, #4]
33f8ff6c:	ea000033 	b	33f90040 <malloc+0x59c>
33f8ff70:	e3790001 	cmn	r9, #1	; 0x1
33f8ff74:	10843003 	addne	r3, r4, r3
33f8ff78:	059f3138 	ldreq	r3, [pc, #312]	; 33f900b8 <malloc+0x614>
33f8ff7c:	10623003 	rsbne	r3, r2, r3
33f8ff80:	05834408 	streq	r4, [r3, #1032]
33f8ff84:	1581300c 	strne	r3, [r1, #12]
33f8ff88:	e2143007 	ands	r3, r4, #7	; 0x7
33f8ff8c:	12630008 	rsbne	r0, r3, #8	; 0x8
33f8ff90:	01a00003 	moveq	r0, r3
33f8ff94:	e2853eff 	add	r3, r5, #4080	; 0xff0
33f8ff98:	10844000 	addne	r4, r4, r0
33f8ff9c:	e283300f 	add	r3, r3, #15	; 0xf
33f8ffa0:	e0843003 	add	r3, r4, r3
33f8ffa4:	e3c33eff 	bic	r3, r3, #4080	; 0xff0
33f8ffa8:	e0842005 	add	r2, r4, r5
33f8ffac:	e3c3300f 	bic	r3, r3, #15	; 0xf
33f8ffb0:	e0623003 	rsb	r3, r2, r3
33f8ffb4:	e0835000 	add	r5, r3, r0
33f8ffb8:	e1a00005 	mov	r0, r5
33f8ffbc:	ebfffde8 	bl	33f8f764 <sbrk>
33f8ffc0:	e3700001 	cmn	r0, #1	; 0x1
33f8ffc4:	e1a03000 	mov	r3, r0
33f8ffc8:	0a000025 	beq	33f90064 <malloc+0x5c0>
33f8ffcc:	e59f00e0 	ldr	r0, [pc, #224]	; 33f900b4 <malloc+0x610>
33f8ffd0:	e59f10e0 	ldr	r1, [pc, #224]	; 33f900b8 <malloc+0x614>
33f8ffd4:	e590200c 	ldr	r2, [r0, #12]
33f8ffd8:	e0643003 	rsb	r3, r4, r3
33f8ffdc:	e0853003 	add	r3, r5, r3
33f8ffe0:	e0852002 	add	r2, r5, r2
33f8ffe4:	e3833001 	orr	r3, r3, #1	; 0x1
33f8ffe8:	e1560001 	cmp	r6, r1
33f8ffec:	e580200c 	str	r2, [r0, #12]
33f8fff0:	e5814008 	str	r4, [r1, #8]
33f8fff4:	e5843004 	str	r3, [r4, #4]
33f8fff8:	0a000010 	beq	33f90040 <malloc+0x59c>
33f8fffc:	e357000f 	cmp	r7, #15	; 0xf
33f90000:	93a03001 	movls	r3, #1	; 0x1
33f90004:	95843004 	strls	r3, [r4, #4]
33f90008:	9a000015 	bls	33f90064 <malloc+0x5c0>
33f9000c:	e5963004 	ldr	r3, [r6, #4]
33f90010:	e247200c 	sub	r2, r7, #12	; 0xc
33f90014:	e3c22007 	bic	r2, r2, #7	; 0x7
33f90018:	e2033001 	and	r3, r3, #1	; 0x1
33f9001c:	e1823003 	orr	r3, r2, r3
33f90020:	e3a01005 	mov	r1, #5	; 0x5
33f90024:	e352000f 	cmp	r2, #15	; 0xf
33f90028:	e0862002 	add	r2, r6, r2
33f9002c:	e5863004 	str	r3, [r6, #4]
33f90030:	e5821008 	str	r1, [r2, #8]
33f90034:	e5821004 	str	r1, [r2, #4]
33f90038:	82860008 	addhi	r0, r6, #8	; 0x8
33f9003c:	8bfffe08 	blhi	33f8f864 <free>
33f90040:	e59f106c 	ldr	r1, [pc, #108]	; 33f900b4 <malloc+0x610>
33f90044:	e591200c 	ldr	r2, [r1, #12]
33f90048:	e5913038 	ldr	r3, [r1, #56]
33f9004c:	e1520003 	cmp	r2, r3
33f90050:	85812038 	strhi	r2, [r1, #56]
33f90054:	e59f1058 	ldr	r1, [pc, #88]	; 33f900b4 <malloc+0x610>
33f90058:	e591303c 	ldr	r3, [r1, #60]
33f9005c:	e1520003 	cmp	r2, r3
33f90060:	8581203c 	strhi	r2, [r1, #60]
33f90064:	e59f304c 	ldr	r3, [pc, #76]	; 33f900b8 <malloc+0x614>
33f90068:	e5933008 	ldr	r3, [r3, #8]
33f9006c:	e5933004 	ldr	r3, [r3, #4]
33f90070:	e3c33003 	bic	r3, r3, #3	; 0x3
33f90074:	e06a0003 	rsb	r0, sl, r3
33f90078:	e350000f 	cmp	r0, #15	; 0xf
33f9007c:	da000009 	ble	33f900a8 <malloc+0x604>
33f90080:	e59fc030 	ldr	ip, [pc, #48]	; 33f900b8 <malloc+0x614>
33f90084:	e59c2008 	ldr	r2, [ip, #8]
33f90088:	e3800001 	orr	r0, r0, #1	; 0x1
33f9008c:	e082100a 	add	r1, r2, sl
33f90090:	e38a3001 	orr	r3, sl, #1	; 0x1
33f90094:	e5823004 	str	r3, [r2, #4]
33f90098:	e58c1008 	str	r1, [ip, #8]
33f9009c:	e5810004 	str	r0, [r1, #4]
33f900a0:	e2825008 	add	r5, r2, #8	; 0x8
33f900a4:	ea000000 	b	33f900ac <malloc+0x608>
33f900a8:	e3a05000 	mov	r5, #0	; 0x0
33f900ac:	e1a00005 	mov	r0, r5
33f900b0:	e8bd87f0 	pop	{r4, r5, r6, r7, r8, r9, sl, pc}
33f900b4:	33fa3e20 	.word	0x33fa3e20
33f900b8:	33f9ff54 	.word	0x33f9ff54
33f900bc:	00000554 	.word	0x00000554

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Scott Wood]

On Fri, 12 Nov 2010 20:45:18 +0800
terry <gliumailenator@gmail.com> wrote:

> Dear Scott,
> 	I have disassemble the nand_base.o file,because i know the problem
> happened here.

Why not disassemble the whole u-boot?

Then you'll get malloc as well, and the addresses will be closer to
what shows up in the dump.

> Do you think it's useful for your analysis?

Can you disassemble malloc?  That's where it actually crashed.

> 00001a4c <nand_scan_tail>:
>  1749     1a4c:   e92d4070    push    {r4, r5, r6, lr}
>  1750     1a50:   e590509c    ldr r5, [r0, #156]
>  1751     1a54:   e595304c    ldr r3, [r5, #76]
>  1752     1a58:   e3130701    tst r3, #262144 ; 0x40000
>  1753     1a5c:   e1a06000    mov r6, r0
>  1754     1a60:   1a000002    bne 1a70 <nand_scan_tail+0x24>
>  1755     1a64:   e59f04ec    ldr r0, [pc, #1260] ; 1f58 <nand_scan_tail
> +0x50c>
>  1756     1a68:   ebfffffe    bl  0 <malloc>

What's the value at PC+1260?

> by the way,I cann't find the prototype of malloc in the whole project,it
> seems that it is encapsulated in some libs.

It's in common/malloc.c.  There's weird preprocessor renaming going on,
so it's called mALLOc in that file, but it shows up as malloc in the
binary.

-Scott

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[terry]

Dear Scott,
	I have disassemble the nand_base.o file,because i know the problem
happened here. Do you think it's useful for your analysis?

00001a4c <nand_scan_tail>:
 1749     1a4c:   e92d4070    push    {r4, r5, r6, lr}
 1750     1a50:   e590509c    ldr r5, [r0, #156]
 1751     1a54:   e595304c    ldr r3, [r5, #76]
 1752     1a58:   e3130701    tst r3, #262144 ; 0x40000
 1753     1a5c:   e1a06000    mov r6, r0
 1754     1a60:   1a000002    bne 1a70 <nand_scan_tail+0x24>
 1755     1a64:   e59f04ec    ldr r0, [pc, #1260] ; 1f58 <nand_scan_tail
+0x50c>
 1756     1a68:   ebfffffe    bl  0 <malloc>
 1757     1a6c:   e58500dc    str r0, [r5, #220]
 1758     1a70:   e59510dc    ldr r1, [r5, #220]
 1759     1a74:   e3510000    cmp r1, #0  ; 0x0
 1760     1a78:   03e0000b    mvneq   r0, #11 ; 0xb
 1761     1a7c:   08bd8070    popeq   {r4, r5, r6, pc}
 1762     1a80:   e5963014    ldr r3, [r6, #20]
 1763     1a84:   e59520b0    ldr r2, [r5, #176]
 1764     1a88:   e0813003    add r3, r1, r3
by the way,I cann't find the prototype of malloc in the whole project,it
seems that it is encapsulated in some libs.
--
Best regards,
Terry.

? 2010-11-11?? 13:49 -0600?Scott Wood???
> On Thu, 11 Nov 2010 23:06:01 +0800
> terry <gliumailenator@gmail.com> wrote:
> 
> > Dear everyone,
> > I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu
> > is s3c2410),the output from serial shows that cpu has exception, the
> > information list as following:
> > U-Boot 2010.09 (Nov 11 2010 - 21:55:07)
> > 
> > U-Boot code: 33F80000 -> 33FA0BDC  BSS: -> 33FA45EC
> > RAM Configuration:
> > Bank #0: 30000000 64 MiB
> > NAND:  data abort
> > pc : [<33f8fbb4>]          lr : [<33f85f70>]
> > sp : 33f07fac  ip : 00000000     fp : 00000000
> > r10: 00001298  r9 : ffffff7f     r8 : 33f4ffe0
> > r7 : 00000000  r6 : 33fa3b50     r5 : 33fa3c00  r4 : 33fa0274
> > r3 : 33f9ff54  r2 : 00000064     r1 : 00000001  r0 : cc33cc33
> > Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
> > Resetting CPU ...
> > 
> > value of pc locate at <malloc> function, value of lr locate at
> > <nand_scan_tail>(/drivers/mtd/nand/nand_base.c).
> 
> Could you look up the specific line numbers of
> 0x33f8fbb4 and 0x33f85f6c, and show a few lines of disassembly around
> those addresses?
> 
> -Scott
> 

-- 
Best regards,
terry

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[Scott Wood]

On Thu, 11 Nov 2010 23:06:01 +0800
terry <gliumailenator@gmail.com> wrote:

> Dear everyone,
> I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu
> is s3c2410),the output from serial shows that cpu has exception, the
> information list as following:
> U-Boot 2010.09 (Nov 11 2010 - 21:55:07)
> 
> U-Boot code: 33F80000 -> 33FA0BDC  BSS: -> 33FA45EC
> RAM Configuration:
> Bank #0: 30000000 64 MiB
> NAND:  data abort
> pc : [<33f8fbb4>]          lr : [<33f85f70>]
> sp : 33f07fac  ip : 00000000     fp : 00000000
> r10: 00001298  r9 : ffffff7f     r8 : 33f4ffe0
> r7 : 00000000  r6 : 33fa3b50     r5 : 33fa3c00  r4 : 33fa0274
> r3 : 33f9ff54  r2 : 00000064     r1 : 00000001  r0 : cc33cc33
> Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> value of pc locate at <malloc> function, value of lr locate at
> <nand_scan_tail>(/drivers/mtd/nand/nand_base.c).

Could you look up the specific line numbers of
0x33f8fbb4 and 0x33f85f6c, and show a few lines of disassembly around
those addresses?

-Scott

[U-Boot] Hanging in kmalloc of nand_scan_tail() function

[terry]

Dear everyone,
I'm using u-boot-2010.09. After I download u-boot.bin to my boards(cpu
is s3c2410),the output from serial shows that cpu has exception, the
information list as following:
U-Boot 2010.09 (Nov 11 2010 - 21:55:07)

U-Boot code: 33F80000 -> 33FA0BDC  BSS: -> 33FA45EC
RAM Configuration:
Bank #0: 30000000 64 MiB
NAND:  data abort
pc : [<33f8fbb4>]          lr : [<33f85f70>]
sp : 33f07fac  ip : 00000000     fp : 00000000
r10: 00001298  r9 : ffffff7f     r8 : 33f4ffe0
r7 : 00000000  r6 : 33fa3b50     r5 : 33fa3c00  r4 : 33fa0274
r3 : 33f9ff54  r2 : 00000064     r1 : 00000001  r0 : cc33cc33
Flags: NzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

value of pc locate at <malloc> function, value of lr locate at
<nand_scan_tail>(/drivers/mtd/nand/nand_base.c).

I have seen that someone had this problem before, have you resolved it?
Can you give me some suggestions?