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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d605473d-35b1-6c6d-3f13-988a04b48c32@gmail.com>
Date:   Mon, 7 Mar 2022 11:31:23 +0100
From:   Rafał Miłecki <zajec5@...il.com>
To:     Rob Herring <robh@...nel.org>, Tom Rini <trini@...sulko.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Ricardo Salveti <ricardo@...ndries.io>,
        Michal Simek <michal.simek@...inx.com>,
        Jorge Ramirez-Ortiz <jorge@...ndries.io>,
        Sean Anderson <seanga2@...il.com>, devicetree@...r.kernel.org,
        u-boot@...ts.denx.de, linux-kernel@...r.kernel.org,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH V2] dt-bindings: nvmem: add U-Boot environment variables
 binding

On 7.03.2022 11:24, Alexander Dahl wrote:
> 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@...ecki.pl>
>>>>
>>>> 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.

I wasn't 100% clear on that but OpenWrt actually uses those U-Boot tools

OpenWrt scripts I mentioned can be found there:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=tree;f=package/boot/uboot-envtools/files;h=687c89806f72756053457a7ab7245bff1c4dcfe8;hb=HEAD

Random example:

linksys,wrt1900ac-v1)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x40000" "0x20000"
	;;
linksys,wrt3200acm|\
linksys,wrt32x)
	ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x20000" "0x20000"
	;;

So those scripts simply generate /etc/fw_env.config required by
fw_printenv / fw_setenv. They have to match what's used by U-Boot at
compilation time.

My long term plan is to move that info to DTS and share it across
projects.