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.
>

-- 
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.

Reply via email to