[PATCH v2] mt7621: move uboot-envtools to DEFAULT_PACKAGES

[Felix Baumann]

Am 28. Februar 2023 12:46:44 MEZ schrieb "Bjørn Mork" <bjorn at mork.no>:
>Peter Naulls <peter at chocky.org> writes:
>> On 2/27/23 17:23, Hauke Mehrtens wrote:
>>
>>> This will add uboot-envtools to all devices. uboot-envtools is not
>>> included in all DEVICE_PACKAGES now, should we explicitly remove it
>>> from device definitions which do not had it before?
>>> The Device/adslr_g7 for example does not add uboot-envtools in its
>>> DEVICE_PACKAGES.
>>> 
>>
>> Same comment for NAND support. Only 1/3rd or so of the mt7621 systems
>> use the nand feature.
>
>This is a difficult problem for any feature which is required by one or
>more device during boot or upgrade.  Using a shared rootfs per target
>means that all such features must be included on all devices.
>
>The alternatives are AFAICS
>1) splitting targets by feature sets
>2) always use a per-device rootfs
>
>I believe 2) is non-trivial.  1) might be easier and could make some sense
>for huge targets like mt7621?
>
>
>Bjørn
>
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel at lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi,

one issue I see here is that there are MT7621 devices like the Asus RT-AX53U that don't save their environment to their u-boot-env partition by default.
You still need to execute saveenv while connected via serial.
Note: the device doesn't have a u-boot-env partition in stock rom. The environment is saved to the second half of the original u-boot partition.
We added uboot-envtools support by splitting the u-boot partition in half.

Some ideas for uboot-envtools if it gets build by default on ramips:
Would it make sense to find a way to extract default config from uboot and introduce a way to (re)set env to default if it can't be read? Or is that impossible?
(Can't be read: empty partition or bad crc)

Right now fw_printenv can't distinguish between empty u-boot-env partitions and ones whose CRC is bad.
Both cases error: "Warning: Bad CRC, using default environment"
Which is misleading since this is a kind of environment that will brick any device you don't have serial access to.

What should fw_printenv/fw_setenv error, when there is no definition for the device in package/boot/uboot-envtools/files/ramips, yet? Right now it's:
"Cannot parse config file '/etc/fw_env.config': No such file or directory
Failed to find NVMEM device"
Or is that error message enough?

I'm not sure whether it's possible to autodetect these offsets, but if we build every device with this package, then it might make sense to add them to dts, so they can be set more easily on a per partition basis? (some devices have two environments, see sys_config)


Regards
Felix Baumann