[U-Boot] [PATCH] sandbox_flattree: Switch to TPMv2 support

[Tom Rini]

On Fri, Jun 01, 2018 at 09:25:19AM -0600, Simon Glass wrote:
> +Miquel due to sandbox TPM issue
> 
> Hi Tom,
> 
> On 25 May 2018 at 06:27, Tom Rini <trini at konsulko.com> wrote:
> > In order to have the test.py tests for TPMv2 run automatically we need
> > to have one of our sandbox builds use TPMv2 rather than TPMv1.  Switch
> > sandbox_flattree over to this style of TPM.
> 
> The problem seems to be that the sandbox driver is only built with
> either TPMv1 or TPMv2. It needs to be able to build with both, so we
> can run tests with both.

Right.  But we don't have any run-time automatic tests for TPMv1 as the
'tpm test' command needs to be done manually, at least today (unless I'm
missing something under test/py/tests/).  And we can't (functionally in
real uses) have both TPM types available.  Perhaps we should make TPMv2
the default for sandbox?  All of the TPMv1 code will still be getting
build-time exercised due to platforms with TPMv1 on them.

> It really doesn't make any sense to have build-time branches for sandbox.
> 
> We currently have:
> 
> sandbox - should be used for most tests
> sandbox64 - special build that forces a 64-bit host
> sandbox_flattree - builds with dev_read_...() functions defined as
> inline. We need this build so that we can test those inline functions,
> and we cannot build with both the inline functions and the non-inline
> functions since they are named the same
> sandbox_noblk - builds without CONFIG_BLK, which means the legacy
> block drivers are used. We cannot use both the legacy and driver-model
> block drivers since they implement the same functions
> sandbox_spl - builds sandbox with SPL support, so you can run
> spl/u-boot-spl and it will start up and then load ./u-boot. We could
> probably remove this and add SPL support to the vanilla sandbox build,
> since people can still run ./u-boot directly
> 
> At present there are unnecessary config differences between these
> builds. This is explained by the fact that it is a pain for people to
> have to add configs separately to each defconfig. But we should
> probably make them more common. I will take a look.

OK.

> What do you think about dropping sandbox_spl and make sandbox build
> SPL? It does take slightly longer to build, perhaps 25%.

That's fine with me.

> > Cc: Simon Glass <sjg at chromium.org>
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > I'm tempted to switch the main sandbox target over instead as I don't
> > quite see where we're running the tpm1.x tests automatically.  Would
> > that be a better idea?
> > ---
> 
> Miquel, can we adjust the code to build both TPMv1 and v2 for sandbox,
> and select at run-time?

I thought we had talked about that before and couldn't easily?  One
thing I am a bit wary of is adding indirection for build coverage sake.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180601/f4d7f94e/attachment.sig>