All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v9 0/7] env: Allow environment in text files
@ 2021-10-19 22:44 Simon Glass
  2021-10-19 22:44 ` [PATCH v9 1/7] sandbox: Drop distro_boot Simon Glass
                   ` (7 more replies)
  0 siblings, 8 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass, Joe Hershberger

One barrier to completing the 7-year-long Kconfig migration is that
the default environment is implemented using ad-hoc CONFIG options.
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS.

It is not really feasible to move the environment to Kconfig as it is
hundreds of lines of text in some cases.

Even considering the current situation, it is painful to add large
amounts of text to the config-header file and dealing with quoting and
newlines is harder than it should be. It would be better if we could just
type the script into a text file and have it included by U-Boot.

This is already supported by the CONFIG_USE_DEFAULT_ENV_FILE feature. but
that does not support use of CONFIG options or comments, so is best suited
for use by other build systems wanting to define the U-Boot environment.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file board/<vendor>/<board>.env or
use CONFIG_ENV_SOURCE_FILE to set a filename.

The environment variables should be of the form "var=value". Values can
extend to multiple lines. This series converts the existing environment
documentation to rST and updates it to explain how to use this.

Note: this series was originally sent eight years ago:

https://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-sjg@chromium.org/

It has been updated to work with Kconfig, etc. Some review comments in
that patch were infeasible so I have not addressed them. I would like
this series to be considered independently, on its merits.

Rather than deal with the complexity of rewriting the distro-boot
script, this is disabled for sandbox. The forthcoming bootmethod approach
should provide the same functionality without needing the complex
scripting in the environment.

Migration needs more thought, although it can be done later. It may be
possible to do migrate automatically, using buildman to extract the
built-in environmnent from the ELF file.

This would produce a pretty ugly conversion though, since it would drop
all the intermediate variables used to create the environment.

Better would be to parse the config.h file, figure out the components of
CONFIG_EXTRA_ENV_SETTINGS then output these as separate pieces in the
file. It is not clear how easy that would be, nor whether the result would
be very pretty. Also the __stringify() macro needs to be handled somehow.

This series is available at u-boot-dm/env-working

Comments welcome.

Changes in v9:
- Drop mention of other strange characters
- Clarify that the + restriction is on the variable name not its value
- Add some tests for the script
- Deal with leading tabs
- Squash indentation down to one space
- Convert newlines within strings to spaces, which seems more consistent
- Handle appending an empty string to an empty var
- Fix blank line between tags
- Fix typo in commit message
- More bikeshedding on env_get_autostart()
- Fix '<vendor><board>' in cover letter
- Use env_get_yesno() in env_get_autostart() and update docs

Changes in v8:
- Update commit message to avoid mentioning the 'env' subdirectory
- Update commit message to mention the + restriction, etc.
- Overwrite the env file each time, to avoid incremental-build problems
- Fix ambiguity about what is ignored
- Go into more detail about the change of behaviour with autostart

Changes in v7:
- Use 'env' basename instead of 'environment' for intermediate output files
- Show a message indicating the source text file being used
- Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined
- Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name
- Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty
- Rewrite the documentation
- Drop the use of common.env
- Update awk script to output the whole CONFIG string, or just a comment
- Add new patch to explain the relationship with DEFAULT_ENV_FILE
- A few more tweaks
- Update the cover letter

Changes in v6:
- Move all updates to a separate patch
- Combine the two env2string.awk patches into one
- Move all updates to a separate patch
- More updates and improvements
- Add new patch to tidy up use of autostart env var

Changes in v5:
- Minor updates as suggested by Wolfgang
- Explain how to include the common.env file
- Explain why variables starting with _ , and / are not supported
- Expand the definition of how to declare an environment variable
- Explain what happens to empty variables
- Update maintainer
- Move use of += to this patch
- Explain that environment variables may not end in +
- Minor updates as suggested by Wolfgang

Changes in v4:
- Add new patch to move environment documentation to rST
- Move this from being part of configuring U-Boot to part of building it
- Don't put the environment in autoconf.mk as it is not needed
- Add documentation in rST format instead of README
- Drop mention of import/export
- Update awk script to ignore blank lines, as generated by clang
- Add documentation in rST format instead of README
- Add new patch to move environment documentation to rST

Changes in v3:
- Adjust Makefile to generate the .inc and .h files in separate fules
- Add more detail in the README about the format of .env files
- Improve the comment about " in the awk script
- Correctly terminate environment files with \n
- Define __UBOOT_CONFIG__ when collecting environment files
- Add new patch to use a text-based environment for sandbox

Changes in v2:
- Move .env file from include/configs to board/
- Use awk script to process environment since it is much easier on the brain
- Add information and updated example script to README
- Add dependency rule so that the environment is rebuilt when it changes
- Add separate patch to enable C preprocessor for environment files
- Enable var+=value form to simplify composing variables in multiple steps

Simon Glass (7):
  sandbox: Drop distro_boot
  doc: Move environment documentation to rST
  env: Allow U-Boot scripts to be placed in a .env file
  sandbox: Use a text-based environment
  doc: Mention CONFIG_DEFAULT_ENV_FILE
  doc: Improve environment documentation
  bootm: Tidy up use of autostart env var

 MAINTAINERS               |   7 +
 Makefile                  |  66 ++++-
 README                    | 328 -------------------------
 board/sandbox/sandbox.env |  25 ++
 cmd/bootm.c               |   4 +-
 cmd/elf.c                 |   3 +-
 common/bootm_os.c         |   5 +-
 config.mk                 |   2 +
 doc/usage/environment.rst | 490 ++++++++++++++++++++++++++++++++++++++
 doc/usage/index.rst       |   1 +
 env/Kconfig               |  18 ++
 env/common.c              |   5 +
 env/embedded.c            |   1 +
 include/configs/sandbox.h |  40 ----
 include/env.h             |   7 +
 include/env_default.h     |  11 +
 scripts/env2string.awk    |  71 ++++++
 test/py/tests/test_env.py |  93 ++++++++
 18 files changed, 799 insertions(+), 378 deletions(-)
 create mode 100644 board/sandbox/sandbox.env
 create mode 100644 doc/usage/environment.rst
 create mode 100644 scripts/env2string.awk

