Newbee patch for A49LF040A (Alix2c2) please have a look.

[Jens Kuehnel]

Hi coreboot list,

I visited the coreboot/flashrom talk during linuxtag, and was really 
impressed how "easy" it is can help/to hack. My target is to let 
coreboot run on my alix2c2 (the one with only 2 network cards).
The advantage for me is, its similar to an existing target (not too 
hard), but far enough to learn something.

My first problem it that flashrom does not support my flashchip.
But I hope I can fix this. :-) Patch attached.

But before I break my flash. Is it possible to destroy the chip, by 
using the wrong method?

The chip is a AMIC A49LF040A. It look like a SST 49LF040 replacement, I 
found the IDs @ http://www.amictechnology.com/pdf/A49LF040A.pdf.

I have a "LPC.1A", which means I can recover from bad flashes. But I 
don't like to solder SMD.

Can someone with more experience look over it, before I test it? Thanks 
a lot!

Greetings from Frankfurt/M (Germany)

CU
Jens

diff -u flashrom/flashchips.c flashrom-jk/flashchips.c
--- flashrom/flashchips.c       2008-06-05 18:06:52.000000000 +0200
+++ flashrom-jk/flashchips.c    2008-06-06 20:31:53.000000000 +0200
@@ -44,6 +44,7 @@
         {"Atmel",       "AT49F002(N)",          ATMEL_ID, 
AT_49F002N,             256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
         {"Atmel",       "AT49F002(N)T",         ATMEL_ID, 
AT_49F002NT,            256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
         {"Atmel",       "AT25DF321",            ATMEL_ID, 
AT_25DF321,             4096,   256,            TEST_OK_PREW, 
probe_spi_rdid,         spi_chip_erase_c7, spi_chip_write,  spi_chip_read},
+       {"Amic Technology","A49LF040A",         AMIC_ID, 
AMIC_A49LF040A,         512,    4096,           TEST_UNTESTED, 
probe_jedec,            erase_49lf040,                  write_49lf040},
         {"Amic Technology","A25L40P",           AMIC_ID, 
AMIC_A25L40P,           512,    256,            TEST_UNTESTED, 
probe_spi_rdid,         spi_chip_erase_c7, spi_chip_write, spi_chip_read},
         {"EMST",        "F49B002UA",            EMST_ID, 
EMST_F49B002UA,         256,    4096,           TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_49f002},
         {"EON",         "EN29F002(A)(N)B",      EON_ID, 
EN_29F002B,             256,    256,            TEST_UNTESTED, 
probe_jedec,            erase_chip_jedec,  write_jedec},
diff -u flashrom/flash.h flashrom-jk/flash.h
--- flashrom/flash.h    2008-06-05 18:06:52.000000000 +0200
+++ flashrom-jk/flash.h 2008-06-06 20:32:19.000000000 +0200
@@ -119,6 +119,7 @@
  #define AMIC_ID                        0x7F37  /* AMIC */
  #define AMIC_ID_NOPREFIX       0x37    /* AMIC */
  #define AMIC_A25L40P           0x2013
+#define AMIC_A49LF040A         0x379D

#define ASD_ID                 0x25    /* ASD, not listed in JEP106W */
  #define ASD_AE49F2008          0x52

[Carl-Daniel Hailfinger]

Hi Jens,

On 06.06.2008 20:50, Jens Kuehnel wrote:
> Hi coreboot list,
>
> I visited the coreboot/flashrom talk during linuxtag, and was really

I remember... you were the one who brought hardware to the workshop.
> impressed how "easy" it is can help/to hack. My target is to let 
> coreboot run on my alix2c2 (the one with only 2 network cards).
> The advantage for me is, its similar to an existing target (not too 
> hard), but far enough to learn something.

That's great.
> My first problem it that flashrom does not support my flashchip.
> But I hope I can fix this. :-) Patch attached.

Thanks for the patch. Unfortunately it seems your mailer wrapped the
patch. Thunderbird users either
- have to attach the patch or
- select HTML composition, then choose "Preformat", then paste the patch
and then send it and confirm converting the mail to plain text.
> But before I break my flash. Is it possible to destroy the chip, by 
> using the wrong method?

In theory, this should not happen. In practice, old or extremely cheap
flash chips can have sticky bits after a few erase cycles. I think the
risk for your board is almost zero.
> The chip is a AMIC A49LF040A. It look like a SST 49LF040 replacement, I 
> found the IDs @ http://www.amictechnology.com/pdf/A49LF040A.pdf.
>
> I have a "LPC.1A", which means I can recover from bad flashes. But I 
> don't like to solder SMD.
>
> Can someone with more experience look over it, before I test it? Thanks 
> a lot!

I'd like to do that, but the patch was so mangled that I had problems
reading it. It looks like you put vendor and device ID together in
AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
> Greetings from Frankfurt/M (Germany)

Greetings from Tuebingen (same country)

Regards,
Carl-Daniel

[Jens Kuehnel]

Carl-Daniel Hailfinger schrieb:
Hi,
> I remember... you were the one who brought hardware to the workshop.

Yep, thats me. :-)
> > My first problem it that flashrom does not support my flashchip.
> > But I hope I can fix this. :-) Patch attached.
>
> Thanks for the patch. Unfortunately it seems your mailer wrapped the
> patch. Thunderbird users either
> have to attach the patch or

