[PATCH V2] nvmem: add driver handling U-Boot environment variables

[Ahmad Fatoum]

Hello Rafał,

On 05.05.22 07:46, Rafał Miłecki wrote:
> On 4.05.2022 11:23, Ahmad Fatoum wrote:
>> Hello Rafał,
>>
>> On 03.05.22 18:56, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal at milecki.pl>
>>>
>>> U-Boot stores its setup as environment variables. It's a list of
>>> key-value pairs stored on flash device with a custom header.
>>>
>>> This commit adds an NVMEM driver that:
>>> 1. Provides NVMEM access to environment vars binary data
>>> 2. Extracts variables as NVMEM cells
>>>
>>> It can be used for:
>>> 1. Accessing env variables from user-space
>>
>> Is this already possible? The only interface I know of is the /nvmem
>> file in sysfs, but that one is not per cell, but per device.
> 
> Maybe that wasn't precise enough, I should probably write:
> 1. Parsing binary data from user-space
> 
> In future I'd like to extend U-Boot's "printenv" tool to support reading
> env variables blob using Linux's sysfs as documented in the
> Documentation/ABI/stable/sysfs-bus-nvmem

So, would you use this interface just to save fw_printenv the hassle
of finding the environment (but redoing parsing) or do you intend
to preprocess the data too? (e.g. only show the active environment) 

For your use case, it sound like teaching NVMEM core to export
cells as binary sysfs files would be very useful.

>>> +    label = of_get_property(np->parent, "label", NULL);
>>> +    if (!label)
>>> +        label = np->parent->name;
>>> +
>>> +    priv->mtd = get_mtd_device_nm(label);
>>> +    if (IS_ERR(priv->mtd)) {
>>> +        dev_err(dev, "Failed to find \"%s\" MTD device: %ld\n", label, PTR_ERR(priv->mtd));
>>> +        return PTR_ERR(priv->mtd);
>>> +    }
>>
>> I am trying to make sense of this using the binding, but I can't.
>> Do you have an example device tree fragment?
> 
> This comes from unreleased yet board I'm working on.
> 
> It stores U-Boot env variables in the middle of U-Boot binary.

Huh, that's an odd layout. I am not sure whether of_get_property to
arrive at the parent is such a good idea though. Doesn't it enforce
a limitation that there must not exist two partitions with the same label?

Some systems can have a second recovery bootloader for example.
Given that these are device tree nodes, wouldn't it be possible
to find the MTD by device tree parent instead of via its label?

> partitions {
>     compatible = "fixed-partitions";
>     #address-cells = <1>;
>     #size-cells = <1>;
> 
>     partition at 0 {
>         label = "loader";
>         reg = <0x0 0x100000>;
> 
>         partition at 40000 {
>             compatible = "u-boot,env";
>             label = "u-boot-env";
>             reg = <0x40000 0x4000>;
>         };
>     };
> 
>     partition at 100000 {
>         label = "image";
>         reg = <0x100000 0x1fe00000>;
>     };
> };


Thanks,
Ahmad


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |