Hi, On 20 February 2017 at 02:18, Dr. Philipp Tomsich <philipp.toms...@theobroma-systems.com> wrote: > > On 20 Feb 2017, at 08:22, Igor Grinberg <grinb...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
