[LinuxBIOS] Flashrom add EON EN29F002NT

[Markus Boas]

I send a patch to add support for the EON EN29F002NT
Write, read works.

Signed-off-by: Markus Boas <[e-mail]>

[Carl-Daniel Hailfinger]

On 31.08.2007 21:40, Markus Boas wrote:
> I send a patch to add support for the EON EN29F002NT
> Write, read works.

Sorry, but the data sheet says you're only doing half of the
identification and this will match all EON chips.

I'll send a more correct patch later on.

Carl-Daniel
> Signed-off-by: Markus Boas <[e-mail]>
>
> ------------------------------------------------------------------------
>
> Index: flash.h
> ===================================================================
> --- flash.h	(Revision 2754)
> +++ flash.h	(Arbeitskopie)
> @@ -68,6 +68,9 @@
>  #define AT_29C040A		0xA4
>  #define AT_29C020		0xDA
>
> +#define EON_ID			0x7F	/* EON */
> +#define EN29F002T		0x7F
> +
>  #define MX_ID			0xC2	/* Macronix (MX) */
>  #define MX_29F002		0xB0
>
> Index: README
> ===================================================================
> --- README	(Revision 2754)
> +++ README	(Arbeitskopie)
> @@ -103,6 +103,7 @@
>  Atmel AT-29C040A
>  Atmel AT-29C020
>  EMST F49B002UA
> +EON EN29F002N
>  Intel 82802AB (Firmware Hub) 
>  Intel 82802AC (Firmware Hub) 
>  M-Systems MD-2802 (unsupported, disabled by default)
> Index: flashchips.c
> ===================================================================
> --- flashchips.c	(Revision 2754)
> +++ flashchips.c	(Arbeitskopie)
> @@ -151,5 +151,7 @@
>    probe_jedec,	erase_chip_jedec, write_49f002},
>   {"S29C31004T", 	SYNCMOS_ID, 	S29C31004T,	512, 128,
>    probe_jedec,	erase_chip_jedec, write_49f002},
> +	{"EN29F002T",	EON_ID,		EN29F002T,	256, 16,
> +	 probe_jedec,	erase_chip_jedec,	write_jedec},
>   {NULL,}
>  };

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Carl-Daniel Hailfinger]

Hi Markus,

On 24.09.2007 00:38, Carl-Daniel Hailfinger wrote:
> On 31.08.2007 21:40, Markus Boas wrote:
> > I send a patch to add support for the EON EN29F002NT
> > Write, read works.
>
> Sorry, but the data sheet says you're only doing half of the
> identification and this will match all EON chips.

Can you test this patch? If identification fails, can you post the
output of "flashrom --verbose" ? Thanks!

Add continuation ID support to jedec.c
Add support for EON EN29F002AT.

Signed-off-by: Carl-Daniel Hailfinger <[e-mail]>

