[PATCH] tools: kwboot: Check if baudrate value is supported before sending image
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;
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
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
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.
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
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
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.
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
participants (4)
-
Marek Behún -
Pali Rohár -
Stefan Roese -
Tony Dinh