Multiple bootenv sections

[Tobias Hebestreit]

Hello everyone,

I use SWUpdate to update different Hardware-Revisions of the same device with a dual-copy strategy.
The bootloader environmnent of all those looks very similar.
However, I have to set the mmc-partition to boot from depending on the active copy and the boot_file
depending on the hardware-revision. To keep the sw-description-file as comprehensive as possible and
to make it easy to maintain I would like to set a "basic" boot-environment for all devices in a first
step and in a second step overwrite some variables depending on hardware-revision and active copy:

software =
{
version = "1.1";
hardware-compatibility = ["0.1","1.0"];

device1=
{
copy-1:
{
images:
(
{
filename = "rootfs.ext3.gz";
device = "/dev/mmcblk0p3";
compressed = true;
},
{
filename = "u-boot-env-base"; #basic boot environment
type = "bootloader";
}
);
bootenv: # device-specific boot variables
(
{
name = "boot_file"
value = "uImage1"
},
{
name = "mmcpart";
value = "3";
}
);
}
}
}

While parsing both bootloader environments are reported but only one is applied or both are, but in the wrong order,
because when checking via fw_printenv the "u-boot-env-base" is unaltered.
I am using
SWUpdate v2018.11.0
U-Boot 2018.09.
I feel that I had this working in an older setup (SWUpdate 2016) and in the documentation I have seen examples that
use an entire u-boot-environment next to u-boot-variables.
What is going wrong here?
Btw. I have asked the very same question on stackoverflow. If you like, you can answer there as well and earn some credits.

[Stefano Babic]

Hi Tobias,

On 04/03/19 11:02, Tobias Hebestreit wrote:
> Hello everyone,
>
> I use SWUpdate to update different Hardware-Revisions of the same device with a dual-copy strategy.
> The bootloader environmnent of all those looks very similar.

Ok

> However, I have to set the mmc-partition to boot from depending on the active copy and the boot_file
> depending on the hardware-revision.

It is a common use case.

> To keep the sw-description-file as comprehensive as possible and
> to make it easy to maintain I would like to set a "basic" boot-environment for all devices in a first
> step and in a second step overwrite some variables depending on hardware-revision and active copy:
>
> software =
> {
> version = "1.1";
> hardware-compatibility = ["0.1","1.0"];
>
> device1=
> {
> copy-1:
> {
> images:
> (
> {
> filename = "rootfs.ext3.gz";
> device = "/dev/mmcblk0p3";
> compressed = true;
> },
> {
> filename = "u-boot-env-base"; #basic boot environment
> type = "bootloader";

SWUpdate supports in last release links, that means you can also
factorize this part to all boards / revisions and put just the
differencies in the specific part.

> }
> );
> bootenv: # device-specific boot variables
> (
> {
> name = "boot_file"

; is missing

> value = "uImage1"
> },
> {
> name = "mmcpart";
> value = "3";
> }
> );
> }
> }
> }
>
> While parsing both bootloader environments are reported but only one is applied or both are, but in the wrong order,
> because when checking via fw_printenv the "u-boot-env-base" is unaltered.

I do not get here - one is applied ? The U-Boot variables *must* be
handled *after* all images are already installed as last step. That
means that u-boot-env-base is not installed first, but variables are
processed and put in a queue together with "bootfile" and "mmcpart". The
whole environment is then updated in one shot to be atomic as last step,
independently how you put them in sw-description. The order does not
play any role.

> I am using
> SWUpdate v2018.11.0
> U-Boot 2018.09.
> I feel that I had this working in an older setup (SWUpdate 2016)

The bootloader handler to install the env from a file did not work for a
while and I fixed in 2018.11, but syntax in file changed - it is now the
same as in U-Boot.

> and in the documentation I have seen examples that
> use an entire u-boot-environment next to u-boot-variables.

Of course, this is a use case. It is definitely supported.

> What is going wrong here?

Which is the error ? I am expecting that if copy-1 is selected,
u-boot-env-base, "bootfile" and "mmcpart" are applied.

> Btw. I have asked the very same question on stackoverflow. If you like, you can answer there as well and earn some credits.

I do not care.

I think that questions should be addressed to the right ML - U-Boot for
relevannt questions, here if they concern to SWUpdate. It coulld be you
get answer from Stackoverflow, too, but I guess you will find less
U-Boot / SWUpdate users.

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Tobias Hebestreit]

Hi Stefano,

thanks for the quick reply!

I love that feature, I am using it already.

