[U-Boot-Users] malloc problem

[Mike Wellington]

--- Wolfgang Denk <wd at denx.de> wrote:
> In message <20040209045324.CD0D642FA7 at denx.de> you
> wrote:
> > 
> > I am porting PPCBoot 2.0.0 to the Xilinx ML300.  I
> know
> > PPCBoot is deprecated in favor of U-Boot, but the
> nearest port
> > for our board was a PPCBoot port that I got from
> someone
> > who never submitted their changes.
> 
> Shame on the unnamed third party!

Yeah.  
> 
> > Everything works fine until the call from
> board_init_r() in
> > lib_ppc/board.c  to devices_init().  Then
> somewhere in devices_init()
> > there is a call to malloc() which never returns
> and overwrites 
> > much of system memory.  
> 
> You can be pretty sure that the malloc() code is NOT
> the culprit  for
> your problem.

Agreed.  Malloc() should be pretty bulletproof by now.

> 
> > Has anyone else had problems like this?  I
> compared the 
> > malloc code from U-Boot 1.0.0 to PPCBoot 2.0.0 and
> except
> > for spacing they look the same.  I then built
> PPCBoot with
> > the dlmalloc.c from U-Boot and the problem is
> still there.
> 
> It may be anything, but  malloc  is  most  certainly
>  innocent  here.
> Sorry, the information you provided is not
> sufficient for an educated
> guess,  but  here is a wild speculation - are you
> 100% sure that your
> SDRAM is working reliably?

I am suspicious of the way memory was initially
allocated for the heap.  I'm not 100% sure that 
SDRAM works reliably, but it does boot and run
a different version of Linux with no problem.  One
thing, the version of PPCBoot that I have appears
to have been written to utilize all 4 processors,
while I am only using 1 CPU.

I have lots more info from putting nasty printf's 
all over the malloc code.  If I still can't figure it
out, I'll send the modified source and the 
trace from its execution.  

These large sizes for victim->size really concern me.
I think that if I can figure out why the victim->size
goes so astronomical then I will have found the 
culprit.  I was hoping that maybe somebody had
seen this problem before.

I just work up, its 7:08AM in Denver.  It will be 
2 hours by the time I have my coffee and catch a bus
to work.  I'll have more info then.


PS:  I LOVE the sig on your message, Wolfgang!

-mikew

> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> See us @ Embedded World, Nuremberg, Feb 17 - 19, 
> Hall 12.0 Booth 440
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88 
> Email: wd at denx.de
> To the systems programmer,  users  and  applications
>  serve  only  to
> provide a test load.