Am 07.07.2011 11:00 schrieb Stefan Tauner: > On Thu, 07 Jul 2011 02:39:14 +0200 > Bernd Blaauw <[email protected]> wrote: > >> Whenever I read the verbose logs I see *all* chips being probed, which >> is pretty fast already. Is there any point to "optimise"(?) this amount >> to "per size" ? Possibly followed by per-method? >> > sizes are pretty uninteresting... we were even discussing dropping its > output in the "probing for" line. > > it does not make sense to probe like we do currently. we resend the > same commands over and over again and get back the same answer if > everything works correctly; just to check if the answer matches the > current chip to be probed... fixing this is on carl-daniel's roadmap, > but i don't know any details yet. >
We could switch to a probe-once scheme (and newbies usually suggest that as the first easy fix), but it is actually harder than most people realize. For LPC/FWH/Parallel chips, we have to run one probe per timing/size/reset/probe combination. We have roughly 10 probe functions, 8 sizes, 3 reset functions and 3 timings. 10*8*3*3=720. This probe-once scheme would mean 720 calls to a probe function for LPC/FWH/Parallel chips alone, and given the 143 currently supported flash chips of that group, this would be an additional 577 probe calls. If we build a lot of intelligence into the generic probing loop to weed out combinations not required for any flash chip, we might get down to maybe 20-40 probes. Yes, it can be done, but I'd rather solve other issues first (e.g. handling multiple flash chips sanely which requires a probing rewrite anyway). >> Maybe also mirror the user's entered commandline in the log (minus the >> prompt/directory) to allow more eyes to check user's input >> Ah yes, that's part of my logging patch. I need to push that one for inclusion. Regards, Carl-Daniel -- http://www.hailfinger.org/ _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
