* [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
@ 2005-10-29 20:44 Sergei Shtylylov
2005-10-30 4:36 ` Pete Popov
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Sergei Shtylylov @ 2005-10-29 20:44 UTC (permalink / raw)
To: linux-mtd; +Cc: Pete Popov
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]
Hello.
(This is a follow-up to the older thread:
http://lists.infradead.org/pipermail/linux-mtd/2005-October/013983.html)
Reintroducing the problem: the static bus controller fails to keep
-CE asserted during chip ready delay on read commands (the NAND chip being
used requires this). So, the current driver allows nand_base.c to drive -CE
manually (during the whole sector read). When the PCMCIA driver is enabled
however, occasionally the ECC errors occur on NAND reads. This happens because
PCMCIA driver polls sockets periodically and reads one of the board's
control/status regs (BCSRs) which are accessible via the same static bus
as the NAND flash using the different chip select (and the NOR flash is
accessible the same way), so as the NAND driver forces NAND chip select
asserted and the -RE signal is shared, there's a contention on the static
bus when BCSR or NOR flash is read while we're reading from NAND.
So, we either can't keep interrupts enabled during the whole NAND
sector read (which is hardly acceptable), or have to implement some
interlocking scheme between multiple drivers (which is painful, and makes
me shudder :-).
There's a third way which proved to work: to force -CE asserted only
while we're waiting for NAND chip to become ready after a read command,
disabling interrupts for a maximum of 25 microsecs (according to Toshiba
TC58DVM92A1FT00 flash chip datasheet). So, here's the initial patch which
I'm hoping to have made looking more decently...
WBR, Sergei
[-- Attachment #2: Au1550-NAND-chip-select.patch --]
[-- Type: text/plain, Size: 4949 bytes --]
Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Index: drivers/mtd/nand/au1550nd.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v
retrieving revision 1.12
diff -a -u -p -r1.12 au1550nd.c
--- drivers/mtd/nand/au1550nd.c 23 Sep 2005 01:44:55 -0000 1.12
+++ drivers/mtd/nand/au1550nd.c 29 Oct 2005 20:04:23 -0000
@@ -14,6 +14,7 @@
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/module.h>
+#include <linux/interrupt.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/partitions.h>
@@ -313,6 +314,141 @@ int au1550_device_ready(struct mtd_info
return ret;
}
+/**
+ * au1550_select_chip - control -CE line
+ * Forbid driving -CE manually permitting the NAND controller to do this.
+ * Keeping -CE asserted during the whole sector reads interferes with the
+ * NOR flash and PCMCIA drivers as it causes contention on the static bus.
+ * We only have to hold -CE low for the NAND read commands since the flash
+ * chip needs it to be asserted during chip not ready time but the NAND
+ * controller keeps it released.
+ *
+ * @mtd: MTD device structure
+ * @chip: chipnumber to select, -1 for deselect
+ */
+static void au1550_select_chip(struct mtd_info *mtd, int chip)
+{
+}
+
+/**
+ * au1550_command - Send command to NAND device
+ * @mtd: MTD device structure
+ * @command: the command to be sent
+ * @column: the column address for this command, -1 if none
+ * @page_addr: the page address for this command, -1 if none
+ */
+static void au1550_command(struct mtd_info *mtd, unsigned command, int column, int page_addr)
+{
+ register struct nand_chip *this = mtd->priv;
+ int ce_override = 0, i;
+ ulong flags;
+
+ /* Begin command latch cycle */
+ this->hwcontrol(mtd, NAND_CTL_SETCLE);
+ /*
+ * Write out the command to the device.
+ */
+ if (command == NAND_CMD_SEQIN) {
+ int readcmd;
+
+ if (column >= mtd->oobblock) {
+ /* OOB area */
+ column -= mtd->oobblock;
+ readcmd = NAND_CMD_READOOB;
+ } else if (column < 256) {
+ /* First 256 bytes --> READ0 */
+ readcmd = NAND_CMD_READ0;
+ } else {
+ column -= 256;
+ readcmd = NAND_CMD_READ1;
+ }
+ this->write_byte(mtd, readcmd);
+ }
+ this->write_byte(mtd, command);
+
+ /* Set ALE and clear CLE to start address cycle */
+ this->hwcontrol(mtd, NAND_CTL_CLRCLE);
+
+ if (column != -1 || page_addr != -1) {
+ this->hwcontrol(mtd, NAND_CTL_SETALE);
+
+ /* Serially input address */
+ if (column != -1) {
+ /* Adjust columns for 16 bit buswidth */
+ if (this->options & NAND_BUSWIDTH_16)
+ column >>= 1;
+ this->write_byte(mtd, column);
+ }
+ if (page_addr != -1) {
+ this->write_byte(mtd, (u8)(page_addr & 0xff));
+
+ if (command == NAND_CMD_READ0 ||
+ command == NAND_CMD_READ1 ||
+ command == NAND_CMD_READOOB) {
+ /*
+ * NAND controller will release -CE after
+ * the last address byte is written, so we'll
+ * have to forcibly assert it. No interrupts
+ * are allowed while we do this as we don't
+ * want the NOR flash or PCMCIA drivers to
+ * steal our precious bytes of data...
+ */
+ ce_override = 1;
+ local_irq_save(flags);
+ this->hwcontrol(mtd, NAND_CTL_SETNCE);
+ }
+
+ this->write_byte(mtd, (u8)(page_addr >> 8));
+
+ /* One more address cycle for devices > 32MiB */
+ if (this->chipsize > (32 << 20))
+ this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f));
+ }
+ /* Latch in address */
+ this->hwcontrol(mtd, NAND_CTL_CLRALE);
+ }
+
+ /*
+ * Program and erase have their own busy handlers.
+ * Status and sequential in need no delay.
+ */
+ switch (command) {
+
+ case NAND_CMD_PAGEPROG:
+ case NAND_CMD_ERASE1:
+ case NAND_CMD_ERASE2:
+ case NAND_CMD_SEQIN:
+ case NAND_CMD_STATUS:
+ return;
+
+ case NAND_CMD_RESET:
+ break;
+
+ case NAND_CMD_READ0:
+ case NAND_CMD_READ1:
+ case NAND_CMD_READOOB:
+ /* Check if we're really driving -CE low (just in case) */
+ if (unlikely(!ce_override))
+ break;
+
+ /* Apply a short delay always to ensure that we do wait tWB. */
+ ndelay(100);
+ /* Wait for a chip to become ready... */
+ for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i)
+ udelay(1);
+
+ /* Release -CE and re-enable interrupts. */
+ this->hwcontrol(mtd, NAND_CTL_CLRNCE);
+ local_irq_restore(flags);
+ return;
+ }
+ /* Apply this short delay always to ensure that we do wait tWB. */
+ ndelay(100);
+
+ while(!this->dev_ready(mtd));
+}
+
+
/*
* Main initialization routine
*/
@@ -437,6 +573,9 @@ int __init au1xxx_nand_init (void)
/* Set address of hardware control function */
this->hwcontrol = au1550_hwcontrol;
this->dev_ready = au1550_device_ready;
+ this->select_chip = au1550_select_chip;
+ this->cmdfunc = au1550_command;
+
/* 30 us command delay time */
this->chip_delay = 30;
this->eccmode = NAND_ECC_SOFT;
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-29 20:44 [PATCH] NAND: Fix NAND ECC errors on AMD Au1550 Sergei Shtylylov
@ 2005-10-30 4:36 ` Pete Popov
2005-10-31 7:58 ` Pete Popov
2005-11-01 8:53 ` Pantelis Antoniou
2 siblings, 0 replies; 13+ messages in thread
From: Pete Popov @ 2005-10-30 4:36 UTC (permalink / raw)
To: Sergei Shtylylov; +Cc: linux-mtd
Hi Sergey,
You are using the db1550 board, correct?
I'll test this on the db1550 and the db1200 to make sure it works on
both boards - it's the same nand controller.
Pete
On Sun, 2005-10-30 at 00:44 +0400, Sergei Shtylylov wrote:
> Hello.
>
> (This is a follow-up to the older thread:
> http://lists.infradead.org/pipermail/linux-mtd/2005-October/013983.html)
>
> Reintroducing the problem: the static bus controller fails to keep
> -CE asserted during chip ready delay on read commands (the NAND chip being
> used requires this). So, the current driver allows nand_base.c to drive -CE
> manually (during the whole sector read). When the PCMCIA driver is enabled
> however, occasionally the ECC errors occur on NAND reads. This happens because
> PCMCIA driver polls sockets periodically and reads one of the board's
> control/status regs (BCSRs) which are accessible via the same static bus
> as the NAND flash using the different chip select (and the NOR flash is
> accessible the same way), so as the NAND driver forces NAND chip select
> asserted and the -RE signal is shared, there's a contention on the static
> bus when BCSR or NOR flash is read while we're reading from NAND.
> So, we either can't keep interrupts enabled during the whole NAND
> sector read (which is hardly acceptable), or have to implement some
> interlocking scheme between multiple drivers (which is painful, and makes
> me shudder :-).
> There's a third way which proved to work: to force -CE asserted only
> while we're waiting for NAND chip to become ready after a read command,
> disabling interrupts for a maximum of 25 microsecs (according to Toshiba
> TC58DVM92A1FT00 flash chip datasheet). So, here's the initial patch which
> I'm hoping to have made looking more decently...
>
> WBR, Sergei
>
>
> plain text document attachment (Au1550-NAND-chip-select.patch)
> Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> Index: drivers/mtd/nand/au1550nd.c
> ===================================================================
> RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v
> retrieving revision 1.12
> diff -a -u -p -r1.12 au1550nd.c
> --- drivers/mtd/nand/au1550nd.c 23 Sep 2005 01:44:55 -0000 1.12
> +++ drivers/mtd/nand/au1550nd.c 29 Oct 2005 20:04:23 -0000
> @@ -14,6 +14,7 @@
> #include <linux/slab.h>
> #include <linux/init.h>
> #include <linux/module.h>
> +#include <linux/interrupt.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/partitions.h>
> @@ -313,6 +314,141 @@ int au1550_device_ready(struct mtd_info
> return ret;
> }
>
> +/**
> + * au1550_select_chip - control -CE line
> + * Forbid driving -CE manually permitting the NAND controller to do this.
> + * Keeping -CE asserted during the whole sector reads interferes with the
> + * NOR flash and PCMCIA drivers as it causes contention on the static bus.
> + * We only have to hold -CE low for the NAND read commands since the flash
> + * chip needs it to be asserted during chip not ready time but the NAND
> + * controller keeps it released.
> + *
> + * @mtd: MTD device structure
> + * @chip: chipnumber to select, -1 for deselect
> + */
> +static void au1550_select_chip(struct mtd_info *mtd, int chip)
> +{
> +}
> +
> +/**
> + * au1550_command - Send command to NAND device
> + * @mtd: MTD device structure
> + * @command: the command to be sent
> + * @column: the column address for this command, -1 if none
> + * @page_addr: the page address for this command, -1 if none
> + */
> +static void au1550_command(struct mtd_info *mtd, unsigned command, int column, int page_addr)
> +{
> + register struct nand_chip *this = mtd->priv;
> + int ce_override = 0, i;
> + ulong flags;
> +
> + /* Begin command latch cycle */
> + this->hwcontrol(mtd, NAND_CTL_SETCLE);
> + /*
> + * Write out the command to the device.
> + */
> + if (command == NAND_CMD_SEQIN) {
> + int readcmd;
> +
> + if (column >= mtd->oobblock) {
> + /* OOB area */
> + column -= mtd->oobblock;
> + readcmd = NAND_CMD_READOOB;
> + } else if (column < 256) {
> + /* First 256 bytes --> READ0 */
> + readcmd = NAND_CMD_READ0;
> + } else {
> + column -= 256;
> + readcmd = NAND_CMD_READ1;
> + }
> + this->write_byte(mtd, readcmd);
> + }
> + this->write_byte(mtd, command);
> +
> + /* Set ALE and clear CLE to start address cycle */
> + this->hwcontrol(mtd, NAND_CTL_CLRCLE);
> +
> + if (column != -1 || page_addr != -1) {
> + this->hwcontrol(mtd, NAND_CTL_SETALE);
> +
> + /* Serially input address */
> + if (column != -1) {
> + /* Adjust columns for 16 bit buswidth */
> + if (this->options & NAND_BUSWIDTH_16)
> + column >>= 1;
> + this->write_byte(mtd, column);
> + }
> + if (page_addr != -1) {
> + this->write_byte(mtd, (u8)(page_addr & 0xff));
> +
> + if (command == NAND_CMD_READ0 ||
> + command == NAND_CMD_READ1 ||
> + command == NAND_CMD_READOOB) {
> + /*
> + * NAND controller will release -CE after
> + * the last address byte is written, so we'll
> + * have to forcibly assert it. No interrupts
> + * are allowed while we do this as we don't
> + * want the NOR flash or PCMCIA drivers to
> + * steal our precious bytes of data...
> + */
> + ce_override = 1;
> + local_irq_save(flags);
> + this->hwcontrol(mtd, NAND_CTL_SETNCE);
> + }
> +
> + this->write_byte(mtd, (u8)(page_addr >> 8));
> +
> + /* One more address cycle for devices > 32MiB */
> + if (this->chipsize > (32 << 20))
> + this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f));
> + }
> + /* Latch in address */
> + this->hwcontrol(mtd, NAND_CTL_CLRALE);
> + }
> +
> + /*
> + * Program and erase have their own busy handlers.
> + * Status and sequential in need no delay.
> + */
> + switch (command) {
> +
> + case NAND_CMD_PAGEPROG:
> + case NAND_CMD_ERASE1:
> + case NAND_CMD_ERASE2:
> + case NAND_CMD_SEQIN:
> + case NAND_CMD_STATUS:
> + return;
> +
> + case NAND_CMD_RESET:
> + break;
> +
> + case NAND_CMD_READ0:
> + case NAND_CMD_READ1:
> + case NAND_CMD_READOOB:
> + /* Check if we're really driving -CE low (just in case) */
> + if (unlikely(!ce_override))
> + break;
> +
> + /* Apply a short delay always to ensure that we do wait tWB. */
> + ndelay(100);
> + /* Wait for a chip to become ready... */
> + for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i)
> + udelay(1);
> +
> + /* Release -CE and re-enable interrupts. */
> + this->hwcontrol(mtd, NAND_CTL_CLRNCE);
> + local_irq_restore(flags);
> + return;
> + }
> + /* Apply this short delay always to ensure that we do wait tWB. */
> + ndelay(100);
> +
> + while(!this->dev_ready(mtd));
> +}
> +
> +
> /*
> * Main initialization routine
> */
> @@ -437,6 +573,9 @@ int __init au1xxx_nand_init (void)
> /* Set address of hardware control function */
> this->hwcontrol = au1550_hwcontrol;
> this->dev_ready = au1550_device_ready;
> + this->select_chip = au1550_select_chip;
> + this->cmdfunc = au1550_command;
> +
> /* 30 us command delay time */
> this->chip_delay = 30;
> this->eccmode = NAND_ECC_SOFT;
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-29 20:44 [PATCH] NAND: Fix NAND ECC errors on AMD Au1550 Sergei Shtylylov
2005-10-30 4:36 ` Pete Popov
@ 2005-10-31 7:58 ` Pete Popov
2005-10-31 14:39 ` Leif Lindholm
2005-11-01 8:53 ` Pantelis Antoniou
2 siblings, 1 reply; 13+ messages in thread
From: Pete Popov @ 2005-10-31 7:58 UTC (permalink / raw)
To: Sergei Shtylylov; +Cc: linux-mtd
It works on the Db1550. I need to run a sanity check on the Db1200. If
no one has any objections, I'll commit it in the next couple of days
after I check the Db1200.
Pete
On Sun, 2005-10-30 at 00:44 +0400, Sergei Shtylylov wrote:
> Hello.
>
> (This is a follow-up to the older thread:
> http://lists.infradead.org/pipermail/linux-mtd/2005-October/013983.html)
>
> Reintroducing the problem: the static bus controller fails to keep
> -CE asserted during chip ready delay on read commands (the NAND chip being
> used requires this). So, the current driver allows nand_base.c to drive -CE
> manually (during the whole sector read). When the PCMCIA driver is enabled
> however, occasionally the ECC errors occur on NAND reads. This happens because
> PCMCIA driver polls sockets periodically and reads one of the board's
> control/status regs (BCSRs) which are accessible via the same static bus
> as the NAND flash using the different chip select (and the NOR flash is
> accessible the same way), so as the NAND driver forces NAND chip select
> asserted and the -RE signal is shared, there's a contention on the static
> bus when BCSR or NOR flash is read while we're reading from NAND.
> So, we either can't keep interrupts enabled during the whole NAND
> sector read (which is hardly acceptable), or have to implement some
> interlocking scheme between multiple drivers (which is painful, and makes
> me shudder :-).
> There's a third way which proved to work: to force -CE asserted only
> while we're waiting for NAND chip to become ready after a read command,
> disabling interrupts for a maximum of 25 microsecs (according to Toshiba
> TC58DVM92A1FT00 flash chip datasheet). So, here's the initial patch which
> I'm hoping to have made looking more decently...
>
> WBR, Sergei
>
>
> plain text document attachment (Au1550-NAND-chip-select.patch)
> Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>
> Index: drivers/mtd/nand/au1550nd.c
> ===================================================================
> RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v
> retrieving revision 1.12
> diff -a -u -p -r1.12 au1550nd.c
> --- drivers/mtd/nand/au1550nd.c 23 Sep 2005 01:44:55 -0000 1.12
> +++ drivers/mtd/nand/au1550nd.c 29 Oct 2005 20:04:23 -0000
> @@ -14,6 +14,7 @@
> #include <linux/slab.h>
> #include <linux/init.h>
> #include <linux/module.h>
> +#include <linux/interrupt.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/partitions.h>
> @@ -313,6 +314,141 @@ int au1550_device_ready(struct mtd_info
> return ret;
> }
>
> +/**
> + * au1550_select_chip - control -CE line
> + * Forbid driving -CE manually permitting the NAND controller to do this.
> + * Keeping -CE asserted during the whole sector reads interferes with the
> + * NOR flash and PCMCIA drivers as it causes contention on the static bus.
> + * We only have to hold -CE low for the NAND read commands since the flash
> + * chip needs it to be asserted during chip not ready time but the NAND
> + * controller keeps it released.
> + *
> + * @mtd: MTD device structure
> + * @chip: chipnumber to select, -1 for deselect
> + */
> +static void au1550_select_chip(struct mtd_info *mtd, int chip)
> +{
> +}
> +
> +/**
> + * au1550_command - Send command to NAND device
> + * @mtd: MTD device structure
> + * @command: the command to be sent
> + * @column: the column address for this command, -1 if none
> + * @page_addr: the page address for this command, -1 if none
> + */
> +static void au1550_command(struct mtd_info *mtd, unsigned command, int column, int page_addr)
> +{
> + register struct nand_chip *this = mtd->priv;
> + int ce_override = 0, i;
> + ulong flags;
> +
> + /* Begin command latch cycle */
> + this->hwcontrol(mtd, NAND_CTL_SETCLE);
> + /*
> + * Write out the command to the device.
> + */
> + if (command == NAND_CMD_SEQIN) {
> + int readcmd;
> +
> + if (column >= mtd->oobblock) {
> + /* OOB area */
> + column -= mtd->oobblock;
> + readcmd = NAND_CMD_READOOB;
> + } else if (column < 256) {
> + /* First 256 bytes --> READ0 */
> + readcmd = NAND_CMD_READ0;
> + } else {
> + column -= 256;
> + readcmd = NAND_CMD_READ1;
> + }
> + this->write_byte(mtd, readcmd);
> + }
> + this->write_byte(mtd, command);
> +
> + /* Set ALE and clear CLE to start address cycle */
> + this->hwcontrol(mtd, NAND_CTL_CLRCLE);
> +
> + if (column != -1 || page_addr != -1) {
> + this->hwcontrol(mtd, NAND_CTL_SETALE);
> +
> + /* Serially input address */
> + if (column != -1) {
> + /* Adjust columns for 16 bit buswidth */
> + if (this->options & NAND_BUSWIDTH_16)
> + column >>= 1;
> + this->write_byte(mtd, column);
> + }
> + if (page_addr != -1) {
> + this->write_byte(mtd, (u8)(page_addr & 0xff));
> +
> + if (command == NAND_CMD_READ0 ||
> + command == NAND_CMD_READ1 ||
> + command == NAND_CMD_READOOB) {
> + /*
> + * NAND controller will release -CE after
> + * the last address byte is written, so we'll
> + * have to forcibly assert it. No interrupts
> + * are allowed while we do this as we don't
> + * want the NOR flash or PCMCIA drivers to
> + * steal our precious bytes of data...
> + */
> + ce_override = 1;
> + local_irq_save(flags);
> + this->hwcontrol(mtd, NAND_CTL_SETNCE);
> + }
> +
> + this->write_byte(mtd, (u8)(page_addr >> 8));
> +
> + /* One more address cycle for devices > 32MiB */
> + if (this->chipsize > (32 << 20))
> + this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f));
> + }
> + /* Latch in address */
> + this->hwcontrol(mtd, NAND_CTL_CLRALE);
> + }
> +
> + /*
> + * Program and erase have their own busy handlers.
> + * Status and sequential in need no delay.
> + */
> + switch (command) {
> +
> + case NAND_CMD_PAGEPROG:
> + case NAND_CMD_ERASE1:
> + case NAND_CMD_ERASE2:
> + case NAND_CMD_SEQIN:
> + case NAND_CMD_STATUS:
> + return;
> +
> + case NAND_CMD_RESET:
> + break;
> +
> + case NAND_CMD_READ0:
> + case NAND_CMD_READ1:
> + case NAND_CMD_READOOB:
> + /* Check if we're really driving -CE low (just in case) */
> + if (unlikely(!ce_override))
> + break;
> +
> + /* Apply a short delay always to ensure that we do wait tWB. */
> + ndelay(100);
> + /* Wait for a chip to become ready... */
> + for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i)
> + udelay(1);
> +
> + /* Release -CE and re-enable interrupts. */
> + this->hwcontrol(mtd, NAND_CTL_CLRNCE);
> + local_irq_restore(flags);
> + return;
> + }
> + /* Apply this short delay always to ensure that we do wait tWB. */
> + ndelay(100);
> +
> + while(!this->dev_ready(mtd));
> +}
> +
> +
> /*
> * Main initialization routine
> */
> @@ -437,6 +573,9 @@ int __init au1xxx_nand_init (void)
> /* Set address of hardware control function */
> this->hwcontrol = au1550_hwcontrol;
> this->dev_ready = au1550_device_ready;
> + this->select_chip = au1550_select_chip;
> + this->cmdfunc = au1550_command;
> +
> /* 30 us command delay time */
> this->chip_delay = 30;
> this->eccmode = NAND_ECC_SOFT;
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-31 7:58 ` Pete Popov
@ 2005-10-31 14:39 ` Leif Lindholm
2005-10-31 16:00 ` Pete Popov
2005-10-31 17:55 ` Sergei Shtylylov
0 siblings, 2 replies; 13+ messages in thread
From: Leif Lindholm @ 2005-10-31 14:39 UTC (permalink / raw)
To: ppopov; +Cc: Sergei Shtylylov, linux-mtd
On Sun, 2005-10-30 at 23:58 -0800, Pete Popov wrote:
> It works on the Db1550. I need to run a sanity check on the Db1200. If
> no one has any objections, I'll commit it in the next couple of days
> after I check the Db1200.
Just a comment (forgot to post this last time around):
At least one of the chips we're using - identified as
"NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
seems to also need the CS manually asserted during a READID operation.
This made the if-statements ridicilously long, so I added a case
statement and a variable keeping track of wether or not to force-enable
CS to the au1550_command function.
If there is any interest, I could post a patch, but am unsure of the
correct way. Should I send a new patch against cvs HEAD containing my
trivial tweak as well as Sergeis modifications, or...?
regards
/
Leif
> Pete
>
> On Sun, 2005-10-30 at 00:44 +0400, Sergei Shtylylov wrote:
> > Hello.
> >
> > (This is a follow-up to the older thread:
> > http://lists.infradead.org/pipermail/linux-mtd/2005-October/013983.html)
> >
> > Reintroducing the problem: the static bus controller fails to keep
> > -CE asserted during chip ready delay on read commands (the NAND chip being
> > used requires this). So, the current driver allows nand_base.c to drive -CE
> > manually (during the whole sector read). When the PCMCIA driver is enabled
> > however, occasionally the ECC errors occur on NAND reads. This happens because
> > PCMCIA driver polls sockets periodically and reads one of the board's
> > control/status regs (BCSRs) which are accessible via the same static bus
> > as the NAND flash using the different chip select (and the NOR flash is
> > accessible the same way), so as the NAND driver forces NAND chip select
> > asserted and the -RE signal is shared, there's a contention on the static
> > bus when BCSR or NOR flash is read while we're reading from NAND.
> > So, we either can't keep interrupts enabled during the whole NAND
> > sector read (which is hardly acceptable), or have to implement some
> > interlocking scheme between multiple drivers (which is painful, and makes
> > me shudder :-).
> > There's a third way which proved to work: to force -CE asserted only
> > while we're waiting for NAND chip to become ready after a read command,
> > disabling interrupts for a maximum of 25 microsecs (according to Toshiba
> > TC58DVM92A1FT00 flash chip datasheet). So, here's the initial patch which
> > I'm hoping to have made looking more decently...
> >
> > WBR, Sergei
> >
> >
> > plain text document attachment (Au1550-NAND-chip-select.patch)
> > Signed-off-by: Konstantin Baydarov <kbaidarov@ru.mvista.com>
> > Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
> >
> > Index: drivers/mtd/nand/au1550nd.c
> > ===================================================================
> > RCS file: /home/cvs/mtd/drivers/mtd/nand/au1550nd.c,v
> > retrieving revision 1.12
> > diff -a -u -p -r1.12 au1550nd.c
> > --- drivers/mtd/nand/au1550nd.c 23 Sep 2005 01:44:55 -0000 1.12
> > +++ drivers/mtd/nand/au1550nd.c 29 Oct 2005 20:04:23 -0000
> > @@ -14,6 +14,7 @@
> > #include <linux/slab.h>
> > #include <linux/init.h>
> > #include <linux/module.h>
> > +#include <linux/interrupt.h>
> > #include <linux/mtd/mtd.h>
> > #include <linux/mtd/nand.h>
> > #include <linux/mtd/partitions.h>
> > @@ -313,6 +314,141 @@ int au1550_device_ready(struct mtd_info
> > return ret;
> > }
> >
> > +/**
> > + * au1550_select_chip - control -CE line
> > + * Forbid driving -CE manually permitting the NAND controller to do this.
> > + * Keeping -CE asserted during the whole sector reads interferes with the
> > + * NOR flash and PCMCIA drivers as it causes contention on the static bus.
> > + * We only have to hold -CE low for the NAND read commands since the flash
> > + * chip needs it to be asserted during chip not ready time but the NAND
> > + * controller keeps it released.
> > + *
> > + * @mtd: MTD device structure
> > + * @chip: chipnumber to select, -1 for deselect
> > + */
> > +static void au1550_select_chip(struct mtd_info *mtd, int chip)
> > +{
> > +}
> > +
> > +/**
> > + * au1550_command - Send command to NAND device
> > + * @mtd: MTD device structure
> > + * @command: the command to be sent
> > + * @column: the column address for this command, -1 if none
> > + * @page_addr: the page address for this command, -1 if none
> > + */
> > +static void au1550_command(struct mtd_info *mtd, unsigned command, int column, int page_addr)
> > +{
> > + register struct nand_chip *this = mtd->priv;
> > + int ce_override = 0, i;
> > + ulong flags;
> > +
> > + /* Begin command latch cycle */
> > + this->hwcontrol(mtd, NAND_CTL_SETCLE);
> > + /*
> > + * Write out the command to the device.
> > + */
> > + if (command == NAND_CMD_SEQIN) {
> > + int readcmd;
> > +
> > + if (column >= mtd->oobblock) {
> > + /* OOB area */
> > + column -= mtd->oobblock;
> > + readcmd = NAND_CMD_READOOB;
> > + } else if (column < 256) {
> > + /* First 256 bytes --> READ0 */
> > + readcmd = NAND_CMD_READ0;
> > + } else {
> > + column -= 256;
> > + readcmd = NAND_CMD_READ1;
> > + }
> > + this->write_byte(mtd, readcmd);
> > + }
> > + this->write_byte(mtd, command);
> > +
> > + /* Set ALE and clear CLE to start address cycle */
> > + this->hwcontrol(mtd, NAND_CTL_CLRCLE);
> > +
> > + if (column != -1 || page_addr != -1) {
> > + this->hwcontrol(mtd, NAND_CTL_SETALE);
> > +
> > + /* Serially input address */
> > + if (column != -1) {
> > + /* Adjust columns for 16 bit buswidth */
> > + if (this->options & NAND_BUSWIDTH_16)
> > + column >>= 1;
> > + this->write_byte(mtd, column);
> > + }
> > + if (page_addr != -1) {
> > + this->write_byte(mtd, (u8)(page_addr & 0xff));
> > +
> > + if (command == NAND_CMD_READ0 ||
> > + command == NAND_CMD_READ1 ||
> > + command == NAND_CMD_READOOB) {
> > + /*
> > + * NAND controller will release -CE after
> > + * the last address byte is written, so we'll
> > + * have to forcibly assert it. No interrupts
> > + * are allowed while we do this as we don't
> > + * want the NOR flash or PCMCIA drivers to
> > + * steal our precious bytes of data...
> > + */
> > + ce_override = 1;
> > + local_irq_save(flags);
> > + this->hwcontrol(mtd, NAND_CTL_SETNCE);
> > + }
> > +
> > + this->write_byte(mtd, (u8)(page_addr >> 8));
> > +
> > + /* One more address cycle for devices > 32MiB */
> > + if (this->chipsize > (32 << 20))
> > + this->write_byte(mtd, (u8)((page_addr >> 16) & 0x0f));
> > + }
> > + /* Latch in address */
> > + this->hwcontrol(mtd, NAND_CTL_CLRALE);
> > + }
> > +
> > + /*
> > + * Program and erase have their own busy handlers.
> > + * Status and sequential in need no delay.
> > + */
> > + switch (command) {
> > +
> > + case NAND_CMD_PAGEPROG:
> > + case NAND_CMD_ERASE1:
> > + case NAND_CMD_ERASE2:
> > + case NAND_CMD_SEQIN:
> > + case NAND_CMD_STATUS:
> > + return;
> > +
> > + case NAND_CMD_RESET:
> > + break;
> > +
> > + case NAND_CMD_READ0:
> > + case NAND_CMD_READ1:
> > + case NAND_CMD_READOOB:
> > + /* Check if we're really driving -CE low (just in case) */
> > + if (unlikely(!ce_override))
> > + break;
> > +
> > + /* Apply a short delay always to ensure that we do wait tWB. */
> > + ndelay(100);
> > + /* Wait for a chip to become ready... */
> > + for (i = this->chip_delay; !this->dev_ready(mtd) && i > 0; --i)
> > + udelay(1);
> > +
> > + /* Release -CE and re-enable interrupts. */
> > + this->hwcontrol(mtd, NAND_CTL_CLRNCE);
> > + local_irq_restore(flags);
> > + return;
> > + }
> > + /* Apply this short delay always to ensure that we do wait tWB. */
> > + ndelay(100);
> > +
> > + while(!this->dev_ready(mtd));
> > +}
> > +
> > +
> > /*
> > * Main initialization routine
> > */
> > @@ -437,6 +573,9 @@ int __init au1xxx_nand_init (void)
> > /* Set address of hardware control function */
> > this->hwcontrol = au1550_hwcontrol;
> > this->dev_ready = au1550_device_ready;
> > + this->select_chip = au1550_select_chip;
> > + this->cmdfunc = au1550_command;
> > +
> > /* 30 us command delay time */
> > this->chip_delay = 30;
> > this->eccmode = NAND_ECC_SOFT;
> >
> >
> >
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Leif Lindholm <leif.lindholm@i3micro.com>
I3 Micro Technology AB
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-31 14:39 ` Leif Lindholm
@ 2005-10-31 16:00 ` Pete Popov
2005-11-01 14:49 ` Leif Lindholm
2005-10-31 17:55 ` Sergei Shtylylov
1 sibling, 1 reply; 13+ messages in thread
From: Pete Popov @ 2005-10-31 16:00 UTC (permalink / raw)
To: Leif Lindholm; +Cc: Sergei Shtylylov, linux-mtd
On Mon, 2005-10-31 at 15:39 +0100, Leif Lindholm wrote:
> On Sun, 2005-10-30 at 23:58 -0800, Pete Popov wrote:
> > It works on the Db1550. I need to run a sanity check on the Db1200. If
> > no one has any objections, I'll commit it in the next couple of days
> > after I check the Db1200.
>
> Just a comment (forgot to post this last time around):
> At least one of the chips we're using - identified as
> "NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
> seems to also need the CS manually asserted during a READID operation.
>
> This made the if-statements ridicilously long, so I added a case
> statement and a variable keeping track of wether or not to force-enable
> CS to the au1550_command function.
>
> If there is any interest, I could post a patch, but am unsure of the
> correct way. Should I send a new patch against cvs HEAD containing my
> trivial tweak as well as Sergeis modifications, or...?
Send an incremental patch on top of Sergey's patch if you can.
Pete
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-31 16:00 ` Pete Popov
@ 2005-11-01 14:49 ` Leif Lindholm
2005-11-01 15:29 ` Sergei Shtylylov
0 siblings, 1 reply; 13+ messages in thread
From: Leif Lindholm @ 2005-11-01 14:49 UTC (permalink / raw)
To: ppopov; +Cc: Sergei Shtylylov, linux-mtd
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Mon, 2005-10-31 at 08:00 -0800, Pete Popov wrote:
> > Just a comment (forgot to post this last time around):
> > At least one of the chips we're using - identified as
> > "NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
> > seems to also need the CS manually asserted during a READID operation.
> >
> > This made the if-statements ridicilously long, so I added a case
> > statement and a variable keeping track of wether or not to force-enable
> > CS to the au1550_command function.
> >
> > If there is any interest, I could post a patch, but am unsure of the
> > correct way. Should I send a new patch against cvs HEAD containing my
> > trivial tweak as well as Sergeis modifications, or...?
>
> Send an incremental patch on top of Sergey's patch if you can.
Attached is an incremental patch on top of Sergeys latest patch
(yesterday). Is that's ok, or should I do the same for the old one?
/
Leif
[-- Attachment #2: au1550nd-READID-force-CE.patch --]
[-- Type: text/x-patch, Size: 2264 bytes --]
--- mtd/drivers/mtd/nand/au1550nd.c 2005-10-31 18:37:29.000000000 +0100
+++ mtd-new/drivers/mtd/nand/au1550nd.c 2005-11-01 15:39:43.000000000 +0100
@@ -343,6 +343,16 @@ static void au1550_command(struct mtd_in
int ce_override = 0, i;
ulong flags;
+ /* Decide wether command needs to force-enable CE or not */
+ switch (command) {
+ case NAND_CMD_READ0:
+ case NAND_CMD_READ1:
+ case NAND_CMD_READOOB:
+ case NAND_CMD_READID:
+ ce_override = 1;
+ break;
+ }
+
/* Begin command latch cycle */
this->hwcontrol(mtd, NAND_CTL_SETCLE);
/*
@@ -382,9 +392,7 @@ static void au1550_command(struct mtd_in
if (page_addr != -1) {
this->write_byte(mtd, (u8)(page_addr & 0xff));
- if (command == NAND_CMD_READ0 ||
- command == NAND_CMD_READ1 ||
- command == NAND_CMD_READOOB) {
+ if (ce_override) {
/*
* NAND controller will release -CE after
* the last address byte is written, so we'll
@@ -393,7 +401,6 @@ static void au1550_command(struct mtd_in
* want the NOR flash or PCMCIA drivers to
* steal our precious bytes of data...
*/
- ce_override = 1;
local_irq_save(flags);
this->hwcontrol(mtd, NAND_CTL_SETNCE);
}
@@ -412,25 +419,7 @@ static void au1550_command(struct mtd_in
* Program and erase have their own busy handlers.
* Status and sequential in need no delay.
*/
- switch (command) {
-
- case NAND_CMD_PAGEPROG:
- case NAND_CMD_ERASE1:
- case NAND_CMD_ERASE2:
- case NAND_CMD_SEQIN:
- case NAND_CMD_STATUS:
- return;
-
- case NAND_CMD_RESET:
- break;
-
- case NAND_CMD_READ0:
- case NAND_CMD_READ1:
- case NAND_CMD_READOOB:
- /* Check if we're really driving -CE low (just in case) */
- if (unlikely(!ce_override))
- break;
-
+ if (ce_override) {
/* Apply a short delay always to ensure that we do wait tWB. */
ndelay(100);
/* Wait for a chip to become ready... */
@@ -442,6 +431,19 @@ static void au1550_command(struct mtd_in
local_irq_restore(flags);
return;
}
+
+ switch (command) {
+
+ case NAND_CMD_PAGEPROG:
+ case NAND_CMD_ERASE1:
+ case NAND_CMD_ERASE2:
+ case NAND_CMD_SEQIN:
+ case NAND_CMD_STATUS:
+ return;
+
+ case NAND_CMD_RESET:
+ break;
+ }
/* Apply this short delay always to ensure that we do wait tWB. */
ndelay(100);
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-11-01 14:49 ` Leif Lindholm
@ 2005-11-01 15:29 ` Sergei Shtylylov
2005-11-01 15:50 ` Leif Lindholm
0 siblings, 1 reply; 13+ messages in thread
From: Sergei Shtylylov @ 2005-11-01 15:29 UTC (permalink / raw)
To: Leif Lindholm, linux-mtd
Hello.
Leif Lindholm wrote:
> On Mon, 2005-10-31 at 08:00 -0800, Pete Popov wrote:
>
>>>Just a comment (forgot to post this last time around):
>>>At least one of the chips we're using - identified as
>>>"NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
>>>seems to also need the CS manually asserted during a READID operation.
>>>
>>>This made the if-statements ridicilously long, so I added a case
>>>statement and a variable keeping track of wether or not to force-enable
>>>CS to the au1550_command function.
>>>
>>>If there is any interest, I could post a patch, but am unsure of the
>>>correct way. Should I send a new patch against cvs HEAD containing my
>>>trivial tweak as well as Sergeis modifications, or...?
>>
>>Send an incremental patch on top of Sergey's patch if you can.
>
>
> Attached is an incremental patch on top of Sergeys latest patch
> (yesterday). Is that's ok, or should I do the same for the old one?
Alas, I have to NAK your patch.
> ------------------------------------------------------------------------
>
> --- mtd/drivers/mtd/nand/au1550nd.c 2005-10-31 18:37:29.000000000 +0100
> +++ mtd-new/drivers/mtd/nand/au1550nd.c 2005-11-01 15:39:43.000000000 +0100
> @@ -343,6 +343,16 @@ static void au1550_command(struct mtd_in
> int ce_override = 0, i;
> ulong flags;
>
> + /* Decide wether command needs to force-enable CE or not */
> + switch (command) {
> + case NAND_CMD_READ0:
> + case NAND_CMD_READ1:
> + case NAND_CMD_READOOB:
> + case NAND_CMD_READID:
> + ce_override = 1;
> + break;
> + }
> +
> /* Begin command latch cycle */
> this->hwcontrol(mtd, NAND_CTL_SETCLE);
> /*
> @@ -382,9 +392,7 @@ static void au1550_command(struct mtd_in
> if (page_addr != -1) {
> this->write_byte(mtd, (u8)(page_addr & 0xff));
>
> - if (command == NAND_CMD_READ0 ||
> - command == NAND_CMD_READ1 ||
> - command == NAND_CMD_READOOB) {
> + if (ce_override) {
Note, that with NAND_CMD_READID page_addr of -1 is always passed (so we
only write out the 1-byte column address) on the address phase, and we just
won't get there for READID command....
> /*
> * NAND controller will release -CE after
> * the last address byte is written, so we'll
> @@ -393,7 +401,6 @@ static void au1550_command(struct mtd_in
> * want the NOR flash or PCMCIA drivers to
> * steal our precious bytes of data...
> */
> - ce_override = 1;
> local_irq_save(flags);
Therefore, neither -CE wil be overridden nor local_irq_save() be executed
for READID case...
> this->hwcontrol(mtd, NAND_CTL_SETNCE);
> }
> @@ -412,25 +419,7 @@ static void au1550_command(struct mtd_in
> * Program and erase have their own busy handlers.
> * Status and sequential in need no delay.
> */
> - switch (command) {
> -
> - case NAND_CMD_PAGEPROG:
> - case NAND_CMD_ERASE1:
> - case NAND_CMD_ERASE2:
> - case NAND_CMD_SEQIN:
> - case NAND_CMD_STATUS:
> - return;
> -
> - case NAND_CMD_RESET:
> - break;
> -
> - case NAND_CMD_READ0:
> - case NAND_CMD_READ1:
> - case NAND_CMD_READOOB:
> - /* Check if we're really driving -CE low (just in case) */
> - if (unlikely(!ce_override))
> - break;
> -
> + if (ce_override) {
> /* Apply a short delay always to ensure that we do wait tWB. */
> ndelay(100);
> /* Wait for a chip to become ready... */
> @@ -442,6 +431,19 @@ static void au1550_command(struct mtd_in
> local_irq_restore(flags);
... and later you get the CPU flags corrupted.
> return;
> }
> +
> + switch (command) {
> +
> + case NAND_CMD_PAGEPROG:
> + case NAND_CMD_ERASE1:
> + case NAND_CMD_ERASE2:
> + case NAND_CMD_SEQIN:
> + case NAND_CMD_STATUS:
> + return;
> +
> + case NAND_CMD_RESET:
> + break;
> + }
> /* Apply this short delay always to ensure that we do wait tWB. */
> ndelay(100);
Has your READID problem arisen with or without my patch?
WBR, Sergei
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-11-01 15:29 ` Sergei Shtylylov
@ 2005-11-01 15:50 ` Leif Lindholm
2005-11-01 16:31 ` Sergei Shtylylov
0 siblings, 1 reply; 13+ messages in thread
From: Leif Lindholm @ 2005-11-01 15:50 UTC (permalink / raw)
To: Sergei Shtylylov; +Cc: linux-mtd
On Tue, 2005-11-01 at 18:29 +0300, Sergei Shtylylov wrote:
> > Attached is an incremental patch on top of Sergeys latest patch
> > (yesterday). Is that's ok, or should I do the same for the old one?
>
> Alas, I have to NAK your patch.
Ok.
> Note, that with NAND_CMD_READID page_addr of -1 is always passed (so we
> only write out the 1-byte column address) on the address phase, and we just
> won't get there for READID command....
> Therefore, neither -CE wil be overridden nor local_irq_save() be executed
> for READID case...
Well, I guess I cheated a bit.
In the more well-tested version of the driver (using your older patch),
I actually do the force-assert for (column != -1) as well.
When doing the merge here, I must have messed up something while testing
and out of pure confusion decided that I didn't have to include that
part.
> > + if (ce_override) {
> > /* Apply a short delay always to ensure that we do wait tWB. */
> > ndelay(100);
> > /* Wait for a chip to become ready... */
> > @@ -442,6 +431,19 @@ static void au1550_command(struct mtd_in
> > local_irq_restore(flags);
>
> ... and later you get the CPU flags corrupted.
Oops...
See above.
> Has your READID problem arisen with or without my patch?
Your patch fixed the problem of a collision with the NOR flash.
But only after I added the READID force-assert. Before that it caused
the NAND chip to stop being detected.
regards
/
Leif
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-11-01 15:50 ` Leif Lindholm
@ 2005-11-01 16:31 ` Sergei Shtylylov
0 siblings, 0 replies; 13+ messages in thread
From: Sergei Shtylylov @ 2005-11-01 16:31 UTC (permalink / raw)
To: linux-mtd
Hello.
Leif Lindholm wrote:
>> Note, that with NAND_CMD_READID page_addr of -1 is always passed (so we
>>only write out the 1-byte column address) on the address phase, and we just
>>won't get there for READID command....
>> Therefore, neither -CE wil be overridden nor local_irq_save() be executed
>>for READID case...
> Well, I guess I cheated a bit.
Especially with separation of setting ce_override to 1 and a real -CE
override -- that's a potentially dangerous trick. :-)
> In the more well-tested version of the driver (using your older patch),
Do you mean the patch originally posted? I wasn't participating in it then
(woulnd't even have posted such stuff :-).
> I actually do the force-assert for (column != -1) as well.
I guess, you'd better set ce_override to 1 at the exact place where you
start to override -CE.
>> Has your READID problem arisen with or without my patch?
> Your patch fixed the problem of a collision with the NOR flash.
> But only after I added the READID force-assert. Before that it caused
> the NAND chip to stop being detected.
Kind of strange. I have the datasheet of that Samsung part before me, and
it doesn't even have R/-B line on the Read ID timing diagrams...
WBR, Sergei
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-31 14:39 ` Leif Lindholm
2005-10-31 16:00 ` Pete Popov
@ 2005-10-31 17:55 ` Sergei Shtylylov
1 sibling, 0 replies; 13+ messages in thread
From: Sergei Shtylylov @ 2005-10-31 17:55 UTC (permalink / raw)
To: Leif Lindholm, linux-mtd
Hello.
Leif Lindholm wrote:
> On Sun, 2005-10-30 at 23:58 -0800, Pete Popov wrote:
>
>>It works on the Db1550. I need to run a sanity check on the Db1200. If
>>no one has any objections, I'll commit it in the next couple of days
>>after I check the Db1200.
>
>
> Just a comment (forgot to post this last time around):
> At least one of the chips we're using - identified as
> "NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)"
> seems to also need the CS manually asserted during a READID operation.
Well, the static bus controller seems to hold -CE asserted itself (at
least from what can be seen in the timing diagrams from the Au1550 datasheet)
-- presumably until it has to release it in favor of servicing I/O via another
chip select. That's the point that causes some concern about my patch since I
was unable to assure myself that the chip can tolerate -CS release (and
re-assertion later) during the sector read and not to interrupt the read.
However, the patch proved working, so...
> This made the if-statements ridicilously long, so I added a case
> statement and a variable keeping track of wether or not to force-enable
> CS to the au1550_command function.
Hm, at what point -CE should be forced low for ID read?
WBR, Sergei
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-10-29 20:44 [PATCH] NAND: Fix NAND ECC errors on AMD Au1550 Sergei Shtylylov
2005-10-30 4:36 ` Pete Popov
2005-10-31 7:58 ` Pete Popov
@ 2005-11-01 8:53 ` Pantelis Antoniou
2005-11-01 12:49 ` Sergei Shtylylov
2 siblings, 1 reply; 13+ messages in thread
From: Pantelis Antoniou @ 2005-11-01 8:53 UTC (permalink / raw)
To: Sergei Shtylylov; +Cc: linux-mtd, Pete Popov
Sergei Shtylylov wrote:
[snip]
I have the exact same problem on a different board, which I
fix by disabling interrupts (and hacking out the yield() call
in nand_base.c).
I'd very much like to see it addressed properly.
Regards
Pantelis
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-11-01 8:53 ` Pantelis Antoniou
@ 2005-11-01 12:49 ` Sergei Shtylylov
2005-11-01 13:00 ` Pantelis Antoniou
0 siblings, 1 reply; 13+ messages in thread
From: Sergei Shtylylov @ 2005-11-01 12:49 UTC (permalink / raw)
To: Pantelis Antoniou, linux-mtd
Pantelis Antoniou wrote:
> Sergei Shtylylov wrote:
>
> [snip]
>
> I have the exact same problem on a different board, which I
> fix by disabling interrupts (and hacking out the yield() call
> in nand_base.c).
In my understanding, you can't yield() as the other process may be
accessing NOR flash at the same time, so we'll get what we're trying to
avoid.
> I'd very much like to see it addressed properly.
>
> Regards
>
> Pantelis
WBR, Sergei
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH] NAND: Fix NAND ECC errors on AMD Au1550
2005-11-01 12:49 ` Sergei Shtylylov
@ 2005-11-01 13:00 ` Pantelis Antoniou
0 siblings, 0 replies; 13+ messages in thread
From: Pantelis Antoniou @ 2005-11-01 13:00 UTC (permalink / raw)
To: Sergei Shtylylov; +Cc: linux-mtd
Sergei Shtylylov wrote:
> Pantelis Antoniou wrote:
>
>> Sergei Shtylylov wrote:
>>
>> [snip]
>>
>> I have the exact same problem on a different board, which I
>> fix by disabling interrupts (and hacking out the yield() call
>> in nand_base.c).
>
>
> In my understanding, you can't yield() as the other process may be
> accessing NOR flash at the same time, so we'll get what we're trying to
> avoid.
>
Yes I know, it's not the proper way to address it, that's why I didn't
bother submitting it.
>> I'd very much like to see it addressed properly.
>>
Pantelis
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2005-11-01 16:29 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-29 20:44 [PATCH] NAND: Fix NAND ECC errors on AMD Au1550 Sergei Shtylylov
2005-10-30 4:36 ` Pete Popov
2005-10-31 7:58 ` Pete Popov
2005-10-31 14:39 ` Leif Lindholm
2005-10-31 16:00 ` Pete Popov
2005-11-01 14:49 ` Leif Lindholm
2005-11-01 15:29 ` Sergei Shtylylov
2005-11-01 15:50 ` Leif Lindholm
2005-11-01 16:31 ` Sergei Shtylylov
2005-10-31 17:55 ` Sergei Shtylylov
2005-11-01 8:53 ` Pantelis Antoniou
2005-11-01 12:49 ` Sergei Shtylylov
2005-11-01 13:00 ` Pantelis Antoniou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox