From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pantelis Antoniou Date: Tue, 27 Apr 2004 15:42:54 +0300 Subject: [U-Boot-Users] [RFC] NAND Flash In-Reply-To: <71555548814716479478431542AA5F8ADF8AE1@dlee2k04.ent.ti.com> References: <71555548814716479478431542AA5F8ADF8AE1@dlee2k04.ent.ti.com> Message-ID: <408E554E.7080004@intracom.gr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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