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

[Igor Grinberg]

Hi Tim,

Sorry for that late reply. I guess better late then never...

On 04/10/15 19:39, Simon Glass wrote:
> 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.

Yes, I did this for several of our boards.
I really wanted to clean it up and push upstream, but I barely had time
to implement it in some way to make it work...

>>>
>>> Thanks,
>>> Stefan
>>>
>>
>> Igor,
>>
>> I think what Stefan might be thinking of is ENV_IS_EMBEDED used in
>> cm-bf537.

Nope, that is not one of our boards... That's Blackfin.
Our board is cm-t35, but the change is not upstream, you can check
our downstream U-Boot here [1] if you would like to,
but it requires a huge rework, so I would recommend
implementing it from scratch using DM concepts.

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

Yep. We do not use ENV_IS_EMBEDDED on our boards.

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

Yep. I had this too.

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

Yes.

>>  - currently supports only mmc/nand

Same stands for cm-t35 downstream U-Boot...

In addition, my downstream implementation has the "env dev" command
to switch between the available env storage devices on the fly.
And that enabled also copying the env from device to device, if needed.

One of the huge drawbacks of my downstream implementation is that
since I had no time to figure out how to properly patch the functions
location after relocation, I had a huge array of ifdefs for all the cases...

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

Yes, I think we have discussed and agreed on this in Düsseldorf, right?

> 
> Probably better that than a linker_list.

Agreed, much better.

[1] - https://github.com/compulab/cm-t3x-u-boot

-- 
Regards,
Igor.