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

[Hector Palacios <hector.palacios@digi.com>]

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