Index: flashrom-eon/flash.h
===================================================================
--- flashrom-eon/flash.h	(Revision 3012)
+++ flashrom-eon/flash.h	(Arbeitskopie)
@@ -32,8 +32,12 @@
 
 struct flashchip {
 	const char *name;
-	int manufacture_id;
-	int model_id;
+	/* With 32bit manufacture_id and model_id we can cover IDs up to
+	 * (including) the 4th bank of JEDEC JEP106W Standard Manufacturer's
+	 * Identification code.
+	 */
+	uint32_t manufacture_id;
+	uint32_t model_id;
 
 	int total_size;
 	int page_size;
@@ -85,8 +89,14 @@
 /*
  * EN25 chips are SPI, first byte of device ID is memory type,
  * second byte of device ID is log(bitsize)-9.
+ * Vendor and device ID of EN29 series are both prefixed with 0x7F, which
+ * is the continuation code for IDs in bank 2.
+ * Vendor ID of EN25 series is NOT prefixed with 0x7F, this results in
+ * a collision with Mitsubishi. Mitsubishi once manufactured flash chips.
+ * Let's hope they are not manufacturing SPI flash chips as well.
  */
-#define EON_ID			0x1C	/* EON */
+#define EON_ID			0x7F1C	/* EON, code is 1C in bank 2 */
+#define EON_ID_NOPREFIX		0x1C	/* EON, code is 1C in bank 2 */
 #define EN_25B05		0x2010	/* 2^19 kbit or 2^16 kByte */
 #define EN_25B10		0x2011
 #define EN_25B20		0x2012
@@ -94,6 +104,13 @@
 #define EN_25B80		0x2014
 #define EN_25B16		0x2015
 #define EN_25B32		0x2016
+#define EN_29F512		0x7F21
+#define EN_29F010		0x7F20
+#define EN_29F040A		0x7F04
+#define EN_29LV010		0x7F6E
+#define EN_29LV040A		0x7F4F	/* EN_29LV040(A) */
+#define EN_29F002AT		0x7F92
+#define EN_29F002AB		0x7F97
 
 #define FUJITSU_ID		0x04	/* Fujitsu */
 #define MBM29F400TC		0x23
Index: flashrom-eon/en29f002a.c
===================================================================
Index: flashrom-eon/jedec.c
===================================================================
--- flashrom-eon/jedec.c	(Revision 3012)
+++ flashrom-eon/jedec.c	(Arbeitskopie)
@@ -4,6 +4,7 @@
  * Copyright (C) 2000 Silicon Integrated System Corporation
  * Copyright (C) 2006 Giampiero Giancipoli <[e-mail]>
  * Copyright (C) 2006 coresystems GmbH <[e-mail]>
+ * Copyright (C) 2007 Carl-Daniel Hailfinger
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -82,6 +83,7 @@
 {
 	volatile uint8_t *bios = flash->virtual_memory;
 	uint8_t id1, id2;
+	uint32_t largeid1, largeid2;
 
 	/* Issue JEDEC Product ID Entry command */
 	*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
@@ -98,7 +100,21 @@
 	/* Read product ID */
 	id1 = *(volatile uint8_t *)bios;
 	id2 = *(volatile uint8_t *)(bios + 0x01);
+	largeid1 = id1;
+	largeid2 = id2;
 
+	/* Check if it is a continuation ID, this should be a while loop. */
+	if (id1 == 0x7F) {
+		largeid1 <<= 8;
+		id1 = *(volatile uint8_t *)(bios + 0x100);
+		largeid1 |= id1;
+	}
+	if (id2 == 0x7F) {
+		largeid2 <<= 8;
+		id2 = *(volatile uint8_t *)(bios + 0x101);
+		largeid2 |= id2;
+	}
+
 	/* Issue JEDEC Product ID Exit command */
 	*(volatile uint8_t *)(bios + 0x5555) = 0xAA;
 	myusec_delay(10);
@@ -107,8 +123,8 @@
 	*(volatile uint8_t *)(bios + 0x5555) = 0xF0;
 	myusec_delay(40);
 
-	printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, id1, id2);
-	if (id1 == flash->manufacture_id && id2 == flash->model_id)
+	printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, largeid1, largeid2);
+	if (largeid1 == flash->manufacture_id && largeid2 == flash->model_id)
 		return 1;
 
 	return 0;
Index: flashrom-eon/flashchips.c
===================================================================
--- flashrom-eon/flashchips.c	(Revision 3012)
+++ flashrom-eon/flashchips.c	(Arbeitskopie)
@@ -42,6 +42,9 @@
 	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"At49F002(N)T",ATMEL_ID,	AT_49F002NT,	256, 256,
 	 probe_jedec,	erase_chip_jedec, write_jedec},
+	/* The EN29F002AT can do byte program at arbitrary boundaries. */
+	{"EN29F002AT",	EON_ID,		EN_29F002AT,	256, 256,
+	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"MBM29F400TC",	FUJITSU_ID,	MBM29F400TC,	512, 64 * 1024,
 	 probe_m29f400bt, erase_m29f400bt, write_linuxbios_m29f400bt},
 	{"MX29F002",	MX_ID,		MX_29F002,	256, 64 * 1024,

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Carl-Daniel Hailfinger]

On 18.12.2007 00:53, Carl-Daniel Hailfinger wrote:
> Hi Markus,
>
> On 24.09.2007 00:38, Carl-Daniel Hailfinger wrote:
> > On 31.08.2007 21:40, Markus Boas wrote:
> > > I send a patch to add support for the EON EN29F002NT
> > > Write, read works.
> >
> > Sorry, but the data sheet says you're only doing half of the
> > identification and this will match all EON chips.
>
> Can you test this patch? If identification fails, can you post the
> output of "flashrom --verbose" ? Thanks!
>
> Add continuation ID support to jedec.c
> Add support for EON EN29F002AT.
>
> Signed-off-by: Carl-Daniel Hailfinger <[e-mail]>

Anyone able to review this?

Regards,
Carl-Daniel

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Corey Osgood]

> +       /* Check if it is a continuation ID, this should be a while
> loop. */
> +       if (id1 == 0x7F) {
> +               largeid1 <<= 8;
> +               id1 = *(volatile uint8_t *)(bios + 0x100);
> +               largeid1 |= id1;
> +       }
> +       if (id2 == 0x7F) {
> +               largeid2 <<= 8;
> +               id2 = *(volatile uint8_t *)(bios + 0x101);
> +               largeid2 |= id2;
> +       }

are you sure this is right? The IDs are, at most, just 0x7f7f7fXX? Just
doesn't seem quite right, but it might be (yes, I realize it means 4x
more IDs). We also break the ability to use IMT flash chips (which
someone may, eventually...). The other things is, if it should be a
while loop, why isn't it?

You also forgot your email in the copyright header in flashchips.c.

-Corey

Carl-Daniel Hailfinger wrote:
> On 18.12.2007 00:53, Carl-Daniel Hailfinger wrote:
> > Hi Markus,
> >
> > On 24.09.2007 00:38, Carl-Daniel Hailfinger wrote:
> > > On 31.08.2007 21:40, Markus Boas wrote:
> > > > I send a patch to add support for the EON EN29F002NT
> > > > Write, read works.
> > >
> > > Sorry, but the data sheet says you're only doing half of the
> > > identification and this will match all EON chips.
> >
> > Can you test this patch? If identification fails, can you post the
> > output of "flashrom --verbose" ? Thanks!
> >
> > Add continuation ID support to jedec.c
> > Add support for EON EN29F002AT.
> >
> > Signed-off-by: Carl-Daniel Hailfinger <[e-mail]>
>
> Anyone able to review this?
>
> Regards,
> Carl-Daniel

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Carl-Daniel Hailfinger]

On 30.12.2007 05:40, Corey Osgood wrote:
> > +       /* Check if it is a continuation ID, this should be a while
> > loop. */
> > +       if (id1 == 0x7F) {
> > +               largeid1 <<= 8;
> > +               id1 = *(volatile uint8_t *)(bios + 0x100);
> > +               largeid1 |= id1;
> > +       }
> > +       if (id2 == 0x7F) {
> > +               largeid2 <<= 8;
> > +               id2 = *(volatile uint8_t *)(bios + 0x101);
> > +               largeid2 |= id2;
> > +       }
>
> are you sure this is right? The IDs are, at most, just 0x7f7f7fXX? Just

Actually, the code above does not go further than checking for IDs of
the type 0x7fXX, but does this for vendor and product ID. The current
published JEDEC spec has a list where the largest vendor ID is 7 bytes
long, but all leading bytes are 0x7f. The list will grow in the future,
and using a 64bit variable will not be enough anymore.
Suggestion for a new encoding:
Use a two-byte data type for the ID, the lower byte contains the only
non-0x7f byte, the upper byte contains the number of 0x7f bytes used as
prefix (which is the "page" number the vendor ID appears in.
> doesn't seem quite right, but it might be (yes, I realize it means 4x
> more IDs). We also break the ability to use IMT flash chips (which
> someone may, eventually...). The other things is, if it should be a
> while loop, why isn't it?

Oh, I had not seen the IMT entry in flash.h. It is obviously wrong. With
the current code, at least EON and IMT will collide, and neither have a
real vendor ID of 0x7f. I'll dig out the real IMT vendor ID.
> You also forgot your email in the copyright header in flashchips.c.

That is intentional.

Thanks for your review!

Regards,
Carl-Daniel

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Carl-Daniel Hailfinger]

On 30.12.2007 13:15, Carl-Daniel Hailfinger wrote:
> On 30.12.2007 05:40, Corey Osgood wrote:
> > doesn't seem quite right, but it might be (yes, I realize it means 4x
> > more IDs). We also break the ability to use IMT flash chips (which
> > someone may, eventually...). The other things is, if it should be a
> > while loop, why isn't it?
>
> Oh, I had not seen the IMT entry in flash.h. It is obviously wrong. With
> the current code, at least EON and IMT will collide, and neither have a
> real vendor ID of 0x7f. I'll dig out the real IMT vendor ID.

Patch to fix the IMT entry sent to the list. I hope this addresses your
concerns.

Regards,
Carl-Daniel

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Corey Osgood]

Carl-Daniel Hailfinger wrote:
> On 30.12.2007 13:15, Carl-Daniel Hailfinger wrote:
> > On 30.12.2007 05:40, Corey Osgood wrote:
> > > doesn't seem quite right, but it might be (yes, I realize it means 4x
> > > more IDs). We also break the ability to use IMT flash chips (which
> > > someone may, eventually...). The other things is, if it should be a
> > > while loop, why isn't it?
> >
> > Oh, I had not seen the IMT entry in flash.h. It is obviously wrong. With
> > the current code, at least EON and IMT will collide, and neither have a
> > real vendor ID of 0x7f. I'll dig out the real IMT vendor ID.
>
> Patch to fix the IMT entry sent to the list. I hope this addresses your
> concerns.
>
> Regards,
> Carl-Daniel

In that case:

Acked-by: Corey Osgood <[e-mail]>

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Carl-Daniel Hailfinger]

On 31.12.2007 00:57, Corey Osgood wrote:
> Carl-Daniel Hailfinger wrote:
> > On 30.12.2007 13:15, Carl-Daniel Hailfinger wrote:
> > > On 30.12.2007 05:40, Corey Osgood wrote:
> > > > doesn't seem quite right, but it might be (yes, I realize it means 4x
> > > > more IDs). We also break the ability to use IMT flash chips (which
> > > > someone may, eventually...). The other things is, if it should be a
> > > > while loop, why isn't it?
> > >
> > > Oh, I had not seen the IMT entry in flash.h. It is obviously wrong. With
> > > the current code, at least EON and IMT will collide, and neither have a
> > > real vendor ID of 0x7f. I'll dig out the real IMT vendor ID.
> >
> > Patch to fix the IMT entry sent to the list. I hope this addresses your
> > concerns.
> >
> > Regards,
> > Carl-Daniel
>
> In that case:
>
> Acked-by: Corey Osgood <[e-mail]>

Thanks, r3030.

Regards,
Carl-Daniel

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002AT, JEDEC continuation IDs

[Markus]

Am Tue, 18 Dec 2007 00:53:37 +0100
schrieb Carl-Daniel Hailfinger <[e-mail]>:
> Hi Markus,
>
> On 24.09.2007 00:38, Carl-Daniel Hailfinger wrote:
> > On 31.08.2007 21:40, Markus Boas wrote:
> > > I send a patch to add support for the EON EN29F002NT
> > > Write, read works.
> >
> > Sorry, but the data sheet says you're only doing half of the
> > identification and this will match all EON chips.
>
> Can you test this patch? If identification fails, can you post the
> output of "flashrom --verbose" ? Thanks!

Geode:~# ./flashrom --verbose
Calibrating delay loop... 27M loops per second. OK.
No LinuxBIOS table found.
Found chipset "CS5530/CS5530A", enabling flash write... OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x25, id2 0x9f
Probing for Am29LV040B, 512 KB
probe_29f040b: id1 0x25, id2 0x9f
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0x25, id2 0x9f
Probing for AE49F2008, 256 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
Probing for At29C040A, 512 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
Probing for At29C020, 256 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
Probing for At49F002(N), 256 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
Probing for At49F002(N)T, 256 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
Probing for EN29F002AT, 256 KB
probe_jedec: id1 0x7f1c, id2 0x7f92
EN29F002AT found at physical address 0xfffc0000.
Flash part is EN29F002AT (256 KB).
No operations were specified.

The Chip is an EN29F002NT.

read, write and verify don't realy work. But i'm think the chip is
destroyed. If i belief my memory, i was able to write once the chip, no
more afterwards. 

Markus

[LinuxBIOS] [PATCH] flashrom: Support EON EN29F002(A)(N)B, improve naming for the EN29F002 series

[Carl-Daniel Hailfinger]

On 30.12.2007 21:09, Markus wrote:
> Am Tue, 18 Dec 2007 00:53:37 +0100
> schrieb Carl-Daniel Hailfinger <[e-mail]>:
> > On 24.09.2007 00:38, Carl-Daniel Hailfinger wrote:
> > > On 31.08.2007 21:40, Markus Boas wrote:
> > > > I send a patch to add support for the EON EN29F002NT
> > > > Write, read works.
> > >
> > > Sorry, but the data sheet says you're only doing half of the
> > > identification and this will match all EON chips.
> >
> > Can you test this patch? If identification fails, can you post the
> > output of "flashrom --verbose" ? Thanks!
>
> Geode:~# ./flashrom --verbose
> Calibrating delay loop... 27M loops per second. OK.
> No LinuxBIOS table found.
> Found chipset "CS5530/CS5530A", enabling flash write... OK.
> Probing for Am29F040B, 512 KB
> probe_29f040b: id1 0x25, id2 0x9f
> Probing for Am29LV040B, 512 KB
> probe_29f040b: id1 0x25, id2 0x9f
> Probing for Am29F016D, 2048 KB
> probe_29f040b: id1 0x25, id2 0x9f
> Probing for AE49F2008, 256 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> Probing for At29C040A, 512 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> Probing for At29C020, 256 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> Probing for At49F002(N), 256 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> Probing for At49F002(N)T, 256 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> Probing for EN29F002AT, 256 KB
> probe_jedec: id1 0x7f1c, id2 0x7f92
> EN29F002AT found at physical address 0xfffc0000.
> Flash part is EN29F002AT (256 KB).
> No operations were specified.

Thanks! So the code works exactly as I thought.
> The Chip is an EN29F002NT.

What do you think about this patch?

Unfortunately, EN29F002T, EN29F002AT, EN29F002ANT, EN29F002NT all have
exactly the same ID. Improve model number printing.
Add EN29F002(A)(N)B support while I'm at it.
Signed-off-by: Carl-Daniel Hailfinger <[e-mail]>

Index: flashrom-eon/flash.h
===================================================================
--- flashrom-eon/flash.h	(Revision 3030)
+++ flashrom-eon/flash.h	(Arbeitskopie)
@@ -109,8 +109,8 @@
 #define EN_29F040A		0x7F04
 #define EN_29LV010		0x7F6E
 #define EN_29LV040A		0x7F4F	/* EN_29LV040(A) */
-#define EN_29F002AT		0x7F92
-#define EN_29F002AB		0x7F97
+#define EN_29F002T		0x7F92
+#define EN_29F002B		0x7F97
 
 #define FUJITSU_ID		0x04	/* Fujitsu */
 /* MBM29F400TC_STRANGE has a value not mentioned in the data sheet and we
Index: flashrom-eon/flashchips.c
===================================================================
--- flashrom-eon/flashchips.c	(Revision 3030)
+++ flashrom-eon/flashchips.c	(Arbeitskopie)
@@ -42,9 +42,10 @@
 	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"At49F002(N)T",ATMEL_ID,	AT_49F002NT,	256, 256,
 	 probe_jedec,	erase_chip_jedec, write_jedec},
-	/* The EN29F002AT can do byte program at arbitrary boundaries. */
-	{"EN29F002AT",	EON_ID,		EN_29F002AT,	256, 256,
+	{"EN29F002(A)(N)T",	EON_ID,	EN_29F002T,	256, 256,
 	 probe_jedec,	erase_chip_jedec, write_jedec},
+	{"EN29F002(A)(N)B",	EON_ID,	EN_29F002B,	256, 256,
+	 probe_jedec,	erase_chip_jedec, write_jedec},
 	{"MBM29F400TC",	FUJITSU_ID,	MBM29F400TC_STRANGE,	512, 64 * 1024,
 	 probe_m29f400bt, erase_m29f400bt, write_linuxbios_m29f400bt},
 	{"MX29F002",	MX_ID,		MX_29F002,	256, 64 * 1024,
> read, write and verify don't realy work. But i'm think the chip is
> destroyed. If i belief my memory, i was able to write once the chip, no
> more afterwards.

Maybe some block protection bits are set in the chip? We don't handle
protection bits for any EON chip right now.


Regards,
Carl-Daniel