我想知道MC34PF3000A7E的CCO值。 工厂标签只显示它是在菲律宾组装的，但我不知道芯片的原始产地。 请问如何通过标签信息找到它？多谢

MC34PF3000A7EのCCOを知りたいです 工場出荷時のラベルにはPHで組み立てられたと記載されていますが、チップの国名は知りません。 ラベル情報から調べる方法を教えてもらえますか?どうもありがとう

S32K142 PWM信号入力読み取り こんにちは、チームの皆さん、 S32K142でFTM入力キャプチャを使用してPWMを読み取るためのサンプルコードはありますか？ はいの場合、例を共有してください。 Re: S32K142 PWM Signal input reading こんにちは、 @Julián_AragónM さん、 迅速なご返信、本当にありがとうございます。 一つ小さな疑問ですが、単一のCHを使ってデューティサイクルと周期の両方を測定できますか? 入力キャプチャモードを「両エッジを検出」に設定した場合。IC_GetMeasurementからどのような測定値が得られますか？ Re: S32K142 PWM Signal input reading こんにちは、 @nirmal_masilamani さん、 参照できるのは: 例4。AN5303より:S32K上のFlexTimerモジュールの特徴と動作モード – アプリケーションノート。 AN5413の例2.5 時限I/O(FTM):S32K1xxシリーズクックブック – アプリケーションノート Ftm_Icu_Ip_BlinkLed_S32K144 RTDパッケージの例(Ftm_Icu_Ip_EnableEdgeDetection API使用) SDK からの ic_pal & ftm_signal_measurement examlpes また、いくつかのコミュニティ投稿も参照できます: s32k1:同じFTMチャネルでのPWM周波数とデューティサイクルの測定方法 S32K入力キャプチャ S32K1-FTMに基づいてモーターの速度を計算する これがお役に立てば幸いです。 よろしくお願いします、 ジュリアン   Re: S32K142 PWM Signal input reading こんにちは、 @nirmal_masilamani さん、 入力キャプチャは3つのモードをサポートしています: 立ち上がりエッジのみキャプチャ -> 期間のみ 立ち下がりエッジのみキャプチャ -> ピリオドのみ 立ち上がりエッジまたは立ち下がりエッジでのキャプチャ -> 高レベルパルス幅または低レベルパルス幅を知るには、GPIO または CnSC [CHIS] ビットを介してレベル状態を読み取る必要があります。 注意: チャネル(n)が入力モードでない場合はCHISビットは無視すべきです。 注意: ペアチャネルがデュアルエッジモードの場合、チャネル(n+1)のCHISビットはチャネル(n+1)の入力値であり、チャネル(n)入力値ではありません(この信号はデュアルエッジモードで使用される入力信号です)。 PWMデューティサイクルのキャプチャには、デュアルエッジキャプチャを使用する必要があります。そうしないと、高水準の期間か低水準の期間しか得られません。デュアルエッジキャプチャモードでは、チャネル(n)入力のみを使用し、チャネル(n+1)入力は無視されます。 Julin_AragnM_0-1788457862022.pngJulin_AragnM_0-1788457862022.png IC_GetMeasurementはティック単位のパルス幅を返し、それを使って信号周波数を計算できます: /* Get the latest value */ inputCaptureMeas = IC_GetMeasurement(&ic_pal_1_instanceConfig, channel); /* Calculate the signal frequency using recorded data*/ inputCaptureMeas = frequency / (inputCaptureMeas); よろしくお願いします、 ジュリアン Re: S32K142 PWM Signal input reading こんにちは、 @Julián_AragónM さん、 ご返信ありがとうございます。 まだ少し混乱しています。 PWM信号を測定するには、何本のピンが必要ですか？ 測定にはIC_PALを使用しています。しかし、信号ピンとシングルチャンネルを使用してPWMを測定することはできません。 RTDはV4.0.0を使用しました

支持 iOS 26 的 Wi-Fi 感知型 NAN（适用于 IW612 和 FRDM-IMX93 的示例代码）以及 88W9098 支持 你好， 我正在开发一款使用 Wi-Fi Aware (NAN) 技术的 iPhone 消费级配件。 作为其数据链路。苹果在 iOS 26 中添加了公共 Wi-Fi 感知框架， 我已经有一个可用的 iPhone 到 iPhone 基准测试应用程序（发布/订阅， 配对设备，TCP 数据路径）。我现在选择NXP一方。 我的计划是在FRDM-IMX93板上评估IW612作为NAN对等器件的性能， 然后转向基于 i.MX 8M Plus 的设计，并采用 NVMe 存储。 我有四个问题： 1.在主题 2170706 中（“iMX 板上 WiFi Aware (NAN) 的示例代码”） IW612 三频模块”），NXP 分享了 Wi-Fi Aware 示例代码 通过安全文件实现iOS互操作性。我可以获得访问权限吗？ 同一种材料？如果需要，我可以提交正式的支持案例。 渠道。 2. FRDM-IMX93 Debian/Yocto 电路板支持包 是否附带 IW612 固件？ 是否默认启用NAN？我应该使用哪个电路板支持包 版本？ 3. 对于相同设计的 2x2 变体，88W9098 固件是否支持 MXM驱动程序支持NAN/Wi-Fi吗？ 4. NXP 是否已针对 iOS 26（Wi-Fi 感知）验证了 NAN 配对和数据路径 4.0 / PASN 配对）？任何已知的局限性都将非常有帮助。 目标平台：运行 iOS 26.5 和 Xcode 26 的 iPhone 17 Pro Max 和 iPhone 12 Pro Max。 也欢迎提供 IW612 NAN 数据路径的吞吐量数据。 谢谢你， 优素福 （ https://community.nxp.com/t5/i-MX-Processors/Sample-code-for-WiFi-Aware-NAN-on-iMX-boards-with-the-IW612-tri/td-p/2170706 ） Re: Wi-Fi Aware NAN with iOS 26 on IW612 and FRDM-IMX93 sample code and 88W9098 support 你好， 希望你一切都好。有关我们 Wi-Fi 设备的功能列表，我建议查看NXP 无线 SoC 功能和 Linux 版本说明。 对于受“安全文件”保护的文档：安全访问权限 | NXP 半导体 请您按照以下步骤操作？ 另外，我建议您查看恩智浦半导体 (NXP Semiconductors) 的“安全访问权限常见问题解答”。 顺祝商祺！ 里卡多

SSEGold: Aniimo Release Date, Gameplay Guide, and How to Get More Currency Fast The creature-collecting RPG genre is getting a fresh new competitor with Aniimo, a free-to-play open-world adventure that combines monster collecting, exploration, battles, and multiplayer features. If you enjoy games where you discover new creatures, build a powerful team, and explore a huge fantasy world, Aniimo is definitely a title worth watching. Developed by Pawprint Studio, Aniimo takes players into the world of Idyll, where mysterious creatures called Aniimo live across different environments. Instead of simply collecting companions, players can also connect with Aniimo and experience the world from their perspective through the unique “Twine” system. When Will Aniimo Release? Aniimo is scheduled to officially launch worldwide on September 16, 2026 for PC and consoles, including PlayStation 5 and Xbox platforms. The mobile version will arrive shortly after on September 23, 2026. The game will follow a free-to-play model, allowing players to download and experience the core gameplay without purchasing the base game. Optional in-game purchases and special packs will be available. What Kind of Game Is Aniimo? Aniimo is an open-world creature-catching RPG. Players take the role of a Pathfinder and explore the continent of Idyll while searching for unique Aniimo companions. The main gameplay loop includes: Exploring different areas and discovering hidden creatures Capturing Aniimo using special tools Training and evolving collected companions Fighting enemies through real-time combat Completing challenges with other players Customizing your personal space and interacting with your Aniimo Unlike traditional creature-collection games, Aniimo focuses heavily on exploration. Different creatures can appear depending on the environment, weather conditions, and time of day, making exploration an important part of progression. Aniimo Twine System Explained One of the biggest features that makes Aniimo different is the Twine mechanic. Instead of only controlling your human character, players can connect with their Aniimo and experience the world through them. This allows you to use different creature abilities for exploration, such as: Flying across areas Diving underwater Digging underground paths Solving puzzles Fighting battles from a new perspective This system gives each Aniimo more value because they are not just combat companions — they also help you explore the world. How Does Combat Work in Aniimo? Combat in Aniimo focuses on real-time battles rather than traditional turn-based systems. Players can: Build a team of different Aniimo Take advantage of creature abilities Fight PvE enemies and bosses Participate in PvP challenges Join multiplayer activities The game also includes competitive modes where players can team up or compete against others. One example is the PvEVP mode Egg Heist, where teams search, fight, and compete for rewards. Aniimo Currency and Why Players Need More Resources Like many free-to-play RPGs, currency and resources will play an important role in Aniimo. Players will likely need in-game currency for: Upgrading Aniimo abilities Unlocking evolution materials Improving equipment Purchasing useful items Preparing stronger teams for battles At the beginning, earning resources through quests and exploration may be enough. However, as players progress into harder content, farming materials and currency can become time-consuming. Having enough currency can help players spend more time enjoying exploration and battles instead of repeating the same farming activities. How to Get Aniimo Currency Faster? There are several ways players can build their resources: 1. Complete Daily Activities Daily missions and limited-time events are usually some of the most reliable ways to collect rewards. 2. Explore and Collect Resources Since Aniimo is built around an open world, exploration will likely reward players with valuable materials and items. 3. Participate in Multiplayer Content Co-op activities and competitive challenges may provide additional rewards while also making progression more enjoyable. 4. Buy Aniimo Currency from Trusted Sellers For players who want to save grinding time, purchasing currency from a reliable third-party marketplace can be a convenient option. SSEGold provides Aniimo currency and game-related services, helping players get the resources they need faster and spend more time enjoying the actual gameplay. Whether you are preparing for stronger Aniimo teams, upgrading your companions, or catching up with friends, having extra currency can make progression smoother. Is Aniimo Worth Playing? Aniimo has a lot of features that appeal to fans of creature-collection games. Its open-world design, unique Twine system, evolving companions, and multiplayer activities give it more depth than a simple monster-catching game. For players who enjoy exploration, collecting rare creatures, and building powerful teams, Aniimo could become one of the interesting RPG releases of 2026. The best way to experience the game will be to explore Idyll, discover new Aniimo, and build your own adventure. And if progression becomes too slow, having additional currency through trusted services like SSEGold can help you focus on the fun parts of the game instead of endless farming.

