On Tuesday 11 January 2022 14:22:43 Alex G. wrote: > On 1/11/22 13:09, Tom Rini wrote: > > On Tue, Jan 11, 2022 at 07:58:05PM +0100, Marek Vasut wrote: > > > On 1/11/22 17:16, Tom Rini wrote: > > > > On Tue, Jan 11, 2022 at 04:36:34PM +0100, Pali Rohár wrote: > > > > > On Tuesday 11 January 2022 16:31:20 Marek Vasut wrote: > > > > > > The kwbimage has hard dependency on OpenSSL, do not build it > > > > > > in case TOOLS_LIBCRYPTO is disabled. > > > > > > > > > > This patch does not work as kwbimage is required for 32-bit Armada > > > > > platforms. So kwbimage.o cannot be disabled on these platforms. > > > > > > > > > > There is already proposal for fixing this issue: > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211021093304.25399-1-p...@kernel.org/ > > > > > > > > And needs to be respun to not have Kconfig issues. To answer something > > > > noted in that thread, yes, it would be good if Kconfig did, or had an > > > > option to make WARNING like that fatal. Or is the problem really that > > > > no, it's non-optional, really, to have OpenSSL installed? > > > > > > OpenSSL should be optional, I got this bug report where someone tried to > > > build u-boot on ancient debian oldoldstable with openssl 1.1.0 (without > > > ecdsa support), for a platform which doesn't need any of this crypto > > > stuff. > > > So, disabling TOOLS_LIBCRYPTO was a sufficient for that platform to build > > > in > > > that setup (with this patch). And there are plenty of such platforms in > > > the > > > U-Boot tree (all that are not marvell I think). > > > > Right. So your patch is a step in the right direction, but we also need > > to have the appropriate platforms depend'ing on TOOLS_LIBCRYPTO and > > updating the help to note that some platforms require it as well, to > > build their images. > > I did not intend for TOOLS_LIBCRYPTO to be used beyond an on/off toggle for > the user. > > My suggestion is to allow platforms to build irrespective of > TOOLS_LIBCRYPTO, and print a warning if for some reason we can't generate a > bootable image. I see quite a few ARMv8 platforms throw such warnings on > gitlab-ci. We can compile an elf, right? Any good reason why kwbimage should > be different? > > Alex
For me: build = generate a bootable image or at least I do not see a reason why an end user should be able to generate e.g. cmd/common.o object file without having working full toolchain for successful generation of final executable. Some platforms (e.g. that Marvell) are not ELF-based, so compiling ELF means nothing. kwbimage for these Marvell platforms is what generates final "executable" image and it does also other checks and tests. It is possible that build process generates SPL ELF binary but kwbimage refuse it. In most cases it means that user chose .config options unusable for booting, but it could mean also other issues. And this is something which CI tests can detect... if some patch is doing to break U-Boot on Marvell platforms. On mailing list are pending other patches which extends those kwbimage checks to prevent generating broken images (e.g. chosen SPL load address cannot be set into kwbimage). So printing a warning does not solve anything because warnings are ignored. Lot of packaging tools and also CI tests pass successfully if build process throw a warning. And if some platforms are throwing warnings on CI, is not this an issue which somebody should care about?
