[PATCH v8 0/8] env: Allow environment in text files

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-...
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 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 (8): binman: Allow timeout to occur in the image or its section 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 | 489 ++++++++++++++++++++++++++++++++++++++ doc/usage/index.rst | 1 + env/Kconfig | 18 ++ env/common.c | 7 + env/embedded.c | 1 + include/configs/sandbox.h | 40 ---- include/env.h | 7 + include/env_default.h | 11 + scripts/env2string.awk | 63 +++++ tools/binman/ftest.py | 3 +- 18 files changed, 700 insertions(+), 380 deletions(-) create mode 100644 board/sandbox/sandbox.env create mode 100644 doc/usage/environment.rst create mode 100644 scripts/env2string.awk

At present testThreadTimeout() assumes that the expected timeout happens first when building the section, but it can just as easily happen at the top-level image. Update the test to cope with both.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
tools/binman/ftest.py | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py index cea3ebf2b9f..8199a4fc7e0 100644 --- a/tools/binman/ftest.py +++ b/tools/binman/ftest.py @@ -4565,8 +4565,7 @@ class TestFunctional(unittest.TestCase): with self.assertRaises(ValueError) as e: self._DoTestFile('202_section_timeout.dts', test_section_timeout=True) - self.assertIn("Node '/binman/section@0': Timed out obtaining contents", - str(e.exception)) + self.assertIn("Timed out obtaining contents", str(e.exception))
def testTiming(self): """Test output of timing information"""

On Mon, 18 Oct 2021 12:13:15 -0600 Simon Glass sjg@chromium.org wrote:
At present testThreadTimeout() assumes that the expected timeout happens first when building the section, but it can just as easily happen at the top-level image. Update the test to cope with both.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Marek Behún marek.behun@nic.cz

