[U-Boot] gpmi-nand driver and jffs2 support
Marek Vasut
marex at denx.de
Sun Sep 15 16:18:51 CEST 2013
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
More information about the U-Boot
mailing list