Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
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.. Few questions.. (1) Which ECC scheme are you using ? - u-boot CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand http://lists.denx.de/pipermail/u-boot/2013-October/164646.html - kernel OMAP_ECC_BCH8_CODE_HW OMAP_ECC_BCH8_CODE_HW_DETECTION_SW Or any other..
(2) Is the problem related to incorrect read/write access to x16 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.
(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)..
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
with regards, pekon
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
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
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@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@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
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@gmail.com] Sent: Thursday, November 07, 2013 6:11 PM To: Gupta, Pekon Cc: Matthias Fuchs; Rini, Tom; scottwood@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.kaasinen@gmail.commailto:matti.kaasinen@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@gmail.commailto: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.commailto: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.commailto: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.demailto: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
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_UserGu... 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@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=256Mroot=ubi0 \
rw rootfstype=ubifsubi.mtd=7,2048 ip=off init=/init'
/* Step-4: load kernel from MMC and boot */ fatload mmc 0 0x82000000 uImage bootm 0x82000000Important: 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@gmail.com] *Sent:* Thursday, November 07, 2013 6:11 PM *To:* Gupta, Pekon *Cc:* Matthias Fuchs; Rini, Tom; scottwood@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.kaasinen@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@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
From: matti kaasinen [matti.kaasinen@gmail.com]
[...]
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?
Yes, the selection of "BCH8" along with "H/W ECC for OMAP devices" should automatically select (OMAP_ECC_BCH8_CODE_HW) which implicitly would configure chip->ecc.bytes = 14.
The layout will also be selected automatically, and this all is in accordance to NAND boot as documented in AM335x TRM [1]. - http://www.ti.com/product/am3359 - [1] latest AM3359 TRM http://www.ti.com/litv/pdf/spruh73i
(a) Section: 26.1.7.4 NAND - This section explains ROM code behavior for booting from NAND. ROM code also fetches device geometry from ONFI params. In addition there is a separate boot mode (called NANDI2C) where device parameters can be fetched from on-board EEPROM.
(b) Figure 26-15. ECC Data Mapping for 2 KB Page and 8b BCH Encoding - This figure explains ecc layout used by ROM code, which is what I'm using as reference for BCH8_HW algorithm.
with regards, pekon
Hi Pekon, Thank you for you advices. http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGu... selecting "Selecting NAND ECC scheme for Linux Kernel" by editing: arch/arm/mach-omap2/board-flash.c and drivers/mtd/nand/omap2.c I try to use Angstrom distribution as a base for my design. Angstrom provides 3.8.13 kernel for beaglebone. There drivers/mtd/nand/omap2.c seems pretty demanding as far as changing chip->ecc.bytes configuration is concerned. That feature seems hard-coded with numeric literal 13 everywhere in that file. So, changing that to 14 does not seem too good idea with my understanding level of that module operation.
Thanks anyway, Matti
2013/11/18 Gupta, Pekon pekon@ti.com
From: matti kaasinen [matti.kaasinen@gmail.com]
[...]
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?
Yes, the selection of "BCH8" along with "H/W ECC for OMAP devices" should automatically select (OMAP_ECC_BCH8_CODE_HW) which implicitly would configure chip->ecc.bytes = 14.
The layout will also be selected automatically, and this all is in accordance to NAND boot as documented in AM335x TRM [1].
- http://www.ti.com/product/am3359
- [1] latest AM3359 TRM
http://www.ti.com/litv/pdf/spruh73i
(a) Section: 26.1.7.4 NAND
- This section explains ROM code behavior for booting from NAND. ROM code also fetches device geometry from ONFI params. In addition there is a separate boot mode (called NANDI2C) where device parameters can be fetched from on-board EEPROM.
(b) Figure 26-15. ECC Data Mapping for 2 KB Page and 8b BCH Encoding
- This figure explains ecc layout used by ROM code, which is what I'm using as reference for BCH8_HW algorithm.
with regards, pekon
Hi Matti,
From: matti kaasinen [mailto:matti.kaasinen@gmail.com] I try to use Angstrom distribution as a base for my design. Angstrom provides 3.8.13 kernel for beaglebone. There drivers/mtd/nand/omap2.c seems pretty demanding as far as changing chip->ecc.bytes configuration is concerned. That feature seems hard-coded with numeric literal 13 everywhere in that file. So, changing that to 14 does not seem too good idea with my understanding level of that module operation.
I have no clue about 3.8.13 kernel provided along with SDK, as there is as separate team in TI to support that. However I know is that beaglebone with NAND cape was not up on that kernel becoz many of the DT and GPMC updates were not present in that kernel version. So even if you take my patches (of u-boot), I doubt that you would be able to boot kernel from beaglebone.
If you need support for 3.8.13 kernel, I suggest you refer to post a query to e2e.ti.com forum. I don't know if you would be able to get any help in this maillist.
But if you plan to use mainline. These patches work fine.
with regards, pekon
participants (2)
-
Gupta, Pekon -
matti kaasinen