From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex G. Date: Wed, 12 May 2021 11:19:52 -0500 Subject: [PATCH v2 16/50] image: Add Kconfig options for FIT in the host build In-Reply-To: References: <20210506142438.1310977-1-sjg@chromium.org> <20210506082420.v2.16.I64826ed33219988294468df7b95dfa3fffd7a0a1@changeid> <659c76d0-d9aa-e270-0eb8-25cefdc238e9@gmail.com> <20210511223427.GW17669@bill-the-cat> <066428be-2db4-d143-6029-119bae223aeb@gmail.com> <20210512011006.GY17669@bill-the-cat> Message-ID: <795bd8ce-ec5b-edf1-bc4b-6f6fac838018@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/12/21 10:52 AM, Simon Glass wrote: > Hi, > > On Tue, 11 May 2021 at 19:10, Tom Rini 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 >>>>> >>>>> Reviewed-by: Alexandru Gagniuc >>>>> >>>>> 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