Hi Pierluigi Can you send the output of your *'mtdinfo -a '.* and what version of mtd-utils you are using? 'versions less than 1.5.1 have a bug with MLC nands'
On Thu, Dec 25, 2014 at 7:54 PM, Pierluigi Scacchi <[email protected]> wrote: > > > Il giorno mercoledì 24 dicembre 2014 00:07:25 UTC+1, Michal Suchanek ha > scritto: > >> On 23 December 2014 at 16:13, <[email protected]> wrote: >> > Il giorno venerdì 19 dicembre 2014 05:53:18 UTC+1, Yassin Jaffer ha >> scritto: >> >> Hi Michal >> >> This was answered previously by Brezillon . Please search the mailing >> list.You have to force bad block erasure to get rid of AW's libnand layout >> >> (which is overriding bad block markers). >> >> >> >> Please follow these steps: >> >> 1) apply this patch [1] >> >> 2) boot on your new kernel and launch >> >> $ flash_erase /dev/mtd0 0 0 >> >> 3) revert the patch >> >> 4) Boot on your new kernel >> >> >> >> Most of your bad blocks should be gone after that... >> >> >> >> [1]http://code.bulix.org/k2v1hx-87237 >> >> Yes K9GBG08U0A has two variants of the chip ID and maybe more... >> >> use some printk in the nand_base.c to get more accurate information >> about your nand. >> >> >> >> >> >> On Fri, Dec 19, 2014 at 7:44 AM, Michal Suchanek <[email protected]> >> wrote:On 18 December 2014 at 14:13, Henrik Nordström >> >> >> >> <[email protected]> wrote: >> >> >> >> > tor 2014-12-18 klockan 13:47 +0100 skrev Michal Suchanek: >> >> >> >> > >> >> >> >> >> Yes, that's what you can obviously do. If the ID listed in the >> >> >> >> >> datasheet and the ID read by the kernel does not agree put the ID >> read >> >> >> >> >> in the table. >> >> >> >> >> >> >> >> >> >> However, how is Joe User with a Chinese tablet supposed to add his >> NAND chip? >> >> >> >> > >> >> >> >> > If the chip supports JEDEC identification then it's supposedly >> >> >> >> > automatically configured.. sadly it seems most chineese tablets uses >> >> >> >> > non-JEDEC identified NAND chips. >> >> >> >> > >> >> >> >> > If not then one need to go thru the manual process of finding the >> >> >> >> > datasheet and try to find needed parameters from there which means >> >> >> >> > opening the device to find the NAND chip model, search the Internet >> for >> >> >> >> > a datasheet (if lucky), or find something usable in the Allwinner >> >> >> >> > drivers if you can find usable source version. >> >> >> >> > >> >> >> >> > >> >> >> >> >> If a Joe User sent us this datasheet can we fabricate an ID entry >> form >> >> >> >> >> that datasheet alone? How? >> >> >> >> > >> >> >> >> > Only if the datasheets lists usable identification strings, >> something >> >> >> >> > many get wrong even from well known NAND manufacturers. >> >> >> >> > >> >> >> >> >> If not should we add a patch to the kernel to always print the full >> >> >> >> >> ID? If so how can we believe *anything* in the datasheet if even >> >> >> >> >> something as simple and basic as chip ID is wrong? >> >> >> >> > >> >> >> >> > General timing data should be correct, but... honestly I have even >> seen >> >> >> >> > page size and OOB size being specified wrongly in datasheets. >> >> >> >> > >> >> >> >> > For many chips finding any reliable information is not easy. >> >> >> >> >> >> >> >> hmm, the sunxi nand driver has this: >> >> >> >> >> >> >> >> // NAND_CHIP_ID DieCnt SecCnt >> >> >> >> PagCnt BlkCnt OpOpt DatBlk Freq EccMode ReadRetry DDRType >> >> >> >> OperationPar >> >> >> >> { {0xec, 0xd5, 0x94, 0x29, 0xff, 0xff, 0xff, 0xff }, 1, 8, >> >> >> >> 128, 4096, 0x0008, 974, 30, 0, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9GAG08U0D >> >> >> >> { {0xec, 0xd5, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1, 16, >> >> >> >> 128, 2048, 0x0000, 950, 24, 2, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9GAG08U0E >> >> >> >> { {0xec, 0xd5, 0x94, 0x76, 0x54, 0xff, 0xff, 0xff }, 1, 16, >> >> >> >> 128, 2048, 0x0408, 950, 30, 2, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9GAG08U0E >> >> >> >> { {0xec, 0xd3, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1, 16, >> >> >> >> 128, 1024, 0x0000, 950, 24, 2, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9G8G08U0C >> >> >> >> { {0xec, 0xd7, 0x94, 0x76, 0xff, 0xff, 0xff, 0xff }, 1, 16, >> >> >> >> 128, 4096, 0x0088, 974, 30, 3, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9GBG08U0A >> >> >> >> { {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff }, 1, 16, >> >> >> >> 128, 4096, 0x0088, 974, 30, 3, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9GBG08U0A >> >> >> >> { {0xec, 0xde, 0xd5, 0x7A, 0x58, 0xff, 0xff, 0xff }, 2, 16, >> >> >> >> 128, 4096, 0x0888, 974, 30, 3, 0, 0, >> >> >> >> &PhysicArchiPara3 }, // K9LCG08U0A >> >> >> >> where 0x88 looks like NAND_MULTI_PROGRAM | NAND_RANDOM >> >> >> >> and >> >> >> >> 974 ValidBlkRatio; //the valid block >> >> >> >> ratio, based on 1024 blocks >> >> >> >> 30 AccessFreq; //the highest access >> >> >> >> frequence of the nand flash chip, based on MHz >> >> >> >> 3 EccMode; //the Ecc Mode for the >> >> >> >> nand flash chip, 0: bch-16, 1:bch-28, 2:bch_32 >> >> >> >> >> >> >> >> So there are two variants of the K9GBG08U0A chip ID there. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> Groups "linux-sunxi" group. >> >> >> >> To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> >> >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > Hello. >> > I have a cobieboard a10 with 4GB nand K9GBG08U0A. >> > I tried the kernel 3.18 nand. >> > I also followed the indications described by XXXX. >> > I still have many errors "Bad eraseblock ... No space left to write bad >> block table". >> >> This is expected. >> You need to apply the two patches that make the kernel ignore bad >> blocks, erase flash, and unapply patches. >> >> Presumably that gets rid of the bogus bad block markers. >> >> I did not try the patches. Rather I wanted to keep the bogus flash >> content so that I can add proper kernel option for ignoring these >> markers that could be set in DT or somewhere and test it. >> >> Should not be overly difficult but did not get to it so far. >> >> Such option is obviously needed so that devices can be upgraded from >> factory installed image to mainline image. >> >> The general idea is that when the option is set on a partition the >> kernel would initialize the MTD although all flash is marked bad but >> would flag it as unusable and only allow erasing it. >> >> > (flash_erase with kernel & a10 dts modified does not reduce them). >> > I try a series combination changing nand_ids.c >> > The proposed configuration for a 32 GB K9GBG08U0A not work for 4GB. >> > How can I fix it? >> > ids for 32G >> > {"K9GBG08U0A 32G 3.3V 8-bit" >> > .id = {{0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43}}, >> > SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO (40, >> SZ_1K), 0}, >> > >> > ids for 4G? >> >> It's 32gigabits ~ 4gigabytes, presumably. >> >> > >> > the kernel SunXi for this chip (4GB) contains a number of parameters >> that I have difficulty in translating: >> >> You can just ignore these if you get the complaint about bad blocks. >> The only interesting bit I found there so far is that the ID seems to >> be matched by 5 bytes so possibly more variants of the last byte >> exist. >> >> Thanks >> >> Michal >> > > > Hi all. > Resolved with > $ flash_erase -N /dev/mtd0 0 0 > > Now with nand kernel i see: > /dev/mtd0 > /dev/mtd0ro > /dev/mtd1 > /dev/mtd1ro > /dev/mtd2 > /dev/mtd2ro > > $ dmesg > [ 5.504107] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7 > [ 5.510466] nand: Samsung K9GBG08U0A 4GB 3.3V 8-bit > [ 5.515302] nand: 4096MiB, MLC, page size: 8192, OOB size: 640 > [ 5.710997] Bad block table not found for chip 0 > [ 5.768800] Bad block table not found for chip 0 > [ 5.773425] Scanning device for bad blocks > [ 5.828759] Bad eraseblock 0 at 0x0000000fe000 > [ 5.867883] Bad eraseblock 1 at 0x0000001fe000 > [ 5.902372] Bad eraseblock 2 at 0x0000002fe000 > [ 5.948928] Bad eraseblock 3 at 0x0000003fe000 > [ 6.020716] Bad eraseblock 6 at 0x0000006fe000 > [ 6.059723] Bad eraseblock 7 at 0x0000007fe000 > [ 6.988123] random: nonblocking pool is initialized > > I tried to use UBI FS on mtd2. But i have this problem. > A long series of this errors: > > [ 3653.750288] CPU: 0 PID: 846 Comm: ubiattach Not tainted 3.18.0-gigi+ #10 > [ 3653.757031] [<c0014440>] (unwind_backtrace) from [<c00115cc>] > (show_stack+0x10/0x14) > [ 3653.764775] [<c00115cc>] (show_stack) from [<c0539e7c>] > (dump_stack+0x88/0x98) > [ 3653.772023] [<c0539e7c>] (dump_stack) from [<c03653a0>] > (ubi_io_read+0x128/0x304) > [ 3653.779519] [<c03653a0>] (ubi_io_read) from [<c0365788>] > (ubi_io_read_ec_hdr+0x44/0x210) > [ 3653.787631] [<c0365788>] (ubi_io_read_ec_hdr) from [<c036a038>] > (ubi_attach+0x150/0x1368) > [ 3653.795849] [<c036a038>] (ubi_attach) from [<c035ff10>] > (ubi_attach_mtd_dev+0x648/0xc08) > [ 3653.803936] [<c035ff10>] (ubi_attach_mtd_dev) from [<c036144c>] > (ctrl_cdev_ioctl+0xcc/0x198) > [ 3653.812385] [<c036144c>] (ctrl_cdev_ioctl) from [<c00e80a0>] > (do_vfs_ioctl+0x3ec/0x5ac) > [ 3653.820395] [<c00e80a0>] (do_vfs_ioctl) from [<c00e8294>] > (SyS_ioctl+0x34/0x5c) > [ 3653.827710] [<c00e8294>] (SyS_ioctl) from [<c000e3e0>] > (ret_fast_syscall+0x0/0x30) > [ 3653.882994] UBI warning: ubi_io_read: error -74 (ECC error) while > reading 64 bytes from PEB 2503:0, read only 64 bytes, retry > [ 3653.927378] UBI warning: ubi_io_read: error -74 (ECC error) while > reading 64 bytes from PEB 2503:0, read only 64 bytes, retry > [ 3653.975933] UBI warning: ubi_io_read: error -74 (ECC error) while > reading 64 bytes from PEB 2503:0, read only 64 bytes, retry > [ 3654.020387] UBI error: ubi_io_read: error -74 (ECC error) while reading > 64 bytes from PEB 2503:0, read 64 bytes > > any idea ? > Thanks > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
