Hi Tom,
On Thu, 10 Oct 2013 18:52:57 -0400, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 06:10 PM, Scott Wood wrote:
On Thu, 2013-10-10 at 15:18 -0400, Tom Rini wrote:
On 10/10/2013 03:00 PM, Albert ARIBAUD wrote:
On Thu, 10 Oct 2013 17:52:14 +0200, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Tom,
On Thu, 10 Oct 2013 07:45:17 -0400, Tom Rini trini@ti.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 04:12 AM, Albert ARIBAUD wrote: > Hi Tom, > > On Wed, 9 Oct 2013 21:45:25 -0400, Tom Rini trini@ti.com wrote: > >> On Wed, Oct 09, 2013 at 01:29:55PM -0500, Scott Wood wrote: >> >>> Sorry for the lateness, but here are some MTD/UBI bugfixes. They've >>> been acked by Stefan Roese. >>> >>> The following changes since commit b770e88a6c2548727f0d57a3e9e8bb0830f977b5: >>> >>> Fix number base handling of "load" command (2013-10-07 15:54:18 -0400) >>> >>> are available in the git repository at: >>> >>> git://git.denx.de/u-boot-nand-flash.git master >>> >>> for you to fetch changes up to cc734f5ab26134e5e8d57c34edc257c89ac5b1d2: >>> >>> cmd_ubi: add write.part command, to write a volume in multiple parts (2013-10-09 12:52:22 -0500) >>> >>> ---------------------------------------------------------------- >>> Paul Burton (4): >>> mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN >>> cmd_mtdparts: use 64 bits for flash size, partition size & offset >>> cmd_ubi: use int64_t volume size for 'ubi create' >>> cmd_ubi: add write.part command, to write a volume in multiple parts >> >> OK, problem: >> Author: Paul Burton paul.burton@imgtec.com >> Date: Wed Sep 4 15:16:57 2013 +0100 >> >> cmd_mtdparts: use 64 bits for flash size, partition size & offset >> >> Causes a number of platform such as am3517_crane to fail to build with >> recent toolchains with errors such as: >> /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/arm-linux-gnueabihf-ld.bfd: >> error: >> /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/libgcc.a(bpabi.o) >> uses VFP register arguments, u-boot does not >> >> Which we need to sort out, one way or another. Albert, any quick ideas? > > Builds OK on my side, both nand-flash/master and a merge of nf/master > and u-boot/master, with gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) > > Tom, can you specify which toolchain shows the issue?
Both ELDK 5.3 and Linaro 2013.03 (one TI has picked for some things) do the above. ELDK 5.2 is OK
I'll test with ELDK5.3 in about an hour.
I've installed eldk-eglibc-i686-arm-toolchain-gmae-5.3.sh and can build am3517_crane on both nand-flash/master as well as on a merge of u-boot/master and nand-flash/master
Here we go, armhf toolchains trigger this problem because, I suspect, we aren't enforcing a flag to say "no, really, no hfp here" or similar.
Any idea why this patchset triggers it? Does the 64-bit stuff cause something from libgcc to be used that previously wasn't? There is some open-coded 64-bit division, but it's by a power of two so GCC should convert it to a shift (and the ability to do 64-bit shifts was already required by print_size()).
I'm not sure what parts of this math exactly cause things to go all nutty, but I suspect the answer is that we should be enforcing
- -msomething or another than hf defaults to using (un)setting.
Ok, trying with the ARMhf toolchain.
Amicalement,