From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Reusch <andrew.reusch@wiline.com>
Date: Tue, 14 Dec 2004 14:04:10 -0500
Subject: [U-Boot-Users] Advice about a problem compiling with alternative
 toolchain
In-Reply-To: <20041214164319.55298C1430@atlas.denx.de>
References: <20041214164319.55298C1430@atlas.denx.de>
Message-ID: <41BF392A.908@wiline.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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