[PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[Haavard Skinnemoen]

Atmel AT49BV6416 is used on the AT32STK1000 development board for
AVR32. This patch makes jedec_probe recognize it.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
 drivers/mtd/chips/jedec_probe.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 8f39d0a..173530b 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -67,6 +67,7 @@ #define AT49BV16X	0x00C0
 #define AT49BV16XT	0x00C2
 #define AT49BV32X	0x00C8
 #define AT49BV32XT	0x00C9
+#define AT49BV6416	0x00D6
 
 /* Fujitsu */
 #define MBM29F040C	0x00A4
@@ -630,6 +631,20 @@ static const struct amd_flash_info jedec
 			ERASEINFO(0x02000,8)
 		}
 	}, {
+		.mfr_id		= MANUFACTURER_ATMEL,
+		.dev_id		= AT49BV6416,
+		.name		= "Atmel AT49BV6416",
+		.uaddr		= {
+			[1] = MTD_UADDR_0x0555_0x0AAA,	/* x16 */
+		},
+		.DevSize	= SIZE_8MiB,
+		.CmdSet		= P_ID_AMD_STD,
+		.NumEraseRegions = 2,
+		.regions	= {
+			 ERASEINFO(0x02000, 8),
+			 ERASEINFO(0x10000, 127)
+		 }
+	}, {
 		.mfr_id		= MANUFACTURER_FUJITSU,
 		.dev_id		= MBM29F040C,
 		.name		= "Fujitsu MBM29F040C",
-- 
1.4.0

[PATCH] MTD: Add lock/unlock operations for Atmel AT49BV6416

[Haavard Skinnemoen]

The AT49BV6416 is locked by default, so we really need to provide
at least the unlock() operation for write and erase to work. This
patch implements both ->lock() and ->unlock() and provides a fixup
to install them when an AT49BV6416 chip is detected.

These functions are probably valid on more Atmel chips, but I don't
know exactly which ones. I can find out and add them if anyone cares.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---

Now, I'm not quite sure how to use this to make the flash usable for
jffs2, etc. At the moment, it works if I unlock the flash using the
flash_unlock utility before mounting a jffs2 file system, but this
obviously won't work when using jffs2 as a root file system.

What's the best way to do this? Unlock the flash in the board-specific
mapping driver perhaps?

Haavard

 drivers/mtd/chips/cfi_cmdset_0002.c |   90 +++++++++++++++++++++++++++++++++++
 1 files changed, 90 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 9885726..70ad7cf 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -45,9 +45,11 @@ #define FORCE_WORD_WRITE 0
 #define MAX_WORD_RETRIES 3
 
 #define MANUFACTURER_AMD	0x0001
+#define MANUFACTURER_ATMEL	0x001F
 #define MANUFACTURER_SST	0x00BF
 #define SST49LF004B	        0x0060
 #define SST49LF008A		0x005a
+#define AT49BV6416		0x00d6
 
 static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
 static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
@@ -68,6 +70,9 @@ static int get_chip(struct map_info *map
 static void put_chip(struct map_info *map, struct flchip *chip, unsigned long adr);
 #include "fwh_lock.h"
 
+static int cfi_atmel_lock(struct mtd_info *mtd, loff_t ofs, size_t len);
+static int cfi_atmel_unlock(struct mtd_info *mtd, loff_t ofs, size_t len);
+
 static struct mtd_chip_driver cfi_amdstd_chipdrv = {
 	.probe		= NULL, /* Not usable directly */
 	.destroy	= cfi_amdstd_destroy,
@@ -179,6 +184,16 @@ static void fixup_use_erase_chip(struct 
 
 }
 
+/*
+ * Some Atmel chips (e.g. the AT49BV6416) power-up with all sectors
+ * locked by default.
+ */
+static void fixup_use_atmel_lock(struct mtd_info *mtd, void *param)
+{
+	mtd->lock = cfi_atmel_lock;
+	mtd->unlock = cfi_atmel_unlock;
+}
+
 static struct cfi_fixup cfi_fixup_table[] = {
 #ifdef AMD_BOOTLOC_BUG
 	{ CFI_MFR_AMD, CFI_ID_ANY, fixup_amd_bootblock, NULL },
@@ -197,6 +212,7 @@ #endif
 static struct cfi_fixup jedec_fixup_table[] = {
 	{ MANUFACTURER_SST, SST49LF004B, fixup_use_fwh_lock, NULL, },
 	{ MANUFACTURER_SST, SST49LF008A, fixup_use_fwh_lock, NULL, },
+	{ MANUFACTURER_ATMEL, AT49BV6416, fixup_use_atmel_lock, NULL },
 	{ 0, 0, NULL, NULL }
 };
 
@@ -1607,6 +1623,80 @@ static int cfi_amdstd_erase_chip(struct 
 	return 0;
 }
 
+static int do_atmel_lock(struct map_info *map, struct flchip *chip,
+			 unsigned long adr, int len, void *thunk)
+{
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ret;
+
+	spin_lock(chip->mutex);
+	ret = get_chip(map, chip, adr + chip->start, FL_LOCKING);
+	if (ret)
+		goto out_unlock;
+	chip->state = FL_LOCKING;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): adr 0x%08lx len %d\n",
+	      __func__, adr, len);
+
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	map_write(map, CMD(0x40), chip->start + adr);
+
+	chip->state = FL_READY;
+	put_chip(map, chip, adr + chip->start);
+	ret = 0;
+
+out_unlock:
+	spin_unlock(chip->mutex);
+	return ret;
+}
+
+static int do_atmel_unlock(struct map_info *map, struct flchip *chip,
+			   unsigned long adr, int len, void *thunk)
+{
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ret;
+
+	spin_lock(chip->mutex);
+	ret = get_chip(map, chip, adr + chip->start, FL_UNLOCKING);
+	if (ret)
+		goto out_unlock;
+	chip->state = FL_UNLOCKING;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): adr 0x%08lx len %d\n",
+	      __func__, adr, len);
+
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	map_write(map, CMD(0x70), adr);
+
+	chip->state = FL_READY;
+	put_chip(map, chip, adr + chip->start);
+	ret = 0;
+
+out_unlock:
+	spin_unlock(chip->mutex);
+	return ret;
+}
+
+static int cfi_atmel_lock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+	return cfi_varsize_frob(mtd, do_atmel_lock, ofs, len, NULL);
+}
+
+static int cfi_atmel_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+	return cfi_varsize_frob(mtd, do_atmel_unlock, ofs, len, NULL);
+}
+
 
 static void cfi_amdstd_sync (struct mtd_info *mtd)
 {
-- 
1.4.0

Re: [PATCH] MTD: Add lock/unlock operations for Atmel AT49BV6416

[David Woodhouse]

On Fri, 2006-08-04 at 10:28 +0200, Haavard Skinnemoen wrote:
> What's the best way to do this? Unlock the flash in the board-specific
> mapping driver perhaps? 

That's what we used to do. If more people are emulating the Intel brain
damage and having chips which render the lock operation entirely
pointless by locking the chips at every power cycle, then I suppose we
ought to consider making auto-unlock a function of the chip type.

-- 
dwmw2

Re: [PATCH] MTD: Add lock/unlock operations for Atmel AT49BV6416

[Haavard Skinnemoen]

On Fri, 04 Aug 2006 16:41:12 +0800
David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2006-08-04 at 10:28 +0200, Haavard Skinnemoen wrote:
> > What's the best way to do this? Unlock the flash in the
> > board-specific mapping driver perhaps? 
> 
> That's what we used to do. If more people are emulating the Intel
> brain damage and having chips which render the lock operation entirely
> pointless by locking the chips at every power cycle, then I suppose we
> ought to consider making auto-unlock a function of the chip type.

It appears that Atmel has reverted this in later chips, like the
AT49BV642D. Updated patch below, if you still want it. Please disregard
the jedec_probe patch as I've got AT49BV6416 working in CFI mode now.

This patch depends on "MTD: Convert Atmel PRI information to AMD
format" which I just submitted, as it needs the definition
of CFI_MFR_ATMEL.

Haavard

---

[PATCH] MTD: Add lock/unlock operations for Atmel AT49BV6416

The AT49BV6416 is locked by default, so we really need to provide
at least the unlock() operation for write and erase to work. This
patch implements both ->lock() and ->unlock() and provides a fixup
to install them when an AT49BV6416 chip is detected.

These functions are probably valid on more Atmel chips, but I believe
it's mostly obsolete ones. The AT49BV6416 is in fact obsolete, but
it's used on all current AT32STK1000 development boards.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
 drivers/mtd/chips/cfi_cmdset_0002.c |   90 ++++++++++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

Index: linux-2.6.18-rc3-mm2/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/mtd/chips/cfi_cmdset_0002.c	2006-08-09 10:28:27.000000000 +0200
+++ linux-2.6.18-rc3-mm2/drivers/mtd/chips/cfi_cmdset_0002.c	2006-08-09 10:32:04.000000000 +0200
@@ -45,9 +45,11 @@
 #define MAX_WORD_RETRIES 3
 
 #define MANUFACTURER_AMD	0x0001
+#define MANUFACTURER_ATMEL	0x001F
 #define MANUFACTURER_SST	0x00BF
 #define SST49LF004B	        0x0060
 #define SST49LF008A		0x005a
+#define AT49BV6416		0x00d6
 
 static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *);
 static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *);
