Il giorno mercoledì 24 dicembre 2014 00:07:25 UTC+1, Michal Suchanek ha scritto: > > On 23 December 2014 at 16:13, <scac...@gmail.com <javascript:>> 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 <hram...@gmail.com> > wrote:On 18 December 2014 at 14:13, Henrik Nordström > >> > >> <hen...@henriknordstrom.net> 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 linux-sunxi...@googlegroups.com. > >> > >> 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
