[coreboot] Newbee patch for A49LF040A (Alix2c2) please have a look.
c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 7 18:14:17 CEST 2008
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?
> 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.
Table order did matter until the "multiple flash chip support" patch was
merged. Having an exception for the Amic chip sounds bad, though.
> 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.
> 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.
More information about the coreboot