--- Wolfgang Denk wd@denx.de wrote:
In message 20040209045324.CD0D642FA7@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@denx.de To the systems programmer, users and applications serve only to provide a test load.