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

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

[Hector Palacios]

Dear Huang,

On 09/02/2013 10:50 AM, Huang Shijie wrote:
> ? 2013?09?02? 16:42, Hector Palacios ??:
>> I am writing the JFFS2 partition from my custom U-Boot. Do you mean
>> that they way it writes it could not be compatible with what the new
>> driver expects? That sounds really bad.
>
> The mtd code(as well as the gpmi driver) has merge many patch to the kernel,
> BUT, the relative patches are not submitted to uboot maillist. So the
> code is not aligned between the
> uboot and the kernel.

Ok, I just rewrote the JFFS2 partition using the mtd-utils and now it mounts correctly 
and without any error.
So does this mean that U-Boot is now unable to properly write a JFFS2 partition for it 
to be understood by the linux-next kernel? What is exactly the difference? Does it 
only affect Freescale NAND controllers?

I'm including the U-Boot mailing list in CC.
The complete thread for reference: http://patchwork.ozlabs.org/patch/271322/

Best regards,
--
Hector Palacios

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

[Huang Shijie]

? 2013?09?02? 18:10, Hector Palacios ??:
> So does this mean that U-Boot is now unable to properly write a JFFS2 
> partition for it to be understood by the linux-next 
For the gpmi nand controller, the uboot is not proper to write a jffs2 now.
> kernel? What is exactly the difference? Does it only affect Freescale 
> NAND controllers?
I think there are many difference. Just diff the nand_base.c, you can 
see there are many patches merged in
the kernel's mtd code, but not exit in the uboot's mtd code.


AFAIK, only the gpmi is affected now.

thanks
Huang Shijie

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

[Marek Vasut]

Dear Huang Shijie,

> ? 2013?09?02? 18:10, Hector Palacios ??:
> > So does this mean that U-Boot is now unable to properly write a JFFS2
> > partition for it to be understood by the linux-next
> 
> For the gpmi nand controller, the uboot is not proper to write a jffs2 now.
> 
> > kernel? What is exactly the difference? Does it only affect Freescale
> > NAND controllers?
> 
> I think there are many difference. Just diff the nand_base.c, you can
> see there are many patches merged in
> the kernel's mtd code, but not exit in the uboot's mtd code.

This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot 
and Linux would be incompatible for all MTD drivers. This would also mean that 
JFFS2 in Linux 3.7 is incompatible with Linux-next (since 3.7 was the last sync 
point between U-Boot and Linux MTD). Is that really the case?

Best regards,
Marek Vasut

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

[Huang Shijie]

? 2013?09?02? 19:32, Marek Vasut ??:
> This makes not much sense to me. If what you claim is true, than JFFS2 in U-Boot
> and Linux would be incompatible for all MTD drivers. This would also mean that
The jffs2 in uboot and linux is compatible now. But the mtd base code, 
such as nand_base.c /nand_bbt.c
has changed. And the gpmi for kernel has be changed too.
All these changes are not sync with the uboot yet.

thanks
Huang Shijie

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

[Marek Vasut]

Dear Huang Shijie,

> ? 2013?09?02? 19:32, Marek Vasut ??:
> > This makes not much sense to me. If what you claim is true, than JFFS2 in
> > U-Boot and Linux would be incompatible for all MTD drivers. This would
> > also mean that
> 
> The jffs2 in uboot and linux is compatible now. But the mtd base code,
> such as nand_base.c /nand_bbt.c
> has changed.

Ok, based on this claim AND U-Boot being last synced with Linux 3.7, the obvious 
questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 
in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next 
that I could mount with Linux 3.7 and earlier?

> And the gpmi for kernel has be changed too.
> All these changes are not sync with the uboot yet.

Best regards,
Marek Vasut

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

[Huang Shijie]

? 2013?09?03? 19:53, Marek Vasut ??:
> questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2
> in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next
The jffs2 does not changed since the linux 3.7.
All the changes happened in the drivers and mtd code.

The gpmi does not support the jffs2 all the time. Only apply the slc/mlc 
patch set,
the gpmi can support the jffs2.

So the jffs2 support is compatiable all the time.


> that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.

thanks
Huang Shijie

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

[Marek Vasut]

Dear Huang Shijie,

> ? 2013?09?03? 19:53, Marek Vasut ??:
> > questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible
> > with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition
> > under Linux-next
> 
> The jffs2 does not changed since the linux 3.7.
> All the changes happened in the drivers and mtd code.

