Skip to contentSkip to conversation

brcmnand: Clear EXT_ADDR error registers in PIO mode

PATCH Applied Simon Arlott 2 participants 7 messages Nov 16, 2015 – Dec 1, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 brcmnand: Clear EXT_ADDR error registers in PIO mode

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
index 12c6190..2c8f67f 100644
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));
Signature · 4 lines
2.1.4

-- 
Simon Arlott
#1 lore raw

+ bcm-kernel-feedback-list

Quoted 6 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

Patch looks OK. Did you see this problem in practice, or is this just theoretical? I thought the documentation seemed to suggest these registers were cleared together with their non-_EXT counterparts. But implementation definitely trumps documentation for HW.

Brian

Quoted 22 lines
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
index 12c6190..2c8f67f 100644
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));
Signature · 4 lines
2.1.4

-- 
Simon Arlott
#2 lore raw
Quoted 6 lines · Brian Norris

+ bcm-kernel-feedback-list

Quoted 3 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Quoted 8 lines
Quoted 3 lines

Reset them to 0 before reading.

Patch looks OK. Did you see this problem in practice, or is this just theoretical? I thought the documentation seemed to suggest these registers were cleared together with their non-_EXT counterparts. But implementation definitely trumps documentation for HW.

It's theoretical (I don't have 4GB+ flash), but the Broadcom version of the NAND driver does this.

Quoted 25 lines

Brian

Quoted 22 lines
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
index 12c6190..2c8f67f 100644
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));
Signature · 4 lines
2.1.4

-- 
Simon Arlott
Signature · 1 line
Simon Arlott
#3 lore raw
Quoted 11 lines · Simon Arlott
Quoted 10 lines · Brian Norris

+ bcm-kernel-feedback-list

Quoted 6 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

Quoted 7 lines
Quoted 4 lines

Patch looks OK. Did you see this problem in practice, or is this just theoretical? I thought the documentation seemed to suggest these registers were cleared together with their non-_EXT counterparts. But implementation definitely trumps documentation for HW.

It's theoretical (I don't have 4GB+ flash), but the Broadcom version of the NAND driver does this.

That's a funny thing to say :) There never really was a single "Broadcom version" until we settled on upstreaming this one. It's a direct descendant of this [1], which also does not do these writes, and was tested on >4GB flash, though not extensively.

Which product line did you get your driver from, then?

Anyway, unless someone still at Broadcom can confirm or deny, I suppose this patch is mostly harmless and I can take it.

Brian

Quoted 17 lines
Quoted 17 lines

Brian

Quoted 15 lines
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
index 12c6190..2c8f67f 100644
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
Quoted 12 lines
Quoted 8 lines
Quoted 7 lines
drivers/mtd/nand/brcmnand/brcmnand.c +0 -0
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));
Signature · 4 lines
2.1.4

-- 
Simon Arlott
Signature · 1 line
Simon Arlott

[1] https://github.com/Broadcom/stblinux-3.8/blob/master/linux/drivers/mtd/nand/brcmstb_nand.c
Disclaimer: I used to work at Broadcom.

#4 lore raw
Quoted 20 lines · Brian Norris
Quoted 11 lines · Simon Arlott
Quoted 10 lines · Brian Norris

+ bcm-kernel-feedback-list

Quoted 6 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

Quoted 7 lines
Quoted 4 lines

Patch looks OK. Did you see this problem in practice, or is this just theoretical? I thought the documentation seemed to suggest these registers were cleared together with their non-_EXT counterparts. But implementation definitely trumps documentation for HW.

It's theoretical (I don't have 4GB+ flash), but the Broadcom version of the NAND driver does this.

Quoted 6 lines

That's a funny thing to say :) There never really was a single "Broadcom version" until we settled on upstreaming this one. It's a direct descendant of this [1], which also does not do these writes, and was tested on >4GB flash, though not extensively.

Which product line did you get your driver from, then?

I have a file called bcm963xx_4.12L.06B_consumer/kernel/linux/drivers/mtd/brcmnand/brcmnand_base.c:

        /* Clear ECC registers */
        chip->ctrl_write(BCHP_NAND_ECC_CORR_ADDR, 0);
        chip->ctrl_write(BCHP_NAND_ECC_UNC_ADDR, 0);
#if CONFIG_MTD_BRCMNAND_VERSION >= CONFIG_MTD_BRCMNAND_VERS_1_0
        chip->ctrl_write(BCHP_NAND_ECC_CORR_EXT_ADDR, 0);
        chip->ctrl_write(BCHP_NAND_ECC_UNC_EXT_ADDR, 0);

