Dear Pali Rohár,
In message 20210913110806.27hc36n6gmhw6uq4@pali you wrote:
If you use loady in any kind of scripts, this would now hard hang the system, while until now it was possible to recover from the error.
Yes, this is a good point. But on the other hand, 'loadb' and 'loads' commands already have this behavior. So question is if it is better to have same behavior in all 'load?' commands or each 'load?' would behave differently... Because for software which transmit files and supports more protocols (e.g. both x-modem and kermit) it may be a nightmare if receiver behaves differently...
Yes, you are right, there is an unlucky difference in behaviour. But all these interfaces are pretty old, and I would not invest efforts to fix a aproblem nobody ever noticed before, at the risk of breaking existing stuff.
I wonder if there are any users of 'loads' left - the Motorola S-record format is close to 50 years old and cumbersome to use. I can't even remeber when I used it the last time - must be 15+ years or such.
'loadb" is a different thing, but there you usually have kermit on the other side, and usually run an interactive session (or an automated one using something like tbot ) - in any case, you normally have to interact on both sides.
I never had a problem wih the current behaviour there.
If you do not have integrated y-modem support in your terminal you have to do:
- open terminal and write 'loady' into U-Boot console
- disconnect terminal
- start y-modem software
- choose file to transmit
- instruct y-modem software to start transfer
And if 'loady' timeouts between 2) - 5) then it returns back to the
If this happens, the timeout is inconveniently short of you are too slow. I think what would be helpful is to make the timeout adjustable (env var).
So... I do not know what is better if current behavior or this new which changes UI interaction.
We can do both, and still solve your problem: make the timeout adjustable so you can set it to something you can conveniently work with.
Best regards,
Wolfgang Denk