[flashrom] selective probing?

[Carl-Daniel Hailfinger]

Am 07.07.2011 11:00 schrieb Stefan Tauner:
> On Thu, 07 Jul 2011 02:39:14 +0200
> Bernd Blaauw <bblaauw at home.nl> 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/