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.
Alex
