Dear Rasmus,
In message 8ff3b8ad-8c4e-fe99-69c8-7c174e997a49@prevas.dk you wrote:
Not in a none standard way! Instead you can define more than one environment storage devices and load them in a board specific order (defined thorugh board specfif function env_get_location())
Yes, agreed. But this logically impossible if there is no storage at all, which is what CONFIG_ENV_IS_NOWHERE says.
Then should all the current config options CONFIG_ENV_IS_ be renamed to CONFIG_ENV_MAY_BE_? Because that's really what they mean.
This is not correct.
The CONFIG_ENV_IS_FOO means: if you use "env save", then U-Boot will write the config to external storage using the FOO storage device.
I certainly agree the current naming isn't very accurate, but the ability to choose CONFIG_ENV_IS_NOWHERE along with some "real" storage option is quite useful. We use it so that we can use the exact same U-Boot binary for both development and production, just different .dtbs; there's a board-specific env_get_location() which reads a DT property to decide whether to return ENVL_SPI_FLASH or ENVL_NOWHERE. Whether there actually needs to be a stub nowhere.c driver for that or one could just return ENVL_UNKNOWN I don't know.
If it makes sense do have a nulldev, then it should be added as a CONFIG_ENV_IS_ option. This is something fundamental different from NOWHERE.
If you define CONFIG_ENV_IS_NOWHERE, I would for example expect that all "env save" related code is omitted as we will never need it.
Best regards,
Wolfgang Denk