0

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).

Toto
  • 79
  • 10

1 Answers1

0

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.

Toto
  • 79
  • 10
  • Hello @Toto, I am using SWUpdate with u-boot. But I am facing an issue. I am able to install updates but after reboot, system is still using old partition after boot. But no errors from SWUpdate reported while updating. Looks like SWUpdate is not able to communicate with u-boot. I am using similar sw-description as above (no file is used to define u-boot variables, only "bootenv" section is used). Any idea what could be the reason for this? – Preeti Mar 28 '22 at 15:37
  • Have you checked your configuration file specified in UBOOT_FWENV . Default is /etc/fw_env.config where it tells where the U-Boot environment is saved. You can check this by using the fw_printenv and fw_setenv commands. – Toto Mar 29 '22 at 10:40
  • Hi @Toto, thanks for the response. Yes, I do have `/etc/fw_env.config` with 2 entries for /dev/mtd0 and also I can do `fw_printenv` and `fw_setenv` from linux user-space. – Preeti Mar 29 '22 at 11:04