Messages in this thread | | | Date | Wed, 21 Sep 2022 13:57:18 +0200 | Subject | Re: [PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding | From | Rafał Miłecki <> |
| |
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.
| |