From 5e41a5deb4b843808f3c892f2f54f1b9c76b3da1 Mon Sep 17 00:00:00 2001 From: James Hilliard Date: Mon, 11 May 2026 12:20:25 -0600 Subject: env: migrate static flags list to Kconfig Environment callbacks can already be configured from Kconfig with CONFIG_ENV_CALLBACK_LIST_STATIC, but static environment flags still require board headers to define CFG_ENV_FLAGS_LIST_STATIC. Add CONFIG_ENV_FLAGS_LIST_STATIC and use it as the only board-provided static environment flags list. Convert the remaining default-config users from CFG_ENV_FLAGS_LIST_STATIC to defconfig settings and drop the legacy header macro from ENV_FLAGS_LIST_STATIC. Move the environment flags format documentation out of README and into the developer environment documentation. Include the format in the Kconfig help as well. This lets boards configure writeable-list policy and type validation from defconfig without adding a config header solely for env flags. This preserves the behavior of default configs. Header-only cases that were inactive in upstream defconfigs are not converted into defconfig entries: iot2050 can add its list when enabling ENV_WRITEABLE_LIST, and smegw01 can add mmcdev:dw support if the unlocked SYS_BOOT_LOCKED=n configuration is needed. Signed-off-by: James Hilliard Reviewed-by: Tom Rini Reviewed-by: Simon Glass Reviewed-by: Alexander Sverdlin Reviewed-by: Walter Schweizer --- doc/develop/environment.rst | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'doc/develop') diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst index e46cd39d601..a7ed4aab0a5 100644 --- a/doc/develop/environment.rst +++ b/doc/develop/environment.rst @@ -49,3 +49,43 @@ The signature of the callback functions is:: include/search.h The return value is 0 if the variable change is accepted and 1 otherwise. + +Flags for environment variables +------------------------------- + +Environment flags validate the values given to environment variables and +restrict how environment variables can be changed. + +The static list is configured with CONFIG_ENV_FLAGS_LIST_STATIC. The list +must be in the following format:: + + type_attribute = [s|d|x|b|i|m] + access_attribute = [a|r|o|c|w] + attributes = type_attribute[access_attribute] + entry = variable_name[:attributes] + list = entry[,list] + +The type attributes are: + +* s - String (default) +* d - Decimal +* x - Hexadecimal +* b - Boolean ([1yYtT|0nNfF]) +* i - IP address, if networking is enabled +* m - MAC address, if networking is enabled + +The access attributes are: + +* a - Any (default) +* r - Read-only +* o - Write-once +* c - Change-default +* w - Writeable, if CONFIG_ENV_WRITEABLE_LIST is enabled + +CONFIG_ENV_FLAGS_LIST_DEFAULT defines the ``.flags`` variable in the +default or embedded environment. Any association in ``.flags`` overrides +an association in the static list. + +If CONFIG_REGEX is defined, the variable name is evaluated as a regular +expression. This allows multiple variables to define the same flags without +explicitly listing them all. -- cgit v1.3.1 From a6369b8bb299aff8d5641fd11d2fcd0214103a18 Mon Sep 17 00:00:00 2001 From: Rasmus Villemoes Date: Tue, 2 Jun 2026 23:30:12 +0200 Subject: doc: develop: add section on embedding scripts inside control DTB Add a section that explains how one can embed scripts in the control DTB and run them from the U-Boot shell, the advantages of doing that compared to using a separately built FIT image, and the configuration knob that must be turned on to allow this to work. Reviewed-by: Simon Glass Signed-off-by: Rasmus Villemoes --- doc/develop/devicetree/control.rst | 58 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'doc/develop') diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst index 634114af59a..7d6117d5c4b 100644 --- a/doc/develop/devicetree/control.rst +++ b/doc/develop/devicetree/control.rst @@ -232,6 +232,64 @@ outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig option to specify a list of .dtsi files that will also be included when building .dtb files. +Scripts embedded in control DTB +------------------------------- + +The `DEVICE_TREE_INCLUDES` option can also be used to make the control +DTB serve double duty as a FIT image. By including a `scripts.dtsi` +file containing something like:: + + / { + images { + default = "boot"; + boot { + description = "Bootscript"; + data = /incbin/("boot.sh"); + type = "script"; + compression = "none"; + }; + factory-reset { + description = "Script for performing factory reset"; + data = /incbin/("factory-reset.sh"); + type = "script"; + compression = "none"; + }; + }; + }; + +one can call those scripts using the `source` command in the U-Boot shell:: + + source ${fdtcontroladdr}:boot + +or just ``source ${fdtcontroladdr}`` for invoking the default. + +Since one does not need to separately build a "real" FIT image +containing those scripts, this simplifies both the build process and +the boot logic, as the latter does not need to first load the FIT +image from storage. + +Another advantage is that when the bootloader and boot script must be +updated together, it is easier to achieve a guaranteed atomic update +when the boot script is embedded inside the U-Boot binary, instead of +stored separately. + +For the above to work, one must enable the `CONTROL_DTB_AS_FIT` config +option, which will (when the address passed to the `source` command is +the address of U-Boot's control DTB) elide certain sanity checks that +are normally done: With the above `.dtsi` snippet, the control DTB +does not quite become a "real" FIT image - it lacks `timestamp` and +`description` properties, but more importantly, FIT images cannot +contain nodes with `@` in their names (unit addresses) anywhere, and +the control DTB obviously does have such nodes. + +This is not a security problem, as the control DTB is necessarily +trusted. In any secure boot setup where the bootloader is verified, +that mechanism must also include verification of the control DTB. So +in fact, since the scripts embedded this way are then also +automatically verified, it simplifies implementation of secure +boot. When using a separate FIT image, one must build it with +appropriate signatures, just as when building a FIT image containing a +kernel/dtb/initramfs. Devicetree bindings schema checks --------------------------------- -- cgit v1.3.1 From fb537c85bca0e3d29a62fe119181bf1744b8c91a Mon Sep 17 00:00:00 2001 From: Ilias Apalodimas Date: Wed, 17 Jun 2026 10:48:25 +0300 Subject: doc: Add a warning about using RELOC_ADDR_TOP Since devices that can't DMA above 4GiB will misbehave with this option enabled add a warning on the documentation. Reviewed-by: Simon Glass Signed-off-by: Ilias Apalodimas Tested-by: Christophe Leroy (CS GROUP) --- doc/develop/memory.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/develop') diff --git a/doc/develop/memory.rst b/doc/develop/memory.rst index 5177229630d..3da39bb6c66 100644 --- a/doc/develop/memory.rst +++ b/doc/develop/memory.rst @@ -111,6 +111,15 @@ U-Boot Proper Flow This follows the same as in SPL flow. In board_init_f(), a part of memory is reserved at the end of RAM (see reserve_* functions in init_sequence_f) + #. Relocation address + + By default U-Boot will try to relocate below the 4GiB boundary. If + RELOC_ADDR_TOP is enabled U-Boot will look into the dram bank config of + gd->dram[] and try to relocate to the highest available bank. Use this + with caution as devices that can only DMA below 4GiB will misbehave + since their buffers may be allocated above the 32-bit boundary. + Boards can override thre relocation address via board_get_usable_ram_top(). + #. Code Relocation relocate_code() is called which relocates U-Boot code from the current -- cgit v1.3.1