From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 10 Oct 2013 18:52:57 -0400 Subject: [U-Boot] Pull request: nand flash In-Reply-To: <1381443015.7979.460.camel@snotra.buserror.net> References: <20131009182955.GA15296@home.buserror.net> <20131010014525.GL15917@bill-the-cat> <20131010101219.13c58b20@lilith> <5256934D.7070909@ti.com> <20131010175214.4da53f80@lilith> <20131010210005.7bf1485a@lilith> <5256FD92.1070800@ti.com> <1381443015.7979.460.camel@snotra.buserror.net> Message-ID: <52572FC9.3000904@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----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 >>> wrote: >>> >>>> Hi Tom, >>>> >>>> On Thu, 10 Oct 2013 07:45:17 -0400, Tom Rini 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 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 >>>>>>> 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. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSVy/JAAoJENk4IS6UOR1WgyIP+gIIF7gvWREeqfbtxt0jktj3 cDc0VsT5FHoIK7qVAmOxhRP7yhN62sSkQJJ8D8b71Vequ5bTiuuDlSs1qml6Rb2F bD4ivDCRSK/7RuE13XJOgSuUnhSEbXdWS5b5WzpHD4r9t+IM6vF03FVBx6Ob4h+Q x8jBZlNjDT+wmDmuSRhN0opIDmhj1+mPt66fkXap/ZsAqyNfHfyWdFIfnprH4JxT RYrtP57vPTELwSQJJY0IOYAw8y/JgMiOO4zkrh6AO87dwZtoRi3M2eV18qcEYjvz g9rHdXMpoaxIecicDgDY4Lnr0XT7phyKaFV1ZEUKxdC1CA1Lsc+LRsuAJFr1s6wB QZZH9ckmJgeYWRmF6jP5qpDCVzzBkZn5D0Nq5gOrkcbaPVNpUQ9//7aEiwWLULDu rhas3MrT+m1MD8OO6LTZG5zn3MYhm8Ih7NHLFOp7W+AZuZlZorjW/+XLHe+UWtKU caExJ4+zXOOjUl7Tz3EWEVBdpM3ikYleHTD/pFbMyP9PpR/Y0o6H8X7VU/Xz8L9v AnkCWdlhavD9NMAIAj/4PuyVTPjUIDWIH7CCk4UcrgFSJaXWQX+2sPIkE+IgiVO4 Cd9UvEsFVcY82uvbWSXLdx/lfa9uIhBqz7JGcseB6Ch20elWrv0uqpGTmPJm5J+d bpdD+ilktDFpS857eMyW =BKAP -----END PGP SIGNATURE-----