From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton =?iso-8859-1?q?W=F6llert?= Date: Thu, 23 Jun 2005 10:15:45 +0200 Subject: [U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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