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".
(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?
the kernel SunXi for this chip (4GB) contains a number of parameters that I
have difficulty in translating:
NAND_CHIP_ID = {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff} (OK)
DieCnt = 1
SecCnt = 16
PagCnt = 128
BlkCnt = 4096
OpOpt = 0x0088
DatBlk = 974
Freq = 30
EccMode = 3
ReadRetry = 0
DDRType = 0
& PhysicArchiPara3 =
static struct __OptionalPhyOpPar_t PhysicArchiPara3 =
{
{0x60, 0x60}, // multi-plane read command
{0x11, 0x81}, // multi-plane program command
{0x60, 0x60, 0x35}, // multi-plane page copy-back read command
{0x85, 0x11, 0x81}, // multi-plane page copy-back program command
0x70, // multi-plane operation status read command
0xf1, // inter-leave bank0 operation status read command
0xf2, // inter-leave bank1 operation status read command
0x02, // bad block flag position, in the last page
1 // multi-plane block address offset
};
Thank You .
--
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.