-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH v9 1/7] sandbox: Drop distro_boot
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-19 22:44 ` [PATCH v9 2/7] doc: Move environment documentation to rST Simon Glass
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

This is a complicated set of #defines and it is painful to convert to a
text file. We can (once pending patches are applied) provide the same
functionality with bootmethod. Drop this for sandbox to allow conversion
to a text-file environment.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
---

(no changes since v1)

 include/configs/sandbox.h | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 24c9a84fa35..c19232f202f 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -49,16 +49,6 @@
 #define CONFIG_SYS_BAUDRATE_TABLE	{4800, 9600, 19200, 38400, 57600,\
 					115200}
 
-#define BOOT_TARGET_DEVICES(func) \
-	func(HOST, host, 1) \
-	func(HOST, host, 0)
-
-#ifdef __ASSEMBLY__
-#define BOOTENV
-#else
-#include <config_distro_bootcmd.h>
-#endif
-
 #define CONFIG_KEEP_SERVERADDR
 #define CONFIG_UDP_CHECKSUM
 #define CONFIG_TIMESTAMP
@@ -103,7 +93,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	SANDBOX_SERIAL_SETTINGS \
 	SANDBOX_ETH_SETTINGS \
-	BOOTENV \
 	MEM_LAYOUT_ENV_SETTINGS
 
 #ifndef CONFIG_SPL_BUILD
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 2/7] doc: Move environment documentation to rST
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
  2021-10-19 22:44 ` [PATCH v9 1/7] sandbox: Drop distro_boot Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-20  6:38   ` Heinrich Schuchardt
  2021-10-19 22:44 ` [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

Move this from the README to rST format.

Drop i2cfast since it is obviously obsolete and breaks the formatting.
Other changes and improvements are in a following patch.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Marek Behún <marek.behun@nic.cz>
---

(no changes since v6)

Changes in v6:
- Move all updates to a separate patch

Changes in v5:
- Minor updates as suggested by Wolfgang

Changes in v4:
- Add new patch to move environment documentation to rST

 README                    | 328 --------------------------------
 doc/usage/environment.rst | 381 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 381 insertions(+), 328 deletions(-)
 create mode 100644 doc/usage/environment.rst

diff --git a/README b/README
index 840b192aae5..f20bc38a41c 100644
--- a/README
+++ b/README
@@ -2999,334 +2999,6 @@ TODO.
 For now: just type "help <command>".
 
 
-Environment Variables:
-======================
-
-U-Boot supports user configuration using Environment Variables which
-can be made persistent by saving to Flash memory.
-
-Environment Variables are set using "setenv", printed using
-"printenv", and saved to Flash using "saveenv". Using "setenv"
-without a value can be used to delete a variable from the
-environment. As long as you don't save the environment you are
-working with an in-memory copy. In case the Flash area containing the
-environment is erased by accident, a default environment is provided.
-
-Some configuration options can be set using Environment Variables.
-
-List of environment variables (most likely not complete):
-
-  baudrate	- see CONFIG_BAUDRATE
-
-  bootdelay	- see CONFIG_BOOTDELAY
-
-  bootcmd	- see CONFIG_BOOTCOMMAND
-
-  bootargs	- Boot arguments when booting an RTOS image
-
-  bootfile	- Name of the image to load with TFTP
-
-  bootm_low	- Memory range available for image processing in the bootm
-		  command can be restricted. This variable is given as
-		  a hexadecimal number and defines lowest address allowed
-		  for use by the bootm command. See also "bootm_size"
-		  environment variable. Address defined by "bootm_low" is
-		  also the base of the initial memory mapping for the Linux
-		  kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
-		  bootm_mapsize.
-
-  bootm_mapsize - Size of the initial memory mapping for the Linux kernel.
-		  This variable is given as a hexadecimal number and it
-		  defines the size of the memory region starting at base
-		  address bootm_low that is accessible by the Linux kernel
-		  during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
-		  as the default value if it is defined, and bootm_size is
-		  used otherwise.
-
-  bootm_size	- Memory range available for image processing in the bootm
-		  command can be restricted. This variable is given as
-		  a hexadecimal number and defines the size of the region
-		  allowed for use by the bootm command. See also "bootm_low"
-		  environment variable.
-
-  bootstopkeysha256, bootdelaykey, bootstopkey	- See README.autoboot
-
-  updatefile	- Location of the software update file on a TFTP server, used
-		  by the automatic software update feature. Please refer to
-		  documentation in doc/README.update for more details.
-
-  autoload	- if set to "no" (any string beginning with 'n'),
-		  "bootp" will just load perform a lookup of the
-		  configuration from the BOOTP server, but not try to
-		  load any image using TFTP
-
-  autostart	- if set to "yes", an image loaded using the "bootp",
-		  "rarpboot", "tftpboot" or "diskboot" commands will
-		  be automatically started (by internally calling
-		  "bootm")
-
-		  If set to "no", a standalone image passed to the
-		  "bootm" command will be copied to the load address
-		  (and eventually uncompressed), but NOT be started.
-		  This can be used to load and uncompress arbitrary
-		  data.
-
-  fdt_high	- if set this restricts the maximum address that the
-		  flattened device tree will be copied into upon boot.
-		  For example, if you have a system with 1 GB memory
-		  at physical address 0x10000000, while Linux kernel
-		  only recognizes the first 704 MB as low memory, you
-		  may need to set fdt_high as 0x3C000000 to have the
-		  device tree blob be copied to the maximum address
-		  of the 704 MB low memory, so that Linux kernel can
-		  access it during the boot procedure.
-
-		  If this is set to the special value 0xFFFFFFFF then
-		  the fdt will not be copied at all on boot.  For this
-		  to work it must reside in writable memory, have
-		  sufficient padding on the end of it for u-boot to
-		  add the information it needs into it, and the memory
-		  must be accessible by the kernel.
-
-  fdtcontroladdr- if set this is the address of the control flattened
-		  device tree used by U-Boot when CONFIG_OF_CONTROL is
-		  defined.
-
-  i2cfast	- (PPC405GP|PPC405EP only)
-		  if set to 'y' configures Linux I2C driver for fast
-		  mode (400kHZ). This environment variable is used in
-		  initialization code. So, for changes to be effective
-		  it must be saved and board must be reset.
-
-  initrd_high	- restrict positioning of initrd images:
-		  If this variable is not set, initrd images will be
-		  copied to the highest possible address in RAM; this
-		  is usually what you want since it allows for
-		  maximum initrd size. If for some reason you want to
-		  make sure that the initrd image is loaded below the
-		  CONFIG_SYS_BOOTMAPSZ limit, you can set this environment
-		  variable to a value of "no" or "off" or "0".
-		  Alternatively, you can set it to a maximum upper
-		  address to use (U-Boot will still check that it
-		  does not overwrite the U-Boot stack and data).
-
-		  For instance, when you have a system with 16 MB
-		  RAM, and want to reserve 4 MB from use by Linux,
-		  you can do this by adding "mem=12M" to the value of
-		  the "bootargs" variable. However, now you must make
-		  sure that the initrd image is placed in the first
-		  12 MB as well - this can be done with
-
-		  setenv initrd_high 00c00000
-
-		  If you set initrd_high to 0xFFFFFFFF, this is an
-		  indication to U-Boot that all addresses are legal
-		  for the Linux kernel, including addresses in flash
-		  memory. In this case U-Boot will NOT COPY the
-		  ramdisk at all. This may be useful to reduce the
-		  boot time on your system, but requires that this
-		  feature is supported by your Linux kernel.
-
-  ipaddr	- IP address; needed for tftpboot command
-
-  loadaddr	- Default load address for commands like "bootp",
-		  "rarpboot", "tftpboot", "loadb" or "diskboot"
-
-  loads_echo	- see CONFIG_LOADS_ECHO
-
-  serverip	- TFTP server IP address; needed for tftpboot command
-
-  bootretry	- see CONFIG_BOOT_RETRY_TIME
-
-  bootdelaykey	- see CONFIG_AUTOBOOT_DELAY_STR
-
-  bootstopkey	- see CONFIG_AUTOBOOT_STOP_STR
-
-  ethprime	- controls which interface is used first.
-
-  ethact	- controls which interface is currently active.
-		  For example you can do the following
-
-		  => setenv ethact FEC
-		  => ping 192.168.0.1 # traffic sent on FEC
-		  => setenv ethact SCC
-		  => ping 10.0.0.1 # traffic sent on SCC
-
-  ethrotate	- When set to "no" U-Boot does not go through all
-		  available network interfaces.
-		  It just stays at the currently selected interface.
-
-  netretry	- When set to "no" each network operation will
-		  either succeed or fail without retrying.
-		  When set to "once" the network operation will
-		  fail when all the available network interfaces
-		  are tried once without success.
-		  Useful on scripts which control the retry operation
-		  themselves.
-
-  npe_ucode	- set load address for the NPE microcode
-
-  silent_linux  - If set then Linux will be told to boot silently, by
-		  changing the console to be empty. If "yes" it will be
-		  made silent. If "no" it will not be made silent. If
-		  unset, then it will be made silent if the U-Boot console
-		  is silent.
-
-  tftpsrcp	- If this is set, the value is used for TFTP's
-		  UDP source port.
-
-  tftpdstp	- If this is set, the value is used for TFTP's UDP
-		  destination port instead of the Well Know Port 69.
-
-  tftpblocksize - Block size to use for TFTP transfers; if not set,
-		  we use the TFTP server's default block size
-
-  tftptimeout	- Retransmission timeout for TFTP packets (in milli-
-		  seconds, minimum value is 1000 = 1 second). Defines
-		  when a packet is considered to be lost so it has to
-		  be retransmitted. The default is 5000 = 5 seconds.
-		  Lowering this value may make downloads succeed
-		  faster in networks with high packet loss rates or
-		  with unreliable TFTP servers.
-
-  tftptimeoutcountmax	- maximum count of TFTP timeouts (no
-		  unit, minimum value = 0). Defines how many timeouts
-		  can happen during a single file transfer before that
-		  transfer is aborted. The default is 10, and 0 means
-		  'no timeouts allowed'. Increasing this value may help
-		  downloads succeed with high packet loss rates, or with
-		  unreliable TFTP servers or client hardware.
-
-  tftpwindowsize	- if this is set, the value is used for TFTP's
-		  window size as described by RFC 7440.
-		  This means the count of blocks we can receive before
-		  sending ack to server.
-
-  vlan		- When set to a value < 4095 the traffic over
-		  Ethernet is encapsulated/received over 802.1q
-		  VLAN tagged frames.
-
-  bootpretryperiod	- Period during which BOOTP/DHCP sends retries.
-		  Unsigned value, in milliseconds. If not set, the period will
-		  be either the default (28000), or a value based on
-		  CONFIG_NET_RETRY_COUNT, if defined. This value has
-		  precedence over the valu based on CONFIG_NET_RETRY_COUNT.
-
-  memmatches	- Number of matches found by the last 'ms' command, in hex
-
-  memaddr	- Address of the last match found by the 'ms' command, in hex,
-		  or 0 if none
-
-  mempos	- Index position of the last match found by the 'ms' command,
-		  in units of the size (.b, .w, .l) of the search
-
-  zbootbase	- (x86 only) Base address of the bzImage 'setup' block
-
-  zbootaddr	- (x86 only) Address of the loaded bzImage, typically
-		  BZIMAGE_LOAD_ADDR which is 0x100000
-
-The following image location variables contain the location of images
-used in booting. The "Image" column gives the role of the image and is
-not an environment variable name. The other columns are environment
-variable names. "File Name" gives the name of the file on a TFTP
-server, "RAM Address" gives the location in RAM the image will be
-loaded to, and "Flash Location" gives the image's address in NOR
-flash or offset in NAND flash.
-
-*Note* - these variables don't have to be defined for all boards, some
-boards currently use other variables for these purposes, and some
-boards use these variables for other purposes.
-
-Image		    File Name	     RAM Address       Flash Location
------		    ---------	     -----------       --------------
-u-boot		    u-boot	     u-boot_addr_r     u-boot_addr
-Linux kernel	    bootfile	     kernel_addr_r     kernel_addr
-device tree blob    fdtfile	     fdt_addr_r	       fdt_addr
-ramdisk		    ramdiskfile	     ramdisk_addr_r    ramdisk_addr
-
-The following environment variables may be used and automatically
-updated by the network boot commands ("bootp" and "rarpboot"),
-depending the information provided by your boot server:
-
-  bootfile	- see above
-  dnsip		- IP address of your Domain Name Server
-  dnsip2	- IP address of your secondary Domain Name Server
-  gatewayip	- IP address of the Gateway (Router) to use
-  hostname	- Target hostname
-  ipaddr	- see above
-  netmask	- Subnet Mask
-  rootpath	- Pathname of the root filesystem on the NFS server
-  serverip	- see above
-
-
-There are two special Environment Variables:
-
-  serial#	- contains hardware identification information such
-		  as type string and/or serial number
-  ethaddr	- Ethernet address
-
-These variables can be set only once (usually during manufacturing of
-the board). U-Boot refuses to delete or overwrite these variables
-once they have been set once.
-
-
-Further special Environment Variables:
-
-  ver		- Contains the U-Boot version string as printed
-		  with the "version" command. This variable is
-		  readonly (see CONFIG_VERSION_VARIABLE).
-
-
-Please note that changes to some configuration parameters may take
-only effect after the next boot (yes, that's just like Windoze :-).
-
-
-Callback functions for environment variables:
----------------------------------------------
-
-For some environment variables, the behavior of u-boot needs to change
-when their values are changed.  This functionality allows functions to
-be associated with arbitrary variables.  On creation, overwrite, or
-deletion, the callback will provide the opportunity for some side
-effect to happen or for the change to be rejected.
-
-The callbacks are named and associated with a function using the
-U_BOOT_ENV_CALLBACK macro in your board or driver code.
-
-These callbacks are associated with variables in one of two ways.  The
-static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC
-in the board configuration to a string that defines a list of
-associations.  The list must be in the following format:
-
-	entry = variable_name[:callback_name]
-	list = entry[,list]
-
-If the callback name is not specified, then the callback is deleted.
-Spaces are also allowed anywhere in the list.
-
-Callbacks can also be associated by defining the ".callbacks" variable
-with the same list format above.  Any association in ".callbacks" will
-override any association in the static list. You can define
-CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the
-".callbacks" environment variable in the default or embedded environment.
-
-If CONFIG_REGEX is defined, the variable_name above is evaluated as a
-regular expression. This allows multiple variables to be connected to
-the same callback without explicitly listing them all out.
-
-The signature of the callback functions is:
-
-    int callback(const char *name, const char *value, enum env_op op, int flags)
-
-* name - changed environment variable
-* value - new value of the environment variable
-* op - operation (create, overwrite, or delete)
-* flags - attributes of the environment variable change, see flags H_* in
-  include/search.h
-
-The return value is 0 if the variable change is accepted and 1 otherwise.
-
-
 Note for Redundant Ethernet Interfaces:
 =======================================
 
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
new file mode 100644
index 00000000000..7a733b44556
--- /dev/null
+++ b/doc/usage/environment.rst
@@ -0,0 +1,381 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Environment Variables
+=====================
+
+U-Boot supports user configuration using Environment Variables which
+can be made persistent by saving to Flash memory.
+
+Environment Variables are set using "setenv", printed using
+"printenv", and saved to Flash using "saveenv". Using "setenv"
+without a value can be used to delete a variable from the
+environment. As long as you don't save the environment you are
+working with an in-memory copy. In case the Flash area containing the
+environment is erased by accident, a default environment is provided.
+
+Some configuration options can be set using Environment Variables.
+
+List of environment variables (most likely not complete):
+
+baudrate
+    see CONFIG_BAUDRATE
+
+bootdelay
+    see CONFIG_BOOTDELAY
+
+bootcmd
+    see CONFIG_BOOTCOMMAND
+
+bootargs
+    Boot arguments when booting an RTOS image
+
+bootfile
+    Name of the image to load with TFTP
+
+bootm_low
+    Memory range available for image processing in the bootm
+    command can be restricted. This variable is given as
+    a hexadecimal number and defines lowest address allowed
+    for use by the bootm command. See also "bootm_size"
+    environment variable. Address defined by "bootm_low" is
+    also the base of the initial memory mapping for the Linux
+    kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
+    bootm_mapsize.
+
+bootm_mapsize
+    Size of the initial memory mapping for the Linux kernel.
+    This variable is given as a hexadecimal number and it
+    defines the size of the memory region starting at base
+    address bootm_low that is accessible by the Linux kernel
+    during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
+    as the default value if it is defined, and bootm_size is
+    used otherwise.
+
+bootm_size
+    Memory range available for image processing in the bootm
+    command can be restricted. This variable is given as
+    a hexadecimal number and defines the size of the region
+    allowed for use by the bootm command. See also "bootm_low"
+    environment variable.
+
+bootstopkeysha256, bootdelaykey, bootstopkey
+    See README.autoboot
+
+updatefile
+    Location of the software update file on a TFTP server, used
+    by the automatic software update feature. Please refer to
+    documentation in doc/README.update for more details.
+
+autoload
+    if set to "no" (any string beginning with 'n'),
+    "bootp" will just load perform a lookup of the
+    configuration from the BOOTP server, but not try to
+    load any image using TFTP
+
+autostart
+    if set to "yes", an image loaded using the "bootp",
+    "rarpboot", "tftpboot" or "diskboot" commands will
+    be automatically started (by internally calling
+    "bootm")
+
+    If set to "no", a standalone image passed to the
+    "bootm" command will be copied to the load address
+    (and eventually uncompressed), but NOT be started.
+    This can be used to load and uncompress arbitrary
+    data.
+
+fdt_high
+    if set this restricts the maximum address that the
+    flattened device tree will be copied into upon boot.
+    For example, if you have a system with 1 GB memory
+    at physical address 0x10000000, while Linux kernel
+    only recognizes the first 704 MB as low memory, you
+    may need to set fdt_high as 0x3C000000 to have the
+    device tree blob be copied to the maximum address
+    of the 704 MB low memory, so that Linux kernel can
+    access it during the boot procedure.
+
+    If this is set to the special value 0xFFFFFFFF then
+    the fdt will not be copied at all on boot.  For this
+    to work it must reside in writable memory, have
+    sufficient padding on the end of it for u-boot to
+    add the information it needs into it, and the memory
+    must be accessible by the kernel.
+
+fdtcontroladdr
+    if set this is the address of the control flattened
+    device tree used by U-Boot when CONFIG_OF_CONTROL is
+    defined.
+
+initrd_high
+    restrict positioning of initrd images:
+    If this variable is not set, initrd images will be
+    copied to the highest possible address in RAM; this
+    is usually what you want since it allows for
+    maximum initrd size. If for some reason you want to
+    make sure that the initrd image is loaded below the
+    CONFIG_SYS_BOOTMAPSZ limit, you can set this environment
+    variable to a value of "no" or "off" or "0".
+    Alternatively, you can set it to a maximum upper
+    address to use (U-Boot will still check that it
+    does not overwrite the U-Boot stack and data).
+
+    For instance, when you have a system with 16 MB
+    RAM, and want to reserve 4 MB from use by Linux,
+    you can do this by adding "mem=12M" to the value of
+    the "bootargs" variable. However, now you must make
+    sure that the initrd image is placed in the first
+    12 MB as well - this can be done with::
+
+        setenv initrd_high 00c00000
+
+    If you set initrd_high to 0xFFFFFFFF, this is an
+    indication to U-Boot that all addresses are legal
+    for the Linux kernel, including addresses in flash
+    memory. In this case U-Boot will NOT COPY the
+    ramdisk at all. This may be useful to reduce the
+    boot time on your system, but requires that this
+    feature is supported by your Linux kernel.
+
+ipaddr
+    IP address; needed for tftpboot command
+
+loadaddr
+    Default load address for commands like "bootp",
+    "rarpboot", "tftpboot", "loadb" or "diskboot"
+
+loads_echo
+    see CONFIG_LOADS_ECHO
+
+serverip
+    TFTP server IP address; needed for tftpboot command
+
+bootretry
+    see CONFIG_BOOT_RETRY_TIME
+
+bootdelaykey
+    see CONFIG_AUTOBOOT_DELAY_STR
+
+bootstopkey
+    see CONFIG_AUTOBOOT_STOP_STR
+
+ethprime
+    controls which interface is used first.
+
+ethact
+    controls which interface is currently active.
+    For example you can do the following::
+
+    => setenv ethact FEC
+    => ping 192.168.0.1 # traffic sent on FEC
+    => setenv ethact SCC
+    => ping 10.0.0.1 # traffic sent on SCC
+
+ethrotate
+    When set to "no" U-Boot does not go through all
+    available network interfaces.
+    It just stays at the currently selected interface.
+
+netretry
+    When set to "no" each network operation will
+    either succeed or fail without retrying.
+    When set to "once" the network operation will
+    fail when all the available network interfaces
+    are tried once without success.
+    Useful on scripts which control the retry operation
+    themselves.
+
+npe_ucode
+    set load address for the NPE microcode
+
+silent_linux
+    If set then Linux will be told to boot silently, by
+    changing the console to be empty. If "yes" it will be
+    made silent. If "no" it will not be made silent. If
+    unset, then it will be made silent if the U-Boot console
+    is silent.
+
+tftpsrcp
+    If this is set, the value is used for TFTP's
+    UDP source port.
+
+tftpdstp
+    If this is set, the value is used for TFTP's UDP
+    destination port instead of the Well Know Port 69.
+
+tftpblocksize
+    Block size to use for TFTP transfers; if not set,
+    we use the TFTP server's default block size
+
+tftptimeout
+    Retransmission timeout for TFTP packets (in milli-
+    seconds, minimum value is 1000 = 1 second). Defines
+    when a packet is considered to be lost so it has to
+    be retransmitted. The default is 5000 = 5 seconds.
+    Lowering this value may make downloads succeed
+    faster in networks with high packet loss rates or
+    with unreliable TFTP servers.
+
+tftptimeoutcountmax
+    maximum count of TFTP timeouts (no
+    unit, minimum value = 0). Defines how many timeouts
+    can happen during a single file transfer before that
+    transfer is aborted. The default is 10, and 0 means
+    'no timeouts allowed'. Increasing this value may help
+    downloads succeed with high packet loss rates, or with
+    unreliable TFTP servers or client hardware.
+
+tftpwindowsize
+    if this is set, the value is used for TFTP's
+    window size as described by RFC 7440.
+    This means the count of blocks we can receive before
+    sending ack to server.
+
+vlan
+    When set to a value < 4095 the traffic over
+    Ethernet is encapsulated/received over 802.1q
+    VLAN tagged frames.
+
+bootpretryperiod
+    Period during which BOOTP/DHCP sends retries.
+    Unsigned value, in milliseconds. If not set, the period will
+    be either the default (28000), or a value based on
+    CONFIG_NET_RETRY_COUNT, if defined. This value has
+    precedence over the valu based on CONFIG_NET_RETRY_COUNT.
+
+memmatches
+    Number of matches found by the last 'ms' command, in hex
+
+memaddr
+    Address of the last match found by the 'ms' command, in hex,
+    or 0 if none
+
+mempos
+    Index position of the last match found by the 'ms' command,
+    in units of the size (.b, .w, .l) of the search
+
+zbootbase
+    (x86 only) Base address of the bzImage 'setup' block
+
+zbootaddr
+    (x86 only) Address of the loaded bzImage, typically
+    BZIMAGE_LOAD_ADDR which is 0x100000
+
+
+Image locations
+---------------
+
+The following image location variables contain the location of images
+used in booting. The "Image" column gives the role of the image and is
+not an environment variable name. The other columns are environment
+variable names. "File Name" gives the name of the file on a TFTP
+server, "RAM Address" gives the location in RAM the image will be
+loaded to, and "Flash Location" gives the image's address in NOR
+flash or offset in NAND flash.
+
+*Note* - these variables don't have to be defined for all boards, some
+boards currently use other variables for these purposes, and some
+boards use these variables for other purposes.
+
+================= ============== ================ ==============
+Image             File Name      RAM Address      Flash Location
+================= ============== ================ ==============
+u-boot            u-boot         u-boot_addr_r    u-boot_addr
+Linux kernel      bootfile       kernel_addr_r    kernel_addr
+device tree blob  fdtfile        fdt_addr_r       fdt_addr
+ramdisk           ramdiskfile    ramdisk_addr_r   ramdisk_addr
+================= ============== ================ ==============
+
+
+Automatically updated variables
+-------------------------------
+
+The following environment variables may be used and automatically
+updated by the network boot commands ("bootp" and "rarpboot"),
+depending the information provided by your boot server:
+
+=========  ===================================================
+Variable   Notes
+=========  ===================================================
+bootfile   see above
+dnsip      IP address of your Domain Name Server
+dnsip2     IP address of your secondary Domain Name Server
+gatewayip  IP address of the Gateway (Router) to use
+hostname   Target hostname
+ipaddr     See above
+netmask    Subnet Mask
+rootpath   Pathname of the root filesystem on the NFS server
+serverip   see above
+=========  ===================================================
+
+
+Special environment variables
+-----------------------------
+
+There are two special Environment Variables:
+
+serial#
+    contains hardware identification information such as type string and/or
+    serial number
+ethaddr
+    Ethernet address
+
+These variables can be set only once (usually during manufacturing of
+the board). U-Boot refuses to delete or overwrite these variables
+once they have been set once.
+
+Also:
+
+ver
+    Contains the U-Boot version string as printed
+    with the "version" command. This variable is
+    readonly (see CONFIG_VERSION_VARIABLE).
+
+Please note that changes to some configuration parameters may take
+only effect after the next boot (yes, that's just like Windoze :-).
+
+
+Callback functions for environment variables
+--------------------------------------------
+
+For some environment variables, the behavior of u-boot needs to change
+when their values are changed.  This functionality allows functions to
+be associated with arbitrary variables.  On creation, overwrite, or
+deletion, the callback will provide the opportunity for some side
+effect to happen or for the change to be rejected.
+
+The callbacks are named and associated with a function using the
+U_BOOT_ENV_CALLBACK macro in your board or driver code.
+
+These callbacks are associated with variables in one of two ways.  The
+static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC
+in the board configuration to a string that defines a list of
+associations.  The list must be in the following format::
+
+    entry = variable_name[:callback_name]
+    list = entry[,list]
+
+If the callback name is not specified, then the callback is deleted.
+Spaces are also allowed anywhere in the list.
+
+Callbacks can also be associated by defining the ".callbacks" variable
+with the same list format above.  Any association in ".callbacks" will
+override any association in the static list. You can define
+CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the
+".callbacks" environment variable in the default or embedded environment.
+
+If CONFIG_REGEX is defined, the variable_name above is evaluated as a
+regular expression. This allows multiple variables to be connected to
+the same callback without explicitly listing them all out.
+
+The signature of the callback functions is::
+
+    int callback(const char *name, const char *value, enum env_op op, int flags)
+
+* name - changed environment variable
+* value - new value of the environment variable
+* op - operation (create, overwrite, or delete)
+* flags - attributes of the environment variable change, see flags H_* in
+  include/search.h
+
+The return value is 0 if the variable change is accepted and 1 otherwise.
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
  2021-10-19 22:44 ` [PATCH v9 1/7] sandbox: Drop distro_boot Simon Glass
  2021-10-19 22:44 ` [PATCH v9 2/7] doc: Move environment documentation to rST Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-21  9:50   ` Wolfgang Denk
  2021-10-19 22:44 ` [PATCH v9 4/7] sandbox: Use a text-based environment Simon Glass
                   ` (4 subsequent siblings)
  7 siblings, 1 reply; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass, Joe Hershberger

At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in a board/<vendor>
directory, typically called <board>.env and controlled by the
CONFIG_ENV_SOURCE_FILE option.

The environment variables should be of the form "var=value". Values can
extend to multiple lines. See the README under 'Environment Variables:'
for more information and an example. Note that variables names may
not end in + due to the += syntax below.

In many cases environment variables need access to the U-Boot CONFIG
variables to select different options. Enable this so that the environment
scripts can be as useful as the ones currently in the board config files.
This uses the C preprocessor, means that comments can be included in the
environment using /* ... */

Also support += to allow variables to be appended to. This is needed when
using the preprocessor.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Tested-by: Marek Behún <marek.behun@nic.cz>
---

Changes in v9:
- Drop mention of other strange characters
- Clarify that the + restriction is on the variable name not its value
- Add some tests for the script
- Deal with leading tabs
- Squash indentation down to one space
- Convert newlines within strings to spaces, which seems more consistent
- Handle appending an empty string to an empty var

Changes in v8:
- Update commit message to avoid mentioning the 'env' subdirectory
- Update commit message to mention the + restriction, etc.
- Overwrite the env file each time, to avoid incremental-build problems

Changes in v7:
- Use 'env' basename instead of 'environment' for intermediate output files
- Show a message indicating the source text file being used
- Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined
- Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name
- Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty
- Rewrite the documentation
- Drop the use of common.env
- Update awk script to output the whole CONFIG string, or just a comment

Changes in v6:
- Combine the two env2string.awk patches into one

Changes in v5:
- Explain how to include the common.env file
- Explain why variables starting with _ , and / are not supported
- Expand the definition of how to declare an environment variable
- Explain what happens to empty variables
- Update maintainer
- Move use of += to this patch
- Explain that environment variables may not end in +

Changes in v4:
- Move this from being part of configuring U-Boot to part of building it
- Don't put the environment in autoconf.mk as it is not needed
- Add documentation in rST format instead of README
- Drop mention of import/export
- Update awk script to ignore blank lines, as generated by clang
- Add documentation in rST format instead of README

Changes in v3:
- Adjust Makefile to generate the .inc and .h files in separate fules
- Add more detail in the README about the format of .env files
- Improve the comment about " in the awk script
- Correctly terminate environment files with \n
- Define __UBOOT_CONFIG__ when collecting environment files

Changes in v2:
- Move .env file from include/configs to board/
- Use awk script to process environment since it is much easier on the brain
- Add information and updated example script to README
- Add dependency rule so that the environment is rebuilt when it changes
- Add separate patch to enable C preprocessor for environment files
- Enable var+=value form to simplify composing variables in multiple steps

 MAINTAINERS               |  7 +++
 Makefile                  | 66 ++++++++++++++++++++++++++-
 config.mk                 |  2 +
 doc/usage/environment.rst | 77 +++++++++++++++++++++++++++++++-
 env/Kconfig               | 18 ++++++++
 env/embedded.c            |  1 +
 include/env_default.h     | 11 +++++
 scripts/env2string.awk    | 71 ++++++++++++++++++++++++++++++
 test/py/tests/test_env.py | 93 +++++++++++++++++++++++++++++++++++++++
 9 files changed, 344 insertions(+), 2 deletions(-)
 create mode 100644 scripts/env2string.awk

diff --git a/MAINTAINERS b/MAINTAINERS
index 71f468c00a8..36846528368 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -738,6 +738,13 @@ F:	test/env/
 F:	tools/env*
 F:	tools/mkenvimage.c
 
+ENVIRONMENT AS TEXT
+M:	Simon Glass <sjg@chromium.org>
+R:	Wolfgang Denk <wd@denx.de>
+S:	Maintained
+F:	doc/usage/environment.rst
+F:	scripts/env2string.awk
+
 FPGA
 M:	Michal Simek <michal.simek@xilinx.com>
 S:	Maintained
diff --git a/Makefile b/Makefile
index f911f703443..370c8710eb0 100644
--- a/Makefile
+++ b/Makefile
@@ -513,6 +513,7 @@ version_h := include/generated/version_autogenerated.h
 timestamp_h := include/generated/timestamp_autogenerated.h
 defaultenv_h := include/generated/defaultenv_autogenerated.h
 dt_h := include/generated/dt.h
+env_h := include/generated/environment.h
 
 no-dot-config-targets := clean clobber mrproper distclean \
 			 help %docs check% coccicheck \
@@ -1785,6 +1786,69 @@ quiet_cmd_sym ?= SYM     $@
 u-boot.sym: u-boot FORCE
 	$(call if_changed,sym)
 
+# Environment processing
+# ---------------------------------------------------------------------------
+
+# Directory where we expect the .env file, if it exists
+ENV_DIR := $(srctree)/board/$(BOARDDIR)
+
+# Basename of .env file, stripping quotes
+ENV_SOURCE_FILE := $(CONFIG_ENV_SOURCE_FILE:"%"=%)
+
+# Filename of .env file
+ENV_FILE_CFG := $(ENV_DIR)/$(ENV_SOURCE_FILE).env
+
+# Default filename, if CONFIG_ENV_SOURCE_FILE is empty
+ENV_FILE_BOARD := $(ENV_DIR)/$(CONFIG_SYS_BOARD:"%"=%).env
+
+# Select between the CONFIG_ENV_SOURCE_FILE and the default one
+ENV_FILE := $(if $(ENV_SOURCE_FILE),$(ENV_FILE_CFG),$(wildcard $(ENV_FILE_BOARD)))
+
+# Run the environment text file through the preprocessor, but only if it is
+# non-empty, to save time and possible build errors if something is wonky with
+# the board
+quiet_cmd_gen_envp = ENVP    $@
+      cmd_gen_envp = \
+	if [ -s "$(ENV_FILE)" ]; then \
+		$(CPP) -P $(CFLAGS) -x assembler-with-cpp -D__ASSEMBLY__ \
+			-D__UBOOT_CONFIG__ \
+			-I . -I include -I $(srctree)/include \
+			-include linux/kconfig.h -include include/config.h \
+			-I$(srctree)/arch/$(ARCH)/include \
+			$< -o $@; \
+	else \
+		echo -n >$@ ; \
+	fi
+include/generated/env.in: include/generated/env.txt FORCE
+	$(call cmd,gen_envp)
+
+# Regenerate the environment if it changes
+# We use 'wildcard' since the file is not required to exist (at present), in
+# which case we don't want this dependency, but instead should create an empty
+# file
+# This rule is useful since it shows the source file for the environment
+quiet_cmd_envc = ENVC    $@
+      cmd_envc = \
+	if [ -f "$<" ]; then \
+		cat $< > $@; \
+	elif [ -n "$(ENV_SOURCE_FILE)" ]; then \
+		echo "Missing file $(ENV_FILE_CFG)"; \
+	else \
+		echo -n >$@ ; \
+	fi
+
+include/generated/env.txt: $(wildcard $(ENV_FILE)) FORCE
+	$(call cmd,envc)
+
+# Write out the resulting environment, converted to a C string
+quiet_cmd_gen_envt = ENVT    $@
+      cmd_gen_envt = \
+	awk -f $(srctree)/scripts/env2string.awk $< >$@
+$(env_h): include/generated/env.in
+	$(call cmd,gen_envt)
+
+# ---------------------------------------------------------------------------
+
 # The actual objects are generated when descending,
 # make sure no implicit rule kicks in
 $(sort $(u-boot-init) $(u-boot-main)): $(u-boot-dirs) ;
@@ -1840,7 +1904,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory
 prepare2: prepare3 outputmakefile cfg
 
-prepare1: prepare2 $(version_h) $(timestamp_h) $(dt_h) \
+prepare1: prepare2 $(version_h) $(timestamp_h) $(dt_h) $(env_h) \
                    include/config/auto.conf
 ifeq ($(wildcard $(LDSCRIPT)),)
 	@echo >&2 "  Could not find linker script."
diff --git a/config.mk b/config.mk
index 7bb1fd4ed1b..2595aed218b 100644
--- a/config.mk
+++ b/config.mk
@@ -50,8 +50,10 @@ endif
 ifneq ($(BOARD),)
 ifdef	VENDOR
 BOARDDIR = $(VENDOR)/$(BOARD)
+ENVDIR=${vendor}/env
 else
 BOARDDIR = $(BOARD)
+ENVDIR=${board}/env
 endif
 endif
 ifdef	BOARD
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 7a733b44556..667fd193ea1 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -15,7 +15,82 @@ environment is erased by accident, a default environment is provided.
 
 Some configuration options can be set using Environment Variables.
 
-List of environment variables (most likely not complete):
+Text-based Environment
+----------------------
+
+The default environment for a board is created using a `.env` environment file
+using a simple text format. The base filename for this is defined by
+`CONFIG_ENV_SOURCE_FILE`, or `CONFIG_SYS_BOARD` if that is empty.
+
+The file must be in the board directory and have a .env extension, so
+assuming that there is a board vendor, the resulting filename is therefore::
+
+   board/<vendor>/<board>/<CONFIG_ENV_SOURCE_FILE>.env
+
+or::
+
+   board/<vendor>/<board>/<CONFIG_SYS_BOARD>.env
+
+This is a plain text file where you can type your environment variables in
+the form `var=value`. Blank lines and multi-line variables are supported.
+The conversion script looks for a line that starts in column 1 with a string
+and has an equals sign immediately afterwards. Spaces before the = are not
+permitted. It is a good idea to indent your scripts so that only the 'var='
+appears at the start of a line.
+
+To add additional text to a variable you can use var+=value. This text is
+merged into the variable during the make process and made available as a
+single value to U-Boot. To support this, environment variables may not end
+in `+`.
+
+This file can include C-style comments. Blank lines and multi-line
+variables are supported, and you can use normal C preprocessor directives
+and CONFIG defines from your board config also.
+
+For example, for snapper9260 you would create a text file called
+`board/bluewater/snapper9260.env` containing the environment text.
+
+Example::
+
+    stdout=serial
+    #ifdef CONFIG_LCD
+    stdout+=,lcd
+    #endif
+    bootcmd=
+        /* U-Boot script for booting */
+
+        if [ -z ${tftpserverip} ]; then
+            echo "Use 'setenv tftpserverip a.b.c.d' to set IP address."
+        fi
+
+        usb start; setenv autoload n; bootp;
+        tftpboot ${tftpserverip}:
+        bootm
+    failed=
+        /* Print a message when boot fails */
+        echo CONFIG_SYS_BOARD boot failed - please check your image
+        echo Load address is CONFIG_SYS_LOAD_ADDR
+
+If CONFIG_ENV_SOURCE_FILE is empty and the default filename is not present, then
+the old-style C environment is used instead. See below.
+
+Old-style C environment
+-----------------------
+
+Traditionally, the default environment is created in `include/env_default.h`,
+and can be augmented by various `CONFIG` defines. See that file for details. In
+particular you can define `CONFIG_EXTRA_ENV_SETTINGS` in your board file
+to add environment variables.
+
+Board maintainers are encouraged to migrate to the text-based environment as it
+is easier to maintain. The distro-board script still requires the old-style
+environment but work is underway to address this.
+
+
+List of environment variables
+-----------------------------
+
+This is most-likely not complete:
 
 baudrate
     see CONFIG_BAUDRATE
diff --git a/env/Kconfig b/env/Kconfig
index f75f2b13536..b93ad5c8ee0 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -3,6 +3,24 @@ menu "Environment"
 config ENV_SUPPORT
 	def_bool y
 
+config ENV_SOURCE_FILE
+	string "Environment file to use"
+	default ""
+	help
+	  This sets the basename to use to generate the default environment.
+	  This a text file as described in doc/usage/environment.rst
+
+	  The file must be in the board directory and have a .env extension, so
+	  the resulting filename is typically
+	  board/<vendor>/<board>/<CONFIG_ENV_SOURCE_FILE>.env
+
+	  If the file is not present, an error is produced.
+
+	  If this CONFIG is empty, U-Boot uses CONFIG SYS_BOARD as a default, if
+	  the file board/<vendor>/<board>/<SYS_BOARD>.env exists. Otherwise the
+	  environment is assumed to come from the ad-hoc
+	  CONFIG_EXTRA_ENV_SETTINGS #define
+
 config SAVEENV
 	def_bool y if CMD_SAVEENV
 
diff --git a/env/embedded.c b/env/embedded.c
index 208553e6af1..9f26e6cad9c 100644
--- a/env/embedded.c
+++ b/env/embedded.c
@@ -66,6 +66,7 @@
 #endif
 
 #define DEFAULT_ENV_INSTANCE_EMBEDDED
+#include <config.h>
 #include <env_default.h>
 
 #ifdef CONFIG_ENV_ADDR_REDUND
diff --git a/include/env_default.h b/include/env_default.h
index 66e203eb6e4..c06506313e5 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -10,6 +10,10 @@
 #include <env_callback.h>
 #include <linux/stringify.h>
 
+#ifndef USE_HOSTCC
+#include <generated/environment.h>
+#endif
+
 #ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
 env_t embedded_environment __UBOOT_ENV_SECTION__(environment) = {
 	ENV_CRC,	/* CRC Sum */
@@ -110,6 +114,13 @@ const uchar default_environment[] = {
 #if defined(CONFIG_BOOTCOUNT_BOOTLIMIT) && (CONFIG_BOOTCOUNT_BOOTLIMIT > 0)
 	"bootlimit="	__stringify(CONFIG_BOOTCOUNT_BOOTLIMIT)"\0"
 #endif
+#ifdef CONFIG_EXTRA_ENV_TEXT
+# ifdef CONFIG_EXTRA_ENV_SETTINGS
+# error "Your board uses a text-file environment, so must not define CONFIG_EXTRA_ENV_SETTINGS"
+# endif
+	/* This is created in the Makefile */
+	CONFIG_EXTRA_ENV_TEXT
+#endif
 #ifdef	CONFIG_EXTRA_ENV_SETTINGS
 	CONFIG_EXTRA_ENV_SETTINGS
 #endif
diff --git a/scripts/env2string.awk b/scripts/env2string.awk
new file mode 100644
index 00000000000..aff3adc67f0
--- /dev/null
+++ b/scripts/env2string.awk
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright 2021 Google, Inc
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+# Awk script to parse a text file containing an environment and convert it
+# to a C string which can be compiled into U-Boot.
+
+# The resulting output is:
+#
+#   #define CONFIG_EXTRA_ENV_TEXT "<environment here>"
+#
+# If the input is empty, this script outputs a comment instead.
+
+BEGIN {
+	# env holds the env variable we are currently processing
+	env = "";
+	ORS = ""
+}
+
+# Skip empty lines, as these are generated by the clang preprocessor
+NF {
+	# Quote quotes
+	gsub("\"", "\\\"")
+
+	# Is this the start of a new environment variable?
+	if (match($0, "^([^ \t=][^ =]*)=(.*)", arr)) {
+		if (length(env) != 0) {
+			# Record the value of the variable now completed
+			vars[var] = env
+		}
+		var = arr[1]
+		env = arr[2]
+
+		# Deal with +=
+		if (length(env) != 0 && match(var, "(.*)[+]$", var_arr)) {
+			var = var_arr[1]
+			env = vars[var] env
+		}
+	} else {
+		# Change newline to space
+		gsub(/^[ \t]+/, "")
+
+		# Don't keep leading spaces generated by the previous blank line
+		if (length(env) == 0) {
+			env = $0
+		} else {
+			env = env " " $0
+		}
+	}
+}
+
+END {
+	# Record the value of the variable now completed. If the variable is
+	# empty it is not set.
+	if (length(env) != 0) {
+		vars[var] = env
+	}
+
+	if (length(vars) != 0) {
+		printf("%s", "#define CONFIG_EXTRA_ENV_TEXT \"")
+
+		# Print out all the variables
+		for (var in vars) {
+			env = vars[var]
+			print var "=" vars[var] "\\0"
+		}
+		print "\"\n"
+	}
+}
diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
index 9bed2f48d77..c142e2c86a2 100644
--- a/test/py/tests/test_env.py
+++ b/test/py/tests/test_env.py
@@ -7,6 +7,7 @@
 import os
 import os.path
 from subprocess import call, check_call, CalledProcessError
+import tempfile
 
 import pytest
 import u_boot_utils
@@ -515,3 +516,95 @@ def test_env_ext4(state_test_env):
     finally:
         if fs_img:
             call('rm -f %s' % fs_img, shell=True)
+
+def test_env_text(u_boot_console):
+    """Test the script that converts the environment to a text file"""
+
+    def check_script(intext, expect_val):
+        """Check a test case
+
+        Args:
+            intext: Text to pass to the script
+            expect_val: Expected value of the CONFIG_EXTRA_ENV_TEXT string, or
+                None if we expect it not to be defined
+        """
+        with tempfile.TemporaryDirectory() as path:
+            fname = os.path.join(path, 'infile')
+            with open(fname, 'w') as inf:
+                print(intext, file=inf)
+            result = u_boot_utils.run_and_log(cons, ['awk', '-f', script, fname])
+            if expect_val is not None:
+                expect = '#define CONFIG_EXTRA_ENV_TEXT "%s"\n' % expect_val
+                assert result == expect
+            else:
+                assert result == ''
+
+    cons = u_boot_console
+    script = os.path.join(cons.config.source_dir, 'scripts', 'env2string.awk')
+
+    # simple script with a single var
+    check_script('fred=123', 'fred=123\\0')
+
+    # no vars
+    check_script('', None)
+
+    # two vars
+    check_script('''fred=123
+ernie=456''', 'fred=123\\0ernie=456\\0')
+
+    # blank lines
+    check_script('''fred=123
+
+
+ernie=456
+
+''', 'fred=123\\0ernie=456\\0')
+
+    # append
+    check_script('''fred=123
+ernie=456
+fred+= 456''', 'fred=123 456\\0ernie=456\\0')
+
+    # append from empty
+    check_script('''fred=
+ernie=456
+fred+= 456''', 'fred= 456\\0ernie=456\\0')
+
+    # variable with + in it
+    check_script('fred+ernie=123', 'fred+ernie=123\\0')
+
+    # ignores variables that are empty
+    check_script('''fred=
+fred+=
+ernie=456''', 'ernie=456\\0')
+
+    # contains quotes
+    check_script('''fred="my var"
+ernie=another"''', 'fred=\\"my var\\"\\0ernie=another\\"\\0')
+
+    # multi-line vars - new vars always start at column 1
+    check_script('''fred=first
+ second
+\tthird with tab
+
+   after blank
+ confusing=oops
+ernie=another"''', 'fred=first second third with tab after blank confusing=oops\\0ernie=another\\"\\0')
+
+    # real-world example
+    check_script('''ubifs_boot=
+	env exists bootubipart ||
+		env set bootubipart UBI;
+	env exists bootubivol ||
+		env set bootubivol boot;
+	if ubi part ${bootubipart} &&
+		ubifsmount ubi${devnum}:${bootubivol};
+	then
+		devtype=ubi;
+		run scan_dev_for_boot;
+	fi
+''',
+        'ubifs_boot=env exists bootubipart || env set bootubipart UBI; '
+        'env exists bootubivol || env set bootubivol boot; '
+        'if ubi part ${bootubipart} && ubifsmount ubi${devnum}:${bootubivol}; '
+        'then devtype=ubi; run scan_dev_for_boot; fi\\0')
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 4/7] sandbox: Use a text-based environment
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
                   ` (2 preceding siblings ...)
  2021-10-19 22:44 ` [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-20  6:58   ` Alexander Dahl
  2021-10-19 22:44 ` [PATCH v9 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE Simon Glass
                   ` (3 subsequent siblings)
  7 siblings, 1 reply; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

Use a text file for the environment instead of the #define settings.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
---

(no changes since v3)

Changes in v3:
- Add new patch to use a text-based environment for sandbox

 board/sandbox/sandbox.env | 25 +++++++++++++++++++++++++
 include/configs/sandbox.h | 29 -----------------------------
 2 files changed, 25 insertions(+), 29 deletions(-)
 create mode 100644 board/sandbox/sandbox.env

diff --git a/board/sandbox/sandbox.env b/board/sandbox/sandbox.env
new file mode 100644
index 00000000000..0f8d95b8db0
--- /dev/null
+++ b/board/sandbox/sandbox.env
@@ -0,0 +1,25 @@
+stdin=serial
+#ifdef CONFIG_SANDBOX_SDL
+stdin+=,cros-ec-keyb,usbkbd
+#endif
+stdout=serial,vidconsole
+stderr=serial,vidconsole
+
+ethaddr=00:00:11:22:33:44
+eth2addr=00:00:11:22:33:48
+eth3addr=00:00:11:22:33:45
+eth4addr=00:00:11:22:33:48
+eth5addr=00:00:11:22:33:46
+eth6addr=00:00:11:22:33:47
+ipaddr=1.2.3.4
+
+/*
+ * These are used for distro boot which is not supported. But once bootmethod
+ * is provided these will be used again.
+ */
+bootm_size=0x10000000
+kernel_addr_r=0x1000000
+fdt_addr_r=0xc00000
+ramdisk_addr_r=0x2000000
+scriptaddr=0x1000
+pxefile_addr_r=0x2000
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index c19232f202f..c703a1330c0 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -64,37 +64,8 @@
 #define CONFIG_LCD_BMP_RLE8
 
 #define CONFIG_KEYBOARD
-
-#define SANDBOX_SERIAL_SETTINGS		"stdin=serial,cros-ec-keyb,usbkbd\0" \
-					"stdout=serial,vidconsole\0" \
-					"stderr=serial,vidconsole\0"
-#else
-#define SANDBOX_SERIAL_SETTINGS		"stdin=serial\0" \
-					"stdout=serial,vidconsole\0" \
-					"stderr=serial,vidconsole\0"
 #endif
 
-#define SANDBOX_ETH_SETTINGS		"ethaddr=00:00:11:22:33:44\0" \
-					"eth2addr=00:00:11:22:33:48\0" \
-					"eth3addr=00:00:11:22:33:45\0" \
-					"eth4addr=00:00:11:22:33:48\0" \
-					"eth5addr=00:00:11:22:33:46\0" \
-					"eth6addr=00:00:11:22:33:47\0" \
-					"ipaddr=1.2.3.4\0"
-
-#define MEM_LAYOUT_ENV_SETTINGS \
-	"bootm_size=0x10000000\0" \
-	"kernel_addr_r=0x1000000\0" \
-	"fdt_addr_r=0xc00000\0" \
-	"ramdisk_addr_r=0x2000000\0" \
-	"scriptaddr=0x1000\0" \
-	"pxefile_addr_r=0x2000\0"
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-	SANDBOX_SERIAL_SETTINGS \
-	SANDBOX_ETH_SETTINGS \
-	MEM_LAYOUT_ENV_SETTINGS
-
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_SYS_IDE_MAXBUS		1
 #define CONFIG_SYS_ATA_IDE0_OFFSET	0
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
                   ` (3 preceding siblings ...)
  2021-10-19 22:44 ` [PATCH v9 4/7] sandbox: Use a text-based environment Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-19 22:44 ` [PATCH v9 6/7] doc: Improve environment documentation Simon Glass
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

Add mention of this option since it does a similar thing to the text
environment.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
---

Changes in v9:
- Fix blank line between tags
- Fix typo in commit message

Changes in v8:
- Fix ambiguity about what is ignored

Changes in v7:
- Add new patch to explain the relationship with DEFAULT_ENV_FILE

 doc/usage/environment.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index 667fd193ea1..adf2e067b58 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -454,3 +454,18 @@ The signature of the callback functions is::
   include/search.h
 
 The return value is 0 if the variable change is accepted and 1 otherwise.
+
+
+External environment file
+-------------------------
+
+The `CONFIG_USE_DEFAULT_ENV_FILE` option provides a way to bypass the
+environment generation in U-Boot. If enabled, then `CONFIG_DEFAULT_ENV_FILE`
+provides the name of a file which is converted into the environment,
+completely bypassing the standard environment variables in `env_default.h`.
+
+The format is the same as accepted by the mkenvimage tool, with lines containing
+key=value pairs. Blank lines and lines beginning with # are ignored.
+
+Future work may unify this feature with the text-based environment, perhaps
+moving the contents of `env_default.h` to a text file.
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 6/7] doc: Improve environment documentation
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
                   ` (4 preceding siblings ...)
  2021-10-19 22:44 ` [PATCH v9 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-19 22:44 ` [PATCH v9 7/7] bootm: Tidy up use of autostart env var Simon Glass
  2021-10-21 14:02 ` [PATCH v9 0/7] env: Allow environment in text files Tom Rini
  7 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

Make various updates suggested during review of the rST conversion.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Suggested-by: Wolfgang Denk <wd@denx.de>
---

(no changes since v7)

Changes in v7:
- A few more tweaks

Changes in v6:
- Move all updates to a separate patch
- More updates and improvements

Changes in v5:
- Minor updates as suggested by Wolfgang

Changes in v4:
- Add new patch to move environment documentation to rST

 doc/usage/environment.rst | 36 +++++++++++++++++++++++++++---------
 doc/usage/index.rst       |  1 +
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index adf2e067b58..a3eddbaaf2e 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -4,16 +4,20 @@ Environment Variables
 =====================
 
 U-Boot supports user configuration using Environment Variables which
-can be made persistent by saving to Flash memory.
+can be made persistent by saving to persistent storage, for example flash
+memory.
 
-Environment Variables are set using "setenv", printed using
-"printenv", and saved to Flash using "saveenv". Using "setenv"
+Environment Variables are set using "env set" (alias "setenv"), printed using
+"env print" (alias "printenv"), and saved to persistent storage using
+"env save" (alias "saveenv"). Using "env set"
 without a value can be used to delete a variable from the
-environment. As long as you don't save the environment you are
+environment. As long as you don't save the environment, you are
 working with an in-memory copy. In case the Flash area containing the
 environment is erased by accident, a default environment is provided.
 
-Some configuration options can be set using Environment Variables.
+Some configuration is controlled by Environment Variables, so that setting the
+variable can adjust the behaviour of U-Boot (e.g. autoboot delay, autoloading
+from tftp).
 
 Text-based Environment
 ----------------------
@@ -90,16 +94,24 @@ environment but work is underway to address this.
 List of environment variables
 -----------------------------
 
+Some configuration options can be set using Environment Variables. In many cases
+the value in the default environment comes from a CONFIG option - see
+`include/env_default.h`) for this.
+
 This is most-likely not complete:
 
 baudrate
-    see CONFIG_BAUDRATE
+    Current baud rate used by the serial console. The built-in value is set by
+    CONFIG_BAUDRATE (see `drivers/serial/Kconfig`)
 
 bootdelay
-    see CONFIG_BOOTDELAY
+    Current autoboot delay. The built-in value is set by CONFIG_BOOTDELAY (see
+    `common/Kconfig`)
 
 bootcmd
-    see CONFIG_BOOTCOMMAND
+    Defines a command string that is automatically executed when no character
+    is read on the console interface within a cetain boot delay after reset.
+    The built-in value is set by CONFIG_BOOTCOMMAND (see `common/Kconfig`)
 
 bootargs
     Boot arguments when booting an RTOS image
@@ -145,7 +157,7 @@ autoload
     if set to "no" (any string beginning with 'n'),
     "bootp" will just load perform a lookup of the
     configuration from the BOOTP server, but not try to
-    load any image using TFTP
+    load any image using TFTP or DHCP.
 
 autostart
     if set to "yes", an image loaded using the "bootp",
@@ -311,6 +323,8 @@ vlan
     Ethernet is encapsulated/received over 802.1q
     VLAN tagged frames.
 
+    Note: This appears not to be used in U-Boot. See `README.VLAN`.
+
 bootpretryperiod
     Period during which BOOTP/DHCP sends retries.
     Unsigned value, in milliseconds. If not set, the period will
@@ -352,6 +366,10 @@ flash or offset in NAND flash.
 boards currently use other variables for these purposes, and some
 boards use these variables for other purposes.
 
+Also note that most of these variables are just a commonly used set of variable
+names, used in some other variable definitions, but are not hard-coded anywhere
+in U-Boot code.
+
 ================= ============== ================ ==============
 Image             File Name      RAM Address      Flash Location
 ================= ============== ================ ==============
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 356f2a56181..1a79d1c03eb 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -5,6 +5,7 @@ Use U-Boot
    :maxdepth: 1
 
    dfu
+   environment
    fdt_overlays
    fit
    netconsole
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* [PATCH v9 7/7] bootm: Tidy up use of autostart env var
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
                   ` (5 preceding siblings ...)
  2021-10-19 22:44 ` [PATCH v9 6/7] doc: Improve environment documentation Simon Glass
@ 2021-10-19 22:44 ` Simon Glass
  2021-10-21 14:02 ` [PATCH v9 0/7] env: Allow environment in text files Tom Rini
  7 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:44 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Marek Behún, Rasmus Villemoes, Heinrich Schuchardt,
	Tom Rini, Wolfgang Denk, Simon Glass

This has different semantics in different places. Go with the bootm method
and put it in a common function so that the behaviour is consistent in
U-Boot. Update the docs.

To be clear, this changes the way that 'bootelf' and standalone boot
work. Before, if autostart was set to "fred" or "YES", for example, they
would consider that a "yes". This may change behaviour for some boards,
but the only in-tree boards which mention autostart use "no" to disable
it, which will still work.

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Wolfgang Denk <wd@denx.de>
---

Changes in v9:
- More bikeshedding on env_get_autostart()
- Fix '<vendor><board>' in cover letter
- Use env_get_yesno() in env_get_autostart() and update docs

Changes in v8:
- Go into more detail about the change of behaviour with autostart

Changes in v7:
- Update the cover letter

Changes in v6:
- Add new patch to tidy up use of autostart env var

 cmd/bootm.c               | 4 +---
 cmd/elf.c                 | 3 +--
 common/bootm_os.c         | 5 +----
 doc/usage/environment.rst | 5 +++--
 env/common.c              | 5 +++++
 include/env.h             | 7 +++++++
 6 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/cmd/bootm.c b/cmd/bootm.c
index 92468d09a1f..b82a872a86c 100644
--- a/cmd/bootm.c
+++ b/cmd/bootm.c
@@ -140,9 +140,7 @@ int do_bootm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 
 int bootm_maybe_autostart(struct cmd_tbl *cmdtp, const char *cmd)
 {
-	const char *ep = env_get("autostart");
-
-	if (ep && !strcmp(ep, "yes")) {
+	if (env_get_autostart()) {
 		char *local_args[2];
 		local_args[0] = (char *)cmd;
 		local_args[1] = NULL;
diff --git a/cmd/elf.c b/cmd/elf.c
index d75b21461c2..2b33c50bd02 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -41,7 +41,6 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 	unsigned long addr; /* Address of the ELF image */
 	unsigned long rc; /* Return value from user code */
 	char *sload = NULL;
-	const char *ep = env_get("autostart");
 	int rcode = 0;
 
 	/* Consume 'bootelf' */
@@ -69,7 +68,7 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 	else
 		addr = load_elf_image_shdr(addr);
 
-	if (ep && !strcmp(ep, "no"))
+	if (!env_get_autostart())
 		return rcode;
 
 	printf("## Starting application at 0x%08lx ...\n", addr);
diff --git a/common/bootm_os.c b/common/bootm_os.c
index 39623f9126b..f30dcebbf7d 100644
--- a/common/bootm_os.c
+++ b/common/bootm_os.c
@@ -26,12 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
 static int do_bootm_standalone(int flag, int argc, char *const argv[],
 			       bootm_headers_t *images)
 {
-	char *s;
 	int (*appl)(int, char *const[]);
 
-	/* Don't start if "autostart" is set to "no" */
-	s = env_get("autostart");
-	if ((s != NULL) && !strcmp(s, "no")) {
+	if (!env_get_autostart()) {
 		env_set_hex("filesize", images->os.image_len);
 		return 0;
 	}
diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
index a3eddbaaf2e..282550a3f44 100644
--- a/doc/usage/environment.rst
+++ b/doc/usage/environment.rst
@@ -165,8 +165,9 @@ autostart
     be automatically started (by internally calling
     "bootm")
 
-    If set to "no", a standalone image passed to the
-    "bootm" command will be copied to the load address
+    If unset, or set to "1"/"yes"/"true" (case insensitive, just the first
+    character is enough), a standalone image
+    passed to the "bootm" command will be copied to the load address
     (and eventually uncompressed), but NOT be started.
     This can be used to load and uncompress arbitrary
     data.
diff --git a/env/common.c b/env/common.c
index 81e9e0b2aaf..e46a9ee644e 100644
--- a/env/common.c
+++ b/env/common.c
@@ -47,6 +47,11 @@ int env_get_yesno(const char *var)
 		1 : 0;
 }
 
+bool env_get_autostart(void)
+{
+	return env_get_yesno("autostart") == 1;
+}
+
 /*
  * Look up the variable from the default environment
  */
diff --git a/include/env.h b/include/env.h
index d5e2bcb530f..fdad495691f 100644
--- a/include/env.h
+++ b/include/env.h
@@ -143,6 +143,13 @@ int env_get_f(const char *name, char *buf, unsigned int len);
  */
 int env_get_yesno(const char *var);
 
+/**
+ * env_get_autostart() - Check if autostart is enabled
+ *
+ * @return true if the "autostart" env var exists and is set to "yes"
+ */
+bool env_get_autostart(void);
+
 /**
  * env_set() - set an environment variable
  *
-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply related	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 2/7] doc: Move environment documentation to rST
  2021-10-19 22:44 ` [PATCH v9 2/7] doc: Move environment documentation to rST Simon Glass
@ 2021-10-20  6:38   ` Heinrich Schuchardt
  2021-10-22  3:05     ` Simon Glass
  0 siblings, 1 reply; 38+ messages in thread
From: Heinrich Schuchardt @ 2021-10-20  6:38 UTC (permalink / raw)
  To: Simon Glass
  Cc: Marek Behún, Rasmus Villemoes, Tom Rini, Wolfgang Denk,
	U-Boot Mailing List

On 10/20/21 00:44, Simon Glass wrote:
> Move this from the README to rST format.
>
> Drop i2cfast since it is obviously obsolete and breaks the formatting.
> Other changes and improvements are in a following patch.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Acked-by: Marek Behún <marek.behun@nic.cz>

This patch leads to a build error for 'make htmldocs':

doc/usage/environment.rst:document isn't included in any toctree

Please add the file to doc/usage/index.rst.

> ---
>
> (no changes since v6)
>
> Changes in v6:
> - Move all updates to a separate patch
>
> Changes in v5:
> - Minor updates as suggested by Wolfgang
>
> Changes in v4:
> - Add new patch to move environment documentation to rST
>
>   README                    | 328 --------------------------------
>   doc/usage/environment.rst | 381 ++++++++++++++++++++++++++++++++++++++
>   2 files changed, 381 insertions(+), 328 deletions(-)
>   create mode 100644 doc/usage/environment.rst
>
> diff --git a/README b/README
> index 840b192aae5..f20bc38a41c 100644
> --- a/README
> +++ b/README
> @@ -2999,334 +2999,6 @@ TODO.
>   For now: just type "help <command>".
>
>
> -Environment Variables:
> -======================
> -
> -U-Boot supports user configuration using Environment Variables which
> -can be made persistent by saving to Flash memory.
> -
> -Environment Variables are set using "setenv", printed using
> -"printenv", and saved to Flash using "saveenv". Using "setenv"
> -without a value can be used to delete a variable from the
> -environment. As long as you don't save the environment you are
> -working with an in-memory copy. In case the Flash area containing the
> -environment is erased by accident, a default environment is provided.
> -
> -Some configuration options can be set using Environment Variables.
> -
> -List of environment variables (most likely not complete):
> -
> -  baudrate	- see CONFIG_BAUDRATE
> -
> -  bootdelay	- see CONFIG_BOOTDELAY
> -
> -  bootcmd	- see CONFIG_BOOTCOMMAND
> -
> -  bootargs	- Boot arguments when booting an RTOS image
> -
> -  bootfile	- Name of the image to load with TFTP
> -
> -  bootm_low	- Memory range available for image processing in the bootm
> -		  command can be restricted. This variable is given as
> -		  a hexadecimal number and defines lowest address allowed
> -		  for use by the bootm command. See also "bootm_size"
> -		  environment variable. Address defined by "bootm_low" is
> -		  also the base of the initial memory mapping for the Linux
> -		  kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
> -		  bootm_mapsize.
> -
> -  bootm_mapsize - Size of the initial memory mapping for the Linux kernel.
> -		  This variable is given as a hexadecimal number and it
> -		  defines the size of the memory region starting at base
> -		  address bootm_low that is accessible by the Linux kernel
> -		  during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
> -		  as the default value if it is defined, and bootm_size is
> -		  used otherwise.
> -
> -  bootm_size	- Memory range available for image processing in the bootm
> -		  command can be restricted. This variable is given as
> -		  a hexadecimal number and defines the size of the region
> -		  allowed for use by the bootm command. See also "bootm_low"
> -		  environment variable.
> -
> -  bootstopkeysha256, bootdelaykey, bootstopkey	- See README.autoboot
> -
> -  updatefile	- Location of the software update file on a TFTP server, used
> -		  by the automatic software update feature. Please refer to
> -		  documentation in doc/README.update for more details.
> -
> -  autoload	- if set to "no" (any string beginning with 'n'),
> -		  "bootp" will just load perform a lookup of the
> -		  configuration from the BOOTP server, but not try to
> -		  load any image using TFTP
> -
> -  autostart	- if set to "yes", an image loaded using the "bootp",
> -		  "rarpboot", "tftpboot" or "diskboot" commands will
> -		  be automatically started (by internally calling
> -		  "bootm")
> -
> -		  If set to "no", a standalone image passed to the
> -		  "bootm" command will be copied to the load address
> -		  (and eventually uncompressed), but NOT be started.
> -		  This can be used to load and uncompress arbitrary
> -		  data.
> -
> -  fdt_high	- if set this restricts the maximum address that the
> -		  flattened device tree will be copied into upon boot.
> -		  For example, if you have a system with 1 GB memory
> -		  at physical address 0x10000000, while Linux kernel
> -		  only recognizes the first 704 MB as low memory, you
> -		  may need to set fdt_high as 0x3C000000 to have the
> -		  device tree blob be copied to the maximum address
> -		  of the 704 MB low memory, so that Linux kernel can
> -		  access it during the boot procedure.
> -
> -		  If this is set to the special value 0xFFFFFFFF then
> -		  the fdt will not be copied at all on boot.  For this
> -		  to work it must reside in writable memory, have
> -		  sufficient padding on the end of it for u-boot to
> -		  add the information it needs into it, and the memory
> -		  must be accessible by the kernel.
> -
> -  fdtcontroladdr- if set this is the address of the control flattened
> -		  device tree used by U-Boot when CONFIG_OF_CONTROL is
> -		  defined.
> -
> -  i2cfast	- (PPC405GP|PPC405EP only)
> -		  if set to 'y' configures Linux I2C driver for fast
> -		  mode (400kHZ). This environment variable is used in
> -		  initialization code. So, for changes to be effective
> -		  it must be saved and board must be reset.
> -
> -  initrd_high	- restrict positioning of initrd images:
> -		  If this variable is not set, initrd images will be
> -		  copied to the highest possible address in RAM; this
> -		  is usually what you want since it allows for
> -		  maximum initrd size. If for some reason you want to
> -		  make sure that the initrd image is loaded below the
> -		  CONFIG_SYS_BOOTMAPSZ limit, you can set this environment
> -		  variable to a value of "no" or "off" or "0".
> -		  Alternatively, you can set it to a maximum upper
> -		  address to use (U-Boot will still check that it
> -		  does not overwrite the U-Boot stack and data).
> -
> -		  For instance, when you have a system with 16 MB
> -		  RAM, and want to reserve 4 MB from use by Linux,
> -		  you can do this by adding "mem=12M" to the value of
> -		  the "bootargs" variable. However, now you must make
> -		  sure that the initrd image is placed in the first
> -		  12 MB as well - this can be done with
> -
> -		  setenv initrd_high 00c00000
> -
> -		  If you set initrd_high to 0xFFFFFFFF, this is an
> -		  indication to U-Boot that all addresses are legal
> -		  for the Linux kernel, including addresses in flash
> -		  memory. In this case U-Boot will NOT COPY the
> -		  ramdisk at all. This may be useful to reduce the
> -		  boot time on your system, but requires that this
> -		  feature is supported by your Linux kernel.
> -
> -  ipaddr	- IP address; needed for tftpboot command
> -
> -  loadaddr	- Default load address for commands like "bootp",
> -		  "rarpboot", "tftpboot", "loadb" or "diskboot"
> -
> -  loads_echo	- see CONFIG_LOADS_ECHO
> -
> -  serverip	- TFTP server IP address; needed for tftpboot command
> -
> -  bootretry	- see CONFIG_BOOT_RETRY_TIME
> -
> -  bootdelaykey	- see CONFIG_AUTOBOOT_DELAY_STR
> -
> -  bootstopkey	- see CONFIG_AUTOBOOT_STOP_STR
> -
> -  ethprime	- controls which interface is used first.
> -
> -  ethact	- controls which interface is currently active.
> -		  For example you can do the following
> -
> -		  => setenv ethact FEC
> -		  => ping 192.168.0.1 # traffic sent on FEC
> -		  => setenv ethact SCC
> -		  => ping 10.0.0.1 # traffic sent on SCC
> -
> -  ethrotate	- When set to "no" U-Boot does not go through all
> -		  available network interfaces.
> -		  It just stays at the currently selected interface.
> -
> -  netretry	- When set to "no" each network operation will
> -		  either succeed or fail without retrying.
> -		  When set to "once" the network operation will
> -		  fail when all the available network interfaces
> -		  are tried once without success.
> -		  Useful on scripts which control the retry operation
> -		  themselves.
> -
> -  npe_ucode	- set load address for the NPE microcode
> -
> -  silent_linux  - If set then Linux will be told to boot silently, by
> -		  changing the console to be empty. If "yes" it will be
> -		  made silent. If "no" it will not be made silent. If
> -		  unset, then it will be made silent if the U-Boot console
> -		  is silent.
> -
> -  tftpsrcp	- If this is set, the value is used for TFTP's
> -		  UDP source port.
> -
> -  tftpdstp	- If this is set, the value is used for TFTP's UDP
> -		  destination port instead of the Well Know Port 69.
> -
> -  tftpblocksize - Block size to use for TFTP transfers; if not set,
> -		  we use the TFTP server's default block size
> -
> -  tftptimeout	- Retransmission timeout for TFTP packets (in milli-
> -		  seconds, minimum value is 1000 = 1 second). Defines
> -		  when a packet is considered to be lost so it has to
> -		  be retransmitted. The default is 5000 = 5 seconds.
> -		  Lowering this value may make downloads succeed
> -		  faster in networks with high packet loss rates or
> -		  with unreliable TFTP servers.
> -
> -  tftptimeoutcountmax	- maximum count of TFTP timeouts (no
> -		  unit, minimum value = 0). Defines how many timeouts
> -		  can happen during a single file transfer before that
> -		  transfer is aborted. The default is 10, and 0 means
> -		  'no timeouts allowed'. Increasing this value may help
> -		  downloads succeed with high packet loss rates, or with
> -		  unreliable TFTP servers or client hardware.
> -
> -  tftpwindowsize	- if this is set, the value is used for TFTP's
> -		  window size as described by RFC 7440.
> -		  This means the count of blocks we can receive before
> -		  sending ack to server.
> -
> -  vlan		- When set to a value < 4095 the traffic over
> -		  Ethernet is encapsulated/received over 802.1q
> -		  VLAN tagged frames.
> -
> -  bootpretryperiod	- Period during which BOOTP/DHCP sends retries.
> -		  Unsigned value, in milliseconds. If not set, the period will
> -		  be either the default (28000), or a value based on
> -		  CONFIG_NET_RETRY_COUNT, if defined. This value has
> -		  precedence over the valu based on CONFIG_NET_RETRY_COUNT.
> -
> -  memmatches	- Number of matches found by the last 'ms' command, in hex
> -
> -  memaddr	- Address of the last match found by the 'ms' command, in hex,
> -		  or 0 if none
> -
> -  mempos	- Index position of the last match found by the 'ms' command,
> -		  in units of the size (.b, .w, .l) of the search
> -
> -  zbootbase	- (x86 only) Base address of the bzImage 'setup' block
> -
> -  zbootaddr	- (x86 only) Address of the loaded bzImage, typically
> -		  BZIMAGE_LOAD_ADDR which is 0x100000
> -
> -The following image location variables contain the location of images
> -used in booting. The "Image" column gives the role of the image and is
> -not an environment variable name. The other columns are environment
> -variable names. "File Name" gives the name of the file on a TFTP
> -server, "RAM Address" gives the location in RAM the image will be
> -loaded to, and "Flash Location" gives the image's address in NOR
> -flash or offset in NAND flash.
> -
> -*Note* - these variables don't have to be defined for all boards, some
> -boards currently use other variables for these purposes, and some
> -boards use these variables for other purposes.
> -
> -Image		    File Name	     RAM Address       Flash Location
> ------		    ---------	     -----------       --------------
> -u-boot		    u-boot	     u-boot_addr_r     u-boot_addr
> -Linux kernel	    bootfile	     kernel_addr_r     kernel_addr
> -device tree blob    fdtfile	     fdt_addr_r	       fdt_addr
> -ramdisk		    ramdiskfile	     ramdisk_addr_r    ramdisk_addr
> -
> -The following environment variables may be used and automatically
> -updated by the network boot commands ("bootp" and "rarpboot"),
> -depending the information provided by your boot server:
> -
> -  bootfile	- see above
> -  dnsip		- IP address of your Domain Name Server
> -  dnsip2	- IP address of your secondary Domain Name Server
> -  gatewayip	- IP address of the Gateway (Router) to use
> -  hostname	- Target hostname
> -  ipaddr	- see above
> -  netmask	- Subnet Mask
> -  rootpath	- Pathname of the root filesystem on the NFS server
> -  serverip	- see above
> -
> -
> -There are two special Environment Variables:
> -
> -  serial#	- contains hardware identification information such
> -		  as type string and/or serial number
> -  ethaddr	- Ethernet address
> -
> -These variables can be set only once (usually during manufacturing of
> -the board). U-Boot refuses to delete or overwrite these variables
> -once they have been set once.
> -
> -
> -Further special Environment Variables:
> -
> -  ver		- Contains the U-Boot version string as printed
> -		  with the "version" command. This variable is
> -		  readonly (see CONFIG_VERSION_VARIABLE).
> -
> -
> -Please note that changes to some configuration parameters may take
> -only effect after the next boot (yes, that's just like Windoze :-).
> -
> -
> -Callback functions for environment variables:
> ----------------------------------------------
> -
> -For some environment variables, the behavior of u-boot needs to change
> -when their values are changed.  This functionality allows functions to
> -be associated with arbitrary variables.  On creation, overwrite, or
> -deletion, the callback will provide the opportunity for some side
> -effect to happen or for the change to be rejected.
> -
> -The callbacks are named and associated with a function using the
> -U_BOOT_ENV_CALLBACK macro in your board or driver code.
> -
> -These callbacks are associated with variables in one of two ways.  The
> -static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC
> -in the board configuration to a string that defines a list of
> -associations.  The list must be in the following format:
> -
> -	entry = variable_name[:callback_name]
> -	list = entry[,list]
> -
> -If the callback name is not specified, then the callback is deleted.
> -Spaces are also allowed anywhere in the list.
> -
> -Callbacks can also be associated by defining the ".callbacks" variable
> -with the same list format above.  Any association in ".callbacks" will
> -override any association in the static list. You can define
> -CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the
> -".callbacks" environment variable in the default or embedded environment.
> -
> -If CONFIG_REGEX is defined, the variable_name above is evaluated as a
> -regular expression. This allows multiple variables to be connected to
> -the same callback without explicitly listing them all out.
> -
> -The signature of the callback functions is:
> -
> -    int callback(const char *name, const char *value, enum env_op op, int flags)
> -
> -* name - changed environment variable
> -* value - new value of the environment variable
> -* op - operation (create, overwrite, or delete)
> -* flags - attributes of the environment variable change, see flags H_* in
> -  include/search.h
> -
> -The return value is 0 if the variable change is accepted and 1 otherwise.
> -
> -
>   Note for Redundant Ethernet Interfaces:
>   =======================================
>
> diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst
> new file mode 100644
> index 00000000000..7a733b44556
> --- /dev/null
> +++ b/doc/usage/environment.rst
> @@ -0,0 +1,381 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Environment Variables
> +=====================
> +
> +U-Boot supports user configuration using Environment Variables which

environment variables

> +can be made persistent by saving to Flash memory.

This is wrong we support having the environment in many different places.

> +
> +Environment Variables are set using "setenv", printed using

variables

> +"printenv", and saved to Flash using "saveenv". Using "setenv"

%s/to Flash//

> +without a value can be used to delete a variable from the
> +environment. As long as you don't save the environment you are
> +working with an in-memory copy. In case the Flash area containing the
> +environment is erased by accident, a default environment is provided.
> +

In a later series we should create separate man-pages for these commands
as well as for the 'env' command.

> +Some configuration options can be set using Environment Variables.

device configuration options

environment variables

> +
> +List of environment variables (most likely not complete):
> +
> +baudrate
> +    see CONFIG_BAUDRATE

Uncommented references to Kconfig variables are not helpful if the
Kconfig variables themselves are not described in the HTML documentation.

How about:

This environment variable is used to set the baudrate of the UART. It
defaults to CONFIG_BAUDRATE (which defaults to 115200).

> +
> +bootdelay

Delay before automatically running bootcmd. During this time the user
can choose to enter the shell (or the boot menu if
CONFIG_AUTOBOOT_MENU_SHOW=y).

- 0 to autoboot with no delay, but you can stop it by key input.
- -1 to disable autoboot.
- -2 to autoboot with no delay and not check for abort

The default value is defined by CONFIG_BOOTDELAY.

The value of 'bootdelay' is overriden by the /config/bootdelay value in
the device-tree if CONFIG_OF_CONTROL=y.

Does it really make sense that the devicetree overrides the user setting?

> +    see CONFIG_BOOTDELAY
> +
> +bootcmd
> +    see CONFIG_BOOTCOMMAND

The command that is run if the user does not enter the shell during the
boot delay.

> +
> +bootargs
> +    Boot arguments when booting an RTOS image

I would not refer to Linux as an RTOS. How about:

Command line arguments passed when booting a binary image.

> +
> +bootfile
> +    Name of the image to load with TFTP

%s/image/file/

The tftp command can be used to load any file not only images.

> +
> +bootm_low
> +    Memory range available for image processing in the bootm
> +    command can be restricted. This variable is given as
> +    a hexadecimal number and defines lowest address allowed
> +    for use by the bootm command. See also "bootm_size"
> +    environment variable. Address defined by "bootm_low" is
> +    also the base of the initial memory mapping for the Linux
> +    kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
> +    bootm_mapsize.
> +
> +bootm_mapsize
> +    Size of the initial memory mapping for the Linux kernel.
> +    This variable is given as a hexadecimal number and it
> +    defines the size of the memory region starting at base
> +    address bootm_low that is accessible by the Linux kernel
> +    during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
> +    as the default value if it is defined, and bootm_size is
> +    used otherwise.
> +
> +bootm_size
> +    Memory range available for image processing in the bootm
> +    command can be restricted. This variable is given as
> +    a hexadecimal number and defines the size of the region
> +    allowed for use by the bootm command. See also "bootm_low"
> +    environment variable.
> +
> +bootstopkeysha256, bootdelaykey, bootstopkey
> +    See README.autoboot

This document should also be moved to make it linkable.

> +
> +updatefile
> +    Location of the software update file on a TFTP server, used
> +    by the automatic software update feature. Please refer to
> +    documentation in doc/README.update for more details.
> +
> +autoload
> +    if set to "no" (any string beginning with 'n'),
> +    "bootp" will just load perform a lookup of the

The dhcp command is also affected.

> +    configuration from the BOOTP server, but not try to
> +    load any image using TFTP
> +
> +autostart
> +    if set to "yes", an image loaded using the "bootp",
> +    "rarpboot", "tftpboot" or "diskboot" commands will
> +    be automatically started (by internally calling
> +    "bootm")

How about the dhcp command?

> +
> +    If set to "no", a standalone image passed to the
> +    "bootm" command will be copied to the load address
> +    (and eventually uncompressed), but NOT be started.
> +    This can be used to load and uncompress arbitrary
> +    data.
> +
> +fdt_high
> +    if set this restricts the maximum address that the
> +    flattened device tree will be copied into upon boot.
> +    For example, if you have a system with 1 GB memory
> +    at physical address 0x10000000, while Linux kernel
> +    only recognizes the first 704 MB as low memory, you
> +    may need to set fdt_high as 0x3C000000 to have the
> +    device tree blob be copied to the maximum address
> +    of the 704 MB low memory, so that Linux kernel can
> +    access it during the boot procedure.
> +
> +    If this is set to the special value 0xFFFFFFFF then

0xffffffff on 32 bit
0xffffffffffffffff on 64 bit

> +    the fdt will not be copied at all on boot.  For this
> +    to work it must reside in writable memory, have
> +    sufficient padding on the end of it for u-boot to
> +    add the information it needs into it, and the memory
> +    must be accessible by the kernel.
> +
> +fdtcontroladdr
> +    if set this is the address of the control flattened
> +    device tree used by U-Boot when CONFIG_OF_CONTROL is
> +    defined.
> +
> +initrd_high
> +    restrict positioning of initrd images:
> +    If this variable is not set, initrd images will be
> +    copied to the highest possible address in RAM; this
> +    is usually what you want since it allows for
> +    maximum initrd size. If for some reason you want to
> +    make sure that the initrd image is loaded below the
> +    CONFIG_SYS_BOOTMAPSZ limit, you can set this environment
> +    variable to a value of "no" or "off" or "0".
> +    Alternatively, you can set it to a maximum upper
> +    address to use (U-Boot will still check that it
> +    does not overwrite the U-Boot stack and data).
> +
> +    For instance, when you have a system with 16 MB
> +    RAM, and want to reserve 4 MB from use by Linux,
> +    you can do this by adding "mem=12M" to the value of
> +    the "bootargs" variable. However, now you must make
> +    sure that the initrd image is placed in the first
> +    12 MB as well - this can be done with::
> +
> +        setenv initrd_high 00c00000
> +
> +    If you set initrd_high to 0xFFFFFFFF, this is an

0xffffffff on 32 bit
0xffffffffffffffff on 64 bit

> +    indication to U-Boot that all addresses are legal
> +    for the Linux kernel, including addresses in flash
> +    memory. In this case U-Boot will NOT COPY the
> +    ramdisk at all. This may be useful to reduce the
> +    boot time on your system, but requires that this
> +    feature is supported by your Linux kernel.
> +
> +ipaddr
> +    IP address; needed for tftpboot command

This address is also used by the tftp command.

> +
> +loadaddr
> +    Default load address for commands like "bootp",
> +    "rarpboot", "tftpboot", "loadb" or "diskboot"
> +
> +loads_echo
> +    see CONFIG_LOADS_ECHO
> +
> +serverip
> +    TFTP server IP address; needed for tftpboot command

and tftp command

> +
> +bootretry
> +    see CONFIG_BOOT_RETRY_TIME
> +
> +bootdelaykey
> +    see CONFIG_AUTOBOOT_DELAY_STR
> +
> +bootstopkey
> +    see CONFIG_AUTOBOOT_STOP_STR
> +
> +ethprime
> +    controls which interface is used first.
> +
> +ethact
> +    controls which interface is currently active.

%s/interface/network interface/

> +    For example you can do the following::
> +
> +    => setenv ethact FEC
> +    => ping 192.168.0.1 # traffic sent on FEC
> +    => setenv ethact SCC
> +    => ping 10.0.0.1 # traffic sent on SCC
> +
> +ethrotate
> +    When set to "no" U-Boot does not go through all

set to "no" or not set?

> +    available network interfaces.
> +    It just stays at the currently selected interface.
> +
> +netretry
> +    When set to "no" each network operation will
> +    either succeed or fail without retrying.
> +    When set to "once" the network operation will
> +    fail when all the available network interfaces
> +    are tried once without success.
> +    Useful on scripts which control the retry operation
> +    themselves.
> +
> +npe_ucode
> +    set load address for the NPE microcode

This variable is not used. Please, remove it.

> +
> +silent_linux
> +    If set then Linux will be told to boot silently, by
> +    changing the console to be empty. If "yes" it will be

by adding 'console=' to the Linux command line.

> +    made silent. If "no" it will not be made silent. If
> +    unset, then it will be made silent if the U-Boot console
> +    is silent.
> +
> +tftpsrcp
> +    If this is set, the value is used for TFTP's
> +    UDP source port.
> +
> +tftpdstp
> +    If this is set, the value is used for TFTP's UDP
> +    destination port instead of the Well Know Port 69.

%s/Well Known Port/default port/

> +
> +tftpblocksize
> +    Block size to use for TFTP transfers; if not set,
> +    we use the TFTP server's default block size
> +
> +tftptimeout
> +    Retransmission timeout for TFTP packets (in milli-
> +    seconds, minimum value is 1000 = 1 second). Defines
> +    when a packet is considered to be lost so it has to
> +    be retransmitted. The default is 5000 = 5 seconds.
> +    Lowering this value may make downloads succeed
> +    faster in networks with high packet loss rates or
> +    with unreliable TFTP servers.
> +
> +tftptimeoutcountmax
> +    maximum count of TFTP timeouts (no
> +    unit, minimum value = 0). Defines how many timeouts
> +    can happen during a single file transfer before that
> +    transfer is aborted. The default is 10, and 0 means
> +    'no timeouts allowed'. Increasing this value may help
> +    downloads succeed with high packet loss rates, or with
> +    unreliable TFTP servers or client hardware.
> +
> +tftpwindowsize
> +    if this is set, the value is used for TFTP's
> +    window size as described by RFC 7440.
> +    This means the count of blocks we can receive before
> +    sending ack to server.
> +
> +vlan
> +    When set to a value < 4095 the traffic over
> +    Ethernet is encapsulated/received over 802.1q
> +    VLAN tagged frames.
> +
> +bootpretryperiod
> +    Period during which BOOTP/DHCP sends retries.
> +    Unsigned value, in milliseconds. If not set, the period will
> +    be either the default (28000), or a value based on
> +    CONFIG_NET_RETRY_COUNT, if defined. This value has
> +    precedence over the valu based on CONFIG_NET_RETRY_COUNT.
> +
> +memmatches
> +    Number of matches found by the last 'ms' command, in hex
> +
> +memaddr
> +    Address of the last match found by the 'ms' command, in hex,
> +    or 0 if none
> +
> +mempos
> +    Index position of the last match found by the 'ms' command,
> +    in units of the size (.b, .w, .l) of the search
> +
> +zbootbase
> +    (x86 only) Base address of the bzImage 'setup' block
> +
> +zbootaddr
> +    (x86 only) Address of the loaded bzImage, typically
> +    BZIMAGE_LOAD_ADDR which is 0x100000
> +
> +
> +Image locations
> +---------------
> +
> +The following image location variables contain the location of images
> +used in booting. The "Image" column gives the role of the image and is
> +not an environment variable name. The other columns are environment
> +variable names. "File Name" gives the name of the file on a TFTP
> +server, "RAM Address" gives the location in RAM the image will be
> +loaded to, and "Flash Location" gives the image's address in NOR
> +flash or offset in NAND flash.
> +
> +*Note* - these variables don't have to be defined for all boards, some
> +boards currently use other variables for these purposes, and some
> +boards use these variables for other purposes.
> +
> +================= ============== ================ ==============
> +Image             File Name      RAM Address      Flash Location
> +================= ============== ================ ==============
> +u-boot            u-boot         u-boot_addr_r    u-boot_addr
> +Linux kernel      bootfile       kernel_addr_r    kernel_addr
> +device tree blob  fdtfile        fdt_addr_r       fdt_addr
> +ramdisk           ramdiskfile    ramdisk_addr_r   ramdisk_addr
> +================= ============== ================ ==============
> +
> +
> +Automatically updated variables
> +-------------------------------
> +
> +The following environment variables may be used and automatically
> +updated by the network boot commands ("bootp" and "rarpboot"),
> +depending the information provided by your boot server:
> +
> +=========  ===================================================
> +Variable   Notes
> +=========  ===================================================
> +bootfile   see above
> +dnsip      IP address of your Domain Name Server
> +dnsip2     IP address of your secondary Domain Name Server
> +gatewayip  IP address of the Gateway (Router) to use
> +hostname   Target hostname
> +ipaddr     See above
> +netmask    Subnet Mask
> +rootpath   Pathname of the root filesystem on the NFS server
> +serverip   see above
> +=========  ===================================================
> +
> +
> +Special environment variables
> +-----------------------------
> +
> +There are two special Environment Variables:
> +
> +serial#
> +    contains hardware identification information such as type string and/or
> +    serial number
> +ethaddr
> +    Ethernet address

If CONFIG_REGEX=y, also eth*addr (where * is an integer).

> +
> +These variables can be set only once (usually during manufacturing of
> +the board). U-Boot refuses to delete or overwrite these variables
> +once they have been set once.

%s/once./if CONFIG_ENV_OVERWRITE is not set in the board configuration./g

> +
> +Also:
> +
> +ver
> +    Contains the U-Boot version string as printed
> +    with the "version" command. This variable is
> +    readonly (see CONFIG_VERSION_VARIABLE).
> +
> +Please note that changes to some configuration parameters may take
> +only effect after the next boot (yes, that's just like Windoze :-).

Please, avoid pejorative language:

%s/Windoze :/Windows/

> +
> +
> +Callback functions for environment variables
> +--------------------------------------------

This section does not fit into doc/usage. Please, move it to doc/develop.

Best regards

Heinrich

> +
> +For some environment variables, the behavior of u-boot needs to change
> +when their values are changed.  This functionality allows functions to
> +be associated with arbitrary variables.  On creation, overwrite, or
> +deletion, the callback will provide the opportunity for some side
> +effect to happen or for the change to be rejected.
> +
> +The callbacks are named and associated with a function using the
> +U_BOOT_ENV_CALLBACK macro in your board or driver code.
> +
> +These callbacks are associated with variables in one of two ways.  The
> +static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC
> +in the board configuration to a string that defines a list of
> +associations.  The list must be in the following format::
> +
e> +    entry = variable_name[:callback_name]
> +    list = entry[,list]
> +
> +If the callback name is not specified, then the callback is deleted.
> +Spaces are also allowed anywhere in the list.
> +
> +Callbacks can also be associated by defining the ".callbacks" variable
> +with the same list format above.  Any association in ".callbacks" will
> +override any association in the static list. You can define
> +CONFIG_ENV_CALLBACK_LIST_DEFAULT to a list (string) to define the
> +".callbacks" environment variable in the default or embedded environment.
> +
> +If CONFIG_REGEX is defined, the variable_name above is evaluated as a
> +regular expression. This allows multiple variables to be connected to
> +the same callback without explicitly listing them all out.
> +
> +The signature of the callback functions is::
> +
> +    int callback(const char *name, const char *value, enum env_op op, int flags)
> +
> +* name - changed environment variable
> +* value - new value of the environment variable
> +* op - operation (create, overwrite, or delete)
> +* flags - attributes of the environment variable change, see flags H_* in
> +  include/search.h
> +
> +The return value is 0 if the variable change is accepted and 1 otherwise.
>

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 4/7] sandbox: Use a text-based environment
  2021-10-19 22:44 ` [PATCH v9 4/7] sandbox: Use a text-based environment Simon Glass
@ 2021-10-20  6:58   ` Alexander Dahl
  0 siblings, 0 replies; 38+ messages in thread
From: Alexander Dahl @ 2021-10-20  6:58 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Marek Behún, Rasmus Villemoes,
	Heinrich Schuchardt, Tom Rini, Wolfgang Denk

Hello Simon,

Am Tue, Oct 19, 2021 at 04:44:19PM -0600 schrieb Simon Glass:
> Use a text file for the environment instead of the #define settings.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Marek Behún <marek.behun@nic.cz>
> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Add new patch to use a text-based environment for sandbox
> 
>  board/sandbox/sandbox.env | 25 +++++++++++++++++++++++++
>  include/configs/sandbox.h | 29 -----------------------------
>  2 files changed, 25 insertions(+), 29 deletions(-)
>  create mode 100644 board/sandbox/sandbox.env
> 
> diff --git a/board/sandbox/sandbox.env b/board/sandbox/sandbox.env
> new file mode 100644
> index 00000000000..0f8d95b8db0
> --- /dev/null
> +++ b/board/sandbox/sandbox.env
> @@ -0,0 +1,25 @@
> +stdin=serial
> +#ifdef CONFIG_SANDBOX_SDL
> +stdin+=,cros-ec-keyb,usbkbd
> +#endif
> +stdout=serial,vidconsole
> +stderr=serial,vidconsole
> +
> +ethaddr=00:00:11:22:33:44
> +eth2addr=00:00:11:22:33:48
> +eth3addr=00:00:11:22:33:45
> +eth4addr=00:00:11:22:33:48
> +eth5addr=00:00:11:22:33:46
> +eth6addr=00:00:11:22:33:47

These MAC addresses use the OUI 00:00:11 which is assigned to NORMEREL
SYSTEMES, a company based in France.  I doubt U-Boot is allowed to use
addresses from that block, and would prefer using a locally
administered address here, and set the second bit. Thus
02:00:11:xx:xx:xx would be okay for example.

> +ipaddr=1.2.3.4

Same here, this is a globally reachable IP address, which U-Boot
probably is not allowed to use.  According to RFC 5737 there are two
IPv4 address blocks for documentational use:

“The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in
documentation.”

Greets
Alex

> +
> +/*
> + * These are used for distro boot which is not supported. But once bootmethod
> + * is provided these will be used again.
> + */
> +bootm_size=0x10000000
> +kernel_addr_r=0x1000000
> +fdt_addr_r=0xc00000
> +ramdisk_addr_r=0x2000000
> +scriptaddr=0x1000
> +pxefile_addr_r=0x2000
> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
> index c19232f202f..c703a1330c0 100644
> --- a/include/configs/sandbox.h
> +++ b/include/configs/sandbox.h
> @@ -64,37 +64,8 @@
>  #define CONFIG_LCD_BMP_RLE8
>  
>  #define CONFIG_KEYBOARD
> -
> -#define SANDBOX_SERIAL_SETTINGS		"stdin=serial,cros-ec-keyb,usbkbd\0" \
> -					"stdout=serial,vidconsole\0" \
> -					"stderr=serial,vidconsole\0"
> -#else
> -#define SANDBOX_SERIAL_SETTINGS		"stdin=serial\0" \
> -					"stdout=serial,vidconsole\0" \
> -					"stderr=serial,vidconsole\0"
>  #endif
>  
> -#define SANDBOX_ETH_SETTINGS		"ethaddr=00:00:11:22:33:44\0" \
> -					"eth2addr=00:00:11:22:33:48\0" \
> -					"eth3addr=00:00:11:22:33:45\0" \
> -					"eth4addr=00:00:11:22:33:48\0" \
> -					"eth5addr=00:00:11:22:33:46\0" \
> -					"eth6addr=00:00:11:22:33:47\0" \
> -					"ipaddr=1.2.3.4\0"
> -
> -#define MEM_LAYOUT_ENV_SETTINGS \
> -	"bootm_size=0x10000000\0" \
> -	"kernel_addr_r=0x1000000\0" \
> -	"fdt_addr_r=0xc00000\0" \
> -	"ramdisk_addr_r=0x2000000\0" \
> -	"scriptaddr=0x1000\0" \
> -	"pxefile_addr_r=0x2000\0"
> -
> -#define CONFIG_EXTRA_ENV_SETTINGS \
> -	SANDBOX_SERIAL_SETTINGS \
> -	SANDBOX_ETH_SETTINGS \
> -	MEM_LAYOUT_ENV_SETTINGS
> -
>  #ifndef CONFIG_SPL_BUILD
>  #define CONFIG_SYS_IDE_MAXBUS		1
>  #define CONFIG_SYS_ATA_IDE0_OFFSET	0
> -- 
> 2.33.0.1079.g6e70778dc9-goog
> 

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-19 22:44 ` [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
@ 2021-10-21  9:50   ` Wolfgang Denk
  2021-10-21 12:23     ` Tom Rini
  0 siblings, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-21  9:50 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Marek Behún, Rasmus Villemoes,
	Heinrich Schuchardt, Tom Rini, Joe Hershberger

Dear Simon,

In message <20211019164418.v9.3.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you wrote:
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
>
> Add a feature that brings in a .env file associated with the board
> config, if present. To use it, create a file in a board/<vendor>
> directory, typically called <board>.env and controlled by the
> CONFIG_ENV_SOURCE_FILE option.
>
> The environment variables should be of the form "var=value". Values can
> extend to multiple lines. See the README under 'Environment Variables:'
> for more information and an example. Note that variables names may
> not end in + due to the += syntax below.

I still object to placing new, arbitrary restrictions on what may or
may not be used in environment variable names.

We have discussed alternative implementations, and trivial changes
like using "=+" instead of "+=" as append operator do not require
such restictions.

Thus, and only for the restictions on variable names:

Naked-by: Wolfgang Denk <wd@denx.de>

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@denx.de
There is is no reason for any individual to have a computer in  their
home.      -- Ken Olsen (President of Digital Equipment Corporation),
              Convention of the World Future Society, in Boston, 1977

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21  9:50   ` Wolfgang Denk
@ 2021-10-21 12:23     ` Tom Rini
  2021-10-21 13:06       ` Wolfgang Denk
  0 siblings, 1 reply; 38+ messages in thread
From: Tom Rini @ 2021-10-21 12:23 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Simon Glass, U-Boot Mailing List, Marek Behún,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 1855 bytes --]

On Thu, Oct 21, 2021 at 11:50:02AM +0200, Wolfgang Denk wrote:
> Dear Simon,
> 
> In message <20211019164418.v9.3.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid> you wrote:
> > At present U-Boot environment variables, and thus scripts, are defined
> > by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> > to this file and dealing with quoting and newlines is harder than it
> > should be. It would be better if we could just type the script into a
> > text file and have it included by U-Boot.
> >
> > Add a feature that brings in a .env file associated with the board
> > config, if present. To use it, create a file in a board/<vendor>
> > directory, typically called <board>.env and controlled by the
> > CONFIG_ENV_SOURCE_FILE option.
> >
> > The environment variables should be of the form "var=value". Values can
> > extend to multiple lines. See the README under 'Environment Variables:'
> > for more information and an example. Note that variables names may
> > not end in + due to the += syntax below.
> 
> I still object to placing new, arbitrary restrictions on what may or
> may not be used in environment variable names.
> 
> We have discussed alternative implementations, and trivial changes
> like using "=+" instead of "+=" as append operator do not require
> such restictions.
> 
> Thus, and only for the restictions on variable names:
> 
> Naked-by: Wolfgang Denk <wd@denx.de>

Do you have any other feedback on the entire rest of the series?
Because I'm not sure the benefit of "we can still support '+' at the end
of a variable name, if anyone uses that" outweighs "we can more easily
append variables in constructing our environment without relying on
uncommon operators".  To me "=+" as the append syntax is worse than "no
+ at the end of your variables".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 12:23     ` Tom Rini
@ 2021-10-21 13:06       ` Wolfgang Denk
  2021-10-21 13:25         ` Marek Behún
  0 siblings, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-21 13:06 UTC (permalink / raw)
  To: Tom Rini
  Cc: Simon Glass, U-Boot Mailing List, Marek Behún,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Dear Tom,

In message <20211021122325.GX7964@bill-the-cat> you wrote:
> 
> Do you have any other feedback on the entire rest of the series?

I already wrote that I support the concept, and the few nit I saw
have been fixed, I think.  Except this unneeded breaking of backward
compatibility.

> Because I'm not sure the benefit of "we can still support '+' at the end
> of a variable name, if anyone uses that" outweighs "we can more easily
> append variables in constructing our environment without relying on
> uncommon operators".

We introduce a new feature here. Defining an append operator is a
convenience thing. It could probably also solved using the
preprocessor, likely in a more ugly way.

In any case, the feature is new, and the operator is new.

For the implementation it does not matter if we define this operator
as "+=" or '=+" or "=." or something else.

the only difference is that any ioperator starting with an equal
sign is inherently backward compatible without need for arbitrary
new restrictions.

> To me "=+" as the append syntax is worse than "no
> + at the end of your variables".

In which way is it worse? For esthetic reasons?

I confirm that '+=' looks better.  But '+=" is technically broken.



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@denx.de
Brain: an apparatus with which we think we think.    - Ambrose Bierce

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 13:06       ` Wolfgang Denk
@ 2021-10-21 13:25         ` Marek Behún
  2021-10-21 13:28           ` Marek Behún
  0 siblings, 1 reply; 38+ messages in thread
From: Marek Behún @ 2021-10-21 13:25 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Tom Rini, Simon Glass, U-Boot Mailing List, Rasmus Villemoes,
	Heinrich Schuchardt, Joe Hershberger

Hello,

On Thu, 21 Oct 2021 15:06:51 +0200
Wolfgang Denk <wd@denx.de> wrote:

> I confirm that '+=' looks better.  But '+=" is technically broken.

a bit of my opinion:
I think =+ will confuse far more people than + as last character of var
name working weirdly. But I also think that + should be supported as
last character. Therefore I propose backslash escaping in variable name,
i.e.
  var+=value
appends value to var, while
  var\+=value
sets variable with name "var+"

Marek

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 13:25         ` Marek Behún
@ 2021-10-21 13:28           ` Marek Behún
  2021-10-21 15:12             ` Wolfgang Denk
  2021-10-21 15:59             ` Simon Glass
  0 siblings, 2 replies; 38+ messages in thread
From: Marek Behún @ 2021-10-21 13:28 UTC (permalink / raw)
  To: Wolfgang Denk, Simon Glass
  Cc: Tom Rini, U-Boot Mailing List, Rasmus Villemoes,
	Heinrich Schuchardt, Joe Hershberger

On Thu, 21 Oct 2021 15:25:37 +0200
Marek Behún <marek.behun@nic.cz> wrote:

> Hello,
> 
> On Thu, 21 Oct 2021 15:06:51 +0200
> Wolfgang Denk <wd@denx.de> wrote:
> 
> > I confirm that '+=' looks better.  But '+=" is technically broken.  
> 
> a bit of my opinion:
> I think =+ will confuse far more people than + as last character of var
> name working weirdly. But I also think that + should be supported as
> last character. Therefore I propose backslash escaping in variable name,
> i.e.
>   var+=value
> appends value to var, while
>   var\+=value
> sets variable with name "var+"
> 
> Marek

Also, I think that it would be better if spaces and tabs were allowed
to indent the .env file, i.e.

	var_a	=	3
	var_bcd	=	7

should set "var_a" to "3", "var_bcd" to "7".

If special character are needed in either name or value, they could be
escaped and/or quoted.

Marek

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 0/7] env: Allow environment in text files
  2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
                   ` (6 preceding siblings ...)
  2021-10-19 22:44 ` [PATCH v9 7/7] bootm: Tidy up use of autostart env var Simon Glass
@ 2021-10-21 14:02 ` Tom Rini
  7 siblings, 0 replies; 38+ messages in thread
From: Tom Rini @ 2021-10-21 14:02 UTC (permalink / raw)
  To: Simon Glass, u-boot-custodians, u-boot-board-maintainers
  Cc: U-Boot Mailing List, Marek Behún, Rasmus Villemoes,
	Heinrich Schuchardt, Wolfgang Denk, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 7698 bytes --]

On Tue, Oct 19, 2021 at 04:44:15PM -0600, Simon Glass wrote:

> One barrier to completing the 7-year-long Kconfig migration is that
> the default environment is implemented using ad-hoc CONFIG options.
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS.
> 
> It is not really feasible to move the environment to Kconfig as it is
> hundreds of lines of text in some cases.
> 
> Even considering the current situation, it is painful to add large
> amounts of text to the config-header file and dealing with quoting and
> newlines is harder than it should be. It would be better if we could just
> type the script into a text file and have it included by U-Boot.
> 
> This is already supported by the CONFIG_USE_DEFAULT_ENV_FILE feature. but
> that does not support use of CONFIG options or comments, so is best suited
> for use by other build systems wanting to define the U-Boot environment.
> 
> Add a feature that brings in a .env file associated with the board
> config, if present. To use it, create a file board/<vendor>/<board>.env or
> use CONFIG_ENV_SOURCE_FILE to set a filename.
> 
> The environment variables should be of the form "var=value". Values can
> extend to multiple lines. This series converts the existing environment
> documentation to rST and updates it to explain how to use this.
> 
> Note: this series was originally sent eight years ago:
> 
> https://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-sjg@chromium.org/
> 
> It has been updated to work with Kconfig, etc. Some review comments in
> that patch were infeasible so I have not addressed them. I would like
> this series to be considered independently, on its merits.
> 
> Rather than deal with the complexity of rewriting the distro-boot
> script, this is disabled for sandbox. The forthcoming bootmethod approach
> should provide the same functionality without needing the complex
> scripting in the environment.
> 
> Migration needs more thought, although it can be done later. It may be
> possible to do migrate automatically, using buildman to extract the
> built-in environmnent from the ELF file.
> 
> This would produce a pretty ugly conversion though, since it would drop
> all the intermediate variables used to create the environment.
> 
> Better would be to parse the config.h file, figure out the components of
> CONFIG_EXTRA_ENV_SETTINGS then output these as separate pieces in the
> file. It is not clear how easy that would be, nor whether the result would
> be very pretty. Also the __stringify() macro needs to be handled somehow.
> 
> This series is available at u-boot-dm/env-working
> 
> Comments welcome.
> 
> Changes in v9:
> - Drop mention of other strange characters
> - Clarify that the + restriction is on the variable name not its value
> - Add some tests for the script
> - Deal with leading tabs
> - Squash indentation down to one space
> - Convert newlines within strings to spaces, which seems more consistent
> - Handle appending an empty string to an empty var
> - Fix blank line between tags
> - Fix typo in commit message
> - More bikeshedding on env_get_autostart()
> - Fix '<vendor><board>' in cover letter
> - Use env_get_yesno() in env_get_autostart() and update docs
> 
> Changes in v8:
> - Update commit message to avoid mentioning the 'env' subdirectory
> - Update commit message to mention the + restriction, etc.
> - Overwrite the env file each time, to avoid incremental-build problems
> - Fix ambiguity about what is ignored
> - Go into more detail about the change of behaviour with autostart
> 
> Changes in v7:
> - Use 'env' basename instead of 'environment' for intermediate output files
> - Show a message indicating the source text file being used
> - Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined
> - Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name
> - Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty
> - Rewrite the documentation
> - Drop the use of common.env
> - Update awk script to output the whole CONFIG string, or just a comment
> - Add new patch to explain the relationship with DEFAULT_ENV_FILE
> - A few more tweaks
> - Update the cover letter
> 
> Changes in v6:
> - Move all updates to a separate patch
> - Combine the two env2string.awk patches into one
> - Move all updates to a separate patch
> - More updates and improvements
> - Add new patch to tidy up use of autostart env var
> 
> Changes in v5:
> - Minor updates as suggested by Wolfgang
> - Explain how to include the common.env file
> - Explain why variables starting with _ , and / are not supported
> - Expand the definition of how to declare an environment variable
> - Explain what happens to empty variables
> - Update maintainer
> - Move use of += to this patch
> - Explain that environment variables may not end in +
> - Minor updates as suggested by Wolfgang
> 
> Changes in v4:
> - Add new patch to move environment documentation to rST
> - Move this from being part of configuring U-Boot to part of building it
> - Don't put the environment in autoconf.mk as it is not needed
> - Add documentation in rST format instead of README
> - Drop mention of import/export
> - Update awk script to ignore blank lines, as generated by clang
> - Add documentation in rST format instead of README
> - Add new patch to move environment documentation to rST
> 
> Changes in v3:
> - Adjust Makefile to generate the .inc and .h files in separate fules
> - Add more detail in the README about the format of .env files
> - Improve the comment about " in the awk script
> - Correctly terminate environment files with \n
> - Define __UBOOT_CONFIG__ when collecting environment files
> - Add new patch to use a text-based environment for sandbox
> 
> Changes in v2:
> - Move .env file from include/configs to board/
> - Use awk script to process environment since it is much easier on the brain
> - Add information and updated example script to README
> - Add dependency rule so that the environment is rebuilt when it changes
> - Add separate patch to enable C preprocessor for environment files
> - Enable var+=value form to simplify composing variables in multiple steps
> 
> Simon Glass (7):
>   sandbox: Drop distro_boot
>   doc: Move environment documentation to rST
>   env: Allow U-Boot scripts to be placed in a .env file
>   sandbox: Use a text-based environment
>   doc: Mention CONFIG_DEFAULT_ENV_FILE
>   doc: Improve environment documentation
>   bootm: Tidy up use of autostart env var
> 
>  MAINTAINERS               |   7 +
>  Makefile                  |  66 ++++-
>  README                    | 328 -------------------------
>  board/sandbox/sandbox.env |  25 ++
>  cmd/bootm.c               |   4 +-
>  cmd/elf.c                 |   3 +-
>  common/bootm_os.c         |   5 +-
>  config.mk                 |   2 +
>  doc/usage/environment.rst | 490 ++++++++++++++++++++++++++++++++++++++
>  doc/usage/index.rst       |   1 +
>  env/Kconfig               |  18 ++
>  env/common.c              |   5 +
>  env/embedded.c            |   1 +
>  include/configs/sandbox.h |  40 ----
>  include/env.h             |   7 +
>  include/env_default.h     |  11 +
>  scripts/env2string.awk    |  71 ++++++
>  test/py/tests/test_env.py |  93 ++++++++
>  18 files changed, 799 insertions(+), 378 deletions(-)
>  create mode 100644 board/sandbox/sandbox.env
>  create mode 100644 doc/usage/environment.rst
>  create mode 100644 scripts/env2string.awk

Cc'ing the other lists...

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 13:28           ` Marek Behún
@ 2021-10-21 15:12             ` Wolfgang Denk
  2021-10-21 15:18               ` Tom Rini
  2021-10-21 15:59             ` Simon Glass
  1 sibling, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-21 15:12 UTC (permalink / raw)
  To: Marek Behún
  Cc: Simon Glass, Tom Rini, U-Boot Mailing List, Rasmus Villemoes,
	Heinrich Schuchardt, Joe Hershberger

Dear Marek,

In message <20211021152831.15524883@thinkpad> you wrote:
>
>
> > I think =+ will confuse far more people than + as last character of var

I still fail to see why '=+' could be confusing if properly
documented to be the append operator.

I mean, it is not a new invention of mine.

OpenEmbedded / Yocto uses '=+' a lot, like in

	meta/recipes-kernel/dtc/dtc.inc:

	PACKAGES =+ "${PN}-misc"

Actually they use both '+=' and '=+', like

	RESULT+=${ERRORS}


> > name working weirdly. But I also think that + should be supported as
> > last character. Therefore I propose backslash escaping in variable name,
> > i.e.
> >   var+=value
> > appends value to var, while
> >   var\+=value
> > sets variable with name "var+"

Yes, this is yet another alternative for handling this problem.

> Also, I think that it would be better if spaces and tabs were allowed
> to indent the .env file, i.e.
>
> 	var_a	=	3
> 	var_bcd	=	7
>
> should set "var_a" to "3", "var_bcd" to "7".

Why not...

In the end it boils down that the file format should be properly
defined and have a clear syntax description.  Apparently the
"<name>=<value>\0" format as used in U-Boot persistent storage
should not be taken literally here.


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@denx.de
If you're out of tree, you don't exist.
     - David Woodhouse in <1304620350.2398.29.camel@i7.infradead.org>

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 15:12             ` Wolfgang Denk
@ 2021-10-21 15:18               ` Tom Rini
  0 siblings, 0 replies; 38+ messages in thread
From: Tom Rini @ 2021-10-21 15:18 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Marek Behún, Simon Glass, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Thu, Oct 21, 2021 at 05:12:26PM +0200, Wolfgang Denk wrote:
> Dear Marek,
> 
> In message <20211021152831.15524883@thinkpad> you wrote:
> >
> >
> > > I think =+ will confuse far more people than + as last character of var
> 
> I still fail to see why '=+' could be confusing if properly
> documented to be the append operator.
> 
> I mean, it is not a new invention of mine.
> 
> OpenEmbedded / Yocto uses '=+' a lot, like in
> 
> 	meta/recipes-kernel/dtc/dtc.inc:
> 
> 	PACKAGES =+ "${PN}-misc"
> 
> Actually they use both '+=' and '=+', like
> 
> 	RESULT+=${ERRORS}

The OE example is exactly why I want to avoid =+.  You cannot
interchangeably use += and =+ as they evaluate differently.  See
https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#appending-and-prepending
and that =+ there is the opposite of what we want.  So, more confusion.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 13:28           ` Marek Behún
  2021-10-21 15:12             ` Wolfgang Denk
@ 2021-10-21 15:59             ` Simon Glass
  2021-10-21 16:03               ` Tom Rini
  2021-10-22  8:06               ` Wolfgang Denk
  1 sibling, 2 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-21 15:59 UTC (permalink / raw)
  To: Marek Behún
  Cc: Wolfgang Denk, Tom Rini, U-Boot Mailing List, Rasmus Villemoes,
	Heinrich Schuchardt, Joe Hershberger

Hi Marek,

On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
>
> On Thu, 21 Oct 2021 15:25:37 +0200
> Marek Behún <marek.behun@nic.cz> wrote:
>
> > Hello,
> >
> > On Thu, 21 Oct 2021 15:06:51 +0200
> > Wolfgang Denk <wd@denx.de> wrote:
> >
> > > I confirm that '+=' looks better.  But '+=" is technically broken.
> >
> > a bit of my opinion:
> > I think =+ will confuse far more people than + as last character of var
> > name working weirdly. But I also think that + should be supported as
> > last character. Therefore I propose backslash escaping in variable name,
> > i.e.
> >   var+=value
> > appends value to var, while
> >   var\+=value
> > sets variable with name "var+"

My first preference is to disallow + at the end of an end var. Perhaps
we can start printing a warning if people do it, for a few releases.

My distance second preference is what Marek has here, using a
backslash to escape the + character.

As for =+ ...while I can see how people might parse it (we are setting
the var equal to what it has with an appending string) I think it is a
terrible idea as it is just not what people expect. Also, putting the
+ after the = places (similarly unlikely) restrictions on the
expression.

The current format is basically the same as 'print'. So if I can't
have the first preference, we could ensure that it prints a \ in the
case that the var ends with +

> >
> > Marek
>
> Also, I think that it would be better if spaces and tabs were allowed
> to indent the .env file, i.e.
>
>         var_a   =       3
>         var_bcd =       7
>
> should set "var_a" to "3", "var_bcd" to "7".
>
> If special character are needed in either name or value, they could be
> escaped and/or quoted.

They are allowed in the value but are reduced to a single space in the
front. We need this for multi-line strings (but I'm a bit worried
about it).

We could update it to skip any leading space after the = I think.

I don't like spaces before the = though. It doesn't match the 'print'
output (which has no space) and it is confusing:

fred=echo something; if [
a == b ]; then
fi

We may well have things like this if we try automatic conversion (I
haven't looked though).

I think we need strict rules so it is easy for people to get exactly
the env they want.

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 15:59             ` Simon Glass
@ 2021-10-21 16:03               ` Tom Rini
  2021-10-21 16:51                 ` Simon Glass
                                   ` (2 more replies)
  2021-10-22  8:06               ` Wolfgang Denk
  1 sibling, 3 replies; 38+ messages in thread
From: Tom Rini @ 2021-10-21 16:03 UTC (permalink / raw)
  To: Simon Glass
  Cc: Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
> Hi Marek,
> 
> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
> >
> > On Thu, 21 Oct 2021 15:25:37 +0200
> > Marek Behún <marek.behun@nic.cz> wrote:
> >
> > > Hello,
> > >
> > > On Thu, 21 Oct 2021 15:06:51 +0200
> > > Wolfgang Denk <wd@denx.de> wrote:
> > >
> > > > I confirm that '+=' looks better.  But '+=" is technically broken.
> > >
> > > a bit of my opinion:
> > > I think =+ will confuse far more people than + as last character of var
> > > name working weirdly. But I also think that + should be supported as
> > > last character. Therefore I propose backslash escaping in variable name,
> > > i.e.
> > >   var+=value
> > > appends value to var, while
> > >   var\+=value
> > > sets variable with name "var+"
> 
> My first preference is to disallow + at the end of an end var. Perhaps
> we can start printing a warning if people do it, for a few releases.
> 
> My distance second preference is what Marek has here, using a
> backslash to escape the + character.

How bad does it make the parser look if we allow trailing + in variable
names, by escaping them?  It's seemingly the substantive objection at
this point.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 16:03               ` Tom Rini
@ 2021-10-21 16:51                 ` Simon Glass
  2021-10-22  6:40                 ` Rasmus Villemoes
  2021-10-22  8:08                 ` Wolfgang Denk
  2 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-21 16:51 UTC (permalink / raw)
  To: Tom Rini
  Cc: Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Hi Tom,

On Thu, 21 Oct 2021 at 10:03, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
> > Hi Marek,
> >
> > On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
> > >
> > > On Thu, 21 Oct 2021 15:25:37 +0200
> > > Marek Behún <marek.behun@nic.cz> wrote:
> > >
> > > > Hello,
> > > >
> > > > On Thu, 21 Oct 2021 15:06:51 +0200
> > > > Wolfgang Denk <wd@denx.de> wrote:
> > > >
> > > > > I confirm that '+=' looks better.  But '+=" is technically broken.
> > > >
> > > > a bit of my opinion:
> > > > I think =+ will confuse far more people than + as last character of var
> > > > name working weirdly. But I also think that + should be supported as
> > > > last character. Therefore I propose backslash escaping in variable name,
> > > > i.e.
> > > >   var+=value
> > > > appends value to var, while
> > > >   var\+=value
> > > > sets variable with name "var+"
> >
> > My first preference is to disallow + at the end of an end var. Perhaps
> > we can start printing a warning if people do it, for a few releases.
> >
> > My distance second preference is what Marek has here, using a
> > backslash to escape the + character.
>
> How bad does it make the parser look if we allow trailing + in variable
> names, by escaping them?  It's seemingly the substantive objection at
> this point.

I'm pretty sure we can do it easily enough. I'll take a look when I
get back to this.

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 2/7] doc: Move environment documentation to rST
  2021-10-20  6:38   ` Heinrich Schuchardt
@ 2021-10-22  3:05     ` Simon Glass
  0 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-22  3:05 UTC (permalink / raw)
  To: Heinrich Schuchardt
  Cc: Marek Behún, Rasmus Villemoes, Tom Rini, Wolfgang Denk,
	U-Boot Mailing List

Hi Heinrich,

On Wed, 20 Oct 2021 at 00:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 10/20/21 00:44, Simon Glass wrote:
> > Move this from the README to rST format.
> >
> > Drop i2cfast since it is obviously obsolete and breaks the formatting.
> > Other changes and improvements are in a following patch.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Acked-by: Marek Behún <marek.behun@nic.cz>
>
> This patch leads to a build error for 'make htmldocs':
>
> doc/usage/environment.rst:document isn't included in any toctree
>
> Please add the file to doc/usage/index.rst.
>
> > ---
> >
> > (no changes since v6)
> >
> > Changes in v6:
> > - Move all updates to a separate patch
> >
> > Changes in v5:
> > - Minor updates as suggested by Wolfgang
> >
> > Changes in v4:
> > - Add new patch to move environment documentation to rST
> >
> >   README                    | 328 --------------------------------
> >   doc/usage/environment.rst | 381 ++++++++++++++++++++++++++++++++++++++
> >   2 files changed, 381 insertions(+), 328 deletions(-)
> >   create mode 100644 doc/usage/environment.rst
> >

Thanks for your comments on this. I'll add another patch with these.

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 16:03               ` Tom Rini
  2021-10-21 16:51                 ` Simon Glass
@ 2021-10-22  6:40                 ` Rasmus Villemoes
  2021-10-24 19:54                   ` Simon Glass
  2021-10-22  8:08                 ` Wolfgang Denk
  2 siblings, 1 reply; 38+ messages in thread
From: Rasmus Villemoes @ 2021-10-22  6:40 UTC (permalink / raw)
  To: Tom Rini, Simon Glass
  Cc: Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Heinrich Schuchardt, Joe Hershberger

On 21/10/2021 18.03, Tom Rini wrote:
> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
>> Hi Marek,
>>
>> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
>>>
>>> On Thu, 21 Oct 2021 15:25:37 +0200
>>> Marek Behún <marek.behun@nic.cz> wrote:
>>>
>>>> Hello,
>>>>
>>>> On Thu, 21 Oct 2021 15:06:51 +0200
>>>> Wolfgang Denk <wd@denx.de> wrote:
>>>>
>>>>> I confirm that '+=' looks better.  But '+=" is technically broken.
>>>>
>>>> a bit of my opinion:
>>>> I think =+ will confuse far more people than + as last character of var
>>>> name working weirdly. But I also think that + should be supported as
>>>> last character. Therefore I propose backslash escaping in variable name,
>>>> i.e.
>>>>   var+=value
>>>> appends value to var, while
>>>>   var\+=value
>>>> sets variable with name "var+"
>>
>> My first preference is to disallow + at the end of an end var. Perhaps
>> we can start printing a warning if people do it, for a few releases.
>>
>> My distance second preference is what Marek has here, using a
>> backslash to escape the + character.
> 
> How bad does it make the parser look if we allow trailing + in variable
> names, by escaping them?  It's seemingly the substantive objection at
> this point.
> 

So I don't understand all the bruhahaha around a + at the end of the
varname. Nobody suggests (that I have seen) changing anything about how
U-Boot at runtime interprets and handles variables, so all variable
names that used to be valid continue to be so.

It's just that this _new_ method of generating the environment places
certain restrictions on what can be done. The old-fashioned ways
(mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and
run-time 'env set') continue to allow people to define whatever env vars
they want. This new method is meant for transitioning in-tree boards'
default environment, and no in-tree boards need anything exotic.

Also, completely independent of whether the subsequent parser is
implemented in awk or python or rust, or what syntax it accepts and the
semantics of that syntax, the fact that we first pass the input through
cpp already means some things just won't work the same way as when given
to mkenvimage, and that applies to both sides of the =:

printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive
 spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp -

x y=
msg=I like 1
five spaces=5spaces

[In case its broken by the email, there are actually five spaces in the
printf string between the words "five" and "spaces", the above should
illustrate that cpp collapses those to a single space].

So, I'd much rather we do a cleaner break, and accept (and ignore)
whitespace on either side of the assignment operator - that's how Make
variable assignments work IIRC. And since a lot of people making use of
this will already be familiar with Yocto, I think we should have two
compound assignment operators, .= and +=. That still allows one to use
any non-whitespace, non-= characters (modulo the restrictions imposed by
the whole thing passing through cpp) in variable names, so

foo+=abc

means

foo+ = abc

while could append to foo by saying

foo += abc

That whitespace around the assignment operators would also make the
input files somewhat more readable - there really is no point in having
human-readable, human-editable text files having a format
almost-but-not-quite be that of the on-disk format.

Rasmus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 15:59             ` Simon Glass
  2021-10-21 16:03               ` Tom Rini
@ 2021-10-22  8:06               ` Wolfgang Denk
  2021-10-22 14:04                 ` Marek Behún
  2021-10-22 14:50                 ` Tom Rini
  1 sibling, 2 replies; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-22  8:06 UTC (permalink / raw)
  To: Simon Glass
  Cc: Marek Behún, Tom Rini, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Dear Simon,

In message <CAPnjgZ1BuAJC6Vhp06HrifU9jZqbOEuC+zRauV1DH3rY1qZp3Q@mail.gmail.com> you wrote:
>
> > > i.e.
> > >   var+=value
> > > appends value to var, while
> > >   var\+=value
> > > sets variable with name "var+"
>
> My first preference is to disallow + at the end of an end var. Perhaps
> we can start printing a warning if people do it, for a few releases.

This might seem to be a harmless change, but it is actually a
fundamental one.  And it breaks backward compatiility.  And all this
without need, as a list of alternatives have been suggested.

> My distance second preference is what Marek has here, using a
> backslash to escape the + character.

Actually this has the same problem, as the backslash is also a legal
character in a variable name:

	=> setenv foo\\+ bar
	=> printenv foo\\+  
	foo\+=bar


Yes, it was probably not a good idea not to restrict the allowed
character set when I implemented this stuff 21 years ago, but then
code size was critical - we had U-Boot running from 128 kB EPROM
(you remember these huge chips which were erased under UV light?).

The fact is, '=' and NUL are the only characters that cannot be used
in a variable name.


> As for =+ ...while I can see how people might parse it (we are setting
> the var equal to what it has with an appending string) I think it is a
> terrible idea as it is just not what people expect.

What do people expect? This is a totally new feature, so people will
use what they find in the documentation and in example code.

> Also, putting the
> + after the = places (similarly unlikely) restrictions on the
> expression.

There is a fundamental difference here.

For the '+=' case, there is no way to escape the '+', as all
commonly used escapes are valid characters in the variable name,
too.

With '=+', the '=' defines where the variable name ends, and from
here you can define your own rules as where the value part begins -
this is just a matter how you implement your parser.

> The current format is basically the same as 'print'. So if I can't
> have the first preference, we could ensure that it prints a \ in the
> case that the var ends with +

But '\' is a legal character in the variable name, too. Anything but
'=' and NUL is a legal char. And this makes escaping impossible:

	=> setenv \'foo\\-\' foobar
	=> printenv \'foo\\-\'
	'foo\-'=foobar

> > Also, I think that it would be better if spaces and tabs were allowed
> > to indent the .env file, i.e.
> >
> >         var_a   =       3
> >         var_bcd =       7
> >
> > should set "var_a" to "3", "var_bcd" to "7".
> >
> > If special character are needed in either name or value, they could be
> > escaped and/or quoted.
>
> They are allowed in the value but are reduced to a single space in the
> front. We need this for multi-line strings (but I'm a bit worried
> about it).

You mean this automatically insert a newline between parts? ugh...
I didn't realize this. Did I miss it in the documentation?

> We could update it to skip any leading space after the = I think.

So what if you need a leading space?


> I don't like spaces before the = though. It doesn't match the 'print'
> output (which has no space) and it is confusing:

env print also does not add any spaces after the '='.

> I think we need strict rules so it is easy for people to get exactly
> the env they want.

Strict rules, proper documentation, and a set of examples.


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@denx.de
Any time things appear to be going better, you have overlooked  some-
thing.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-21 16:03               ` Tom Rini
  2021-10-21 16:51                 ` Simon Glass
  2021-10-22  6:40                 ` Rasmus Villemoes
@ 2021-10-22  8:08                 ` Wolfgang Denk
  2021-10-22 14:47                   ` Tom Rini
  2 siblings, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-22  8:08 UTC (permalink / raw)
  To: Tom Rini
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Dear Tom,

In message <20211021160311.GC3577824@bill-the-cat> you wrote:
> 
> How bad does it make the parser look if we allow trailing + in variable
> names, by escaping them?  It's seemingly the substantive objection at
> this point.

Any escape character is also a legal name character.

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@denx.de
Q:  How many IBM CPU's does it take to execute a job?
A:  Four; three to hold it down, and one to rip its head off.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-22  8:06               ` Wolfgang Denk
@ 2021-10-22 14:04                 ` Marek Behún
  2021-10-22 14:50                 ` Tom Rini
  1 sibling, 0 replies; 38+ messages in thread
From: Marek Behún @ 2021-10-22 14:04 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Simon Glass, Tom Rini, U-Boot Mailing List, Rasmus Villemoes,
	Heinrich Schuchardt, Joe Hershberger

Hello Wolfgang,

On Fri, 22 Oct 2021 10:06:55 +0200
Wolfgang Denk <wd@denx.de> wrote:

> For the '+=' case, there is no way to escape the '+', as all
> commonly used escapes are valid characters in the variable name,
> too.

We can define that backslash is to be also escaped if it is to be used
as variable name:
  weird_var\\\+=abcd

I still think it is far more intuitive than =+.

Anyway, IMO '+' as the last character in varname is a extreme corner
case; I think that no one sane actually uses it.

But even if they did, Simon's patches do not break it. Simon's patches
only disallow it in board environment definition during compilation.

I think it is a completely reasonable thing to diallow board
maintainers (i.e. only U-Boot developers, not users) from using such
construction.

Marek

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-22  8:08                 ` Wolfgang Denk
@ 2021-10-22 14:47                   ` Tom Rini
  2021-10-24 15:46                     ` Wolfgang Denk
  0 siblings, 1 reply; 38+ messages in thread
From: Tom Rini @ 2021-10-22 14:47 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Fri, Oct 22, 2021 at 10:08:05AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20211021160311.GC3577824@bill-the-cat> you wrote:
> > 
> > How bad does it make the parser look if we allow trailing + in variable
> > names, by escaping them?  It's seemingly the substantive objection at
> > this point.
> 
> Any escape character is also a legal name character.

I am struggling to have a non-meme reaction to this.  Perhaps the best
step is just earlier on in the series note that variable names need to
fit within the broadly and commonly used set of characters and assorted
funny business you can do historically needs to be migrated.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-22  8:06               ` Wolfgang Denk
  2021-10-22 14:04                 ` Marek Behún
@ 2021-10-22 14:50                 ` Tom Rini
  1 sibling, 0 replies; 38+ messages in thread
From: Tom Rini @ 2021-10-22 14:50 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 4032 bytes --]

