Dear Reinhard Meyer,
In message 4CCC709F.20306@emk-elektronik.de you wrote:
Neither do I -- if you think of Alexander's issue, I think it is not related to BSS initialization.
No, since everything works fine here (though I cannot confirm BSS gets cleared, maybe none of the code active here assumes cleared BSS:) ), but I am sure ALL code and vars is really accessed at the final, high end RAM location. I filled all RAM upto 2MB below the end with garbage and nothing crashed and u-boot still behaved proper.
Well, if you like then just make an experiment and replace the
mov r2, #0x00000000 /* clear */
by something like
mov r2, #0xA5A5A5A5 /* clear */
and watch your system go kaboom...
Alexander's issue cannot be related to a general u-boot problem, it must be SoC or board specific or handling specific. As to what we can only speculate.
I can only advise again to check for static vars that are used before relocation (which need not lead to a crash), but their values will be lost during relocation. This made timers fail here because clock frequencies calculated in timer init before relocation and stored in static vars were gone after relocation.
That would most likely be driver stuff, which is shared with other boards, so thse should show similar issues.
My bet is on errors in the initial RAM setup - like unaligned intial stack (which would also explain the bogus RAM sizes printed, with the hex numbers not even corresponding to the decimal decoding), and/or tool chain issues (I've seen way too many optimizer bugs in GCC >= 4.3 lately).
Oh, and u-boot did not work here when compiled with gcc 4.4.5 - I almost forgot about that... I think I even mentioned that in some message a while ago, but I can't find it right now.
I'm neither surprised nor amused.
Best regards,
Wolfgang Denk