Some random thoughts about progress printing in flashrom.
Am Freitag, den 09.07.2010, 21:55 +0200 schrieb Carl-Daniel Hailfinger:
The biggest problem is deciding which operations should print a progress bar.
The first thing we have to be aware of is that there are two kinds of progress printing that seems very similar, but are in fact completely different when you get at implementing them. Being aware of this distinction should help answering some of the questions.
A) The first type of progress bar ist just what one naively thinks of when one heres "progress bar", i.e. 0%=start of "operation", 100%=end of "operation". You "just" have to define what you mean by "operation", and how to map the steps of the operation to percentage.
B) The second type of progress bar is a "flash status map". You probably know the kind of disk map displayed by the defragmentation tools, I mean something like that. So we can display flash areas as "no rewrite needed", "sucessfully flashed", "erased sucessfully", "currently modified block" and so on, for example by different letters or colors representing the different states.
It might turn out that in fact we want both type-A (simple UI) and type-B (sophisticated GUI, having the status map and a type-A progress bar) progress indication, but as far as I can see this means we have to implement both seperately, and not have just one type of progress indication and try to fudge the one type of output from code that calls status updates for the other type.
Write? Sure. Erase? Sure. But how do you handle a one-sector erase in the middle of some write operation?
One-sector-erases don't just happen in the middle of write, but they are planned from the beginning. If you want to go to mere progress printing, the "operation" defined above must include both erasing and writing, so that erasing is a part of the "operation". This has the consequence that the "current address" is not directly proportional to the progress bar state, as the "operation" is not just doing one thing for each addresss.
If you are deciding to implement type-B address map printing, this question of course does not apply at all.
Read? Makes sense as well. But how do you handle the reads used for verification of erase/write? The two-bars problem strikes again.
Same comment as above. A "in-total" progress bar needs to consider for each "block" (probably erase-block) the steps of "erase", "erase check", "write", "verify" and scale the progress appropriately. Or one recolors/overwrites "erasing" marks to "erased OK" marks.
Another problem: How often do we call the progress bar update? Once per byte? Per sector? Per arbitrary unit? Will the division and multiplication performed on every progress bar update affect performance, especially on architectures where such operations are sloooooooooow?
Of course calling progress update per byte is nonsense. We need a bigger unit. For some operations like mmapped reads (block copies) that are currently implemented atomic, progress updating seems to make no sense. Most flash operations are considerably slower than progress bar updates (think page program, sector erase, chip erase). The only operation that suffers from progress printing would be byte program/byte read. Maybe even the 5-byte stuff some SPI masters have at maximum.
One approach to solve the problem of "how do we avoid much too many multiplication/division operations" is to calculate the position of the next change too when a change of the progress bar is printed, and ignore all progess values (maybe addresses, but see above that addresses might not be what we really want) below the calculated next-change point. This avoids all calculations until needed.
Regards, Michael Karcher