SWUpdate multiple bootenv sections

Question

I use SWUpdate to update different Hardware-Revisions of the same device with a double-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     = "uboot";
            }
        );
        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).

Answer 1

I have addressed the mailing list with this question. Stefano Babic, SWUpdate developer and maintainer, answered my question I am just trying to summarize it here.

What I have described is desired behaviour. It is not foreseen to set bootloader variables twice during an update. The u-boot variables defined in a file have priority over u-boot name-value-pairs in the bootenv section because the file is processed in the very end of the update. The solution in my case is to set the variables only in the bootenv section.