Done
> In theory, this should not happen. In practice, old or extremely cheap
> flash chips can have sticky bits after a few erase cycles. I think the
> risk for your board is almost zero.

I thought so, but want to be sure.
> I'd like to do that, but the patch was so mangled that I had problems
> reading it. It looks like you put vendor and device ID together in
> AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.

OK, I changed that.
> > Greetings from Frankfurt/M (Germany)
>
> Greetings from Tuebingen (same country)

CU
Jens

[Carl-Daniel Hailfinger]

Hi Jens,

On 07.06.2008 00:39, Jens Kuehnel wrote:
> Carl-Daniel Hailfinger schrieb:
> > I'd like to do that, but the patch was so mangled that I had problems
> > reading it. It looks like you put vendor and device ID together in
> > AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
>
> OK, I changed that.

Looks really good.

The only remaining question is whether the erase and write functions
should be the generic JEDEC functions instead. I haven't tested that and
unfortunately I did not have time to read the spec yet.

Simply running "flashrom" with the patch should tell you whether the
chip detection works and it is absolutely harmless. We can postpone
testing erase and write until you have confirmed chip detection.

Also, could you please add a Signed-off-by statement to your patch?
Otherwise we can't commit it. See
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details.

Regards,
Carl-Daniel

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Sat, Jun 07, 2008 at 01:55:50AM +0200, Carl-Daniel Hailfinger wrote:
> Hi Jens,
>
> On 07.06.2008 00:39, Jens Kuehnel wrote:
> > Carl-Daniel Hailfinger schrieb:
> > > I'd like to do that, but the patch was so mangled that I had problems
> > > reading it. It looks like you put vendor and device ID together in
> > > AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
> >
> > OK, I changed that.
>
> Looks really good.
>
> The only remaining question is whether the erase and write functions
> should be the generic JEDEC functions instead. I haven't tested that and
> unfortunately I did not have time to read the spec yet.
>
> Simply running "flashrom" with the patch should tell you whether the
> chip detection works and it is absolutely harmless. We can postpone
> testing erase and write until you have confirmed chip detection.

I'm testing on an ALIX.2c3, which has the same rom chip:

# ./flashrom 
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.

-----------------------------------------------------------------------------

So that's good. But running it again flashrom no longer sees the chip!

# ./flashrom -v -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom 
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

-----------------------------------------------------------------------------

After a cold reboot, I can run flashrom again, and the image it reads out
looks like it could be correct:

# ./flashrom -v -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
Verifying flash... VERIFIED.          
littleredbox:/usr/src/flashrom3# v test.rom 
-rw-r--r-- 1 root src 524288 2008-06-06 23:15 test.rom

-----------------------------------------------------------------------------

And then, no more:

# ./flashrom -v -r test2.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
No EEPROM/flash device found.

Thanks,
Ward.

[Carl-Daniel Hailfinger]

