On Friday 06 August 2021 18:23:49 Heinrich Schuchardt wrote:
> On 8/6/21 6:07 PM, Pali Rohár wrote:
> > When k_recv() returns zero it indicates that kermit transfer was aborted.
> > Function do_load_serial_bin() (caller of load_serial_bin()) interprets
> > value ~0 as aborted transfer, so properly propagates information about
> > aborted transfer from k_recv() to do_load_serial_bin().
> >
> > Signed-off-by: Pali Rohár <p...@kernel.org>
> > ---
> > cmd/load.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/cmd/load.c b/cmd/load.c
> > index 462340ad2cde..249ebd4ae078 100644
> > --- a/cmd/load.c
> > +++ b/cmd/load.c
> > @@ -551,6 +551,9 @@ static ulong load_serial_bin(ulong offset)
> > udelay(1000);
> > }
> >
> > + if (size == 0)
> > + return ~0; /* Download aborted */
> > +
>
> I cannot see where k_recv() sets the return value to 0 if the download
> is interrupted after transferring the first packages.
I must admit that I have not decoded whole kermit protocol. But by
testing show that ETX (CTRL+C) is transferred when I abort kermit
upload. And this ETX is handled in switch(getchar()) where is return 0;
and also after sending more kermit packets (not only at beginning).
> So isn't some logic in k_recv() missing to identify an abort?
This is a good question. I would guess that "yes". But to answer it I
need to fully decode kermit protocol...
But at least at this one place it really returns zero on aborted file
transfer.
> Best regards
>
> Heinrich
>
> > flush_cache(offset, size);
> >
> > printf("## Total Size = 0x%08x = %d Bytes\n", size, size);
> >
