RE: [U-Boot-Users] [RFC] NAND Flash
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.
I'm asking for any people currently working with NAND to comment on the following points:
- 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.
- 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.
- Do you use it as a raw device without employing ECC? Do you understand the implications?
Raw only for development.
- 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.
- 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
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! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
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:
- 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.
- 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.
- Do you use it as a raw device without employing ECC? Do you
understand the implications?
Raw only for development.
- 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.
- 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
In message 408E554E.7080004@intracom.gr you wrote:
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.
Please remember what environment variables are intended for. This seems not to be the case here. YMMV.
Best regards,
Wolfgang Denk
participants (3)
-
Pantelis Antoniou -
Wolfgang Denk -
Woodruff, Richard