On Fri, Oct 22, 2021 at 10:06:55AM +0200, Wolfgang Denk wrote:
> Dear Simon,
> 
> In message <CAPnjgZ1BuAJC6Vhp06HrifU9jZqbOEuC+zRauV1DH3rY1qZp3Q@mail.gmail.com> you wrote:
> >
> > > > i.e.
> > > >   var+=value
> > > > appends value to var, while
> > > >   var\+=value
> > > > sets variable with name "var+"
> >
> > My first preference is to disallow + at the end of an end var. Perhaps
> > we can start printing a warning if people do it, for a few releases.
> 
> This might seem to be a harmless change, but it is actually a
> fundamental one.  And it breaks backward compatiility.  And all this
> without need, as a list of alternatives have been suggested.
> 
> > My distance second preference is what Marek has here, using a
> > backslash to escape the + character.
> 
> Actually this has the same problem, as the backslash is also a legal
> character in a variable name:
> 
> 	=> setenv foo\\+ bar
> 	=> printenv foo\\+  
> 	foo\+=bar
> 
> 
> Yes, it was probably not a good idea not to restrict the allowed
> character set when I implemented this stuff 21 years ago, but then
> code size was critical - we had U-Boot running from 128 kB EPROM
> (you remember these huge chips which were erased under UV light?).
> 
> The fact is, '=' and NUL are the only characters that cannot be used
> in a variable name.
> 
> 
> > As for =+ ...while I can see how people might parse it (we are setting
> > the var equal to what it has with an appending string) I think it is a
> > terrible idea as it is just not what people expect.
> 
> What do people expect? This is a totally new feature, so people will
> use what they find in the documentation and in example code.
> 
> > Also, putting the
> > + after the = places (similarly unlikely) restrictions on the
> > expression.
> 
> There is a fundamental difference here.
> 
> For the '+=' case, there is no way to escape the '+', as all
> commonly used escapes are valid characters in the variable name,
> too.
> 
> With '=+', the '=' defines where the variable name ends, and from
> here you can define your own rules as where the value part begins -
> this is just a matter how you implement your parser.
> 
> > The current format is basically the same as 'print'. So if I can't
> > have the first preference, we could ensure that it prints a \ in the
> > case that the var ends with +
> 
> But '\' is a legal character in the variable name, too. Anything but
> '=' and NUL is a legal char. And this makes escaping impossible:
> 
> 	=> setenv \'foo\\-\' foobar
> 	=> printenv \'foo\\-\'
> 	'foo\-'=foobar
> 
> > > Also, I think that it would be better if spaces and tabs were allowed
> > > to indent the .env file, i.e.
> > >
> > >         var_a   =       3
> > >         var_bcd =       7
> > >
> > > should set "var_a" to "3", "var_bcd" to "7".
> > >
> > > If special character are needed in either name or value, they could be
> > > escaped and/or quoted.
> >
> > They are allowed in the value but are reduced to a single space in the
> > front. We need this for multi-line strings (but I'm a bit worried
> > about it).
> 
> You mean this automatically insert a newline between parts? ugh...
> I didn't realize this. Did I miss it in the documentation?
> 
> > We could update it to skip any leading space after the = I think.
> 
> So what if you need a leading space?
> 
> 
> > I don't like spaces before the = though. It doesn't match the 'print'
> > output (which has no space) and it is confusing:
> 
> env print also does not add any spaces after the '='.
> 
> > I think we need strict rules so it is easy for people to get exactly
> > the env they want.
> 
> Strict rules, proper documentation, and a set of examples.

