On Sun, Nov 21, 2010 at 4:59 PM, Wolfgang Denk wd@denx.de wrote:
Dear Attila Sukosd,
In message AANLkTikDfFa4VZ3uo=vfht7-ZinpiBT=CqmvVzuUrjGU@mail.gmail.com you wrote:
...
Reserving 264k for malloc() at: a0f43000 Reserving 24 Bytes for Board Info at: a0f42fe8 Reserving 92 Bytes for Global Data at: a0f42f8c New Stack Pointer is: a0f42f88 RAM Configuration: Bank #0: a0000000 16 MiB relocation Offset is: a0f85000 monitor flash len: 0002CEFC Now running in RAM - U-Boot at: a0f85000 Using default environment
himport_r: can't malloc 72 bytes, ret = (null) ERROR: Me sad :( Environment import failed: errno = -1 ret: -2
...
As far as I can tell, the bootloader successfully relocates itself into
RAM
but fails to allocate 72bytes for the environment.
Please keep in mind that computers are dumb. Yes, they really are (hope none of them listens in right now).
When they tell you "I cannot to that" they usually really mean it. So the best thing in such a situation is to ask them (or, if they don't answer, ask yourself): "Why cannot you do that?"
In the case of a failing malloc() the first thing that comes to my mind is: well, maybe all available memory has been used up.
So why don't you simply try and provide more (for a test, much more) room for malloc? Try, for example, setting CONFIG_SYS_MALLOC_LEN to "(1024 * 1024)" or such?
IIRC I told you the same on IRC already, but you failed to comment...
Hi,
Thanks for your fast reply. I have indeed tried that too, 128kbytes, 256kbytes, 512kbytes and 1MB for malloc, with the same issue.
Additionally, I failed to mention another issue in my previous email, which is, I seem to be getting random behaviours from the board depending on what I modify in the code.
For example, if I add one extra debug() or puts() line under another, flash the new version on the board, the board fails to boot, and I don't see any output on the serial.
Other times, I see some output on the serial, but fails to relocate to RAM. (Note: I do not change anything other than adding one extra puts line, so all configurations stay the same)
This uncertainty worries me a bit as I do not see a clear reason on why this would be happening...
Rgrds,
Attila
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_