[PATCH 0/2] Import environment variables from FIT configuration
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
Lukas Funke (2): env: Add function to import environment variables from FIT conf node test: fit: Add test to check environment extraction from FIT conf node
boot/image-fit.c | 4 ++++ configs/sandbox_defconfig | 1 + env/Kconfig | 10 +++++++++ env/common.c | 28 ++++++++++++++++++++++++ include/env.h | 11 ++++++++++ test/py/tests/test_fit.py | 45 +++++++++++++++++++++++++++++++++++++++ 6 files changed, 99 insertions(+)
From: Lukas Funke lukas.funke@weidmueller.com
Add function which reads properties from FIT conf node prefixed with "env,". Import property name (without 'env,') and it's value as runtime environment variables.
Note: this only works with string properties
Example:
configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,foo = "somevalue"; env,bar = "someothervalue"; }; };
=> env print foo foo=somevalue
Signed-off-by: Lukas Funke lukas.funke@weidmueller.com ---
boot/image-fit.c | 4 ++++ env/Kconfig | 10 ++++++++++ env/common.c | 28 ++++++++++++++++++++++++++++ include/env.h | 11 +++++++++++ 4 files changed, 53 insertions(+)
diff --git a/boot/image-fit.c b/boot/image-fit.c index 89e377563ce..0ca31c5f851 100644 --- a/boot/image-fit.c +++ b/boot/image-fit.c @@ -34,6 +34,7 @@ DECLARE_GLOBAL_DATA_PTR; #endif /* !USE_HOSTCC*/
+#include <env.h> #include <bootm.h> #include <image.h> #include <bootstage.h> @@ -2128,6 +2129,9 @@ int fit_image_load(struct bootm_headers *images, ulong addr, puts("OK\n"); }
+#if !defined(USE_HOSTCC) + env_import_fit_conf(fit, cfg_noffset); +#endif bootstage_mark(BOOTSTAGE_ID_FIT_CONFIG);
noffset = fit_conf_get_prop_node(fit, cfg_noffset, prop_name, diff --git a/env/Kconfig b/env/Kconfig index 1f8e90af55e..01b802e54b9 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -748,6 +748,16 @@ config ENV_FDT_PATH help The initial value of the env_fdt_path variable.
+config ENV_IMPORT_FIT_CONF + bool "Amend environment by FIT configuration node properties" + depends on OF_CONTROL + help + If selected, after the environment has been loaded from its + persistent location, the "env,*" properties in the conf-node + of FIT image are used to update the run-time environment. This + can be useful in order to transport signed environment variables + to the kernel cmdline. + config ENV_APPEND bool "Always append the environment with new data" help diff --git a/env/common.c b/env/common.c index 48a565107c1..c8aa59447e9 100644 --- a/env/common.c +++ b/env/common.c @@ -24,6 +24,7 @@ #include <dm/ofnode.h> #include <net.h> #include <watchdog.h> +#include <fdt_support.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -661,3 +662,30 @@ void env_import_fdt(void) } } #endif + +#define FIT_CONF_ENV_PROPERTY_PREFIX "env," +void env_import_fit_conf(const void *fdt, int conf_node) +{ + int offset, len; + const char *name; + const void *value; + const struct fdt_property *property; + + if (!CONFIG_IS_ENABLED(ENV_IMPORT_FIT_CONF)) + return; + + fdt_for_each_property_offset(offset, fdt, conf_node) { + property = fdt_get_property_by_offset(fdt, offset, NULL); + + name = fdt_get_string(fdt, fdt32_to_cpu(property->nameoff), NULL); + if (strncmp(name, FIT_CONF_ENV_PROPERTY_PREFIX, + sizeof(FIT_CONF_ENV_PROPERTY_PREFIX) - 1)) + continue; + + value = fdt_getprop(fdt, conf_node, name, &len); + /* Get the actual variable name "env,somename" -> "somename" */ + name += sizeof(FIT_CONF_ENV_PROPERTY_PREFIX) - 1; + + env_set(name, value); + } +} diff --git a/include/env.h b/include/env.h index d2a5954ded8..fa4c67056e7 100644 --- a/include/env.h +++ b/include/env.h @@ -382,4 +382,15 @@ void env_import_fdt(void); static inline void env_import_fdt(void) {} #endif
+/** + * env_import_fit_conf() - Import environment values from FIT configuration node + * + * This imports environment variables from FIT configuration node. Each + * property name starting with an "env,"-prefix is imported as variable where + * the variable name is the suffix of the property name. + * + * Example: env,somevalue = "foobar" --> somevalue=foobar + */ +void env_import_fit_conf(const void *fdt, int conf_node); + #endif
From: Lukas Funke lukas.funke@weidmueller.com
Add test which adds environment variables to the FIT configuration node and checks whether they are exported to the runtime environment.
Signed-off-by: Lukas Funke lukas.funke@weidmueller.com ---
configs/sandbox_defconfig | 1 + test/py/tests/test_fit.py | 45 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 93b52f2de5c..7431c8a910e 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -142,6 +142,7 @@ CONFIG_ENV_IS_IN_EXT4=y CONFIG_ENV_EXT4_INTERFACE="host" CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0" CONFIG_ENV_IMPORT_FDT=y +CONFIG_ENV_IMPORT_FIT_CONF=y CONFIG_BOOTP_SEND_HOSTNAME=y CONFIG_NETCONSOLE=y CONFIG_IP_DEFRAG=y diff --git a/test/py/tests/test_fit.py b/test/py/tests/test_fit.py index 8f9c4b26411..2a3aba74502 100755 --- a/test/py/tests/test_fit.py +++ b/test/py/tests/test_fit.py @@ -74,6 +74,8 @@ base_its = ''' fdt = "fdt-1"; %(ramdisk_config)s %(loadables_config)s + %(env_var0)s + %(env_var1)s }; }; }; @@ -308,6 +310,13 @@ def test_fit(u_boot_console):
'loadables_config' : '', 'compression' : 'none', + + 'env_var0': '', + 'env_var0_name': 'foo', + 'env_var0_value': 'somevalue', + 'env_var1': '', + 'env_var1_name': 'bar', + 'env_var1_value': 'anothervalue', }
# Make a basic FIT and a script to load it @@ -396,6 +405,42 @@ def test_fit(u_boot_console): check_not_equal(ramdisk, ramdisk_out, 'Ramdisk got decompressed?') check_equal(ramdisk + '.gz', ramdisk_out, 'Ramdist not loaded')
+ # Now a kernel, FDT and environment variables + with cons.log.section('Kernel + FDT load + env'): + params['fdt_load'] = 'load = <%#x>;' % params['fdt_addr'] + params['env_var0'] = ('env,%s = "%s";' % + (params['env_var0_name'], + params['env_var0_value'])) + params['env_var1'] = ('env,%s = "%s";' % + (params['env_var1_name'], + params['env_var1_value'])) + fit = fit_util.make_fit(cons, mkimage, base_its, params) + cons.restart_uboot() + + output = cons.run_command_list(cmd.splitlines()) + check_equal(kernel, kernel_out, 'Kernel not loaded') + check_equal(control_dtb, fdt_out, 'FDT not loaded') + check_not_equal(ramdisk, ramdisk_out, + 'Ramdisk loaded but should not be') + + # Check if bootargs strings substitution works + output = cons.run_command_list([ + 'env set bootargs \"'my_boot_var=${%s}'\"' % params['env_var0_name'], + 'bootm prep', + 'env print %s' % params['env_var0_name'], + 'env print %s' % params['env_var1_name'], + 'env print bootargs']) + assert ('%s=%s' % + (params['env_var0_name'], + params['env_var0_value'])) \ + in output, "Environment not loaded from configuration" + assert ('%s=%s' % + (params['env_var1_name'], + params['env_var1_value'])) \ + in output, "Environment not loaded from configuration" + assert 'bootargs="my_boot_var=%s"' % params['env_var0_value'] \ + in output, "Bootargs strings not substituted" +
cons = u_boot_console # We need to use our own device tree file. Remember to restore it
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
Cheers, Quentin
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts per default. I would also change current behaviour. For env variables I see no harm.
Please let me know what you think.
Cheers - Lukas
Cheers, Quentin
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
per default. I would also change current behaviour. For env variables I see no harm.
If the env properties in the FIT image are part of the checksum and signature of the conf node, which is necessary for secure boot, I guess "no harm" fits the bill.
Cheers, Quentin
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or a bad thing, but makes things definitely more complicated.
per default. I would also change current behaviour. For env variables I see no harm.
If the env properties in the FIT image are part of the checksum and signature of the conf node, which is necessary for secure boot, I guess "no harm" fits the bill.
To my current knowledge the configuration node itself is signed. Thus, all env-properties are signed. Please correct me if I'm wrong.
Cheers, Quentin
Hi Lukas,
On 7/2/24 2:58 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or a bad thing, but makes things definitely more complicated.
Yes, but this isn't an indirection the project has to support. We currently support scripts that are in the images node to source. We would need to support automatically running the script if it's in a conf node and that'd be it.
To be clear, I am not blocking this (and I don't have any veto power anyway :) ), just wanted to raise that something else already exists and could be extended to fit your usecase.
Cheers, Quentin
Hi Quentin,
On 02.07.2024 15:05, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 2:58 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or a bad thing, but makes things definitely more complicated.
Yes, but this isn't an indirection the project has to support. We currently support scripts that are in the images node to source. We would need to support automatically running the script if it's in a conf node and that'd be it.
To be clear, I am not blocking this (and I don't have any veto power anyway :) ), just wanted to raise that something else already exists and could be extended to fit your usecase.
Thanks for the clarification, I appreciate your input.
Yeah, I guess it works somehow using the current 'source'-cmd approach. Yocto even supports the integration of a U-Boot environment into the kernel FIT-image. However, I think the integration for some dm-vertiy env variables is quite cumbersome using this approach. I'd rather prefer to have the variables directly in the fit-configuration since they have no script character. But this might just be personal preference.
Cheers, Quentin
Hi Lukas,
On Wed, 3 Jul 2024 at 02:29, Lukas Funke lukas.funke-oss@weidmueller.com wrote:
Hi Quentin,
On 02.07.2024 15:05, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 2:58 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote: > From: Lukas Funke lukas.funke@weidmueller.com > > > This series enables U-Boot to import environment variables from the > selectd FIT configuration. One use-case is that the overall build > process > enriches the FIT configuration node with dm-verity information which > should be injected into the kernel commandline. U-Boot will then read > these (possibly signed) environment variables and put them into the > actual Kernel commandline using variable replacement > (see CONFIG_BOOTARGS_SUBST). > > Example: > > Config: > CONFIG_BOOTARGS_SUBST=y > CONFIG_ENV_IMPORT_FIT_CONF=y > > FIT: > configurations { > default = "conf-1"; > conf-1 { > kernel = "kernel-1"; > fdt = "fdt-1"; > env,dm-verity-args = "dm-mod.create=..."; > env,bar = "someothervalue"; > }; > }; > > U-Boot cmdline: > => env set bootargs="rootfstype=squashfs root=/dev/xyz > ${dm-verity-args} ro" > => boot > > Kernel cmdline: > Kernel command line: rootfstype=squashfs ... dm-mod.create= ... > >
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or a bad thing, but makes things definitely more complicated.
Yes, but this isn't an indirection the project has to support. We currently support scripts that are in the images node to source. We would need to support automatically running the script if it's in a conf node and that'd be it.
To be clear, I am not blocking this (and I don't have any veto power anyway :) ), just wanted to raise that something else already exists and could be extended to fit your usecase.
Thanks for the clarification, I appreciate your input.
Yeah, I guess it works somehow using the current 'source'-cmd approach. Yocto even supports the integration of a U-Boot environment into the kernel FIT-image. However, I think the integration for some dm-vertiy env variables is quite cumbersome using this approach. I'd rather prefer to have the variables directly in the fit-configuration since they have no script character. But this might just be personal preference.
This ended up in my queue.
Is this used with boot scripts? We are trying to move boards to bootstd and get rid of the scripts, for common cases.
If you are wanting to specify the verity hash, I think it would be better to add that information. VBE[1] has the concept of 'OS requests' - see static bootmeth_vbe_ft_fixup() for the implementation.
Here it seems we have a request for the verity hash? So can we add it that way? Are there any other features you are needed?
Using environment variables seems a bit ad-hoc to me.
Regards, Simon
participants (4)
-
Lukas Funke -
lukas.funke-oss＠weidmueller.com
-
Quentin Schulz -
Simon Glass