[U-Boot] [PATCH v1] env_mmc: configure environment offsets via device tree

[Simon Glass]

Hi,

On 20 February 2017 at 02:18, Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
>
> On 20 Feb 2017, at 08:22, Igor Grinberg <grinberg at compulab.co.il> wrote:
>
> That sounds too odd...
> DT's purpose is to describe the h/w... and that does not look so...
> We also, have a dt file name in the environment, so this creates will create
> a chicken and an egg problem…
>
>
> I don’t really follow… as far as I knew the DT name would have to come
> from some other source anyway, as the device containing the env might
> only be described through the device tree (e.g. mmc0).
>
>
> Why? U-Boot can live pretty well w/o DT.
>
>
> If U-Boot runs without DT, then nothing will/should change about how the
> setting
> is retrieved from CONFIG_ENV_OFFSET.
>
> The platform that motivated this change is ARCH_SUNXI, which does not use
> per-board defines but aims to have one generic bootloader per-SoC.
>
> I really don't think we should go that direction. DT is not meant to provide
> a solution to all your problems...
>
>
> I don’t see how this is different from other entries in chosen and config as
> of today:
> common/autoboot.c allows an override through /config/bootdelay
> common/board_r.c uses /config/load-environment
> common/cli.c can pull in /config/bootcmd
> drivers/serial/serial-uclass.c uses /chosen/stdout-path
>
> In fact, it is the absence of this mechanism that is causing problems today:
> CONFIG_ENV_OFFSET is not configurable through Kconfig, so we would
> need board-specific defines (e.g. CONFIG_SUNXI_BOARD_LYNX) and
> matching #ifdef primitives in a shared header (sunxi-common.h in our case).
>
>
> Right. Exactly, I think we should move the CONFIG_ENV_OFFSET to Kconfig.
> And that will solve the problem.
>
>
> Doing this would still get into the way of architectures that want to build
> a single
> ‘universal’ bootloader for their SoC: the ENV_OFFSET may not be the same
> across all board and vendor configurations. This can easily be handled with
> the
> (optional) prop in the DT, but not with the compile-time ENV_OFFSET.
>
> If we decide to this, I’d at least like to introduce the function call to
> (the weak
> function) mmc_get_env_addr(…), so we can override this in the board code.
>
> So putting this in the DT is the best (and least intrusive) option
> available.
>
>
> Ok. I see your point now. Yet I think we should keep the DT to its purpose -
> which
> is to describe the h/w (and not the s/w placement layout).

Well actually we put things like flash map in there and the
environment position seems like a very good thing to have there. So I
like this patch. There is too compile-time configuration in U-Boot
still...

In fact I wish we could support this for all environment types.
Overall the environment drivers need some work to make them more
similar...

Regards,
Simon