[PATCH] tools: kwboot: Check if baudrate value is supported before sending image

[PATCH] tools: kwboot: Check if baudrate value is supported before sending image

[Pali Rohár]

Call kwboot_open_tty() which baudrate value which was specified at the
command line by option -B. This function returns error if baudrate is not
supported by selected tty device.

Initial baudrate for image transfer is always 115200, so call
kwboot_tty_change_baudrate() with value 115200 immediately after
kwboot_open_tty() if baudrate specified by option -B is different than
115200.

This help user to see error message about unsupported baudrate value by
local tty device immediately after starting kwboot.

Before this change, kwboot sent kwbimage header (at 115200 Bd) and then
validated that selected baudrate if is supported by tty device. It consumed
too much time (need to send kwbimage again and again) until some supported
baudrate by local tty device was guessed.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index f975c4a6c6ca..d9498af8fc02 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2137,12 +2137,24 @@ main(int argc, char **argv)
 	if (optind != argc)
 		goto usage;
 
-	tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
+	tty = kwboot_open_tty(ttypath, baudrate);
 	if (tty < 0) {
 		perror(ttypath);
 		goto out;
 	}
 
+	/*
+	 * initial baudrate for image transfer is always 115200,
+	 * change to different baudrate is done after sending header
+	 */
+	if (imgpath && baudrate != 115200) {
+		rc = kwboot_tty_change_baudrate(tty, 115200);
+		if (rc) {
+			perror(ttypath);
+			goto out;
+		}
+	}
+
 	if (baudrate == 115200)
 		/* do not change baudrate during Xmodem to the same value */
 		baudrate = 0;
-- 
2.20.1

Re: [PATCH] tools: kwboot: Check if baudrate value is supported before sending image

[Marek Behún]

On Sun,  6 Mar 2022 13:39:07 +0100
Pali Rohár <pali@kernel.org> wrote:

> Call kwboot_open_tty() which baudrate value which was specified at the
                         with
> command line by option -B. This function returns error if baudrate is not
> supported by selected tty device.
> 
> Initial baudrate for image transfer is always 115200, so call
> kwboot_tty_change_baudrate() with value 115200 immediately after
> kwboot_open_tty() if baudrate specified by option -B is different than
> 115200.
> 
> This help user to see error message about unsupported baudrate value by
> local tty device immediately after starting kwboot.
This makes kwboot fail immediately, informing that baudrate is
unsupported, instead of failing only after the first part of image is
already sent.

> 
> Before this change, kwboot sent kwbimage header (at 115200 Bd) and then
> validated that selected baudrate if is supported by tty device. It consumed
> too much time (need to send kwbimage again and again) until some supported
> baudrate by local tty device was guessed.
This last paragraph can be dropped. If you want to keep it, please
change "Before this change" to "Until now"
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  tools/kwboot.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index f975c4a6c6ca..d9498af8fc02 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -2137,12 +2137,24 @@ main(int argc, char **argv)
>  	if (optind != argc)
>  		goto usage;
>  
> -	tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
> +	tty = kwboot_open_tty(ttypath, baudrate);
>  	if (tty < 0) {
>  		perror(ttypath);
>  		goto out;
>  	}
>  
> +	/*
> +	 * initial baudrate for image transfer is always 115200,
> +	 * change to different baudrate is done after sending header
*the change to different baudrate is done only after the header is sent
> +	 */
> +	if (imgpath && baudrate != 115200) {
> +		rc = kwboot_tty_change_baudrate(tty, 115200);
> +		if (rc) {
> +			perror(ttypath);
> +			goto out;
> +		}
> +	}
> +
>  	if (baudrate == 115200)
>  		/* do not change baudrate during Xmodem to the same value */
>  		baudrate = 0;

Marek

Re: [PATCH] tools: kwboot: Check if baudrate value is supported before sending image

[Tony Dinh]

Hi Pali,

I have an observation, which is not related to this patch. But about
the kwboot options changes in general, I hope it is OK to mention it
here.

Before the changes you've made to solve the problem with the -b
option, I can do this:

kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb

But now, the -b option can not be used after the tty device name. All
options must appear before the tty device.

Is this the actual intention? it did break some of my existing
aliases/scripts (It is not a big deal to retrofit them). Just want to
make sure I understand the reason to make the tty device a positional
argument for kwboot.

Thanks,
Tony

