[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Prafulla Wadaskar]

> -----Original Message-----
> From: Simon Kagstrom [mailto:simon.kagstrom at netinsight.net] 
> Sent: Monday, September 07, 2009 11:54 AM
> To: Wolfgang Denk
> Cc: u-boot at lists.denx.de; Prafulla Wadaskar; Jean-Christophe 
> PLAGNIOL-VILLARD
> Subject: Re: [U-Boot] [PATCH] ARM: compiler options cleanup - 
> improve tool chain support
> 
> On Fri, 04 Sep 2009 22:05:45 +0200
> Wolfgang Denk <wd at denx.de> wrote:
> 
> > >   nand_bbt: Can't scan flash and build the RAM-based BBT
> > >   Net:   egiga0
> > >   88E1116 Initialized on egiga0
> > >   Hit any key to stop autoboot:  0 
> > >   Marvell>> 
> > > 
> > > The 4.1 version just hangs on the NAND printout. I've 
> tested both with
> > > USE_PRIVATE_LIBGCC=yes and USE_PRIVATE_LIBGCC unset, and 
> get the same
> > > results.
> > 
> > Did you make any progress an analyzing the cause of the issue?
> 
> Well, I sent a patch "[PATCH, RFC] Make arm926ejs use -march=armv5t to
> avoid problems with EABI", which corrects this for me, although I'd
> like some input on if it really makes any sense.
I have tested this with Sheevaplug, this patch even works well for me too.
The Kirkwood specification says that the core is armv5te compliant
But this change is global, applicable for all arm926ejs based SoC which isn't relevant too.
Do anybody have similar test results with other processors?

Since this is very specific NAND
How about looking into NAND code?

Regards..
Prafulla . .
> 
> The main difference I see between the two binaries is the use of
> ldrd/strd instructions, which comes with the "e"-version of armv5t.
> Obviously, that shouldn't by itself produce broken binaries, so
> something is still fishy here.
> 
> // Simon
> 
>