On Mon, 18 Oct 2021 12:13:15 -0600 Simon Glass sjg@chromium.org wrote:
At present testThreadTimeout() assumes that the expected timeout happens first when building the section, but it can just as easily happen at the top-level image. Update the test to cope with both.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Marek Behún marek.behun@nic.cz
Applied to u-boot-dm, thanks!

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 ---
(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

On Mon, 18 Oct 2021 12:13:16 -0600 Simon Glass sjg@chromium.org wrote:
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

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 ---
(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.

On Mon, 18 Oct 2021 12:13:17 -0600 Simon Glass sjg@chromium.org 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

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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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 ---
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 | 63 ++++++++++++++++++++++++++++++++ 8 files changed, 243 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..9efb8f07b9f --- /dev/null +++ b/scripts/env2string.awk @@ -0,0 +1,63 @@ +# 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, "^([^ =][^ =]*)=(.*)", 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 (match(var, "(.*)[+]$", var_arr)) { + var = var_arr[1] + env = vars[var] env + } + } else { + # Change newline to \n + env = env "\n" $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) { + print var "=" vars[var] "\0" + } + print ""\n" + } +}

Dear Simon,
In message 20211018121315.v8.4.Ie78bfbfca0d01d9cba501e127f446ec48e1f7afe@changeid you wrote:
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 environment variables may not end in +
This makes not really clear that the restriction is on the name (and not the value) of the environment variable.
but can start with other strange characters, including underscore, comma and slash.
I would omit this as it does not provide any relevant information here, and in addition it is misleading as it could be interpreted that such characters are only legal at the start of the variable name. But you can do:
=> setenv .-^-. foo => printenv .-^-. .-^-.=foo
Best regards,
Wolfgang Denk

On Mon, Oct 18, 2021 at 12:13:18PM -0600, Simon Glass 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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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
As much as I and others appreciate that you've written the parser here in a classic UNIX tool, awk, since a lot of the problems also seem to stem from having the parser be able to handle previously valid environment variables, if this was written in Python say, would we have this problem?

Hi Tom,
On Tue, 19 Oct 2021 at 08:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 18, 2021 at 12:13:18PM -0600, Simon Glass 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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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
As much as I and others appreciate that you've written the parser here in a classic UNIX tool, awk, since a lot of the problems also seem to stem from having the parser be able to handle previously valid environment variables, if this was written in Python say, would we have this problem?
Well ideally I'd like to avoid Python in this case as it is in the compilation path. I am not sure yet what Wolfgang actually wants, apart from variable names ending with + which I would like to disallow.
So if we can clearly understand the goal, then we might be able to do it in awk, but, again, can we just disallow '+' in var names ?
Regards, Simon

On Tue, Oct 19, 2021 at 08:11:08AM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 19 Oct 2021 at 08:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 18, 2021 at 12:13:18PM -0600, Simon Glass 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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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
As much as I and others appreciate that you've written the parser here in a classic UNIX tool, awk, since a lot of the problems also seem to stem from having the parser be able to handle previously valid environment variables, if this was written in Python say, would we have this problem?
Well ideally I'd like to avoid Python in this case as it is in the compilation path. I am not sure yet what Wolfgang actually wants, apart from variable names ending with + which I would like to disallow.
So if we can clearly understand the goal, then we might be able to do it in awk, but, again, can we just disallow '+' in var names ?
If we say that everything that's valid in the environment today needs to continue to be valid, so that includes '+' and only disallowing '=' and NUL as Wolfgang has said, can you update the awk parser to handle it?

Hi Tom,
On Tue, 19 Oct 2021 at 08:25, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 19, 2021 at 08:11:08AM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 19 Oct 2021 at 08:07, Tom Rini trini@konsulko.com wrote:
On Mon, Oct 18, 2021 at 12:13:18PM -0600, Simon Glass 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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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
As much as I and others appreciate that you've written the parser here in a classic UNIX tool, awk, since a lot of the problems also seem to stem from having the parser be able to handle previously valid environment variables, if this was written in Python say, would we have this problem?
Well ideally I'd like to avoid Python in this case as it is in the compilation path. I am not sure yet what Wolfgang actually wants, apart from variable names ending with + which I would like to disallow.
So if we can clearly understand the goal, then we might be able to do it in awk, but, again, can we just disallow '+' in var names ?
If we say that everything that's valid in the environment today needs to continue to be valid, so that includes '+' and only disallowing '=' and NUL as Wolfgang has said, can you update the awk parser to handle it?
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
We can allow it in the middle of the var name if you like.
Regards, Simon

Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=+fred assignes the value "+fred" var=++fred appends "+fred"
Best regards,
Wolfgang Denk

Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
er...
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all. It requires an escape for a common case and is very confusing.
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
Regards, Simon

On Tue, Oct 19, 2021 at 10:24:25AM -0600, Simon Glass wrote:
Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
er...
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
With the assumption that the append operator is "=+" and NOT "+=" then yes, your examples are unambiguous because = is not allowed in variable names, before and after.
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all. It requires an escape for a common case and is very confusing.
Wait saying we'll add "+SOMETHING" is a common case?
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing.

Hi Tom,
On Tue, 19 Oct 2021 at 10:30, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 19, 2021 at 10:24:25AM -0600, Simon Glass wrote:
Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
er...
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
With the assumption that the append operator is "=+" and NOT "+=" then yes, your examples are unambiguous because = is not allowed in variable names, before and after.
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all. It requires an escape for a common case and is very confusing.
Wait saying we'll add "+SOMETHING" is a common case?
Yes we have places where we add to env vars depending on CONFIG settings.
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing.
Me neither. I started hearing Voltaire's admonition ringing in my head a few emails back.
The way I have this, is it fairly trivial to convert an existing script to a text file. I suspect it can be done automatically but I have not actually tried it. I'd really like to keep it simple. I also want to invoke the 'if you are not in mainline you don't exist' maxim at this point.
Regards, Simon

On Tue, Oct 19, 2021 at 10:39:55AM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 19 Oct 2021 at 10:30, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 19, 2021 at 10:24:25AM -0600, Simon Glass wrote:
Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
er...
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
With the assumption that the append operator is "=+" and NOT "+=" then yes, your examples are unambiguous because = is not allowed in variable names, before and after.
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all. It requires an escape for a common case and is very confusing.
Wait saying we'll add "+SOMETHING" is a common case?
Yes we have places where we add to env vars depending on CONFIG settings.
Yes, but what requires escape is we want "var" to evaluate to or append the string "+fred". Not append "fred" which is common.
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing.
Me neither. I started hearing Voltaire's admonition ringing in my head a few emails back.
The way I have this, is it fairly trivial to convert an existing script to a text file. I suspect it can be done automatically but I have not actually tried it. I'd really like to keep it simple. I also want to invoke the 'if you are not in mainline you don't exist' maxim at this point.
I really want to see the non-trivially-constructed case where "+" is at the end of a variable today. If we can support it in the middle, yes, I can see how there might be example of that in use today.

Hi Tom,
On Tue, 19 Oct 2021 at 10:44, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 19, 2021 at 10:39:55AM -0600, Simon Glass wrote:
Hi Tom,
On Tue, 19 Oct 2021 at 10:30, Tom Rini trini@konsulko.com wrote:
On Tue, Oct 19, 2021 at 10:24:25AM -0600, Simon Glass wrote:
Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:20, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ1p6ueRhDsgBZGMXFhgv7UhRFA1UfvoHGGd0-136oTgvA@mail.gmail.com you wrote:
But how do we handle this?
var+=fred
Is this appending to var or assigning to var+ ?
It is assigning to "var+".
er...
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
With the assumption that the append operator is "=+" and NOT "+=" then yes, your examples are unambiguous because = is not allowed in variable names, before and after.
I think we should not change what is old and might be in use.
It is much easier to change what is new and can be defined at will.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all. It requires an escape for a common case and is very confusing.
Wait saying we'll add "+SOMETHING" is a common case?
Yes we have places where we add to env vars depending on CONFIG settings.
Yes, but what requires escape is we want "var" to evaluate to or append the string "+fred". Not append "fred" which is common.
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing.
Me neither. I started hearing Voltaire's admonition ringing in my head a few emails back.
The way I have this, is it fairly trivial to convert an existing script to a text file. I suspect it can be done automatically but I have not actually tried it. I'd really like to keep it simple. I also want to invoke the 'if you are not in mainline you don't exist' maxim at this point.
I really want to see the non-trivially-constructed case where "+" is at the end of a variable today. If we can support it in the middle, yes, I can see how there might be example of that in use today.
OK it is supported in the middle at present.
This produces no output for me:
git grep +=include/configs/
I'll add some tests, deal with the comments from Marek and send v9.
Regards, Simon

Dear Simon,
In message CAPnjgZ00MfCPTpUkD_=dgC463ve4cqXj0c=2xFEYX2yqtsEk8w@mail.gmail.com you wrote:
Wait saying we'll add "+SOMETHING" is a common case?
Yes we have places where we add to env vars depending on CONFIG settings.
Yes, but how many places are there where the appended value starts with a '+' ?
The way I have this, is it fairly trivial to convert an existing script to a text file. I suspect it can be done automatically but I have not actually tried it. I'd really like to keep it simple. I also want to invoke the 'if you are not in mainline you don't exist' maxim at this point.
In which way is "+=" easier to parse than "=+"? The only extension you have to make is for the "=[^+]" case to check the first charater of the value: if it is a backslash, then ignore it.
This has zero influence on doing this manually or automatic.
Best regards,
Wolfgang Denk

Dear Tom,
In message 20211019163000.GI7964@bill-the-cat you wrote:
I'm not sure I like saying the operator is "=+" rather than "+=" because "=+" is a less commonly seen operator and tends to be an alternative appends for special cases / side-effects / position in parsing.
I fully agree that "+=" would be nicer. But it has issues, which "=+" does not have.
Best regards,
Wolfgang Denk

Dear Simon,
In message CAPnjgZ0RiiCuOgxce1mRv=GLzadWfvq6cgn0oHeSfhXrCOZR9Q@mail.gmail.com you wrote:
var++=fred
is unambiguous but very confusing. I think it would be better to disallow +
It's neither unambiguous nor confusing. It is assigning to "var++".
What? Can you read that again?
Did so, but didn't get what you might mean?
In the "<name><operator><value>" syntax there is no way to define an operator that starts with a character that is legal at the end o a name. Especially since usual escape characters like backslash are also valid characters in a name.
So if you want to maintain the status quo for variable names, you must use an operator that has no such needs.
It is much easier to change what is new and can be defined at will.
i. e. define an operator that is stil trivial to parse (as in an awk script) and does not clash with name rules.
If we define for example that "<name>=+<value>" appends, then we can also define our own escape rules, for example:
var=fred assigns var=+fred appends "fred" var=\+fred assignes the value "+fred" var=++fred appends "+fred"
I don't like that at all.
Why not?
Yes, "=+" may be less intuitive than "+=", but then, it's a new feature, it is esy to use, and it does not clash with any potentially existing environments.
It requires an escape for a common case and
Well, I think if appending a value that starts with a '+' charecter is a "common case", then variable names ending ith a '+' are common case, too.
And at least my proposal can handle all situations I can think of in a somewhat reasonable way, and it does not need to place new restrictions on variable names.
is very confusing.
Is it?
Since people will be converting their out-of-tree scripts anyway, they can check for this sort of madness at the time. There should be no problem.
Agreed. There should be no problem with my proposal - the last 2 of the 4 example aboves are pathological situations which will not happen often.
Best regards,
Wolfgang Denk

Dear Simon,
In message CAPnjgZ3THSM=TYvkGQJanmD0SwUzWsmcYWTG=vUaHiqFje3VfQ@mail.gmail.com you wrote:
Well ideally I'd like to avoid Python in this case as it is in the compilation path. I am not sure yet what Wolfgang actually wants, apart from variable names ending with + which I would like to disallow.
So if we can clearly understand the goal, then we might be able to do it in awk, but, again, can we just disallow '+' in var names ?
My goal is to have a parser that does not place new restrictions on an ancient interface. The first step would probably be to define a clear syntax description.
Eventually this would be also more allowing for variations in white space, so that "<name>=<value>" could also be written as "<name> = <value>". ....which in turn would allow for
foo+ = bar vs. foo += bar .
Just my 2¢...
Best regards,
Wolfgang Denk

Hi Wolfgang,
On Tue, 19 Oct 2021 at 10:05, Wolfgang Denk wd@denx.de wrote:
Dear Simon,
In message CAPnjgZ3THSM=TYvkGQJanmD0SwUzWsmcYWTG=vUaHiqFje3VfQ@mail.gmail.com you wrote:
Well ideally I'd like to avoid Python in this case as it is in the compilation path. I am not sure yet what Wolfgang actually wants, apart from variable names ending with + which I would like to disallow.
So if we can clearly understand the goal, then we might be able to do it in awk, but, again, can we just disallow '+' in var names ?
Re lex..
I cannot imagine why we would want to use that, given that we want to include the environment literally, so far as possible.
Anyway, if we did we would presumably have symbols for + and += so how would that help with the ambiguity I mentioned?
My goal is to have a parser that does not place new restrictions on an ancient interface. The first step would probably be to define a clear syntax description.
Eventually this would be also more allowing for variations in white space, so that "<name>=<value>" could also be written as "<name> = <value>". ....which in turn would allow for
foo+ = bar
vs. foo += bar .
Just my 2¢...
I think we're up to about $12 at this point :-)
But then how do you add a space to an env variable? At the moment you can do:
bootargs=fred #ifdef CONFIG_SOMETHING bootargs+= more #endif
Regards, Simon

Dear Tom,
In message 20211019140711.GC7964@bill-the-cat you wrote:
As much as I and others appreciate that you've written the parser here in a classic UNIX tool, awk, since a lot of the problems also seem to stem from having the parser be able to handle previously valid environment variables, if this was written in Python say, would we have this problem?
A classic tool would be lex ...
Best regards,
Wolfgang Denk

On Mon, 18 Oct 2021 12:13:18 -0600 Simon Glass sjg@chromium.org 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 environment variables may not end in + but can start with other strange characters, including underscore, comma and slash.
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
Tested on Turris Omnia, but we use distroboot, so will convert only after distroboot is supported.

Use a text file for the environment instead of the #define settings.
Signed-off-by: Simon Glass sjg@chromium.org ---
(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

On Mon, 18 Oct 2021 12:13:19 -0600 Simon Glass sjg@chromium.org wrote:
--- /dev/null +++ b/board/sandbox/sandbox.env @@ -0,0 +1,25 @@ +stdin=serial +#ifdef CONFIG_SANDBOX_SDL +stdin+=,cros-ec-keyb,usbkbd
this was CONFIG_KEYBOARD and now is CONFIG_SANDBOX_SDL, is this okay?

Hi Marek,
On Tue, 19 Oct 2021 at 08:32, Marek Behún marek.behun@nic.cz wrote:
On Mon, 18 Oct 2021 12:13:19 -0600 Simon Glass sjg@chromium.org wrote:
--- /dev/null +++ b/board/sandbox/sandbox.env @@ -0,0 +1,25 @@ +stdin=serial +#ifdef CONFIG_SANDBOX_SDL +stdin+=,cros-ec-keyb,usbkbd
this was CONFIG_KEYBOARD and now is CONFIG_SANDBOX_SDL, is this okay?
The old code is:
#ifdef CONFIG_SANDBOX_SDL #define LCD_BPP LCD_COLOR16 #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
so really the check is on CONFIG_SANDBOX_SDL. The setting of CONFIG_KEYBOARD is not related to the environment.
Regards, Simon

On Tue, 19 Oct 2021 09:52:14 -0600 Simon Glass sjg@chromium.org wrote:
Hi Marek,
On Tue, 19 Oct 2021 at 08:32, Marek Behún marek.behun@nic.cz wrote:
On Mon, 18 Oct 2021 12:13:19 -0600 Simon Glass sjg@chromium.org wrote:
--- /dev/null +++ b/board/sandbox/sandbox.env @@ -0,0 +1,25 @@ +stdin=serial +#ifdef CONFIG_SANDBOX_SDL +stdin+=,cros-ec-keyb,usbkbd
this was CONFIG_KEYBOARD and now is CONFIG_SANDBOX_SDL, is this okay?
The old code is:
#ifdef CONFIG_SANDBOX_SDL #define LCD_BPP LCD_COLOR16 #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
so really the check is on CONFIG_SANDBOX_SDL. The setting of CONFIG_KEYBOARD is not related to the environment.
Ah, sorry. In that case
Reviewed-by: Marek Behún marek.behun@nic.cz

Add mention of this option this it does a similar thing to the text environment.
Suggested-by: Rasmus Villemoes rasmus.villemoes@prevas.dk
Signed-off-by: Simon Glass sjg@chromium.org ---
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.

On Mon, 18 Oct 2021 12:13:20 -0600 Simon Glass sjg@chromium.org wrote:
Add mention of this option this it does a similar thing to the text environment.
Strange wording.
Suggested-by: Rasmus Villemoes rasmus.villemoes@prevas.dk
Signed-off-by: Simon Glass sjg@chromium.org
Extra newline.
Other than that
Reviewed-by: Marek Behún marek.behun@nic.cz

Hi Marek,
On Tue, 19 Oct 2021 at 08:34, Marek Behún marek.behun@nic.cz wrote:
On Mon, 18 Oct 2021 12:13:20 -0600 Simon Glass sjg@chromium.org wrote:
Add mention of this option this it does a similar thing to the text environment.
Strange wording.
I say that a lot :-)
https://ludwig.guru/s/add+mention
Regards, Simon

On Tue, 19 Oct 2021 09:52:17 -0600 Simon Glass sjg@chromium.org wrote:
Hi Marek,
On Tue, 19 Oct 2021 at 08:34, Marek Behún marek.behun@nic.cz wrote:
On Mon, 18 Oct 2021 12:13:20 -0600 Simon Glass sjg@chromium.org wrote:
Add mention of this option this it does a similar thing to the text environment.
Strange wording.
I say that a lot :-)
I am talking about "of this option this it does" shouldn't it be "of this option that it does" ?

Hi Marek,
On Tue, 19 Oct 2021 at 10:07, Marek Behún marek.behun@nic.cz wrote:
On Tue, 19 Oct 2021 09:52:17 -0600 Simon Glass sjg@chromium.org wrote:
Hi Marek,
On Tue, 19 Oct 2021 at 08:34, Marek Behún marek.behun@nic.cz wrote:
On Mon, 18 Oct 2021 12:13:20 -0600 Simon Glass sjg@chromium.org wrote:
Add mention of this option this it does a similar thing to the text environment.
Strange wording.
I say that a lot :-)
I am talking about "of this option this it does" shouldn't it be "of this option that it does" ?
OK, got it.
Thanks, Simon

