[PATCH] dt-bindings: nvmem: u-boot, env: add Broadcom's variant binding
From: Rafał Miłecki rafal@milecki.pl
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 rafal@milecki.pl --- Documentation/devicetree/bindings/nvmem/u-boot,env.yaml | 2 ++ 1 file changed, 2 insertions(+)
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
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.
Regards,
Joel Peshkin
On Wed, Apr 6, 2022 at 8:25 AM Rafał Miłecki zajec5@gmail.com wrote:
From: Rafał Miłecki rafal@milecki.pl
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 rafal@milecki.pl
Documentation/devicetree/bindings/nvmem/u-boot,env.yaml | 2 ++ 1 file changed, 2 insertions(+)
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 headerconst: brcm,envreg: maxItems: 1
-- 2.34.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
On Thu, Apr 7, 2022 at 11:17 AM Rob Herring robh@kernel.org wrote:
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
Hi Rob,
I'm not sure how much of this you would want to try to upstream (this is actually the reason why we didn't attempt to upstream it ourselves). There is quite a chicken-and-egg problem with using the DT. I'll explain here in case the explanation is useful but I don't think there is a good path to upstreaming all of it.
Our early boot loader (SPL) doesn't even know where the FIT image lives until it has the uboot environment. Once the environment is found (using the magic number and the CRC check I described earlier), there are variables within the environment that are used to find the device in which the FIT image is located, DTB included. There is also a variable, env_boot_magic that identifies the physical offset (after any skipbb has been done) of all of the copies of the environment. For example,
env_boot_magic=16384@0x40000,0xaa000
This value is written after the image is first recorded with skipbb and is used to ensure that, even if one copy were to be corrupted by something like a powerfail during write, all copies are restored when there is a write or a refresh.
I would be happy to upstream this if we could find a decent way to make it fit.
Regards,
Joel
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.
participants (3)
-
Joel Peshkin -
Rafał Miłecki -
Rob Herring