On Mon, Feb 10, 2025 at 09:55:22AM +0530, Kumar, Udit wrote: > Hi Tom > > On 2/9/2025 10:50 PM, Tom Rini wrote: > > On Sat, Feb 08, 2025 at 10:09:36AM +0530, Anurag Dutta wrote: > > > > > Previously saved environment introduce discrepancies and may lead to > > > incompatibilities without default settings. This series removes the saved > > > environment functionality on am57xx evms so that the default configuration > > > is always loaded > > > > > > Test result: > > > https://gist.github.com/anuragdutta731/b253ddb0a5538ab6588a3535d7bbecf7 > > > > > > Anurag Dutta (2): > > > configs: am57xx_hs: Remove saved environments > > > configs: am57xx: Remove saved environments > > > > > > configs/am57xx_evm_defconfig | 4 +--- > > > configs/am57xx_hs_evm_defconfig | 4 +--- > > > 2 files changed, 2 insertions(+), 6 deletions(-) > > I'm not sure what this is intended to solve. A persistent environment > > can be reset to the defaults with "env default -f -a" and telling users > > to do this when needed when upgrading is a long standing practice. > > There are few inconsistencies in development flow with saved env. > > There we revert already for k3 platforms. Please see > > https://github.com/u-boot/u-boot/commit/a5e8678e0a32f85ad012aea7641e9534ada5c0fe
I did miss that one at the time, yeah. I do think this is the wrong direction because custom designs tend to copy the ref platform and making each of them pick the right long term likely to not be overwritten location seems like more work than reminding developers to run "env default -f -a" when modifying the environment, or even just locally switching to ENV_IS_NOWHERE. I'm not nak'ing it but I would encourage everyone to re-think all of the use cases here and make sure that yes, really, this is the best option. -- Tom
signature.asc
Description: PGP signature
