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
[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.
This binding allows describing environment data located in a raw flash
partition. It's treated as NVMEM device and can be reused later for
other storage devices.
Using DT should be cleaner than hardcoding & duplicating such info in
multiple places. Bootloader & kernel can share DTS and user-space can
try reading it too or just have correct data exposed by a kernel.
A custom "compatible" string allows system to automatically load
relevant NVMEM driver but phandle can be also used for reading raw
location.
Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
---
V2: Update descriptions to don't make this binding MTD (flash partition)
specific. Mention multiple possible storage ways.
---
.../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
new file mode 100644
index 000000000000..a53e34152c97
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-Boot environment variables
+
+description: |
+ U-Boot uses environment variables to store device parameters and
+ configuration. They may be used for booting process, setup or keeping end user
+ info.
+
+ Data is stored using U-Boot specific formats (variant specific header and NUL
+ separated key-value pairs).
+
+ Environment data can be stored on various storage entities, e.g.:
+ 1. Raw flash partition
+ 2. UBI volume
+
+ This binding allows marking storage device (as containing env data) and
+ specifying used format.
+
+ Right now only flash partition case is covered but it may be extended to e.g.
+ UBI volumes in the future.
+
+maintainers:
+ - Rafał Miłecki <rafal@xxxxxxxxxx>
+
+allOf:
+ - $ref: nvmem.yaml#
What exactly is used from nvmem.yaml? Based on the example, nothing.
Nothing. I thought it's nice for a context. I'll drop it.
+
+properties:
+ compatible:
+ oneOf:
+ - description: A standalone env data block
+ const: u-boot,env
+ - description: Two redundant blocks with active one flagged
+ const: u-boot,env-redundant-bool
+ - description: Two redundant blocks with active having higher counter
+ const: u-boot,env-redundant-count
Aren't these 2 discoverable based on a flag or count property?
U-Boot discovers that based on a type of flash device(s). In redundant
mode env data can be stored on one or two flash devices.
U-Boot conditions:
/* Check flag scheme compatibility */
if (DEVTYPE(dev_current) == MTD_NORFLASH &&
DEVTYPE(!dev_current) == MTD_NORFLASH) {
environment.flag_scheme = FLAG_BOOLEAN;
} else if (DEVTYPE(dev_current) == MTD_NANDFLASH &&
DEVTYPE(!dev_current) == MTD_NANDFLASH) {
environment.flag_scheme = FLAG_INCREMENTAL;
} else if (DEVTYPE(dev_current) == MTD_DATAFLASH &&
DEVTYPE(!dev_current) == MTD_DATAFLASH) {
environment.flag_scheme = FLAG_BOOLEAN;
} else if (DEVTYPE(dev_current) == MTD_UBIVOLUME &&
DEVTYPE(!dev_current) == MTD_UBIVOLUME) {
environment.flag_scheme = FLAG_INCREMENTAL;
} else if (DEVTYPE(dev_current) == MTD_ABSENT &&
DEVTYPE(!dev_current) == MTD_ABSENT &&
IS_UBI(dev_current) == IS_UBI(!dev_current)) {
environment.flag_scheme = FLAG_INCREMENTAL;
} else {
fprintf(stderr, "Incompatible flash types!\n");
ret = -EINVAL;
goto open_cleanup;
}
I thought it's better & more flexible to describe format explicitly in
the DT. That way vendors have more options - they can e.g. start using
incremental setup on NOR flash devices.
+
+ reg:
+ maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ reg = <0x0 0x40000>;
+ label = "u-boot";
+ read-only;
+ };
+
+ env: partition@40000 {
+ compatible = "u-boot,env";
+ reg = <0x40000 0x10000>;
+ label = "u-boot-env";
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 66aa3a589f6a..55c56ce82856 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19905,6 +19905,11 @@ W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/pci/tw686x/
+U-BOOT ENVIRONMENT VARIABLES
+M: Rafał Miłecki <rafal@xxxxxxxxxx>
+S: Maintained
+F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+
UACCE ACCELERATOR FRAMEWORK
M: Zhangfei Gao <zhangfei.gao@xxxxxxxxxx>
M: Zhou Wang <wangzhou1@xxxxxxxxxxxxx>
--
2.34.1
