[U-Boot] gpmi-nand driver and jffs2 support

[Huang Shijie]

于 2013年09月04日 23:46, Hector Palacios 写道:
> Dear Marek,
>
> On 09/04/2013 04:38 PM, Marek Vasut wrote:
>> Dear Huang Shijie,
>>
>>> On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
>>>> Dear Huang Shijie,
>>>> How come hector was then able to write his JFFS2 partition ?
>>>
>>> If he uses the gpmi, he should not write the JFFS2, since the gpmi
>>> does not support the jffs2. He will get the failure in the end.
>>
>> Hector, can you comment on this?
>
> I don't think I'm following these comments. The facts are:
> 1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
> a) does not mount on kernel v3.10
> b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from 
> Huang
> (actually I didn't use linux-next but instead a v3.10 where I merged 
> all the commits done to MTD in linux-next, which are a lot).
>
> 2) A JFFS2 filesystem image written with U-Boot v2013.01
> a) mounts OK on old FSL kernel 2.6.35
> b) does not mount on kernel v3.10 (neither on v3.8, I believe).
> c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or 
linux v3.10.

We have abandoned the old gpmi driver, and we use the same gpmi code in 
current FSL kernel.

Since we swtich to the upstream gpmi code, and it could not support the 
jffs2,

and that's why you mount always failed.


>
> [1] 
> http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
>
> Marek, could you please confirm 2b on your side, just in case I'm 
> doing anything wrong in my custom U-Boot?
>
>
>>>>> So the jffs2 support is compatiable all the time.
>>>>
>>>> Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
>>>> after applying this patchset?
>>>
>>> Not compatible.
>>>
>>> This patch set is still underreview.
>>
>> So this patch breaks compatiblity with FSL kernel release? This needs 
>> fixing,
>> otherwise it's impossible to do a drop-in replacement for the ancient 
>> FSL
>> kernel.
>>
>>>>>> that I could mount with Linux 3.7 and earlier?
>>>>>
>>>>> I think the mount can be succeeded.
>>>>
>>>> Ok, does that mean that we need this patchset in U-Boot in order to
>>>> properly write JFFS2 onto GPMI NAND there? Is that the message you
>>>> wanted to relay to us?
>>>
>>> Besides this patchset, the u-boot needs more patches to sync with the
>>> kernel mtd code. Such as the full-id features.
>>
>> Can you elaborate on this more? This is very vague, I would like to 
>> know what
>> exactly is missing.
>
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
f22d5f6 mtd: add new fields to nand_flash_dev{}

2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}

> Yes, please, we need more details. This seems to be related with how 
> the MTD drivers (in Linux and in U-Boot) access the OOB area to store 
> the JFFS2 cleanmarkers, right?
>
> The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
>
> if (!oinfo || oinfo->oobavail == 0) {
> pr_err("inconsistent device description\n");
> return -EINVAL;
> }
Before apply the patches above, the gpmi will use all the oob, so 
"oinfo->oobavail == 0" becomes true.

After apply the patches, the gpmi will not use all the oob for the ONFI 
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.


thanks
Huang Shijie