Change in flashrom[master]: Add "gingerly" flashing mode for the unreliable ISP environments

[Nico Huber (Code Review)]

Nico Huber has posted comments on this change. ( https://review.coreboot.org/23840 )

Change subject: Add "gingerly" flashing mode for the unreliable ISP environments
......................................................................

Patch Set 2:
> However, even with such a dangerous boards in the existence, ISP is
> still much safer than desoldering a flash chip without an experienced
> steady hand - that's why I believe the advanced modes for ISP flashing,
> be it that "gingerly" mode or any other future inventions, have a right
> to exist

No need to argue about that. It just has to be done right. And in a way
that doesn't encourage users to do stupid things.
> > > > And that is where the problems start... if it can fail,
> > > > we have to handle the failure correctly, otherwise
> > > > flashrom (in its current implementation) would probably
> > > > fall back to erase the whole chip and make things worse.
> > >
> > > If there is a timeout: we could just print some error message and
> > > shutdown the flashrom, then it shouldn't do anything else... also,
> > > why would it try to erase the whole chip if we didn't specify such
> > > an operation?
> >
> > Flashrom defaults to try another erase function if one fails,
> > finally using one that erases the whole chip. Can be handled
> > more gracefully ofc, just something that we have to keep in
> > mind.
>
> Perhaps there should be a way to just exit a flashrom with some message
> without trying any other erase functions. Maybe by adding a new return
> value to the erase functions ( perhaps "2" or "-2" if there is already
> "1" or "-1" code in the failure case ) and adjusting the flashrom
> algorithm to act accordingly if such a return value has been accepted
> from erase function

Yes, there is already a distinction in return values. One just has to
choose the right one. Maybe it is already safe, I just wanted to make
sure we don't forget about it ;)
> > > Also, if we'd introduce a timeout - it shouldn't be hardcoded. In
> > > example: if I'd hardcode it to 5 seconds - it will block a way for
> > > the boards whose chip is available for 1 second per each 10 seconds;
> > > hardcode to 15 seconds - blocks those which are 1sec/20sec available,
> > > and so on
> > >
> > > Most likely we'll have to introduce a new flag "-t | --timeout
> > > <seconds>" ("t" is also not occupied) but lets' have more discussions
> > > to clarify our further steps
> >
> > I would prefer a static timeout, doesn't have to be a small one.
> > For instance 60s, then bail out. It's not that bad to wait 1min
> > but if single hunks take more than 60s, nobody would have the
> > patience to wait for the full run anyway.
>
> Is it possible that there are some boards with a lengthy
> available/unavailable durations, like " 70 seconds unavailable / 30
> seconds available " ? If yes, the full run would still could take a
> reasonably small time despite the long wait between each two groups of
> many successful attempts

Anything is possible with a broken hardware setup... how about we
start with a static timeout and discuss an option for it in a follow-
up commit?