On 24.06.2008 11:36, Peter Stuge wrote: > On Tue, Jun 24, 2008 at 11:16:37AM +0200, Carl-Daniel Hailfinger wrote: > >>>> NACK. This patch randomly (depending on flashchips.c order) breaks >>>> probing for ~80% of the chips we currently support. >>>> >>> Can you expand on why this would happen? >>> >> The pointer to the (bios) probe location changes depending on flash >> chip size. >> > > Yes of course! Thank you to Stefan and you for cluestick on head. >
You're welcome. (A few months ago, I had the same idea, but I buried it pretty fast ;-) ) >> There are three ways to solve this: >> - Keep probe results per function per chip size (ugly) >> > > I like a variation on this: > > - Cache probe results per function per start address > > I don't think it's so ugly because as you pointed out the address > probed is input to the sequence. > > Needs a little more code changed though. > And it is definitely post-1.0 material if we ever commit it. Things to do if you want to move forward with that: - Generalize probing so that you can probe for the same chip at multiple memory locations (ID strapping) - Same for multiple buses - Probe only for buses (SPI, LPC, ...) which make sense The last point would automatically fix the AMIC/W29EE conflict because both can't reside on the same bus. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
