[U-Boot] Pull request: nand flash

[Albert ARIBAUD]

On Fri, 11 Oct 2013 09:11:52 +0200, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:

> Hi Tom,
> 
> On Thu, 10 Oct 2013 18:52:57 -0400, Tom Rini <trini at 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 at aribaud.net> wrote:
> > >>>
> > >>>> Hi Tom,
> > >>>>
> > >>>> On Thu, 10 Oct 2013 07:45:17 -0400, Tom Rini <trini at 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 at 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 at 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.

Even using the gnueabihf ELDK 5.3 toolchain, I still can build
am3517_crane with no problem.

Amicalement,
-- 
Albert.