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 <heinrich.schucha...@canonical.com> 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
