Proposal to configure uboot.env location

snapd
1

On current devices using u-boot bootloader uboot.env is expected to reside in system-boot partition as file.
While this is working solution there are situations when device does not support this configuration.
Additionally having uboot.env located in system-boot means that u-boot has to regularly write to this vfat partition, which can lead to file system corruptions as we have two different implementation of vfat operating on same filesystem.
To enable greater device customisation, we should enable possibility for uboot environment to be located as separate partition, removing file system complexity when accession and modifying uboot environment.
Proposed gadget.yaml could look something like this:

device-tree: bcm2710-rpi-3-b.dtb
volumes:
  pi3:
    schema: mbr
    bootloader: u-boot
    structure:
      - name: ubootenv
        size: 262144
        content:
          - image: uboot.env
        type: 26CEFF30-B2B8-4D62-A6A1-52BDDF585F0B
      - name: system-boot
        type: 0C
        filesystem: vfat
        filesystem-label: system-boot
        size: 128M
        role: system-data
        content:
          - source: boot-assets/
            target: /
2

What type of filesystem would this be, obviously we don’t want it to be vfat again. Does this become something like ext4? Would this not be two different implementations of the new filesystem type accessing the uboot config again?

3

it would be raw data, no filesystem at all (this is typically the default if uboot lives on NAND flash and such, the uboot.env binary blob becomes its own “partition” in this case and u-boot writes raw variables/values to it)…

4

the point behind using a fixed size binary blob file (instead of … say a uEnv.txt text file) is that no fat writes happen at all, when changing variables only binary bits are changed inside that file by u-boot, there should never be actual FAT writes since the filesystem metadata (size, position etc) never changes, u-boot only toggles bits inside the blob.

while i fully agree that we should have multiple options to handle u-boot config, i would also like us to find out why the corruption happens at all, the toggling of bits inside the file are unlikely to be at fault (i.e. the “writing of variables by u-boot”), my guess would rather be some unconditional fsck action here. after all (as genious as the fix is) @mvo only worked around the symptom but nobody really researched the cause with the recent fixes.

that said … yes, please lets go ahead with a raw alternative, after all this is the oldest and most tested u-boot implementation to hold the environment.

1 Like