Hi Tom, On 1 June 2018 at 11:55, Tom Rini <tr...@konsulko.com> wrote: > > 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 <tr...@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.
I'll take a look at this. It should actually be quite easy to have two TPMs in sandbox, one v1 and one v2. At least I don't know of any impediment. > > > 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 <s...@chromium.org> > > > Signed-off-by: Tom Rini <tr...@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. Yes, I am hoping that it is just different drivers with the same API but perhaps I am going to be disappointed. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
