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