And sanity and restrictions introduced to our environment variables.
The amount of "fun" things that were allowed by disallowing only NUL and
= from names, and also allowing us to stay crazy tiny are just not
relevant to where we are now.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-22 14:47                   ` Tom Rini
@ 2021-10-24 15:46                     ` Wolfgang Denk
  2021-10-24 16:44                       ` Tom Rini
  0 siblings, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-24 15:46 UTC (permalink / raw)
  To: Tom Rini
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Dear Tom,

In message <20211022144759.GG3577824@bill-the-cat> you wrote:
> 
> > Any escape character is also a legal name character.
>
> I am struggling to have a non-meme reaction to this.  Perhaps the best
> step is just earlier on in the series note that variable names need to
> fit within the broadly and commonly used set of characters and assorted
> funny business you can do historically needs to be migrated.

Indeed I think this is the most reasonable approach.

Like you cannot write any aritrary code in plain C and have to fall
back to assembler in a few places, this patch series should simply
not claim to be able to support all legal environment settings.

It is a convenience tool, and it is OK if it has a few restrictions,
like for the character set of supported variable names.

But:

1) These restrictions must be clearly documented, both in the commit
   message and in the related documentation/readme.
2) There should be another, more primitive way to generate
   environment settings without these restrictions..

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@denx.de
Whom the gods would destroy, they first teach BASIC.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-24 15:46                     ` Wolfgang Denk
@ 2021-10-24 16:44                       ` Tom Rini
  2021-10-25  7:48                         ` Wolfgang Denk
  0 siblings, 1 reply; 38+ messages in thread
From: Tom Rini @ 2021-10-24 16:44 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On Sun, Oct 24, 2021 at 05:46:00PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20211022144759.GG3577824@bill-the-cat> you wrote:
> > 
> > > Any escape character is also a legal name character.
> >
> > I am struggling to have a non-meme reaction to this.  Perhaps the best
> > step is just earlier on in the series note that variable names need to
> > fit within the broadly and commonly used set of characters and assorted
> > funny business you can do historically needs to be migrated.
> 
> Indeed I think this is the most reasonable approach.
> 
> Like you cannot write any aritrary code in plain C and have to fall
> back to assembler in a few places, this patch series should simply
> not claim to be able to support all legal environment settings.
> 
> It is a convenience tool, and it is OK if it has a few restrictions,
> like for the character set of supported variable names.
> 
> But:
> 
> 1) These restrictions must be clearly documented, both in the commit
>    message and in the related documentation/readme.
> 2) There should be another, more primitive way to generate
>    environment settings without these restrictions..

First, in that we don't have tests today for any of the "interesting"
possible variable options, I have no clue which ones even work as
intended.

Second, yes, an end result here should be that yes, the default
environment should be more easily buildable and integrated with
arbitrary tools, so if something else can parse it (libubootenv?) it can
be done.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-22  6:40                 ` Rasmus Villemoes
@ 2021-10-24 19:54                   ` Simon Glass
  2021-10-25  7:06                     ` Rasmus Villemoes
  0 siblings, 1 reply; 38+ messages in thread
From: Simon Glass @ 2021-10-24 19:54 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Tom Rini, Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Heinrich Schuchardt, Joe Hershberger

Hi Rasmus,

On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 21/10/2021 18.03, Tom Rini wrote:
> > On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
> >> Hi Marek,
> >>
> >> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
> >>>
> >>> On Thu, 21 Oct 2021 15:25:37 +0200
> >>> Marek Behún <marek.behun@nic.cz> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> On Thu, 21 Oct 2021 15:06:51 +0200
> >>>> Wolfgang Denk <wd@denx.de> wrote:
> >>>>
> >>>>> I confirm that '+=' looks better.  But '+=" is technically broken.
> >>>>
> >>>> a bit of my opinion:
> >>>> I think =+ will confuse far more people than + as last character of var
> >>>> name working weirdly. But I also think that + should be supported as
> >>>> last character. Therefore I propose backslash escaping in variable name,
> >>>> i.e.
> >>>>   var+=value
> >>>> appends value to var, while
> >>>>   var\+=value
> >>>> sets variable with name "var+"
> >>
> >> My first preference is to disallow + at the end of an end var. Perhaps
> >> we can start printing a warning if people do it, for a few releases.
> >>
> >> My distance second preference is what Marek has here, using a
> >> backslash to escape the + character.
> >
> > How bad does it make the parser look if we allow trailing + in variable
> > names, by escaping them?  It's seemingly the substantive objection at
> > this point.
> >
>
> So I don't understand all the bruhahaha around a + at the end of the
> varname. Nobody suggests (that I have seen) changing anything about how
> U-Boot at runtime interprets and handles variables, so all variable
> names that used to be valid continue to be so.
>
> It's just that this _new_ method of generating the environment places
> certain restrictions on what can be done. The old-fashioned ways
> (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and
> run-time 'env set') continue to allow people to define whatever env vars
> they want. This new method is meant for transitioning in-tree boards'
> default environment, and no in-tree boards need anything exotic.
>
> Also, completely independent of whether the subsequent parser is
> implemented in awk or python or rust, or what syntax it accepts and the
> semantics of that syntax, the fact that we first pass the input through
> cpp already means some things just won't work the same way as when given
> to mkenvimage, and that applies to both sides of the =:
>
> printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive
>  spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp -
>
> x y=
> msg=I like 1
> five spaces=5spaces
>
> [In case its broken by the email, there are actually five spaces in the
> printf string between the words "five" and "spaces", the above should
> illustrate that cpp collapses those to a single space].
>
> So, I'd much rather we do a cleaner break, and accept (and ignore)
> whitespace on either side of the assignment operator - that's how Make
> variable assignments work IIRC. And since a lot of people making use of
> this will already be familiar with Yocto, I think we should have two
> compound assignment operators, .= and +=. That still allows one to use
> any non-whitespace, non-= characters (modulo the restrictions imposed by
> the whole thing passing through cpp) in variable names, so
>
> foo+=abc
>
> means
>
> foo+ = abc
>
> while could append to foo by saying
>
> foo += abc
>
> That whitespace around the assignment operators would also make the
> input files somewhat more readable - there really is no point in having
> human-readable, human-editable text files having a format
> almost-but-not-quite be that of the on-disk format.

I am OK with this on the name front, as I assume we don't want to
allow space in a var name!

But how do I do this?

bootargs=console=fred
#ifdef SOMETHING
bootargs+= dm-verity=...
#endif

We need the space between the bootargs.

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-24 19:54                   ` Simon Glass
@ 2021-10-25  7:06                     ` Rasmus Villemoes
  2021-10-25 15:18                       ` Simon Glass
  0 siblings, 1 reply; 38+ messages in thread
