public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC] NAND Flash
Date: Tue, 27 Apr 2004 15:42:54 +0300	[thread overview]
Message-ID: <408E554E.7080004@intracom.gr> (raw)
In-Reply-To: <71555548814716479478431542AA5F8ADF8AE1@dlee2k04.ent.ti.com>

Woodruff, Richard wrote:

>Hello Pantelis,
>
>I recently used that code a quite a bit...I probably have a few changes
>which I probably should have sent back in...there were some problems
>with some operations to the oob, and one bit about bad blocks which we
>enhanced.  I'll send you version of the code for you to compare against
>later.
>
>
TIA.

>>I'm asking for any people currently working with NAND to comment
>>on the following points:
>>
>>1. Do you read and write the NAND at arbitrary offsets?
>>   That means not in page boundaries.
>>
>
>No not usually.  We generally only used it for catastrophic recovery. In
>that case we would write a file system image out.  Because it is fairly
>slow, I usually had a separate kernel partition.  The board I used to
>use had a NOR u-boot.  At reset with would jffs2 scan the first
>partition and recover the kernel (which had mtd+nand) built in.  It
>would load and start this kernel.  This kernel mounted a read only root
>system partition in NAND, and a r/w user partition.  Updates were
>expected to happen at the kernel level...if they failed badly, you could
>send an Image to u-boot which could then re-burn the entire partitions.
>
>
That sounds reasonably safe.

>In newer processors which TI is doing, we actually can drop the NOR all
>together.  The processor's have hardware acceleration and enough
>microcode in mask rom to boot from a single external NAND.  U-boot will
>be supported in these systems.
>
>
>>2. Do you use the NAND boot command? It can be replaced by a copy and
>>   bootm sequence.
>>
>
>Only for development.  It's a bit more quick to burn in a raw image, but
>also not very safe.   I think some manufactures may guarantee that some
>number of the first blocks are good.  If you don't write them very much
>you are probably pretty safe.
> 
>
>>3. Do you use it as a raw device without employing ECC? Do you
>>   understand the implications?
>>
>Raw only for development.
>
>
>>4. What kind of filesystem do you use? JFFS2 & YAFS have different OOB
>>   placement of ECC and status bits?
>>
>We used JFFS2 and NAND.  Actually, we paid Woodhouse to get JFFS2+NAND
>support up to par.  Current snapshots on his CVS seem pretty safe.
>
That was my main impetus. I updated from a recent CVS snapshot
and noticed the disrepancies. I'm thinking in putting the oob placement
in a environment variable, just to be able to follow the Linux MTD.

> 
>
>>5. What kind of bad block management options would you like? I'm
>>
>thinking
>
>>   of implementing a bad block detection mechanism which would erase
>>
>and
>
>>   test the whole chip for any bad blocks.
>>   Another command could also utilise ECC to detect borderline working
>>   pages and relocate them to avoid a permanent failure.
>>
>>Awaiting your input...
>>
>>Regards
>>
>>Pantelis
>>
>>
>>
>>
Regards

Pantelis

  reply	other threads:[~2004-04-27 12:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-27 12:39 [U-Boot-Users] [RFC] NAND Flash Woodruff, Richard
2004-04-27 12:42 ` Pantelis Antoniou [this message]
2004-04-27 14:13   ` Wolfgang Denk
  -- strict thread matches above, loose matches on Subject: below --
2004-04-27 13:52 Dave Ellis
2004-04-27 12:46 Woodruff, Richard
2004-04-27 12:44 ` Pantelis Antoniou
2004-04-27 11:46 VanBaren, Gerald
2004-04-27  7:42 Peter Billek
2004-04-27  7:45 ` Pantelis Antoniou
2004-04-27  7:08 Pantelis Antoniou
2004-06-06 21:55 ` Wolfgang Denk
2004-06-07  5:54   ` Pantelis Antoniou

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=408E554E.7080004@intracom.gr \
    --to=panto@intracom.gr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox