On Wed, May 12, 2021 at 11:19:52AM -0500, Alex G. wrote: > > > On 5/12/21 10:52 AM, Simon Glass wrote: > > Hi, > > > > On Tue, 11 May 2021 at 19:10, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Tue, May 11, 2021 at 07:50:38PM -0500, Alex G. wrote: > > > > On 5/11/21 5:34 PM, Tom Rini wrote: > > > > > On Tue, May 11, 2021 at 02:57:03PM -0500, Alex G. wrote: > > > > > > On 5/6/21 9:24 AM, Simon Glass wrote: > > > > > > > In preparation for enabling CONFIG_IS_ENABLED() on the host > > > > > > > build, add > > > > > > > some options to enable the various FIT options expected in these > > > > > > > tools. > > > > > > > This will ensure that the code builds correctly when > > > > > > > CONFIG_HOST_xxx > > > > > > > is distinct from CONFIG_xxx. > > > > > > > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > > > > > > > > > Reviewed-by: Alexandru Gagniuc <mr.nuke...@gmail.com> > > > > > > > > > > > > This makes me wonder whether we should just always enable host > > > > > > features. > > > > > > Right now, each defconfig can have a different mkimage config. So > > > > > > we should > > > > > > really have mkimage-imx8, mkimage-stm32mp, etc, which support > > > > > > different > > > > > > feature sets. This doesn't make much sense. > > > > > > > > > > > > The alternative is to get rid of all these configs and always > > > > > > enable mkimage > > > > > > features. The disadvantage is that we'd require openssl for > > > > > > building target > > > > > > code. > > > > > > > > > > > > A second alternative is to have a mkimage-nossl that gets built and > > > > > > used > > > > > > when openssl isn't available. It's really just openssl that causes > > > > > > such a > > > > > > schism. > > > > > > > > > > It would probably be best to have a single mkimage for everyone, with > > > > > everything on. But before then we really need to move from openssl to > > > > > gnutls or some other library that's compatible as it's been raised > > > > > before that linking with openssl like we do is a license violation I > > > > > believe. > > > > > > > > How about the former alternative for now? i.e. compile mkimage with or > > > > without openssl, and have that be the only host side switch. > > > > > > That would be a step in the right direction, yeah. > > > > We have a NO_SDL build-time control. Perhaps have a NO_SSL one as well? > > It could be a config option instead of an environment variable. I think it > can be independent of target options, since we don't sign images in the > buildsystem anyway -- we can enable FIT verification, but mkimage without > openssl.
As people point out from time to time, "NO_SDL" is very non-obvious and doesn't fit with how the rest of U-Boot is configured. So I would rather not see NO_SSL added. Frankly, given everything else that's needed to build today, I don't think just enabling the support for verified boot in mkimage by default and making it a bit odd to turn off is a problem. But given: https://lists.denx.de/pipermail/u-boot/2017-December/313742.html I would really like to see the switch to gnutls or some other clearly compatibly licensed library first. -- Tom
signature.asc
Description: PGP signature