>> }
>> );
>> bootenv: # device-specific boot variables
>> (
>> {
>> name = "boot_file"
>
> ; is missing
>

Thank you for spotting that. However, it works fine anyway.

>> value = "uImage1"
>> },
>> {
>> name = "mmcpart";
>> value = "3";
>> }
>> );
>> }
>> }
>> }
>>
>> While parsing both bootloader environments are reported but only one is applied or both are, but in the wrong order,
>> because when checking via fw_printenv the "u-boot-env-base" is unaltered.
>
> I do not get here - one is applied ? The U-Boot variables *must* be
> handled *after* all images are already installed as last step. That
> means that u-boot-env-base is not installed first, but variables are
> processed and put in a queue together with "bootfile" and "mmcpart". The
> whole environment is then updated in one shot to be atomic as last step,
> independently how you put them in sw-description. The order does not
> play any role.

Sorry for not being explicit enough. I am setting some uboot variables
twice in a single update. In the uboot-env-file there is a default value
for a variable eg. "mmcpart 2" and in the bootenv section I am trying to
overwrite that default value with "mmcpart 3".

However, when the same variables is defined in the u-boot-env-file as
well as in the bootenv as a name-value pair, apparently the value in
u-boot-env-file "wins".

->So in the environment of uboot I end up with "mmcpart = 2".

I would like to know what is the desired behaviour, because I was doing
that with SWUpdate 2016.x I believe.

>> I am using
>> SWUpdate v2018.11.0
>> U-Boot 2018.09.
>> I feel that I had this working in an older setup (SWUpdate 2016)
>
> The bootloader handler to install the env from a file did not work for a
> while and I fixed in 2018.11, but syntax in file changed - it is now the
> same as in U-Boot.
>
>> and in the documentation I have seen examples that
>> use an entire u-boot-environment next to u-boot-variables.
>
> Of course, this is a use case. It is definitely supported.
>
>> What is going wrong here?
>
> Which is the error ? I am expecting that if copy-1 is selected,
> u-boot-env-base, "bootfile" and "mmcpart" are applied.
>

Yes they are applied. So there is no problem with that. Only setting
bootloader vars twice in a single update. See above.

>> Btw. I have asked the very same question on stackoverflow. If you like, you can answer there as well and earn some credits.
>
> I do not care.

Ok. I will answer myself in the end.

> I think that questions should be addressed to the right ML - U-Boot for
> relevannt questions, here if they concern to SWUpdate. It coulld be you
> get answer from Stackoverflow, too, but I guess you will find less
> U-Boot / SWUpdate users.

You are right. That is why I got here.

> Best regards,
> Stefano Babic
>
Thank you!
Tobias

[Stefano Babic]

Hallo Tobias,

ok

>>>              }
>>>          );
>>>          bootenv:      #  device-specific boot variables
>>>          (
>>>              {
>>>                  name = "boot_file"
>>
>> ; is missing
>>
> Thank you for spotting that. However, it works fine anyway.

ok

>
>>>                  value = "uImage1"
>>>              },
>>>              {
>>>                  name    = "mmcpart";
>>>                  value   = "3";
>>>              }
>>>          );
>>>      }
>>>      }
>>> }
>>>
>>> While parsing both bootloader environments are reported but only one
>>> is applied or both are, but in the wrong order,
>>>   because when checking via fw_printenv the "u-boot-env-base" is
>>> unaltered.
>>
>> I do not get here - one is applied ?  The U-Boot variables *must* be
>> handled *after* all images are already installed as last step. That
>> means that u-boot-env-base is not installed first, but variables are
>> processed and put in a queue together with "bootfile" and "mmcpart". The
>> whole environment is then updated in one shot to be atomic as last step,
>> independently how you put them in sw-description. The order does not
>> play any role.
>
> Sorry for not being explicit enough. I am setting  some uboot variables
> twice in a single update.

Same variable ? This is not foreseen. As SWUpdate must provide atomic
update, it goes from a state "A" (before update) to a state "B" (after
installing everything). The environment is seen as a shot. U-Boot
variables are just processed as they are found.

> In the uboot-env-file there is a default value
> for a variable eg. "mmcpart 2" and in the bootenv section I am trying to
> overwrite that default value with "mmcpart 3".

Because you set it as file to be processed by the handler, it has
priority on variables put in sw-description, that are processed at
parsing time. You will obtain "mmcpart=2".

>
> However, when the same variables is defined in the u-boot-env-file as
> well as in the bootenv  as a name-value pair, apparently the value in
> u-boot-env-file "wins".

Right, this is the behaviour. As explained, the update is atomic and the
bootloader environment is seen as a whole.

>
> ->So in the environment of uboot I end up with "mmcpart = 2".
>

This is correct.

> I would like to know what is the desired behaviour, because I was doing
> that with SWUpdate 2016.x I believe.

It is.


In SWUpdate 2016.x was wrong. The handler "bootloader" processed all
variables directly. This means that such as a condition was not atomic:

