-----Original Message----- From: Simon Kagstrom [mailto:simon.kagstrom@netinsight.net] Sent: Monday, September 07, 2009 11:54 AM To: Wolfgang Denk Cc: u-boot@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@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