Make various updates suggested during review of the rST conversion.
Signed-off-by: Simon Glass sjg@chromium.org 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

On Mon, 18 Oct 2021 12:13:21 -0600 Simon Glass sjg@chromium.org wrote:
Make various updates suggested during review of the rST conversion.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Wolfgang Denk wd@denx.de
Reviewed-by: Marek Behún marek.behun@nic.cz

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 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 | 4 ++-- env/common.c | 7 +++++++ include/env.h | 7 +++++++ 6 files changed, 19 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..b14019179dd 100644 --- a/doc/usage/environment.rst +++ b/doc/usage/environment.rst @@ -165,8 +165,8 @@ 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 anything other than "yes", 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..ef9502a34f7 100644 --- a/env/common.c +++ b/env/common.c @@ -47,6 +47,13 @@ int env_get_yesno(const char *var) 1 : 0; }
+bool env_get_autostart(void) +{ + const char *val = env_get("autostart"); + + return val && !strcmp(val, "yes"); +} + /* * 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 *

On Mon, 18 Oct 2021 12:13:22 -0600 Simon Glass sjg@chromium.org wrote:
+bool env_get_autostart(void) +{
- const char *val = env_get("autostart");
- return val && !strcmp(val, "yes");
+}
Why not use env_get_yesno() ?

Dear Simon,
In message 20211018181322.1181847-1-sjg@chromium.org you wrote:
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.
Again, slash missing. This should be board/<vendor>/<board>.env , right?
But that's only the cover letter...
Best regards,
Wolfgang Denk
participants (4)
-
Marek Behún
-
Simon Glass
-
Tom Rini
-
Wolfgang Denk