On Thu, Apr 8, 2010 at 6:08 AM, Wolfgang Denk wd@denx.de wrote:
Dear Brian Hutchinson,
In message s2x3d1967ab1004071751j50c177f6haaafa222f76f3632@mail.gmail.com you wrote:
...
## Booting image at 00200000 ... Image Name: Linux-2.6.28-picochip-3.2.0 Created: 2010-04-05 19:24:18 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1700808 Bytes = 1.6 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK
And then everything hangs. Should I play with moving around TEXT_BASE (0x05000000), linker files? I'm kind of stumped at the moment. :(
What makes you think this would be a U-Boot problem?
Because everything worked just fine before. I only ran into problems when I turned on the redundant environment.
A load address of 0x00008000 / entry point of 0x00008000 is pretty certainly bogus on a ARM system, which typically has ROM at this address range. Are you sure that you have unused RAM there on your system?
Yes, again, everything worked fine before.
I guess I wasn't clear on why I thought it was a RAM issue. The context of the u-boot README that talked about the REDUNDANT environment has a big warning right after it that talks about linker sections etc. This plus the malloc failing is what caused me to start thinking it might be something to do with memory, memory sections etc.
I noticed my malloc pool was only 128k so I changed that to 256 and it didn't help.
CFG_MONITOR_LEN is set to 256k, the same size as a flash sector.
I guess I could continue to increase the malloc pool but I'm not sure that is my problem since when I make the environment size the same as the sector size ... I get past the malloc problem but then the kernel does not boot and hangs. The good news is saveenv is working in the case where I make the environment length the same as the flash sector length.
Regards,
Brian