Re: [U-Boot] Fwd: [PATCH v4] arm: omap3: Add SPL support to cm_t35
Hi Nikita!
(Added Pekon to Cc)
On 03.12.2013 17:07, Nikita Kiryanov wrote:
Hi Stefan,
On 11/27/2013 12:05 PM, Stefan Roese wrote:
Hi Nikita!
On 27.11.2013 10:46, Nikita Kiryanov wrote:
I compiled SPL with your patch and it does boot U-Boot from an SD card. U-Boot functionality seems to be intact too. However, I was unable to install it on the NAND flash. When booting from NAND, SPL does start (the SPL header is displayed), but it fails to load U-Boot with the following errors:
Error: Bad compare! failed
I used similar commands as the ones I use to install X-Loader: CM-T3x # mmc rescan && fatload mmc 0 80a00000 mlo && nandecc hw && nand erase.chip && nand scrub.chip -y && nand write 80a00000 0 30000 CM-T3x # fatload mmc 0 80a00000 u-boot.img && nandecc sw && nand erase 80000 60000 && nand write 80a00000 80000 60000
Perhaps some of the recent changes regarding NAND ECC messed things up?
Might be. I have not tested the latest U-Boot version on this board yet. The last version I did test was:
63c4f17b2f8017d22241522a48c765073b8791b0
Author: Nikita Kiryanov nikita@compulab.co.il 2013-10-16 16:23:29 Committer: Anatolij Gustschin agust@denx.de 2013-11-12 10:12:07 Parent: f109a6e73e6bf177eabedfa5fb622ed4809e145c (omap3_dss: define DSS_ONOFF) Child: 3f0b8b4da58c702c92652981a1e563c129108316 (arm: omap3: Add SPL support to cm_t35) Branches: cm-t35-2013-11-15, cm-t35-2013-11-26, dxr2-v1, master, remotes/origin/master Follows: v2013.10 Precedes: v2014.01-rc1
cm_t35: use scf0403 driver Use scf0403 driver to add scf0403x LCD support for cm-t35 and cm-t3730 boards. Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Acked-by: Igor Grinberg <grinberg@compulab.co.il>With this patch attached. Perhaps you might test this version as well. To see if this works for you too.
I tried the above, but SPL still can't boot U-Boot from NAND. I get an SPL header followed by a stream of "Error: Bad compare! failed".
I'll try to test with the latest U-Boot version (hopefully) later this week.
When based on v2014.01-rc1, SPL itself doesn't boot from NAND (no SPL header or any visible activity when booting from NAND).
Yes. I have now tested this as well. I have been digging into this a bit this morning. And it seems that this patch is causing the regression:
d016dc42 [mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform]
I can only suspect that with this patch applied, U-Boot writes the SPL (MLO) to NAND in an incompatible way for the BootROM. I have switched to 1bit HW ECC of course.
Very strangely, the Technexion TAO3530 board works fine with SPL. Even with current mainline. The only difference I can see right now is, that TAO3530 has an 16bit NAND chip and the CM_T35 has an 8bit NAND chip.
Unfortunately I have to stop debugging this issue now. Perhaps Pekon has an idea on whats going on here. Pekon, do you have an OMAP3530 board with an 8bit NAND chip? Or do you have any other idea, what might cause this problem?
Thanks, Stefan
On Wed, Dec 04, 2013 at 12:38:16PM +0100, Stefan Roese wrote:
Hi Nikita!
(Added Pekon to Cc)
On 03.12.2013 17:07, Nikita Kiryanov wrote:
Hi Stefan,
On 11/27/2013 12:05 PM, Stefan Roese wrote:
Hi Nikita!
On 27.11.2013 10:46, Nikita Kiryanov wrote:
I compiled SPL with your patch and it does boot U-Boot from an SD card. U-Boot functionality seems to be intact too. However, I was unable to install it on the NAND flash. When booting from NAND, SPL does start (the SPL header is displayed), but it fails to load U-Boot with the following errors:
Error: Bad compare! failed
I used similar commands as the ones I use to install X-Loader: CM-T3x # mmc rescan && fatload mmc 0 80a00000 mlo && nandecc hw && nand erase.chip && nand scrub.chip -y && nand write 80a00000 0 30000 CM-T3x # fatload mmc 0 80a00000 u-boot.img && nandecc sw && nand erase 80000 60000 && nand write 80a00000 80000 60000
OK, but why the nandecc switching around? On omap3_beagle _now_ (and for a year or two, but a change from long ago) we do nandecc hw for MLO and U-Boot and get the same 1bit ECC scheme the kernel uses too. I bet the problem is that SPL is loading and expecting the HW scheme, but you wrote in the SW scheme...
On 04.12.2013 12:57, Tom Rini wrote:
On 27.11.2013 10:46, Nikita Kiryanov wrote:
I compiled SPL with your patch and it does boot U-Boot from an SD card. U-Boot functionality seems to be intact too. However, I was unable to install it on the NAND flash. When booting from NAND, SPL does start (the SPL header is displayed), but it fails to load U-Boot with the following errors:
Error: Bad compare! failed
I used similar commands as the ones I use to install X-Loader: CM-T3x # mmc rescan && fatload mmc 0 80a00000 mlo && nandecc hw && nand erase.chip && nand scrub.chip -y && nand write 80a00000 0 30000 CM-T3x # fatload mmc 0 80a00000 u-boot.img && nandecc sw && nand erase 80000 60000 && nand write 80a00000 80000 60000
OK, but why the nandecc switching around? On omap3_beagle _now_ (and for a year or two, but a change from long ago) we do nandecc hw for MLO and U-Boot and get the same 1bit ECC scheme the kernel uses too. I bet the problem is that SPL is loading and expecting the HW scheme, but you wrote in the SW scheme...
No (please read my mail to the end). The problem is that the BootROM doesn't boot the SPL which is written with the latest U-Boot and with 1bit hw ecc. And this works again when the patch I mention is reverted.
Thanks, Stefan
Hi Stefan,
From: Stefan Roese [mailto:sr@denx.de]
On 03.12.2013 17:07, Nikita Kiryanov wrote:
[...]
When based on v2014.01-rc1, SPL itself doesn't boot from NAND (no SPL header or any visible activity when booting from NAND).
Yes. I have now tested this as well. I have been digging into this a bit this morning. And it seems that this patch is causing the regression:
d016dc42 [mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform]
I can only suspect that with this patch applied, U-Boot writes the SPL (MLO) to NAND in an incompatible way for the BootROM. I have switched to 1bit HW ECC of course.
Very strangely, the Technexion TAO3530 board works fine with SPL. Even with current mainline. The only difference I can see right now is, that TAO3530 has an 16bit NAND chip and the CM_T35 has an 8bit NAND chip.
For HAM1_HW this selects ecc-scheme as below.. @@omap_select_ecc_scheme() case OMAP_ECC_HAM1_CODE_HW: + /* define ecc-layout */ + ecclayout->eccbytes = nand->ecc.bytes * eccsteps; + for (i = 0; i < ecclayout->eccbytes; i++) + ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH; + ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH; + ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes - + BADBLOCK_MARKER_LENGTH;
Aah!!... May be I understand the issue.. Reference: As per OMAP3530 TRM given below http://www.ti.com/product/omap3530 http://www.ti.com/litv/pdf/spruf98x Chapter-25: Initialization Sub-topic: Memory Booting Section: 25.4.7.4 NAND Figure 25-19. ECC Locations in NAND Spare Areas For large-page NAND (a) x8 Device: ECC signature starts from byte[1] in OOB (offset of 1 *byte*) (b) x16 Device: ECC signature starts from byte[2] in OOB (offset of 1 *word*)
And in omap_gpmc.c .. BADBLOCK_MARKER_LENGTH = 2. So ECC signature starts from offset ecclayout->eccpos[0] = 0 + BADBLOCK_MARKER_LENGTH = 0x2; which is actually for (b) that is x16 device.
Thus, Technexion TAO3530 board with x16 NAND device is booting correctly, Whereas CM_T35 with x8 NAND device fails..
Unfortunately I have to stop debugging this issue now. Perhaps Pekon has an idea on whats going on here. Pekon, do you have an OMAP3530 board with an 8bit NAND chip? Or do you have any other idea, what might cause this problem?
It's a bug in driver. I should have taken care of device-width while defining the layout. I think this is the issue with HAM1 scheme only, because ROM code has same ecc-layout for other schemes (like BCH8) whether it's a x8 or x16 devices. Please patch following to see if CM_T35 boots fine, with latest u-boot.
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index bf43520..99dfcc6 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -626,7 +626,10 @@ static int omap_select_ecc_scheme(struct nand_chip *nand, /* define ecc-layout */ ecclayout->eccbytes = nand->ecc.bytes * eccsteps; for (i = 0; i < ecclayout->eccbytes; i++) - ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH; + if (nand->options & NAND_BUSWIDTH_16) + ecclayout->eccpos[i] = i + 2; + else + ecclayout->eccpos[i] = i + 1; ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH; ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes - BADBLOCK_MARKER_LENGTH;
Thanks for pointing out this.. Sorry I don't have many OMAP3 boards to boot-test HAM1, so this error crept in. Once you confirm its working, I'll submit a formal patch.
with regards, pekon
Pekon!
On 04.12.2013 13:15, Gupta, Pekon wrote:
Very strangely, the Technexion TAO3530 board works fine with SPL. Even with current mainline. The only difference I can see right now is, that TAO3530 has an 16bit NAND chip and the CM_T35 has an 8bit NAND chip.
For HAM1_HW this selects ecc-scheme as below.. @@omap_select_ecc_scheme() case OMAP_ECC_HAM1_CODE_HW:
/* define ecc-layout */ecclayout->eccbytes = nand->ecc.bytes * eccsteps;for (i = 0; i < ecclayout->eccbytes; i++)ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH;ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH;ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes -BADBLOCK_MARKER_LENGTH;Aah!!... May be I understand the issue.. Reference: As per OMAP3530 TRM given below http://www.ti.com/product/omap3530 http://www.ti.com/litv/pdf/spruf98x Chapter-25: Initialization Sub-topic: Memory Booting Section: 25.4.7.4 NAND Figure 25-19. ECC Locations in NAND Spare Areas For large-page NAND (a) x8 Device: ECC signature starts from byte[1] in OOB (offset of 1 *byte*) (b) x16 Device: ECC signature starts from byte[2] in OOB (offset of 1 *word*)
And in omap_gpmc.c .. BADBLOCK_MARKER_LENGTH = 2. So ECC signature starts from offset ecclayout->eccpos[0] = 0 + BADBLOCK_MARKER_LENGTH = 0x2; which is actually for (b) that is x16 device.
Thus, Technexion TAO3530 board with x16 NAND device is booting correctly, Whereas CM_T35 with x8 NAND device fails..
Sounds like a very good explanation. Thanks!
Unfortunately I have to stop debugging this issue now. Perhaps Pekon has an idea on whats going on here. Pekon, do you have an OMAP3530 board with an 8bit NAND chip? Or do you have any other idea, what might cause this problem?
It's a bug in driver. I should have taken care of device-width while defining the layout. I think this is the issue with HAM1 scheme only, because ROM code has same ecc-layout for other schemes (like BCH8) whether it's a x8 or x16 devices. Please patch following to see if CM_T35 boots fine, with latest u-boot.
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index bf43520..99dfcc6 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -626,7 +626,10 @@ static int omap_select_ecc_scheme(struct nand_chip *nand, /* define ecc-layout */ ecclayout->eccbytes = nand->ecc.bytes * eccsteps; for (i = 0; i < ecclayout->eccbytes; i++)
ecclayout->eccpos[i] = i + BADBLOCK_MARKER_LENGTH;
if (nand->options & NAND_BUSWIDTH_16)ecclayout->eccpos[i] = i + 2;elseecclayout->eccpos[i] = i + 1; ecclayout->oobfree[0].offset = i + BADBLOCK_MARKER_LENGTH; ecclayout->oobfree[0].length = oobsize - ecclayout->eccbytes - BADBLOCK_MARKER_LENGTH;Thanks for pointing out this.. Sorry I don't have many OMAP3 boards to boot-test HAM1, so this error crept in. Once you confirm its working, I'll submit a formal patch.
Yes. This fixes this issue on the cm-t35 board. So please submit a proper patch. :)
Thanks again for this quick fix! Stefan
participants (3)
-
Gupta, Pekon -
Stefan Roese -
Tom Rini