[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Andrew Reusch]

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

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Wolfgang Denk]

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.

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The people of Gideon have always believed that life is  sacred.  That
the  love  of  life  is  the  greatest  gift  ... We are incapable of
destroying or interfering with the creation of that which we love  so
deeply -- life in every form from fetus to developed being.
	-- Hodin of Gideon, "The Mark of Gideon", stardate 5423.4

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Andrew Reusch]

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

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is fluid ... like a river with currents, eddies, backwash.
	-- Spock, "The City on the Edge of Forever", stardate 3134.0

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Andrew Reusch]

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

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Andrew Reusch]

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

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Andrew Reusch]

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?

[U-Boot-Users] Advice about a problem compiling with alternative toolchain

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three things I always forget. Names, faces -  the  third  I
can't remember.                                         - Italo Svevo