如何在 Linux 系统上通过 OP-TEE 使用 SE051 执行密钥生成、加密/解密和签名/验证操作？ 大家好，NXP社区的各位！ 我目前正在根据这篇文章中描述的环境，将 Plug and Trust 中间件集成到 OP-TEE 中：如何将 Plug and Trust MW 集成到 OP-TEE 中。 我的目标是利用 SE051 安全元件，从运行在 Linux 上的用户空间应用程序实现以下操作： 生成 AES 密钥并将其存储在 SE051 中。 生成 RSA 密钥对并将其存储在 SE051 中。 使用存储在 SE051 中的 AES 密钥加密文件。 使用存储在 SE051 中的 AES 密钥解密文件。 使用 SE051 中的 RSA 私钥对数据进行签名。 使用 SE051 中的 RSA 公钥验证签名。 使用 SE051 中的 RSA 公钥对数据进行加密。 使用 SE051 中的 RSA 私钥解密数据。 请问各位能否指导我如何以最佳方式完成这些操作？我愿意使用以下任何命令行工具（或它们的组合），前提是这些工具在此 OP-TEE 设置中受支持： openssl 命令（通过 OpenSSL 提供程序） ssscli 工具 pkcs11-tool（通过 PKCS#11 接口） 非常感谢您能提供针对此特定 OP-TEE 环境的任何示例、文档链接或命令使用示例。 SE050 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? 嗨@Uc_S ， 从 Linux 用户空间到 SE051 有三条受支持的路径。这三款产品均可通过 Plug & Trust MW v04.07.01 获取： 通路 库 最适合 PKCS#11 libsss_pkcs11.so 通过 AES、RSA 生成/签名/验证/加密/解密 pkcs11-tool OpenSSL 提供程序 (3.x) libsss_provider.so RSA 签名/验证/加密/解密 openssl pkeyutl ssscli Python CLI 仅密钥注入/配置 OP-TEE 环境的重要提示：在您的 OP-TEE 设置 ( CFG_NXP_SE05X=y ) 中，SE051 由 OP-TEE 内核通过原生 I2C 驱动程序直接访问。Linux 用户空间应用程序不拥有 I2C 总线。以上三条路径均能正常工作，因为 Plug & Trust MW Access Manager ( accessManager ) 或 T1oI2C 套接字接口通过 OP-TEE 的可信世界将命令路由到 SE051。 操作 1：生成 AES 密钥并将其存储在 SE051 中 使用 ssscli 生成指定密钥 ID（SE051 中的对象 ID）的 AES-256 密钥： # Generate AES-256 key at Key ID 0x20000001 ssscli generate aes 0x20000001 256 验证密钥是否存在： ssscli get aes 0x20000001 aes_key_info.txt 注意： AES 密钥是对称的，不能从 SE051 导出。密钥 ID 0x20000001 是一个 32 位对象标识符，持久存储在 SE051 NVM 中。 操作 2：生成 RSA 密钥对并将其存储在 SE051 中 选项 A — 使用 pkcs11-tool （推荐） RSA密钥标签使用 sss: 格式： # Generate RSA-2048 key pair at Key ID 0x10101010 pkcs11-tool --module $PKCS11_MODULE --keypairgen --key-type rsa:2048 --label "sss:10101010" 选项 B — 使用 ssscli ssscli generate rsa 0x10101010 2048 AN13030 第 3.3.8.3 节注释：从外部注入时，RSA 密钥对必须使用 PKCS#8 或传统的 OpenSSL 格式进行 DER 编码。通过 sss_key_store_get_key() 获取时，仅返回公钥。 操作 3：使用 SE051 中的 AES 密钥加密文件 AES 对称加密可通过 SSS API ( sss_cipher_one_go ) 执行，或者，对于命令行使用，可通过小型包装应用程序执行。MW 提供了一个内置的对称示例，位于： simw-top/sss/ex/symmetric/ex_sss_symmetric.c 要直接在命令行中使用，请构建并运行示例： # After building the MW examples: ./se05x_symmetric_aes_cbc_encrypt --keyid 0x20000001 --input plaintext.bin --output ciphertext.bin --iv 00000000000000000000000000000000 MW 支持： kAlgorithm_SSS_AES_ECB 、 kAlgorithm_SSS_AES_CBC 、 kAlgorithm_SSS_AES_CTR 、 kAlgorithm_SSS_AES_GCM 、 kAlgorithm_SSS_AES_CCM （来自 AN13030 的第 3.3.9.1 节）。 操作 4：使用 SE051 中的 AES 密钥解密文件 ./se05x_symmetric_aes_cbc_decrypt --keyid 0x20000001 --input ciphertext.bin --output decrypted.bin --iv 00000000000000000000000000000000 SSS API 使用 kMode_SSS_Decrypt 模式和 sss_cipher_one_go() 进行一次性解密，或使用多步 sss_cipher_init() / sss_cipher_update() / sss_cipher_finish() 序列进行流式传输。 操作 5：使用 SE051 中的 RSA 私钥对数据进行签名 使用 pkcs11-tool （密钥保留在 SE051 中） # Sign with RSA private key (key never leaves SE051) pkcs11-tool --module $PKCS11_MODULE --sign --label sss:10101010 -m SHA256-RSA-PKCS --slot 1 -i in.der -o signature.der 支持通过 PKCS#11 实现的签名机制： SHA256-RSA-PKCS （RSASSA-PKCS1-v1_5，安全散列算法(SHA)-256） SHA1-RSA-PKCS ， SHA384-RSA-PKCS ， SHA512-RSA-PKCS RSA-PKCS-PSS （PSS 填充） 使用 OpenSSL 提供程序 (v3.x) # 配置 OpenSSL 使用 NXP 提供程序（参见 /etc/ssl/openssl.cnf） openssl pkeyutl -provider nxp -sign -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in in.txt -out signature.der   操作 6：使用 SE051 中的 RSA 公钥验证签名 步骤 1 — 从 SE051 导出公钥 # Method A: via ssscli ssscli get rsa pub 0x10101010 rsa_pub.der # Method B: via pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --read-object --type pubkey --slot 1 --label sss:10101010 -o pubkey.der # Convert DER to PEM for OpenSSL openssl rsa -in pubkey.der -inform der -out pubkey.pem -outform pem -pubin 步骤 2 — 验证（主机端，无需 SE051） openssl dgst -keyform PEM -verify pubkey.pem -sha256 -signature signature.der in.txt # Expected output: Verified OK 操作 7：使用 SE051 中的 RSA 公钥加密数据 RSA 加密使用公钥（加密时不需要安全元件）： # Encrypt with public key (host side) openssl rsautl -encrypt -inkey pubkey.pem -in in.txt -pubin -out crypt.txt 对于 OAEP 衬垫（推荐），请使用： openssl pkeyutl -encrypt -inkey pubkey.pem -pubin > -pkeyopt rsa_padding_mode:oaep > -pkeyopt rsa_oaep_md:sha256 > -in in.txt -out crypt.txt AN13030 第 3.3.5.6 节列出了支持的算法，包括 kAlgorithm_SSS_RSAES_PKCS1_OAEP_SHA256 和 kAlgorithm_SSS_RSAES_PKCS1_V1_5 。 操作 8：使用 SE051 中的 RSA 私钥解密数据 RSA 私钥解密完全在 SE051 内部执行。私钥永远不会离开安全元件。 使用 pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --decrypt --label sss:10101010 --slot 1 -i crypt.txt -o decrypt.txt cat decrypt.txt 使用 OpenSSL 提供程序 (v3.x) openssl pkeyutl -provider nxp -decrypt -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in crypt.txt -out decrypt.txt AN13030 第 2.3.4 节确认：“在提供程序中添加了 RSA 加密和解密功能”（从 v04.05.03 开始，包含在 v04.07.01 中）。 关键 ID 标签约定 当使用 NXP PKCS#11 库中的 pkcs11-tool 时，密钥 ID 标签格式为： sss: 例如，键 ID 0x10101010 → 标签 sss:10101010 v04.07.00 版本中的重大变更（PKCS#11 v4.7）：为了避免字节交换， CKA_ID 属性（ --id ）现在被视为字节数组。传递ID时不要改变字节序。 PKCS#11 令牌初始化（首次设置） 在使用 pkcs11-tool 之前，您可能需要初始化令牌槽： # Initialize slot 0 pkcs11-tool --module $PKCS11_MODULE --init-token --slot 0 --label "SE051_Token" --so-pin 12345678 # Set user PIN pkcs11-tool --module $PKCS11_MODULE --init-pin --slot 0 --login --so-pin 12345678 --pin 87654321 OpenSSL 3.x 提供程序配置 添加到 /etc/ssl/openssl.cnf （或自定义配置文件）： [openssl_init] providers = provider_sect [provider_sect] default = default_sect nxp = nxp_sect [default_sect] activate = 1 [nxp_sect] module = /usr/local/lib/libsss_provider.so activate = 1 OpenSSL 提供程序源代码也可在以下网址获取： https://github.com/NXPPlugNTrust/se05x-openssl-provider 源代码示例（在 simw-top 中） MW 包中的以下内置示例直接演示了这些操作： Operation 示例路径 AES 加密/解密 simw-top/sss/ex/symmetric/ex_sss_symmetric.c RSA签名/验证 simw-top/sss/ex/rsa/ （AN13030 第 5.2.1.2 节） ECC签名/验证 simw-top/sss/ex/ecc/ （AN13030 第 5.2.1.1 节） PKCS#11 脚本 simw-top/sss/plugin/pkcs11/scripts/ OpenSSL 提供程序 RSA 加密 simw-top/sss/plugin/openssl_provider/scripts/openssl_RsaEnc.py OP-TEE 背景下的已知局限性 从 OP-TEE 内核端到 SE051 的 AES 卸载取决于 CFG_NXP_SE05X_CTR_DRV 是否启用。用户空间 AES 通过 PKCS#11 进行加密，这需要经过访问管理器，并且与 OP-TEE 加密驱动程序卸载是分开的。 在 v04.07.01 中，SE051 中的 RSA 密钥生成默认采用 CRT 格式（在 PKCS11 v4.8 中添加了 RSA_CRT 支持）。使用 PKCS11_ENABLE_RSA_KEY_GEN_CRT cmake 选项在 CRT 和普通 RSA 之间切换。 SE051 NVM 有局限性。多次 RSA 密钥对生成可能会耗尽持久存储空间——使用 ssscli delete 删除未使用的对象。 对于并发多进程访问（例如，多个用户空间应用程序），请使用 simw-top/hostlib/hostlib/accessManager 处的访问管理器。使用 -DSMCOM:STRING=JRCP_V1_AM 构建。 参考文档 文档 说明 AN13030 Plug & Trust MW 文档（主要参考资料） AN12660 符合 IEC 62443 标准（SE05x）——包含 SSS API 示例指针 simw-top/doc/ （本地 HTML） 您已安装的版本 v04.08.01 的完整文档 simw-top/doc/plugins/pkcs11.html PKCS#11 独立库文档 simw-top/doc/demos.html 可用演示示例完整列表 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? 嗨@Uc_S ， 当设置 CFG_NXP_SE05X=y 时， OP-TEE 将独占 SE051 的 I2C 总线。Linux DTS 必须禁用该 I2C 控制器（如集成指南中所述）。这从根本上改变了 Plug & Trust MW 的使用方式： 层 谁来运营它 它如何到达SE051 OP-TEE 安全世界 OP-TEE核心 原生 I2C 驱动程序 ( CFG_IMX_I2C=y ) —直接、独占 Linux 用户空间 您的应用程序 ssscli，访问管理器 无法使用 T1oI2C — Linux DTS 中已禁用 I2C 这意味着您现有的带有 -DPTMW_SMCOM=T1oI2C 的 cmake 配置仅适用于 Linux 直接拥有 I2C 的情况。在 OP-TEE 设置中，它适用于下面描述的两种不同的版本场景。 场景 1：MW 版本输入到 OP-TEE ( CFG_NXP_SE05X_PLUG_AND_TRUST= ) 这是最重要的案件。MW在 OP-TEE 中被编译为静态库——您无需为此手动运行 cmake 。当您将 CFG_NXP_SE05X_PLUG_AND_TRUST 指向已解压的 MW 目录时，OP-TEE 的 Makefile 会自动处理集成： CFG_NXP_SE05X_PLUG_AND_TRUST=$HOME/linux-factory/plug-and-trust 您列出的 SMCOM、Host 和 Auth 标志在这里不适用。OP-TEE 通过其自身的原生 I2C 抽象层 ( CFG_IMX_I2C=y ) 驱动 SE051，完全绕过 Linux MW 通信协议栈。 场景 2：Linux 用户空间工具（ssscli / 访问管理器 / 演示） 这里就需要用到你的 cmake 标志了。当 OP-TEE 拥有 I2C 接口时，以下是对必须更改的各项标志位的逐一分析： 必须更改的标志 标志位 您当前的价值 OP-TEE 设置的推荐值 原因 -DPTMW_SMCOM T1oI2C JRCP_V1_AM （如果使用访问管理器） Linux 无法直接使用 I2C；访问管理器提供套接字代理。 -DPTMW_SE05X_Auth PlatfSCP03 None SCP03 通道由 OP-TEE 建立，而非 Linux 用户空间。 -DPTMW_SCP SCP03_SSS None 原因相同——SCP-03归OP-TEE安全世界所有。 保持不变的旗帜 标志位 Value 原因 -DPTMW_Applet SE05X_C 请更正您的 SE051C2 型号（OEF ID A8FA） -DPTMW_SE05X_Ver 07_02 与 OP-TEE 启动日志中显示的 applet 版本 7.2 相符 -DPTMW_Host iMXLinux 仍然运行在 i.MX Linux 上 -DPTMW_HostCrypto OPENSSL 未更改 -DPTMW_RTOS Default 未更改 -DPTMW_OpenSSL 3_0 OpenSSL 3.x 版本保持不变 -DPTMW_FIPS None 未更改 -DPTMW_SBL None 未更改 -DPTMW_mbedTLS_ALT None 未更改 -DPTMW_Log Silent 未更改 -DPTMW_SE_RESET_LOGIC 1 未更改；v04.07.00 版本新增选项 OP-TEE 安装中推荐的 Linux 用户空间工具的 cmake 命令 cd simw-top && mkdir build_optee_linux cmake -S . -B ./build_optee_linux/ -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=None -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=None -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 cd build_optee_linux && make -j8 注意： JRCP_V1_AM 要求访问管理器在目标上作为守护进程运行。Access Manager 本身连接到 SE051 — 但请注意以下重要注意事项。 重要提示：访问管理器 I2C 冲突 访问管理器（ hostlib/hostLib/accessManager ）旨在串行化来自多个 Linux 进程的并发 I2C 访问。然而： 当 OP-TEE 完全禁用 Linux DTS 中的 I2C 接口（如 CFG_NXP_SE05X=y 所要求的）时，访问管理器本身也无法打开 I2C。 这意味着您有两种有效的部署选择： 选项 A：OP-TEE 独家产品（推荐用于生产） OP-TEE 完全拥有 I2C。Linux 用户空间仅使用 OP-TEE PKCS#11 TA ( libckteec.so ) 进行加密操作。在这种模式下，Plug & Trust MW ssscli 和演示程序无法在 Linux 上运行。 Linux App → libckteec.so → OP-TEE PKCS#11 TA → SE051 这是 i.MX Linux 用户指南 (UG10163) 中描述的基于 OP-TEE 的 SE05x 使用的路径。 选项 B：共存（测试/配置） 使用不会禁用 Linux 中 I2C 的 Linux DTS（即，不要应用 lf-6.12.y-i2c-disabled-se050 DTS 补丁）。在此配置中： OP-TEE 使用 SE051 进行加密卸载（RSA/ECC） Linux 用户空间仍然可以使用 T1oI2C （您原来的标志）运行 ssscli / Access Manager 风险：OP-TEE 和 Linux 同时进行 I2C 访问需要谨慎仲裁。 对于此选择，请将 SMCOM、SCP 和 Auth 标志恢复为原始值，并保留原始 I2C DTS（不要禁用它）。 汇总表 用例 SMCOM SCP 身份验证 说明 OP-TEE 内部 MW（用于 OP-TEE 版本的静态库） N/A N/A N/A 无需 cmake；由……处理 CFG_NXP_SE05X_PLUG_AND_TRUST= Linux 用户空间，OP-TEE 专用 I2C JRCP_V1_AM None None 需要 Access Manager，但如果 I2C 被禁用，AM 本身无法访问 SE051。 Linux 用户空间，共存（I2C 共享） T1oI2C SCP03_SSS PlatfSCP03 您原始的标志——如果 Linux DTS 仍然启用了 I2C，则这些标志有效。 Linux 用户空间通过 PKCS#11 TA（OP-TEE 独占） 不适用（无MW版本） N/A N/A 使用 pkcs11-tool / openssl libckteec.so 补充参考 AN13030 修订版 2.4 — 第 4.4 节（i.MX Linux 版本）、第 8.9 节（PKCS#11 独立库）、访问管理器文档 UG10163 i.MX Linux 用户指南— 使用 libckteec.so 的 OP-TEE PKCS#11 命令示例（第 10.4.7 节和 10.4.8 节，第 110-114 页）；注意：这些示例使用 OP-TEE 内部安全存储作为密钥后端，而不是直接使用 SE05x — 当通过 CFG_NXP_SE05X=y 将 SE051 配置为 OP-TEE 加密后端时，命令语法相同。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? @Kan_Li 非常感谢您详尽周到的回复。 对三种支持路径的详细说明和命令示例非常有帮助。 关于 OP-TEE 环境，我有一个关于 Linux 根文件系统上 Plug & Trust 中间件的 CMake 构建配置的后续问题。 之前，当直接在 Linux 上运行中间件（不使用 OP-TEE 路由）时，我们使用了以下 CMake 配置标志： -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=T1oI2C -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=SCP03_SSS -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 请问上述哪些设置需要更改，以及对于此 OP-TEE 设置，它们的推荐新值应该是多少？ 细节： 既然 OP-TEE 已经拥有了对 SE051 的直接 I2C 访问（通过 CFG_NXP_SE05X=y），请问在构建 Linux 用户空间中间件/工具（例如 ssscli 或 Access Manager）时，是否需要修改这些 CMake 标志？ 具体来说，是否应该更新 Linux 用户空间端的 -DPTMW_SMCOM 选项（例如，从 T1oI2C 更改为 JRCP_V1_AM 或套接字接口）或 -DPTMW_Host 选项，以便通过 OP-TEE 正确路由请求？ 以下是我的环境详情： 电路板：MCIMX8M-WEVK 和 OM-SE051ARD Plug and Trust MW 版本：v04.07.01 OP-TEE 操作系统版本：3.19.0 Linux 内核：6.1.151 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? 非常感谢您如此详尽清晰的解释。 逐个标志位的分析、构建命令示例，以及关于 I2C 冲突的关键注意事项，以及在选项 A（通过 libckteec.so 使用 OP-TEE 独占）和选项 A 之间进行选择的问题。选择 B（共存）明确了我们的设置选项。 这些信息正是我们确定未来架构所需要的。

