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

Peter Stuge peter at stuge.se
Sat Jun 7 16:29:13 CEST 2008


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




More information about the coreboot mailing list