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

[Pali Rohár]

On Monday 13 September 2021 14:12:54 Wolfgang Denk wrote:
> 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.

Wow, I did not know that it is such old.

> 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.

There is also gkermit tool which do not implement interactive session,
only file transfer itself. And it is present in more linux distributions
so is quite popular...

> 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).

Timeout is not too slow, but sometimes user is (when is interrupted by
other things during selecting file). And then it is not obvious why
sx/sb command is failing... compared to transfer via gkermit which do
not have this "problem".

> > 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.

Good point! env with timeout (or easier would be retry count?) seems
like a ideal solution how to "define" behavior without changing default
one. And e.g. negative value can mean infinite to support all possible
combinations.

> 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.