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

[Simon Glass]

+U-Boot

Hi Tim,

On 10 April 2015 at 10:46, Tim Harvey <tharvey at gateworks.com> wrote:
>
> On Fri, Apr 10, 2015 at 9:39 AM, Simon Glass <sjg at chromium.org> wrote:
> >
> > 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.
> >
>
> Simon,
>
> If its not too much of a time-sink I would love to take a stab at it.
>
> I've been too swamped to even follow all your work regarding DM. Could
> you point me to any existing
> docs/presentation/simple-example/similar-patches that will give me an
> idea of what needs to be done? Even spit-balling some psuedo-code
> would get me started.

Sure. There's a doc/driver-model/README.

Here are my ideas:

1. Add a new value to the enum in uclass-id.h

2. Create a env-uclass.c file (see demo-uclass.c and dm-demo.h for an
example). Add the operations you want to support. Enable it if
CONFIG_DM_ENV is defined (you can add this new option to Kconfig).

3. Add a sandbox environment driver which implements your operations -
 add a U_BOOT_DRIVER() for your driver, setting .ops to contain
functions that implement the uclass operations for sandbox. Then and
some tests (test/dm/env.c). Then it should be possible to use
saveenv(), etc. from sandbox. The implementation could store it in a
file, perhaps (e.g. using os_open(), etc.). This should speed up
development too since you don't need to test on real hardware.

4. Implement env_relocate() etc. in the uclass file, so that if
CONFIG_DM_ENV is defined you can't define the other ones -
CONFIG_ENV_IS_IN_... or you will get duplicate functions.

5. In your env_relocate(), you can do something like
uclass_get_device(UCLASS_ENV, 0, &dev) to get the default environment
device. Then call the correct operation.

6. Add more driver support - e.g. in env_mmc.c, add a U_BOOT_DRIVER()
for your mmc driver, setting .ops to contain functions that implement
the uclass operations for mmc.

That should be most of it. I don't think it's too tricky. It would be
a big win. I'm happy to help with review and advice. Plus I'll sign up
to do SPI once you are done.

Regards,
Simon