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.kaasi...@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.kaasi...@gmail.com> > >> Hi Pekon, >> Thank you for your answers. Please find my answers/comments to your >> questions below. >> >> 2013/11/6 Gupta, Pekon <pe...@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.kaasi...@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 <mfu...@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 >> > >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot