I send a patch to add support for the EON EN29F002NT Write, read works.
Signed-off-by: Markus Boas ryven@ryven.de
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 ryven@ryven.de
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,
{NULL,}probe_jedec, erase_chip_jedec, write_jedec},
};
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 c-d.hailfinger.devel.2006@gmx.net
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 gianci@email.it * Copyright (C) 2006 coresystems GmbH info@coresystems.de + * 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,
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 c-d.hailfinger.devel.2006@gmx.net
Anyone able to review this?
Regards, Carl-Daniel
/* 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 c-d.hailfinger.devel.2006@gmx.net
Anyone able to review this?
Regards, Carl-Daniel
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
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
Am Tue, 18 Dec 2007 00:53:37 +0100 schrieb Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
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
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 corey.osgood@gmail.com
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 corey.osgood@gmail.com
Thanks, r3030.
Regards, Carl-Daniel
On 30.12.2007 21:09, Markus wrote:
Am Tue, 18 Dec 2007 00:53:37 +0100 schrieb Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
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 c-d.hailfinger.devel.2006@gmx.net
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