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

[Sean Anderson]

On 2/15/22 9:02 AM, Michal Simek wrote:
> 
> 
> On 2/15/22 14:49, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal at milecki.pl>
>>
>> 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 at milecki.pl>
>> ---
>>   .../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 at milecki.pl>
>> +
>> +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>;

What about when the environment is on top of UBI?

>          #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

For emmc at least you will need another cell for the hardware partition.
And of course, you can name the environment file whatever you want, so
that needs to be recorded as well.

IMO to do this properly you'd need to have a property corresponding to
each of the major configs in the env menu.

--Sean

>          #etc.
>      };
> };
> 
> 
> &qspi {
>      flash {
>          partitions {
>              compatible = "fixed-partitions";
>              #address-cells = <1>;
>              #size-cells = <1>;
> 
>              part0: partition at 0 {
>                  label = "u-boot-env";
>                  reg = <0x0 0x40000>;
>              };
> 
>              part1: partition at 40000 {
>                  label = "u-boot-env-redundant";
>                  reg = <0x40000 0x10000>;
>              };
>      };
> };
> 
> Thanks,
> Michal
>