Wi-Fi Aware NAN with iOS 26 on IW612 and FRDM-IMX93 sample code and 88W9098 support Hello, I am developing a consumer accessory for iPhone that uses Wi-Fi Aware (NAN) as its data link. Apple added a public Wi-Fi Aware framework in iOS 26, and I already have a working iPhone-to-iPhone benchmark app (Publish/Subscribe, paired devices, TCP data path). I am now selecting the NXP side. My plan is to evaluate the IW612 on the FRDM-IMX93 board as the NAN peer, then move to an i.MX 8M Plus based design with NVMe storage. I have four questions: 1. In thread 2170706 ("Sample code for WiFi Aware (NAN) on iMX boards with the IW612 tri-radio module"), NXP shared Wi-Fi Aware sample code for iOS interoperability through secure files. Could I get access to the same material? I can open a formal support case if that is the proper channel. 2. Does the FRDM-IMX93 Debian/Yocto BSP ship with an IW612 firmware that has NAN enabled out of the box, and which BSP release should I use? 3. For a 2x2 variant of the same design, does the 88W9098 firmware support NAN / Wi-Fi Aware under the MXM driver? 4. Has NXP validated NAN pairing and data path against iOS 26 (Wi-Fi Aware 4.0 / PASN pairing)? Any known limitations would be very helpful. Target: iPhone 17 Pro Max and iPhone 12 Pro Max on iOS 26.5, Xcode 26. Any throughput figures for the IW612 NAN data path would also be welcome. Thank you, Youssef (https://community.nxp.com/t5/i-MX-Processors/Sample-code-for-WiFi-Aware-NAN-on-iMX-boards-with-the-IW612-tri/td-p/2170706) Re: Wi-Fi Aware NAN with iOS 26 on IW612 and FRDM-IMX93 sample code and 88W9098 support Hello, Hope you are doing well. For feature list of our Wi-Fi devices, I would recommend checking the NXP Wireless SoC Features and Release Notes for Linux. For documents that are under Secure Files: Secure Access Rights | NXP Semiconductors Could you please follow the process?  Also, I would recommend checking the Secure Access Rights FAQs | NXP Semiconductors Best Regards, Ricardo

SSEGold：Animo发布日期、游戏玩法指南以及如何快速获得更多货币 Aniimo 的出现为生物收集角色扮演游戏类型带来了一位全新的竞争者。这是一款免费的开放世界冒险游戏，融合了怪物收集、探索、战斗和多人游戏功能。如果你喜欢在游戏中发现新生物、组建强大的队伍并探索广阔的奇幻世界，那么 Aniimo 绝对是一款值得一看的游戏。 由 Pawprint Studio 开发的 Aniimo 将玩家带入 Idyll 的世界，在那里，被称为 Aniimo 的神秘生物生活在不同的环境中。除了收集伙伴之外，玩家还可以通过独特的“Twine”系统与 Aniimo 建立联系，并从 Aniimo 的视角体验这个世界。 Aniimo何时发布？ Aniimo 计划于 2026 年 9 月 16 日在全球范围内正式上线，支持 PC 和游戏主机平台，包括 PlayStation 5 和 Xbox 平台。移动版将于 2026 年 9 月 23 日紧随其后推出。 该游戏将采用免费游玩模式，玩家无需购买基础游戏即可下载并体验核心玩法。游戏内将提供可选的付费项目和特殊礼包。 Aniimo 是什么类型的游戏？ Aniimo 是一款开放世界生物捕捉角色扮演游戏。玩家扮演探路者的角色，探索伊迪尔大陆，寻找独特的阿尼莫伙伴。 主要游戏循环包括： 探索不同区域，发现隐藏的生物 使用特殊工具捕捉 Aniimo 训练和进化收集到的伙伴 通过实时战斗与敌人作战 与其他玩家一起完成挑战 定制您的个人空间并与您的 Aniimo 互动 与传统的生物收集游戏不同，《Animimo》非常注重探索。根据环境、天气状况和时间的不同，可能会出现不同的生物，因此探索是游戏进程中重要的一部分。 Aniimo Twine系统详解 Aniimo 的最大特色之一就是 Twine 机制。 玩家不仅可以控制人类角色，还可以与他们的 Aniimo 建立联系，并通过 Aniimo 体验世界。这样你就可以利用不同的生物能力进行探索，例如： 飞越区域 潜水 挖掘地下通道 解谜 以全新的视角进行战斗 这个系统赋予了每个阿尼莫更大的价值，因为它们不仅是战斗伙伴，还能帮助你探索世界。 Aniimo中的战斗机制是怎样的？ Aniimo 的战斗侧重于实时战斗，而不是传统的回合制系统。 玩家可以： 组建一支由不同 Aniimo 组成的团队 充分利用生物的能力 与PvE敌人和首领战斗 参与 PvP 挑战 加入多人游戏活动 游戏还包含竞技模式，玩家可以组队或与其他玩家对抗。例如，PvEVP 模式“蛋壳劫案”中，团队需要搜索、战斗并争夺奖励。 Aniimo货币以及玩家为何需要更多资源 与许多免费角色扮演游戏一样，货币和资源在 Aniimo 中将发挥重要作用。 玩家可能需要游戏内货币来购买： 升级 Aniimo 能力 解锁进化材料 改进设备 购买实用物品 为战斗打造更强大的队伍 游戏初期，通过任务和探索获取资源可能就足够了。然而，随着玩家进入更高难度的游戏内容，收集材料和货币可能会变得非常耗时。 拥有足够的货币可以帮助玩家将更多的时间用于探索和战斗，而不是重复相同的刷怪活动。 如何更快地获得Animo货币？ 玩家可以通过多种方式积累资源： 1. 完成每日活动 每日任务和限时活动通常是获得奖励最可靠的途径之一。 2. 探索和收集资源 由于 Aniimo 采用开放世界设计，探索可能会让玩家获得宝贵的材料和物品。 3. 参与多人游戏内容 合作活动和竞争挑战可能会带来额外的奖励，同时也会让游戏进程更加有趣。 4. 从信誉良好的卖家处购买 Aniimo 货币 对于想要节省刷怪时间的玩家来说，从可靠的第三方市场购买游戏货币可能是一个方便的选择。 SSEGold提供 Aniimo 货币和游戏相关服务，帮助玩家更快地获得所需的资源，并花更多时间享受实际的游戏体验。无论你是准备组建更强大的 Aniimo 队伍、升级你的伙伴，还是追赶朋友的进度，拥有额外的货币都能让你的进度更加顺利。 Aniimo值得玩吗？ Aniimo 拥有许多吸引生物收集游戏爱好者的功能。它的开放世界设计、独特的 Twine 系统、不断进化的伙伴以及多人游戏活动，使其比简单的怪物捕捉游戏更具深度。 对于喜欢探索、收集稀有生物和组建强大队伍的玩家来说，《Animimo》可能会成为 2026 年最有趣的 RPG 版本之一。 体验这款游戏的最佳方式是探索伊甸园，发现新的阿尼莫，并打造你自己的冒险之旅。如果游戏进度变得太慢，通过 SSEGold 等值得信赖的服务获得额外的货币可以帮助你专注于游戏中有趣的部分，而不是无休止地刷资源。

SSEGold：Aniimoのリリース日、ゲームプレイガイド、そしてゲーム内通貨を素早く入手する方法 モンスター収集RPGジャンルに、新たなライバルが登場する。『Aniimo』は、モンスター収集、探索、戦闘、マルチプレイヤー機能を組み合わせた、基本プレイ無料のオープンワールドアドベンチャーゲームだ。新しい生き物を発見したり、強力なチームを編成したり、広大なファンタジー世界を探索したりするゲームが好きなら、Aniimoは間違いなく注目に値するタイトルです。 Pawprint Studioが開発した『Aniimo』は、プレイヤーをイディルの世界へと誘います。そこでは、アニモと呼ばれる不思議な生き物たちが様々な環境に生息しています。単に仲間を集めるだけでなく、プレイヤーは独自の「Twine」システムを通じてアニモとつながり、彼らの視点から世界を体験できます。 Aniimoはいつリリースされますか？ Aniimoは2026年9月16日にPCおよびコンソール向けに正式に世界中で発売予定で、PlayStation 5やXboxプラットフォームも含まれます。モバイル版は2026年9月23日に間もなく発売されます。 このゲームは基本ゲームを購入せずに基本ゲームプレイをダウンロードして体験できる基本プレイモデルを採用します。任意でゲーム内購入できるアイテムやスペシャルパックが用意されています。 Aniimoはどんなゲームですか？ Aniimoは、オープンワールド型のモンスター捕獲RPGです。プレイヤーはパスファインダーとなり、イディル大陸を探索しながら、個性豊かなアニモの仲間を探し出す。 主なゲームプレイの流れは以下のとおりです。 さまざまなエリアを探索し、隠された生き物を発見すること 特殊な道具でアニイモを捕らえる トレーニングと進化する収集コンパニオン リアルタイム戦闘で敵と戦う 他のプレイヤーと一緒にチャレンジをクリアする パーソナルスペースのカスタマイズとアニイモとの交流 従来のクリーチャー収集ゲームとは異なり、『アニモ』は探索に重点を置いている。環境や天候、時間帯によって異なる生き物が現れるため、探索は進行の重要な要素となっています。 Aniimo Twineシステムについて解説します Aniimoを他と大きく差別化する特徴の一つは、Twineというゲームシステムです。 人間キャラクターだけでなく、プレイヤーはアニモとつながり、彼らを通じて世界を体験できます。これにより、探索に次のようなさまざまなクリーチャーの能力を使用できます。 地域を横断して飛行する 水中ダイビング 地下通路を掘る パズルを解く 新たな視点から戦いに挑む このシステムにより、各アニモの価値が高まります。なぜなら、アニモは単なる戦闘の仲間ではなく、世界を探索する際にも役立つからです。 Aniimoの戦闘システムはどのようになっていますか？ 『アニモ』の戦闘システムは、従来のターン制システムではなく、リアルタイムバトルに重点を置いている。 プレイヤーは以下のことができます: さまざまなアニモのチームを編成する クリーチャーの能力を活用する PvEの敵やボスと戦う PvPチャレンジに参加する マルチプレイヤーアクティビティに参加する また、プレイヤーがチームを組んだり他者と競い合ったりできる競技モードも含まれています。その一例がPvEVPモードのエッグハイストで、チームは報酬を巡って探索し、戦い、競い合います。 アニモ通貨とプレイヤーがより多くのリソースを必要とする理由 多くの基本プレイ無料RPGと同様に、『アニモ』でも通貨と資源は重要な役割を果たす。 プレイヤーは、以下の目的でゲーム内通貨が必要になる可能性が高いです。 アニモの能力をアップグレードする 進化素材の解放 設備の改善 便利なアイテムを購入する 戦闘に向けてより強力なチームを準備する 最初は、クエストや探索を通して資源を獲得するだけで十分かもしれません。しかし、プレイヤーがより難しいコンテンツに進むにつれて、素材や通貨の周集に時間がかかることもあります。 十分な通貨を持つことで、同じ農作業を繰り返す代わりに探索や戦闘を楽しむ時間を増やせます。 Aniimoの通貨をより早く入手する方法は？ プレイヤーが資源を建設する方法はいくつかあります: 1. 日々の活動を完了する デイリーミッションや期間限定イベント情報は、報酬を集める最も確実な方法の一つです。 2. 資源を探索し収集する Aniimoはオープンワールドを基盤としているため、探索を行うことでプレイヤーは貴重な素材やアイテムを入手できる可能性が高い。 3. マルチプレイヤーコンテンツに参加する 協力プレイや競技チャレンジは追加の報酬を提供し、進行をより楽しくすることもあります。 4. 信頼できる販売者からアニモ通貨を購入する 周回作業を節約したいプレイヤーにとっては、信頼できるサードパーティのマーケットプレイスで通貨を購入するのが便利な選択肢となり得ます。 SSEGoldは、Aniimoのゲーム内通貨やゲーム関連サービスを提供し、プレイヤーが必要なリソースをより早く入手し、実際のゲームプレイを楽しむ時間を増やせるよう支援します。より強力なアニイモチームの準備をしている時や仲間をアップグレードする時、友達と近況を語る時など、追加の通貨を持つことで進行がスムーズになります。 Aniimoはプレイする価値があるか？ Aniimoには、クリーチャー収集ゲームのファンにとって魅力的な機能が数多く備わっている。オープンワールドのデザイン、独特のTwineシステム、進化する仲間、マルチプレイヤーアクティビティが、単なるモンスター捕獲ゲーム以上の深みを与えています。 探索や希少な生物の収集、強力なチームのビルディングを楽しむプレイヤーにとって、『アニモ』は2026年の興味深いRPGの一つになる可能性があります。 このゲームを最大限に楽しむには、イディルを探索し、新しいアニモを発見し、自分だけの冒険を作り上げるのが一番です。進行が遅すぎる場合は、SSEGoldのような信頼できるサービスで追加の通貨を手に入れることで、終わりのない周回作業よりも楽しい部分に集中できます。

iOS 26のWi-Fi Aware NAN(IW612、FRDM-IMX93サンプルコード、88W9098サポート) こんにちは、 私はWi-Fi Aware(NAN)を使ったiPhone向けの消費者向けアクセサリーを開発しています データリンクとして。AppleはiOS 26で公開Wi-Fi Awareフレームワークを追加し、 すでにiPhone間で動作するベンチマークアプリ(Publish/Subscribe、 ペアリングされたデバイス、TCPデータパスなどです。NXP側を選択します。 私の計画は、FRDM-IMX93ボード上のIW612をNANピアとして評価することです。 その後、NVMeストレージを備えた i.MX 8M Plusベースの設計に移行します。 私には4つの質問があります。 1.スレッド2170706(「iMXボード上のWiFi Aware(NAN)のサンプルコードと IW612 トライラジオ モジュール」)、NXPはWi-Fi Awareのサンプルコードを共有していました。 iOSのセキュアファイルによる相互運用性。アクセスできますか? 同じ素材?もしそれが適切であれば、正式なサポートケースを開くこともできます チャネル。 2. FRDM-IMX93 Debian/Yocto BSPはIW612ファームウェアを搭載していますか? NANは最初から有効になっていますか?どのBSPリリースを使うべきでしょうか? 3. 同じ設計の2x2バリアントの場合、88W9098ファームウェアはサポートしていますか? MXMドライバーでNAN / Wi-Fi Awareはどうですか? 4. NXPはiOS 26（Wi-Fi対応）に対してNANペアリングとデータパスの検証を行いましたか？ 4.0 / PASNペアリング）？既知の制限事項があれば、ぜひ教えていただけると大変助かります。 対象: iOS 26.5、Xcode 26 を搭載した iPhone 17 Pro Max および iPhone 12 Pro Max。 IW612 NANデータパスのスループットに関するデータも歓迎します。 ありがとう、 ユセフ ( https://community.nxp.com/t5/i-MX-Processors/Sample-code-for-WiFi-Aware-NAN-on-iMX-boards-with-the-IW612-tri/td-p/2170706 ) Re: Wi-Fi Aware NAN with iOS 26 on IW612 and FRDM-IMX93 sample code and 88W9098 support こんにちは、 あなたの調子が良いといいのですが。Wi-Fiデバイスの機能リストについては、 NXPワイヤレスSoCのLinux版機能とリリースノートをご確認ください。 Secure Filesの対象となる文書: Secure Access Rights |NXPセミコンダクターズ その手順に従っていただけますか? また、 Secure Access Rights FAQs | NXP Semiconductorsをご確認することをお勧めします。 よろしくお願いいたします。 リカルド

Linux上でOP-TEE経由でSE051でキー生成、エンコン/デック、署名/検証を行う方法は? こんにちは、NXPコミュニティの皆さん、 現在、この投稿「Plug and Trust MWをOP-TEEに統合する方法」で説明されている環境に基づいて、Plug and Trust MiddlewareをOP-TEEに統合する作業を行っています。 私の目標は、SE051のセキュア要素を活用し、Linux上で動作するユーザー空間アプリケーションから以下の操作を実現することです。 AESキーを生成し、SE051に保存します。 RSA鍵ペアを生成し、SE051に保存します。 SE051に保存されたAESキーを使ってファイルを暗号化します。 SE051に保存されているAESキーを使ってファイルを復号します。 SE051でRSA秘密鍵を使用してデータに署名します。 SE051にあるRSA公開鍵を使用して署名を検証します。 SE051でRSA公開鍵を使用してデータを暗号化します。 SE051でRSA秘密鍵を使用してデータを復号します。 これらの手術を達成するための最適な方法について、どなたかアドバイスをいただけませんか?このOP-TEE環境でサポートされている限り、以下のコマンドラインツール（またはそれらの組み合わせ）のいずれかを使用することに抵抗はありません。 openSSLコマンド(OpenSSLプロバイダー経由) ssscliツール pkcs11-tool(PKCS#11インターフェース経由) この特定のOP-TEE環境に関する例、ドキュメントリンク、コマンドの使用例があれば大変ありがたいです。 SE050 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? こんにちは、 @Uc_S さん。 Linuxユーザー空間からSE051への サポートされた経路は3 つあります。これら3つはすべてPlug & Trust MW v04.07.01で利用可能です。 パス 図書館 最適な用途 PKCS#11 libsss_pkcs11.so AES、RSAキーの生成/署名/検証/エンク/デック pkcs11-tool OpenSSL プロバイダー(3.x) libsss_provider.so RSA署名/検証/エンコード/デコード openssl pkeyutl ssscli Python CLI キーの注入/プロビジョニングのみ OP-TEE環境に関する重要な注意点: OP-TEEセットアップ( CFG_NXP_SE05X=y )では、SE051はOP-TEEコアがネイティブI2Cドライバを通じて直接アクセスします。Linuxユーザー空間アプリケーションはI2Cバスを所有 していません 。上記の3つのパスはすべて正しく動作します。なぜなら、Plug & Trust MWアクセスマネージャー( accessManager )またはT1oI2CソケットインターフェースがOP-TEEの信頼されたワールドを通じてコマンドをSE051にルーティングするためです。 操作1:AESキーを生成し、SE051に保存する ssscli を使って特定のキーID(SE051のオブジェクトID)でAES-256キーを生成します: # Generate AES-256 key at Key ID 0x20000001 ssscli generate aes 0x20000001 256 キーが存在することを確認するには： ssscli get aes 0x20000001 aes_key_info.txt 注意: AESキーは対称的であり、SE051からエクスポートすることはできません。キーID 0x20000001 は、SE051 NVMに永続的に保存される32ビットのオブジェクト識別子です。 操作2：RSA鍵ペアを生成し、SE051に保存する オプションA — pkcs11-tool を使用する（推奨） RSAキーラベルは以下の形式を使用します sss: : # Generate RSA-2048 key pair at Key ID 0x10101010 pkcs11-tool --module $PKCS11_MODULE --keypairgen --key-type rsa:2048 --label "sss:10101010" オプションB — 使用 ssscli ssscli generate rsa 0x10101010 2048 AN13030 セクション 3.3.8.3 注記: RSA キー ペアを外部から注入する場合は、PKCS#8 または従来の OpenSSL フォーマットを使用して DER エンコードする必要があります。 sss_key_store_get_key() を介して取得した場合、公開鍵のみが返されます。 操作3:SE051のAESキーを使ってファイルを暗号化する AES対称暗号化はSSS API( sss_cipher_one_go )またはコマンドライン使用の場合は小型ラッパーアプリケーションを介して行われます。MWには、以下の場所に組み込みの対称例が用意されています。 simw-top/sss/ex/symmetric/ex_sss_symmetric.c コマンドラインから直接使用するには、以下のサンプルをビルドして実行してください。 # After building the MW examples: ./se05x_symmetric_aes_cbc_encrypt --keyid 0x20000001 --input plaintext.bin --output ciphertext.bin --iv 00000000000000000000000000000000 MWは以下をサポートしています: kAlgorithm_SSS_AES_ECB 、 kAlgorithm_SSS_AES_CBC 、 kAlgorithm_SSS_AES_CTR 、 kAlgorithm_SSS_AES_GCM 、 kAlgorithm_SSS_AES_CCM (AN13030の第3.3.9.1節より)。 操作4:SE051のAESキーを使ってファイルを復号する ./se05x_symmetric_aes_cbc_decrypt --keyid 0x20000001 --input ciphertext.bin --output decrypted.bin --iv 00000000000000000000000000000000 SSS APIは、ワンショット復号には sss_cipher_one_go() を使用した kMode_SSS_Decrypt モード、ストリーミングには複数ステップの sss_cipher_init() / sss_cipher_update() / sss_cipher_finish() シーケンスを使用します。 操作5：SE051のRSA秘密鍵を使用してデータに署名する pkcs11-tool を使用します（キーはSE051に保持されます） # Sign with RSA private key (key never leaves SE051) pkcs11-tool --module $PKCS11_MODULE --sign --label sss:10101010 -m SHA256-RSA-PKCS --slot 1 -i in.der -o signature.der PKCS#11でサポートされている手話メカニズム： SHA256-RSA-PKCS (RSASSA-PKCS1-v1_5、SHA-256) SHA1-RSA-PKCS 、 SHA384-RSA-PKCS 、 SHA512-RSA-PKCS RSA-PKCS-PSS (PSSパディング) OpenSSL プロバイダー(v3.x)の使用 # OpenSSLをNXPプロバイダーを使用するように設定してください(/etc/ssl/openssl.cnf参照) openssl pkeyutl -provider nxp -sign -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in in.txt -out signature.der   操作6：SE051のRSA公開鍵を使用して署名を検証する ステップ1 — SE051から公開鍵をエクスポートする # Method A: via ssscli ssscli get rsa pub 0x10101010 rsa_pub.der # Method B: via pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --read-object --type pubkey --slot 1 --label sss:10101010 -o pubkey.der # Convert DER to PEM for OpenSSL openssl rsa -in pubkey.der -inform der -out pubkey.pem -outform pem -pubin ステップ2 — 検証（ホスト側、SE051は不要） openssl dgst -keyform PEM -verify pubkey.pem -sha256 -signature signature.der in.txt # Expected output: Verified OK 操作7：SE051のRSA公開鍵を使用してデータを暗号化する RSA暗号化は公開鍵を使用します（暗号化にセキュアエレメントは不要です）。 # Encrypt with public key (host side) openssl rsautl -encrypt -inkey pubkey.pem -in in.txt -pubin -out crypt.txt OAEPパディング（推奨）には以下を使用してください。 openssl pkeyutl -encrypt -inkey pubkey.pem -pubin > -pkeyopt rsa_padding_mode:oaep > -pkeyopt rsa_oaep_md:sha256 > -in in.txt -out crypt.txt AN13030 セクション 3.3.5.6 には、 kAlgorithm_SSS_RSAES_PKCS1_OAEP_SHA256 および kAlgorithm_SSS_RSAES_PKCS1_V1_5 を含むサポートされているアルゴリズムがリストされています。 操作8：SE051のRSA秘密鍵を使用してデータを復号化する RSA秘密鍵の復号化は、SE051内部で完全に実行されます。秘密鍵はセキュアエレメントから決して外に出ることはありません。 使用 pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --decrypt --label sss:10101010 --slot 1 -i crypt.txt -o decrypt.txt cat decrypt.txt OpenSSL プロバイダー(v3.x)の使用 openssl pkeyutl -provider nxp -decrypt -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in crypt.txt -out decrypt.txt AN13030 セクション2.3.4は「RSAの暗号化および復号機能がプロバイダーに追加された」(v04.05.03以降、v04.07.01に含まれます)を確認しています。 キーIDラベルの慣例 NXP PKCS#11ライブラリで pkcs11-tool を使用する場合、Key IDラベル形式は以下の通りです。 sss: 例えば、キーID 0x10101010 →ラベル sss:10101010 バージョン04.07.00 (PKCS#11 v4.7) における互換性のない変更点:バイトスワップを回避するため、 CKA_ID 属性（ --id ）はバイト配列として扱われるようになりました。エンディアンを変更せずにIDを渡します。 PKCS#11トークンの初期化（初回設定） pkcs11-tool を使用する前に、トークンスロットを初期化する必要がある場合があります。 # Initialize slot 0 pkcs11-tool --module $PKCS11_MODULE --init-token --slot 0 --label "SE051_Token" --so-pin 12345678 # Set user PIN pkcs11-tool --module $PKCS11_MODULE --init-pin --slot 0 --login --so-pin 12345678 --pin 87654321 OpenSSL 3.x プロバイダー構成 /etc/ssl/openssl.cnf （またはカスタム設定ファイル）に追加します。 [openssl_init] providers = provider_sect [provider_sect] default = default_sect nxp = nxp_sect [default_sect] activate = 1 [nxp_sect] module = /usr/local/lib/libsss_provider.so activate = 1 OpenSSLプロバイダーのソースは以下の場所でも利用可能です: https://github.com/NXPPlugNTrust/se05x-openssl-provider ソースコード例（simw-top内） MWパッケージに内蔵された以下の例は、これらの操作を直接示しています: 動作 パス例 AESの暗号化/復号 simw-top/sss/ex/symmetric/ex_sss_symmetric.c RSA署名/検証 simw-top/sss/ex/rsa/ （AN13030のセクション5.2.1.2） ECC署名/検証 simw-top/sss/ex/ecc/ （AN13030のセクション5.2.1.1） PKCS#11 スクリプト simw-top/sss/plugin/pkcs11/scripts/ OpenSSL プロバイダ RSA enc simw-top/sss/plugin/openssl_provider/scripts/openssl_RsaEnc.py OP-TEEにおける既知の制限事項 OP-TEEカーネル側からSE051へのAESオフロードは、 CFG_NXP_SE05X_CTR_DRV 有効化されている必要があります。PKCS#11を経由したユーザー空間AESはアクセス**マネージャ**を経由し、OP-TEEの暗号**ドライバ**オフロードとは別に行われます。 SE051のRSA鍵生成は、バージョン04.07.01でデフォルトでCRT形式となっています(PKCS11 v4.8でサポートが追加され RSA_CRT )。cmakeオプション PKCS11_ENABLE_RSA_KEY_GEN_CRT を使ってCRTと普通のRSAを切り替えてください。 SE051 NVMには制限があります。RSA鍵ペアの生成回数が多いと、永続ストレージが枯渇する可能性があります。使用されていないオブジェクトは ssscli delete で削除してください。 複数のプロセス同時アクセス(例:複数のユーザー空間アプリ)には、 simw-top/hostlib/hostlib/accessManager のアクセスマネージャを使用します。 -DSMCOM:STRING=JRCP_V1_AM で構築します。 参考資料 ドキュメント 説明 AN13030 プラグ&トラストMWドキュメント(主要参照) AN12660 SE05xによるIEC 62443準拠 ― SSS APIの例へのポインタを含む simw-top/doc/ (ローカルHTML) インストール済みバージョンv04.08.01の完全なドキュメント simw-top/doc/plugins/pkcs11.html PKCS#11 スタンドアロンライブラリのドキュメント simw-top/doc/demos.html 利用可能なデモ例の完全なリスト お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? こんにちは、 @Uc_S さん。 CFG_NXP_SE05X=y が設定されると、OP-TEEはSE051のI2Cバスの独占所有権を取得します。Linux DTSはそのI2Cコントローラを無効にしなければなりません(統合ガイドに記載されています)。これは、Plug & Trust MW の使用方法を根本的に変えるものです。 レイヤ 誰が運営しているのか SE051への到達方法 OP-TEE セキュアワールド OP-TEEコア ネイティブI2Cドライバー( CFG_IMX_I2C=y )— ダイレクト、排他 Linuxユーザースペース あなたのアプリケーション、ssscli、アクセス マネージャ T1oI2Cは使えません — Linux DTSではI2Cが無効化されています つまり、既存のcmake設定はLinuxが直接I2Cを所有している場合にのみ適用される -DPTMW_SMCOM=T1oI2C です。OP-TEEの設定では、以下に説明する2つの異なるビルドシナリオに適用されます。 シナリオ1：MWビルドがOP-TEE（ CFG_NXP_SE05X_PLUG_AND_TRUST= ）に供給される これが最も重要な事件です。MWはOP-TEE内部で静的ライブラリとしてコンパイルされるため、 cmake 手動で実行する必要はありません。OP-TEEのMakefileは、 CFG_NXP_SE05X_PLUG_AND_TRUST で抽出したMWディレクトリを指定すると、自動的に統合処理を行います。 CFG_NXP_SE05X_PLUG_AND_TRUST=$HOME/linux-factory/plug-and-trust あなたが挙げたSMCOM、Host、およびAuthフラグは、ここでは適用されません。OP-TEEは独自のネイティブI2C抽象化層( CFG_IMX_I2C=y )を介してSE051を駆動し、Linux MW通信スタックを完全にバイパスします。 シナリオ2:Linuxユーザースペースツール(ssscli / Access Manager / デモ) ここで、CMakeのフラグが適用されます。OP-TEEがI2Cを所有する場合、変更が必要な箇所をフラグごとに分析した結果は以下のとおりです。 変更しなければならない旗 フラグ 現在の価値 OP-TEEセットアップの推奨値 理由 -DPTMW_SMCOM T1oI2C JRCP_V1_AM (アクセス マネージャを使う場合) Linuxは直接I2Cを使用できません。アクセス マネージャはソケットプロキシを提供します -DPTMW_SE05X_Auth PlatfSCP03 None SCP03チャネルはLinuxユーザースペースではなくOP-TEEによって確立されています -DPTMW_SCP SCP03_SSS None 同じ理由です。SCP03はOP-TEEセキュアワールドが所有しています。 変わらない旗 フラグ バリュー 理由 -DPTMW_Applet SE05X_C お使いのSE051C2バリアント（OEF ID A8FA）に適合しています。 -DPTMW_SE05X_Ver 07_02 OP-TEEのブートログに見られるアプレットバージョン7.2に一致します。 -DPTMW_Host iMXLinux まだLinux i.MX 動いています -DPTMW_HostCrypto OPENSSL 変更なし -DPTMW_RTOS Default 変更なし -DPTMW_OpenSSL 3_0 OpenSSL 3.x では変更なし -DPTMW_FIPS None 変更なし -DPTMW_SBL None 変更なし -DPTMW_mbedTLS_ALT None 変更なし -DPTMW_Log Silent 変更なし -DPTMW_SE_RESET_LOGIC 1 変更なし。v04.07.00で新しいオプションが追加されました。 LinuxユーザースペースツールのOP-TEEセットアップにおける推奨cmakeコマンド cd simw-top && mkdir build_optee_linux cmake -S . -B ./build_optee_linux/ -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=None -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=None -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 cd build_optee_linux && make -j8 注: JRCP_V1_AM アクセスマネージャーがターゲット上でデーモンとして動作している必要があります。アクセスマネージャー自体はSE051に接続しますが、重要な注意点を参照してください。 重要な注意点:アクセスマネージャーとのI2C対立 アクセスマネージャー( hostlib/hostLib/accessManager )は、複数のLinuxプロセスからの同時I2Cアクセスをシリアライズするよう設計されています。しかし： OP-TEEがLinux DTSでI2Cインターフェースを完全に無効にした場合( CFG_NXP_SE05X=y で求められます)、アクセスマネージャー自体もI2Cを起動できません。 つまり、有効なデプロイメントオプションは2つあります。 選択肢A：OP-TEE限定（生産向け推奨） OP-TEEはI2Cを完全に所有しています。Linuxユーザースペースでは、暗号操作にはOP-TEE PKCS#11 TA( libckteec.so )のみを使用しています。このモードでは、Plug and Trust MWのSSSCLIやデモはLinuxからは実行されません。 Linux App → libckteec.so → OP-TEE PKCS#11 TA → SE051 これは i.MX Linux ユーザーガイド(UG10163)で説明されているOP-TEEベースのSE05x使用に関する経路です。 選択肢B：共存（テスト／プロビジョニング） LinuxからI2Cを無効化 しない LinuxのDTSを使いましょう(つまり、 lf-6.12.y-i2c-disabled-se050 DTSパッチを適用しないでください)。この構成では： OP-TEEは暗号化オフロード（RSA/ECC）にSE051を使用します。 Linuxのユーザースペースは、元のフラグを使ってSSSCLIやアクセスマネージャーを T1oI2C 実行できます。 リスク:OP-TEEとLinuxの両方からの同時I2Cアクセスには慎重な仲裁が必要です この選択肢では、 SMCOM、SCP、およびAuthフラグを元の値に戻し、元のI2C DTSを維持してください（無効にしないでください）。 要約表 ユース・ケース SMCOM SCP 認証 備考 OP-TEE内部MW（OP-TEEビルド用の静的ライブラリ） N/A N/A N/A cmakeは不要です。 CFG_NXP_SE05X_PLUG_AND_TRUST= Linuxユーザースペース、OP-TEE独占I2C JRCP_V1_AM None None Access Managerが必要ですが、I2Cを無効にするとAM自体がSE051にアクセスできません Linuxユーザースペース、共存(I2C共有) T1oI2C SCP03_SSS PlatfSCP03 あなたの元のフラグは、Linux DTSがまだI2Cを有効にしている場合に有効です Linuxユーザースペース(PKCS#11 TA経由、OP-TEE限定) 該当なし（MWビルドなし） N/A N/A pkcs11-tool / openssl を libckteec.so 追加参考資料 AN13030 Rev. 2.4 — セクション4.4(i.MX Linux ビルド)、セクション8.9(PKCS#11 スタンドアロンライブラリ)、Access Managerドキュメント UG10163 i.MX Linuxユーザーガイド — libckteec.so を用いたOP-TEE PKCS#11コマンド例(セクション10.4.7および10.4.8、110–114ページ); 注: これらの例はOP-TEE内部セキュアストレージをキーバックエンドとして使用しており、SE05xを直接使うわけではありません。SE051がOP-TEE暗号バックエンドとしてCFG_NXP_SE05X=yを介して設定されている場合もコマンド構文は同じです すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? @Kan_Li 丁寧かつ詳細なご回答をいただき、誠にありがとうございました。 サポートされている3つのパスの詳細な説明とコマンド例は非常に役立ちます。 OP-TEE環境に関して、Linuxのrootfs上のPlug & TrustミドルウェアのCMakeビルド構成について追加の質問があります。 以前は、OP-TEEルーティングなしでLinux上でミドルウェアを直接実行していた際、以下のCMake設定フラグを使用していました: -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=T1oI2C -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=SCP03_SSS -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 上記の設定のうちどれを変えるべきか、またこのOP-TEEセットアップで推奨される新しい値は何であるべきか教えていただけますか? 詳細： OP-TEEがSE051への直接I2Cアクセス(CFG_NXP_SE05X=y経由)を所有している今、Linuxのユーザー空間ミドルウェアやツール(SSSCLIやアクセス マネージャなど)を構築する際に、これらのCMakeフラグのいずれかを変更する必要があるのか教えていただけますか? 具体的には、-DPTMW_SMCOM(例:T1oI2CからJRCP_V1_AMやソケットインターフェースへの変更)や-DPTMW_Hostのようなオプションは、Linuxユーザー空間向けにOP-TEE経由でリクエストを適切にルーティングするために更新すべきでしょうか? 私の環境情報は以下のとおりです。 基板：MCIMX8M-WEVKおよびOM-SE051ARD Plug and Trust MW バージョン: v04.07.01 OP-TEE OSバージョン：3.19.0 Linuxカーネル:6.1.151 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? この非常に詳細かつ明快な説明をいただき、誠にありがとうございました。 フラッグごとの説明、ビルドコマンドの例、特にI2Cの競合と選択肢A(OP-TEE独占、libckteec.so 経由)の選択に関する重要な注意点そして選択肢B（共存）によって、設定オプションが明確になりました。 この情報は、今後のアーキテクチャを決定する上でまさに必要なものでした。

How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hello, NXP Community, I am currently working on integrating the Plug and Trust Middleware into OP-TEE based on the environment described in this post: How to integrate Plug and Trust MW into OP-TEE. My goal is to achieve the following operations from a user-space application running on Linux, leveraging the SE051 secure element: Generate an AES key and store it in SE051. Generate an RSA key pair and store it in SE051. Encrypt a file using the AES key stored in SE051. Decrypt the file using the AES key stored in SE051. Sign data using the RSA private key in SE051. Verify the signature using the RSA public key in SE051. Encrypt data using the RSA public key in SE051. Decrypt data using the RSA private key in SE051. Could anyone guide me on the best approach to achieve these operations? I am open to using any of the following command-line tools (or a combination of them), provided they are supported in this OP-TEE setup: openssl commands (via OpenSSL provider) ssscli tool pkcs11-tool (via PKCS#11 interface) Any examples, documentation links, or command usage samples for this specific OP-TEE environment would be greatly appreciated. SE050 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hi @Uc_S , There are three supported paths from Linux user-space to the SE051. All three are available with Plug & Trust MW v04.07.01: Path Library Best For PKCS#11 libsss_pkcs11.so AES, RSA key gen/sign/verify/enc/dec via pkcs11-tool OpenSSL Provider (3.x) libsss_provider.so RSA sign/verify/enc/dec via openssl pkeyutl ssscli Python CLI Key injection / provisioning only Important note for OP-TEE environment: In your OP-TEE setup ( CFG_NXP_SE05X=y ), the SE051 is accessed by OP-TEE core directly via the native I2C driver. Linux user-space applications do not own the I2C bus. All three paths above work correctly because the Plug & Trust MW Access Manager ( accessManager ) or the T1oI2C socket interface routes commands through OP-TEE's trusted world to the SE051. Operation 1: Generate an AES Key and Store It in SE051 Use ssscli to generate an AES-256 key at a specific Key ID (object ID in SE051): # Generate AES-256 key at Key ID 0x20000001 ssscli generate aes 0x20000001 256 To verify the key exists: ssscli get aes 0x20000001 aes_key_info.txt Note: AES keys are symmetric and cannot be exported from SE051. The Key ID 0x20000001 is a 32-bit object identifier stored persistently in SE051 NVM. Operation 2: Generate an RSA Key Pair and Store It in SE051 Option A — Using pkcs11-tool (recommended) RSA key labels use the format sss: : # Generate RSA-2048 key pair at Key ID 0x10101010 pkcs11-tool --module $PKCS11_MODULE --keypairgen --key-type rsa:2048 --label "sss:10101010" Option B — Using ssscli ssscli generate rsa 0x10101010 2048 AN13030 Section 3.3.8.3 notes: RSA key pairs must be DER encoded using PKCS#8 or traditional OpenSSL format when injecting externally. When retrieved via sss_key_store_get_key() , only the public key is returned. Operation 3: Encrypt a File Using the AES Key in SE051 AES symmetric encryption is performed via the SSS API ( sss_cipher_one_go ) or, for command-line use, through a small wrapper application. The MW provides a built-in symmetric example at: simw-top/sss/ex/symmetric/ex_sss_symmetric.c For direct command-line use, build and run the example: # After building the MW examples: ./se05x_symmetric_aes_cbc_encrypt --keyid 0x20000001 --input plaintext.bin --output ciphertext.bin --iv 00000000000000000000000000000000 The MW supports: kAlgorithm_SSS_AES_ECB , kAlgorithm_SSS_AES_CBC , kAlgorithm_SSS_AES_CTR , kAlgorithm_SSS_AES_GCM , kAlgorithm_SSS_AES_CCM (from Section 3.3.9.1 of AN13030). Operation 4: Decrypt a File Using the AES Key in SE051 ./se05x_symmetric_aes_cbc_decrypt --keyid 0x20000001 --input ciphertext.bin --output decrypted.bin --iv 00000000000000000000000000000000 The SSS API uses kMode_SSS_Decrypt mode with sss_cipher_one_go() for one-shot decryption, or the multi-step sss_cipher_init() / sss_cipher_update() / sss_cipher_finish() sequence for streaming. Operation 5: Sign Data Using the RSA Private Key in SE051 Using pkcs11-tool (key stays in SE051) # Sign with RSA private key (key never leaves SE051) pkcs11-tool --module $PKCS11_MODULE --sign --label sss:10101010 -m SHA256-RSA-PKCS --slot 1 -i in.der -o signature.der Supported sign mechanisms via PKCS#11: SHA256-RSA-PKCS (RSASSA-PKCS1-v1_5 with SHA-256) SHA1-RSA-PKCS , SHA384-RSA-PKCS , SHA512-RSA-PKCS RSA-PKCS-PSS (PSS padding) Using OpenSSL Provider (v3.x) # Configure OpenSSL to use the NXP provider (see /etc/ssl/openssl.cnf) openssl pkeyutl -provider nxp -sign -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in in.txt -out signature.der   Operation 6: Verify Signature Using the RSA Public Key in SE051 Step 1 — Export public key from SE051 # Method A: via ssscli ssscli get rsa pub 0x10101010 rsa_pub.der # Method B: via pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --read-object --type pubkey --slot 1 --label sss:10101010 -o pubkey.der # Convert DER to PEM for OpenSSL openssl rsa -in pubkey.der -inform der -out pubkey.pem -outform pem -pubin Step 2 — Verify (host-side, no SE051 required) openssl dgst -keyform PEM -verify pubkey.pem -sha256 -signature signature.der in.txt # Expected output: Verified OK Operation 7: Encrypt Data Using the RSA Public Key in SE051 RSA encryption uses the public key (no secure element needed for encrypt): # Encrypt with public key (host side) openssl rsautl -encrypt -inkey pubkey.pem -in in.txt -pubin -out crypt.txt For OAEP padding (recommended), use: openssl pkeyutl -encrypt -inkey pubkey.pem -pubin > -pkeyopt rsa_padding_mode:oaep > -pkeyopt rsa_oaep_md:sha256 > -in in.txt -out crypt.txt AN13030 Section 3.3.5.6 lists supported algorithms including kAlgorithm_SSS_RSAES_PKCS1_OAEP_SHA256 and kAlgorithm_SSS_RSAES_PKCS1_V1_5 . Operation 8: Decrypt Data Using the RSA Private Key in SE051 The RSA private key decryption is performed entirely inside SE051. The private key never leaves the secure element. Using pkcs11-tool pkcs11-tool --module $PKCS11_MODULE --decrypt --label sss:10101010 --slot 1 -i crypt.txt -o decrypt.txt cat decrypt.txt Using OpenSSL Provider (v3.x) openssl pkeyutl -provider nxp -decrypt -inkey "pkcs11:token=sss;object=sss:10101010;type=private" -in crypt.txt -out decrypt.txt AN13030 Section 2.3.4 confirms: "RSA Encrypt and decrypt feature added in provider" (from v04.05.03 onwards, included in v04.07.01). Key ID Label Convention When using pkcs11-tool with the NXP PKCS#11 library, the Key ID label format is: sss: For example, Key ID 0x10101010 → label sss:10101010 Breaking change in v04.07.00 (PKCS#11 v4.7): The CKA_ID attribute ( --id ) is now treated as a byte array to avoid byte swapping. Pass the ID without changing endianness. PKCS#11 Token Initialization (First-Time Setup) Before using pkcs11-tool , you may need to initialize the token slot: # Initialize slot 0 pkcs11-tool --module $PKCS11_MODULE --init-token --slot 0 --label "SE051_Token" --so-pin 12345678 # Set user PIN pkcs11-tool --module $PKCS11_MODULE --init-pin --slot 0 --login --so-pin 12345678 --pin 87654321 OpenSSL 3.x Provider Configuration Add to /etc/ssl/openssl.cnf (or a custom config file): [openssl_init] providers = provider_sect [provider_sect] default = default_sect nxp = nxp_sect [default_sect] activate = 1 [nxp_sect] module = /usr/local/lib/libsss_provider.so activate = 1 The OpenSSL provider source is also available at: https://github.com/NXPPlugNTrust/se05x-openssl-provider Source Code Examples (in simw-top) The following built-in examples in the MW package directly demonstrate these operations: Operation Example Path AES encrypt/decrypt simw-top/sss/ex/symmetric/ex_sss_symmetric.c RSA sign/verify simw-top/sss/ex/rsa/ (Section 5.2.1.2 of AN13030) ECC sign/verify simw-top/sss/ex/ecc/ (Section 5.2.1.1 of AN13030) PKCS#11 scripts simw-top/sss/plugin/pkcs11/scripts/ OpenSSL Provider RSA enc simw-top/sss/plugin/openssl_provider/scripts/openssl_RsaEnc.py Known Limitations in OP-TEE Context AES offload to SE051 from OP-TEE kernel side depends on CFG_NXP_SE05X_CTR_DRV being enabled. User-space AES via PKCS#11 goes through the Access Manager and is separate from the OP-TEE crypto driver offload. RSA key generation in SE051 is CRT format by default in v04.07.01 ( RSA_CRT support added in PKCS11 v4.8). Use PKCS11_ENABLE_RSA_KEY_GEN_CRT cmake option to switch between CRT and plain RSA. SE051 NVM is limited. Many RSA key pair generations may exhaust persistent storage — delete unused objects with ssscli delete . For concurrent multi-process access (e.g., multiple user-space apps), use the Access Manager at simw-top/hostlib/hostlib/accessManager . Build with -DSMCOM:STRING=JRCP_V1_AM . Reference Documents Document Description AN13030 Plug & Trust MW Documentation (primary reference) AN12660 IEC 62443 compliance with SE05x — includes SSS API example pointers simw-top/doc/ (local HTML) Full documentation for your installed version v04.08.01 simw-top/doc/plugins/pkcs11.html PKCS#11 Standalone Library documentation simw-top/doc/demos.html Complete list of available demo examples Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Hi @Uc_S , When CFG_NXP_SE05X=y is set, OP-TEE takes exclusive ownership of the I2C bus to the SE051. The Linux DTS must disable that I2C controller (as described in the integration guide). This fundamentally changes how the Plug & Trust MW is used: Layer Who Runs It How It Reaches SE051 OP-TEE Secure World OP-TEE core Native I2C driver ( CFG_IMX_I2C=y ) — direct, exclusive Linux Userspace Your application, ssscli, Access Manager Cannot use T1oI2C — I2C is disabled in Linux DTS This means your existing cmake configuration with -DPTMW_SMCOM=T1oI2C applies only when Linux directly owns I2C. In the OP-TEE setup, it applies to two separate build scenarios described below. Scenario 1: MW Build Fed into OP-TEE ( CFG_NXP_SE05X_PLUG_AND_TRUST= ) This is the most important case. The MW is compiled as a static library inside OP-TEE — you do not run cmake manually for this. OP-TEE's Makefile handles the integration automatically when you point CFG_NXP_SE05X_PLUG_AND_TRUST at your extracted MW directory: CFG_NXP_SE05X_PLUG_AND_TRUST=$HOME/linux-factory/plug-and-trust The SMCOM, Host, and Auth flags you listed are not applicable here. OP-TEE drives the SE051 via its own native I2C abstraction layer ( CFG_IMX_I2C=y ), bypassing the Linux MW communication stack entirely. Scenario 2: Linux Userspace Tools (ssscli / Access Manager / Demos) This is where your cmake flags do apply. When OP-TEE owns I2C, here is the flag-by-flag analysis of what must change: Flags That MUST Change Flag Your Current Value Recommended Value for OP-TEE Setup Reason -DPTMW_SMCOM T1oI2C JRCP_V1_AM (if using Access Manager) Linux cannot use I2C directly; Access Manager provides socket proxy -DPTMW_SE05X_Auth PlatfSCP03 None SCP03 channel is established by OP-TEE, not Linux userspace -DPTMW_SCP SCP03_SSS None Same reason — SCP03 is owned by OP-TEE secure world Flags That Stay the Same Flag Value Reason -DPTMW_Applet SE05X_C Correct for your SE051C2 variant (OEF ID A8FA) -DPTMW_SE05X_Ver 07_02 Matches applet version 7.2 seen in OP-TEE boot logs -DPTMW_Host iMXLinux Still running on i.MX Linux -DPTMW_HostCrypto OPENSSL Unchanged -DPTMW_RTOS Default Unchanged -DPTMW_OpenSSL 3_0 Unchanged for OpenSSL 3.x -DPTMW_FIPS None Unchanged -DPTMW_SBL None Unchanged -DPTMW_mbedTLS_ALT None Unchanged -DPTMW_Log Silent Unchanged -DPTMW_SE_RESET_LOGIC 1 Unchanged; new option added in v04.07.00 Recommended cmake Command for Linux Userspace Tools in OP-TEE Setup cd simw-top && mkdir build_optee_linux cmake -S . -B ./build_optee_linux/ -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=JRCP_V1_AM -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=None -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=None -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 cd build_optee_linux && make -j8 Note: JRCP_V1_AM requires the Access Manager to be running as a daemon on the target. The Access Manager itself connects to the SE051 — but see the important caveat below. Critical Caveat: The Access Manager I2C Conflict The Access Manager ( hostlib/hostLib/accessManager ) is designed to serialize concurrent I2C access from multiple Linux processes. However: When OP-TEE fully disables the I2C interface in Linux DTS (as required by CFG_NXP_SE05X=y ), the Access Manager itself cannot open I2C either. This means you have two valid deployment choices: Choice A: OP-TEE Exclusive (Recommended for Production) OP-TEE owns I2C completely. Linux userspace uses only the OP-TEE PKCS#11 TA ( libckteec.so ) for crypto operations. The Plug & Trust MW ssscli and demos are not run from Linux in this mode. Linux App → libckteec.so → OP-TEE PKCS#11 TA → SE051 This is the path described in the i.MX Linux User's Guide (UG10163) for OP-TEE-based SE05x use. Choice B: Co-existence (Testing / Provisioning) Use a Linux DTS that does not disable I2C from Linux (i.e., do NOT apply the lf-6.12.y-i2c-disabled-se050 DTS patch). In this configuration: OP-TEE uses SE051 for crypto offload (RSA/ECC) Linux userspace can still run ssscli / Access Manager using T1oI2C (your original flags) Risk: concurrent I2C access from both OP-TEE and Linux requires careful arbitration For this choice, revert SMCOM, SCP, and Auth flags to your original values and keep the original I2C DTS (do not disable it). Summary Table Use Case SMCOM SCP Auth Notes OP-TEE internal MW (static lib for OP-TEE build) N/A N/A N/A No cmake needed; handled by CFG_NXP_SE05X_PLUG_AND_TRUST= Linux userspace, OP-TEE exclusive I2C JRCP_V1_AM None None Requires Access Manager, but AM itself can't reach SE051 if I2C disabled Linux userspace, co-existence (I2C shared) T1oI2C SCP03_SSS PlatfSCP03 Your original flags — valid if Linux DTS still has I2C enabled Linux userspace via PKCS#11 TA (OP-TEE exclusive) N/A (no MW build) N/A N/A Use pkcs11-tool / openssl with libckteec.so Additional Reference AN13030 Rev. 2.4 — Section 4.4 (i.MX Linux Build), Section 8.9 (PKCS#11 Standalone Library), Access Manager documentation UG10163 i.MX Linux User's Guide — OP-TEE PKCS#11 command examples using libckteec.so (Sections 10.4.7 & 10.4.8, pages 110–114); Note: these examples use OP-TEE internal secure storage as the key backend, not SE05x directly — the command syntax is the same when SE051 is configured as the OP-TEE crypto backend via CFG_NXP_SE05X=y Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? @Kan_Li  Thank you very much for the thorough and detailed response. The breakdown of the three supported paths and the command examples are extremely helpful. Regarding the OP-TEE environment, I have a follow-up question regarding the CMake build configuration for the Plug & Trust Middleware on the Linux rootfs. Previously, when running the middleware directly on Linux (without OP-TEE routing), we used the following CMake configuration flags: -DPTMW_Applet=SE05X_C -DPTMW_SE05X_Ver=07_02 -DPTMW_Host=iMXLinux -DPTMW_SMCOM=T1oI2C -DPTMW_HostCrypto=OPENSSL -DPTMW_RTOS=Default -DPTMW_mbedTLS_ALT=None -DPTMW_SCP=SCP03_SSS -DPTMW_FIPS=None -DPTMW_SBL=None -DPTMW_SE05X_Auth=PlatfSCP03 -DPTMW_Log=Silent -DCMAKE_BUILD_TYPE=Release -DPTMW_OpenSSL=3_0 -DPTMW_SE_RESET_LOGIC=1 Could you please advise which of the above settings should be changed and what their new recommended values should be for this OP-TEE setup? Details: Now that OP-TEE owns the direct I2C access to the SE051 (via CFG_NXP_SE05X=y), could you please clarify if any of these CMake flags need to be modified when building the Linux user-space middleware/tools (such as ssscli or Access Manager)? Specifically, should options like -DPTMW_SMCOM (e.g., changing from T1oI2C to JRCP_V1_AM or socket interface) or -DPTMW_Host be updated for the Linux user-space side to properly route requests through OP-TEE? Here are my environment details: Board: MCIMX8M-WEVK and OM-SE051ARD Plug and Trust MW Version: v04.07.01 OP-TEE OS Version: 3.19.0 Linux Kernel: 6.1.151 Re: How to perform Key Gen, Enc/Dec, and Sign/Verify with SE051 via OP-TEE on Linux? Thank you very much for this exceptionally detailed and clear explanation. The flag-by-flag breakdown, the build command example, and especially the critical caveat regarding the I2C conflict and the choice between Choice A (OP-TEE Exclusive via libckteec.so) and Choice B (Co-existence) have clarified our setup options. This information was exactly what we needed to determine our architecture moving forward.

关于 i.MX8Mplus 的有限状态机 (FSM) 我们公司使用的是 Toradex 的 Veridin i.MX8Mplus。 此时，输入 SOM_PW_ON 信号以控制 SoM 的电源。（直接连接到 i.mx8MPlusSoC 的 ON/OFF 信号）。*请参考所附示波器上的波形。 V1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.pngV1-1B_tool0_OFF.png   由于 SoM 侧的电路配置，电压应为高电压 (1.8V)，但在启动后约 800 毫秒内，电压保持在约 0.3-0.4V 的中间电位。 我想知道 SoC 端是如何处理 0.3 至 0.4V 电压作为 ON/OFF 信号的。 该信息未包含在数据表或参考手册中。 我认为，在极短的开/关操作（<5秒）的情况下，系统可能会关机。操作检测标准是否应该是从高电平到低电平的转换以及低电平状态的持续时间？ 我还想知道这些时间段的具体最短/最长时间。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MplusのFinite-State Machine (FSM)について 对于 i.MX8M Plus，ONOFF 被处理成一个按住按钮输入，可配置 0/50/100/500 毫秒的延迟和 5/10/15 秒的强制关机时间，并且观察到 0.3–0.4根据现有的输入阈值文档，1.8V ONOFF 网络上的 V 最常被解释为逻辑低电平。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档，观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下，您能否也告诉我一下逻辑上被解释为低电压的阈值是多少？ 此外，如果解释为逻辑低，则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒，然后变为逻辑高。 在这种情况下，是否可以认为发生了按钮输入？ 我担心按下按钮是否会导致系统在启动后立即自动关机。 Re: i.MX8MplusのFinite-State Machine (FSM)について 顺便问一下，您能否也告诉我一下逻辑上被解释为低电压的阈值是多少？ 抱歉。我想知道逻辑值被解读时的电压阈值。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档，观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下，您能否也告诉我一下被解释为逻辑高电平的电压阈值是多少？ 此外，如果解释为逻辑低，则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒，然后变为逻辑高。 在这种情况下，是否可以认为发生了按钮输入？ 我担心按下按钮是否会导致系统在启动后立即自动关机。 致恩智浦技术支持代表 你对此事有何看法？ 我还有一个问题： ON/OFF 被处理为电平保持按钮输入，条件为 0/50/100/500 毫秒。 关于这一点，我认为默认值是 0。在这种情况下，如果由于噪声或其他因素导致电平瞬间超过逻辑高电平或逻辑低电平阈值，电平是否会被保持？ 我担心，在这种默认设置下，如果接收到噪声，即使只是一瞬间，如果引入了导致逻辑判断与当前保持的逻辑电平相反的因素，也可能导致故障。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 我又补充了一些问题。 给您带来的不便，我们深表歉意，请您尽快回复。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 确认流程进展如何？ 请提供答案。 Re: i.MX8MplusのFinite-State Machine (FSM)について 很抱歉错过了您的消息，我可以帮忙查看，下周会回复您。 祝你今天过得愉快 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 谢谢你的帮助。 这是Pal Giken的Mori。 已经过去快一周了，反响如何？ 感谢您的合作。 Re: i.MX8MplusのFinite-State Machine (FSM)について @毛利修二 对于 i.MX8MP，ONOFF 引脚属于 NVCC_SNVS 电源组，并被列为复位状态为“带 PU 的输入”的 GPIO 类型输入。适用的 GPIO 直流输入低电平规格为： VIL(最大值)=0.3× VDD V I L( 最大值) = 0.3 × V D D 表格中将低电平输入电压的最小值设定为 -0.3V,max = 0.3 × VDD。 因此，如果 ONOFF 由 1.8 V SNVS I/O 功能域供电，则保证的逻辑低电平阈值为： 0.3×1.8 V=0.54 V 0.3 × 1.8 V = 0.54 V 因此，观察到的ONOFF电压约为0.3–0.4V 将被解释为逻辑低。 关于这是否会被视为按钮输入：是的，如果设备处于 ON 模式后 ONOFF 引脚保持低电平足够长的时间，则可以将其视为有效的 ONOFF 按钮事件。 持续 800 毫秒的低电平信号可被识别为正常的 ONOFF 按钮事件。 因为它超过了配置的正常按钮防抖持续时间。 它不应直接触发硬件紧急强制关机。 因为那需要大约 5秒 。 系统启动后是否立即关闭取决于软件/PMIC对正常ONOFF事件的处理。在 ON 模式下，短暂连接到 GND 会产生一个中断，旨在启动软件可控的断电。如果启动软件或操作系统电源键处理程序将该中断视为关机请求，则启动后可能会发生意外关机。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 感谢你的回复。 我提出这个问题想问的是： 问题是，在启动过程中，当ONOFF 引脚处于逻辑低状态时，按钮输入是否能被识别。 我们的验证 观察到的一种现象是，当 ONOFF 引脚以逻辑高电平开始，然后在 10 毫秒到 20 毫秒后变为逻辑低电平时，系统会在启动后立即关闭。 当系统以逻辑低电平启动时，尚未观察到系统启动后立即关机的情况。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 请回答我提出的问题。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 给您带来不便，敬请谅解，请问您能否也回答一下这个问题？ Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 问题是，在启动过程中，当ONOFF 引脚处于逻辑低状态时，按钮输入是否能被识别。 你对此有何看法？ Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 你对这些问题的答案有什么看法？ 请检查。

CircO2レビュー2026：成分、効果、副作用、購入ガイド CircO2はAdvanced Bionutritionalsが製造する一酸化窒素サポートサプリメントです。多くの錠剤を水と一緒に飲み込むのとは異なり、CircO2は口の中で溶ける素早く溶ける錠剤(時にトローチとも呼ばれます)で提供されています。これがマーケットにある他のCircO2タブレットと差別化される理由の一つです。 CircO2酸素ブースターと循環サポートの主な考え方はシンプルです。体がより多くの一酸化窒素を生成するのを助け、血管をリラックスさせて広げることです。そうなると、血液(およびその酸素)が体内をより自由に流れることが可能になります。それはエネルギーの増加、手足の温かさ、そして日中の持久力の向上を意味するかもしれません。

触发模式下的ADC问题 在 S32 设计工作室中，我们使用两种方法进行 ADC 外设配置。第一种方法使用 BCTU 触发进行电流检测，而其余通道（如温度和电压检测）则使用普通 ADC 链方法触发。 当 CTU 模式配置为触发模式，并且只有三个电流检测通道配置为 BCTU 触发时，不会出现明显的电流尖峰。但是，当我使用常规链式方法将剩余的温度和电压通道与电流检测通道一起加入时，电流检测值会受到尖峰的影响。 praveen_ext_0-1788357008084.pngpraveen_ext_0-1788357008084.pngpraveen_ext_0-1788357008084.png 这两种方法之间存在时间差异：BCTU 转换是通过中断触发的，而正常的 ADC 链是从 5 毫秒的任务中调用的。 praveen_ext_1-1788357050345.pngpraveen_ext_1-1788357050345.pngpraveen_ext_1-1788357050345.png praveen_ext_2-1788357069814.pngpraveen_ext_2-1788357069814.pngpraveen_ext_2-1788357069814.png praveen_ext_3-1788357094947.pngpraveen_ext_3-1788357094947.pngpraveen_ext_3-1788357094947.png 请问为什么这种差异会导致电流感应尖峰，并请您提出如何减少或消除这种尖峰？ S32K1系列的S32SDK Re: Adc Issue With Trigger Mode 你好@ praveen_ext 看来我和我的同事之前也遇到过和你一样的问题。 我们也按照您的软件配置进行了一些测试，但没有发现如此显著的差异。我们不确定您是否采纳了我们的任何建议。 因此，我需要你提供你的测试项目。我将在我们的硬件平台上重现这个问题。如果问题能够重现，我们就能迅速为您提供有关问题原因的结论。 Re: Adc Issue With Trigger Mode 我已附上测试代码供您审核。我们仍然观察到，在触发配置中同时运行 BCTU 触发信号和正常链模式时会出现峰值。请问您能否帮我们解决一下如何消除这些峰值？我已经在之前的帖子中附上了测试结果。 Re: Adc Issue With Trigger Mode 你好@ praveen_ext 我使用您提供的项目文件录制了测试视频，没有做任何修改。 我将采样引脚外部连接到 VDD；下面的结果表明我没有遇到您描述的尖峰。 Senlent_0-1788492709905.png 我还注意到，您提供的项目文件似乎与您的测试图片中显示的图片不符。如果您能够使用此项目重现该问题，则应检查您的采样电路设计——特别是采样引脚的输入阻抗是否过高。

S32K312 Development Board Debug Probe Selection. Dear NXP Community, I am using an S32K312 (100-pin HDQFP) on a custom controller board with a 10-pin JTAG interface for programming/debugging. I understand from some forum discussions that the S32 Debug Probe may not support S32K312. Can anyone confirm whether the PEmicro U-MULTILINK can be used to program/debug the S32K312 through the JTAG interface? Any guidance on a Cost effective and suitable debug probe would be appreciated. Best Regards, Fayas SCTSPL, Bangalore Re: S32K312 Development Board Debug Probe Selection. Hi @NPD_SCTSPL  Actually, support for S32K3 devices was added relatively recently to the S32 Debug Probe. When using this probe, please note that it supports target system voltage levels only in the range of 1.2 V to 3.3 V. Therefore, VDD_HV_A must be configured to 3.3 V in order to establish a proper debug connection. On the other hand, PEMicro debug probes have supported S32K3 devices for a longer period and have been widely used throughout the development and validation of many S32K3 software. As a result, a significant portion of the available application notes, getting-started guides, and example projects have been developed and tested using PEMicro tools. Finally, regarding your question about the compatibility of the PEmicro U-MULTILINK with S32K3 devices, the answer is yes. PEmicro U-MULTILINK support S32K3 devices and are currently listed among the supported devices on the corresponding product pages of our website (Universal Multilink Development Interface | NXP Semiconductors). BR, VaneB

S32G399A IIC 配置 您好， 我打算使用S32G399的I2C4来配置外部PMIC。我想请问一下，这个I2C4模块是否可以通过A核进行底层软件配置（比如：时钟频率，上下拉电阻，地址等）？我们暂时不会用到M核。所以想通过A核进行S32G的IO的底层配置。 MichaelTao_0-1788251860175.pngMichaelTao_0-1788251860175.png Re: S32G399A IIC 配置 Hello, @MichaelTao  您好，是可以的，A核可以配置I2C4这个模块 BR Chenyin Re: S32G399A IIC 配置 您可以尝试使用 S32 设计工作室进行 I2C 底层驱动程序配置。

在 KW45B41Z-EVK 上使用 eIQ TSS 和移植的 TFLM 中间件实现 AI/ML NXP社区的各位好， 我正在开发一款适用于KW45B41Z-EVK (Cortex-M33) 的边缘 AI 应用，希望就如何在该板上部署机器学习模型获得一些建议。 由于 KW45 SDK 默认不包含 eIQ/TFLM 中间件，我的计划是： 模型训练：使用eIQ Time Series Studio (eIQ TSS)训练一个用于时间序列数据的 n 类分类模型。由于 eIQ TSS 中未列出 KW45 作为目标平台，因此我选择FRDM-MCXN947 (Cortex-M33) 作为导出模型的目标平台。 运行时部署：将FRDM-MCXN947 SDK中的 中间件/eiq/tensorflow-lite 文件夹移植到我的 KW45 SDK 项目中，并将其与 CMSIS-NN 链接。 我的问题： 将 eIQ TFLM 中间件从 MCXN947 SDK 移植到 KW45 SDK 是否是一种有效且受支持的方法？ 在 eIQ TSS 中选择 FRDM-MCXN947 是否适合生成在 KW45 上运行的模型？ 在 KW45B41Z-EVK 上实现 AI/ML 是否有其他推荐的或原生工作流程？ 感谢您的帮助！ Kinetis W系列MCU Re: Implementing AI/ML on KW45B41Z-EVK using eIQ TSS and Ported TFLM Middleware 您好，NXP支持团队和社区， 我写这封信是为了跟进这个询问，因为找到解决方案对我目前的项目时间表来说非常紧迫。 NXP 团队的某位成员能否快速确认一下，将 eIQ/TFLM 中间件从 FRDM-MCXN947 SDK 移植到 KW45 SDK 是否是一种有效且受支持的解决方法？任何关于推荐工作流程的简要指导或确认都将对我非常有帮助，以便我能自信地继续进行开发工作。 感谢您抽出时间提供帮助！ KW45B41Z-EVK EIQ-工具包EIQ-TFLITE-MICRO #AI/ML Re: Implementing AI/ML on KW45B41Z-EVK using eIQ TSS and Ported TFLM Middleware 你好@Srushti_Mulimani ，希望你一切都好。   如果您使用的是 eIQ Time Series Studio (TSS)，我建议您将项目从 FRDM-MCXW71 移植过来。它是 eIQ TSS 官方支持的目标，并且在软件上与 KW45 兼容。这两个设备都采用相同的 Cortex-M33 内核架构和类似的内存配置，因此生成的库应该与您的硬件更加匹配。 当使用硬件配置差异很大的设备（例如 FRDM-MCXN947）作为移植目标时，可能会生成不兼容的模型，例如，由于两个设备之间的可用 RAM 存在差异，或者生成了专门针对 MCXN947 的 NPU 加速模型。 希望这能帮到你！ 此致， 索菲亚。

S32K116的信号复用和引脚分配 您好，NXP团队： 我正在配置我的 NXP MCU 的信号复用和引脚分配，但我无法在现有文档中找到相关信息。 请问谁能指出包含信号复用选项和引脚分配详情（例如，哪些信号/功能可以映射到哪些引脚）的文档或章节？ 我查阅了现有的参考手册和数据表，但仍然找不到我需要的信息。 请问您能否告知我这些信息出处，或者提供相关的参考资料/文件？ 先行致谢。 Re: Signal Multiplexing and Pin Assignment of s32k116 您好， 如 RM 在第 4.5 章 IO 信号描述输入多路复用表所述，该表附在设备参考手册中。 因此，请在 pdf 查看器中打开 RM，以便显示/打开附件，然后直接从那里打开/下载所需的 Excel 文件。 PetrS_0-1788511369480.png BR，彼得

eIQ TSSと移植されたTFLMミドルウェアを使用してKW45B41Z-EVKにAI/MLを実装する こんにちは、NXPコミュニティの皆さん、 私は KW45B41Z-EVK (Cortex-M33)向けのエッジAIアプリケーションを開発しており 、このボード上で機械学習モデルを展開する際にアドバイスをいただきたいです。 KW45 SDKにはデフォルトでeIQ/TFLMミドルウェアが含まれていないため、私の計画は以下の通りです: モデルトレーニング:eIQ Time Series Studio(eIQ TSS)を用いて時系列データのnクラス分類モデルを訓練します。KW45はeIQ TSSのターゲットとしてリストされていないため、モデルをエクスポートするターゲットプラットフォームとしてFRDM-MCXN947(Cortex-M33)を選択しました。 ランタイムデプロイ:FRDM-MCXN947 SDKのmiddleware/eiq/tensorflow-liteフォルダを私のKW45 SDKプロジェクトにポートし、CMSIS-NNと連携させます。 私の質問： MCXN947 SDKからKW45 SDKへのeIQ TFLMミドルウェアの移植は有効でサポートされている方法でしょうか? eIQ TSSでFRDM-MCXN947を選択することは、KW45上で動作するモデルを生成するのに適していますか? KW45B41Z-EVKにAI/MLを実装するための、他に推奨されるワークフローやネイティブなワークフローはありますか？ ご協力いただきありがとうございます！ Kinetis Wシリーズ・マイクロコントローラ Re: Implementing AI/ML on KW45B41Z-EVK using eIQ TSS and Ported TFLM Middleware NXPサポートチームおよびコミュニティの皆様、こんにちは。 この件についてフォローアップのためご連絡いたしました。現在のプロジェクトのスケジュール上、解決策を見つけることが非常に急務となっているためです。 NXPチームのどなたか、FRDM-MCXN947 SDKからKW45 SDKへのeIQ/TFLMミドルウェアの移植が有効でサポートされている回避策かどうか、簡単な確認をいただけませんか?推奨ワークフローについて簡単なガイダンスや確認があれば、自信を持って開発を進められるよう助かります。 お時間とご協力に、前もって感謝申し上げます！ KW45B41Z-EVK EIQ-ツールキットEIQ-TFLITE-MICRO #AI/ML Re: Implementing AI/ML on KW45B41Z-EVK using eIQ TSS and Ported TFLM Middleware こんにちは、 @Srushti_Mulimani さん。お元気でお過ごしでしょうか。   eIQ Time Series Studio (TSS) を使用している場合は、FRDM-MCXW71 からプロジェクトを移植することをお勧めします。eIQ TSSで公式にサポートされているターゲットであり、KW45ともソフトウェア互換性があります。両デバイスは同じCortex-M33コアアーキテクチャと似たメモリプロファイルを共有しているので、生成されるライブラリはあなたのハードウェアにかなり近いはずです。 FRDM-MCXN947のようにハードウェアプロファイルが大きく異なるデバイスをポーティング対象として使用する場合、両デバイス間の利用可能なRAMの違いや、MCXN947特有のNPU加速モデルの生成などにより互換性のないモデルを生成するリスクがあります。 お役に立てば幸いです！ よろしくお願いします、 ソフィア。