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
next prev parent 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 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.