[U-Boot] single build of uboot supporting env stored in dynamically detected boot device

[Simon Glass]

Hi Tim,

On 10 April 2015 at 09:42, Tim Harvey <tharvey at gateworks.com> wrote:
> On Thu, Apr 9, 2015 at 11:07 PM, Stefan Roese <sr at denx.de> wrote:
>> Hi Tim,
>>
>> (added Igor to cc)
>>
>>
>> On 10.04.2015 00:58, Tim Harvey wrote:
>>>
>>> It seems the U-Boot's env storage is implemented by various types of
>>> storage from common/env_*.c, one (and only one) which is included by
>>> common/Makefile based off of the CONFIG_ENV_IS_IN_* config.
>>>
>>> I want to build a single uboot image which can be installed on one of
>>> several supported boot devices (NAND, SATA, SD for example) and have
>>> the env storage hooked to the device that was detected as the boot
>>> device. Am I correct in assuming this is not currently possible and
>>> that instead I would have to build 3 versions of uboot each with one
>>> type of storage defined?
>>>
>>> If it turns out that this is not currently possible, I'm open to
>>> suggestions on how to rectify it (or if you think I'm crazy for
>>> wanting to have a single uboot image for the above please explain your
>>> reasoning). I'm thinking I would start by making the env_init/saveenv
>>> functions (I believe those are the only ones that need to be
>>> implemented by an env storage subsystem) unique function names, then
>>> creating a wrapper for those functions that call the right one.
>>
>>
>> IIRC, Compulab has such a feature implemented in some of their U-Boot
>> versions. Igor, please either correct me if I'm wrong. Or elaborate how you
>> have implemented this dynamic env feature.
>>
>> Thanks,
>> Stefan
>>
>
> Igor,
>
> I think what Stefan might be thinking of is ENV_IS_EMBEDED used in
> cm-bf537. It looks like this support was originally for the renesas
> sh775* boards which don't look to be maintained any longer. I haven't
> gone through it in depth yet but it seems this has to do with
> embedding the env within U-Boot binary itself yet I'm clear why this
> isn't just using the default_environment array (maybe it predated that
> notion?). If I'm understanding it correctly ENV_IS_EMBEDDED is not
> really what I'm looking for and likely that support could use some
> cleanup and updating.
>
> I have an RFC patch I'm working on that will allow
> CONFIG_ENV_IS_DYNAMIC that currently does the following:
>  - makes env_init(), saveenv(), env_relocate_spec(), env_ptr,
> env_name_spec namespace unique in env_*.c
>  - provide a env_init(), saveenv(), env_relocate_spec() in
> env_common.c using spl_boot_device() to determine the boot device and
> calling the namespace unique impl instead
>  - currently supports only mmc/nand

I've wanted this feature for some years, and also the ability to
define the environment offset/address/size (and other parameters)
dynamically.

This feels like a job for driver model. We could have an environment
uclass with operations like load and save. Then mmc and nand could
implement drivers for this uclass.

Probably better that than a linker_list.

>
> I don't see any clear maintainers of anything env related so I'm not
> sure who else may want to be involved in this conversation.
>
> (added Wolfgang to cc)
>
> Tim

Regards,
Simon