[参考译文] AM625：SDK 10.00.07.04 Yocto 构建- TEE-supplicant 服务不运行

您好！

Yocto 主题所有者在9月剩余的时间内不在办公室。 如果您没有得到回复、请在10月初随意 ping 该主题。

此致、

Nick

我在 meta-arm 邮件列表中找到一个补丁、它更新了 opte-client 配方、安装了必要的 optee-udev.rules 文件以使 te-supplicant 服务启动。

此补丁是否会添加到 meta-arm scarthgap 并整合到 SDK 10版本中？

参考链接： https://lists.yoctoproject.org/g/meta-arm/message/6118

尊敬的 Bryan：

我在 meta-arm 邮件列表中找到一个补丁、该补丁更新了 optee-client 配方、以安装必需的 optee-udev.rules 文件、从而启动 tee-supplicant 服务。

感谢你进一步调查这在你的结束,而我是在办公室外。

您发现的补丁是否修复/解决了问题？

如果是、我将与开发团队讨论。 AFAIK OP-TEE 是我们官方/测试的功能之一、但我想、添加您自己的应用程序就是问题所在 。

此致、Andreas

是的、我使用该补丁作为编写自己的 optee-client_%.bbappend 文件的基础、它解决了我的问题。

考虑到在 SDK 10 (基于 scarthgap)中、te-supplicant 不会在没有创建服务实例的 udev 规则文件启动时、我很确定依赖它的 optee-examples 不会起作用。  我不知道这些是否是 TI 测试的一部分。

不过、我确实注意到了一些有趣的东西。  缺少的 udev rules 文件存在于 meta-arm scarthgap 中、如下所示：

meta-arm/recipers-security/trusted-services/libts/tee-udev.rules

然而,库的配方并不是为我构建的,它也不是我正在创建的图像的一部分。  我不确定 TI 的标准映像是否引用了任何依赖于库的"可信服务"软件包。   但并未显示出来。  但如果他们做到了、并且能够成功地建立、那么这可能会解释监督。  我只是不熟悉 libts 或其他"值得信赖的服务"配方。  这似乎是一件新奇的事。

我刚刚注意到这个补丁已经把它变成了 meta-arm 主器件(但还没有 scarthgap):

提交2d28195634671eccfafa49d656a5fdcbc27d9636
作者：Javier Tia
日期：9月26日、星期四、11：47：36 2024-0400

arm/optee：添加 optee udev 规则

如果检测到/dev/teepriv [0-9]*设备、请启动的实例
tee-supplicant.service、器件名称作为参数。

签字人：Javier Tia
签字人：Jon Mason

好的、感谢提供额外的背景。 我将在下周与开发团队讨论、并在这里圈出圈数。

此致、Andreas