All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michel Benoit <murpme@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
Date: Thu, 8 Feb 2007 09:34:27 +0100	[thread overview]
Message-ID: <c88e466f0702080034l33c06d91tdcf7503cd1ea2d83@mail.gmail.com> (raw)
In-Reply-To: <200702080706.48809.sr@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 <sr@denx.de> 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
> =====================================================================
>

  reply	other threads:[~2007-02-08  8:34 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c88e466f0702050752t16c18251gcddf40a7ec95469@mail.gmail.com>
2007-02-07 23:17 ` [U-Boot-Users] AT91 NAND om AT91SAM9260EK Ulf Samuelsson
2007-02-08  6:06   ` Stefan Roese
2007-02-08  8:34     ` Michel Benoit [this message]
2007-02-08 19:25       ` Ulf Samuelsson
2007-02-08 20:58         ` Haavard Skinnemoen
2007-02-08 22:20           ` Ulf Samuelsson
2007-02-09 15:45             ` Haavard Skinnemoen
2007-02-09 19:11               ` Ulf Samuelsson
2007-02-09 19:54                 ` Haavard Skinnemoen
2007-02-09 19:39               ` Wolfgang Denk
2007-02-09 22:18                 ` Ulf Samuelsson
2007-02-09 22:58                   ` Haavard Skinnemoen
2007-02-09 23:20                     ` Ulf Samuelsson
2007-02-09 23:42                       ` Haavard Skinnemoen
2007-02-10  0:10                         ` Ulf Samuelsson
2007-02-10  1:18                       ` Wolfgang Denk
2007-02-10  9:05                         ` Ulf Samuelsson
2007-02-10  7:23                     ` Stefan Roese
2007-02-10  1:15                   ` Wolfgang Denk
2007-02-10  7:32                     ` Stefan Roese
2007-02-10  9:29                     ` Ulf Samuelsson
2007-02-10  1:53       ` Ken Watson
     [not found] <mailman.5069.1170973304.16820.u-boot-users@lists.sourceforge.net>
2007-02-08 22:57 ` Ivan Kuten
     [not found] <mailman.12584.1171099992.16820.u-boot-users@lists.sourceforge.net>
2007-02-10 20:31 ` Ivan Kuten
2007-02-11 16:43   ` Ulf Samuelsson
2007-02-11 18:04     ` Haavard Skinnemoen
2007-02-11 19:42       ` Ulf Samuelsson
2007-02-11 20:23         ` Haavard Skinnemoen
2007-02-11 20:29           ` Ulf Samuelsson
2007-02-11 20:54             ` Haavard Skinnemoen
2007-02-11 21:10           ` Wolfgang Denk
2007-02-11 21:39             ` Ulf Samuelsson
2007-02-11 23:45               ` Wolfgang Denk
2007-02-12  0:26                 ` Ulf Samuelsson
2007-02-12 15:18                   ` Haavard Skinnemoen
2007-02-12 18:40                     ` Ulf Samuelsson
2007-02-12 19:36                       ` Stefan Roese
2007-02-12 19:37                       ` Haavard Skinnemoen
2007-02-12 20:05                         ` Ulf Samuelsson
2007-02-11 21:54       ` Ulf Samuelsson
2007-02-11 11:49 Michel Benoit
2007-02-11 16:20 ` Ulf Samuelsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c88e466f0702080034l33c06d91tdcf7503cd1ea2d83@mail.gmail.com \
    --to=murpme@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.