OK, JFFS2 aside then, let's focus on MTD core code.

> The gpmi does not support the jffs2 all the time. Only apply the slc/mlc
> patch set,
> the gpmi can support the jffs2.

How come hector was then able to write his JFFS2 partition ?

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

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

Best regards,
Marek Vasut

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

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


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

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

thanks
Huang Shijie

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

[Marek Vasut]

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?

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

Best regards,
Marek Vasut

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

[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]

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

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;
}

Best regards,
--
Hector Palacios

[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

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

[Marek Vasut]

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

With the patchset, mounting the jffs should work again, no? If mounting the jffs 
works with the patchset AND it only works with jffs written using the new 
driver, you will need to introduce soem compatibility option or something along 
that.

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

Do these really have any impact?

> 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{}

Hector, can you inspect those patches ?

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

So the patches you listed above are not enough?

Best regards,
Marek Vasut

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

[Huang Shijie]

? 2013?09?15? 22:18, Marek Vasut ??:
> Dear 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.
> With the patchset, mounting the jffs should work again, no? If mounting the jffs
If the jffs2 image is written by the uboot, the mounting should not works.


> works with the patchset AND it only works with jffs written using the new
> driver, you will need to introduce soem compatibility option or something along
> that.
do you mean i should a new dt property for the jffs2 support ?
>>> [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
> Do these really have any impact?
>
yes. the full-id nand is not supported by the old mtd code.
>> 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{}
> Hector, can you inspect those patches ?
>
>>> 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.
> So the patches you listed above are not enough?

It should be enough.

thanks
Huang Shijie

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

[Marek Vasut]

Dear Huang Shijie,

Sorry, I think I got lost in the discussion. I will pull out.

btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm 
trying to backport patches from -next and apply the GPMI NAND patchset, without 
much luck yet.

Best regards,
Marek Vasut

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

[Hector Palacios]

Dear Marek Vasut,

On 09/19/2013 06:07 PM, Marek Vasut wrote:
> btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm
> trying to backport patches from -next and apply the GPMI NAND patchset, without
> much luck yet.

If it helps, to make it work on v3.10 I had to apply lots of commits (listed in 
reverse order, from most recent to oldest):

53a9abf27213154d1ebaa54d111533f1e69d8ef3 mtd: mtd-abi: add a helper to detect the nand 
type
44aabd5fe3423f5b2071379bd55e708d523a1b4c mtd: add a helper to detect the nand type
2a2d49314b6a36eca80947ad021d01f7e6294291 mtd: add MTD_MLCNANDFLASH case for 
mtd_type_show()
576c9744f0f62d0b8d207d74b9066f00f4bdd347 jffs2: do not support the MLC nand
654b09629a50fd1680afcce46514e9ffc6723418 mtd: fix the wrong mtd->type for nand chip
95bc60491c394174cdbd1b24b0940fa61b6f2aec mtd: add more comment for 
MTD_NANDFLASH/MTD_MLCNANDFLASH
b9032012d68cf881e48237336e79d783b69f2a1b mtd: gpmi: rewrite the gpmi_ecc_write_oob() 
to support the jffs2
2c92e6f5e6a61020443ec3dbb7d51c6a84170f36 mtd: print out the cell information for nand chip
01e1b2c398952ead5d8b3eb370dc7a31560e9c00 mtd: set the cell information for ONFI nand
2dcd73d5c96067342fafeb088cc08872f68558d5 mtd: nand: rename the cellinfo to bits_per_cell
40f5c3f65f9f2151ae5cdd9293af6d62f551d51a mtd: add a new field to mtd_info{}
a0181739d881f3e973ebfbe29769f0d4f08b26a4 mtd: add ECC info for nand_flash_dev{}
247db5b42147d0b764c6096e1b55c7f01439b9a5 mtd: add a helper to get the supported 
features for ONFI nand
0db74df18a1dbd9814637ba891cc123f3b7a4bba mtd: add data structures for Extended 
Parameter Page
f4ead19a666581c78a7f9d27379e4ee4850d38ae mtd: add datasheet's ECC information to 
nand_chip{}
b47e2aa8f044092ea63a2b28d1ead0ff6bc54ac3 mtd: nand: remove NAND_BBT_SCANEMPTY
91eae06eb963ad7f5faf8f585f21d34921cb7830 mtd: nand: hide in-memory BBT implementation 
details
4b8c49529b49e84a9472e52ffa2b452b48779563 mtd: nand_base: Only use GET/SET FEATURES 
command on chips that support them.
8babb2385cfcd9ee24b62e2dd1577a1e05ef2f1f mtd: nand: fsmc: update of OF support
34b182c94acfc08e851af3500d8f3fa8b1d073e5 mtd: increase max OOB size to 744
b726168414d1ce3cff143e4bdc3f944459894388 mtd: nand: reword nand_chip bad block 
interface comments
36b46f044704df158078beaa368284fdc435f34a mtd: mpc5121_nfc: cleanup clock API use
5afbc047077a88c38181b9d4de6bea70a140b5a0 mtd cs553x_nand: use kzalloc() instead of memset
247f500f0903c084fa04f96e41aed049a3ec0709 mtd: atmel_nand: fix error return code in 
atmel_nand_probe()
573f505290ac60920d2e4d4c39323acb14b7b0c4 mtd: remove alauda driver
240ca8e6f0f5689bc34130c5843fc7df40fc994a mtd: nand: mxc_nand: mark 'const' properly
fdd0ddf7fac3ae18b8cbaf64a60a3f9591e124ac mtd: r852: Staticize local symbols
e979054e90b480bb62ac8ac2d69bbe13418f6514 mtd: nandsim: Staticize local symbols
cfa8de169b47502e0ce8b30b9a79b615b68af6b1 mtd: MTD_NAND_DENALI should depend on HAS_DMA
d322e0477e11fdd9bdec1040a7c8d4e14ec3e188 mtd: fsmc_nand: simplify 
platform_get_resource_byname/devm_ioremap_resource
f09f9d2061572d858856085d57d2f580fb60db0d mtd: atmel_nand: pmecc: fix bug fail to 
correct bit error in 1024-bytes sector
8a7f3dbd96350bc1d3f012c14da682049eb89530 mtd: nand: fixup kerneldoc, rename parameter
69d75957804c0cc214b705fee8c618bcca6c1671 mtd: gpmi: remove the nand_scan()
6aa28d55ddaf7ce5e245f835bfd0871ef3db492c mtd: set ONFI nand's default hooks in 
nand_set_defaults()
3320916b8845e06d04cea7b492920829ce49ac0e mtd: set the ecc step size for master/slave 
mtd_info
8d6a288d8b950b08a150f96781d365f770669898 mtd: nand: silence some shift wrap warnings
38cd6478fb2b38b12525fbede22cf549e1581a3e mtd: simplify use of devm_ioremap_resource
7b900eb9f497da080c3a46a50fe33ffa14e093aa mtd: nand: Allow to build pxa3xx_nand on 
Orion platforms
2cd4ce5d72919da4a5eb48f63d50ccbb38d96b19 mtd: nand: pxa3xx: Allow devices with no dma 
resources
383b9edf4a14193c819cb5f1cf841206da064095 mtd: nand: pxa3xx: Add __maybe_unused keyword 
to enable_int()
4552440a0c279fac04e4a7216c36a537956a2acc mtd: nand: pxa3xx: Make dma code dependent on 
dma capable platforms
475e1ad93c4bc100ad8ed82013669f8569471a96 mtd: nand: pxa3xx: Move cached registers to 
info structure
8270cfd39ae136c10082287f612f825414a01950 mtd: nand: pxa3xx: Remove uneeded internal cmdset
234f82f9269e2a96c4b6f3802121d8e307d29580 mtd: nand: pxa3xx: Remove hardcoded mtd name
afa5a8a3750f428fe4c9f9a5840dfddfe4f7d503 mtd: nand: pxa3xx: Add a local loop variable
dc33d8fcfc245dab443ef1a5172864bb6d3d2c94 mtd: nand: pxa3xx: Use 'length override' in 
ONFI paramater page read
1b3334cf50d40eb1ef7f39d6e3396b30d5d085f0 mtd: nand: pxa3xx: Support command buffer #3
33275c59dab511acd0fbb988519bd8dba670b7ff mtd: nand: pxa3xx: Allow to set/clear the 
'spare enable' field
08f509aac14a0c7120f2885ac543c9758b00a518 mtd: nand: pxa3xx: Handle ECC and DMA 
enable/disable properly
00187c3a76b6e3da79ef495ce2a6c68fe96ee0de mtd: nand: pxa3xx: Introduce 
'marvell,armada370-nand' compatible string
58fd0eb5d7fa386ff2ef23490d69b8a7699ed85b mtd: nand: pxa3xx: Remove unneeded ifdef 
CONFIG_OF
3a60185cc775357153f52804f61d0a271a5f0696 fs: create file_readable() and 
file_writable() functions
35d0c403f8df90eb53f8b3d7058435a5971cf843 mtd: gpmi: set the BCH's geometry with the 
ecc info
e9f731bd91a0b0de671f2c786152913d77aa37b3 mtd: add the ecc info for some full-id nand chips
2574dd936a6039a9e0c64e598e728384fc5d1fb5 mtd: parse out the ECC info for the full-id 
nand chips
7f9da59d3ce36590295543d4b59e0f8b7d68ca0d mtd: replace the hardcode with the onfi_feature()
26b275a4f4ed1191f1be7c4489f568c8604de641 mtd: get the ECC info from the Extended 
Parameter Page
77788a73eab5c6a8cbda30b8797a269c1f8e3480 mtd: get the ECC info from the parameter page 
for ONFI nand
c8daf04b75e1cee55a81cc47c28daca921e8ce15 mtd: atmel_nand: move the sanity check to the 
beginning of pmecc_enable()
67f6dd67d69b9d018411a2e34b10a192edb2aeaf mtd: nand: use dev_get_platdata()
7120499942b95c88e8273bef557906e14742911f mtd: denali: use NAND_CI_CELLTYPE_MSK instead 
of hardcoded constant
6105c5fc8cbfab44c80fc2ff24d3de89edca8946 mtd: nand: gpmi-nand: use more sensible error 
codes at various places
fbecc4c137f70f1d7d8f43de600f08242c75934b mtd: nand: gpmi-nand: janitorial cleanup: 
(commas after last element of struct initializ
77ba056a60d8ace805410002129036cff4bf5c52 mtd: atmel_nand: fix the warning when 
CONFIG_OF is not defined
f889dd6aec3fd3041d650b3b4ba32a1f167836c1 mtd: nand: remove NAND_BBT_SCANEMPTY
01b5773bb02cc534a073272e45f2d75928aabbdb mtd: nand: hide in-memory BBT implementation 
details
3f61aa34c884cc1fa67f97d5a25772112b0147a8 mtd: nand: refactor chip->block_markbad interface
d15973ed747ce28d129f0f08cbcf7248f83ce7b0 mtd: nand: eliminate cast
d5ec22b16799f05f222ce949df9f7c7788c9a388 mtd: nand: remove multiplied-by-2 block logic
ff4ef6b2faf909227c06b1c7494f9e9b009d0711 mtd: nand: add accessors, macros for 
in-memory BBT
572acb4aec443d9b07ca62dcd2e321aff64c2058 mtd: atmel_nand: enable Nand Flash Controller 
(NFC) write via sram
7fdd5e2555451c9646303f87001f33a2b180d3a5 mtd: atmel_nand: enable Nand Flash Controller 
(NFC) read data via sram
f3c0fc1870a4ac21ebda77b69477e35ee2345fab mtd: atmel_nand: add Nand Flash Controller 
(NFC) support
f9be6c059590d55b16000353bd25180fb3524060 mtd: atmel_nand: replace pmecc enable code 
with one function.
995979747c758d0618a5999b72e4e9645126996a mtd: atmel_nand: use devm_xxx gpio kzalloc, 
gpio and ioremap
d8b351cb3f380345eeaa6de0911568ebd083f763 mtd: nandsim: remove unused ns->geom.oobshift
6250f5a5b534e8840eafb6773e1d1fe4aa337096 mtd: nandsim: remove unused code
414d34c448779edc1ea9517fc9f75cb740091fd2 mtd: nandsim: use NS_RAW_OFFSET()
32ed63c74fdc9c11b5a744f2d846d9ff3dc690c8 mtd: nandsim: simplify NS_RAW_OFFSET()
0361bb75b2d75efcd30ca79531862e6799e6e3a0 mtd: nandsim: use kasprintf()
c50761be2b4c278247d4ef198d2120043cb96083 mtd: nandsim: convert pages_written[] to bitmap
b0430eb26dbcff68528a48ad55865c25cb8e7dce mtd: nand: detect OOB size for Toshiba 24nm 
raw SLC
af1f55ae90e1e8060318b1e16b9a2c1cb55c6956 mtd: atmel_nand: fix pmecc selction for ecc 
requirement typo
d05debb658fd8ff72e570e04ea1950b6980f229d mtd: nand: fix NAND_BUSWIDTH_AUTO for x16 devices
d8f855a6961028909032d617fb35bb440dd7ad33 mtd: diskonchip: remove unused entries in Kconfig
861ef3fb9819f5b3688836ff7e4c44180b9982df mtd: atmel_nand: don't use 
devm_pinctrl_get_select_default() in probe
c7babfbc49aa6f903e66b93b88dd8736279df2c9 mtd: gpmi-nand: don't use 
devm_pinctrl_get_select_default() in probe
84c9313cacdbc8d8e7bfbca5e1f94569dfd94a5f mtd: nand: mxc_nand: Remove unneeded check 
for platform_get_resource()
7f62a0169b724684e4cf33ecb782134359271919 mtd: atmel_nand: using a stronger ECC is not 
dangerous
b3be64643c39f91401e017d67182dd1089be1a14 mtd: nand: txx9ndfmc: remove unnecessary 
platform_set_drvdata()
3d74b88ef09bcf3538dad9e16c35bd4133897fed mtd: nand: sharpsl: remove unnecessary 
platform_set_drvdata()
62f78268fe22bd4116715dc3a0a063789786e532 mtd: nand: s3c2410: remove unnecessary 
platform_set_drvdata()
f11ce2b3680b5491973b5592195c4a3e49292191 mtd: nand: pxa3xx_nand: remove unnecessary 
platform_set_drvdata()
ccc3fab23551b0f737066f1c3d15105f768779f5 mtd: nand: plat_nand: remove unnecessary 
platform_set_drvdata()
3e6c8f5e62d48ea2a97e60a5d57a2e4df2b8c8bd mtd: nand: orion_nand: remove unnecessary 
platform_set_drvdata()
284ec293b80ce08ceb2677bbd15cfda2fd4d9794 mtd: nand: omap2: remove unnecessary 
platform_set_drvdata()
9315d116a80429c9ce2f9378079b6a829b523c10 mtd: nand: nuc900_nand: remove unnecessary 
platform_set_drvdata()
1a35df39fb4f948f4fbc7908033ec9c122567166 mtd: nand: mxc_nand: remove unnecessary 
platform_set_drvdata()
da4ed680a5530367f672cdfaf1860a71a7c8185e mtd: nand: lpc32xx: remove unnecessary 
platform_set_drvdata()
294824698f8267788a381928fe1818f1d695e258 mtd: nand: jz4740_nand: remove unnecessary 
platform_set_drvdata()
5e72ee56f9113d60cabb4f8adc2c1fa4f15f82a9 mtd: nand: gpmi-nand: remove unnecessary 
platform_set_drvdata()
63d5c5167c38967ded910c74b2190c368957c4ee mtd: nand: fsmc_nand: remove unnecessary 
platform_set_drvdata()
0c45084c9b2ab66af282193d43f736d02f5dcb1e mtd: nand: docg4: remove unnecessary 
platform_set_drvdata()
385f9c1ef89efaf4bd4d4f3236e81c755b8caddf mtd: nand: bf5xx_nand: remove unnecessary 
platform_set_drvdata()
65a561c4335f598a2e33239d25f4d1a1a4e0fcf1 mtd: nand: atmel_nand: remove unnecessary 
platform_set_drvdata()
c27ed888870c52292fc322050ddf80e84aa0de4f mtd: nand: ams-delta: remove unnecessary 
platform_set_drvdata()
49649863a7dd1f3ee0c46320ff78856974e9772a mtd: nand: pxa3xx: Add support for Read 
parameter page command
caa75d26a05fa5155855a86b58acb74e916c2328 mtd: nand: pxa3xx: Add address support for 
READID command
a456431d85b37365bb324c48300781ec940fff99 mtd: nand: pxa3xx: Fix MODULE_DEVICE_TABLE 
declaration
a6ab4f906eb96cfbaa8823e6668bb840020c3252 mtd: nand: pxa3xx: Use of_machine_is_compatible()
c6bf90f74720c76ddededb035d335827b55e9c87 mtd: nand: pxa3xx: Set info->use_dma properly
98dde6f6ec74e855a206904c6e4f82baa041ca9a mtd: atmel_nand: add a new dt binding item 
for nand dma support
4df160fe6b080116a37ac90d4619983b71a3d21d mtd: atmel_nand: replace cpu_is_at32ap7000() 
with a nand platform data
40aeefd2d7b15037141a36bb99ee8ac0fc192d77 mtd: gpmi-nand: fix error return from 
gpmi_get_clks()
359a1df828b36e9a9994a23418544bc88c28074f mtd: nand: davinci: use devm_ioremap_resource()
6e0efb855af64ab8322a9eb523027fc8f6bc43f6 mtd: nand_base: Only use GET/SET FEATURES 
command on chips that support them.
9ab677c6bb897ef2108292996e66530cce66c2b9 mtd: nand: fsmc: update of OF support
ff59928a191e881df9e267b93506ed016ac15a1a mtd: nand: pxa3xx: Move buffer release code 
to its own function
0c0412495b9b3481220ca2b550254749efcca2b9 mtd: nand: pxa3xx: Check for 
clk_prepare_enable() return value
9ecbf288af72b90c141dcfdd41a1159a41ca2992 mtd: nand: pxa3xx: Use clk_prepare_enable and 
clk_disable_unprepare
62f822b04664f2bb5259013dc033da773e6e47b8 mtd: nand: pxa3xx: Use devm_clk_get
9b948fb5b989ac8faf387968dd9e1de4b4fb2cb1 mtd: nand: pxa3xx: Use devm_ioremap_resource
7e4dd5c37fa010dd55c243e58e9c22a03d73687d mtd: nand: pxa3xx: Use devm_kzalloc
57646f659a8a9cdc52f1ad561efbe8df653ccba6 mtd: nand_base: Use io{read, write}*_rep 
functions for transfer
b426958cc7b80a7bc82e2d93e2ad9324876fe982 mtd: nand-gpio: Add missing "owner" field in 
platform_driver struct
9822c3457e6664f6b7476fc0ccee242204b95272 mtd: nand-gpio: Rename internal variables to 
match functionality
c9906128d056e743e0f207147e0f880b2242c047 mtd: nand-gpio: Unneeded dependency on ARM 
removed
38af907581d9397d41ee8237f3e67a7d1319a8ce mtd: nand-gpio: Use default nand_base 
{read/write}_buf functions
dd6ca7acd8bebf280dbdb1d675732fa7f9cac8bd mtd: nand-gpio: Do not override GPIOs if 
driver uses platform_data but OF is enabled in
45078431a6ea64791ad8a72ac5860c0671ac53d4 mtd: nand-gpio: Use default dev_ready 
function if RDY is missing in configuration
055deba61df0a1e34d7682701babb62678f9ab9e mtd: nand-gpio: Convert driver to using 
resource-managed functions
b6eec0dada833875d85a3c0917a394ad57dfb54b mtd: fsl_ifc_nand: set NAND_NO_SUBPAGE_WRITE
892bccd8efae6175dc9d8628627e347c526564d2 mtd: fsmc_nand: add CONFIG_PM_SLEEP to 
suspend/resume functions
18c40318889629ad2f767603b0f4b51ebb71e4de mtd: r852: add CONFIG_PM_SLEEP to 
suspend/resume functions
42def8ab25ecd8a81f1bd4b452445ed3636d159f mtd: fsl_ifc_nand: remove incorrect kfree()
d855bd95ad35568b109f1b4587b68f0c950011f5 mtd: omap2: allow bulding as a module



Best regards,
--
Hector Palacios

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

[Hector Palacios]

On 09/19/2013 06:07 PM, Marek Vasut wrote:
> Dear Huang Shijie,
>
> Sorry, I think I got lost in the discussion. I will pull out.
>
> btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now I'm
> trying to backport patches from -next and apply the GPMI NAND patchset, without
> much luck yet.

Oops, sorry, did you mean you were trying to backport them into U-Boot? Then please 
disregards my previous message.


Best regards,
--
Hector Palacios

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

[Marek Vasut]

Dear Hector Palacios,

> On 09/19/2013 06:07 PM, Marek Vasut wrote:
> > Dear Huang Shijie,
> > 
> > Sorry, I think I got lost in the discussion. I will pull out.
> > 
> > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now
> > I'm trying to backport patches from -next and apply the GPMI NAND
> > patchset, without much luck yet.
> 
> Oops, sorry, did you mean you were trying to backport them into U-Boot?
> Then please disregards my previous message.

You actually just saved me a lot of annoyance, thank you ;-)

btw feel free to run into me on IRC (#u-boot on freenode) or jabber so we can 
work on the backporting-to-uboot part ;-)

Best regards,
Marek Vasut

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

[Marek Vasut]

Dear Hector Palacios,

> On 09/19/2013 06:07 PM, Marek Vasut wrote:
> > Dear Huang Shijie,
> > 
> > Sorry, I think I got lost in the discussion. I will pull out.
> > 
> > btw Hector, I managed to verify JFFS2 mounting doesn't work on 3.10 , now
> > I'm trying to backport patches from -next and apply the GPMI NAND
> > patchset, without much luck yet.
> 
> Oops, sorry, did you mean you were trying to backport them into U-Boot?
> Then please disregards my previous message.

After applying the batch of patches, this is what I get. Interestingly enough, 
this JFFS2 was written from FSL 2.6.35 kernel.

[   24.118091] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error
[   24.164458] jffs2: mtd->read(0x1fa34 bytes from 0x5cc) returned ECC error
[   24.171377] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005cc: 0x7953 i
nstead
[   24.180969] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005d0: 0xe837 i
nstead
[   24.190675] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005d8: 0x85ff i
nstead
[   24.200274] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005dc: 0xcde0 i
nstead
[   24.209853] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005e0: 0x7000 i
nstead
[   24.219428] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005e4: 0x020f i
nstead
[   24.229000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005e8: 0x0200 i
nstead
[   24.238570] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005ec: 0x2400 i
nstead
[   24.248142] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x000005f4: 0xa400 i
nstead
[   24.257645] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 
0x00000608: 0xacc8 i
nstead
[   24.267191] jffs2: Further such events for this erase block will not be 
printed
[   24.275419] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000021c8: 
Read 0x00000000, cal
culated 0xd5be0e0f
[   24.287221] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000049d4: 
Read 0xd1f00000, cal
culated 0x34cb9a56
[   24.300900] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0000b9c0: 
Read 0x7fd74190, cal                                                                       
culated 0xfdbc37a5                                                                                                                                                          
[   24.312171] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0000d1f4: 
Read 0x16600000, cal                                                                       
culated 0x00cb3014                                                                                                                                                          
[   24.326509] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x000161d4: 
Read 0x9a500000, cal                                                                       
culated 0xcd68c7e3                                                                                                                                                          
[   24.338761] jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x0001a1e4: 
Read 0x14500000, cal                                                                       
culated 0xa3e78a6c                                                                                                                                                          
[   24.352739] jffs2: mtd->read(0xc28 bytes from 0x1f3d8) returned ECC error                                                                                                
[   24.359661] jffs2: Empty flash at 0x0001f3d4 ends at 0x0001f400                                                                                                          
[   24.366953] jffs2: mtd->read(0xbec bytes from 0x1f414) returned ECC error                                                                                                
[   24.374053] jffs2: Empty flash at 0x0001f410 ends at 0x0001f604                                                                                                          
[   24.381408] jffs2: mtd->read(0x9e8 bytes from 0x1f618) returned ECC error                                                                                                
[   24.388450] jffs2: Empty flash at 0x0001f614 ends at 0x0001fa00                                                                                                          
[   24.395141] jffs2: mtd->read(0x5f4 bytes from 0x1fa0c) returned ECC error                                                                                                
[   24.402059] jffs2: Empty flash at 0x0001fa08 ends at 0x0001fc00                                                                                                          
[   24.408794] jffs2: mtd->read(0x3ec bytes from 0x1fc14) returned ECC error
[   24.415615] jffs2: Empty flash at 0x0001fc10 ends at 0x0001fca8
[   24.422351] jffs2: mtd->read(0x350 bytes from 0x1fcb0) returned ECC error
[   24.429262] jffs2: Empty flash at 0x0001fcac ends at 0x0001fe04
[   24.435930] jffs2: mtd->read(0x1e8 bytes from 0x1fe18) returned ECC error
[   24.443789] jffs2: mtd->read(0x100 bytes from 0x20000) returned ECC error
[   24.491452] jffs2: mtd->read(0x1f964 bytes from 0x2069c) returned ECC error

Best regards,
Marek Vasut

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

[Marek Vasut]

Dear 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]
> 
> [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?

Sorry for the late reply. I cannot test it, since I don't have such a setup.

I still believe it'd be worth figuring out what the heck is going on in here. 
There is obviously a bug which breaks compatibility and that must not happen.

[...]

Best regards,
Marek Vasut