In message 41BF1344.7020103@wiline.com you wrote:
So, I now wanted to try and compile the bootloader using a versionof gcc greater or equal to 3.3. Maybe this is a bad idea but I was
It is not a bad idea - it should work fine. ELDK release 3.1 uses GC-3.3.3, and this works fine.
curious. Anyway the compilation seemed to go fine but producing the srec, "objcopy --gap-fill=0xff -O srec u-boot u-boot.srec", resulted in the objcopy application being stuck in a long loop and eating up a significant amount of system memory. Apparently it had caculated that
I've seen this before. It happened for the ERIC board. The problem was that the TEXT_BASE definition for the ERIC board was set to 0xFFFE0000 while the resultant code and data size of U-Boot was bigger than the 0x20000 bytes. This confused the linker and objcopy because the memory address of the last portion of the image goes beyond the 0xFFFFFFFF value causing an overflow of a 32-bit variable.
The easiest way to solve the problem for this particular board was to change the TEXT_BASE definition to a lower value, for instance to 0xFFFC0000.
output of the compiler is different than what should be expected. I know an easy solution would be to use the ELDK in place of the current toolchain but I'm more interested in understanding what is going wrong.
Check if it's really a toolchain problem, or just a misconfiguration for your board.
For example, try if you can build other (standard) board configurations using your toolchain.
Best regards,
Wolfgang Denk