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@gmail.com
Hi Pekon, Thank you for your answers. Please find my answers/comments to your questions below.
2013/11/6 Gupta, Pekon pekon@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@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
- "[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@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