On Mon, Sep 13, 2021 at 01:08:06PM +0200, Pali Rohár wrote:
On Monday 13 September 2021 12:42:42 Wolfgang Denk wrote:
Dear Pali Rohár,
In message 20210910204653.3066-1-pali@kernel.org you wrote:
Now when command loady can be aborted / cancelled by CTRL+C, change wait timeout for initial packet to infinite. This would allow user to not be hurry when locating file which want to send. Commands loadb and loads already waits infinitely too.
I'm not sure if this is a good idea.
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...
This is a change to the user interface that is not really necessary, so I recommend NOT to change the behaviour here, especially as it does not hurt.
Well... there is an issue if you do not start file transfer in the timeout which current 'loady' command expects.
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
So, when does this happen? It's been a long long time since I used minicom, but I know in screen you can do a filter to trigger the transfer, ie: :exec !! /home/trini/bin/load-boot-xymodem.sh is one of the things in my notes and little script is just to sx SPL and then sx --ymodem U-Boot itself. I know tmux is the preferred tool of power users these days but I assume it can do similar.