To librarize flashrom, we have to move away from printf to generic printing functions.
I'd like to classify messages into four severity levels: * Error (out of memory, write failed, ...) * Warning (chipset init incomplete, ...) * Notice (chip detected, flashing successful) * Debug
I also would like to differentiate between controller related and flashchip related messages. E.g. one might be interested in verbose probing output, but not in full SB600 SPI debugging for every command sent. Since all messages above debug level are shown anyway, this differentiation makes most sense if only applied to debug messages. Suggested set of message functions (all with printk syntax): msg_err msg_warn msg_notice msg_debug_controller msg_debug_flash
Progress printing is done with dots, equals, numbers, sometimes with, sometimes without backspace for beautification. Some focus on percentage, others focus on addresses. With a maxval parameter, we can handle policy on a case-by-case basis. Suggested progress bar function: progressbar(int curval, int maxval)
Comments appreciated.
Regards, Carl-Daniel
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
So I like the idea of being able to optionally disable the progress bar.
thanks
ron
On 18.09.2009 15:49, ron minnich wrote:
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
So I like the idea of being able to optionally disable the progress bar.
Sure. The frontend is free to replace the progressbar function with an empty function (or a spinning animation, if anyone really cares) as long as the function signature stays the same. To be honest, I'd like to have progress printing off by default (and enable it in verbose mode) in the flashrom binary.
Regards, Carl-Daniel
On Fri, Sep 18, 2009 at 06:49:44AM -0700, ron minnich wrote:
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
So I like the idea of being able to optionally disable the progress bar.
Yep, too fast progress bar printing is also a problem on serial sometimes, it even caused some flashing to reproducibly fail for me, until I decreased the amount of stuff printed on the serial port.
Uwe.
On 18.09.2009 16:06, Uwe Hermann wrote:
Yep, too fast progress bar printing is also a problem on serial sometimes, it even caused some flashing to reproducibly fail for me, until I decreased the amount of stuff printed on the serial port.
By the way, if you're using SB600 SPI and have a flash chip with one-byte writing, you get ~150 MB debug output from the chipset driver alone.
Regards, Carl-Daniel
ron minnich wrote:
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
I want to add to this: We've had cases where printing too much output would mess with the timing (maximum time allowed until a block has to be completely written) due to heavy output of "current addresses" over a serial line. Not only would it take several hours to finish but the result was a few dozen non-booting systems. Very frustrating.
Stefan
On 18.09.2009 20:28, Stefan Reinauer wrote:
ron minnich wrote:
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
I want to add to this: We've had cases where printing too much output would mess with the timing (maximum time allowed until a block has to be completely written) due to heavy output of "current addresses" over a serial line. Not only would it take several hours to finish but the result was a few dozen non-booting systems. Very frustrating.
So the consensus is to make progress bars (or any other progress printing) off by default? Great.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 18.09.2009 20:28, Stefan Reinauer wrote:
ron minnich wrote:
one thing to keep in mind: the limiting factor on progress on flashing 1024 nodes at a time was the printout of the "current address" being flashed. I had to turn that off or a 30-second task could take much, much longer.
I want to add to this: We've had cases where printing too much output would mess with the timing (maximum time allowed until a block has to be completely written) due to heavy output of "current addresses" over a serial line. Not only would it take several hours to finish but the result was a few dozen non-booting systems. Very frustrating.
So the consensus is to make progress bars (or any other progress printing) off by default? Great.
Not necessarily... Just make sure it doesn't print more than a given number of characters per block (no spinning wheels or some such) over serial port.
-
Carl-Daniel Hailfinger -
ron minnich -
Stefan Reinauer -
Uwe Hermann