| Message ID | 20210720132940.1171011-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | lib: Add support for a decimal 0m prefix for numbers | expand |
On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > U-Boot mostly uses hex for value input, largely because addresses are much > easier to understand in hex. > > But in some cases a hex value is requested, but it is more convenient to > provide a decimal value. This may be because the value comes from another > source, where its base cannot be controlled. > > This series adds support for a 0m prefix to indicate a decimal number. The I _really_ don't want to invent something here. When the setexpr thread came up before I went and did a little digging. Per https://en.wikipedia.org/wiki/Radix the general way to express a number is (x)y where x is the number and y is the base (and y is in base10, and also a subscript). I thought it was a bit cumbersome for general use and didn't bring it up at the time. If we're going to add some global way to always say a number is decimal, and I'm not sure I think that's a good idea even (I kind of think it might be better on a case by case basis to maybe tweak some prints so that for example "ls mmc 0:10" tells the user it's accessing partition 16 would lead to a quick "oh that's hex, #$%@!"), I think it should follow the radix notation, or if not, some other well known example.
On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > U-Boot mostly uses hex for value input, largely because addresses are much > easier to understand in hex. > > But in some cases a hex value is requested, but it is more convenient to > provide a decimal value. This may be because the value comes from another > source, where its base cannot be controlled. > > This series adds support for a 0m prefix to indicate a decimal number. The > letter 'm' is chosen because: > > - 'm' as in deciMal > - cannot use a-f since they indicate a hex value (e.g. 0d would be > ambiguous) > - 'l' is harder to read since 1 and l look similar (0l123) > - 't' (as in ten) seems a bit obscure NetBSD ddb(4) uses 0t as a prefix for base 10. Jonathan
On Tue, Jul 20, 2021 at 10:00:13AM -0500, Jonathan A. Kollasch wrote: > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > U-Boot mostly uses hex for value input, largely because addresses are much > > easier to understand in hex. > > > > But in some cases a hex value is requested, but it is more convenient to > > provide a decimal value. This may be because the value comes from another > > source, where its base cannot be controlled. > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > letter 'm' is chosen because: > > > > - 'm' as in deciMal > > - cannot use a-f since they indicate a hex value (e.g. 0d would be > > ambiguous) > > - 'l' is harder to read since 1 and l look similar (0l123) > > - 't' (as in ten) seems a bit obscure > > NetBSD ddb(4) uses 0t as a prefix for base 10. Oh no... And per https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/n--set-number-base- there's examples of '0t' being decimal and '0n' being decimal. http://web.mit.edu/~jik/sipbsrc/sun4c_53/lsof/lsof_3.61/00FAQ uses 0t the same way NetBSD ddb(4) does. https://docs.oracle.com/cd/E19683-01/806-6545/api-21/index.html is also using 0t for decimal.
Hi Tom, On Tue, 20 Jul 2021 at 08:22, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > > U-Boot mostly uses hex for value input, largely because addresses are much > > easier to understand in hex. > > > > But in some cases a hex value is requested, but it is more convenient to > > provide a decimal value. This may be because the value comes from another > > source, where its base cannot be controlled. > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > I _really_ don't want to invent something here. When the setexpr thread > came up before I went and did a little digging. Per > https://en.wikipedia.org/wiki/Radix the general way to express a number > is (x)y where x is the number and y is the base (and y is in base10, and > also a subscript). I thought it was a bit cumbersome for general use > and didn't bring it up at the time. Well I don't want to invent something either...but what to do? So for example (10)123 would mean decimal 123? I don't know how we would parse brackets separately from expressions though. > > If we're going to add some global way to always say a number is decimal, > and I'm not sure I think that's a good idea even (I kind of think it > might be better on a case by case basis to maybe tweak some prints so > that for example "ls mmc 0:10" tells the user it's accessing partition > 16 would lead to a quick "oh that's hex, #$%@!"), I think it should > follow the radix notation, or if not, some other well known example. Can you give examples for what you are thinking for radix notation? BTW, quite a bit of the series is a clean-up, so can be reviewed separately. Regards, Simon
On Tue, Jul 20, 2021 at 09:57:55AM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 20 Jul 2021 at 08:22, Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > > > > U-Boot mostly uses hex for value input, largely because addresses are much > > > easier to understand in hex. > > > > > > But in some cases a hex value is requested, but it is more convenient to > > > provide a decimal value. This may be because the value comes from another > > > source, where its base cannot be controlled. > > > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > > > I _really_ don't want to invent something here. When the setexpr thread > > came up before I went and did a little digging. Per > > https://en.wikipedia.org/wiki/Radix the general way to express a number > > is (x)y where x is the number and y is the base (and y is in base10, and > > also a subscript). I thought it was a bit cumbersome for general use > > and didn't bring it up at the time. > > Well I don't want to invent something either...but what to do? > > So for example (10)123 would mean decimal 123? I don't know how we > would parse brackets separately from expressions though. (123)10 would be "123" in decimal. Which is indeed a mouthful. But it would also be generic and (123)16 would be 0x123. So the parsing shouldn't be too hard, for most commands. But then yes, expressions become quite hard. > > If we're going to add some global way to always say a number is decimal, > > and I'm not sure I think that's a good idea even (I kind of think it > > might be better on a case by case basis to maybe tweak some prints so > > that for example "ls mmc 0:10" tells the user it's accessing partition > > 16 would lead to a quick "oh that's hex, #$%@!"), I think it should > > follow the radix notation, or if not, some other well known example. > > Can you give examples for what you are thinking for radix notation? Well, since we don't have subscript in shell, '(number)base' would how it would be. Which I'm not convinced is better than making it clear to users that almost everything is hex input, including a few places that might surprise you such as partition numbers. > BTW, quite a bit of the series is a clean-up, so can be reviewed separately. OK.
On Tue, Jul 20, 2021 at 12:05:47PM -0400, Tom Rini wrote: > On Tue, Jul 20, 2021 at 09:57:55AM -0600, Simon Glass wrote: [..] > > Can you give examples for what you are thinking for radix notation? > > Well, since we don't have subscript in shell, '(number)base' would how > it would be. Which I'm not convinced is better than making it clear to > users that almost everything is hex input, including a few places that > might surprise you such as partition numbers. [FWIW/.02$] As a user, I would be happier to follow a project-wide convention that any decimal command line input is treated as HEX or DEC, rather than being forced to surround any number by its base in the shell. -- Best regards, Eugeniu Rosca
Hi Tom. On Tue, 20 Jul 2021 at 10:05, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Jul 20, 2021 at 09:57:55AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 20 Jul 2021 at 08:22, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > > > > > > U-Boot mostly uses hex for value input, largely because addresses are much > > > > easier to understand in hex. > > > > > > > > But in some cases a hex value is requested, but it is more convenient to > > > > provide a decimal value. This may be because the value comes from another > > > > source, where its base cannot be controlled. > > > > > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > > > > > I _really_ don't want to invent something here. When the setexpr thread > > > came up before I went and did a little digging. Per > > > https://en.wikipedia.org/wiki/Radix the general way to express a number > > > is (x)y where x is the number and y is the base (and y is in base10, and > > > also a subscript). I thought it was a bit cumbersome for general use > > > and didn't bring it up at the time. > > > > Well I don't want to invent something either...but what to do? > > > > So for example (10)123 would mean decimal 123? I don't know how we > > would parse brackets separately from expressions though. > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > would also be generic and (123)16 would be 0x123. So the parsing > shouldn't be too hard, for most commands. But then yes, expressions > become quite hard. > > > > If we're going to add some global way to always say a number is decimal, > > > and I'm not sure I think that's a good idea even (I kind of think it > > > might be better on a case by case basis to maybe tweak some prints so > > > that for example "ls mmc 0:10" tells the user it's accessing partition > > > 16 would lead to a quick "oh that's hex, #$%@!"), I think it should > > > follow the radix notation, or if not, some other well known example. > > > > Can you give examples for what you are thinking for radix notation? > > Well, since we don't have subscript in shell, '(number)base' would how > it would be. Which I'm not convinced is better than making it clear to > users that almost everything is hex input, including a few places that > might surprise you such as partition numbers. After a bit of thought and digging, I think that is a mathematical thing and confusing/unworkable on the command line. Should we consider 0t for decimal? > > > BTW, quite a bit of the series is a clean-up, so can be reviewed separately. > > OK. > > -- > Tom Regards, Simon
On Tue, Jul 20, 2021 at 12:33:14PM -0600, Simon Glass wrote: > Hi Tom. > > On Tue, 20 Jul 2021 at 10:05, Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Jul 20, 2021 at 09:57:55AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 20 Jul 2021 at 08:22, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > > > > > > > > U-Boot mostly uses hex for value input, largely because addresses are much > > > > > easier to understand in hex. > > > > > > > > > > But in some cases a hex value is requested, but it is more convenient to > > > > > provide a decimal value. This may be because the value comes from another > > > > > source, where its base cannot be controlled. > > > > > > > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > > > > > > > I _really_ don't want to invent something here. When the setexpr thread > > > > came up before I went and did a little digging. Per > > > > https://en.wikipedia.org/wiki/Radix the general way to express a number > > > > is (x)y where x is the number and y is the base (and y is in base10, and > > > > also a subscript). I thought it was a bit cumbersome for general use > > > > and didn't bring it up at the time. > > > > > > Well I don't want to invent something either...but what to do? > > > > > > So for example (10)123 would mean decimal 123? I don't know how we > > > would parse brackets separately from expressions though. > > > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > > would also be generic and (123)16 would be 0x123. So the parsing > > shouldn't be too hard, for most commands. But then yes, expressions > > become quite hard. > > > > > > If we're going to add some global way to always say a number is decimal, > > > > and I'm not sure I think that's a good idea even (I kind of think it > > > > might be better on a case by case basis to maybe tweak some prints so > > > > that for example "ls mmc 0:10" tells the user it's accessing partition > > > > 16 would lead to a quick "oh that's hex, #$%@!"), I think it should > > > > follow the radix notation, or if not, some other well known example. > > > > > > Can you give examples for what you are thinking for radix notation? > > > > Well, since we don't have subscript in shell, '(number)base' would how > > it would be. Which I'm not convinced is better than making it clear to > > users that almost everything is hex input, including a few places that > > might surprise you such as partition numbers. > > After a bit of thought and digging, I think that is a mathematical > thing and confusing/unworkable on the command line. I agree. > Should we consider 0t for decimal? My biggest concern is that when I search for "0t prefix" the first relevant answers are the MS links where 0t is for ocTal, and not the other examples where it's decimal (base Ten, I assume).
Dear Simon, In message <20210720132940.1171011-1-sjg@chromium.org> you wrote: > U-Boot mostly uses hex for value input, largely because addresses are much > easier to understand in hex. > > But in some cases a hex value is requested, but it is more convenient to > provide a decimal value. This may be because the value comes from another > source, where its base cannot be controlled. > > This series adds support for a 0m prefix to indicate a decimal number. The > letter 'm' is chosen because: What is the impact of this change on the U-Boot size for typical configurations? Best regards, Wolfgang Denk
Hi, In message <20210720160547.GM9379@bill-the-cat> you wrote: > > > So for example (10)123 would mean decimal 123? I don't know how we > > would parse brackets separately from expressions though. > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > would also be generic and (123)16 would be 0x123. So the parsing > shouldn't be too hard, for most commands. But then yes, expressions > become quite hard. Come on, guys, be serious! This is a boot loader. Size matters. Do we _really_ need all this, and is it worth the code size? Simon's patches include some cleanup, which probably even reduces the size, so good. But whether it's 0m123 or 0t123 or 0!123 or ... is pretty much irrelevant - chose one symbol, use it, and be done with that. Best regards, Wolfgang Denk
Hi Tom, On Tue, 20 Jul 2021 at 13:28, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Jul 20, 2021 at 12:33:14PM -0600, Simon Glass wrote: > > Hi Tom. > > > > On Tue, 20 Jul 2021 at 10:05, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Jul 20, 2021 at 09:57:55AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 20 Jul 2021 at 08:22, Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Jul 20, 2021 at 07:29:24AM -0600, Simon Glass wrote: > > > > > > > > > > > U-Boot mostly uses hex for value input, largely because addresses are much > > > > > > easier to understand in hex. > > > > > > > > > > > > But in some cases a hex value is requested, but it is more convenient to > > > > > > provide a decimal value. This may be because the value comes from another > > > > > > source, where its base cannot be controlled. > > > > > > > > > > > > This series adds support for a 0m prefix to indicate a decimal number. The > > > > > > > > > > I _really_ don't want to invent something here. When the setexpr thread > > > > > came up before I went and did a little digging. Per > > > > > https://en.wikipedia.org/wiki/Radix the general way to express a number > > > > > is (x)y where x is the number and y is the base (and y is in base10, and > > > > > also a subscript). I thought it was a bit cumbersome for general use > > > > > and didn't bring it up at the time. > > > > > > > > Well I don't want to invent something either...but what to do? > > > > > > > > So for example (10)123 would mean decimal 123? I don't know how we > > > > would parse brackets separately from expressions though. > > > > > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > > > would also be generic and (123)16 would be 0x123. So the parsing > > > shouldn't be too hard, for most commands. But then yes, expressions > > > become quite hard. > > > > > > > > If we're going to add some global way to always say a number is decimal, > > > > > and I'm not sure I think that's a good idea even (I kind of think it > > > > > might be better on a case by case basis to maybe tweak some prints so > > > > > that for example "ls mmc 0:10" tells the user it's accessing partition > > > > > 16 would lead to a quick "oh that's hex, #$%@!"), I think it should > > > > > follow the radix notation, or if not, some other well known example. > > > > > > > > Can you give examples for what you are thinking for radix notation? > > > > > > Well, since we don't have subscript in shell, '(number)base' would how > > > it would be. Which I'm not convinced is better than making it clear to > > > users that almost everything is hex input, including a few places that > > > might surprise you such as partition numbers. > > > > After a bit of thought and digging, I think that is a mathematical > > thing and confusing/unworkable on the command line. > > I agree. > > > Should we consider 0t for decimal? > > My biggest concern is that when I search for "0t prefix" the first > relevant answers are the MS links where 0t is for ocTal, and not the > other examples where it's decimal (base Ten, I assume). Hmm, so make 0n would make more sense? I know it is a new thing but I think it would be very useful... Regards, Simon
Hi Wolfgang, On Wed, 21 Jul 2021 at 01:53, Wolfgang Denk <wd@denx.de> wrote: > > Hi, > > In message <20210720160547.GM9379@bill-the-cat> you wrote: > > > > > So for example (10)123 would mean decimal 123? I don't know how we > > > would parse brackets separately from expressions though. > > > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > > would also be generic and (123)16 would be 0x123. So the parsing > > shouldn't be too hard, for most commands. But then yes, expressions > > become quite hard. > > Come on, guys, be serious! This is a boot loader. Size matters. > > Do we _really_ need all this, and is it worth the code size? > > Simon's patches include some cleanup, which probably even reduces > the size, so good. It reduces U-Boot proper by about 400-700 bytes but not much effect on SPL: 16: RFC: Change simple_strtoul() et al to default to hex arm: evb-ast2500 brppt1_spi brsmarc1 aarch64: (for 300/301 boards) all -754.8 bss +0.0 spl/u-boot-spl:all -9.9 spl/u-boot-spl:text -9.9 text -754.8 arc: (for 10/11 boards) all -242.0 text -242.0 arm: (for 625/627 boards) all -468.7 bss +0.8 data +0.0 rodata +0.0 spl/u-boot-spl:all -1.5 spl/u-boot-spl:bss -0.1 spl/u-boot-spl:text -1.4 text -469.5 m68k: (for 18/18 boards) all -499.1 data +11.8 text -510.9 microblaze: (for 1/1 boards) all -392.0 bss +44.0 data +4.0 rodata -4.0 text -436.0 mips: (for 43/43 boards) all -457.5 bss +1.1 text -458.6 nds32: (for 2/2 boards) all -206.0 text -206.0 nios2: (for 2/2 boards) all -480.0 text -480.0 powerpc: (for 40/98 boards) all -708.4 text -708.4 > > But whether it's 0m123 or 0t123 or 0!123 or ... is pretty much > irrelevant - chose one symbol, use it, and be done with that. Regards, Simon
Hi, On Wed, 21 Jul 2021 at 08:46, Simon Glass <sjg@chromium.org> wrote: > > Hi Wolfgang, > > On Wed, 21 Jul 2021 at 01:53, Wolfgang Denk <wd@denx.de> wrote: > > > > Hi, > > > > In message <20210720160547.GM9379@bill-the-cat> you wrote: > > > > > > > So for example (10)123 would mean decimal 123? I don't know how we > > > > would parse brackets separately from expressions though. > > > > > > (123)10 would be "123" in decimal. Which is indeed a mouthful. But it > > > would also be generic and (123)16 would be 0x123. So the parsing > > > shouldn't be too hard, for most commands. But then yes, expressions > > > become quite hard. > > > > Come on, guys, be serious! This is a boot loader. Size matters. > > > > Do we _really_ need all this, and is it worth the code size? > > > > Simon's patches include some cleanup, which probably even reduces > > the size, so good. > > It reduces U-Boot proper by about 400-700 bytes but not much effect on SPL: > > 16: RFC: Change simple_strtoul() et al to default to hex > arm: evb-ast2500 brppt1_spi brsmarc1 > aarch64: (for 300/301 boards) all -754.8 bss +0.0 > spl/u-boot-spl:all -9.9 spl/u-boot-spl:text -9.9 text -754.8 > arc: (for 10/11 boards) all -242.0 text -242.0 > arm: (for 625/627 boards) all -468.7 bss +0.8 data +0.0 rodata > +0.0 spl/u-boot-spl:all -1.5 spl/u-boot-spl:bss -0.1 > spl/u-boot-spl:text -1.4 text -469.5 > m68k: (for 18/18 boards) all -499.1 data +11.8 text -510.9 > microblaze: (for 1/1 boards) all -392.0 bss +44.0 data +4.0 rodata > -4.0 text -436.0 > mips: (for 43/43 boards) all -457.5 bss +1.1 text -458.6 > nds32: (for 2/2 boards) all -206.0 text -206.0 > nios2: (for 2/2 boards) all -480.0 text -480.0 > powerpc: (for 40/98 boards) all -708.4 text -708.4 > > > > > But whether it's 0m123 or 0t123 or 0!123 or ... is pretty much > > irrelevant - chose one symbol, use it, and be done with that. Given Roland's setexpr thing and the discussion here I think I will resend the series with 0n for decimal and drop the binary/octal for now. It is a tiny size increment and easy to add later if useful. Regards, Simon
U-Boot mostly uses hex for value input, largely because addresses are much easier to understand in hex. But in some cases a hex value is requested, but it is more convenient to provide a decimal value. This may be because the value comes from another source, where its base cannot be controlled. This series adds support for a 0m prefix to indicate a decimal number. The letter 'm' is chosen because: - 'm' as in deciMal - cannot use a-f since they indicate a hex value (e.g. 0d would be ambiguous) - 'l' is harder to read since 1 and l look similar (0l123) - 't' (as in ten) seems a bit obscure - 'n' (Number) is easier to read than 'm', but a bit vague as to meaning At present, base prefixes are only accepted when no specific base is provided to the simple_strtoul() function, i.e. base is 0. This is not very flexible, so this series updates the code to always allow a base prefix. So when decimal is requested, it is possible to provide 0x123 to get a hex value. A final patch is included for discussion only. This is intended to change the default to hex consistently through U-Boot, although it does not quite accomplish that. If this goal is desirable, then we should also consider: - dropping the base argument, since callers can now hextoul() and dectoul() when a specific base is requested - converting these calls (with base == 0) to hextoul() since that is what would mean Simon Glass (15): hash: Ensure verification hex pairs are terminated global: Convert simple_strtoul() with hex to hextoul() global: Convert simple_strtoul() with decimal to dectoul() lib: Comment the base parameter with simple_strtoul/l() lib: Drop unnecessary check for hex digit lib: Add tests for simple_strtoull() lib: Add octal tests for simple_strtoul/l() lib: Move common digit-parsing code into a function doc: Convert command-line info to rST doc: Add a note about number representation lib: Allow using 0x when a decimal value is requested lib: Support a decimal prefix 0m RFC: lib: Support a binary prefix 0y RFC: lib: Use 0o prefix for octal RFC: Change simple_strtoul() et al to default to hex README | 41 ------ arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 12 +- arch/arm/cpu/armv8/fsl-layerscape/soc.c | 2 +- arch/arm/lib/semihosting.c | 2 +- arch/arm/mach-imx/cmd_dek.c | 6 +- arch/arm/mach-imx/cmd_mfgprot.c | 4 +- arch/arm/mach-imx/cmd_nandbcb.c | 10 +- arch/arm/mach-imx/hab.c | 6 +- arch/arm/mach-imx/imx8/ahab.c | 2 +- arch/arm/mach-imx/imx8/snvs_security_sc.c | 56 ++++---- arch/arm/mach-imx/imx_bootaux.c | 2 +- arch/arm/mach-imx/mx6/mp.c | 2 +- arch/arm/mach-keystone/cmd_clock.c | 10 +- arch/arm/mach-keystone/cmd_mon.c | 8 +- arch/arm/mach-kirkwood/cpu.c | 2 +- arch/arm/mach-nexell/clock.c | 2 +- arch/arm/mach-snapdragon/misc.c | 2 +- arch/arm/mach-socfpga/misc.c | 2 +- arch/arm/mach-socfpga/vab.c | 4 +- arch/arm/mach-stm32mp/cmd_stm32key.c | 4 +- .../cmd_stm32prog/cmd_stm32prog.c | 6 +- .../mach-stm32mp/cmd_stm32prog/stm32prog.c | 2 +- arch/arm/mach-uniphier/board_late_init.c | 2 +- arch/arm/mach-zynqmp/mp.c | 2 +- arch/mips/mach-octeon/bootoctlinux.c | 5 +- arch/nds32/lib/bootm.c | 2 +- arch/nios2/lib/bootm.c | 2 +- arch/powerpc/cpu/mpc83xx/ecc.c | 18 +-- arch/powerpc/cpu/mpc85xx/mp.c | 2 +- arch/sh/lib/zimageboot.c | 5 +- arch/x86/lib/zimage.c | 14 +- board/Arcturus/ucp1020/ucp1020.c | 2 +- board/BuS/eb_cpu5282/eb_cpu5282.c | 10 +- board/Marvell/octeontx2/board.c | 2 +- board/amlogic/beelink-s922x/beelink-s922x.c | 2 +- board/amlogic/odroid-n2/odroid-n2.c | 2 +- board/amlogic/vim3/vim3.c | 2 +- board/atmel/common/board.c | 2 +- board/bluewater/gurnard/gurnard.c | 2 +- board/cavium/thunderx/atf.c | 32 ++--- board/compulab/common/eeprom.c | 2 +- board/compulab/common/omap3_display.c | 2 +- board/davinci/da8xxevm/da850evm.c | 2 +- board/esd/meesc/meesc.c | 2 +- board/freescale/common/cmd_esbc_validate.c | 2 +- board/freescale/common/fsl_validate.c | 2 +- board/freescale/common/pixis.c | 8 +- board/freescale/common/sys_eeprom.c | 6 +- board/freescale/lx2160a/eth_lx2160aqds.c | 2 +- board/freescale/lx2160a/eth_lx2162aqds.c | 2 +- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +- board/freescale/p2041rdb/cpld.c | 4 +- board/gateworks/gw_ventana/common.c | 2 +- board/gateworks/gw_ventana/gsc.c | 4 +- board/gateworks/gw_ventana/gw_ventana.c | 4 +- board/gateworks/venice/gsc.c | 2 +- board/gdsys/common/cmd_ioloop.c | 16 +-- board/gdsys/common/osd.c | 18 +-- board/gdsys/common/osd_cmd.c | 16 +-- board/keymile/common/common.c | 4 +- board/kontron/sl28/cmds.c | 2 +- board/menlo/m53menlo/m53menlo.c | 2 +- board/renesas/stout/cpld.c | 4 +- board/renesas/ulcb/cpld.c | 4 +- board/samsung/common/exynos5-dt.c | 2 +- board/samsung/odroid/odroid.c | 2 +- board/siemens/common/factoryset.c | 14 +- board/siemens/taurus/taurus.c | 5 +- .../unmatched/hifive-platform-i2c-eeprom.c | 8 +- board/synopsys/hsdk/env-lib.c | 4 +- board/ti/am64x/evm.c | 2 +- board/ti/j721e/evm.c | 2 +- board/toradex/common/tdx-cfg-block.c | 14 +- board/varisys/common/sys_eeprom.c | 6 +- .../work_92105/work_92105_display.c | 3 +- board/xilinx/common/fru.c | 4 +- board/xilinx/versal/cmds.c | 2 +- board/xilinx/zynq/cmds.c | 14 +- board/xilinx/zynqmp/cmds.c | 46 +++---- cmd/abootimg.c | 2 +- cmd/adtimg.c | 2 +- cmd/aes.c | 10 +- cmd/armflash.c | 2 +- cmd/avb.c | 26 ++-- cmd/axi.c | 18 +-- cmd/bedbug.c | 6 +- cmd/bind.c | 4 +- cmd/binop.c | 8 +- cmd/blk_common.c | 16 +-- cmd/blob.c | 8 +- cmd/bmp.c | 10 +- cmd/boot.c | 2 +- cmd/bootefi.c | 4 +- cmd/booti.c | 2 +- cmd/bootm.c | 4 +- cmd/bootstage.c | 4 +- cmd/bootz.c | 2 +- cmd/broadcom/nitro_image_load.c | 4 +- cmd/cbfs.c | 6 +- cmd/clk.c | 2 +- cmd/clone.c | 2 +- cmd/cramfs.c | 4 +- cmd/cros_ec.c | 8 +- cmd/demo.c | 4 +- cmd/disk.c | 2 +- cmd/efidebug.c | 14 +- cmd/elf.c | 4 +- cmd/exit.c | 2 +- cmd/fastboot.c | 4 +- cmd/fdt.c | 41 +++--- cmd/flash.c | 16 +-- cmd/fpga.c | 10 +- cmd/fpgad.c | 6 +- cmd/gpio.c | 4 +- cmd/gpt.c | 2 +- cmd/host.c | 6 +- cmd/i2c.c | 68 +++++----- cmd/ini.c | 8 +- cmd/io.c | 8 +- cmd/iotrace.c | 8 +- cmd/itest.c | 6 +- cmd/jffs2.c | 2 +- cmd/led.c | 2 +- cmd/legacy_led.c | 2 +- cmd/load.c | 16 +-- cmd/log.c | 4 +- cmd/lzmadec.c | 6 +- cmd/mbr.c | 2 +- cmd/md5sum.c | 14 +- cmd/mdio.c | 2 +- cmd/mem.c | 56 ++++---- cmd/mfsl.c | 14 +- cmd/mii.c | 8 +- cmd/misc.c | 6 +- cmd/mmc.c | 80 +++++------ cmd/mp.c | 2 +- cmd/mtd.c | 10 +- cmd/mvebu/bubt.c | 2 +- cmd/mvebu/comphy_rx_training.c | 4 +- cmd/nand.c | 20 +-- cmd/net.c | 6 +- cmd/nvedit.c | 12 +- cmd/nvedit_efi.c | 4 +- cmd/onenand.c | 8 +- cmd/optee_rpmb.c | 2 +- cmd/osd.c | 20 +-- cmd/pcap.c | 4 +- cmd/pci.c | 12 +- cmd/pstore.c | 16 +-- cmd/pwm.c | 10 +- cmd/pxe_utils.c | 4 +- cmd/qfw.c | 10 +- cmd/read.c | 10 +- cmd/reiser.c | 10 +- cmd/remoteproc.c | 10 +- cmd/rng.c | 2 +- cmd/rtc.c | 14 +- cmd/sata.c | 2 +- cmd/setexpr.c | 4 +- cmd/sf.c | 10 +- cmd/sleep.c | 2 +- cmd/smccc.c | 16 +-- cmd/sound.c | 4 +- cmd/source.c | 2 +- cmd/spi.c | 10 +- cmd/strings.c | 4 +- cmd/ti/ddr3.c | 10 +- cmd/ti/pd.c | 4 +- cmd/tlv_eeprom.c | 2 +- cmd/tpm-common.c | 4 +- cmd/trace.c | 4 +- cmd/tsi148.c | 10 +- cmd/ubi.c | 10 +- cmd/ubifs.c | 4 +- cmd/ufs.c | 2 +- cmd/universe.c | 12 +- cmd/unlz4.c | 6 +- cmd/unzip.c | 12 +- cmd/usb.c | 6 +- cmd/w1.c | 8 +- cmd/x86/mtrr.c | 6 +- cmd/ximg.c | 6 +- cmd/yaffs2.c | 10 +- cmd/zfs.c | 6 +- cmd/zip.c | 8 +- common/bedbug.c | 4 +- common/bootm_os.c | 5 +- common/fdt_support.c | 2 +- common/hash.c | 14 +- common/image-fdt.c | 6 +- common/image-fit.c | 2 +- common/image.c | 12 +- common/kallsyms.c | 2 +- common/lcd.c | 2 +- common/lcd_console.c | 4 +- common/splash.c | 4 +- common/splash_source.c | 2 +- common/update.c | 2 +- disk/part.c | 6 +- disk/part_amiga.c | 4 +- doc/usage/cmdline.rst | 103 +++++++++++++++ doc/usage/index.rst | 1 + drivers/dfu/dfu_mmc.c | 2 +- drivers/dfu/dfu_mtd.c | 6 +- drivers/dfu/dfu_nand.c | 8 +- drivers/dfu/dfu_ram.c | 4 +- drivers/dfu/dfu_sf.c | 8 +- drivers/dfu/dfu_virt.c | 2 +- drivers/fastboot/fb_command.c | 2 +- drivers/gpio/gpio-uclass.c | 2 +- drivers/gpio/mxs_gpio.c | 4 +- drivers/gpio/pca953x.c | 4 +- drivers/gpio/tca642x.c | 4 +- drivers/misc/ds4510.c | 10 +- drivers/net/e1000.c | 2 +- drivers/net/e1000_spi.c | 4 +- drivers/net/fm/fdt.c | 2 +- drivers/net/fsl-mc/mc.c | 5 +- drivers/net/netconsole.c | 6 +- drivers/net/pfe_eth/pfe_cmd.c | 14 +- drivers/net/pfe_eth/pfe_firmware.c | 2 +- drivers/net/phy/b53.c | 14 +- drivers/net/phy/mv88e6352.c | 14 +- drivers/net/qe/dm_qe_uec.c | 4 +- drivers/pinctrl/nexell/pinctrl-nexell.c | 2 +- drivers/pinctrl/pinctrl-uclass.c | 2 +- drivers/power/power_core.c | 6 +- drivers/qe/qe.c | 4 +- drivers/ram/octeon/octeon_ddr.c | 2 +- drivers/rtc/m41t60.c | 2 +- drivers/serial/serial-uclass.c | 2 +- drivers/serial/serial.c | 2 +- drivers/usb/cdns3/gadget.c | 2 +- drivers/usb/gadget/epautoconf.c | 2 +- drivers/usb/gadget/ether.c | 3 +- drivers/video/ati_radeon_fb.c | 2 +- drivers/video/cfb_console.c | 2 +- drivers/video/mx3fb.c | 2 +- drivers/video/vidconsole-uclass.c | 4 +- examples/standalone/atmel_df_pow2.c | 5 +- fs/fs.c | 14 +- include/vsprintf.h | 63 ++++++++- lib/dhry/cmd_dhry.c | 2 +- lib/fdtdec.c | 2 +- lib/net_utils.c | 4 +- lib/strto.c | 80 ++++++++--- lib/uuid.c | 14 +- lib/vsprintf.c | 2 +- net/bootp.c | 2 +- net/eth-uclass.c | 4 +- net/eth_legacy.c | 2 +- net/net.c | 2 +- net/tftp.c | 13 +- test/str_ut.c | 125 +++++++++++++++++- 254 files changed, 1217 insertions(+), 950 deletions(-) create mode 100644 doc/usage/cmdline.rst