[U-Boot-Users] [RFC] NAND Flash
r-woodruff2 at ti.com
Tue Apr 27 14:39:59 CEST 2004
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
> 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.
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.
> 5. What kind of bad block management options would you like? I'm
> of implementing a bad block detection mechanism which would erase
> 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...
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
More information about the U-Boot