#endif

There's also a workaround (brcmnand_handle_false_read_ecc_unc_errors) that I'm going to write a patch for as it affects my v4.0 device. It'd be useful to know which version of the controller fixes the issue:

       /* Flash chip returns errors 
        || There is a bug in the controller, where if one reads from an erased block that has NOT been written to,
        || this error is raised.  
        || (Writing to OOB area does not have any effect on this bug)
        || The workaround is to also look into the OOB area, to see if they are all 0xFF
        */
Quoted 38 lines

Anyway, unless someone still at Broadcom can confirm or deny, I suppose this patch is mostly harmless and I can take it.

Brian

Quoted 17 lines
Quoted 17 lines

Brian

Quoted 15 lines
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
index 12c6190..2c8f67f 100644
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
Quoted 12 lines
Quoted 8 lines
Quoted 7 lines
drivers/mtd/nand/brcmnand/brcmnand.c +0 -0
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));
Signature · 4 lines
2.1.4

-- 
Simon Arlott
Signature · 1 line
Simon Arlott

[1] https://github.com/Broadcom/stblinux-3.8/blob/master/linux/drivers/mtd/nand/brcmstb_nand.c
Disclaimer: I used to work at Broadcom.

Signature · 1 line
Simon Arlott
#5 lore raw

Hi,

Quoted 30 lines · Simon Arlott
Quoted 20 lines · Brian Norris
Quoted 11 lines · Simon Arlott
Quoted 10 lines · Brian Norris

+ bcm-kernel-feedback-list

Quoted 6 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

Quoted 7 lines
Quoted 4 lines

Patch looks OK. Did you see this problem in practice, or is this just theoretical? I thought the documentation seemed to suggest these registers were cleared together with their non-_EXT counterparts. But implementation definitely trumps documentation for HW.

It's theoretical (I don't have 4GB+ flash), but the Broadcom version of the NAND driver does this.

Quoted 6 lines

That's a funny thing to say :) There never really was a single "Broadcom version" until we settled on upstreaming this one. It's a direct descendant of this [1], which also does not do these writes, and was tested on >4GB flash, though not extensively.

Which product line did you get your driver from, then?

I have a file called bcm963xx_4.12L.06B_consumer/kernel/linux/drivers/mtd/brcmnand/brcmnand_base.c:

Quoted 7 lines
        /* Clear ECC registers */
        chip->ctrl_write(BCHP_NAND_ECC_CORR_ADDR, 0);
        chip->ctrl_write(BCHP_NAND_ECC_UNC_ADDR, 0);
#if CONFIG_MTD_BRCMNAND_VERSION >= CONFIG_MTD_BRCMNAND_VERS_1_0
        chip->ctrl_write(BCHP_NAND_ECC_CORR_EXT_ADDR, 0);
        chip->ctrl_write(BCHP_NAND_ECC_UNC_EXT_ADDR, 0);

#endif

I'd bet it was done without ever actually testing or observing the behavior. The version 1.0 controller is extremely old and most definitely never was used with >4GB NAND.

But since this should be harmless and has some small chance of fixing a bug, I'll take it anyway.

Quoted 10 lines

There's also a workaround (brcmnand_handle_false_read_ecc_unc_errors) that I'm going to write a patch for as it affects my v4.0 device. It'd be useful to know which version of the controller fixes the issue:

       /* Flash chip returns errors 
        || There is a bug in the controller, where if one reads from an erased block that has NOT been written to,
        || this error is raised.  
        || (Writing to OOB area does not have any effect on this bug)
        || The workaround is to also look into the OOB area, to see if they are all 0xFF
        */

That one's pretty ugly... but that's a different story.

Brian

Applied
#6 lore raw
In reply to Simon Arlott
Quoted 15 lines · Simon Arlott

If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR registers will be set to the location of the error and never cleared.

Reset them to 0 before reading.

---
 drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/mtd/nand/brcmnand/brcmnand.c +0 -0
index 12c6190..2c8f67f 100644

drivers/mtd/nand/brcmnand/brcmnand.c static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip, · line 1407

Quoted 8 lines
drivers/mtd/nand/brcmnand/brcmnand.c +2 -0
@@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Clear error addresses */
 	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
+	brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
 
 	brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
 			(host->cs << 16) | ((addr >> 32) & 0xffff));

Applied to l2-mtd.git