[U-Boot-Users] examples programs

Hi Folks,
I am using U-Boot 0.4.0 with an MPC8245 processor with 64MBytes of SDRAM. The hardware appears to work fine, as we can load / run U-Boot and then run Embedded Linux without a problem.
I have written some simple hardware test programs, again without a problem, using the examples/hello_world.c as a starting point. However, as they get more complex, i.e. more variables and larger, the program crashes, with odd messages coming out of mon_printf commands. It looks to me as though the stack is crashing.
If I make the LOAD_ADDR in the Makefile 0x03000000, originally the default location 0x00040004, i.e. much higher up than the original, the test program works fine and returns to U-Boot without error.
Has anybody else seen anything like this? Or can anybody tell me where the stack is? I have looked at the documentation, and cannot see anywhere that describes the memory layout when U-Boot is running.
Regards
David Stoddart
Aculab PLC

Dear Dave,
in message 8C9A566C643ED6119E8900A0C9DE297A01CE79B0@saturn.aculab.com you wrote:
I have written some simple hardware test programs, again without a problem, using the examples/hello_world.c as a starting point. However, as they get more complex, i.e. more variables and larger, the program crashes, with odd messages coming out of mon_printf commands. It looks to me as though the stack is crashing.
Your application may cortrupt the stack, but otherwise I don;t think this is related to U-Boot's memory management.
If I make the LOAD_ADDR in the Makefile 0x03000000, originally the default location 0x00040004, i.e. much higher up than the original, the test program works fine and returns to U-Boot without error.
Then it's clearly a problem with your own code.
Has anybody else seen anything like this? Or can anybody tell me where the stack is? I have looked at the documentation, and cannot see anywhere that describes the memory layout when U-Boot is running.
Ummm... Did you really miss the section "Memory Management" in the README file? Strange...
Best regards,
Wolfgang Denk
participants (2)
-
Dave.Stoddartļ¼ aculab.com
-
Wolfgang Denk