@@ -68,6 +70,9 @@ static int get_chip(struct map_info *map
 static void put_chip(struct map_info *map, struct flchip *chip, unsigned long adr);
 #include "fwh_lock.h"
 
+static int cfi_atmel_lock(struct mtd_info *mtd, loff_t ofs, size_t len);
+static int cfi_atmel_unlock(struct mtd_info *mtd, loff_t ofs, size_t len);
+
 static struct mtd_chip_driver cfi_amdstd_chipdrv = {
 	.probe		= NULL, /* Not usable directly */
 	.destroy	= cfi_amdstd_destroy,
@@ -199,6 +204,16 @@ static void fixup_use_erase_chip(struct 
 
 }
 
+/*
+ * Some Atmel chips (e.g. the AT49BV6416) power-up with all sectors
+ * locked by default.
+ */
+static void fixup_use_atmel_lock(struct mtd_info *mtd, void *param)
+{
+	mtd->lock = cfi_atmel_lock;
+	mtd->unlock = cfi_atmel_unlock;
+}
+
 static struct cfi_fixup cfi_fixup_table[] = {
 #ifdef AMD_BOOTLOC_BUG
 	{ CFI_MFR_AMD, CFI_ID_ANY, fixup_amd_bootblock, NULL },
@@ -228,6 +243,7 @@ static struct cfi_fixup fixup_table[] = 
 	 * we know that is the case.
 	 */
 	{ CFI_MFR_ANY, CFI_ID_ANY, fixup_use_erase_chip, NULL },
+	{ CFI_MFR_ATMEL, AT49BV6416, fixup_use_atmel_lock, NULL },
 	{ 0, 0, NULL, NULL }
 };
 
@@ -1628,6 +1644,80 @@ static int cfi_amdstd_erase_chip(struct 
 	return 0;
 }
 
+static int do_atmel_lock(struct map_info *map, struct flchip *chip,
+			 unsigned long adr, int len, void *thunk)
+{
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ret;
+
+	spin_lock(chip->mutex);
+	ret = get_chip(map, chip, adr + chip->start, FL_LOCKING);
+	if (ret)
+		goto out_unlock;
+	chip->state = FL_LOCKING;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): LOCK 0x%08lx len %d\n",
+	      __func__, adr, len);
+
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	map_write(map, CMD(0x40), chip->start + adr);
+
+	chip->state = FL_READY;
+	put_chip(map, chip, adr + chip->start);
+	ret = 0;
+
+out_unlock:
+	spin_unlock(chip->mutex);
+	return ret;
+}
+
+static int do_atmel_unlock(struct map_info *map, struct flchip *chip,
+			   unsigned long adr, int len, void *thunk)
+{
+	struct cfi_private *cfi = map->fldrv_priv;
+	int ret;
+
+	spin_lock(chip->mutex);
+	ret = get_chip(map, chip, adr + chip->start, FL_UNLOCKING);
+	if (ret)
+		goto out_unlock;
+	chip->state = FL_UNLOCKING;
+
+	DEBUG(MTD_DEBUG_LEVEL3, "MTD %s(): LOCK 0x%08lx len %d\n",
+	      __func__, adr, len);
+
+	cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
+			 cfi->device_type, NULL);
+	map_write(map, CMD(0x70), adr);
+
+	chip->state = FL_READY;
+	put_chip(map, chip, adr + chip->start);
+	ret = 0;
+
+out_unlock:
+	spin_unlock(chip->mutex);
+	return ret;
+}
+
+static int cfi_atmel_lock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+	return cfi_varsize_frob(mtd, do_atmel_lock, ofs, len, NULL);
+}
+
+static int cfi_atmel_unlock(struct mtd_info *mtd, loff_t ofs, size_t len)
+{
+	return cfi_varsize_frob(mtd, do_atmel_unlock, ofs, len, NULL);
+}
+
 
 static void cfi_amdstd_sync (struct mtd_info *mtd)
 {

Re: [PATCH] MTD: Add lock/unlock operations for Atmel AT49BV6416

[Josh Boyer]

On 8/9/06, Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
> On Fri, 04 Aug 2006 16:41:12 +0800
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > On Fri, 2006-08-04 at 10:28 +0200, Haavard Skinnemoen wrote:
> > > What's the best way to do this? Unlock the flash in the
> > > board-specific mapping driver perhaps?
> >
> > That's what we used to do. If more people are emulating the Intel
> > brain damage and having chips which render the lock operation entirely
> > pointless by locking the chips at every power cycle, then I suppose we
> > ought to consider making auto-unlock a function of the chip type.
>
> It appears that Atmel has reverted this in later chips, like the
> AT49BV642D. Updated patch below, if you still want it. Please disregard
> the jedec_probe patch as I've got AT49BV6416 working in CFI mode now.
>
> This patch depends on "MTD: Convert Atmel PRI information to AMD
> format" which I just submitted, as it needs the definition
> of CFI_MFR_ATMEL.

I've added this patch to my tree.

josh

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[David Woodhouse]

On Fri, 2006-08-04 at 10:28 +0200, Haavard Skinnemoen wrote:
> Atmel AT49BV6416 is used on the AT32STK1000 development board for
> AVR32. This patch makes jedec_probe recognize it.

Ew. People are still making non-CFI chips?

-- 
dwmw2

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[Haavard Skinnemoen]

On Fri, 04 Aug 2006 16:39:58 +0800
David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2006-08-04 at 10:28 +0200, Haavard Skinnemoen wrote:
> > Atmel AT49BV6416 is used on the AT32STK1000 development board for
> > AVR32. This patch makes jedec_probe recognize it.
> 
> Ew. People are still making non-CFI chips?

It is actually a CFI chip. But I couldn't figure out how to install the
fixup in the other patch in the CFI code. The AT49BV6416 chip
identifies itself as using the AMD command set, so the fixup must be
installed based on the jedec ID...

Haavard

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[David Woodhouse]

On Fri, 2006-08-04 at 10:52 +0200, Haavard Skinnemoen wrote:
> 
> It is actually a CFI chip. But I couldn't figure out how to install the
> fixup in the other patch in the CFI code. The AT49BV6416 chip
> identifies itself as using the AMD command set, so the fixup must be
> installed based on the jedec ID... 

But that's OK -- doesn't the cfi_probe code also read the jedec ID so
that the same fixups work?

-- 
dwmw2

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[David Woodhouse]

On Fri, 2006-08-04 at 10:52 +0200, Haavard Skinnemoen wrote:
> It is actually a CFI chip. But I couldn't figure out how to install the
> fixup in the other patch in the CFI code. The AT49BV6416 chip
> identifies itself as using the AMD command set, so the fixup must be
> installed based on the jedec ID... 

Er, note that the _correct_ answer is to advertise the availability of
the lock functionality in the CFI 'extended query' information. Did the
hardware designer screw that up?

-- 
dwmw2

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[Haavard Skinnemoen]

On Fri, 04 Aug 2006 17:06:19 +0800
David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2006-08-04 at 10:52 +0200, Haavard Skinnemoen wrote:
> > It is actually a CFI chip. But I couldn't figure out how to install
> > the fixup in the other patch in the CFI code. The AT49BV6416 chip
> > identifies itself as using the AMD command set, so the fixup must be
> > installed based on the jedec ID... 
> 
> Er, note that the _correct_ answer is to advertise the availability of
> the lock functionality in the CFI 'extended query' information. Did
> the hardware designer screw that up?

Hmmm...it looks like the information is there, but the PRI page looks
different than the one defined by the kernel. Which could make sense,
depending on whether "vendor specific" refers to the JEDEC vendor ID of
the device or the command set ID.

I'll try to ask someone from the Atmel flash group about this.

Anyway, I could of course add a fixup based on manufacturer ID and
convert the PRI information into something the kernel understands.
Would that be a better idea?

Haavard

Re: [PATCH] MTD jedec_probe: Recognize Atmel AT49BV6416

[Haavard Skinnemoen]

On Fri, 04 Aug 2006 17:06:19 +0800
David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2006-08-04 at 10:52 +0200, Haavard Skinnemoen wrote:
> > It is actually a CFI chip. But I couldn't figure out how to install
> > the fixup in the other patch in the CFI code. The AT49BV6416 chip
> > identifies itself as using the AMD command set, so the fixup must be
> > installed based on the jedec ID... 
> 
> Er, note that the _correct_ answer is to advertise the availability of
> the lock functionality in the CFI 'extended query' information. Did
> the hardware designer screw that up?

I can't find any information about the softlock feature in the PRI
block. However, the AT49BV6416 is obsolete, and the replacement chip,
AT49BV642D, does not power up locked. We'll be using AT49BV642D for new
designs, but in order to support the AT32STK1000 development board, we
need to install a fixup for AT49BV6416.

Another issue is that Atmel uses a different PRI block than AMD. I can
work around this by installing a CFI fixup that converts the Atmel PRI
block to look like an AMD block.

Alternatively, we could define a vendor-independent format with just
the information we need and select different readers/parsers based on
the JEDEC manufacturer ID. Do you know if there are other vendors using
the AMD command set but a different PRI format?

Haavard