Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 22/10/2021 17:09, Tom Rini wrote: On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: On Fri, 22 Oct 2021 12:09:19 +0200 Heinrich Schuchardt wrote: On 10/21/21 15:00, Marek Behún wrote: BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu platform in Kconfig? We should only use 'imply' for suggested settings and never for hard requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it for mvebu would be redundant. In an OS distribution we only want to ship a single version of mkimage. So it is good to elimate symbol CONFIG_MXS. How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. Tom wrote regarding this aspect in https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: "if we're building a generically useful tool, we don't want another symbol for it." OK, so mkimage and dumpimage should be always generic and always support all platforms, that makes sense, since the tools can be installed as a distribution package. But I still think it should be possible to cripple these tools if the developer wants to disable libcrypto due to embedded environment. This is probably the time to reach out to some of the distro folks to see how they would like to see things handled for "build the tools we need to package for the user" and also "build the binary for the platform". in openSUSE we are building the tools for each u-boot binary but those are not part of our u-boot-tools package. For that package we use sandbox_defconfig to only build the tools. So we are using openSSL in our packaging. AFAIK that's not an issue for us. Regards, Matthias
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
> > >> I also have been doing some packaging of u-boot for GNU Guix, where I > > >> suspect the stance wouldn't be as willing to accept such a compromise... > > >> > > >> So... I would *love* an option to be able to build a board-only config > > >> without any of the tools; > > > > > > Why is this a problem (see above)? Who is building board builds? It's > > > either the maintainer when creating the binary package, or a curious user, > > > right? And they can surely *use* OpenSSL during build time - if it's > > > needed by the board. > > > > Sure, if there is no actual openssl code embedded in the resulting > > binary with GPLv2 code, it shouldn't be a problem... > > > > > > It's a mess of an issue to tease out exactly what codepaths trigger and > > do not trigger the compatibility issues between openssl and GPL... > > > > > > Depending on openssl in a project with GPLv2-only code does seem at risk > > to introduce license compatibility issues without sufficient and > > constant review and dilligence, even if it is technically ok how it is > > done right now... > > There's still the long standing request to migrate the tooling to use a > different library, but it's apparently not been a large enough concern > of company with concerns to fund a developer of theirs to do the > migration. I feel like that might be one of the better, at least in > terms of license, fixes for this issue. > > And then maybe we do just need a way to say if you're building for > platform X then you must also have the crypto requirement resolved to > build mkimage. And conversely if you aren't building those platforms, > it's OK to not. Does the re-license [1] to Apache License 2.0 for openssl 3+ change this situation at all? For reference all the pieces of U-Boot that Fedora builds seem to build fine with openssl 3. [1] https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, Oct 22, 2021 at 12:46:59PM -0700, Vagrant Cascadian wrote: > On 2021-10-22, Andre Przywara wrote: > > On Fri, 22 Oct 2021 09:47:35 -0700 > > Vagrant Cascadian wrote: > >> On 2021-10-22, Tom Rini wrote: > >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: > >> >> On Fri, 22 Oct 2021 11:09:27 -0400 > >> >> Tom Rini wrote: > >> > >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200 > >> >> > > Heinrich Schuchardt wrote: > >> >> > > > >> >> > > > On 10/21/21 15:00, Marek Behún wrote: > >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for > >> >> > > > > mvebu > >> >> > > > > platform in Kconfig? > >> >> > > > > > >> >> > > > > >> >> > > > We should only use 'imply' for suggested settings and never for > >> >> > > > hard > >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So > >> >> > > > implying it > >> >> > > > for mvebu would be redundant. > >> >> > > > > >> >> > > > In an OS distribution we only want to ship a single version of > >> >> > > > mkimage. > >> >> > > > So it is good to elimate symbol CONFIG_MXS. > >> >> > > > > >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > >> >> > > > > >> >> > > > Tom wrote regarding this aspect in > >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > >> >> > > > > >> >> > > > "if we're building a generically useful tool, we don't want > >> >> > > > another > >> >> > > > symbol for it." > >> >> > > > >> >> > > OK, so mkimage and dumpimage should be always generic and always > >> >> > > support all platforms, that makes sense, since the tools can be > >> >> > > installed as a distribution package. > >> >> > > > >> >> > > But I still think it should be possible to cripple these tools if > >> >> > > the > >> >> > > developer wants to disable libcrypto due to embedded environment. > >> >> > > > >> >> > >> >> Well, I don't think this is the real question here, is it? > >> >> I think the tools part is clear: distros want to build just mkimage, > >> >> supporting as many platforms as possible, and might need to avoid > >> >> OpenSSL. > >> >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make > >> >> tools-only_defconfg && make tools", and Samuel's patch actually fixes > >> >> the > >> >> build (at least somewhat, I still get link errors). > >> > > >> > The problem is, are distros doing a tools-only build, for tools, or are > >> > they doing it per board? Like, hey, ugh, OpenEmbedded uses > >> > sandbox_defconfig and cross_tools as the targets. That's not quite what > >> > I was hoping to see. So I want to know everyone else is doing, rather > >> > than we hope they're doing. > >> > >> Thanks for bringing this to my attention! > >> > >> In Debian, the u-boot-tools package is built using tools-only, and for > >> each of the board-specific targets, it still ends up building the > >> relevent tools, but we throw them away and do not ship them in any > >> packages. > >> > >> With 2021.10, the board-specific builds made it harder to avoid openssl > >> with the corresponding tools, and I reluctantly added a dependency on > >> openssl... (which is technically permitted in Debian, having declared > >> openssl as a system library to avoid the GPL incompatibilities, but > >> ... meh.) > > > > But this is purely a *build-time* dependency only, right? The resulting > > images do not have any openssl code in them, they were just *created* > > (signed) using that code. > > I don't think this a legal issue? > > The various .h includes are all that I saw, and I *think* all in the > tools/ directory, but yeah, if this is really the case that no openssl > code ends up in the board-specific binaries, that simplifies things > considerably. > > > > The problems are about *shipping* openssl code, which you only do for > > u-boot-tools - where it now can be disabled. > > Probably won't disable it for u-boot-tools in Debian (reluctantly riding > on the system library exception), but the tools builds that are part of > the build process would be nice to be able to disable. > > > > >> I also have been doing some packaging of u-boot for GNU Guix, where I > >> suspect the stance wouldn't be as willing to accept such a compromise... > >> > >> So... I would *love* an option to be able to build a board-only config > >> without any of the tools; > > > > Why is this a problem (see above)? Who is building board builds? It's > > either the maintainer when creating the binary package, or a curious user, > > right? And they can surely *use* OpenSSL during build time - if it's > > needed by the board. > > Sure, if there is no actual openssl code embedded in the resulting > binary with GPLv2 code, it shouldn't be a problem... > > > It's a mess of an issue to tease out exactly what codepaths trigger and > do not trigger the compatibility issues between
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Andre Przywara wrote: > On Fri, 22 Oct 2021 09:47:35 -0700 > Vagrant Cascadian wrote: >> On 2021-10-22, Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> >> On Fri, 22 Oct 2021 11:09:27 -0400 >> >> Tom Rini wrote: >> >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> >> > > Heinrich Schuchardt wrote: >> >> > > >> >> > > > On 10/21/21 15:00, Marek Behún wrote: >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for >> >> > > > > mvebu >> >> > > > > platform in Kconfig? >> >> > > > > >> >> > > > >> >> > > > We should only use 'imply' for suggested settings and never for >> >> > > > hard >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying >> >> > > > it >> >> > > > for mvebu would be redundant. >> >> > > > >> >> > > > In an OS distribution we only want to ship a single version of >> >> > > > mkimage. >> >> > > > So it is good to elimate symbol CONFIG_MXS. >> >> > > > >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> >> > > > >> >> > > > Tom wrote regarding this aspect in >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> >> > > > >> >> > > > "if we're building a generically useful tool, we don't want another >> >> > > > symbol for it." >> >> > > >> >> > > OK, so mkimage and dumpimage should be always generic and always >> >> > > support all platforms, that makes sense, since the tools can be >> >> > > installed as a distribution package. >> >> > > >> >> > > But I still think it should be possible to cripple these tools if the >> >> > > developer wants to disable libcrypto due to embedded environment. >> >> >> >> Well, I don't think this is the real question here, is it? >> >> I think the tools part is clear: distros want to build just mkimage, >> >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> >> build (at least somewhat, I still get link errors). >> > >> > The problem is, are distros doing a tools-only build, for tools, or are >> > they doing it per board? Like, hey, ugh, OpenEmbedded uses >> > sandbox_defconfig and cross_tools as the targets. That's not quite what >> > I was hoping to see. So I want to know everyone else is doing, rather >> > than we hope they're doing. >> >> Thanks for bringing this to my attention! >> >> In Debian, the u-boot-tools package is built using tools-only, and for >> each of the board-specific targets, it still ends up building the >> relevent tools, but we throw them away and do not ship them in any >> packages. >> >> With 2021.10, the board-specific builds made it harder to avoid openssl >> with the corresponding tools, and I reluctantly added a dependency on >> openssl... (which is technically permitted in Debian, having declared >> openssl as a system library to avoid the GPL incompatibilities, but >> ... meh.) > > But this is purely a *build-time* dependency only, right? The resulting > images do not have any openssl code in them, they were just *created* > (signed) using that code. > I don't think this a legal issue? The various .h includes are all that I saw, and I *think* all in the tools/ directory, but yeah, if this is really the case that no openssl code ends up in the board-specific binaries, that simplifies things considerably. > The problems are about *shipping* openssl code, which you only do for > u-boot-tools - where it now can be disabled. Probably won't disable it for u-boot-tools in Debian (reluctantly riding on the system library exception), but the tools builds that are part of the build process would be nice to be able to disable. >> I also have been doing some packaging of u-boot for GNU Guix, where I >> suspect the stance wouldn't be as willing to accept such a compromise... >> >> So... I would *love* an option to be able to build a board-only config >> without any of the tools; > > Why is this a problem (see above)? Who is building board builds? It's > either the maintainer when creating the binary package, or a curious user, > right? And they can surely *use* OpenSSL during build time - if it's > needed by the board. Sure, if there is no actual openssl code embedded in the resulting binary with GPLv2 code, it shouldn't be a problem... It's a mess of an issue to tease out exactly what codepaths trigger and do not trigger the compatibility issues between openssl and GPL... Depending on openssl in a project with GPLv2-only code does seem at risk to introduce license compatibility issues without sufficient and constant review and dilligence, even if it is technically ok how it is done right now... live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 09:47:35 -0700 Vagrant Cascadian wrote: Hi, > On 2021-10-22, Tom Rini wrote: > > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: > >> On Fri, 22 Oct 2021 11:09:27 -0400 > >> Tom Rini wrote: > > >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > >> > > On Fri, 22 Oct 2021 12:09:19 +0200 > >> > > Heinrich Schuchardt wrote: > >> > > > >> > > > On 10/21/21 15:00, Marek Behún wrote: > >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for > >> > > > > mvebu > >> > > > > platform in Kconfig? > >> > > > > > >> > > > > >> > > > We should only use 'imply' for suggested settings and never for hard > >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying > >> > > > it > >> > > > for mvebu would be redundant. > >> > > > > >> > > > In an OS distribution we only want to ship a single version of > >> > > > mkimage. > >> > > > So it is good to elimate symbol CONFIG_MXS. > >> > > > > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > >> > > > > >> > > > Tom wrote regarding this aspect in > >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > >> > > > > >> > > > "if we're building a generically useful tool, we don't want another > >> > > > symbol for it." > >> > > > >> > > OK, so mkimage and dumpimage should be always generic and always > >> > > support all platforms, that makes sense, since the tools can be > >> > > installed as a distribution package. > >> > > > >> > > But I still think it should be possible to cripple these tools if the > >> > > developer wants to disable libcrypto due to embedded environment. > >> > >> Well, I don't think this is the real question here, is it? > >> I think the tools part is clear: distros want to build just mkimage, > >> supporting as many platforms as possible, and might need to avoid OpenSSL. > >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make > >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the > >> build (at least somewhat, I still get link errors). > > > > The problem is, are distros doing a tools-only build, for tools, or are > > they doing it per board? Like, hey, ugh, OpenEmbedded uses > > sandbox_defconfig and cross_tools as the targets. That's not quite what > > I was hoping to see. So I want to know everyone else is doing, rather > > than we hope they're doing. > > Thanks for bringing this to my attention! > > In Debian, the u-boot-tools package is built using tools-only, and for > each of the board-specific targets, it still ends up building the > relevent tools, but we throw them away and do not ship them in any > packages. > > With 2021.10, the board-specific builds made it harder to avoid openssl > with the corresponding tools, and I reluctantly added a dependency on > openssl... (which is technically permitted in Debian, having declared > openssl as a system library to avoid the GPL incompatibilities, but > ... meh.) But this is purely a *build-time* dependency only, right? The resulting images do not have any openssl code in them, they were just *created* (signed) using that code. I don't think this a legal issue? The problems are about *shipping* openssl code, which you only do for u-boot-tools - where it now can be disabled. > I also have been doing some packaging of u-boot for GNU Guix, where I > suspect the stance wouldn't be as willing to accept such a compromise... > > So... I would *love* an option to be able to build a board-only config > without any of the tools; Why is this a problem (see above)? Who is building board builds? It's either the maintainer when creating the binary package, or a curious user, right? And they can surely *use* OpenSSL during build time - if it's needed by the board. Cheers, Andre > do some boards use board-specific tools as > part of their build processes? > > > live well, > vagrant
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Friday 22 October 2021 09:47:35 Vagrant Cascadian wrote: > do some boards use board-specific tools as part of their build processes? Lot of boards are using mkimage for generating final U-Boot binary. Prior U-Boot 2021.10 all 32-bit mvebu boards used own specific version of mkimage to generate final U-Boot binary. mkimage had own compile time options (defined in board include header files) which generated unique ./tools/mkimage binary, specific for just one board. Since U-Boot 2021.10 now all 32-bit mvebu boards are using one common mkimage binary. So you can even do defconfig for some x86 board, build mkimage binary and then you can use this mkimage binary also for building final mvebu (arm) U-Boot binary. Side effect of this change was hard dependency on openssl, but we are discussing how to solve and remove that hard dependency. I do not know if there are any processors, SoCs or boards which require board-specific version of some tool (e.g. mkimage) in U-Boot 2021.10.
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Tom Rini wrote: > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> On Fri, 22 Oct 2021 11:09:27 -0400 >> Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> > > Heinrich Schuchardt wrote: >> > > >> > > > On 10/21/21 15:00, Marek Behún wrote: >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu >> > > > > platform in Kconfig? >> > > > > >> > > > >> > > > We should only use 'imply' for suggested settings and never for hard >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it >> > > > for mvebu would be redundant. >> > > > >> > > > In an OS distribution we only want to ship a single version of >> > > > mkimage. >> > > > So it is good to elimate symbol CONFIG_MXS. >> > > > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> > > > >> > > > Tom wrote regarding this aspect in >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> > > > >> > > > "if we're building a generically useful tool, we don't want another >> > > > symbol for it." >> > > >> > > OK, so mkimage and dumpimage should be always generic and always >> > > support all platforms, that makes sense, since the tools can be >> > > installed as a distribution package. >> > > >> > > But I still think it should be possible to cripple these tools if the >> > > developer wants to disable libcrypto due to embedded environment. >> >> Well, I don't think this is the real question here, is it? >> I think the tools part is clear: distros want to build just mkimage, >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> build (at least somewhat, I still get link errors). > > The problem is, are distros doing a tools-only build, for tools, or are > they doing it per board? Like, hey, ugh, OpenEmbedded uses > sandbox_defconfig and cross_tools as the targets. That's not quite what > I was hoping to see. So I want to know everyone else is doing, rather > than we hope they're doing. Thanks for bringing this to my attention! In Debian, the u-boot-tools package is built using tools-only, and for each of the board-specific targets, it still ends up building the relevent tools, but we throw them away and do not ship them in any packages. With 2021.10, the board-specific builds made it harder to avoid openssl with the corresponding tools, and I reluctantly added a dependency on openssl... (which is technically permitted in Debian, having declared openssl as a system library to avoid the GPL incompatibilities, but ... meh.) I also have been doing some packaging of u-boot for GNU Guix, where I suspect the stance wouldn't be as willing to accept such a compromise... So... I would *love* an option to be able to build a board-only config without any of the tools; do some boards use board-specific tools as part of their build processes? live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: > On Fri, 22 Oct 2021 11:09:27 -0400 > Tom Rini wrote: > > Hi, > > > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > > > On Fri, 22 Oct 2021 12:09:19 +0200 > > > Heinrich Schuchardt wrote: > > > > > > > On 10/21/21 15:00, Marek Behún wrote: > > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > > > platform in Kconfig? > > > > > > > > > > > > > We should only use 'imply' for suggested settings and never for hard > > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > > > for mvebu would be redundant. > > > > > > > > In an OS distribution we only want to ship a single version of mkimage. > > > > So it is good to elimate symbol CONFIG_MXS. > > > > > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > > > > > Tom wrote regarding this aspect in > > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > > > > > "if we're building a generically useful tool, we don't want another > > > > symbol for it." > > > > > > OK, so mkimage and dumpimage should be always generic and always > > > support all platforms, that makes sense, since the tools can be > > > installed as a distribution package. > > > > > > But I still think it should be possible to cripple these tools if the > > > developer wants to disable libcrypto due to embedded environment. > > Well, I don't think this is the real question here, is it? > I think the tools part is clear: distros want to build just mkimage, > supporting as many platforms as possible, and might need to avoid OpenSSL. > This should be covered by TOOLS_LIBCRYPTO=[yn] and "make > tools-only_defconfg && make tools", and Samuel's patch actually fixes the > build (at least somewhat, I still get link errors). The problem is, are distros doing a tools-only build, for tools, or are they doing it per board? Like, hey, ugh, OpenEmbedded uses sandbox_defconfig and cross_tools as the targets. That's not quite what I was hoping to see. So I want to know everyone else is doing, rather than we hope they're doing. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 11:09:27 -0400 Tom Rini wrote: Hi, > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > > On Fri, 22 Oct 2021 12:09:19 +0200 > > Heinrich Schuchardt wrote: > > > > > On 10/21/21 15:00, Marek Behún wrote: > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > > platform in Kconfig? > > > > > > > > > > We should only use 'imply' for suggested settings and never for hard > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > > for mvebu would be redundant. > > > > > > In an OS distribution we only want to ship a single version of mkimage. > > > So it is good to elimate symbol CONFIG_MXS. > > > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > > > Tom wrote regarding this aspect in > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > > > "if we're building a generically useful tool, we don't want another > > > symbol for it." > > > > OK, so mkimage and dumpimage should be always generic and always > > support all platforms, that makes sense, since the tools can be > > installed as a distribution package. > > > > But I still think it should be possible to cripple these tools if the > > developer wants to disable libcrypto due to embedded environment. Well, I don't think this is the real question here, is it? I think the tools part is clear: distros want to build just mkimage, supporting as many platforms as possible, and might need to avoid OpenSSL. This should be covered by TOOLS_LIBCRYPTO=[yn] and "make tools-only_defconfg && make tools", and Samuel's patch actually fixes the build (at least somewhat, I still get link errors). The question at hand is whether *board* builds should be able to *force* TOOLS_LIBCRYPTO, aka "select" this symbol. This was somewhat denied by Alex, on the grounds of the top comment in tools/Makefile: # Host tools can be used across multiple targets, or different configurations # of the same target. Thus, host tools must be able to handle any combination # of target configurations. To prevent having different variations of the same # tool, the tool build options may not depend on target configuration. I read this as: "a tool like mkimage should not use #ifdef CONFIG_PLATFORM_FEATURE", but I don't see why a defconfig should not be able to select TOOLS_LIBCRYPTO, if that's needed to package the firmware. Do I get this correctly? If that's the case, then I think we should actually stick more with the solution in v2, or maybe split that patch, so v4 plus Pali's separate patch to select/depend on LIBCRYPTO for boards using kwbimage. Does that make sense? Cheers, Andre > > This is probably the time to reach out to some of the distro folks to > see how they would like to see things handled for "build the tools we > need to package for the user" and also "build the binary for the > platform". >
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: > On Fri, 22 Oct 2021 12:09:19 +0200 > Heinrich Schuchardt wrote: > > > On 10/21/21 15:00, Marek Behún wrote: > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > platform in Kconfig? > > > > > > > We should only use 'imply' for suggested settings and never for hard > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > > for mvebu would be redundant. > > > > In an OS distribution we only want to ship a single version of mkimage. > > So it is good to elimate symbol CONFIG_MXS. > > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > > > Tom wrote regarding this aspect in > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > > > "if we're building a generically useful tool, we don't want another > > symbol for it." > > OK, so mkimage and dumpimage should be always generic and always > support all platforms, that makes sense, since the tools can be > installed as a distribution package. > > But I still think it should be possible to cripple these tools if the > developer wants to disable libcrypto due to embedded environment. This is probably the time to reach out to some of the distro folks to see how they would like to see things handled for "build the tools we need to package for the user" and also "build the binary for the platform". -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Fri, 22 Oct 2021 12:09:19 +0200 Heinrich Schuchardt wrote: > On 10/21/21 15:00, Marek Behún wrote: > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > platform in Kconfig? > > > > We should only use 'imply' for suggested settings and never for hard > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it > for mvebu would be redundant. > > In an OS distribution we only want to ship a single version of mkimage. > So it is good to elimate symbol CONFIG_MXS. > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > Tom wrote regarding this aspect in > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > "if we're building a generically useful tool, we don't want another > symbol for it." OK, so mkimage and dumpimage should be always generic and always support all platforms, that makes sense, since the tools can be installed as a distribution package. But I still think it should be possible to cripple these tools if the developer wants to disable libcrypto due to embedded environment. Marek
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 10/21/21 15:00, Marek Behún wrote: BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu platform in Kconfig? We should only use 'imply' for suggested settings and never for hard requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it for mvebu would be redundant. In an OS distribution we only want to ship a single version of mkimage. So it is good to elimate symbol CONFIG_MXS. How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. Tom wrote regarding this aspect in https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: "if we're building a generically useful tool, we don't want another symbol for it." We should therefore remove the following dependencies in tools/Makefile: CONFIG_MX23 CONFIG_MX28 CONFIG_ARMADA_38X Best regards Heinrich
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 10/21/21 8:00 AM, Marek Behún wrote: > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > platform in Kconfig? No, that would not do anything. For example: config ARMADA_32BIT imply TOOLS_LIBCRYPTO is equivalent to: config TOOLS_LIBCRYPTO default y if ARMADA_32BIT but TOOLS_LIBCRYPTO is already "default y". To force TOOLS_LIBCRYPTO=y, you must select it. Regards, Samuel
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Thursday 21 October 2021 15:00:48 Marek Behún wrote: > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > platform in Kconfig? FYI https://lore.kernel.org/u-boot/20211021093304.25399-1-p...@kernel.org/ (forgot to CC)
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu platform in Kconfig?
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
Hi Samuel, On Wed, 20 Oct 2021 09:14:11 -0500 Samuel Holland wrote: > Andre is correct. No version of this patch makes *any* change to *any* > in-tree defconfig build, because TOOLS_LIBCRYPTO=y in all defconfigs. > Even if I was to accept your assertion that it hides a possible error on > platforms using kwbimage: > > 1) It does not *create* any errors for those platforms, and > 2) It *fixes* possible errors for almost all other platforms. It does create possible errors, since it is possible to choose config options which won't compile. The fact that defconfig have this option enabled for those platforms does not matter. What matters is that I can then validly change the config with make menuconfig, and it won't compile. A compilation error should not occur with valid config options. That's why dependencies need to be made in Kconfig, so that if Kconfig decides that kwbimage is to be built, then it will force crypto. (Yes, I know that there currently are many ways to change Kconfig options and the result will fail to compile. That behaviour is unwanted and should be fixed by adding Kconfig dependencies so that it isn't possible to choose configuration that won't compile.) Marek
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 10/20/21 8:47 AM, Pali Rohár wrote: > On Wednesday 20 October 2021 14:29:02 Andre Przywara wrote: >> On Wed, 20 Oct 2021 09:29:25 +0200 >> Pali Rohár wrote: >> >> Hi, >> >>> On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote: Some image types (kwbimage and mxsimage) always depend on OpenSSL, so they can only be included in mkimage when TOOLS_LIBCRYPTO is selected. Use Makefile logic to conditionally link the files. Signed-off-by: Samuel Holland >>> >>> NAK. >>> >>> As explained in previous email [1], kwbimage is required for building >>> Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms. >>> Therefore it cannot be disabled or hidden behind some user config >>> options for these platforms (and it does not matter if it is crypto >>> option or any other option). >> >> So somehow we need to find a solution between your view and Alex' view of >> things. >> First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO >> defaults to y, so if I am not mistaken that means that a user would need >> to deliberately turn that off to trigger build errors? >> And also: the situation with this patch is not worse as before, isn't it? > > I do not think so. Without this patch, kwbimage is always going > compiled, which means it is compiled also for mvebu platforms which > needs it. > > With this patch it is possible via _valid_ config options to disable > compilation of kwbimage which would lead to totally bogus and > unintuitive behavior and errors. Without this patch compilation fails on > exact and clear error = cryto header files (or libs) were not found and > user / developer / package maintainer would know what is needed (= mean > to install missing dependency). Andre is correct. No version of this patch makes *any* change to *any* in-tree defconfig build, because TOOLS_LIBCRYPTO=y in all defconfigs. >> So if it's just the missing improvement that you are concerned about, I am >> not sure that should block this patch? > > V3 patch was improvement - it enforced required dependencies and I guess > it showed some build system error message when dependences were not met. > This is improvement from situation without patch when it failed on > compiling kwbimage which probably showed error message about missing > header files (or libs, depends on which stage it failed). It was not the > best choice as in some cases it enforced crypto dependencies also in > cases when they were not really required -- but it should have solve the > problem that dependences are there for platforms which require them. No, you would have seen the exact same error message with v3 as you get today without any patch. Because all v3 does is enforce that kwbimage.o gets compiled on certain platforms (whereas today, it is compiled on *all* platforms). > v4 patch is not improvement, it is step backward - it started allowing > to compile mkimage without required functionality, even on platforms > which needs them, and effectively hides issue which is there. Even if I was to accept your assertion that it hides a possible error on platforms using kwbimage: 1) It does not *create* any errors for those platforms, and 2) It *fixes* possible errors for almost all other platforms. >> I mean you could always propose >> your own version of that missing piece, to improve the situation for the >> boards you care about? And we should have this discussion there? > > I think I have written details and some proposed solution in that email. Yes, Pali, like I said in response to your comments on v2, you should really be the one sending the patch here. I know next to nothing about your platforms, and even giving me a list of SoC families does not tell me where in the Kconfig you want the change to go. I am not interested in continuing to play a guessing game (which so far I have been losing). The TOOLS_LIBCRYPTO option has been around for several months now, so there is no need to wait for my series to send your patch. In fact, it was your change which broke the mkimage build with TOOLS_LIBCRYPTO=n in the first place, so it is all the more disappointing that, instead of fixing it, you are now trying to block other people from fixing it. > What is needed is to ensure that kwbimage is always compiled for > platforms which require it (list of platform are in email 1 in previous > email). This can be done as hard dependency like it is currently without > this patch (ugly, does not show nice error message and enforce everybody > to have crypto dependency, even platforms which do not need it). Other > solution could be to define some select symbol which says that kwbimage > is required and then kwbimage would be unconditionally compiled when > this symbol is selected. And to make error message nice in build system, > this symbol could depends on crypto symbol to ensure that all > dependencies are met when trying to compile something which needs it. > Another option could be to implement required
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Wednesday 20 October 2021 14:29:02 Andre Przywara wrote: > On Wed, 20 Oct 2021 09:29:25 +0200 > Pali Rohár wrote: > > Hi, > > > On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote: > > > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so > > > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected. > > > Use Makefile logic to conditionally link the files. > > > > > > Signed-off-by: Samuel Holland > > > > NAK. > > > > As explained in previous email [1], kwbimage is required for building > > Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms. > > Therefore it cannot be disabled or hidden behind some user config > > options for these platforms (and it does not matter if it is crypto > > option or any other option). > > So somehow we need to find a solution between your view and Alex' view of > things. > First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO > defaults to y, so if I am not mistaken that means that a user would need > to deliberately turn that off to trigger build errors? > And also: the situation with this patch is not worse as before, isn't it? I do not think so. Without this patch, kwbimage is always going compiled, which means it is compiled also for mvebu platforms which needs it. With this patch it is possible via _valid_ config options to disable compilation of kwbimage which would lead to totally bogus and unintuitive behavior and errors. Without this patch compilation fails on exact and clear error = cryto header files (or libs) were not found and user / developer / package maintainer would know what is needed (= mean to install missing dependency). > So if it's just the missing improvement that you are concerned about, I am > not sure that should block this patch? V3 patch was improvement - it enforced required dependencies and I guess it showed some build system error message when dependences were not met. This is improvement from situation without patch when it failed on compiling kwbimage which probably showed error message about missing header files (or libs, depends on which stage it failed). It was not the best choice as in some cases it enforced crypto dependencies also in cases when they were not really required -- but it should have solve the problem that dependences are there for platforms which require them. v4 patch is not improvement, it is step backward - it started allowing to compile mkimage without required functionality, even on platforms which needs them, and effectively hides issue which is there. > I mean you could always propose > your own version of that missing piece, to improve the situation for the > boards you care about? And we should have this discussion there? I think I have written details and some proposed solution in that email. What is needed is to ensure that kwbimage is always compiled for platforms which require it (list of platform are in email 1 in previous email). This can be done as hard dependency like it is currently without this patch (ugly, does not show nice error message and enforce everybody to have crypto dependency, even platforms which do not need it). Other solution could be to define some select symbol which says that kwbimage is required and then kwbimage would be unconditionally compiled when this symbol is selected. And to make error message nice in build system, this symbol could depends on crypto symbol to ensure that all dependencies are met when trying to compile something which needs it. Another option could be to implement required crypto functions directly in u-boot source tree to remove external dependency. I do not know which solution is the best or how hard they are to implement, and neither what can be accepted by other u-boot developers / maintainers. I see an issue here that fixing this problem need to touch more parts of u-boot source code and build system which, which means that u-boot maintainers need to say what they are willing to accept and what not. > As it stands right now, this patch just improves things (just not > *everything*), and it is a prerequisite for the rest of the series > (unrelated to your problems), so I would like to go ahead on this one. Well, maybe this patch improves some things about non-mvebu platforms, but makes mvebu platform code / build system worse. And due to this fact I cannot say that I want this change... > Cheers, > Andre. > > > kwbimage must be unconditionally enabled on > > these platforms like it was before this change, as it is crucial part of > > build. > > > > [1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/ > > > > > --- > > > > > > Changes in v4: > > > - Do not select TOOLS_LIBCRYPTO anywhere > > > > > > Changes in v3: > > > - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best > > >as I can tell, using the suggestions from Pali Rohár) > > > > > > Changes in v2: > > > - Refactored the first patch on top of TOOLS_LIBCRYPTO >
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Wed, 20 Oct 2021 09:29:25 +0200 Pali Rohár wrote: Hi, > On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote: > > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so > > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected. > > Use Makefile logic to conditionally link the files. > > > > Signed-off-by: Samuel Holland > > NAK. > > As explained in previous email [1], kwbimage is required for building > Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms. > Therefore it cannot be disabled or hidden behind some user config > options for these platforms (and it does not matter if it is crypto > option or any other option). So somehow we need to find a solution between your view and Alex' view of things. First: Pali, do you see any actual problem at the moment? TOOLS_LIBCRYPTO defaults to y, so if I am not mistaken that means that a user would need to deliberately turn that off to trigger build errors? And also: the situation with this patch is not worse as before, isn't it? So if it's just the missing improvement that you are concerned about, I am not sure that should block this patch? I mean you could always propose your own version of that missing piece, to improve the situation for the boards you care about? And we should have this discussion there? As it stands right now, this patch just improves things (just not *everything*), and it is a prerequisite for the rest of the series (unrelated to your problems), so I would like to go ahead on this one. Cheers, Andre. > kwbimage must be unconditionally enabled on > these platforms like it was before this change, as it is crucial part of > build. > > [1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/ > > > --- > > > > Changes in v4: > > - Do not select TOOLS_LIBCRYPTO anywhere > > > > Changes in v3: > > - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best > >as I can tell, using the suggestions from Pali Rohár) > > > > Changes in v2: > > - Refactored the first patch on top of TOOLS_LIBCRYPTO > > > > scripts/config_whitelist.txt | 1 - > > tools/Makefile | 19 +-- > > tools/mxsimage.c | 3 --- > > 3 files changed, 5 insertions(+), 18 deletions(-) > > > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > > index cd94b5777a..affae6875d 100644 > > --- a/scripts/config_whitelist.txt > > +++ b/scripts/config_whitelist.txt > > @@ -828,7 +828,6 @@ CONFIG_MXC_UART_BASE > > CONFIG_MXC_USB_FLAGS > > CONFIG_MXC_USB_PORT > > CONFIG_MXC_USB_PORTSC > > -CONFIG_MXS > > CONFIG_MXS_AUART > > CONFIG_MXS_AUART_BASE > > CONFIG_MXS_OCOTP > > diff --git a/tools/Makefile b/tools/Makefile > > index 999fd46531..a9b3d982d8 100644 > > --- a/tools/Makefile > > +++ b/tools/Makefile > > @@ -94,9 +94,11 @@ ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix > > lib/ecdsa/, ecdsa-libcrypto. > > AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \ > > aes-encrypt.o aes-decrypt.o) > > > > -# Cryptographic helpers that depend on openssl/libcrypto > > -LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \ > > - fdt-libcrypto.o) > > +# Cryptographic helpers and image types that depend on openssl/libcrypto > > +LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \ > > + lib/fdt-libcrypto.o \ > > + kwbimage.o \ > > + mxsimage.o > > > > ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o > > > > @@ -118,10 +120,8 @@ dumpimage-mkimage-objs := aisimage.o \ > > imximage.o \ > > imx8image.o \ > > imx8mimage.o \ > > - kwbimage.o \ > > lib/md5.o \ > > lpc32xximage.o \ > > - mxsimage.o \ > > omapimage.o \ > > os_support.o \ > > pblimage.o \ > > @@ -156,22 +156,13 @@ fit_info-objs := $(dumpimage-mkimage-objs) > > fit_info.o > > fit_check_sign-objs := $(dumpimage-mkimage-objs) fit_check_sign.o > > file2include-objs := file2include.o > > > > -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),) > > -# Add CONFIG_MXS into host CFLAGS, so we can check whether or not register > > -# the mxsimage support within tools/mxsimage.c . > > -HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS > > -endif > > - > > ifdef CONFIG_TOOLS_LIBCRYPTO > > # This affects include/image.h, but including the board config file > > # is tricky, so manually define this options here. > > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE > > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x > > HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER > > -endif > > > > -# MXSImage needs LibSSL > > -ifneq > > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),) > >
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On Tuesday 19 October 2021 21:44:51 Samuel Holland wrote: > Some image types (kwbimage and mxsimage) always depend on OpenSSL, so > they can only be included in mkimage when TOOLS_LIBCRYPTO is selected. > Use Makefile logic to conditionally link the files. > > Signed-off-by: Samuel Holland NAK. As explained in previous email [1], kwbimage is required for building Kirkwood, Dove, A370, AXP, A375, A38x, A39x and MSYS platforms. Therefore it cannot be disabled or hidden behind some user config options for these platforms (and it does not matter if it is crypto option or any other option). kwbimage must be unconditionally enabled on these platforms like it was before this change, as it is crucial part of build. [1] - https://lore.kernel.org/u-boot/20211015114735.rig3e4cuc7mn6a7e@pali/ > --- > > Changes in v4: > - Do not select TOOLS_LIBCRYPTO anywhere > > Changes in v3: > - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best >as I can tell, using the suggestions from Pali Rohár) > > Changes in v2: > - Refactored the first patch on top of TOOLS_LIBCRYPTO > > scripts/config_whitelist.txt | 1 - > tools/Makefile | 19 +-- > tools/mxsimage.c | 3 --- > 3 files changed, 5 insertions(+), 18 deletions(-) > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index cd94b5777a..affae6875d 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -828,7 +828,6 @@ CONFIG_MXC_UART_BASE > CONFIG_MXC_USB_FLAGS > CONFIG_MXC_USB_PORT > CONFIG_MXC_USB_PORTSC > -CONFIG_MXS > CONFIG_MXS_AUART > CONFIG_MXS_AUART_BASE > CONFIG_MXS_OCOTP > diff --git a/tools/Makefile b/tools/Makefile > index 999fd46531..a9b3d982d8 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -94,9 +94,11 @@ ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix > lib/ecdsa/, ecdsa-libcrypto. > AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \ > aes-encrypt.o aes-decrypt.o) > > -# Cryptographic helpers that depend on openssl/libcrypto > -LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/, \ > - fdt-libcrypto.o) > +# Cryptographic helpers and image types that depend on openssl/libcrypto > +LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \ > + lib/fdt-libcrypto.o \ > + kwbimage.o \ > + mxsimage.o > > ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o > > @@ -118,10 +120,8 @@ dumpimage-mkimage-objs := aisimage.o \ > imximage.o \ > imx8image.o \ > imx8mimage.o \ > - kwbimage.o \ > lib/md5.o \ > lpc32xximage.o \ > - mxsimage.o \ > omapimage.o \ > os_support.o \ > pblimage.o \ > @@ -156,22 +156,13 @@ fit_info-objs := $(dumpimage-mkimage-objs) fit_info.o > fit_check_sign-objs := $(dumpimage-mkimage-objs) fit_check_sign.o > file2include-objs := file2include.o > > -ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_TOOLS_LIBCRYPTO),) > -# Add CONFIG_MXS into host CFLAGS, so we can check whether or not register > -# the mxsimage support within tools/mxsimage.c . > -HOSTCFLAGS_mxsimage.o += -DCONFIG_MXS > -endif > - > ifdef CONFIG_TOOLS_LIBCRYPTO > # This affects include/image.h, but including the board config file > # is tricky, so manually define this options here. > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x > HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER > -endif > > -# MXSImage needs LibSSL > -ifneq > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_TOOLS_LIBCRYPTO),) > HOSTCFLAGS_kwbimage.o += \ > $(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "") > HOSTLDLIBS_mkimage += \ > diff --git a/tools/mxsimage.c b/tools/mxsimage.c > index 002f4b525a..2bfbb421eb 100644 > --- a/tools/mxsimage.c > +++ b/tools/mxsimage.c > @@ -5,8 +5,6 @@ > * Copyright (C) 2012-2013 Marek Vasut > */ > > -#ifdef CONFIG_MXS > - > #include > #include > #include > @@ -2363,4 +2361,3 @@ U_BOOT_IMAGE_TYPE( > NULL, > mxsimage_generate > ); > -#endif > -- > 2.32.0 >
