可信平台模块的SPI硬件协议(寻找最小的工作示例)

发布于 2025-01-23 09:14:28 字数 1683 浏览 2 评论 0原文

我正在与 infineon optiga tpm slm 9670 tpm 2.0 通过其SPI接口。

我得到了一些第一个帮助在这里,但是再次挣扎。

对于初学者,我想读出TPM的状态寄存器 href =“ https://trustedcomputinggroup.org/wp-content/uploads/tcg_pc_pc_pc_pc_client_platform_tpm_tpm_profile_ptp_2.0_r1 r1 r1 r1 22name%22%3A%22xyz%22%7D%2C69%2C734%2C0%5D“ rel =“ nofollow noreferrer”>地址为0018H 。

Interpreting the table from the TPM's

0x83            // msb to 1 because I want to read, lower bits to 3 because my xfer consists of 4 bytes
0x00 0x00 0x18  // three register address bytes, naming the register address

当我对4个字节(状态寄存器的大小)进行SPI读取后,我总是会得到ffffffff。

这是预期的还是我做错了什么?

”表46-

I am making my first steps in communication with an Infineon OPTIGA TPM SLM 9670 TPM 2.0 via its SPI interface.

I got some first help here, but struggling again.

For starters, I would like to read out the TPM's status register, whose address is given as 0018h.

Interpreting the table from the TPM's SPI Hardware Protocol specification (see below), I do an SPI write of the following four bytes:

0x83            // msb to 1 because I want to read, lower bits to 3 because my xfer consists of 4 bytes
0x00 0x00 0x18  // three register address bytes, naming the register address

When I do an SPI read of 4 bytes (size of the status register) afterwards, I always get FFFFFFFF.

Is this expected or am I doing something wrong?

enter image description here

Table 46 - SPI Bit Protocol

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

您的好友蓝忘机已上羡 2025-01-30 09:14:28

spi硬件协议规范

TPM应解码发送到Offset 0xd4_xxxx时的CS#的交易

,您必须忘记将地址偏移到0xD4:

0x83            // msb to 1 because I want to read, lower bits to 3 because my xfer consists of 4 bytes
0xD4 0x00 0x18  // three register address bytes, naming the register address

示例序列序列

TPM2_GetRandom

注意:这假设Linux内核初始化了TPM,包括已发送TPM2_STARTUP命令。如果您使用Mainline Linux,则无需担心这一点。

图例:

  • 04-> 81:读取寄存器0x04,读取值为0x81
  • 04< - 02:写入值0x02至

getrandom的注册0x04,我有以下序列。用一粒盐来拿这件盐,这只是我在阅读内核驾驶员时的猜测。问号可以检查是否设置了STS寄存器中的有效位(每当读取STS时也可以检查)。

操作我的猜测为什么是
04 - > 81访问:检查ActiveLocality,有效,请求集,如果使用了局部性,则可能已经
04< - 02访问:set requestuse
code> 04-> A1访问:Check requestUse设置
18-> 44
18-> 44状态:检查命令准备已设置
18-> 44D00700状态:读取爆发计数
24< - 80010000000c0000017b00命令blob blob除了最后一个字节
18-> 8c状态:检查期望设置
24< - 10命令blob last Byte
18-> 84状态:检查期望位清除
18< -20状态:设置go bit
18-> 94
18-> 94状态:等待dataavail
18-> 941C0000状态:读取爆发计数
24-> 80010000001C00000000响应blob标头
18-> 94状态:等待dataavail
18-> 94120000状态:读取爆发计数
24-> 0010755F8A5B158E44F5CD2EDF784156EED7响应blob handles(none)和参数
18-> 84状态:等待直到有效的位置
18-> 84状态:检查dataAvail清晰
18< - 40状态:设置命令准备重置状态机
04< - 20访问:

如果您'感兴趣,请参阅驱动程序的这部分

SPI Hardware Protocol specification:

The TPM SHALL decode transactions sent to offset 0xD4_xxxx when its CS# is asserted

Basically, you must not forget to offset your address by 0xD4:

0x83            // msb to 1 because I want to read, lower bits to 3 because my xfer consists of 4 bytes
0xD4 0x00 0x18  // three register address bytes, naming the register address

Example Sequence

Tpm2_GetRandom

Note: this assumes that the Linux Kernel initialized the TPM, including having sent the Tpm2_Startup command. If you use mainline linux, you do not need to worry about that.

Legend:

  • 04 -> 81: Read register 0x04, read value is 0x81
  • 04 <- 02: Write value 0x02 to register 0x04

For a GetRandom, I have the following sequence. Take that with a grain of salt, that is just my guess when reading the kernel driver. The question marks could be checking that the valid bit in the STS register is set (which is probably also checked whenever STS is read).

OperationMy guess of why that is
04 -> 81Access: check activeLocality, valid, requestUse set, probably if locality is used already
04 <- 02Access: set requestUse
04 -> A1Access: check requestUse is set
18 -> 44?
18 -> 44Status: check commandReady is set
18 -> 44D00700Status: read burst count
24 <- 80010000000C0000017B00Command Blob except last byte
18 -> 8CStatus: check expect is set
24 <- 10Command Blob last byte
18 -> 84Status: check expect bit is clear
18 <- 20Status: set go bit
18 -> 94?
18 -> 94Status: wait for dataAvail
18 -> 941C0000Status: read burst count
24 -> 80010000001C00000000Response Blob Header
18 -> 94Status: wait for dataAvail
18 -> 94120000Status: read burst count
24 -> 0010755F8A5B158E44F5CD2EDF784156EED7Response Blob Handles (here none) and Parameters
18 -> 84Status: wait until valid bit set
18 -> 84Status: check dataAvail is clear
18 <- 40Status: set commandReady to reset state machine
04 <- 20Access: relinquish control

If you're interested, see roughly this part of the driver.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文