images:
(
{
filename = "rootfs.ext3.gz";
device = "/dev/mmcblk0p3";
compressed = true;
},
{
filename = "u-boot-env-base"; #basic boot environment
type = "bootloader";

},
{
filename = "something else";
device = "somewhereelse";
type = "some handler";
}
);

If "something else" faiuls to be installed, the environemtn with
u-boot-env-base was already set without possibility of fallback - this
is wrong.

On later versions, installing environment from a file was simply broken.
It did not install anything.

This was fixed with 2018.11 - the environment is seen as a whole and set
just once after all images, files and scripts were done.

Anyway, it is enough you drop mmcpart from u-boot-env-base to get what
you want.

>
>
>>> I am using
>>> SWUpdate v2018.11.0
>>> U-Boot 2018.09.
>>> I feel that I had this working in an older setup (SWUpdate 2016)
>>
>> The bootloader handler to install the env from a file did not work for a
>> while and I fixed in 2018.11, but syntax in file changed - it is now the
>> same as in U-Boot.
>>
>>> and in the documentation I have seen examples that
>>> use an entire u-boot-environment next to u-boot-variables.
>>
>> Of course, this is a use case. It is definitely supported.
>>
>>> What is going wrong here?
>>
>> Which is the error ? I am expecting that if copy-1 is selected,
>> u-boot-env-base, "bootfile" and "mmcpart" are applied.
>>
>
> Yes they are applied. So there is no problem with that. Only setting
> bootloader vars twice in a single update. See above.

This is wrong - it is thought to go from state A to state B. The
environment in U-Boot does not allow duplication.

>
>
>>> Btw. I have asked the very same question on stackoverflow. If you
>>> like, you can answer there as well and earn some credits.
>>
>> I do not care.
>
> Ok. I will answer myself in the end.
>
>> I think that questions should be addressed to the right ML - U-Boot for
>> relevannt questions, here if they concern to SWUpdate. It coulld be you
>> get answer from Stackoverflow, too, but I guess you will find less
>> U-Boot / SWUpdate users.
> You are right. That is why I got here.

> Thank you!
> Tobias

[Tobias Hebestreit]

>> Sorry for not being explicit enough. I am setting  some uboot variables
>> twice in a single update.
>
> Same variable ? This is not foreseen. As SWUpdate must provide atomic
> update, it goes from a state "A" (before update) to a state "B" (after
> installing everything). The environment is seen as a shot. U-Boot
> variables are just processed as they are found.
>

Ok.

>> In the uboot-env-file there is a default value
>> for a variable eg. "mmcpart 2" and in the bootenv section I am trying to
>> overwrite that default value with "mmcpart 3".
>
> Because you set it as file to be processed by the handler, it has
> priority on variables put in sw-description, that are processed at
> parsing time. You will obtain "mmcpart=2".

That makes it clear :). I was assuming a reverse priority. I felt so
sure about that because of the wrong behaviour of SWUpdate 2016.

>>
>> However, when the same variables is defined in the u-boot-env-file as
>> well as in the bootenv  as a name-value pair, apparently the value in
>> u-boot-env-file "wins".
>
> Right, this is the behaviour. As explained, the update is atomic and the
> bootloader environment is seen as a whole.
>
>>
>> ->So in the environment of uboot I end up with "mmcpart = 2".
>>
>
> This is correct.

Makes sense now.

>> I would like to know what is the desired behaviour, because I was doing
>> that with SWUpdate 2016.x I believe.
>
> It is.
>
>
> In SWUpdate 2016.x was wrong. The handler "bootloader" processed all
> variables directly. This means that such as a condition was not atomic:
>
> images:
> (
> {
> filename = "rootfs.ext3.gz";
> device = "/dev/mmcblk0p3";
> compressed = true;
> },
> {
> filename = "u-boot-env-base"; #basic boot environment
> type = "bootloader";
> },
> {
> filename = "something else";
> device = "somewhereelse";
> type = "some handler";
> }
> );
>
> If "something else" faiuls to be installed, the environemtn with
> u-boot-env-base was already set without possibility of fallback - this
> is wrong.
>
> On later versions, installing environment from a file was simply broken.
> It did not install anything

> This was fixed with 2018.11 - the environment is seen as a whole and set
> just once after all images, files and scripts were done.
>

good to know!

> Anyway, it is enough you drop mmcpart from u-boot-env-base to get what
> you want.
>

That is what I am going to do.

>>>
>>> Which is the error ? I am expecting that if copy-1 is selected,
>>> u-boot-env-base, "bootfile" and "mmcpart" are applied.
>>>
>>
>> Yes they are applied. So there is no problem with that. Only setting
>> bootloader vars twice in a single update. See above.
>
> This is wrong - it is thought to go from state A to state B. The
> environment in U-Boot does not allow duplication.

Thanks for clarification!
Tobias