[U-Boot] tpm TIS TPMv2.0
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including full duplex. Regards, Martin
Dipl. Inform. Martin Hecht
Senior Embedded Specialist / Functional Safety Engineer TA1130871952
Avnet SILICA
[http://digital.avnet.com/signature/images/silica/Avnet_silica_logo.png]
Englische Straße 27
10587 Berlin
martin.hecht@avnet.eumailto:%20martin.hecht@avnet.eu O +49 (0) 30 214 88 227
M +49 (0) 172 890 60 19
avnet-silica.comhttp://avnet-silica.eu/
[cid:image002.png@01D404BE.4B5BC5F0]
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
Regards, Miquèl
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM. Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware. For the code you wrote I'm considering to add a few lines to control the CS# in that way how my xfer is doing this for the SLB9670. On the other hand what about to use a xfer what can handle all three cases (in, out, in/out)?
Regards, Miquèl
Regards, Martin
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
For the code you wrote I'm considering to add a few lines to control the CS# in that way how my xfer is doing this for the SLB9670.
Yes please, share the patch and add me in cc so I could test it with mine.
On the other hand what about to use a xfer what can handle all three cases (in, out, in/out)?
As I did not implement any TPM command that needed it I did not care about it. Of course if there is a need for it: it should be implemented too. I contributed only basic support for essential commands (measured boot, mainly) but please feel free to enhance the code to add more features!
Regards, Miquèl
Hi Miquèl,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:43 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that signal.
For the code you wrote I'm considering to add a few lines to control the CS# in that way how my xfer is doing this for the SLB9670.
Yes please, share the patch and add me in cc so I could test it with mine.
Fine, will do so soon.
On the other hand what about to use a xfer what can handle all three cases (in, out, in/out)?
As I did not implement any TPM command that needed it I did not care about it. Of course if there is a need for it: it should be implemented too. I contributed only basic support for essential commands (measured boot, mainly) but please feel free to enhance the code to add more features!
Ok, seems we are working on the same stuff.
Regards, Miquèl
Regards, Martin
Hi Martin,
On Mon, 18 Jun 2018 09:13:36 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquèl,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:43 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that signal.
Ok, can you explain what should be done (and where/when) to make it work with the SLB9670?
Thanks, Miquèl
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 11:22 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de; Roeder, Michael (Avnet Silica) Michael.Roeder@avnet.eu Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 09:13:36 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquèl,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:43 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel, Simon,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual
xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control
the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that
signal.
Ok, can you explain what should be done (and where/when) to make it work with the SLB9670?
Please let me come back with my proposal soon. I have already the tpm running with my little different driver. There is another patch required for my SoC to setup the SPI correctly. Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
Thanks, Miquèl
Hi Martin (Avnet Silica),
On Mon, 18 Jun 2018 09:29:33 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 11:22 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de; Roeder, Michael (Avnet Silica) Michael.Roeder@avnet.eu Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 09:13:36 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquèl,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:43 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:05 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
> Hi Miquel, Simon, > > Is there any specific reason why the new tpm2_tis_spi_xfer > doesn't support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual
xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control
the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that
signal.
Ok, can you explain what should be done (and where/when) to make it work with the SLB9670?
Please let me come back with my proposal soon. I have already the tpm running with my little different driver. There is another patch required for my SoC to setup the SPI correctly.
ok
Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
I did not know this one, actually I mostly worked on U-Boot.
However, this compatible is misleading as it does not make any difference between v1.x and v2.0 specification.
Regards, Miquèl
Hi Miquèl,
Hi Martin (Avnet Silica),
On Mon, 18 Jun 2018 09:29:33 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 11:22 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de; Roeder, Michael (Avnet Silica) Michael.Roeder@avnet.eu Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 09:13:36 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquèl,
-----Original Message----- From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] Sent: Montag, 18. Juni 2018 10:43 To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de Subject: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote:
Hi Miquel,
> -----Original Message----- > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] > Sent: Montag, 18. Juni 2018 10:05 > To: Hecht, Martin (Avnet Silica) Martin.Hecht@avnet.eu > Cc: sjg@chromium.org; u-boot@lists.denx.de > Subject: Re: [U-Boot] tpm TIS TPMv2.0 > > Hi Martin, > > On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" > Martin.Hecht@avnet.eu wrote: > > > Hi Miquel, Simon, > > > > Is there any specific reason why the new tpm2_tis_spi_xfer > > doesn't > support full duplex? It seems we did some work in parallel > but you sent the patches earlier. Is that codes tested > against an existing TPM v2? I have a working implementation > what runs on > SLB9670 including
full duplex.
> > What do you mean exactly? > > I don't think the TPM2 protocol makes real use of > full-duplex unless for the wait state between the host > command and the actual
xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at
same time.
I did this in my implementation what gave me an easy chance to control
the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that
signal.
Ok, can you explain what should be done (and where/when) to make it work with the SLB9670?
Please let me come back with my proposal soon. I have already the tpm running with my little different driver. There is another patch required for my SoC to setup the SPI correctly.
ok
Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
I did not know this one, actually I mostly worked on U-Boot.
However, this compatible is misleading as it does not make any difference between v1.x and v2.0 specification.
But on the other hand it would give us a chance to determine the version at runtime what could be beneficial for firmware updates. But this is a special case.
Regards, Miquèl
Regards, Martin
Hi Martin,
Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
I did not know this one, actually I mostly worked on U-Boot.
However, this compatible is misleading as it does not make any difference between v1.x and v2.0 specification.
But on the other hand it would give us a chance to determine the version at runtime what could be beneficial for firmware updates. But this is a special case.
We already discussed that point on the ML and decided to choose the version at compile time. I did not have the firmware update case in mind though.
Regards, Miquèl
Hi,
On 18 June 2018 at 03:47, Miquel Raynal miquel.raynal@bootlin.com wrote:
Hi Martin,
Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
I did not know this one, actually I mostly worked on U-Boot.
However, this compatible is misleading as it does not make any difference between v1.x and v2.0 specification.
But on the other hand it would give us a chance to determine the version at runtime what could be beneficial for firmware updates. But this is a special case.
We already discussed that point on the ML and decided to choose the version at compile time. I did not have the firmware update case in mind though.
I think we need to move to determining the version at run-time, allowing people to build U-Boot with both versions if needed. This will be helpful for testing in particular.
Regards, Simon
Hi Miquel, Simon,
Hi,
On 18 June 2018 at 03:47, Miquel Raynal miquel.raynal@bootlin.com wrote:
Hi Martin,
Nevertheless one question: Why did you define another dts binding instead of using that one what is already available on the Linux kernel? There is "tcg,tpm_tis-spi" already defined.
I did not know this one, actually I mostly worked on U-Boot.
However, this compatible is misleading as it does not make any
difference
between v1.x and v2.0 specification.
But on the other hand it would give us a chance to determine the version
at
runtime what could be beneficial for firmware updates. But this is a
special case.
We already discussed that point on the ML and decided to choose the version at compile time. I did not have the firmware update case in mind though.
I think we need to move to determining the version at run-time, allowing people to build U-Boot with both versions if needed. This will be helpful for testing in particular.
Also I would prefer to determine the version at runtime. I will check this with two different firmware versions of SLB9670 (for TPM 1.2 and 2.0).
Regards Martin
Regards, Simon
Hi Martin,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that signal.
For the code you wrote I'm considering to add a few lines to control the CS# in that way how my xfer is doing this for the SLB9670.
Yes please, share the patch and add me in cc so I could test it with mine.
Fine, will do so soon.
What's the status of this? I did not spot any patches, maybe you forgot to copy me? Otherwise do you still plan to share the changes? That would be great!
Thanks, Miquèl
Hi Miquel,
I'm busy on that again hopefully end of next week. I was bound in other projects too. So you didn't miss anything. I come back on you soon. By the way allow me one question please. Would you have a chance to test on your how too? What processor do you use? I'm on Zynq7000 and ZynqMP.
Regards Martin
Gesendet über BlackBerry Work (www.blackberry.com) ________________________________ Von: Miquel Raynal miquel.raynal@bootlin.com Datum: 13.07.2018 21:30 An: "Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu Cc: sjg@chromium.org; u-boot@lists.denx.de; "Roeder, Michael (Avnet Silica)" Michael.Roeder@avnet.eu Betreff: Re: [U-Boot] tpm TIS TPMv2.0
Hi Martin,
Is there any specific reason why the new tpm2_tis_spi_xfer doesn't
support full duplex? It seems we did some work in parallel but you sent the patches earlier. Is that codes tested against an existing TPM v2? I have a working implementation what runs on SLB9670 including
full duplex.
What do you mean exactly?
I don't think the TPM2 protocol makes real use of full-duplex unless for the wait state between the host command and the actual xfer.
You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What I
mean is that the driver you just wrote doesn't use the xfer function in that way that you can specify in and out parameters at same time. I did this in my implementation what gave me an easy chance to control the CS# of the TPM.
Do you need this CS# handling for more advanced features? Same question for the in/out xfers?
Can you tell me on what TPM did you test? For the SLB9670 the code doesn't work on my hardware.
I tested with a ST33TPHF20 SPI TPM.
I'm surprised it did not work with an SLB9670, I don't see anything in the spec explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that signal.
For the code you wrote I'm considering to add a few lines to control the CS# in that way how my xfer is doing this for the SLB9670.
Yes please, share the patch and add me in cc so I could test it with mine.
Fine, will do so soon.
What's the status of this? I did not spot any patches, maybe you forgot to copy me? Otherwise do you still plan to share the changes? That would be great!
Thanks, Miquèl
Hi Martin,
"Hecht, Martin (Avnet Silica)" Martin.Hecht@avnet.eu wrote on Sat, 14 Jul 2018 13:04:26 +0000:
Hi Miquel,
I'm busy on that again hopefully end of next week. I was bound in other projects too. So you didn't miss anything. I come back on you soon. By the way allow me one question please. Would you have a chance to test on your how too? What processor do you use? I'm on Zynq7000 and ZynqMP.
If I still have the hardware I could test it on a Marvell Espressobin with a ST TPM.
Thanks, Miquèl
participants (3)
-
Hecht, Martin (Avnet Silica) -
Miquel Raynal -
Simon Glass