Wolfgang Denk wrote:
In message 41BF1344.7020103@wiline.com you wrote:
So, I now wanted to try and compile the bootloader using a version of 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.
I'm compiling using the settings for the a3000 (make A3000_config). The board I'm using is similar, there were some slight modifications to make it work. But, I'm running into the same issue when I use the "vanilla" 1.1.1 release of u-boot.
Changing the TEXT_BASE allowed me to compile but I had to set it to a very low address. Initially it was set to 0xFFF00000, I was able to compile when I changed it to 0xF00000. The resulting u-boot.bin was over 15MB in size which can't be right.
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.
I was able to build the other boards without a problem such as the MPC8540ADS and Sandpoint8245. I wonder what particular about the a3000 settings is causing the problems. I'll try out version 3.1 of the ELDK and see what happens.
I really appreciate your helpful and informative response, Thank you.
Best regards,
Wolfgang Denk
regards, Andrew