[U-Boot-Users] [RFC] NAND Flash

[Pantelis Antoniou]

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