[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 13:41:52 CET 2013
Hi Pekon,
It seems after patching without BCH16 patches that at least
OMAP_ECC_BCH8_CODE_HW can't be compatible with Linux 3.8.13 mode. U-Boot
drivers/mtd/nand/omap_gpmc.c:omap_select_ecc_scheme states that
nand->ecc.bytes = 14 whereas in OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode
setting seems to be 13. Therefore, OMAP_ECC_BCH8_CODE_HW_DETECTION_SW could
possibly be compatible.
I have not got change to try it, though as I do have Angstrom related
problems (I need to fix license path/md5 checksum to get build pass).
-Matti
2013/11/7 matti kaasinen <matti.kaasinen at gmail.com>
> Pekon,
> Please find the nand dumps from oob area below. UBIFS volume created and
> edited in Linux.
>
> Linux:
> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff 5c 87 73 23
> OOB Data: ae 36 a6 16 fc 81 dd 8e f0 ff ff ff ff ff ff ff
> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> U-Boot:
> OOB:
> ff ff ff ff ff ff ff ff
> ff ff ff ff 90 df 27 b0
> f7 8c db 4c 0e 76 25 7e
> a9 ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff
>
> Best regards,
> Matti
>
>
> 2013/11/7 matti kaasinen <matti.kaasinen at gmail.com>
>
>> 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