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

[Tim Harvey]

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 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