[U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem

[Anton Wöllert]

I've got the same problem with binutils 2.16 and gcc 3.4.4. also binutils 
2.16.91.0.1 doesn't work right.

>  > 
>  > I used to compile U-Boot with ELDK, but I currently need to work with
>  > newer toolchain :
>  >  - binutils-2.16
>  >  - gcc-3.4.3
>  
>  This looks line a binutils problem, then. May I ask why you  have  to
>  use binutils-2.16 ?

May I ask you why it should not be used? How to recover bugs, if people just 
use older software?

>  
>  And which exact board are we talking about?
>  
>  > The "__u_boot_cmd_start" symbol value, generated with this new
>  > toolchain, is wrong (U-Boot crashes when relocating the command
>  > table).
>  
>  Can you please provide exact data, like the differences  between  the
>  System.map  and  the  u-boot.map  files  when using binutils-2.16 and
>  another, working version of binutils? [Please use the _same_  version
>  of GCC for this comparison.]
>  
>  > There are two new sections between "__u_boot_cmd_start" and
>  > ".u_boot_cmd" address :
>  >  - .data.rel.local
>  >  - .data.rel
>  
>  Can you please show exactly what happens?

The above, i couldn't acknowledge, but u-boot definitly hangs _after_ 
relocating to memory. it will dump 'Now running in RAM at .....'. But then it 
hangs. After relocating, it tries to manually relocate the command table. But 
that doesn't work. Don't know why, but with the patch it works.
Obviously 

	__u_boot_cmd_start = .;
	.u_boot_cmd : { *(.u_boot_cmd) }
	__u_boot_cmd_end = .;

and

	__u_boot_cmd_start = ADDR(.u_boot_cmd);
	.u_boot_cmd : { *(.u_boot_cmd) }
	__u_boot_cmd_end = .;

should be the same. However, this should be a binutils bug or the linker 
script voodoo that is done with the first script above isn't really valid. 
Maybe .u_boot_cmd gets misalligned. Maybe i should try to DEBUG(& 
__u_boot_cmd_start) in both (the patched and unpatched) versions to see, 
where it points, or maybe objdump show more. Btw. this happens on the tqm8xx 
board. Thanks to Vincent for recovering that, that saved me a lot of time...

kind regards

Anton Wöllert