Re: [U-Boot-Users] malloc problem
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!
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.
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?
Best regards,
Wolfgang Denk
--- 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.
Dear Mike,
in message 20040209141354.93048.qmail@web40112.mail.yahoo.com you wrote:
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
OK, this should be pretty save, then.
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.
Ummm.. what do you mean about "utilize all 4 processors"? U-Boot / PPCboot is strictly single-tasking, so what are the other processors used for?
I have lots more info from putting nasty printf's all over the malloc code. If I still can't figure it
I think this will not lead anywhere. Probably you are just hunting down post-mortem symptoms.
out, I'll send the modified source and the trace from its execution.
Oh no, please not. The problem is most definitely somewhere else.
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.
Check your memory map, stack depth, stack overruns (or underruns) in your private code, etc. I tend to believe that you either corrupted the malloc internal data and/or the stack somehow.
I just work up, its 7:08AM in Denver. It will be
7 am? What a lousy time to get up ;-)
PS: I LOVE the sig on your message, Wolfgang!
:-) Just never mention it to the manager or the customer ...
Best regards,
Wolfgang Denk
participants (2)
-
Mike Wellington -
Wolfgang Denk