On 15/12/2019 23.29, Rasmus Villemoes wrote:
> I'm also seeing the build failure that commit
> 
> 7d4776545b env: solve compilation error in SPL
> 
> tried to fix, namely that the reference to env_flags_validate from
> env_htab cannot be satisfied when flags.o is not built in. However,
> that commit got reverted by
> 
> d90fc9c3de Revert "env: solve compilation error in SPL"
> 
> Necessary, but not sufficient conditions to see this are
> 
> CONFIG_SPL=y (obviously)
> CONFIG_SPL_ENV_SUPPORT=n (so flags.o does not get compiled)
> CONFIG_SPL_LIBCOMMON_SUPPORT=y (so env/built-in.o is part of the SPL link)
> 
> Now, these are satisfied for e.g. imx6q_logic_defconfig. But that
> builds just fine, and spl/u-boot-spl.map lists .data.env_htab among
> the discarded (garbage collected) sections. Yet, on our
> mpc8309-derived board, we do see the build failure, so perhaps the
> linker works a bit differently on ppc than on ARM, or there's yet some
> other configuration option needed to observe the break.

Yeah, I think this is a difference in how the linker works on ppc vs
arm. Doing

git grep --files-with-matches SPL=y -- configs/ | xargs grep
--files-with-matches SPL_LIBCOMMON_SUPPORT=y | xargs grep
--files-without-match SPL_ENV_SUPPORT | xargs head -n1

shows that all the in-tree defconfigs with the above combination are ARM
boards (except for microblaze_defconfig, but I don't have such a
toolchain), and they most likely all build just fine. But taking some
random PPC config (say T2080QDS_NAND_defconfig) with the first and third
point, and then manually disabling SPL_ENV_SUPPORT, immediately shows
the break.

For reference, I have

$ ${CROSS_COMPILE}ld --version
GNU ld (GNU Binutils for Ubuntu) 2.30

> This is another attempt at solving it, which also cleans up
> env/Makefile a bit: Introduce a def_bool y symbol CONFIG_ENV_SUPPORT
> which complements CONFIG_(SPL/TPL)_SUPPORT. Then use
> CONFIG_$(SPL_TPL_)ENV_SUPPORT to decide whether to include the five
> basic env/*.o files. For attr.o, flags.o and callback.o, this
> shouldn't change anything. Also, common.o and env.o still get
> unconditionally built for U-boot proper. But for TPL/SPL, those two
> are only included if CONFIG_(SPL/TPL)_SUPPORT is set.

Any comments on this approach, apart from the spellos (I'm missing ENV_
in front of SUPPORT in two places)?

Rasmus

Reply via email to