[U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver

matti kaasinen matti.kaasinen at gmail.com
Thu Nov 7 09:48:16 CET 2013


Hi Pekon,
Thank you for your answers. Please find my answers/comments to your
questions below.

2013/11/6 Gupta, Pekon <pekon at ti.com>

> Hi Matti and Matthias
>
> Sorry I was away from my mailbox so couldn't reply you earlier.
> I'm still away from my setup and other boards, so cannot replicate
> the issue below until early next week. But I'll surely do so asap..
>
> However, please see my replies below, which might help you someway.
>
>
> > From: matti kaasinen [mailto:matti.kaasinen at gmail.com]
> > Hi Pekon,
> > Thanks to Tom Rini's hint I have tried to execute your patch sets
> > (http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320&state=*
> )
> >  in order to get Linux and U-Boot working with same NAND flash.
> > Set-up is pretty much like Mathias has before in this chain.
> > Latest problem I faced with is that last versions of
> >  1)  "[U-Boot,v8,3/5] mtd: nand: omap: optimize chip->ecc.calculate()
> for H/W ECC schemes"
> >  and 2) "[U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC -
> NAND driver updates"
> > are not compatible any more. As I told in
> > https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s
> > versions v5..v7 of 1) could possibly be compatible.
>
> There is no change in ECC layout or other functional updates between
> v7 and v8 of this patch, so if there is any incompatibility then it would
> be in all versions of the patch..
>

I did not mean "ECC layout-wisely" incompatible but "patching-wisely"
incompatible. Patching 2) v2 after 1) v8 stops to errors and it seems that
with 1) v7 it could (possibly) succeed.

Few questions..
> (1) Which ECC scheme are you using ?
>

Now I'm talking Linux 3.8.13 - U-Boot 10.04 combination that I have as
currently as "working" environment.  I have not managed getting above
patches successfully through.

> - u-boot
>         CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand
>         http://lists.denx.de/pipermail/u-boot/2013-October/164646.html
>
U-Boot 10.04 does not seem to have such choices  and in fact I have not
selected it.

> - kernel
>         OMAP_ECC_BCH8_CODE_HW
>         OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
>         Or any other..
>

I believe OMAP_ECC_BCH8_CODE_HW gets selected with following options from
kernel.

CONFIG_MTD_NAND_OMAP2
CONFIG_MTD_NAND_OMAP_BCH
CONFIG_MTD_NAND_OMAP_BCH8

... and selecting following choice

ti,nand-ecc-opt = "bch8"

in device tree.

With these options boot process reports;
[    1.128154] enabling NAND BCH ecc with 8-bit correction
[    1.133985] ONFI param page 0 valid
[    1.137662] ONFI flash detected
[    1.140985] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron
MT29F2G08AAD), 256MiB, page size: 2048, OOB size: 64

First line seems coming from drivers/nand/mtd/omap2.c:omap3_init_bch
that gets printed in this from only if OMAP_ECC_BCH8_CODE_HW ==
platform_data.ecc_opt

I printed nand.ecc.layout.eccbytes = 52 ( from from
drivers/nand/mtd/omap2.c:omap3_init_bch_tail )
and
nand.ecc.layout->eccpos[] = 12..63

BTW it seems that similar layout has been defined in u-boot
arch/arm/include/asm/arch-omap3/omap_gpmc.h
There is one exception, though: eccbytes have been set 54 instead of 52
that seems to be in linux (and correct I suppose).


>
>
> (2) Is the problem related to incorrect read/write access to x16 NAND ?
>
No using x8 NAND

> Or
> Is it incompatibility in ecc.layout ?
>
You can check this by dumping raw nand page via 'nand dump' command
> from both u-boot and kernel.
>
>
I'll try to check this

>

(3) you should not pick BCH16 patch-series
> - because I have not rebased this patch, and re-tested since other
>    base patch-series on which BCH16 will be build, is still not accepted.
> - Also BCH16 ecc scheme would work only for
>    NAND device with pagesize=4K and oobsize=224.
>    whereas current beaglebone capes have
>    NAND device with pagesize=2K and oobsize=64, so you can only use
>    BCH8 with current NAND capes (for now)..
>
This is perfectly fine with me. This set seems to block patching. I need
only BCH8 and if this patch set provides only BCH16 functionality and
nothing else, I need not using it.

>
>

>

> > > 2013/11/1 Matthias Fuchs <mfuchs at ma-fu.de>
> > > Hi Pekon,
> > >
> > > should I consider the U-Boot and Linux am335x NAND
> > > implementation to be compatible? So are the ECC schemes
> > > in a way identical that I can nandwrite a kernel image from
> > > Linux and "nand read" it from U-Boot? I tested with the 3.8.13
> > > beaglebone kernel (which is of course not very representative)
> > >  and it does not work. If it should work, do you know it that was
> > > already the case before your patches and with which Linux kernel?
>
> I don't think any earlier kernel versions ever supported beaglebone
> Its only recently that a major patch-series of NAND driver was
> accepted and  tested on beaglebone.
> The patches  are currently in l2-mtd.git tree which should make into
> 3.13 kernel, before being in linux-next for sometime.
> (a) Reference:
> http://lists.infradead.org/pipermail/linux-mtd/2013-October/049462.html
>
> (b) In addition to above series, you might need beaglebone DTS updates
> which you can refer from below ..
> http://lists.infradead.org/pipermail/linux-mtd/2013-October/049438.html
>
> So, you mean that it should not be possible to access beaglebone (alike)
board NAND with Linux 3.8.13. However, it seems that I can access it from
Linux (well, I have done some patching for IO and mux and device tree).
Problem really is that U-Boot and Linux handle it in different ways so that
if I create e.g. ubifs volume in Linux, that works quite fine. I can
rean/write it quite fine. However, if I mount it from U-boot, it get tons
of ecc error messages and as a result it gets corrupted. After that also
Linux side prints tons of ecc error messages while acessing it.

>
> with regards, pekon

Thanks,
Matti


More information about the U-Boot mailing list