On 07.06.2008 05:17, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 01:55:50AM +0200, Carl-Daniel Hailfinger wrote:
> > Hi Jens,
> >
> > On 07.06.2008 00:39, Jens Kuehnel wrote:
> > > Carl-Daniel Hailfinger schrieb:
> > > > I'd like to do that, but the patch was so mangled that I had problems
> > > > reading it. It looks like you put vendor and device ID together in
> > > > AMIC_A49LF040A. The vendor ID you want is probably AMIC_ID_NOPREFIX.
> > >
> > > OK, I changed that.
> >
> > Looks really good.
> >
> > The only remaining question is whether the erase and write functions
> > should be the generic JEDEC functions instead. I haven't tested that and
> > unfortunately I did not have time to read the spec yet.
> >
> > Simply running "flashrom" with the patch should tell you whether the
> > chip detection works and it is absolutely harmless. We can postpone
> > testing erase and write until you have confirmed chip detection.
>
> I'm testing on an ALIX.2c3, which has the same rom chip:
>
> # ./flashrom 
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
> Please email a report to [e-mail] if any of the above operations
> work correctly for you with this flash part. Please include the full output
> from the program, including chipset found. Thank you for your help!
> ===
> No operations were specified.
>
> So that's good. But running it again flashrom no longer sees the chip!
>
> # ./flashrom -v -r test.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.
>
> # ./flashrom 
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.
>
> After a cold reboot, I can run flashrom again, and the image it reads out
> looks like it could be correct:
>
> # ./flashrom -v -r test.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> ===
> This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
> Please email a report to [e-mail] if any of the above operations
> work correctly for you with this flash part. Please include the full output
> from the program, including chipset found. Thank you for your help!
> ===
> Reading Flash...done
> Verifying flash... VERIFIED.          
> littleredbox:/usr/src/flashrom3# v test.rom 
> -rw-r--r-- 1 root src 524288 2008-06-06 23:15 test.rom
>
> And then, no more:
>
> # ./flashrom -v -r test2.rom
> Calibrating delay loop... OK.
> No coreboot table found.
> Found chipset "AMD CS5536", enabling flash write... OK.
> No EEPROM/flash device found.

I suspect one of the other probe functions is killing communication with
the chip. If that's not the case, maybe we don't leave ID mode correctly.

Can you try repeated
flashrom -c A49LF040A
(I forgot the exact chipname specification) after a cold boot?

Regards,
Carl-Daniel

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
> I suspect one of the other probe functions is killing communication with
> the chip. If that's not the case, maybe we don't leave ID mode correctly.
>
> Can you try repeated
> flashrom -c A49LF040A
> (I forgot the exact chipname specification) after a cold boot?

Yeah, that works:

littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
No operations were specified.
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom -V
Calibrating delay loop... 108M loops per second. OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Probing for Amic Technology A49LF040A, 512 KB: probe_jedec: id1 0x37, id2
0x9d
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A -r test2.rom -v
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "AMD CS5536", enabling flash write... OK.
Found chip "Amic Technology A49LF040A" (512 KB) at physical address
0xfff80000.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
Please email a report to [e-mail] if any of the above operations
work correctly for you with this flash part. Please include the full output
from the program, including chipset found. Thank you for your help!
===
Reading Flash...done
Verifying flash... VERIFIED.

Thanks,
Ward.

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Carl-Daniel Hailfinger]

On 07.06.2008 05:47, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
> > I suspect one of the other probe functions is killing communication with
> > the chip. If that's not the case, maybe we don't leave ID mode correctly.
> >
> > Can you try repeated
> > flashrom -c A49LF040A
> > (I forgot the exact chipname specification) after a cold boot?
>
> Yeah, that works:
>
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.
> littleredbox:/usr/src/flashrom3# ./flashrom -c A49LF040A
> [...]
> Found chip "Amic Technology A49LF040A" (512 KB) at physical address
> 0xfff80000.
> [...]
> No operations were specified.

Ouch. So one of the other probe functions kills communication. Can one
of you try disabling other chip definitions in flashchips.c with #if 0
to narrow this problem down?

Regards,
Carl-Daniel

