Hi Tim,
On 19.03.21 19:40, Tim Harvey wrote:
On Fri, Mar 19, 2021 at 10:17 AM Stefano Babic <sba...@denx.de> wrote:
Hi Tim,
On 19.03.21 16:50, Tim Harvey wrote:
Greetings,
I'm looking at using SWUpdate to facilitate an A/B ping-pong method of
firmware updates where a state is stored in U-Boot env by the SWUpdate
postinst script.
You do not need a postinstall script, yoiu just add the environment to
the "bootenv" section in sw-description.
I'm using the postinst script to determine the root partition and
write it, so there is some intelligence there. The generic
instructions I put together to demonstrate this setup are at
http://trac.gateworks.com/wiki/buildroot#SWUpdate which likely
explains best what I'm doing.
If this can help...
Your setup forbids streaming (installed-directly = true for each
artifact), and the images are first extracted into /tmp before installing.
If this can help, I have recently exported a global "getroot" lua
function that can be called from sw-description.
I'm needing to use secure boot with U-Boot's verified boot support and
am not clear how, if at all, the U-Boot env can be authenticated.
Is there any authentication support within a flash stored U-boot
environment that is supported by fw_setenv and if not what is the
recommendation for removing environment and are there any other
suggestions for an SWUpdate postinstall script to select the OS image
to boot after an update?
There is no authentication in U-Boot - I supposed to add a signed
environment to U-Boot, but then U-Boot won't be able save the env
because a "saveenv" requires a private key.
The current solution is to use CONFIG_ENV_WRITEABLE_LIST. You have a
short list (I use just one) of variables that are allowed to be changed,
while the complete environment is added via CONFIG_EXTRA_ENV and,
because it is linked to u-boot, is signed as well. If you set your
script to depend on just one variable to select if A or B can run, you
can be sure that the rest of environment cannot be compromised. You
should also set flags for the variable to be sure that it is not changed
to be a script (just integer are accepted).
Thanks - I was not aware of this feature. This looks like it would work well.
So for my case I'm toggling 'mmcbootpart' from a '2' to a '3' in
postinst so I suppose in U-Boot I would:
CONFIG_ENV_WRITEABLE_LIST=y
CONFIG_ENV_FLAGS_LIST_DEFAULT=mmcbootpart:d
and make sure my compiled in env a minimal bootcmd that uses
mmcbootpart as the only variable.
when CONFIG_ENV_WRITEABLE_LIST=y do all other env vars defined in
built-in-env get automatically flagged as non-writable?
Yes, only variables in the list can be modified.
and regardless of what modifications are done to the flash backed env
(via something like fw_setenv for example) are the only vars that get
merged into the runtime env hashtable those defined in
CONFIG_ENV_FLAGS_LIST_DEFAULT?
Right - you can write whatever you want via SWUpdate or fw_setenv, but
U-Boot takes just the variables in the list and discards the other ones.
Another solution is to use CONFIG_ENV_EMBEDDED and to switch via the
ssbl_hanlder in SWUpdate. Anyway, support for this easy "switcher" is
not present in U-Boot and should be added. This left the whole
environment untouched, and the selection between A/B is done via an
external structure.
Sounds like your previous solution works well enough.
Best regards,
Stefano
