Re: [PATCH] dt-bindings: nvmem: add U-Boot environment variables binding

[Michal Simek]

On 2/15/22 14:49, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@xxxxxxxxxx>
>
> U-Boot uses environment variables for storing device setup data on
> flash. That data usually needs to be accessed by a bootloader, kernel
> and often user-space.
>
> This binding allows describing environment data location and its format
> clearly. In some/many cases it should be cleaner than hardcoding &
> duplicating that 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.
>
> Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
> ---
>   .../devicetree/bindings/nvmem/u-boot,env.yaml | 58 +++++++++++++++++++
>   MAINTAINERS                                   |  5 ++
>   2 files changed, 63 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..a2b3a9b88eb8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> @@ -0,0 +1,58 @@
> +# 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 on flash in a U-Boot specific format (header and NUL separated
> +  key-value pairs).
> +
> +  This binding allows specifying data location and used format.
> +
> +maintainers:
> +  - Rafał Miłecki <rafal@xxxxxxxxxx>
> +
> +allOf:
> +  - $ref: nvmem.yaml#
> +
> +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

I am not convinced that this is the best way how to do it. Because in u-boot 
implementation you would have to enable MTD partitions to get there.
And the whole parsing will take a lot of time.

I think the way how I think this can be handled is.

# I don't think that discussion with Simon was finished.
But for example (chosen or firmware node)
chosen {
	u-boot {
		u-boot,env = <&qspi &part0>;
		u-boot,env-redundant = <&qspi &part1>;
		#or
		u-boot,env = <&qspi 0 40000>;
		u-boot,env-redundant = <&qspi 40000 40000>;
		#or
		u-boot,env = <&mmc 0 0 10000>; #device/start/size - raw mode
		u-boot,env = <&mmc 0 1>; # device/partition - as file to FS
		#etc.
	};
};


&qspi {
	flash {
	    partitions {
	        compatible = "fixed-partitions";
	        #address-cells = <1>;
	        #size-cells = <1>;

	        part0: partition@0 {
        	    label = "u-boot-env";
	            reg = <0x0 0x40000>;
        	};

	        part1: partition@40000 {
        	    label = "u-boot-env-redundant";
	            reg = <0x40000 0x10000>;
        	};
	};
};

Thanks,
Michal