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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox