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