dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding

Commit Message

Rafał Miłecki April 6, 2022, 3:25 p.m. UTC

From: Rafał Miłecki <[e-mail]>

Broadcom uses U-Boot for some of their recent platforms like BCM4908.
They decided to use modified environment variables variables format
though. Their header includes 2 extra 32 b fields at the beginning.

The first field meaning is unknown, the second one stores length of env
data block. Example (length 0x4000):
$ hexdump -n 32 -C -s 0x40000 /dev/mtdblock0
00040000  76 6e 45 75 00 40 00 00  34 89 7a 82 49 4d 41 47  |vnEu.@..4.z.IMAG|
00040010  45 3d 4e 41 4e 44 3a 31  4d 2c 31 30 32 34 4d 00  |E=NAND:1M,1024M.|

Add a custom "compatible" value to allow describing Broadcom devices
properly.

Signed-off-by: Rafał Miłecki <[e-mail]>
---
 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml | 2 ++
 1 file changed, 2 insertions(+)

Comments

Rob Herring (Arm) April 7, 2022, 6:17 p.m. UTC | #1

On Thu, Apr 07, 2022 at 04:55:14AM -0700, Joel Peshkin wrote:
> Hi Rafal,
> 
>    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.

Rob

Rafał Miłecki Sept. 21, 2022, 11:57 a.m. UTC | #2

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.

Patch

diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
index e70b2a60cb9a..6a6b223be4a0 100644
--- a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -36,6 +36,8 @@  properties:
         const: u-boot,env-redundant-bool
       - description: Two redundant blocks with active having higher counter
         const: u-boot,env-redundant-count
+      - description: Broadcom's variant with custom header
+        const: brcm,env
 
   reg:
     maxItems: 1