Subject: Re: How to do "low-level format" on NAND MTD partiton? - msg#00002List: linux.file-systems.yaffs> Hi, I'm using a 4GB(4 x 1GB NAND chips) NAND partition on my at91rm9200 ARM > board, recently, I found half of my NAND eraseblocks were reported as "bad > block" by yaffs2(v1.59, v1.48) at mount time. I think those blocks must be > marked "BAD" by mistake, because those NAND chips are quite new and show > few bad blocks by MTD driver at boot time: > > > As we can see, the first two NAND chips are reported correctlly, but the > last two chips are reported 99% bad blocks, but the freespace of 4GB > partiton is 3.5GB NOT 2GB: > > ARM nand]# du > 2 ./lost+found > 4 . > [ARM nand]# df > Filesystem 1k-blocks Used Available Use% Mounted on > tmpfs 14984 4 14980 0% /dev > /dev/mtdblock6 4194176 620032 3574144 15% /mnt/nand > > I have used nand_erase to erase entire NAND partiton but the problem > remains. > Is it a yaffs bug? If it's not, how can I low-level format it (to clear > those bad block marks) ? The bad block marker position depends on flash page size/MTD version/yaffs version, but is normally OOB byte 5 for 512b page/yaffs1 and OOB byte 0 for 2K nand/yaffs2. 0xFF is good, anything else is bad. All the normal flash utils will respect these markers and refuse to write such blocks so to fix this you need to hack the tools a little. It is easy to just go through and set them all to 'OK', but beware that there are a few that probably _are_ bad so you really want something (like yaffs) so read and write it all to check for genuine failures and mark accordingly. Your problem could be caused by a nand driver bug which is doing the wrong thing for the last 2 chips (i.e. messing up the oob layout), or it could be due to some previous driver bug which caused all writes to fail and get the blocks marked bad accordingly. Maarking them all good again is a sensible thing to try at this stage. Just pass over all the blocks, erasing them, ignoring any bad-block checking, which will normally be present. There is a (n unecessarily complicated) example here: http://balloonboard.org/cgi-bin/viewcvs.cgi/balloon/branches/bootldr36-pxa-sa1100/nand/nand_base.c?rev=104&view=markup (grep for 'force_erase') the nand-utils probably have an example that is much simpler. The above is boot-loader code so can be run without userspace (but that bootloader needs gcc 2.95 to compile properly so I certainly don't recommend you actually use it :-) I just happen to be familiar. Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/
Thread at a glance:
Previous Message by Date: (click to view message preview)Percent usage affects write performanceHello, I'm run into problem with yaffs2 usage. When yaffs2 was only created(0% usage), I have write performance about ~1Mb/sec. When usage increased to 40-50%, I have only 450-500Kb/sec. When usage increased to 95-99%, it's only 50-90Kb/sec. :-() My test is very simple, just copy 1Mb file from mem to yaffs2: time cp /test.txt /usr/local /usr/local is yaffs2, / - is initramfs. Is there any reason for that? Maybe it's some GC related things and it's normal behaviour? -- Nickolay Vinogradov Next Message by Date: click to view message previewRe: Percent usage affects write performanceOn Friday 06 April 2007 04:53, ÐÐÐÐÐÐÐ Ð. ÐÐÐÐÐÑÐÐÐÐ wrote: > Hello, > > I'm run into problem with yaffs2 usage. > When yaffs2 was only created(0% usage), I have write performance about > ~1Mb/sec. > When usage increased to 40-50%, I have only 450-500Kb/sec. > When usage increased to 95-99%, it's only 50-90Kb/sec. :-() > > My test is very simple, just copy 1Mb file from mem to yaffs2: > time cp /test.txt /usr/local > > /usr/local is yaffs2, / - is initramfs. > > Is there any reason for that? Maybe it's some GC related things and it's > normal behaviour? Yes it is GC causing this. Depending on how stuff is written to the fs, the GC sometimes has to work much harder to get erased space to write. It seems the GC could do with some exploration to look for some improvements. -- Charles Previous Message by Thread: click to view message previewHow to do "low-level format" on NAND MTD partiton?Hi, I'm using a 4GB(4 x 1GB NAND chips) NAND partition on my at91rm9200 ARM board, recently, I found half of my NAND eraseblocks were reported as "bad block" by yaffs2(v1.59, v1.48) at mount time. I think those blocks must be marked "BAD" by mistake, because those NAND chips are quite new and show few bad blocks by MTD driver at boot time: NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit) 4 NAND chips detected Scanning device for bad blocks Bad eraseblock 1422 at 0x0b1c0000 Bad eraseblock 3085 at 0x181a0000 Bad eraseblock 6618 at 0x33b40000 Bad eraseblock 7773 at 0x3cba0000 Bad eraseblock 8055 at 0x3eee0000 Bad eraseblock 8785 at 0x44a20000 Bad eraseblock 12568 at 0x62300000 Bad eraseblock 13067 at 0x66160000 Bad eraseblock 13431 at 0x68ee0000 Bad eraseblock 14546 at 0x71a40000 Bad eraseblock 15241 at 0x77120000 Bad eraseblock 15525 at 0x794a0000 Bad eraseblock 16075 at 0x7d960000 Bad eraseblock 24212 at 0xbd280000 Bad eraseblock 25755 at 0xc9360000 Bad eraseblock 28638 at 0xdfbc0000 Bad eraseblock 28639 at 0xdfbe0000 Bad eraseblock 28704 at 0xe0400000 Bad eraseblock 29231 at 0xe45e0000 Bad eraseblock 29573 at 0xe70a0000 Bad eraseblock 29892 at 0xe9880000 Bad eraseblock 30116 at 0xeb480000 Bad eraseblock 32735 at 0xffbe0000 Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit": 0x00000000-0xfffe0000 : "NAND Data Storage" The flowing badblocks are reported by yaffs2: ... find next checkpt block: search: block 32765 oid 0 seq 0 eccr 0 find next checkpt block: search: block 32766 oid 0 seq 0 eccr 0 find next checkpt block: search: block 32767 oid 0 seq 0 eccr 0 found no more checkpt blocks checkpoint byte count 0 restore exit: isCheckpointed 0 block 1423 is bad block 3086 is bad block 6619 is bad block 7774 is bad block 8056 is bad block 8786 is bad block 12569 is bad block 13068 is bad block 13432 is bad block 14547 is bad block 15242 is bad block 15526 is bad block 16076 is bad block 16385 is bad <- first bad block of last two chips block 16386 is bad block 16388 is bad block 16389 is bad block 16390 is bad ... block 32737 is bad block 32738 is bad block 32739 is bad block 32742 is bad block 32743 is bad block 32745 is bad block 32746 is bad block 32747 is bad block 32750 is bad block 32752 is bad block 32753 is bad block 32755 is bad block 32756 is bad block 32758 is bad block 32759 is bad block 32760 is bad block 32761 is bad block 32763 is bad block 32764 is bad block 32765 is bad block 32766 is bad As we can see, the first two NAND chips are reported correctlly, but the last two chips are reported 99% bad blocks, but the freespace of 4GB partiton is 3.5GB NOT 2GB: ARM nand]# du 2 ./lost+found 4 . [ARM nand]# df Filesystem 1k-blocks Used Available Use% Mounted on tmpfs 14984 4 14980 0% /dev /dev/mtdblock6 4194176 620032 3574144 15% /mnt/nand I have used nand_erase to erase entire NAND partiton but the problem remains. Is it a yaffs bug? If it's not, how can I low-level format it (to clear those bad block marks) ? Thanx. _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ Next Message by Thread: click to view message previewPercent usage affects write performanceHello, I'm run into problem with yaffs2 usage. When yaffs2 was only created(0% usage), I have write performance about ~1Mb/sec. When usage increased to 40-50%, I have only 450-500Kb/sec. When usage increased to 95-99%, it's only 50-90Kb/sec. :-() My test is very simple, just copy 1Mb file from mem to yaffs2: time cp /test.txt /usr/local /usr/local is yaffs2, / - is initramfs. Is there any reason for that? Maybe it's some GC related things and it's normal behaviour? -- Nickolay Vinogradov
Web Hosting Reviews from OSDir.com Sister Site iBizWebHosting.com
|
|
