From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel Benoit Date: Thu, 8 Feb 2007 09:34:27 +0100 Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK In-Reply-To: <200702080706.48809.sr@denx.de> References: <03d701c74b14$07ec1510$c58e11d4@atmel.com> <200702080706.48809.sr@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Good morning! What version of the AT91SAM9260EK u-boot code are you referring to? I am using u-boot-1.1.5_atmel_1.2 from the Atmel ftp site. Is there a more recent version available? Are there any plans to add the at91sam9260ek support to the main branch of u-boot (latest version 1.2). In looking through the 1.1.5 Atmel u-boot code I see that nand_bbt.c is used to map out bad blocks marked by the manufacturer. I can write my code to nand from external SAM-BA tool and boot without any problems. Has anyone tried booting from JFFS2 nand within u-boot? The problem that I was having with the NAND flash on my AT91SAM9260EK board is related to the fact that the hw ECC controller in the 9260 uses the first four bytes of out of bounds space after each page to store an error correction/verification number. The Samsung flash on my board uses the first byte of oob space in the first two pages of a block to mark that it is bad. If the byte is not FF then the mfg has marked the block as bad and it should never be used. When linux mtd starts up it looks for mfg bad blocks and removes them from the available list of nand blocks. Thus any page which contains data is excluded. Looking around at other nand flash devices I found that some use both offsets 0 and 5 in the oob space to mark bad blocks. We plan to use such a nand flash on our custom board. I hope that Atmel will do the same on future revisions of its AT91SAM9260EK board. My work around for now is to ignore mfg bad blocks and hope that they get caught by the ECC verification code. Mfg bad block info has already been overwritten on my flash chip by the ECC data. Does anyone know if the Atmel SAMBA tool does any bad block verification when programming nand flash? It seems to be writing the 4 byte ECC code in the oob space. Is it also marking mfg bad blocks? If so, at which offset into the oob space? Michel On 2/8/07, Stefan Roese wrote: > On Thursday 08 February 2007 00:17, Ulf Samuelsson wrote: > > > Has anyone used the at91_nand driver on the AT91SAM9260EK? > > > > > > I get bad erase blocks on every block that contaions data (written to > > > nand flash with SAM-BA). Seems like the read_oob (read out of bounds > > > area) function is returning data from the in bounds area. > > > > > > U-boot configs the nand flash to use hw ecc (syndrome) whereas the > > > at91_nand seems to be setup to use soft ecc. > > > > According to recent conversations on U-Boot mailing list > > U-boot can do a raw copy of a flash file system, but nothing more. > > (Correct me if I have misunderstood) > > Yes. But this copy is bad block aware. > > > This means that if there are faulty pages in the NAND flash, you are dead. > > No. Bad blocks are handled correctly. > > Best regards, > Stefan > > ===================================================================== > DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk > Office: Kirchenstr. 5, D-82194 Groebenzell, Germany > ===================================================================== >