Hi all. Compiled 3:19 kernel-rc1 (https://github.com/wens/linux ) with dts/dtsi 3.18-nand. I now have a good needed results:
root@cubie:~# dmesg [ 5.574808] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7 [ 5.581167] nand: Samsung K9GBG08U0A 4GB 3.3V 8-bit [ 5.586089] nand: 4096 MiB, MLC, erase size: 1024 KiB, page size: 8192, OOB size: 640 [ 5.710328] Bad block table found at page 524160, version 0x05 [ 5.765223] Bad block table found at page 524032, version 0x05 [ 5.818924] nand_read_bbt: bad block at 0x000000000000 [ 5.824069] nand_read_bbt: bad block at 0x000000100000 [ 5.829269] nand_read_bbt: bad block at 0x000000200000 [ 5.834400] nand_read_bbt: bad block at 0x000000300000 [ 5.839554] nand_read_bbt: bad block at 0x000000400000 [ 5.844703] nand_read_bbt: bad block at 0x000000500000 [ 5.849833] nand_read_bbt: bad block at 0x000000600000 [ 5.854980] nand_read_bbt: bad block at 0x000000700000 [ 5.860109] nand_read_bbt: bad block at 0x000000800000 [ 5.865256] nand_read_bbt: bad block at 0x000000900000 [ 5.870385] nand_read_bbt: bad block at 0x000001000000 [ 5.875534] nand_read_bbt: bad block at 0x000001100000 [ 6.003147] 3 ofpart partitions found on MTD device K9GBG08U0A 4GB 3.3V 8-bit [ 6.010359] Creating 3 MTD partitions on "K9GBG08U0A 4GB 3.3V 8-bit": [ 6.016824] 0x000000000000-0x000000200000 : "boot0" [ 6.046632] 0x000000200000-0x000000400000 : "boot0-rescue" [ 6.090295] 0x000000400000-0x000100000000 : "main" root@cubie:~# ubiformat -s 8192 /dev/mtd2 root@cubie:~# ubiattach /dev/ubi_ctrl -m 2 -O 8192 root@cubie:~# ubimkvol /dev/ubi0 -N main -m root@cubie:~# mount -t ubifs ubi0:main /mnt root@cubie:~# dmesg [ 2043.252786] UBI-0: ubi_attach_mtd_dev:default fastmap pool size: 200 [ 2043.259221] UBI-0: ubi_attach_mtd_dev:default fastmap WL pool size: 25 [ 2043.265741] UBI-0: ubi_attach_mtd_dev:attaching mtd2 to ubi0 [ 2068.980031] UBI-0: scan_all:scanning is finished [ 2069.012442] UBI-0: ubi_attach_mtd_dev:attached mtd2 (name "main", size 4092 MiB) [ 2069.019909] UBI-0: ubi_attach_mtd_dev:PEB size: 1048576 bytes (1024 KiB), LEB size: 1032192 bytes [ 2069.028797] UBI-0: ubi_attach_mtd_dev:min./max. I/O unit sizes: 8192/8192, sub-page size 8192 [ 2069.037324] UBI-0: ubi_attach_mtd_dev:VID header offset: 8192 (aligned 8192), data offset: 16384 [ 2069.046097] UBI-0: ubi_attach_mtd_dev:good PEBs: 4080, bad PEBs: 12, corrupted PEBs: 0 [ 2069.054015] UBI-0: ubi_attach_mtd_dev:user volume: 1, internal volumes: 1, max. volumes count: 128 [ 2069.062977] UBI-0: ubi_attach_mtd_dev:max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 632176814 [ 2069.073756] UBI-0: ubi_attach_mtd_dev:available PEBs: 0, total reserved PEBs: 4080, PEBs reserved for bad PEB handling: 68 [ 2069.087090] UBI-0: ubi_thread:background thread "ubi_bgt0d" started, PID 840 [ 2081.562327] UBIFS: background thread "ubifs_bgt0_0" started, PID 844 [ 2083.425364] UBIFS: mounted UBI device 0, volume 0, name "main" [ 2083.431250] UBIFS: LEB size: 1032192 bytes (1008 KiB), min./max. I/O unit sizes: 8192 bytes/8192 bytes [ 2083.440576] UBIFS: FS size: 4124639232 bytes (3933 MiB, 3996 LEBs), journal size 33030144 bytes (31 MiB, 32 LEBs) [ 2083.450836] UBIFS: reserved for root: 4952683 bytes (4836 KiB) [ 2083.456677] UBIFS: media format: w4/r0 (latest is w4/r0), UUID AFE05BAF-A7FE-4CA6-94D7-FE153AE8D0E0, small LPT model root@cubie:~# df . . ubi0:main 3798064 28 3793200 1% /mnt root@cubie:~# touch file /mnt; ls -al /mnt total 4 drwxr-xr-x 2 root root 224 dic 25 19:50 . drwxr-xr-x 22 root root 4096 dic 1 13:58 .. -rw-r--r-- 1 root root 0 dic 25 19:49 file Il giorno giovedì 25 dicembre 2014 17:16:10 UTC+1, Pierluigi Scacchi ha scritto: > > 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]> >> 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.
