Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding

["Rafał Miłecki" <zajec5@gmail.com>]

On 7.04.2022 20:17, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
>>     The first 32b value is a magic number (endian swapped mnemonic of "uEnv"
>> short for "u-boot environment").   Finding that magic number of a 4K
>> boundary followed by a length and then a u-boot environment with a valid
>> CRC permits a scan of the flash partition to locate the environment without
>> knowing a-priori where it is.
> 
> So it doesn't need to be described in DT? But how does one identify
> whether to scan the flash or not. You wouldn't want to do that one every
> platform. IOW, it's a sufficient discovery mechanism for a custom build,
> but not generic OS.

I can't tell if U-Boot is ever going to handle discovery based on that
binding.

I still find it very practical for operating systems (like Linux).
Consider:

&flash {
	partitions {
		partition-loader {
			compatible = "brcm,u-boot";

			partition-u-boot-env {
				compatible = "brcm,env";

				mac: ethaddr {
				};
			};
		};
	};
};

&enet {
	nvmem-cells = <&mac>;
	nvmem-cell-names = "mac-address";
};

That allows operating system to have:
1. Driver for finding env data subpartitions [1]
2. Independent driver parsing env data structured with Broadcom's format

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=27bfb201b2c03c8a033b60e5ad80cbf3aaa52b94



If you don't like it, another option could be to use "u-boot,env" and
then make U-Boot env data NVMEM driver detect actual format.



Please let me know if any of above options looks acceptable or if you
can think of another solution.