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?
For example if I'd want to write a 8Mbit BIOS file, only scan for 1024KB eeproms (determine (uncompressed) BIOS file's filesize). Reading/erasing is more difficult ofcourse, or not worthwile, requiring you be able to enter a size parameter.
So from: * alphabetical name for EEPROM * various sizes * various scan methods
To: * filesize * scan method 1 * results in some EEPROMS * scan method 2 * results in other EEPROMS -- etc
(this assumes 1 EEPROM only found through 1 method, or 1st method used, whatever).
Probably not worthwile, though it would reduce the verbose log by 75% Maybe also mirror the user's entered commandline in the log (minus the prompt/directory) to allow more eyes to check user's input
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.
Probably not worthwile, though it would reduce the verbose log by 75% Maybe also mirror the user's entered commandline in the log (minus the prompt/directory) to allow more eyes to check user's input
true. the first step to get them out of the way was http://patchwork.coreboot.org/patch/3151/
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
-
Bernd Blaauw -
Carl-Daniel Hailfinger -
Stefan Tauner