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. Regards, Carl-Daniel -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
