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?
To view, visit change 23840. To unsubscribe, or for help writing mail filters, visit settings.