On 18 December 2014 at 08:10, Yassin Jaffer <[email protected]> wrote:
>
> On Thu, Dec 18, 2014 at 5:07 AM, Michal Suchanek <[email protected]> wrote:
>>
>> Hello,
>>
>> On 17 December 2014 at 11:40, Boris BREZILLON <[email protected]>
>> wrote:
>> > Hi Michal
>> >
>> > Le mardi 16 décembre 2014 19:01:58 UTC+1, Michal Suchanek a écrit :
>> >>
>> >> Hello,
>> >>
>> >> I tried to rebase the v7 patchset on top of 3.18 and add the DT
>> >> bindings on cubieboard:
>> >>
>> >>
>> >> https://github.com/hramrach/linux-sunxi/commit/a946d593ddcf443b0f035f6d39fe0c558189dacc
>> >>
>> >> The nand driver fails equally on both cubieboard versions:
>> >>
>> >> cubieboard:
>> >> [ 0.643554] calling nand_base_init+0x0/0x20 @ 1
>> >> [ 0.643565] initcall nand_base_init+0x0/0x20 returned 0 after 3
>> >> usecs
>> >> [ 0.643578] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
>> >> [ 0.665751] nand: Could not find valid JEDEC parameter page;
>> >> aborting
>> >> [ 0.670907] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
>> >> [ 0.675949] nand: Samsung NAND 4GiB 3,3V 8-bit
>> >> [ 0.679098] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
>> >> [ 0.683748] sunxi_nand 1c03000.nand: ECC init failed: -22
>> >> [ 0.687839] sunxi_nand 1c03000.nand: failed to init nand chips
>> >> [ 0.692440] sunxi_nand: probe of 1c03000.nand failed with error -22
>> >> [ 0.697500] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
>> >> after 52642 usecs
>> >> cubieboard2:
>> >> [ 0.666766] calling nand_base_init+0x0/0x20 @ 1
>> >> [ 0.666777] initcall nand_base_init+0x0/0x20 returned 0 after 3
>> >> usecs
>> >> [ 0.666790] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
>> >> [ 0.683003] nand: Could not find valid JEDEC parameter page;
>> >> aborting
>> >> [ 0.688159] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
>> >> [ 0.693201] nand: Samsung NAND 4GiB 3,3V 8-bit
>> >> [ 0.696349] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
>> >> [ 0.700956] sunxi_nand 1c03000.nand: ECC init failed: -22
>> >> [ 0.705060] sunxi_nand 1c03000.nand: failed to init nand chips
>> >> [ 0.709658] sunxi_nand: probe of 1c03000.nand failed with error -22
>> >> [ 0.714768] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
>> >> after 46833 usecs
>> >>
>> >> Is this expected or does somebody have the driver working on some
>> >> device?
>> >
>> >
>> > As Henrik already answered, it seems that your NAND chip is not properly
>> > defined in the nand_ids table [1].
>> > Read your NAND datasheet and add a new entry (take a look at this one
>> > [2] as
>> > an example).
>> > You should also fill the correct timing mode, though mode 0 should work
>> > correctly on all recent NANDs.
>>
>> The nand chip says Samsung 222 K9GBG08U0A SCB0
>>
>> Is there some document on filling out his table?
>>
>> It seems that 0xec 0xd7 matches info on top op page 80 of
>>
>> http://www.datasheet4u.com/datasheet-pdf/Samsung/K9GBG08U0A/pdf.php?id=704185
>>
>> But that table lists 0xec, 0xd7, 0x94, 0x76, 0x64, 0x43 and additional
>> debug output shows that the chip sends Manufacturer ID: 0xec, Chip
>> ID: 0xd7; 0x94 0x7a 0x54 0x43 0xec 0xd7 the last two bytes possibly
>> being wrap-around of the first two.
>>
>> However, that document lists multitudes of identification strings.
>> Which one is used where in the table?
>>
>> The document lists that there is 8k page and 640 oob which matches
>> existing output. It also says that that ecc is 40bit (1k + 80byte) on
>> page 5 which looks like value obtained by dividing that 640 oob data
>> by 8 to get oob amount per 1k - no staggering new information.
>>
>> Some timing information is presented on pages 18-19 but the provided
>> table has way more data than a nand entry in the kernel table.
> Hi Michal
>
> add the following to the nand id table
>
> {"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 },
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?
Some people are willing to open the device and look at the chip,
especially when the case is easy to take apart. Finding a datasheet
once you have seen the chip is not that much of a problem, either.
But if the data in the datasheet is useless and the kernel does not
even print the full ID unless you patch it how do you get to your
device working form that point?
If a Joe User sent us this datasheet can we fabricate an ID entry form
that datasheet alone? How?
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?
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.
