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

[Tim Harvey]

On Tue, Apr 21, 2015 at 11:17 PM, Igor Grinberg <grinberg at compulab.co.il> wrote:
> Hi Tim,
>
> Sorry for that late reply. I guess better late then never...
>
<snip>
>
> 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...

Hi Igor,

I know the feeling - I was in the same boat.

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

sounds like you and I did about the same thing. If anyone reading this
needs it for reference:
 - https://github.com/Gateworks/u-boot-imx6/commit/ed166eb5c8a83f7489f900d2217763f0fd458f17
 - https://github.com/Gateworks/u-boot-imx6/commit/c398f755a0483e55b661c96c119dd5f3b953eda9

the above are based on U-Boot 2014.04 although I have the same patch
for U-Boot 2015.04

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

I'm hoping to have some time in the next month or so to come back and
propose a proper upstreamable patch using DM. The DM part seems easy
enough, but I will first need get around all the various uses of
CONFIG_ENV_SIZE.

Regards,

Tim