
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