[U-Boot-Users] Advice about a problem compiling with alternative toolchain
Hi,
I've been experimenting with the u-boot bootloader and have found it to be an eminently useful utility for development on a powerpc based embedded device. Much thanks to the developers who have put so much effort into this project.
The question of posing while related to the compilation of u-boot doesn't really involve a problem or issue with u-boot but I thought that I might be able to get some good input on this list. Apologies in advance if this is not the proper place for this topic.
Anyway, I've been using a uclibc toolchain to build the userland applications, busybox, openssl, etc.. I thought it would be possible and convenient to use the same cross compiler for u-boot. I figured it would be possible without much difficulty because u-boot doesn't use the standard C library. And so it was fairly painless to compile a working version of u-boot. I was using a 2.95 version of gcc and 2.14.90.0.7 version of binutils. ld crashed because of silly bug in ldlang.c that was easy to fix.
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 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 one of the gaps had a size close to max int which shouldn't be possible. I don't think the problem isn't with objcopy itself but instead that the 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.
Hence, the reason for my email. If I wanted to discover the root of my problem are there any good resources for information? Potentially a specification for the format expected by object copy. Or maybe some advice on problems to expect when using a new version of gcc and/or binutils to cross compile for a different architecture. Also any general comments or information anyone would be willing to impart would be useful. Essentially I'm just trying to learn. Thank you for your time.
regards, Andrew
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
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
In message 41BF392A.908@wiline.com you wrote:
[33 lines of unrelated quote deleted]
Please quote only those parts of the message you really need for reference.
I'm compiling using the settings for the a3000 (make A3000_config). The
The A3000 board builds fine without any errors; and the resulting images has a reasonable size:
-> MAKEALL A3000 Configuring for A3000 board... text data bss dec hex filename 119432 7648 25616 152696 25478 u-boot -> ls -lh u-boot.bin -rwxr-xr-x 1 wd users 127K Dec 14 20:19 u-boot.bin
board I'm using is similar, there were some slight modifications to make
Then double-check your "slight" modifications.
it work. But, I'm running into the same issue when I use the "vanilla" 1.1.1 release of u-boot.
Except for a harmless warning (by GCC-3.3.3) U-Boot-1.1.1 builds just fine, too:
-> MAKEALL A3000 Configuring for A3000 board... cmd_bootm.c: In function `do_bootm': cmd_bootm.c:329: warning: dereferencing type-punned pointer will break strict-aliasing rules text data bss dec hex filename 119296 7648 25616 152560 253f0 u-boot -> ls -lh u-boot.bin -rwxr-xr-x 1 wd users 127K Dec 14 20:22 u-boot.bin
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.
Indeed. Check your "slight" modifications.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Except for a harmless warning (by GCC-3.3.3) U-Boot-1.1.1 builds just fine, too:
Thanks that is good to know. I'm fairly certain now that the problem is with the cross compiler I built.
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.
Indeed. Check your "slight" modifications.
Will do. Well when I said "slight" I didn't make any guarantees about correct. Truly the root cause of my problems is myself.
Thanks again, Andrew
Just to follow up. I was able to get the toolchain I built, gcc-3.3.3 and binutil 2.14.90.0.6, to compile u-boot.bin by modifying linker script, board/a3000/u-boot.lds.
--- u-boot.lds 2003-06-27 17:31:56.000000000 -0400 +++ u-boot.lds.bak 2004-12-15 10:39:49.000000000 -0500 @@ -70,6 +70,7 @@ . = ALIGN(16); *(.rodata) *(.rodata1) + *(.rodata.str1.4) } .fini : { *(.fini) } =0 .ctors : { *(.ctors) }
Apparently, the toolchain I built wasn't handling the .rodata.str1.4 section correctly, it wasn't being subsumed into the .text section. Instead it was at some low address. This caused the objcopy command to try and pad a large number of bytes. I'm still curious as to why the toolchain in ELDK-3.1 was able to build the u-boot.bin file without this change in the linker script. Whose responsibility is it to properly handle the reallocation of the ".rodata.str1.4" section? Is that a proper question?
regards, Andrew
Andrew Reusch wrote:
Apparently, the toolchain I built wasn't handling the .rodata.str1.4 section correctly, it wasn't being subsumed into the .text section. Instead it was at some low address.
What I said was wrong. Is it correct to say that the ".rodata.str1.4" section is realigned or relocated to be part of the ".data" sections by the linker?
In message 41C08298.1070502@wiline.com you wrote:
What I said was wrong. Is it correct to say that the ".rodata.str1.4" section is realigned or relocated to be part of the ".data" sections by the linker?
I'd expect to see it as part of the ".rodata" section, which the linker script adds together with ".data" etc.
Best regards,
Wolfgang Denk
participants (2)
-
Andrew Reusch -
Wolfgang Denk