В Пнд, 25/10/2010 в 22:35 +0200, Lars-Peter Clausen пишет: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gennady Kupava wrote: > > В Пнд, 25/10/2010 в 18:24 +0300, Vasily Khoruzhick пишет: > >> On Monday 25 October 2010 18:13:13 Martix wrote: > >> > >>> I read on #openmoko-cdevel few months ago that hardware NAND ECC is > >>> buggy. > > > > Here is archive of openmoko-cdevel: > > > >> What changed? Was it only rumor or SW bug? > >> > >> It's buggy on some s3c2410 CPUs, it's bug free on s3c2442, but ECC layout > >> is a > >> bit weird :) > > > > But ECC calculations for HW ECC and SW ECC are same? In-kernel > > implementation is ok? So... need to investigate how to turn it on. > > > > Gennady. > > > > > > Pretty simple: boot with hardware_ecc=1 > > But I think the ecc layout is different between HW and SW ECC, so you'll > probably > need to turn on HW ECC in u-boot as well. >
Thanks for suggestion, i tested it. Seem it works very well. And yes, it's just bootloader that do not support it. So, i just backup my qtmoko, enabled ecc in kernel in bootloader, reformat my / partition on flash, copy qtmoko back, and it works very well. In-kernel support seem fine, i am using it for 2 days and it's working well. I did some tests, seem ubifs with zlib, in reading urandom data (same for each test of course) test speed is increased from 3.9Mb/s to 4.2Mb/s while using hw ecc. My plan is to add support of hw ecc to u-boot: may be port from linux kernel of use some patches for u-boot floating around. Btw, also i've found that ubifs contains additional crc check, which can be disabled (while reading only), raising speed from 3.7Ms/s to 3.9Mb/s. (mount option no_chk_data_crc or kernel option 'rootflags=no_chk_data_crc') Suggest to remove that crc, as we already have ecc and write verify turned on. Such sad read speed in general caused by zlib, according to this tab: http://www.linux-mtd.infradead.org/misc.html#L_ubifs_compr it should be much better with lzo, but i can understand value of free space :) regards, Gennady.
