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