Hei hei,
just want to give a little more background here from embedded non
openwrt point of view. See below.
Am Mon, Feb 28, 2022 at 12:32:11PM +0100 schrieb Rafał Miłecki:
On 25.02.2022 17:42, Rob Herring wrote:
On Thu, Feb 17, 2022 at 02:02:35PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki <rafal@xxxxxxxxxx>
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
How much of this is already in use vs. proposed? I know I've seen
something, but that may have been a u-boot env string in 'label' and
that's it.
[bootloader]
Right now U-Boot doesn't use any binding for describing env variables.
It's location is usually hardcoded, see (in U-Boot):
* CONFIG_ENV_ADDR
* CONFIG_ENV_SECT_SIZE
* CONFIG_ENV_ADDR_REDUND
And more … U-Boot has a variety of options to store the U-Boot env,
from the top of my head:
- at some offset in raw flash / mtd partition on NAND, NOR, serial dataflash, etc.
- at some offset on a block device, e.g. on eMMC
- as a file in a FAT partition
- in a UBI volume
- …
And yes, it's determined by some build option and hardcoded at compile
time.
[kernel]
There is no support for accessing U-Boot env data. This patch is the
first step for adding such a support.
[user-space]
OpenWrt uses bash script to store a list of devices and their U-Boot env
variables location. In a long term I'd like to replace it and use DT
info + possibly a kernel exposed NVMEM data.
U-Boot source itself has userspace tools fw_setenv and fw_printenv
and those look into /etc/fw_env.config on how that env should be
accessed.