From: Rasmus Villemoes @ 2021-10-25  7:06 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Heinrich Schuchardt, Joe Hershberger

On 24/10/2021 21.54, Simon Glass wrote:
> Hi Rasmus,
> 
> On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:
>>
>> On 21/10/2021 18.03, Tom Rini wrote:
>>> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
>>>> Hi Marek,
>>>>
>>>> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
>>>>>
>>>>> On Thu, 21 Oct 2021 15:25:37 +0200
>>>>> Marek Behún <marek.behun@nic.cz> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> On Thu, 21 Oct 2021 15:06:51 +0200
>>>>>> Wolfgang Denk <wd@denx.de> wrote:
>>>>>>
>>>>>>> I confirm that '+=' looks better.  But '+=" is technically broken.
>>>>>>
>>>>>> a bit of my opinion:
>>>>>> I think =+ will confuse far more people than + as last character of var
>>>>>> name working weirdly. But I also think that + should be supported as
>>>>>> last character. Therefore I propose backslash escaping in variable name,
>>>>>> i.e.
>>>>>>   var+=value
>>>>>> appends value to var, while
>>>>>>   var\+=value
>>>>>> sets variable with name "var+"
>>>>
>>>> My first preference is to disallow + at the end of an end var. Perhaps
>>>> we can start printing a warning if people do it, for a few releases.
>>>>
>>>> My distance second preference is what Marek has here, using a
>>>> backslash to escape the + character.
>>>
>>> How bad does it make the parser look if we allow trailing + in variable
>>> names, by escaping them?  It's seemingly the substantive objection at
>>> this point.
>>>
>>
>> So I don't understand all the bruhahaha around a + at the end of the
>> varname. Nobody suggests (that I have seen) changing anything about how
>> U-Boot at runtime interprets and handles variables, so all variable
>> names that used to be valid continue to be so.
>>
>> It's just that this _new_ method of generating the environment places
>> certain restrictions on what can be done. The old-fashioned ways
>> (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and
>> run-time 'env set') continue to allow people to define whatever env vars
>> they want. This new method is meant for transitioning in-tree boards'
>> default environment, and no in-tree boards need anything exotic.
>>
>> Also, completely independent of whether the subsequent parser is
>> implemented in awk or python or rust, or what syntax it accepts and the
>> semantics of that syntax, the fact that we first pass the input through
>> cpp already means some things just won't work the same way as when given
>> to mkenvimage, and that applies to both sides of the =:
>>
>> printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive
>>  spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp -
>>
>> x y=
>> msg=I like 1
>> five spaces=5spaces
>>
>> [In case its broken by the email, there are actually five spaces in the
>> printf string between the words "five" and "spaces", the above should
>> illustrate that cpp collapses those to a single space].
>>
>> So, I'd much rather we do a cleaner break, and accept (and ignore)
>> whitespace on either side of the assignment operator - that's how Make
>> variable assignments work IIRC. And since a lot of people making use of
>> this will already be familiar with Yocto, I think we should have two
>> compound assignment operators, .= and +=. That still allows one to use
>> any non-whitespace, non-= characters (modulo the restrictions imposed by
>> the whole thing passing through cpp) in variable names, so
>>
>> foo+=abc
>>
>> means
>>
>> foo+ = abc
>>
>> while could append to foo by saying
>>
>> foo += abc
>>
>> That whitespace around the assignment operators would also make the
>> input files somewhat more readable - there really is no point in having
>> human-readable, human-editable text files having a format
>> almost-but-not-quite be that of the on-disk format.
> 
> I am OK with this on the name front, as I assume we don't want to
> allow space in a var name!

