Hi Tom, On Wed, 6 Oct 2021 at 20:52, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Oct 06, 2021 at 08:49:13PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 6 Oct 2021 at 18:26, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Sat, Sep 25, 2021 at 07:43:15PM -0600, Simon Glass wrote: > > > > > > > At present we must separately test for the host build for many options, > > > > since we force them to be enabled. For example, CONFIG_FIT is always > > > > enabled in the host tools, even if CONFIG_FIT is not enabled by the > > > > board itself. > > > > > > > > It would be more convenient if we could use, for example, > > > > CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the > > > > host. Add support for this. > > > > > > > > With this and the tools_build() function, we should be able to remove > > > > all > > > > the #ifdefs currently needed in code that is build by tools and targets. > > > > > > > > This will be even nicer when we move to using CONFIG(xxx) everywhere, > > > > since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go > > > > away. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > Suggested-by: Rasmus Villemoes <rasmus.villem...@prevas.dk> # b4f73886 > > > > Reviewed-by: Alexandru Gagniuc <mr.nuke...@gmail.com> > > > > > > The problem here is we don't include <linux/kconfig.h> automatically > > > when building host stuff, I believe. This is why doing this breaks > > > test_mkimage_hashes for me on am335x_evm with: > > > /tmp/.bm-work/am335x_evm/tools/mkimage -D -I dts -O dtb -i > > > /tmp/.bm-work/am335x_evm -f > > > /home/trini/work/u-boot/u-boot/test/py/tests/vboot//hash-images.its > > > /tmp/.bm-work/am335x_evm/test.fit > > > *** stack smashing detected ***: <unknown> terminated > > > > Oh dear, and no CI coverage. > > > > I was reluctant to include kconfig.h everywhere but perhaps that is > > the best approach. Will take a look ASAP. > > Maybe we need to think a bit harder too about how we structure > intentionally shared code. > > Why not, for example, for these common algorithms, rely on typical > system headers/libraries in the tooling, which means we validated U-Boot > vs common reference, rather than just our implementations?
Do you mean we use openssl for sha1, for example? Regards, Simon