Dear Patrick,
In message 60273317e5704581bef81c4beb28ad75@SFHDAG6NODE3.st.com you wrote:
I strongly advice against such a method. Please drop that.
Understood, I drops this patch....
Thanks.
I introduce this behavior after a internal request and to avoid issues during tests:
Some users use the same SD card (same rootfs) on several boards (EV1 and DK2 for example) and the U-Boot environment is saved on this SD card.
OK.
When an user updates U-Boot binary to use this SD card on other board but not erase the environment file (save in ext4 file in bootfs partition), the boot can fail because the environment is not compatible between the 2 boards.
Well, why would that fail on another board but not on the one that is currently in use? Where is the U-Boot image you are booting from? Not on the SDCard, too?
Well, then this is a design problem (or you may even call it a design bug). It has always been a bad idea to use a fixed structure binary format if there are chances that provider (the env storage) and consumer (U-Boot) may get out of sync.
The binary blob environment format (checksum, eventually redundancy flag, date with a fixed total size) is inherently only compatible with other U-Boot versions as long as redundancy and size settings are kept the same.
If you cannot garantee this, you should use a different storage format - for example as plain text file. Of course you pay for added compatibility across U-Boot configurations with the price of reduced security (lack of checksum).
But then, normally you do not change redundancy or environment size between U-Boot versions, so all this should be a theroretical problem only?
This patch try to avoid this issue when I detect that the removable device (as SD card) is used on a a different board (it is detected when saved serial number with different the OTP).
You see this only as a risk - try to see it as a chance, too. Imagine a user is trying to copy environment between systems. Why would you want to stop him?
Any incompatibility issues can reliably be avoided when using binary blob format, as then you will get a checksum error, and the incorrect copy is ignored.
I make too many assumption on user usage and this patch can't be acceptable in arch (common for all board based on STM32MP15x).
See signature below :-)
Best regards,
Wolfgang Denk