On Sun, Mar 6, 2022 at 4:39 AM Pali Rohár <pali@kernel.org> wrote:
>
> Call kwboot_open_tty() which baudrate value which was specified at the
> command line by option -B. This function returns error if baudrate is not
> supported by selected tty device.
>
> Initial baudrate for image transfer is always 115200, so call
> kwboot_tty_change_baudrate() with value 115200 immediately after
> kwboot_open_tty() if baudrate specified by option -B is different than
> 115200.
>
> This help user to see error message about unsupported baudrate value by
> local tty device immediately after starting kwboot.
>
> Before this change, kwboot sent kwbimage header (at 115200 Bd) and then
> validated that selected baudrate if is supported by tty device. It consumed
> too much time (need to send kwbimage again and again) until some supported
> baudrate by local tty device was guessed.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  tools/kwboot.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/tools/kwboot.c b/tools/kwboot.c
> index f975c4a6c6ca..d9498af8fc02 100644
> --- a/tools/kwboot.c
> +++ b/tools/kwboot.c
> @@ -2137,12 +2137,24 @@ main(int argc, char **argv)
>         if (optind != argc)
>                 goto usage;
>
> -       tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
> +       tty = kwboot_open_tty(ttypath, baudrate);
>         if (tty < 0) {
>                 perror(ttypath);
>                 goto out;
>         }
>
> +       /*
> +        * initial baudrate for image transfer is always 115200,
> +        * change to different baudrate is done after sending header
> +        */
> +       if (imgpath && baudrate != 115200) {
> +               rc = kwboot_tty_change_baudrate(tty, 115200);
> +               if (rc) {
> +                       perror(ttypath);
> +                       goto out;
> +               }
> +       }
> +
>         if (baudrate == 115200)
>                 /* do not change baudrate during Xmodem to the same value */
>                 baudrate = 0;
> --
> 2.20.1
>

kwboot - positional tty argument

[Pali Rohár]

Hello!

On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:
> Hi Pali,
> 
> I have an observation, which is not related to this patch. But about
> the kwboot options changes in general, I hope it is OK to mention it
> here.
> 
> Before the changes you've made to solve the problem with the -b
> option, I can do this:
> 
> kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb

Interesting... I did not know that this kind of setup worked. It was not
documented neither in usage nor in manpage. Normally in applications and
scripts, all option arguments are before non-option (positional)
argument.

> But now, the -b option can not be used after the tty device name. All
> options must appear before the tty device.
> 
> Is this the actual intention? it did break some of my existing
> aliases/scripts (It is not a big deal to retrofit them). Just want to
> make sure I understand the reason to make the tty device a positional
> argument for kwboot.
> 
> Thanks,
> Tony

Marek, Stefan, do you want to support above (old) handling of positional
tty device argument to be present in the middle of option arguments?

I think I can develop some "hack" patch for argv[] processing to support
this operation. But my question is, if this is something which we want
to officially support. Because if not, it is better to have separate
option arguments and positional arguments like in any other application.

Re: kwboot - positional tty argument

[Stefan Roese]

On 3/7/22 12:40, Pali Rohár wrote:
> Hello!
> 
> On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:
>> Hi Pali,
>>
>> I have an observation, which is not related to this patch. But about
>> the kwboot options changes in general, I hope it is OK to mention it
>> here.
>>
>> Before the changes you've made to solve the problem with the -b
>> option, I can do this:
>>
>> kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb
> 
> Interesting... I did not know that this kind of setup worked. It was not
> documented neither in usage nor in manpage. Normally in applications and
> scripts, all option arguments are before non-option (positional)
> argument.
> 
>> But now, the -b option can not be used after the tty device name. All
>> options must appear before the tty device.
>>
>> Is this the actual intention? it did break some of my existing
>> aliases/scripts (It is not a big deal to retrofit them). Just want to
>> make sure I understand the reason to make the tty device a positional
>> argument for kwboot.
>>
>> Thanks,
>> Tony
> 
> Marek, Stefan, do you want to support above (old) handling of positional
> tty device argument to be present in the middle of option arguments?

I personally don't...

> I think I can develop some "hack" patch for argv[] processing to support
> this operation. But my question is, if this is something which we want
> to officially support. Because if not, it is better to have separate
> option arguments and positional arguments like in any other application.

...

The only case I can think of, is scripts that use the "incorrect" format
and might fail now. I don't have any such scripts and I would not object
to breaking this backward compatibility. Tony, what's your thinking on
this? Marek?

Thanks,
Stefan

Re: kwboot - positional tty argument

[Marek Behún]

On Mon, 7 Mar 2022 15:39:33 +0100
Stefan Roese <sr@denx.de> wrote:

> On 3/7/22 12:40, Pali Rohár wrote:
> > Hello!
> > 
> > On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:  
> >> Hi Pali,
> >>
> >> I have an observation, which is not related to this patch. But about
> >> the kwboot options changes in general, I hope it is OK to mention it
> >> here.
> >>
> >> Before the changes you've made to solve the problem with the -b
> >> option, I can do this:
> >>
> >> kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb  
> > 
> > Interesting... I did not know that this kind of setup worked. It was not
> > documented neither in usage nor in manpage. Normally in applications and
> > scripts, all option arguments are before non-option (positional)
> > argument.
> >   
> >> But now, the -b option can not be used after the tty device name. All
> >> options must appear before the tty device.
> >>
> >> Is this the actual intention? it did break some of my existing
> >> aliases/scripts (It is not a big deal to retrofit them). Just want to
> >> make sure I understand the reason to make the tty device a positional
> >> argument for kwboot.
> >>
> >> Thanks,
> >> Tony  
> > 
> > Marek, Stefan, do you want to support above (old) handling of positional
> > tty device argument to be present in the middle of option arguments?  
> 
> I personally don't...
> 
> > I think I can develop some "hack" patch for argv[] processing to support
> > this operation. But my question is, if this is something which we want
> > to officially support. Because if not, it is better to have separate
> > option arguments and positional arguments like in any other application.  
> 
> ...
> 
> The only case I can think of, is scripts that use the "incorrect" format
> and might fail now. I don't have any such scripts and I would not object
> to breaking this backward compatibility. Tony, what's your thinking on
> this? Marek?