Exactly, there's really never any case where that would be sensible. But
I would probably go a bit further and simply restrict varnames to the
usual alphanumerics plus [_.+-] - in particular, exclude single and
double quotes and backslash. That leaves the door open for somebody to
later support "arbitrary" variable names by defining what it would mean
to say e.g.

"abc \n'\"\tfoo" = hahaha

or whatever syntax they'd propose, but there's absolutely no point in
implementing anything like that initially.

> But how do I do this?
> 
> bootargs=console=fred
> #ifdef SOMETHING
> bootargs+= dm-verity=...
> #endif
> 
> We need the space between the bootargs.

Exactly like that, and for the case where you want to append something
_without_ an extra space there's the .= operator I also suggested.

FWIW, I like the idea that an indented line represents a continuation of
the value of the current assignment.

I don't think I've seen it addressed, but how do you deal with CONFIG_
string items? In the config.h file, the macro definition includes the
double quotes, but I don't think one wants that in the env values.

conf = CONFIG_DEFAULT_CONF
bootcmd = bootm $loadaddr#$conf

would attempt to boot e.g. 0x12340000#"foo", and while one can do
de-quotification in U-Boot shell, it's rather cumbersome.

Rasmus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-24 16:44                       ` Tom Rini
@ 2021-10-25  7:48                         ` Wolfgang Denk
  0 siblings, 0 replies; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-25  7:48 UTC (permalink / raw)
  To: Tom Rini
  Cc: Simon Glass, Marek Behún, U-Boot Mailing List,
	Rasmus Villemoes, Heinrich Schuchardt, Joe Hershberger

Dear Tom,

In message <20211024164404.GQ3577824@bill-the-cat> you wrote:
> 
> > It is a convenience tool, and it is OK if it has a few restrictions,
> > like for the character set of supported variable names.
> > 
> > But:
> > 
> > 1) These restrictions must be clearly documented, both in the commit
> >    message and in the related documentation/readme.
> > 2) There should be another, more primitive way to generate
> >    environment settings without these restrictions..
>
> First, in that we don't have tests today for any of the "interesting"
> possible variable options, I have no clue which ones even work as
> intended.
>
> Second, yes, an end result here should be that yes, the default
> environment should be more easily buildable and integrated with
> arbitrary tools, so if something else can parse it (libubootenv?) it can
> be done.

Actually I have an even more low-level approach in mind, like the
capability to include (or rather import) binary U-Boot environment
data given in the usual

	<name1>=<value1>\0...<nameN>=<valueN>\0\0

