[PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet

[Wolfgang Denk]

Dear Pali Rohár,

In message <20210913110806.27hc36n6gmhw6uq4 at 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:
>
> 1) open terminal and write 'loady' into U-Boot console
> 2) disconnect terminal
> 3) start y-modem software
> 4) choose file to transmit
> 5) 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

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I can call spirits from the vasty deep."
"Why so can I, or so can any man; but will they come when you do call
for them?"          - Shakespeare, 1 King Henry IV, Act III, Scene I.