Pekon, Great to hear that you have managed in that. I tried that with previous patch sets (and re-writing beaglebone paches). Result was such that oob printout from u-boot had full of ff. Well, partition map was different on u-boot and Linux sides. However, partition that I tried to acces was in the same physical address (partition 8 in u-boot and partition 7 in Linux). It somewhat lame down my mood... Anyway, sounds that you have written those beaglebone patches, too- so that I need not re-writing them again. I'll come back when I have something to report.
You mentioned, that OMAP_ECC_BCH8_CODE_HW mode and ecc.bytes=14 has to be used. I suppose that at least the former option requires kernel patching like explained in http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGuide#Selecting_NAND_ECC_scheme_for_Linux_Kernel In any case I did not find configuration option in menuconfig for that. Will "ecc.bytes=14" setting be taken care by that selection, too? -Matti 2013/11/15 Gupta, Pekon <pe...@ti.com> > Hi Matti, > > > > > > I have recently posted another version of patch-set, (splitting the patch > series into two parts). > > I was able to boot kernel on beaglebone-LT (white) + x16 NAND cape, > > using UBIFS flashed via u-boot using following updates: > > > > (a) Patch to add beaglebone pin-mux support > > > http://lists.denx.de/pipermail/u-boot/2013-September/163881.html > > > > (b) Hack in board-file to configure GPMC for x16 device > > -------------- > > diff --git a/arch/arm/cpu/armv7/am33xx/mem.c > b/arch/arm/cpu/armv7/am33xx/mem.c > > index 56c9e7d..b166a94 100644 > > --- a/arch/arm/cpu/armv7/am33xx/mem.c > > +++ b/arch/arm/cpu/armv7/am33xx/mem.c > > @@ -64,7 +64,7 @@ void gpmc_init(void) > > u32 base = CONFIG_SYS_FLASH_BASE; > > #elif defined(CONFIG_NAND) > > /* configure GPMC for NAND */ > > - const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1, > > + const u32 gpmc_regs[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1 | > 0x1000, > > M_NAND_GPMC_CONFIG2, > > M_NAND_GPMC_CONFIG3, > > M_NAND_GPMC_CONFIG4, > > -------------- > > > > I followed following steps to boot beaglebone from ubifs image.. > > /* Step-1: flash boot-loader on NAND from MMC */ > > fatload mmc 0 0x82000000 MLO > > nand erase 0x0000 0x20000 > > nand write 0x82000000 0x00000 0x20000 > > fatload mmc 0 0x82000000 u-boot.img > > nand erase 0x80000 0x60000 > > nand write 0x82000000 0x80000 0x60000 > > > > /* Step-2: flash file-system on NAND from MMC */ > > fatload mmc 0 0x82000000 ubifs.img > > nand erase 0x780000 0xf880000 > > nand write 0x82000000 0x780000 <file-system image size> > > > > /*Step-3: set boot args */ > > setenv bootargs 'console=ttyO0,115200n8 noinitrd mem=256M > root=ubi0 \ > > rw rootfstype=ubifs > ubi.mtd=7,2048 ip=off init=/init' > > > > /* Step-4: load kernel from MMC and boot */ > > fatload mmc 0 0x82000000 uImage > > bootm 0x82000000 > > > > Important: I'm using 'OMAP_ECC_BCH8_CODE_HW' as ecc-scheme for > > both kernel and u-boot. (ecc.bytes=14) > > > Please let me know if it works for you... > > > > > with regards, pekon > > > > > > ------------------------------ > *From:* matti kaasinen [matti.kaasi...@gmail.com] > *Sent:* Thursday, November 07, 2013 6:11 PM > *To:* Gupta, Pekon > *Cc:* Matthias Fuchs; Rini, Tom; scottw...@freescale.com; > u-boot@lists.denx.de; Balbi, Felipe > *Subject:* Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and > clean-up of OMAP NAND driver > > 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