Newbee patch for A49LF040A (Alix2c2) please have a look.

> On 07.06.2008 05:47, Ward Vandewege wrote:
> > On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
>
> Ouch. So one of the other probe functions kills communication. Can one
> of you try disabling other chip definitions in flashchips.c with #if 0
> to narrow this problem down?

I did a small shell script.
flashrom -c "W29EE011"
is the problem!

CU
Jens

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> Ouch. So one of the other probe functions kills communication. Can one
> of you try disabling other chip definitions in flashchips.c with #if 0
> to narrow this problem down?

This is the culprit:

{"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},

Thanks,
Ward.

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Stefan Reinauer]

Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> > Ouch. So one of the other probe functions kills communication. Can one
> > of you try disabling other chip definitions in flashchips.c with #if 0
> > to narrow this problem down?
>
> This is the culprit:
>
> {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},

Is it enough to change the order of the lines?

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
> Ward Vandewege wrote:
> > On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> > > Ouch. So one of the other probe functions kills communication. Can one
> > > of you try disabling other chip definitions in flashchips.c with #if 0
> > > to narrow this problem down?
> >
> > This is the culprit:
> >
> > {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> > TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
>
> Is it enough to change the order of the lines?

No; the probe for W29EE011 is done after the probe for A49LF040A.

Thanks,
Ward.

[Stefan Reinauer]

Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
> > Ward Vandewege wrote:
> > > On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> > > > Ouch. So one of the other probe functions kills communication. Can one
> > > > of you try disabling other chip definitions in flashchips.c with #if 0
> > > > to narrow this problem down?
> > >
> > > This is the culprit:
> > >
> > > {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> > > TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
> >
> > Is it enough to change the order of the lines?
>
> No; the probe for W29EE011 is done after the probe for A49LF040A.
>
> Thanks,
> Ward.

Ah, this is broken... flashrom should not continue when it found a chip
in a given memory area already.

Stefan

[Carl-Daniel Hailfinger]

On 07.06.2008 16:07, Stefan Reinauer wrote:
> Ward Vandewege wrote:
> > On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
> > > Ward Vandewege wrote:
> > > > On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
> > > > > Ouch. So one of the other probe functions kills communication. Can one
> > > > > of you try disabling other chip definitions in flashchips.c with #if 0
> > > > > to narrow this problem down?
> > > >
> > > > This is the culprit:
> > > >
> > > > {"Winbond", "W29EE011",   WINBOND_ID, W_29C011,   128,  128,
> > > > TEST_OK_PREW, probe_w29ee011,   erase_chip_jedec,   write_jedec},
> > >
> > > Is it enough to change the order of the lines?
> >
> > No; the probe for W29EE011 is done after the probe for A49LF040A.
> >
> > Thanks,
> > Ward.
>
> Ah, this is broken... flashrom should not continue when it found a chip
> in a given memory area already.

Besides that, we probe twice for W_29C011. Once we probe with the normal
JEDEC function, the second time we use the special probe function. Maybe
we can figure out why.

Regards,
Carl-Daniel

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Peter Stuge]

On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> Ah, this is broken... flashrom should not continue when it found a
> chip in a given memory area already.

flashrom supports boards with more than one flash chip.

But perhaps we need to teach flashrom more about how chips can be
connected. On boards with two chips, they can obviously not be on
the same LPC bus for example. There would be a collision on the bus.

Ward and me investigated. The W29EE011 probe command is quite similar
to the A49LF040A block erase command, but the last byte differs.
A49LF040A seems to enter an undefined state when it receives such an
unknown command. Sleeping the maximum A49LF040A timeout before
sending the jedec ID exit command did not help.

It seems to me that the Amic chip is behaving badly.

Action plan?

1. Penalize W29EE011 by never probing it without -c W29EE011

This sucks because the W29EE011 chip isn't the one misbehaving here.
On the other hand, it does have a nasty product ID sequence.

2. Make order in flashchips.c important, and stop probing after an
   A49LF040A is found since we know no boards with Amic+other chip.

This sucks because it is SO not obvious that the order of entries in
the table should matter. It also sucks because we would introduce an
exception in the flashrom code flow.

3. Teach flashrom that the only way to have multiple flash chips is
   to have them on different busses. LPC and ISA would have to be
   considered the same, which I think is OK.

This sucks for the same reasons as #2 above. The order of entries in
flashchips.c becomes important here as well.

Personally I think #1 is the lesser of these evils, mainly because
that solution is tinker safe, generic, and W29EE011 is not so common
today. It is not a great solution though, so please share your input
and any ideas.

//Peter

[Carl-Daniel Hailfinger]

On 07.06.2008 16:29, Peter Stuge wrote:
> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > Ah, this is broken... flashrom should not continue when it found a
> > chip in a given memory area already.
>
> flashrom supports boards with more than one flash chip.
>
> But perhaps we need to teach flashrom more about how chips can be
> connected. On boards with two chips, they can obviously not be on
> the same LPC bus for example. There would be a collision on the bus.

Well, you can have multiple different/identical LPC chips on the same
bus as long as they are strapped to different memory locations (chip
numbers). flashrom ignores that right now.
> Ward and me investigated. The W29EE011 probe command is quite similar
> to the A49LF040A block erase command, but the last byte differs.
> A49LF040A seems to enter an undefined state when it receives such an
> unknown command. Sleeping the maximum A49LF040A timeout before
> sending the jedec ID exit command did not help.

Does anyone have the ability to test whether the standard JEDEC probe
would work for the W29EE011?
> It seems to me that the Amic chip is behaving badly.
>
> Action plan?
> Penalize W29EE011 by never probing it without -c W29EE011
>
> This sucks because the W29EE011 chip isn't the one misbehaving here.
> On the other hand, it does have a nasty product ID sequence.
> Make order in flashchips.c important, and stop probing after an
> A49LF040A is found since we know no boards with Amic+other chip.
>
> This sucks because it is SO not obvious that the order of entries in
> the table should matter. It also sucks because we would introduce an
> exception in the flashrom code flow.

Table order did matter until the "multiple flash chip support" patch was
merged. Having an exception for the Amic chip sounds bad, though.
> Teach flashrom that the only way to have multiple flash chips is
> to have them on different busses. LPC and ISA would have to be
> considered the same, which I think is OK.
>
> This sucks for the same reasons as #2 above. The order of entries in
> flashchips.c becomes important here as well.

That's the only correct way to do it.
> Personally I think #1 is the lesser of these evils, mainly because
> that solution is tinker safe, generic, and W29EE011 is not so common
> today. It is not a great solution though, so please share your input
> and any ideas.

I'd say retest whether the W29EE011 can work with standard JEDEC
commands, then decide on further actions.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> On 07.06.2008 16:29, Peter Stuge wrote:
> > On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > > Ah, this is broken... flashrom should not continue when it found a
> > > chip in a given memory area already.
> >
> > flashrom supports boards with more than one flash chip.
> >
> > But perhaps we need to teach flashrom more about how chips can be
> > connected. On boards with two chips, they can obviously not be on
> > the same LPC bus for example. There would be a collision on the bus.  
> > 3. Teach flashrom that the only way to have multiple flash chips is
> >    to have them on different busses. LPC and ISA would have to be
> >    considered the same, which I think is OK.
> >
> > This sucks for the same reasons as #2 above. The order of entries in
> > flashchips.c becomes important here as well.
>
> That's the only correct way to do it.

It does not have to be different busses. There can be 4 flash chips in a
row on the same bus, but not sharing the same physical address space.

[Carl-Daniel Hailfinger]

On 07.06.2008 18:37, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > On 07.06.2008 16:29, Peter Stuge wrote:
> > > On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > > > Ah, this is broken... flashrom should not continue when it found a
> > > > chip in a given memory area already.
> > Well, you can have multiple different/identical LPC chips on the same
> > bus as long as they are strapped to different memory locations (chip
> > numbers). flashrom ignores that right now.
> > > flashrom supports boards with more than one flash chip.
> > >
> > > But perhaps we need to teach flashrom more about how chips can be
> > > connected. On boards with two chips, they can obviously not be on
> > > the same LPC bus for example. There would be a collision on the bus.  
> > > 3. Teach flashrom that the only way to have multiple flash chips is
> > >    to have them on different busses. LPC and ISA would have to be
> > >    considered the same, which I think is OK.
> > >
> > > This sucks for the same reasons as #2 above. The order of entries in
> > > flashchips.c becomes important here as well.
> >
> > That's the only correct way to do it.
>
> It does not have to be different busses. There can be 4 flash chips in a
> row on the same bus, but not sharing the same physical address space.

Yes, I wrote that in my mail as well. The "only correct way" statement
was a bit strong, it was intended to request probing for one chip per
bus+addresspace only.

Regards,
Carl-Daniel

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Sat, Jun 07, 2008 at 04:29:13PM +0200, Peter Stuge wrote:
> On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > Ah, this is broken... flashrom should not continue when it found a
> > chip in a given memory area already.
>
> flashrom supports boards with more than one flash chip.
>
> But perhaps we need to teach flashrom more about how chips can be
> connected. On boards with two chips, they can obviously not be on
> the same LPC bus for example. There would be a collision on the bus.
>
> Ward and me investigated. The W29EE011 probe command is quite similar
> to the A49LF040A block erase command, but the last byte differs.
> A49LF040A seems to enter an undefined state when it receives such an
> unknown command. Sleeping the maximum A49LF040A timeout before
> sending the jedec ID exit command did not help.
>
> It seems to me that the Amic chip is behaving badly.
>
> Action plan?
> Penalize W29EE011 by never probing it without -c W29EE011
>
> This sucks because the W29EE011 chip isn't the one misbehaving here.
> On the other hand, it does have a nasty product ID sequence.

Please find a patch attached that does just that.

Thanks,
Ward.

Newbee patch for A49LF040A (Alix2c2) please have a look.

[Ward Vandewege]

On Tue, Jun 17, 2008 at 10:08:58PM -0400, Ward Vandewege wrote:
> On Sat, Jun 07, 2008 at 04:29:13PM +0200, Peter Stuge wrote:
> > On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
> > > Ah, this is broken... flashrom should not continue when it found a
> > > chip in a given memory area already.
> >
> > flashrom supports boards with more than one flash chip.
> >
> > But perhaps we need to teach flashrom more about how chips can be
> > connected. On boards with two chips, they can obviously not be on
> > the same LPC bus for example. There would be a collision on the bus.
> >
> > Ward and me investigated. The W29EE011 probe command is quite similar
> > to the A49LF040A block erase command, but the last byte differs.
> > A49LF040A seems to enter an undefined state when it receives such an
> > unknown command. Sleeping the maximum A49LF040A timeout before
> > sending the jedec ID exit command did not help.
> >
> > It seems to me that the Amic chip is behaving badly.
> >
> > Action plan?
> > Penalize W29EE011 by never probing it without -c W29EE011
> >
> > This sucks because the W29EE011 chip isn't the one misbehaving here.
> > On the other hand, it does have a nasty product ID sequence.
>
> Please find a patch attached that does just that.

And now for a revised copy that does not disable -c W29EE011 as well (thanks
Peter!).

Thanks,
Ward.

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Peter Stuge]