I don't care. I only care whether I can use the -t flag after
everything else, and I think this still works.

Marek

Re: kwboot - positional tty argument

[Pali Rohár]

On Monday 07 March 2022 17:45:53 Marek Behún wrote:
> On Mon, 7 Mar 2022 15:39:33 +0100
> Stefan Roese <sr@denx.de> wrote:
> 
> > On 3/7/22 12:40, Pali Rohár wrote:
> > > Hello!
> > > 
> > > On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:  
> > >> Hi Pali,
> > >>
> > >> I have an observation, which is not related to this patch. But about
> > >> the kwboot options changes in general, I hope it is OK to mention it
> > >> here.
> > >>
> > >> Before the changes you've made to solve the problem with the -b
> > >> option, I can do this:
> > >>
> > >> kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb  
> > > 
> > > Interesting... I did not know that this kind of setup worked. It was not
> > > documented neither in usage nor in manpage. Normally in applications and
> > > scripts, all option arguments are before non-option (positional)
> > > argument.
> > >   
> > >> But now, the -b option can not be used after the tty device name. All
> > >> options must appear before the tty device.
> > >>
> > >> Is this the actual intention? it did break some of my existing
> > >> aliases/scripts (It is not a big deal to retrofit them). Just want to
> > >> make sure I understand the reason to make the tty device a positional
> > >> argument for kwboot.
> > >>
> > >> Thanks,
> > >> Tony  
> > > 
> > > Marek, Stefan, do you want to support above (old) handling of positional
> > > tty device argument to be present in the middle of option arguments?  
> > 
> > I personally don't...
> > 
> > > I think I can develop some "hack" patch for argv[] processing to support
> > > this operation. But my question is, if this is something which we want
> > > to officially support. Because if not, it is better to have separate
> > > option arguments and positional arguments like in any other application.  
> > 
> > ...
> > 
> > The only case I can think of, is scripts that use the "incorrect" format
> > and might fail now. I don't have any such scripts and I would not object
> > to breaking this backward compatibility. Tony, what's your thinking on
> > this? Marek?
> 
> I don't care. I only care whether I can use the -t flag after
> everything else, and I think this still works.
> 
> Marek

I figure out that mixing of positional arguments and options is by
default supported by getopt API and seems that it is used (in other
applications).

Anyway, it looks like that other usage of kwboot is broken too, so I
will send a patch which fix processing -b option with optional argument
again, including mixing of positional arguments and options, like it was
in older kwboot version.

Re: kwboot - positional tty argument

[Tony Dinh]

Hi Stefan,

On Mon, Mar 7, 2022 at 6:39 AM Stefan Roese <sr@denx.de> wrote:
>
> On 3/7/22 12:40, Pali Rohár wrote:
> > Hello!
> >
> > On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:
> >> Hi Pali,
> >>
> >> I have an observation, which is not related to this patch. But about
> >> the kwboot options changes in general, I hope it is OK to mention it
> >> here.
> >>
> >> Before the changes you've made to solve the problem with the -b
> >> option, I can do this:
> >>
> >> kwboot -t  -B 115200 /dev/ttyUSB0 -b uboot.kwb
> >
> > Interesting... I did not know that this kind of setup worked. It was not
> > documented neither in usage nor in manpage. Normally in applications and
> > scripts, all option arguments are before non-option (positional)
> > argument.
> >
> >> But now, the -b option can not be used after the tty device name. All
> >> options must appear before the tty device.
> >>
> >> Is this the actual intention? it did break some of my existing
> >> aliases/scripts (It is not a big deal to retrofit them). Just want to
> >> make sure I understand the reason to make the tty device a positional
> >> argument for kwboot.
> >>
> >> Thanks,
> >> Tony
> >
> > Marek, Stefan, do you want to support above (old) handling of positional
> > tty device argument to be present in the middle of option arguments?
>
> I personally don't...
>
> > I think I can develop some "hack" patch for argv[] processing to support
> > this operation. But my question is, if this is something which we want
> > to officially support. Because if not, it is better to have separate
> > option arguments and positional arguments like in any other application.
>
> ...
>
> The only case I can think of, is scripts that use the "incorrect" format
> and might fail now. I don't have any such scripts and I would not object
> to breaking this backward compatibility. Tony, what's your thinking on
> this? Marek?

I've just tested Pali's latest patch and it is working like it was before.

Actually, I'm OK either way. But I do think it is kind of handy if we
can mix the order.

Thanks,
Tony


>
> Thanks,
> Stefan