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

matti kaasinen matti.kaasinen at gmail.com
Fri Nov 15 17:22:54 CET 2013


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 <pekon at 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.kaasinen at gmail.com]
> *Sent:* Thursday, November 07, 2013 6:11 PM
> *To:* Gupta, Pekon
> *Cc:* Matthias Fuchs; Rini, Tom; scottwood at freescale.com;
> u-boot at 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.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