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/?...
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.