On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
> This patch disables default probing for the Winbond W29EE011, because
> its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.

Ok! I put together these patches and also found that the Pm49FL
functions work for this chip.

//Peter

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Carl-Daniel Hailfinger]

On 18.06.2008 06:28, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
> > This patch disables default probing for the Winbond W29EE011, because
> > its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.
>
> Ok! I put together these patches and also found that the Pm49FL
> functions work for this chip.

I'd still like to know:
- whether the W29EE011 non-standard probing could be replaced by JEDEC
probing
- whether we can write 0xFF to the chip after probing, triggering a
reset for most chips.

Regards,
Carl-Daniel

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Peter Stuge]

On Wed, Jun 18, 2008 at 01:56:33PM +0200, Carl-Daniel Hailfinger wrote:
> I'd still like to know:
> whether the W29EE011 non-standard probing could be replaced by
>
> JEDEC probing

I don't believe we will be able to test this anytime soon because the
chip is quite old.
> whether we can write 0xFF to the chip after probing, triggering a
>
> reset for most chips.

We did try writing the product ID exit command, and unfortunately it
did not help.

Note that the chip still responds fine to LPC reads, data is
returned, but any write commands are ignored. The way I read the data
sheet this indicates that the chip is in an undocumented state.

Please do feel free to investigate this further, but personally I
doubt we'll ever find out what AMIC's state machine is up to. :\

//Peter

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Carl-Daniel Hailfinger]

On 18.06.2008 15:35, Peter Stuge wrote:
> On Wed, Jun 18, 2008 at 01:56:33PM +0200, Carl-Daniel Hailfinger wrote:
> > I'd still like to know:
> > whether the W29EE011 non-standard probing could be replaced by
> >
> > JEDEC probing
>
> I don't believe we will be able to test this anytime soon because the
> chip is quite old.

And it is listed as TEST_OK_PREW in flashchips.c, so we have some tester
somewhere (Uwe). By the way, since we don't probe for that chip anymore,
we have to change the chip to TEST_OK_REW|TEST_BAD_PROBE.
> > whether we can write 0xFF to the chip after probing, triggering a
> >
> > reset for most chips.
>
> We did try writing the product ID exit command, and unfortunately it
> did not help.

Yes, that's why I suggested 0xFF.
> Note that the chip still responds fine to LPC reads, data is
> returned, but any write commands are ignored. The way I read the data
> sheet this indicates that the chip is in an undocumented state.
>
> Please do feel free to investigate this further, but personally I
> doubt we'll ever find out what AMIC's state machine is up to. :\

Unfortunately I don't have the necessary hardware.

Regards,
Carl-Daniel

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Ward Vandewege]

On Wed, Jun 18, 2008 at 06:28:26AM +0200, Peter Stuge wrote:
> On Tue, Jun 17, 2008 at 10:25:15PM -0400, Ward Vandewege wrote:
> > This patch disables default probing for the Winbond W29EE011, because
> > its (unusual) probe sequence puts the AMIC A49LF040A in a funky state.
>
> Ok! I put together these patches and also found that the Pm49FL
> functions work for this chip.
>
> //Peter
>
> !DSPAM:4858af3c32361804284693!
> flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore
>
> Jens sent the first patch that added A49LF040A to flash.h and flashchips.c
> using _jedec and _49lf040 functions.
>
> An issue was found with probe_w29ee011() for the Winbond W29EE011, which
> caused the A49LF040A to no longer respond to any commands.
>
> Ward made a patch to disable probing by default for the W29EE011 following
> some discussion. Using -c W29EE011 will make flashrom probe for the chip.
>
> Peter did some more datasheet diving and found that the Pm49FL00x functions
> suited this chip quite well because of the block locking registers in
> A49LF040A, and finally tested PROBE READ ERASE WRITE to work on ALIX.3c3.
>
> Signed-off-by: Jens Kuehnel 
> Signed-off-by: Ward Vandewege 
> Signed-off-by: Peter Stuge

Excellent - confirmed to work on alix.2c3.

Acked-by: Ward Vandewege

Thanks,
Ward.

flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore

[Peter Stuge]

On Wed, Jun 18, 2008 at 08:42:32AM -0400, Ward Vandewege wrote:
> Excellent - confirmed to work on alix.2c3.
>
> Acked-by: Ward Vandewege

Thanks! r3368

//Peter

[PATCH] Newbee patch for A49LF040A (Alix2c2) please have a look.

[Jens Kuehnel]

Carl-Daniel Hailfinger schrieb:
> Hi Jens,

Here the patch, I will play around with generic JEDEC and detection 
tomorrow.

CU
Jens
---

Signed-Off-By: Jens Kuehnel

[PATCH] Newbee patch for A49LF040A (Alix2c2) please have a look.

[Jens Kuehnel]

Hi,
I tried to erase the flash tonight. But without result, both 
erase_49lf040 and erase_chip_jedec.

But after a erase_49fl040 the chip does not reacts anymore,until a reboot.

I will compare the Specs of SST49LF040 and the AMIC and will try again 
tomorrow.

Good night from Germany.

CU
Jens