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