From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Holler <holler@ahsoftware.de>
Date: Thu, 28 Oct 2010 11:31:49 +0200
Subject: [U-Boot] Most ARM CPU's have buggy clear_bss?
In-Reply-To: <4CC93C74.6050309@ahsoftware.de>
References: <AANLkTimP9_Am6PKt8YchW8Mrj8LWujorXs=f+RtfREJ4@mail.gmail.com>
	<4CC93C74.6050309@ahsoftware.de>
Message-ID: <4CC94305.8060001@ahsoftware.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Am 28.10.2010 11:03, schrieb Alexander Holler:
> Hello,
>
> Am 27.10.2010 09:26, schrieb Darius Augulis:
>
>  > the code for clearing bss section for most ARM cores looks like this
>  > or very similar:
>
> ... [some code from start.S]
>
> Currently I'm analyzing the same problem (on a kirkwood based hw). It
> turns out not to be a problem of clear_bss, but a problem of the
> relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along
> with binutils 2.20.1 and it seems that some stuff is not relocated. It
> looks like the BSS before relocation is used (e.g. for nand_chip in
> drivers/mtd/nand.c), but the BSS after relocation might be cleared (in
> start.S).
>
> I assume it's because of some fixups start.S doesn't know about. But I
> don't know anything about those fixups, and have to read. So I still
> have no solution.
>
> Just as a pointer.

To verify the problem:

Add

#define DEBUG

in top of arch/arm/lib/board.c

and

printf("nand_chip: %p\n",, &nand_chip[0]);

in nand_init() in drivers/mtd/nand/nand.c

and have a look at the output when u-boot comes up.

Regards,

Alexander