form.  This might come in handy if your data comes from exporting
the environmentof a running system.

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@denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-25  7:06                     ` Rasmus Villemoes
@ 2021-10-25 15:18                       ` Simon Glass
  2021-10-25 19:52                         ` Rasmus Villemoes
  2021-10-26 10:15                         ` Wolfgang Denk
  0 siblings, 2 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-25 15:18 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Tom Rini, Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Heinrich Schuchardt, Joe Hershberger

Hi Rasmus,

On Mon, 25 Oct 2021 at 01:06, Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> On 24/10/2021 21.54, Simon Glass wrote:
> > Hi Rasmus,
> >
> > On Fri, 22 Oct 2021 at 00:41, Rasmus Villemoes
> > <rasmus.villemoes@prevas.dk> wrote:
> >>
> >> On 21/10/2021 18.03, Tom Rini wrote:
> >>> On Thu, Oct 21, 2021 at 09:59:38AM -0600, Simon Glass wrote:
> >>>> Hi Marek,
> >>>>
> >>>> On Thu, 21 Oct 2021 at 07:28, Marek Behún <marek.behun@nic.cz> wrote:
> >>>>>
> >>>>> On Thu, 21 Oct 2021 15:25:37 +0200
> >>>>> Marek Behún <marek.behun@nic.cz> wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> On Thu, 21 Oct 2021 15:06:51 +0200
> >>>>>> Wolfgang Denk <wd@denx.de> wrote:
> >>>>>>
> >>>>>>> I confirm that '+=' looks better.  But '+=" is technically broken.
> >>>>>>
> >>>>>> a bit of my opinion:
> >>>>>> I think =+ will confuse far more people than + as last character of var
> >>>>>> name working weirdly. But I also think that + should be supported as
> >>>>>> last character. Therefore I propose backslash escaping in variable name,
> >>>>>> i.e.
> >>>>>>   var+=value
> >>>>>> appends value to var, while
> >>>>>>   var\+=value
> >>>>>> sets variable with name "var+"
> >>>>
> >>>> My first preference is to disallow + at the end of an end var. Perhaps
> >>>> we can start printing a warning if people do it, for a few releases.
> >>>>
> >>>> My distance second preference is what Marek has here, using a
> >>>> backslash to escape the + character.
> >>>
> >>> How bad does it make the parser look if we allow trailing + in variable
> >>> names, by escaping them?  It's seemingly the substantive objection at
> >>> this point.
> >>>
> >>
> >> So I don't understand all the bruhahaha around a + at the end of the
> >> varname. Nobody suggests (that I have seen) changing anything about how
> >> U-Boot at runtime interprets and handles variables, so all variable
> >> names that used to be valid continue to be so.
> >>
> >> It's just that this _new_ method of generating the environment places
> >> certain restrictions on what can be done. The old-fashioned ways
> >> (mkenvimage, good'ol CONFIG_ENV_EXTRA_SETTINGS with all its warts, and
> >> run-time 'env set') continue to allow people to define whatever env vars
> >> they want. This new method is meant for transitioning in-tree boards'
> >> default environment, and no in-tree boards need anything exotic.
> >>
> >> Also, completely independent of whether the subsequent parser is
> >> implemented in awk or python or rust, or what syntax it accepts and the
> >> semantics of that syntax, the fact that we first pass the input through
> >> cpp already means some things just won't work the same way as when given
> >> to mkenvimage, and that applies to both sides of the =:
> >>
> >> printf 'x/* huh */y=/* where did this go ? */\nmsg=I like unix\nfive
> >>  spaces=5spaces\n' | gcc -E -P -x assembler-with-cpp -
> >>
> >> x y=
> >> msg=I like 1
> >> five spaces=5spaces
> >>
> >> [In case its broken by the email, there are actually five spaces in the
> >> printf string between the words "five" and "spaces", the above should
> >> illustrate that cpp collapses those to a single space].
> >>
> >> So, I'd much rather we do a cleaner break, and accept (and ignore)
> >> whitespace on either side of the assignment operator - that's how Make
> >> variable assignments work IIRC. And since a lot of people making use of
> >> this will already be familiar with Yocto, I think we should have two
> >> compound assignment operators, .= and +=. That still allows one to use
> >> any non-whitespace, non-= characters (modulo the restrictions imposed by
> >> the whole thing passing through cpp) in variable names, so
> >>
> >> foo+=abc
> >>
> >> means
> >>
> >> foo+ = abc
> >>
> >> while could append to foo by saying
> >>
> >> foo += abc
> >>
> >> That whitespace around the assignment operators would also make the
> >> input files somewhat more readable - there really is no point in having
> >> human-readable, human-editable text files having a format
> >> almost-but-not-quite be that of the on-disk format.
> >
> > I am OK with this on the name front, as I assume we don't want to
> > allow space in a var name!
>
> Exactly, there's really never any case where that would be sensible. But
> I would probably go a bit further and simply restrict varnames to the
> usual alphanumerics plus [_.+-] - in particular, exclude single and
> double quotes and backslash. That leaves the door open for somebody to
> later support "arbitrary" variable names by defining what it would mean
> to say e.g.
>
> "abc \n'\"\tfoo" = hahaha
>
> or whatever syntax they'd propose, but there's absolutely no point in
> implementing anything like that initially.
>
> > But how do I do this?
> >
> > bootargs=console=fred
> > #ifdef SOMETHING
> > bootargs+= dm-verity=...
> > #endif
> >
> > We need the space between the bootargs.
>
> Exactly like that, and for the case where you want to append something
> _without_ an extra space there's the .= operator I also suggested.

Do you have a link to the docs for that?

Perhaps we should get this initial thing in and we can take it from
there. I expect that as we start to convert more environments we'll
find more things we need.

>
> FWIW, I like the idea that an indented line represents a continuation of
> the value of the current assignment.
>
> I don't think I've seen it addressed, but how do you deal with CONFIG_
> string items? In the config.h file, the macro definition includes the
> double quotes, but I don't think one wants that in the env values.
>
> conf = CONFIG_DEFAULT_CONF
> bootcmd = bootm $loadaddr#$conf
>
> would attempt to boot e.g. 0x12340000#"foo", and while one can do
> de-quotification in U-Boot shell, it's rather cumbersome.

Badly. I really don't like the stringify stuff so we don't have that
problem, but we have this one.

I would much prefer it be automatic, if possible. This needs some
thought...e.g. I wonder what the default behaviour should be?

In your example, conf would end up being set to "fred" with the quote,
for example, which seem like the wrong default behaviour. Perhaps we
do need something like:

conf=_dequote(CONFIG_DEFAULT_CONF)

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-25 15:18                       ` Simon Glass
@ 2021-10-25 19:52                         ` Rasmus Villemoes
  2021-10-26 10:15                         ` Wolfgang Denk
  1 sibling, 0 replies; 38+ messages in thread
From: Rasmus Villemoes @ 2021-10-25 19:52 UTC (permalink / raw)
  To: Simon Glass
  Cc: Tom Rini, Marek Behún, Wolfgang Denk, U-Boot Mailing List,
	Heinrich Schuchardt, Joe Hershberger

On 25/10/2021 17.18, Simon Glass wrote:
> Hi Rasmus,
> 
> On Mon, 25 Oct 2021 at 01:06, Rasmus Villemoes
> <rasmus.villemoes@prevas.dk> wrote:

>> Exactly, there's really never any case where that would be sensible. But
>> I would probably go a bit further and simply restrict varnames to the
>> usual alphanumerics plus [_.+-] - in particular, exclude single and
>> double quotes and backslash. That leaves the door open for somebody to
>> later support "arbitrary" variable names by defining what it would mean
>> to say e.g.
>>
>> "abc \n'\"\tfoo" = hahaha
>>
>> or whatever syntax they'd propose, but there's absolutely no point in
>> implementing anything like that initially.
>>
>>> But how do I do this?
>>>
>>> bootargs=console=fred
>>> #ifdef SOMETHING
>>> bootargs+= dm-verity=...
>>> #endif
>>>
>>> We need the space between the bootargs.
>>
>> Exactly like that, and for the case where you want to append something
>> _without_ an extra space there's the .= operator I also suggested.
> 
> Do you have a link to the docs for that?
>

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#appending-and-prepending-with-spaces

As I said, it will be familiar to anyone who has ever dealt with
Yocto/bitbake, and the behaviour of += (of adding the RHS with a space
prepended) is known from Make. I think there are uses for both, and it
shouldn't be very hard to support both operators.
of the current assignment.

>> I don't think I've seen it addressed, but how do you deal with CONFIG_
>> string items? In the config.h file, the macro definition includes the
>> double quotes, but I don't think one wants that in the env values.
>>
>> conf = CONFIG_DEFAULT_CONF
>> bootcmd = bootm $loadaddr#$conf
>>
>> would attempt to boot e.g. 0x12340000#"foo", and while one can do
>> de-quotification in U-Boot shell, it's rather cumbersome.
> 
> Badly. I really don't like the stringify stuff so we don't have that
> problem, but we have this one.
> 
> I would much prefer it be automatic, if possible. This needs some
> thought...e.g. I wonder what the default behaviour should be?

I think it should be the value without quotes, if that is at all
possible. But, it's not completely trivial, because cpp won't do macro
expansion inside what it sees as a string literal, so if one wants a
CONFIG string inside double quotes, one can't do

  foo = "CONFIG_FOO"

Dunno, I think it needs some more thought.

Rasmus

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-25 15:18                       ` Simon Glass
  2021-10-25 19:52                         ` Rasmus Villemoes
@ 2021-10-26 10:15                         ` Wolfgang Denk
  2021-10-28 14:18                           ` Simon Glass
  1 sibling, 1 reply; 38+ messages in thread
From: Wolfgang Denk @ 2021-10-26 10:15 UTC (permalink / raw)
  To: Simon Glass
  Cc: Rasmus Villemoes, Tom Rini, Marek Behún,
	U-Boot Mailing List, Heinrich Schuchardt, Joe Hershberger

Dear Simon,

In message <CAPnjgZ0Rn00ob09hHZsu-sszbm9-UhDDSkDLmGZ5HeWSzV1H7Q@mail.gmail.com> you wrote:
>
> > > We need the space between the bootargs.
> >
> > Exactly like that, and for the case where you want to append something
> > _without_ an extra space there's the .=3D operator I also suggested.
>
> Do you have a link to the docs for that?
>
> Perhaps we should get this initial thing in and we can take it from
> there. I expect that as we start to convert more environments we'll
> find more things we need.

I think it is not a good idea to use two different operators for the
same appand operation, just to add a space in one case.

So assume I want to start the appended part with a TAB character,
would we define another operator then?

We have problems with escaping characters for the variable _name_
part, but not for the value. We can for example use standard shell
escape rules, like:

	foo += bar
	foo += \ bar
	foo += ' bar'

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@denx.de
"There is no statute of limitations on stupidity."
- Randomly produced by a computer program called Markov3.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
  2021-10-26 10:15                         ` Wolfgang Denk
@ 2021-10-28 14:18                           ` Simon Glass
  0 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-28 14:18 UTC (permalink / raw)
  To: Wolfgang Denk
  Cc: Rasmus Villemoes, Tom Rini, Marek Behún,
	U-Boot Mailing List, Heinrich Schuchardt, Joe Hershberger

Hi,

On Tue, 26 Oct 2021 at 04:16, Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ0Rn00ob09hHZsu-sszbm9-UhDDSkDLmGZ5HeWSzV1H7Q@mail.gmail.com> you wrote:
> >
> > > > We need the space between the bootargs.
> > >
> > > Exactly like that, and for the case where you want to append something
> > > _without_ an extra space there's the .=3D operator I also suggested.
> >
> > Do you have a link to the docs for that?
> >
> > Perhaps we should get this initial thing in and we can take it from
> > there. I expect that as we start to convert more environments we'll
> > find more things we need.
>
> I think it is not a good idea to use two different operators for the
> same appand operation, just to add a space in one case.
>
> So assume I want to start the appended part with a TAB character,
> would we define another operator then?
>
> We have problems with escaping characters for the variable _name_
> part, but not for the value. We can for example use standard shell
> escape rules, like:
>
>         foo += bar
>         foo += \ bar
>         foo += ' bar'
>

I don't mind either way and there is precedent for .= maybe in perl?
Can't remember.

But I think that change would be for user-friendliness, rather than a
strict requirement, so if we have agreement on the series as is now, I
say let's go ahead with that and refine it later. Patches welcome, as
they say.

After that we can discuss:
- this idea to relax the whitespace rules
- the idea of restricting env-var names to A-Za-z_0-9- or similar
- whether we can write a tool to convert all the envs automatically
- if not, what to do to encourage people to migrate so we can drop env
from the ad-hoc CONFIG thing

Regards,
Simon

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH v9 0/7] env: Allow environment in text files
@ 2021-10-19 22:43 Simon Glass
  0 siblings, 0 replies; 38+ messages in thread
From: Simon Glass @ 2021-10-19 22:43 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Reviewed-by : Marek Behún, Heinrich Schuchardt,
	Wolfgang Denk, Tom Rini, Rasmus Villemoes, Simon Glass,
	Joe Hershberger

One barrier to completing the 7-year-long Kconfig migration is that
the default environment is implemented using ad-hoc CONFIG options.
At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS.

It is not really feasible to move the environment to Kconfig as it is
hundreds of lines of text in some cases.

Even considering the current situation, it is painful to add large
amounts of text to the config-header file and dealing with quoting and
newlines is harder than it should be. It would be better if we could just
type the script into a text file and have it included by U-Boot.

This is already supported by the CONFIG_USE_DEFAULT_ENV_FILE feature. but
that does not support use of CONFIG options or comments, so is best suited
for use by other build systems wanting to define the U-Boot environment.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file board/<vendor>/<board>.env or
use CONFIG_ENV_SOURCE_FILE to set a filename.

The environment variables should be of the form "var=value". Values can
extend to multiple lines. This series converts the existing environment
documentation to rST and updates it to explain how to use this.

Note: this series was originally sent eight years ago:

https://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-sjg@chromium.org/

It has been updated to work with Kconfig, etc. Some review comments in
that patch were infeasible so I have not addressed them. I would like
this series to be considered independently, on its merits.

Rather than deal with the complexity of rewriting the distro-boot
script, this is disabled for sandbox. The forthcoming bootmethod approach
should provide the same functionality without needing the complex
scripting in the environment.

Migration needs more thought, although it can be done later. It may be
possible to do migrate automatically, using buildman to extract the
built-in environmnent from the ELF file.

This would produce a pretty ugly conversion though, since it would drop
all the intermediate variables used to create the environment.

Better would be to parse the config.h file, figure out the components of
CONFIG_EXTRA_ENV_SETTINGS then output these as separate pieces in the
file. It is not clear how easy that would be, nor whether the result would
be very pretty. Also the __stringify() macro needs to be handled somehow.

This series is available at u-boot-dm/env-working

Comments welcome.

Changes in v9:
- Drop mention of other strange characters
- Clarify that the + restriction is on the variable name not its value
- Add some tests for the script
- Deal with leading tabs
- Squash indentation down to one space
- Convert newlines within strings to spaces, which seems more consistent
- Handle appending an empty string to an empty var
- Fix blank line between tags
- Fix typo in commit message
- More bikeshedding on env_get_autostart()
- Fix '<vendor><board>' in cover letter
- Use env_get_yesno() in env_get_autostart() and update docs

Changes in v8:
- Update commit message to avoid mentioning the 'env' subdirectory
- Update commit message to mention the + restriction, etc.
- Overwrite the env file each time, to avoid incremental-build problems
- Fix ambiguity about what is ignored
- Go into more detail about the change of behaviour with autostart

Changes in v7:
- Use 'env' basename instead of 'environment' for intermediate output files
- Show a message indicating the source text file being used
- Give an error if CONFIG_EXTRA_ENV_SETTINGS is also defined
- Use CONFIG_ENV_SOURCE_FILE instead of rules to specify the text-file name
- Make board.env the default name if CONFIG_ENV_SOURCE_FILE is empty
- Rewrite the documentation
- Drop the use of common.env
- Update awk script to output the whole CONFIG string, or just a comment
- Add new patch to explain the relationship with DEFAULT_ENV_FILE
- A few more tweaks
- Update the cover letter

Changes in v6:
- Move all updates to a separate patch
- Combine the two env2string.awk patches into one
- Move all updates to a separate patch
- More updates and improvements
- Add new patch to tidy up use of autostart env var

Changes in v5:
- Minor updates as suggested by Wolfgang
- Explain how to include the common.env file
- Explain why variables starting with _ , and / are not supported
- Expand the definition of how to declare an environment variable
- Explain what happens to empty variables
- Update maintainer
- Move use of += to this patch
- Explain that environment variables may not end in +
- Minor updates as suggested by Wolfgang

Changes in v4:
- Add new patch to move environment documentation to rST
- Move this from being part of configuring U-Boot to part of building it
- Don't put the environment in autoconf.mk as it is not needed
- Add documentation in rST format instead of README
- Drop mention of import/export
- Update awk script to ignore blank lines, as generated by clang
- Add documentation in rST format instead of README
- Add new patch to move environment documentation to rST

Changes in v3:
- Adjust Makefile to generate the .inc and .h files in separate fules
- Add more detail in the README about the format of .env files
- Improve the comment about " in the awk script
- Correctly terminate environment files with \n
- Define __UBOOT_CONFIG__ when collecting environment files
- Add new patch to use a text-based environment for sandbox

Changes in v2:
- Move .env file from include/configs to board/
- Use awk script to process environment since it is much easier on the brain
- Add information and updated example script to README
- Add dependency rule so that the environment is rebuilt when it changes
- Add separate patch to enable C preprocessor for environment files
- Enable var+=value form to simplify composing variables in multiple steps

Simon Glass (7):
  sandbox: Drop distro_boot
  doc: Move environment documentation to rST
  env: Allow U-Boot scripts to be placed in a .env file
  sandbox: Use a text-based environment
  doc: Mention CONFIG_DEFAULT_ENV_FILE
  doc: Improve environment documentation
  bootm: Tidy up use of autostart env var

 MAINTAINERS               |   7 +
 Makefile                  |  66 ++++-
 README                    | 328 -------------------------
 board/sandbox/sandbox.env |  25 ++
 cmd/bootm.c               |   4 +-
 cmd/elf.c                 |   3 +-
 common/bootm_os.c         |   5 +-
 config.mk                 |   2 +
 doc/usage/environment.rst | 490 ++++++++++++++++++++++++++++++++++++++
 doc/usage/index.rst       |   1 +
 env/Kconfig               |  18 ++
 env/common.c              |   5 +
 env/embedded.c            |   1 +
 include/configs/sandbox.h |  40 ----
 include/env.h             |   7 +
 include/env_default.h     |  11 +
 scripts/env2string.awk    |  71 ++++++
 test/py/tests/test_env.py |  93 ++++++++
 18 files changed, 799 insertions(+), 378 deletions(-)
 create mode 100644 board/sandbox/sandbox.env
 create mode 100644 doc/usage/environment.rst
 create mode 100644 scripts/env2string.awk

-- 
2.33.0.1079.g6e70778dc9-goog


^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2021-10-28 14:19 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-19 22:44 [PATCH v9 0/7] env: Allow environment in text files Simon Glass
2021-10-19 22:44 ` [PATCH v9 1/7] sandbox: Drop distro_boot Simon Glass
2021-10-19 22:44 ` [PATCH v9 2/7] doc: Move environment documentation to rST Simon Glass
2021-10-20  6:38   ` Heinrich Schuchardt
2021-10-22  3:05     ` Simon Glass
2021-10-19 22:44 ` [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file Simon Glass
2021-10-21  9:50   ` Wolfgang Denk
2021-10-21 12:23     ` Tom Rini
2021-10-21 13:06       ` Wolfgang Denk
2021-10-21 13:25         ` Marek Behún
2021-10-21 13:28           ` Marek Behún
2021-10-21 15:12             ` Wolfgang Denk
2021-10-21 15:18               ` Tom Rini
2021-10-21 15:59             ` Simon Glass
2021-10-21 16:03               ` Tom Rini
2021-10-21 16:51                 ` Simon Glass
2021-10-22  6:40                 ` Rasmus Villemoes
2021-10-24 19:54                   ` Simon Glass
2021-10-25  7:06                     ` Rasmus Villemoes
2021-10-25 15:18                       ` Simon Glass
2021-10-25 19:52                         ` Rasmus Villemoes
2021-10-26 10:15                         ` Wolfgang Denk
2021-10-28 14:18                           ` Simon Glass
2021-10-22  8:08                 ` Wolfgang Denk
2021-10-22 14:47                   ` Tom Rini
2021-10-24 15:46                     ` Wolfgang Denk
2021-10-24 16:44                       ` Tom Rini
2021-10-25  7:48                         ` Wolfgang Denk
2021-10-22  8:06               ` Wolfgang Denk
2021-10-22 14:04                 ` Marek Behún
2021-10-22 14:50                 ` Tom Rini
2021-10-19 22:44 ` [PATCH v9 4/7] sandbox: Use a text-based environment Simon Glass
2021-10-20  6:58   ` Alexander Dahl
2021-10-19 22:44 ` [PATCH v9 5/7] doc: Mention CONFIG_DEFAULT_ENV_FILE Simon Glass
2021-10-19 22:44 ` [PATCH v9 6/7] doc: Improve environment documentation Simon Glass
2021-10-19 22:44 ` [PATCH v9 7/7] bootm: Tidy up use of autostart env var Simon Glass
2021-10-21 14:02 ` [PATCH v9 0/7] env: Allow environment in text files Tom Rini
  -- strict thread matches above, loose matches on Subject: below --
2021-10-19 22:43 Simon Glass

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.