Hi Yassin, root@cubie:~# mtdinfo -a Count of MTD devices: 3 Present MTD devices: mtd0, mtd1, mtd2 Sysfs interface supported: yes
mtd0 Name: boot0 Type: mlc-nand Eraseblock size: 1048576 bytes, 1024.0 KiB Amount of eraseblocks: 2 (2097152 bytes, 2.0 MiB) Minimum input/output unit size: 8192 bytes Sub-page size: 8192 bytes OOB size: 640 bytes Character device major/minor: 90:0 Bad blocks are allowed: true Device is writable: true mtd1 Name: boot0-rescue Type: mlc-nand Eraseblock size: 1048576 bytes, 1024.0 KiB Amount of eraseblocks: 2 (2097152 bytes, 2.0 MiB) Minimum input/output unit size: 8192 bytes Sub-page size: 8192 bytes OOB size: 640 bytes Character device major/minor: 90:2 Bad blocks are allowed: true Device is writable: true mtd2 Name: main Type: mlc-nand Eraseblock size: 1048576 bytes, 1024.0 KiB Amount of eraseblocks: 4092 (4290772992 bytes, 4.0 GiB) Minimum input/output unit size: 8192 bytes Sub-page size: 8192 bytes OOB size: 640 bytes Character device major/minor: 90:4 Bad blocks are allowed: true Device is writable: true root@cubie:~# mtdinfo --version mtdinfo 1.5.1 The version seem correct. I have an Debian jessie/testing distribution. Thanks. Il giorno giovedì 25 dicembre 2014 13:02:03 UTC+1, Yassin Jaffer ha scritto: > > 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] > <javascript:>> 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] <javascript:>. >> 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.
