ITS Device ID for PCI devices on LX2160A Hello, I am using the Honeycomb LX2 board which uses the LX2160A chip. I have inspected the uboot and linux code and found that in uboot, each PCI BDFs (bridges and devices) are assigned a stream ID that is put into msi-map in the dtb.  I assume that Linux uses this stream ID as the ITS device ID for each PCI BDF though when I inspected the Linux code, drivers/irqchip/irq-gic-v3-its-pci-msi.c, the ITS specific deviceID seems to be just the RID. On the system that I am working on, the ITS device ID of the BDF is the stream ID of the PCI-PCI bridge upstream. Also, the ITS device ID of each port on a 2 port NIC card is the same. Is this the same case on Linux? Can someone help me confirm how the ITS device ID for PCI devices is calculated on Linux and if 2 ports of a NIC card should share the same ITS device ID? If not, what could have been possibly missing on my system? Re: ITS Device ID for PCI devices on LX2160A I found this discussion helpful. Working with ITS Device IDs on the LX2160A can be tricky, especially when dealing with PCI interrupt routing and configuration details. While researching similar technical topics I also came across Citrus Court Resources which offers well organized public record information. Thanks for sharing this and it’s always useful to see practical insights from others tackling the same hardware. Re: ITS Device ID for PCI devices on LX2160A The discussion around ITS Device IDs for PCI devices on the LX2160A is very informative, especially for anyone working with interrupt translation and embedded systems. While researching related technical documentation I also found Bibb Court Clerk to be a useful resource for accessing organized public information. Thanks for sharing these insights and they make a complex topic much easier to understand and explore further. Re: ITS Device ID for PCI devices on LX2160A Please address your new problem in a new thread. Thanks Re: ITS Device ID for PCI devices on LX2160A I have a more HW issue that I hope you can help me with. From debugs, it looks like it mgiht be the PCI-to-PCI Bridge Device that has been sending the Message Signaled Interrupts instead of the PCI devices causing me to see wrong ITS Device ID. Could there be any settings in the PCI config registers that may cause this to happen? Thanks, Re: ITS Device ID for PCI devices on LX2160A Please refer to the following update Here is my understanding: 1. The PCIe device generates an interrupt message including its Requester ID (RID). 2. The ITS receives this message and uses the RID to look up the corresponding StreamID. 3. The ITS then translates this information into an appropriate interrupt message for the interrupt controller. So more specifically, RID, which is composed of BDF, is used by ITS to manage and translate interrupts The StreamID, derived from the same BDF as the RID, is used by the SMMU to manage and translate DMA operations. Re: ITS Device ID for PCI devices on LX2160A Please refer to the following update from the AE team. Those questions are more about linux, so customer can find information how MSI assignment behind PCI-PCI bridge in Documentation/PCI/msi-howto.rst. Re: ITS Device ID for PCI devices on LX2160A Thanks for looking into this. Is there any relationship between the ITS device ID and the stream ID that is programmed into the LUT entries that is mapped to the BDF? Re: ITS Device ID for PCI devices on LX2160A Discussing with the AE team. Re: ITS Device ID for PCI devices on LX2160A Device ID handling for ITS on the LX2160A can definitely be tricky, especially when working with different PCI configurations. While researching similar topics I also came across useful property data through Watauga Property Assessment which was well organized. Thanks for sharing this information and it’s always helpful to see practical discussions on complex hardware behavior.

Modbus RTU通信エラー 私はMC9S08JM60用のMODBUS RTU保持レジスタを読み取るためのコードを書いています。私は15個の保持レジスタを読み取っており、それによって35バイトのフレームが得られます。つまり、各バイトごとに1回の割り込みを受けることが期待されていますが、フレームの最初のバイトは1回、次の割り込みは次のフレームの最初のバイトに対してです。SO、残りの34バイトを失うことになります。これに関して何かご意見があればお聞かせください。 コードスニペットを添付します。 Re: Modbus RTU communication error こんにちは、 @An95さん 投稿ありがとうございます！ S08にModbus RTUのドキュメントは存在します。 しかし、あなたが直面している問題はRDRFをクリアしていないことに関係している可能性があります。 RDRF（受信データレジスタ満杯）フラグは、SCI1S1を読み取った後にSCI1Dを読み取った場合にのみクリアされます。ISRでSCI1Dが読み取れない場合、割り込みは一度発生し、その後レシーバが停止します。 14.2.4を参照MC9S08JM60シリーズデータシートのSCIステータスレジスタ1（SCIxS1）。 コードがフラグを正しくクリアしていることを確認してください。 BR Re: Modbus RTU communication error こんにちは、 @carlos_o さん。 ご回答ありがとうございます。 RDRFフラグは、割り込みサービスルーチンのコールバック関数に入るとクリアされます。35バイトのフレームは、単一の割り込みで送られてきます。35バイトのバッファを使用しても、フレーム全体を読み込むことができません。 この件に関して、ご意見をお聞かせください。 BR Re: Modbus RTU communication error 実装をベアメタルコードに変更しましたが、それでも1バイトしか受信できません。 ご意見をお聞かせください。 Re: Modbus RTU communication error こんにちは、 @An95さん SCIはRDRFがトリガーされるたびに1バイトしか受信できませんでした。つまり、送信する35バイトを読み取るために35回の割り込みをトリガーする必要があります。 14.3.3章「レシーバ機能説明」を参照すると良いでしょう SCIモジュールには1つのSCIデータレジスタ(SCIxD)しかなく、毎回8ビットを節約できます。

FS6500 IO2_3/FCCU障害におけるデバッグモードと通常モード間の動作の不一致 こんにちは！   FS6500のIO2_3ピンはMCU FCCUに接続されています。   デバッグモードでは、FCCUの障害が1回発生すると、即座にリセットされます。   通常動作モードでは、FCCUの障害が1回発生すると、SBCはディープフェイルセーフ（DFS）モードに移行します。 この行動が予想されるものかどうか確認してもらえますか? 私の理解では、IO2_3の障害が発生すると、障害エラーカウンタが増加します。セーフティ応答(RSTBパルス、FS0Bアサーション、またはDFS遷移)は、フォールトエラーカウンターが設定済み閾値(3または6)を超えた場合にのみ行われます。 FS6500開発キット-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、ピーターさん。 ご説明いただき、ありがとうございました。   もう一つ質問があります。   FS6500のデータシートとRMを徹底的に検索しましたが、FCCUフォルトによって引き起こされるセーフティメカニズム戦略や対応するIMPACTレジスタ構成についてのドキュメントIO2_3ほとんど見当たりません。 以前は、故障IO2_3 Fault Error Counterが増加し、カウンターが閾値に達した後にセーフティ対策が適用されると思っていました。あなたの返信によると、IO2/IO3の故障がセーフティレスポンスを直接トリガーします。   マニュアルのどの章でIO2/IO3の直接セーフティ反作用の設定が説明されているか教えていただけますか? よろしくお願いいたします。 Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 この挙動は、SBCが両方のテストで同じ動作状態でない場合に予想されます。 以下の点を区別してください。 MCUのデバッグモード、例えばMPCデバイスに接続されたデバッガー、 FS6500のデバッグモードは、FS6500のDEBUGピンを介して起動します。 FS6500がデバッグモードの場合、ウォッチドッグは内部的に動作しますが、リセットピンやフェイルセーフピンをアサートすることによってデバイスの動作に影響を与えることはありません。したがって、デバッグ中に観察される挙動は、単独または通常の動作とは異なる場合があります。このモードは、SBCがシステムを継続的にリセットすることなくソフトウェアデバッグを可能にすることを目的としています。 通常動作時、FS6500フェイルセーフ状態機械は設定されたセーフティ入力や反応を監視します。IO_2/IO_3がMCU FCCUエラー出力監視に使用される場合、SBCはFCCUフォルトを検出し、設定されたリアクションを実行することができます。例えば、構成に応じてFS0B/RSTBのアサーションなどです。 したがって、デバッグモードとスタンドアロンモードの違いは必ずしもMCUのFCCUの問題ではありません。これはおそらくFS6500がデバッグモードに入っているか、両CASE間のSBC初期化・構成の違いが原因です。 障害エラーカウンタは、通常、ウォッチドッグ監視やフェイルセーフ状態機械処理などのメカニズムに関連付けられています。FCCUが報告したセーフティクリティカルな故障は、カウンタが閾値に達するまで蓄積されるのではなく、直接設定された反応をトリガーすべきです。 したがって、即時のセーフティ応答の観察された挙動は意図されたセーフティ概念と整合しています。 よろしくお願いいたします。 ピーター Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 重要な点は、FS6500はIO2/IO3 FCCUの監視を、他のほとんどの故障源とは異なる方法で処理するという点です。 この説明はFCCUの故障反応(IMPACT)表には記載されておらず、代わりにFS6500のフェイルセーフ故障マネジメントドキュメントに記載されています。 [[ ## completed ##]] FS6500のドキュメントによると、IO_23エラー検出(FCCU)は、常にフォールトエラーカウンターを増加させ、設定できないフォールトソースの一つとしてリストされています。ドキュメントでは、設定可能な故障源とは明確に区別されています。 したがって、IO2/IO3障害時に観測される動作は、設定可能なフェイルセーフ反応に使用されるIMPACTレジスタの設定のみによって制御されるわけではありません。IO2/IO3 FCCUモニターは、SBCの専用FCCU監視パスの一部であり、フェイルセーフ状態マシンによって処理されます。 確認すべき関連セクションはFS6500のドキュメント章 "故障エラーカウンター" で、以下のように記載されています。 [[ ## completed ##]] IO_23エラー検出（FCCU）は、障害エラーカウンタをインクリメントします。 この動作は設定変更できません。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html よろしくお願いいたします。 ピーター

Modbus RTU communication error I am writing code for MC9S08JM60 to read MODBUS RTU holding registers. I am reading 15 holding registers which gives me a 35 byte frame. So i am expected to get 1 interrupt for each byte but i am getting 1 interrupt for the first byte of the frame and next interrupt is for the first byte of the next frame. So I am losing the rest 34 bytes. Please provide any input for this. I am attaching my code snippets. Re: Modbus RTU communication error Hi @An95  Thank you for your post! There is any documentation of Modbus RTU with the S08. But the issue you are facing could be related to not clear the RDRF. The RDRF (Receive Data Register Full) flag is cleared only by reading SCI1D after reading SCI1S1. If SCI1D is not read in the ISR, the interrupt fires once and then the receiver stalls. Refer to 14.2.4 SCI Status Register 1 (SCIxS1) of the MC9S08JM60 Series Data Sheet. Make sure your code is clearing the flag correctly. BR Re: Modbus RTU communication error Hi @carlos_o , Thank you for your response. The RDRF flag is cleared when it enters the callback function of the interrupt service routine. The 35 byte frame is coming in a single interrupt. If I take a buffer of 35 bytes even then i am not able to read the whole frame. Please share your input regarding this. BR Re: Modbus RTU communication error I have changed my implementation to bare metal code still i am receiving only 1 byte. Please share any input. Re: Modbus RTU communication error Hi @An95  The SCI only could receive 1 byte each time RDRF is trigger. So, you will need to trigger 35 interrupts to read the 35 bytes you are sending.  You could refer to the chapter 14.3.3 Receiver Functional Description The SCI module only has one SCI Data Register (SCIxD) that could save 8 bits each time. 

S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hello, I am bringing up a battery-management application on an S32K344 (172-pin MQFP) custom board whose SPI wiring follows the NXP RD33772C14EVM reference design. I am using S32 Design Studio 3.5 with RTD 3.0.0 (the Platform, Port and Spi modules all report SW version 3.0.0) and the FS26 SBC CDD 2.0.0 (Sbc_fs26). My starting point is the Sbc_fs26_example_HLD example for S32K344. In my system LPSPI0 is reserved for a future two-channel daisy-chain and the other SPI instances are already in use, so the FS26 SBC has to run on LPSPI4. Following the RD33772C14EVM schematic, I routed the four LPSPI4 signals to the same pads the reference design uses: lpspi4_pcs0 on PTB8, lpspi4_sout on PTB9, lpspi4_sck on PTB10 and lpspi4_sin on PTB11. On the peripheral side I set the SPI physical-unit mapping to LPSPI_4, left SpiHwUnit at CSIB0, and enabled the LPSPI_4 peripheral-clock gate in the Mcu component. After running "Update Code" and building, the compiler stops with errors in the generated file generate/src/Siul2_Port_Ip_VS_0_PBcfg.c. The generator has produced an assignment with no right-hand side: ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: error: expected expression before ',' token 118 | .slewRateCtrlSel = , The same empty .slewRateCtrlSel = , appears at lines 158, 198 and 238 — one for each of the four LPSPI4 pins. If I manually fill those four lines with PORT_SLEW_RATE_NOT_AVAILABLE, the build gets a little further and then fails the same way on .inputMuxReg = { (empty initializer, "ISO C forbids empty initializer braces"). In other words, the pin-configuration structures for these four pads are generated with empty fields that are not valid C. When I look at the Pins tool "Routing Details" for PTB8–PTB11, the Slew Rate Control column (and the Input Filter column) shows n/a, and selecting the Slew Rate cell shows the tooltip: "The selected pin does not support the configuration of this feature. Selects the slew rate control." So these particular pads simply have no slew-rate-control hardware. My understanding is that in that case the generator should emit PORT_SLEW_RATE_NOT_AVAILABLE (that value does exist in the Siul2_Port_Ip_PortSlewRateControl enum on this device), the same way it uses *_NOT_AVAILABLE values for other unsupported pad features — but instead it emits nothing, which breaks the build. What convinces me this is a tool/driver problem rather than a wrong pin choice is that NXP's own LVBMS_RD_Bring_up_Example uses the exact same four LPSPI4 pads (PTB8/PTB9/PTB10/PTB11) for the FS26 SBC and builds cleanly. The only difference I can find between that example and my project is the RTD version: the LVBMS example is built on RTD 2.0.0 (Platform/Port/Spi SW 2.0.0), while my project uses RTD 3.0.0. Same board pinout, same four pins, and the pin electrical features are identical (only direction is set in both). So it really looks like the Siul2_Port_Ip code generation for slew-rate-unsupported pads regressed between RTD 2.0.0 and RTD 3.0.0. My questions: Is this a known issue in RTD 3.0.0, and is there a fixed / patched RTD release? What is the correct, supported way to configure LPSPI4 on PTB8–PTB11 (the RD33772C14EVM pinout) under RTD 3.0.0 so that the Pins tool generates valid code — i.e. slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE and a valid inputMuxReg, instead of empty fields? If there is no configuration-level fix, is editing the generated Siul2_Port_Ip_VS_0_PBcfg.c by hand the only workaround (it is overwritten on every "Update Code"), or is moving the project to Port/RTD 2.0.0 the recommended path? I can attach the full build log, the Pins "Routing Details" screenshot with the tooltip, and a side-by-side of the two projects' module versions if that helps. Thank you, Hyunsik Song Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi VaneB, Thank you very much — that was exactly the problem. The Pins tool had been updated to LPSPI4 (PTB8–PTB11), but the Port component's PortPin entries were still pointing at the original LPSPI0 pads, so the PortPin Pcr (Mscr) values were stale. I updated the four PortPin Pcr values in the Port configuration to match the new pin assignment: PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10 (Pcr 42) SIN → PTB11 (Pcr 43) After running Update Code and rebuilding, the empty .slewRateCtrlSel / .inputMuxReg errors in Siul2_Port_Ip_VS_0_PBcfg.c are gone and the project builds cleanly. I really appreciate the quick and precise answer — it saved me a lot of time. Marking this as the solution. Best regards, Hyunsik Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi @hyunsiksong  This issue is not related to the RTD itself, nor with the code generated by the S32DS Configuration Tools. Instead, it is related to the configurations. In the Port driver configuration within the Peripheral Tool, the values assigned to the PortPin Mscr parameters still correspond to the original project configuration. For example, the project was previously configured to use PTB1 as LPSPI0_PCS0, corresponds to PortPin Mscr = 33. In the updated configuration, however, LPSPI4 is being used and PCS0 has been reassigned to pin 8. Therefore, the corresponding PortPin Mscr value should be 40 instead of 33. Review the PortPin Mscr for all the pins and ensure they match the current pin assignments Updating these values to reflect the new configuration should resolve the issue. BR, VaneB

Modbus RTU 通信错误 我正在编写代码，使 MC9S08JM60 能够读取 MODBUS RTU 保持寄存器。我正在读取 15 个保持寄存器，得到一个 35 字节的帧。因此，我预期每个字节都会收到 1 个中断，但我收到的中断是帧的第一个字节，而下一个中断是下一帧的第一个字节。所以剩下的 34 字节就丢失了。请提供任何意见。 我附上了我的代码片段。 Re: Modbus RTU communication error 嗨@An95 感谢您的帖子！ 是否有关于S08的Modbus RTU文档？ 但您遇到的问题可能与未清除 RDRF 有关。 只有在读取 SCI1S1 之后读取 SCI1D 才能清除 RDRF（接收数据寄存器已满）标志。如果在 ISR 中未读取 SCI1D，则中断触发一次，然后接收器停止运行。 请参阅 14.2.4 节MC9S08JM60 系列数据手册中的 SCI 状态寄存器 1 (SCIxS1)。 请确保你的代码能够正确清除标志位。 BR Re: Modbus RTU communication error 嗨@carlos_o ， 感谢您的回复。 当程序进入中断服务例程的回调函数时，RDRF 标志将被清除。35 字节的帧通过单个中断传入。即使我使用 35 字节的缓冲区，也无法读取整个帧。 请分享您对此的看法。 BR Re: Modbus RTU communication error 嗨@An95 每次触发 RDRF 时，SCI 只能接收 1 个字节。因此，您需要触发 35 次中断才能读取您发送的 35 个字节。 您可以参考第14.3.3 节“接收器功能描述”。 SCI模块只有一个SCI数据寄存器（SCIxD），每次可以保存8位数据。 Re: Modbus RTU communication error 我已经将实现方式改为裸机代码，但仍然只收到 1 个字节。 欢迎提出任何意见。

S32K311 RTD 5.0 - リンカーエラー: .non_cacheable_bss.int_resultsとのオーバーフローおよび重複 こんにちは、NXP チームの皆様、 私は以下の環境を使用してS32K311プロジェクトに取り組んでいます。 MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 問題 当初、プロジェクトは順調にビルディングされていました。 プロジェクトが進むにつれて、ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCLなど、いくつかのRTDドライバを有効化・設定し、アプリケーションに必要なその他のペリフェラルを活用しました。 これらのドライバを統合した後、プロジェクトはリンク段階で以下のエラーで失敗します。 .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status メモリレイアウト デフォルトのリンカスクリプトには、以下のSRAM領域が含まれています。 int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 リンカーは、 .non_cacheable_bssがこのセクションは、割り当てられた int_sram_no_cacheable 領域を約440 バイト超過しています。 質問 複数のRTDドライバがS32K311で有効になっている場合、このメモリ使用は予想されますか? .non_cacheable_bssのサイズを減らすための推奨方法はありますか? リンカースクリプトを修正してint_sram_no_cacheable領域を増やすことは推奨されますか？もしそうなら、S32K311の推奨メモリ配置はどうなっていますか? キャッシュできないセクションに割り当てられるメモリを減らすRTDの設定オプションはありますか? 複数のRTDペリフェラルを統合する際に同じような問題に遭遇した方はいらっしゃいますか? 何かご助言や解決策をご提案いただければ大変ありがたいです。 よろしくお願いします。 Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results こんにちは、 @Esakkiさん 以下のディスカッションThreadは、似たような問題を扱い、有用なトラブルシューティングの提案を提供してくれるので役立つかもしれません。 int_sram_no_cacheable の問題 S32K312のSRAMがオーバーフローする さらに、S32K3のアプリケーションノートには、リンカーファイルやスタートアップコードについてより詳しく説明されており、メモリ領域の変更やカスタマイズ方法も含まれています。 AN14893 : S32K3xx リンカーファイルとスタートアップコード この最後のThreadでは、コード最適化技術に関するいくつかの提案が含まれています。 S32K3xxでAPPのコードを最適化してパフォーマンスを向上させる方法 BR、VaneB

S32K344 RTD 3.0.0：空 .slewRateCtrlSel为 LPSPI4 引脚生成 — 版本失败 你好， 我正在 S32K344（172 引脚 MQFP）定制板上开发一个电池管理应用程序，该板的 SPI 布线遵循 NXP RD33772C14EVM 参考设计。我正在使用 S32 Design Studio 3.5 和 RTD 3.0.0。（平台、端口和 Spi 模块均报告软件版本为 3.0.0）以及 FS26 SBC CDD 2.0.0 (Sbc_fs26)。我的出发点是 S32K344 的 Sbc_fs26_example_HLD 示例。 在我的系统中，LPSPI0 已预留给未来的双通道菊花链，而其他 SPI 实例已被使用，因此 FS26 SBC 必须在 LPSPI4 上运行。按照 RD33772C14EVM 原理图，我将四个 LPSPI4 信号连接到参考设计使用的相同焊盘：lpspi4_pcs0 连接到 PTB8，lpspi4_sout 连接到 PTB9，lpspi4_sck 连接到 PTB10，lpspi4_sin 连接到 PTB11。在外围设备方面，我将 SPI 物理单元映射设置为 LPSPI_4，将 SpiHwUnit 设置为 CSIB0，并在 Mcu 元器件中启用了 LPSPI_4 外围时钟门。 运行“更新代码”并构建后，编译器停止运行，生成的文件 generate/src/Siul2_Port_Ip_VS_0_PBcfg.c 出现错误。生成器生成的赋值语句没有右侧等式： ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: 错误：应在逗号 (,) 前插入表达式 118 | .slewRateCtrlSel=， 同样的空 .slewRateCtrlSel等号出现在第 158、198 和 238 行——分别对应四个 LPSPI4 引脚。如果我手动将这四行填充为 PORT_SLEW_RATE_NOT_AVAILABLE，版本会继续进行下去，然后在 .inputMuxReg 处以相同的方式失败。= {（空初始化器，“ISO C 禁止空初始化器大括号”）。换句话说，这四个焊盘的引脚配置结构生成的字段为空，这不是有效的 C。 当我查看 PTB8–PTB11 的“引脚”工具“布线详情”时，“转换速率控制”列（以及“输入滤波器”列）显示为“n/a”，选择“转换速率”单元格时，工具提示显示：“所选引脚不支持此功能的配置。”选择转换速率控制。所以这些特殊的垫子根本没有转换速率控制硬件。我的理解是，在这种情况下，生成器应该发出 PORT_SLEW_RATE_NOT_AVAILABLE（该值确实存在于此设备的 Siul2_Port_Ip_PortSlewRateControl 枚举中），就像它对其他不支持的 pad 功能使用 *_NOT_AVAILABLE 值一样——但它却什么也没发出，这导致版本失败。 让我确信这是工具/驱动程序问题而不是引脚选择错误的原因在于，NXP 自己的 LVBMS_RD_Bring_up_Example 使用了完全相同的四个 LPSPI4 焊盘（PTB8/PTB9/PTB10/PTB11）来构建 FS26 SBC，并且版本构建顺利。我发现该示例与我的项目之间唯一的区别是 RTD 版本：LVBMS 示例基于 RTD 2.0.0（平台/端口/Spi 软件 2.0.0），而我的项目使用 RTD 3.0.0。电路板引脚排列相同，四个引脚相同，引脚的电气特性也相同（两者仅方向设置不同）。所以看起来，RTD 2.0.0 和 RTD 3.0.0 之间，Siul2_Port_Ip 代码生成对于不支持压摆率的 pad 确实出现了倒退。 我的问题： 这是RTD 3.0.0中的已知问题吗？是否有已修复/已打补丁的RTD版本？ 在 RTD 3.0.0 版本下，配置 PTB8–PTB11（RD33772C14EVM 引脚排列）上的 LPSPI4 的正确且受支持的方法是什么？这样，引脚工具就能生成有效的代码——例如，slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE 和一个有效的 inputMuxReg，而不是空字段？ 如果没有配置级别的修复，手动编辑生成的 Siul2_Port_Ip_VS_0_PBcfg.c 是唯一的解决方法吗（每次“更新代码”都会覆盖它），还是将项目迁移到 Port/RTD 2.0.0 是推荐的方案？ 如果需要，我可以附上完整的构建日志、带有工具提示的引脚“布线详情”屏幕截图，以及两个项目模块版本的并排对比图。 谢谢你， 宋炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 嗨 VaneB， 非常感谢——问题果然出在这里。Pins 工具已更新为 LPSPI4 (PTB8–PTB11)，但Port元器件的 PortPin 条目仍然指向原始的 LPSPI0 焊盘，因此 PortPin Pcr (Mscr) 值已过时。 我已将端口配置中的四个 PortPin Pcr 值更新为与新的引脚分配相匹配： PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10（Pcr 42） SIN → PTB11 (Pcr 43) 运行更新代码并重新构建后，.slewRateCtrlSel 文件为空。/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c 中的错误已消失，项目可以顺利构建。 我非常感谢您快速而准确的答复——这为我节省了很多时间。标记为解决方案。 此致， 炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 你好@hyunsiksong 这个问题与 RTD 本身无关，也与 S32DS 配置工具生成的代码无关。相反，它与配置有关。 在外设工具的端口驱动程序配置中，分配给 PortPin Mscr 参数的值仍然与原始项目配置相对应。例如，该项目之前配置为使用 PTB1 作为 LPSPI0_PCS0，对应于 PortPin Mscr = 33。 然而，在更新后的配置中，使用的是 LPSPI4，并且 PCS0 已重新分配给引脚 8。因此，相应的 PortPin Mscr 值应为 40 而不是 33。 检查所有引脚的 PortPin Mscr，确保它们与当前的引脚分配匹配。更新这些值以反映新的配置应该可以解决问题。 BR，VaneB

Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi!   The IO2_3 pin of FS6500 is connected to the MCU FCCU.   In DEBUG mode, one single FCCU fault trigger leads to an immediate reset.   In Normal operating mode, one single FCCU fault trigger causes the SBC to enter Deep Fail-Safe (DFS) mode. Could you help confirm whether this behavior is expected? My understanding: The IO2_3 fault will increment the Fault Error Counter. The safety responses (RSTB pulse, FS0B assertion or DFS transition) should only take place once the Fault Error Counter exceeds the configured threshold (3 or 6). FS6500 DEVKIT-MPC5744P  Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi Peter, Thanks a lot for your clarification.   I have a further question.   I searched the FS6500 datasheet and RM thoroughly, yet there is little documentation introducing the safety mechanism strategy triggered by IO2_3 FCCU fault, as well as the corresponding IMPACT register configuration. Previously I thought IO2_3 fault will increment the Fault Error Counter, and safety actions take effect after the counter hits the threshold. According to your reply, IO2/IO3 fault triggers safety response directly.   Could you tell me which chapter of the manual covers the configuration of direct safety reaction for IO2/IO3? Best regards Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, This behavior can be expected if the SBC is not in the same operating condition in both tests. Please distinguish between: MCU debug mode, for example debugger attached to the MPC device, and FS6500 debug mode, which is entered through the FS6500 DEBUG pin. When the FS6500 is in debug mode, the watchdog still runs internally, but it does not affect device operation by asserting reset or fail-safe pins. Therefore, the behavior observed during debug can differ from standalone/normal operation. This mode is intended to allow software debugging without the SBC continuously resetting the system. In normal operation, the FS6500 fail-safe state machine monitors the configured safety inputs/reactions. If IO_2/IO_3 are used for the MCU FCCU error output monitoring, then an FCCU fault can be detected by the SBC and the configured reaction can be executed, for example assertion of FS0B/RSTB depending on the configuration. So the different behavior between debug and standalone mode is not necessarily an MCU FCCU issue. It is most likely caused by the FS6500 being in debug mode, or by a difference in the SBC initialization/configuration between the two cases. The Fault Error Counter is typically associated with mechanisms such as watchdog supervision and fail-safe state machine handling. A safety-critical fault reported by the FCCU should trigger its configured reaction directly rather than being accumulated until the counter reaches its threshold. Therefore, the observed behavior of an immediate safety response is consistent with the intended safety concept. Best regards, Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, The key point is that the FS6500 treats IO2/IO3 FCCU monitoring differently from most other fault sources. The description is not located in the FCCU fault-reaction (IMPACT) tables, but rather in the FS6500 fail-safe fault management documentation. According to the FS6500 documentation, IO_23 error detection (FCCU) is listed among the fault sources that always increment the Fault Error Counter and cannot be configured out. The documentation explicitly separates it from the configurable fault sources. Therefore, the behavior observed with an IO2/IO3 fault is not governed solely by the IMPACT register settings that are used for configurable fail-safe reactions. The IO2/IO3 FCCU monitor is part of the dedicated FCCU supervision path of the SBC and is handled by the fail-safe state machine. The relevant section to review is the FS6500 documentation chapter "Fault error counter", which states: IO_23 error detection (FCCU) increments the Fault Error Counter. This behavior is not configurable. https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html Best regards, Peter

MX8-DSI-OLED1 ディスプレイの部品番号とシーケンス。 こんにちは、チームのみなさん。 カスタムボードにはMX8-DSI-OLED1アクセサリーも使用する予定です。 ディスプレイの部品番号と、維持すべき電源順序があれば教えていただけますか? Re: MX8-DSI-OLED1 Display part No and sequence. こんにちは、 どのような情報をお探しですか? MX8-DSI-OLED1A(raydium rm67199)のディスプレイは、タッチ対応のMIPI-DSI OLEDディスプレイです。以下は主な特徴です: • 5.49インチFHD(1080p@60fps)AMOLEDディスプレイ • 16.7 M(RGB*8ビット)表示色 ・タッチスクリーン • 表示用の4レーンMIPI-DSIインターフェース ・タッチおよび制御のためのI2Cインターフェース また、この部分については共有できる情報があまり多くないことにご注意ください。 よろしくお願いいたします。 アルド。 Re: MX8-DSI-OLED1 Display part No and sequence. チームの皆さん、こんにちは。 この件について何か進展はありますか？ Re: MX8-DSI-OLED1 Display part No and sequence. こんにちは、 @AldoGさん これらのレールに電源を入れる際の順序があるかどうかを知りたいです。 VDD_1V8 VEXT_3V3 VDD_5V

i.MX 93のEdgeLock® Secure Enclave(ELE)の使用方法 : PKCS#11経由での暗号鍵の保存と使用 (日本語ブログ) 本記事では、i.MX 93内蔵のEdgeLock® Secure Enclave(ELE)の暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。 PKCS#11は暗号処理において広く使用されているAPIであり、同じく広く使用されているライブラリであるOpenSSLとの統合も可能です。そのためPKCS#11やOpenSSLを使用した認証処理を行うアプリケーション全て(例: Eclipse Mosquitto™ etc.)に対して、アプリケーション側の改造無しで保護機能の適用も可能です。 暗号アクセラレータおよび鍵管理の機能を提供するという点は別記事で紹介しているSE050などのセキュアエレメントとも共通します。 暗号アクセラレータおよび鍵管理の概要、セキュアエレメントとの大まかな比較や使い分けは以下の記事も参照ください。 半導体ハードウェア・セキュリティでよく耳にする機能について解説 (セキュアエレメント、セキュアエンクレーブ、TPM、HSM、TEE、TrustZoneなど) (日本語ブログ) 作業時間: 約55分 (yoctoのビルド除く) pkcs11-tool経由でのELEの使用 : 10分 openssl経由でのELEの使用 : 10分 PKCS#11 URI PEMファイルの作成 : 5分 Azure IoT Hubへのクラウド接続 : 30分 Keita_Nagashima_0-1785473891452.png   動作確認に使用した環境 ハードウェア: FRDM i.MX 93開発ボード (FRDM-IMX93) MicroSDカード32GB (SDカードにイメージを書き込んで使用する場合。16GBでも動作すると思われます) ソフトウェア: Linux BSP Version L6.18.2-1.0.0 ※FRDM-IMX93のwebページにあるビルド済みイメージでは正常に動作しないため、以下を参考にビルドください。 [入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 (日本語ブログ)   私がビルドした際はrepo initおよびimx-setup-release.sh実行時のコマンドに以下を使用しました。 repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-frdm source imx-setup-release.sh -b ./build     EdgeLock® Secure Enclave(ELE)の概要   i.MX 93における「EdgeLock® Secure Enclave(ELE)」は、NXPが提供する暗号アクセラレータ、鍵管理、SoC全体の監視やアクセス権限管理など多数の高度なセキュリティ機能を統合したセキュリティブロックです。   SoC全体の監視やアクセス権限管理という点では代表的な機能としてセキュアブートがあります。i.MX　93のセキュアブートおよびその使用方法に関しては以下の記事を参照ください。 i.MX 93プロセッサ: セキュアブートの署名と認証の仕組みを解説 (日本語ブログ) i.MX 93プロセッサ: セキュアブートの実装方法 - 実践編   本記事では暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。     i.MX Security Middleware(SMW)の概要   NXPはi.MXプロセッサ内蔵のセキュリティハードウェアを制御するためのソフトウェアとしてi.MX SMW(Security Middleware)を提供しています。 GitHub - nxp-imx/imx-smw: i.MX Security Middleware Library · GitHub   SMWはハードウェアに依存しないAPIを提供します。これには後述するPKCS#11のAPIも含みます。 i.MX 93ではELEが内蔵されているため、実際にELEを制御する部分はimx-secure-enclaveが使用されます。 GitHub - nxp-imx/imx-secure-enclave: Secure Enclave Userspace Library · GitHub     PKCS#11の概要 PKCS#11（Public-Key Cryptography Standards #11）は、暗号処理を行うハードウェアやソフトウェア（例：HSM、スマートカード、USBトークンなど）をアプリケーションから統一的に利用するためのAPI仕様です。別名「Cryptoki（クリプトキー）」とも呼ばれます。 PKCS#11を使用するアプリケーションとして、今回はpkcs11-toolを使用します。 imx-smwを含めた関係を図示すると以下のようになります。 PKCS#11を使用するアプリケーション(pkcs11-tool etc.) ↓ (PKCS#11 API経由での使用) imx-smw ↓ imx-secure-enclave ↓ EdgeLock Secure Enclave Hardware     また、以前のOpenSSL経由でのSE050の使用方法の記事では、Plug and Trust Middlewareに含まれるopenssl providerを使用してopenssl経由での使用方法を解説しました。 SMWはopenssl providerを提供しませんが、pkcs11-providerを使用することでopensslからPKCS#11のインターフェースを使用可能なため、openssl経由でのELEの使用も可能です。 GitHub - openssl-projects/pkcs11-provider: A pkcs#11 provider for OpenSSL 3.0+ · GitHub OpenSSL provider非使用時と、imx-smw + PKCSを使用する場合の関係を図示すると以下のようになります。 Provider非使用時はkeyがファイルとしてファイルシステム上に存在し、暗号処理もソフトウェアにより行われます。 imx-smwおよびpkcs11-provider使用時はkeyおよび暗号処理はELEハードウェアにより保護されます。使用するkeyはコード上またはファイルシステム上にあるPKCS#11 URIにより指定します。 ※URI(uri)とは？:  　ハードウェア・セキュリティ・モジュール（HSM）などに安全に保管された秘密鍵や証明書を、ローカルファイルのパスの代わりに指定するための標準化された識別子（URI）です。   note : Plug and Trust MiddlewareもPKCS#11のAPIを提供しています。 画像1.png   pkcs11-tool経由でのELEの使用   使用方法はSMW内のPKCS11-Tool User Guideに記載がありますが、ECDSA署名および検証に絞って一連の流れを説明します。   まず以下コマンドを実行してnvm_daemonを起動します。 nvm_daemonはELEを使用するためにファイルシステム領域を管理するサービスです。 systemctl start nvm_daemon systemctl status nvm_daemon   以下コマンドを実行することで次回起動時に自動で起動するようにもできます。 systemctl enable nvm_daemon   以降のコマンドを簡略化するため、以下コマンドでlibsmw_pkcs11の場所を指定します。 末尾の番号はsmwのバージョンによって変わる可能性があるためインストール済みのものに合わせてください。 export MODULE_PKCS11=/usr/lib/libsmw_pkcs11.so.5   以下コマンドでlibsmw_pkcs11経由で確認可能なトークンを確認します。 pkcs11-tool --module $MODULE_PKCS11 -L   以下の例のような表示がされれば問題なく動作しています。 Available slots: Slot 0 (0x0): Security Middleware Abstraction token label : smw token manufacturer : NXP Semiconductor token model : token flags : login required, PIN pad present, token initialized hardware version : 0.0 firmware version : 0.0 serial num : pin min/max : 0/0 uri : pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw   以下コマンドで利用可能なオブジェクトの一覧を表示します。 最初は何も表示されないはずです。 pkcs11-tool --module $MODULE_PKCS11 --login -O   以下コマンドでECC key pairを生成します。 pkcs11-tool --module $MODULE_PKCS11 \ --login \ --keypairgen \ --key-type EC:prime256v1 \ --id 02 \ --label "MyECCKey" \ --usage-sign \ --allowed-mechanisms "ECDSA-SHA256"   再度オブジェクト一覧を表示すると以下のようにECC key pairが見えるはずです。 Using slot 0 with a present token (0x0) Profile object 250360144 profile_id: CKP_BASELINE_PROVIDER (1) Public Key Object; EC EC_POINT 256 bits EC_POINT: 044104fe4c97a7a4f54702f9fc5740f62c0864e851098dc43cb4c9ba8633421e5bc362cdc559523118bb4fe4281851c051e24a88846a2d774eb3f928595761cf719e90 EC_PARAMS: 06082a8648ce3d030107 (OID 1.2.840.10045.3.1.7) label: MyECCKey ID: 02 Usage: verify Access: none Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=public Private Key Object; EC label: MyECCKey ID: 02 Usage: sign Access: sensitive, always sensitive Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=private   以下コマンドで適当なmessage.txtファイルを生成、それに対して署名の生成及び検証を行うことができます。 echo hello > message.txt pkcs11-tool --module $MODULE_PKCS11 \ --login \ --sign \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --output-file signature.bin pkcs11-tool --module $MODULE_PKCS11 \ --login \ --verify \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --signature-file signature.bin     openssl経由でのELEの使用   同様にECDSA署名および検証に絞って一連の流れを説明します。 前章のpkcs11-tool用の手順によってnvm_daemonの起動及びECC key pairの生成が完了している前提です。   以下の内容のopenssl.cnfを作成します。 末尾のmoduleおよびpkcs11-module-pathの行は、実際のシステムに合わせて変更が必要な可能性があります。 openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect pkcs11 = pkcs11_sect [default_sect] activate = 1 [pkcs11_sect] module = /usr/lib/ossl-modules/pkcs11.so pkcs11-module-path = /usr/lib/libsmw_pkcs11.so.5 activate = 1   以下コマンドで上記設定ファイルをopensslで使用するよう設定します。 export OPENSSL_CONF=<作成したopenssl.cnfの絶対path>   以下コマンドで署名生成及び検証が可能です。 openssl pkeyutl -sign -inkey "pkcs11:object=MyECCKey;type=private" -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     PKCS#11 URI PEMファイルの作成   openssl providerの使用方法では、keyに直接オブジェクト一覧で確認可能なURIを使用しました。   しかしpkcs11-providerのドキュメントの "USE IN OLDER APPLICATIONS (URIs in PEM files)" には、これは新しい方法であり、従来のアプリケーションを使用する場合はこの方法が使用できない場合がある旨記載があります。   実際後述のMosquitto clientでは、openssl 3.0以降を使用する場合、URIを直接指定できないコードとなっていました。   このような場合、CLI tool uri2pem.pyを使用することでURIを含むファイルを生成し、通常の鍵ファイルを指定するのと同じ方法で使用することが可能です。   上記ページからダウンロードしたuri2pem.pyを使用し、以下コマンドでPKCS#11 URIを含むファイルを生成します。 python3 uri2pem.py --out MyECCKey.pem "pkcs11:object=MyECCKey;type=private" 詳細は確認できておりませんが、uri2pem.pyの内容を確認する限りprivate key以外のURIのpemファイルは作成できないようです。 生成された「MyECCKey.pem」を署名時のkeyとして指定することで先ほどと同様の動作が可能です。 openssl pkeyutl -sign -inkey MyECCKey.pem -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     ELE内の鍵を使用したEclipse Mosquitto™ client経由でのAzure IoT Hubへのクラウド接続   生成した鍵を使用してMosquitto clientを使用したAzure IoT Hubへのクラウド接続を試みます。   注: この手順で作成するRootCA証明書はあくまでテスト用です。テスト完了後はAzure IoT Hub上から証明書を削除することを推奨します。   事前に セキュアエレメントSE05xの使用方法 : FRDM-IMX93開発ボード上でのPlug and Trust Middlewareのセットアップ(日本語ブログ) の「Mosquitto clientのビルドとインストール」の章   セキュアエレメントSE05xの使用方法 : Eclipse Mosquitto clientを使用したAzure IoT Hubへの接続(日本語ブログ) の「Azure IoT Hubの作成」の章、   それぞれの手順を行い、Mosquitto clientのインストールおよびAzure IoT Hubの作成を完了させてください。     まずFRDM-IMX93側で以下コマンドを実行しMyECCKeyのpublic keyに対する証明書リクエストを作成、内容を確認します。 openssl req -new -key "pkcs11:object=MyECCKey" -outform PEM -subj /CN=frdmimx93_test -out frdmimx93_test.csr -sha256 openssl req -text -noout -in frdmimx93_test.csr   その後ホストPC側に「frdmimx93_test.csr」を移動し、以下を実行します。 openssl ecparam -genkey -name prime256v1 -out rootCA_key_pair.pem openssl req -new -x509 -subj /CN=rootCA -key rootCA_key_pair.pem > rootCA_cert.cer openssl x509 -req -in frdmimx93_test.csr -days 365 -CA rootCA_cert.cer -CAkey rootCA_key_pair.pem -out frdmimx93_test_cert.cer 作成した「frdmimx93_test_cert.cer」をFRDM-IMX93に戻します。後ほど「MyECCKey.pem」とセットで使用するため、そちらを作成したディレクトリに置きます。 また、Azure IoT Hubにて、作成した「rootCA_cert.cer」の登録、「frdmimx93_test」という名前のデバイスの作成を行います。 手順は以下記事の「Azure IoT Hubへの中間CA証明書の追加」の章を参照ください。 セキュアエレメントSE05xの使用方法 : Eclipse Mosquitto clientを使用したAzure IoT Hubへの接続(日本語ブログ) 注 : 前述のとおりここで登録した証明書はテスト用のため、動作確認後は削除を推奨します。   ここまでの手順を終えるとMosquitto clientを使用してAzure IoT Hubへの接続が可能になります。   以下コマンドを実行します。IOT_HUB_NAMEは適宜変更ください。 export IOT_HUB_NAME=ShinjiIotHubTest export DEVICE_NAME=frdmimx93_test mosquitto_pub -h "${IOT_HUB_NAME}.azure-devices.net" -p 8883 -u "${IOT_HUB_NAME}.azure-devices.net/${DEVICE_NAME}/api-version=2016-11-14" -t "devices/${DEVICE_NAME}/messages/events/" -m '{"mes":"Hello Azure with i.MX93!"}' --capath /etc/ssl/certs/ --cert frdmimx93_test_cert.cer --key MyECCKey.pem -i ${DEVICE_NAME} -d -q 1 以下のような出力が出れば成功です。 Client frdmimx93_test sending CONNECT Client frdmimx93_test received CONNACK (0) Client frdmimx93_test sending PUBLISH (d0, q1, r0, m1, 'devices/frdmimx93_test/messages/events/', ... (34 bytes)) Client frdmimx93_test received PUBACK (Mid: 1, RC:0) Client frdmimx93_test sending DISCONNECT 以下記事の「IoT Hubへ送信されたメッセージの確認とデバイスへのメッセージ送信」の手順を使用するとAzure IoT Hub側のCloud Shellでも受信メッセージを確認できます。 セキュアエレメントSE05xの使用方法 : Eclipse Mosquitto clientを使用したAzure IoT Hubへの接続(日本語ブログ)  ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 本記事では、i.MX 93内蔵のEdgeLock® Secure Enclave(ELE)の暗号アクセラレータおよび鍵管理の機能をPKCS#11経由で使用する方法について解説いたします。 PKCS#11は暗号処理において広く使用されているAPIであり、同じく広く使用されているライブラリであるOpenSSLとの統合も可能です。そのためPKCS#11やOpenSSLを使用した認証処理を行うアプリケーション全て(例: Eclipse Mosquitto™ etc.)に対して、アプリケーション側の改造無しで保護機能の適用も可能です。 暗号アクセラレータおよび鍵管理の機能を提供するという点は別記事で紹介しているSE050などのセキュアエレメントとも共通します。 暗号アクセラレータおよび鍵管理の概要、セキュアエレメントとの大まかな比較や使い分けは以下の記事も参照ください。 半導体ハードウェア・セキュリティでよく耳にする機能について解説 (セキュアエレメント、セキュアエンクレーブ、TPM、HSM、TEE、TrustZoneなど) (日本語ブログ) 作業時間: 約55分 (yoctoのビルド除く) pkcs11-tool経由でのELEの使用 : 10分 openssl経由でのELEの使用 : 10分 PKCS#11 URI PEMファイルの作成 : 5分 Azure IoT Hubへのクラウド接続 : 30分   i.MX Processors Security 日本語ブログ

如何在 i.MX 93 上使用 EdgeLock® 安全隔离区 (ELE)：通过 PKCS#11 存储和使用加密密钥（日语博客） 本文解释了如何通过 PKCS#11 使用i.MX 93 内置的EdgeLock ®安全隔离区 (ELE) 的加密加速器和密钥管理功能。 PKCS#11 是密码学中广泛使用的 API，并且可以与另一个广泛使用的库 OpenSSL 集成。因此，所有使用 PKCS#11 或 OpenSSL 进行身份验证的应用程序（例如 Eclipse Mosquitto ™等）都可以应用保护，而无需对应用程序本身进行任何修改。 它提供加密加速和密钥管理功能，这一点与SE050等安全元件相同，SE050 将在另一篇文章中介绍。 有关加密加速器和密钥管理的概述，以及与安全元件的一般比较和使用指南，请参阅以下文章。 本文解释了半导体硬件安全中常见的特性（安全元件、安全隔离区、TPM、HSM、TEE、TrustZone 等）（日语博客）。 预计时间：约 55 分钟（不包括 Yocto 构建时间） 使用 pkcs11 工具通过 ELE 进行操作：10 分钟 使用 OpenSSL 通过 ELE 运行：10 分钟 创建 PKCS#11 URI PEM 文件：5 分钟 与 Azure IoT 中心的云连接：30 分钟 Keita_Nagashima_0-1785473891452.png   测试环境 硬件： FRDM i.MX 93 开发板 ( FRDM-IMX93 ) 32GB microSD 卡（如果您要将镜像写入 SD 卡并使用它。据说 16GB 的卡也可以。） 软件： Linux BSP 版本 L6.18.2-1.0.0 *FRDM-IMX93 网页上的预构建镜像无法正常工作，请按照以下说明进行构建。 【新手指南】如何构建 Yocto Linux BSP - i.MX FRDM 开发板版（日语博客）   构建时，我在运行 repo init 和 imx-setup-release.sh 时使用了以下命令： repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-frdm source imx-setup-release.sh -b ./build     EdgeLock® 安全隔离区 (ELE) 概述   在 i.MX 93 中，“EdgeLock® 安全隔离区 (ELE)”是一个安全模块，它集成了 NXP 提供的众多高级安全功能，包括加密加速器、密钥管理、整体 SoC 监控和访问权限管理。   安全启动是监控整个SoC并管理访问权限的一项代表性功能。有关i.MX 93中的安全启动及其使用方法，请参阅以下文章。 i.MX 93 处理器：安全启动签名和认证机制详解（日语博客） i.MX 93 处理器：如何实现安全启动 - 实用指南   本文解释了如何通过 PKCS#11 使用加密加速器和密钥管理功能。     i.MX 安全中间件 (SMW) 概述   NXP 提供 i.MX SMW（安全中间件）软件，用于控制 i.MX 处理器内置的安全硬件。 GitHub - nxp-imx/imx-smw：i.MX 安全中间件库 · GitHub   SMW 提供与硬件无关的 API，包括 PKCS#11 API，稍后将对此进行讨论。 由于 i.MX 93 内置了 ELE，因此实际控制 ELE 的部分是 imx-secure-enclave。 GitHub - nxp-imx/imx-secure-enclave：安全隔离区用户空间库 · GitHub     PKCS#11概述 PKCS#11（公钥密码学标准#11）是一个API规范，用于在应用程序中统一使用加密硬件和软件（例如，HSM、智能卡、USB令牌等）。它也被称为“Cryptoki”。 在这个例子中，我们将使用 pkcs11-tool 作为使用 PKCS#11 的应用程序。 imx-smw之间的关系可以表示如下： PKCS#11を使用するアプリケーション(pkcs11-tool etc.) ↓ (PKCS#11 API経由での使用) imx-smw ↓ imx-secure-enclave ↓ EdgeLock Secure Enclave Hardware     此外，在之前一篇关于通过 OpenSSL 使用 SE050 的文章中，我们解释了如何使用 Plug and Trust Middleware 中包含的 openssl 提供程序通过 openssl 来使用它。 SMW 不提供 openssl 提供程序，但可以通过 openssl 使用 ELE，因为可以通过使用 pkcs11-provider 从 openssl 使用 PKCS#11 接口。 GitHub - openssl-projects/pkcs11-provider：适用于 OpenSSL 3.0+ 的 pkcs#11 提供程序 · GitHub 下面图示了不使用 OpenSSL 提供程序与使用 imx-smw + PKCS 之间的关系。 当不使用密钥提供商时，密钥以文件的形式存在于文件系统中，加密由软件执行。 使用 imx-smw 和 pkcs11-provider 时，密钥和加密过程由 ELE 硬件保护。要使用的密钥由代码或文件系统中的 PKCS#11 URI 指定。 什么是URI？ 这是一个标准化的标识符（URI），用于指定安全地存储在硬件安全模块（HSM）或类似设备中的私钥和证书，而不是本地文件路径。   注意：Plug and Trust Middleware 还提供 PKCS#11 API。 画像1.png   通过 pkcs11-tool 使用 ELE   使用说明在 SMW 中的PKCS11 工具用户指南中有描述，但本说明将特别关注 ECDSA 签名和验证过程。   首先，运行以下命令启动 nvm_daemon。 nvm_daemon 是一项管理文件系统空间以供 ELE 使用的服务。 systemctl start nvm_daemon systemctl status nvm_daemon   您还可以通过执行以下命令，将其配置为在下次启动时自动启动。 systemctl enable nvm_daemon   为了简化后续命令，请使用以下命令指定 libsmw_pkcs11 的位置。 末尾的数字可能因 SMW 版本而异，请根据您安装的版本进行调整。 export MODULE_PKCS11=/usr/lib/libsmw_pkcs11.so.5   以下命令将检查可通过 libsmw_pkcs11 验证的令牌。 pkcs11-tool --module $MODULE_PKCS11 -L   如果您看到与以下示例类似的显示，则说明它运行正常。 Available slots: Slot 0 (0x0): Security Middleware Abstraction token label : smw token manufacturer : NXP Semiconductor token model : token flags : login required, PIN pad present, token initialized hardware version : 0.0 firmware version : 0.0 serial num : pin min/max : 0/0 uri : pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw   以下命令将显示可用对象列表。 一开始不应该显示任何内容。 pkcs11-tool --module $MODULE_PKCS11 --login -O   以下命令将生成 ECC 密钥对。 pkcs11-tool --module $MODULE_PKCS11 \ --login \ --keypairgen \ --key-type EC:prime256v1 \ --id 02 \ --label "MyECCKey" \ --usage-sign \ --allowed-mechanisms "ECDSA-SHA256"   如果再次显示对象列表，您应该会看到如下所示的 ECC 密钥对。 Using slot 0 with a present token (0x0) Profile object 250360144 profile_id: CKP_BASELINE_PROVIDER (1) Public Key Object; EC EC_POINT 256 bits EC_POINT: 044104fe4c97a7a4f54702f9fc5740f62c0864e851098dc43cb4c9ba8633421e5bc362cdc559523118bb4fe4281851c051e24a88846a2d774eb3f928595761cf719e90 EC_PARAMS: 06082a8648ce3d030107 (OID 1.2.840.10045.3.1.7) label: MyECCKey ID: 02 Usage: verify Access: none Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=public Private Key Object; EC label: MyECCKey ID: 02 Usage: sign Access: sensitive, always sensitive Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=private   以下命令将生成一个合适的 message.txt 文件，然后您可以生成并验证该文件的签名。 echo hello > message.txt pkcs11-tool --module $MODULE_PKCS11 \ --login \ --sign \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --output-file signature.bin pkcs11-tool --module $MODULE_PKCS11 \ --login \ --verify \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --signature-file signature.bin     通过 openssl 使用 ELE   同样，我们将解释整个过程，重点关注 ECDSA 的签署和验证。 这假设您已经启动了 nvm_daemon 并使用上一章中描述的 pkcs11-tool 程序生成了 ECC 密钥对。   创建一个名为 openssl.cnf 的文件，内容如下： 末尾的 `module` 和 `pkcs11-module-path` 行可能需要根据您的实际系统进行更改。 openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect pkcs11 = pkcs11_sect [default_sect] activate = 1 [pkcs11_sect] module = /usr/lib/ossl-modules/pkcs11.so pkcs11-module-path = /usr/lib/libsmw_pkcs11.so.5 activate = 1   使用以下命令配置 openssl 以使用上述配置文件。 export OPENSSL_CONF=<作成したopenssl.cnfの絶対path>   可以使用以下命令生成和验证签名。 openssl pkeyutl -sign -inkey "pkcs11:object=MyECCKey;type=private" -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     创建 PKCS#11 URI PEM 文件   在使用 openssl 提供程序时，我使用了一个可以直接在对象列表中验证的 URI 作为键。   然而， pkcs11-provider 文档在“在旧应用程序中使用（PEM 文件中的 URI）”部分指出，这是一种新方法，在使用旧应用程序时可能无法使用。   事实上，稍后将讨论的 Mosquitto 客户端的代码会阻止您在使用 openssl 3.0 或更高版本时直接指定 URI。   在这种情况下，您可以使用CLI 工具 uri2pem.py生成包含 URI 的文件，并以与指定常规密钥文件相同的方式使用它。   使用从上述页面下载的 uri2pem.py，通过以下命令生成包含 PKCS#11 URI 的文件。 python3 uri2pem.py --out MyECCKey.pem "pkcs11:object=MyECCKey;type=private" 虽然我还没有能够确认细节，但根据 uri2pem.py 的内容来看，似乎无法为私钥以外的 URI 创建 pem 文件。 通过指定生成的“MyECCKey.pem”作为签名密钥，您可以执行与以前相同的操作。 openssl pkeyutl -sign -inkey MyECCKey.pem -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     使用 ELE 中的密钥，通过 Eclipse Mosquitto ™客户端连接到 Azure IoT 中心云。   我们将尝试使用生成的密钥通过 Mosquitto 客户端建立与 Azure IoT 中心的云连接。   注意：使用此过程创建的根 CA 证书仅用于测试目的。建议在测试完成后从 Azure IoT 中心删除该证书。   提前 如何使用安全元件 SE05x：在 FRDM-IMX93 开发板上设置即插即用中间件（日文博客） “构建和安装 Mosquitto 客户端”这一章节   如何使用安全元件 SE05x：使用 Eclipse Mosquitto 客户端连接到 Azure IoT 中心（日语博客） 在“创建 Azure IoT 中心”这一章中，   按照每个步骤完成 Mosquitto 客户端的安装和 Azure IoT 中心的创建。     首先，在 FRDM-IMX93 端，执行以下命令为 MyECCKey 的公钥创建证书请求并验证其内容。 openssl req -new -key "pkcs11:object=MyECCKey" -outform PEM -subj /CN=frdmimx93_test -out frdmimx93_test.csr -sha256 openssl req -text -noout -in frdmimx93_test.csr   接下来，将“frdmimx93_test.csr”移动到主机，并执行以下操作： openssl ecparam -genkey -name prime256v1 -out rootCA_key_pair.pem openssl req -new -x509 -subj /CN=rootCA -key rootCA_key_pair.pem > rootCA_cert.cer openssl x509 -req -in frdmimx93_test.csr -days 365 -CA rootCA_cert.cer -CAkey rootCA_key_pair.pem -out frdmimx93_test_cert.cer 将创建的“frdmimx93_test_cert.cer”放回FRDM-IMX93上。由于稍后将与“ MyECCKey.pem ”一起使用，请将其放在创建它的同一目录中。 此外，您还需要在 Azure IoT 中心注册创建的“rootCA_cert.cer”文件，并创建一个名为“frdmimx93_test”的设备。 有关说明，请参阅以下文章中的“向 Azure IoT 中心添加中间 CA 证书”部分。 如何使用安全元件 SE05x：使用 Eclipse Mosquitto 客户端连接到 Azure IoT 中心（日语博客） 注意：如上所述，此处注册的证书仅用于测试目的，因此建议在确认其功能后将其删除。   完成这些步骤后，您就可以使用 Mosquitto 客户端连接到 Azure IoT 中心了。   执行以下命令。请根据实际情况更改 IOT_HUB_NAME。 export IOT_HUB_NAME=ShinjiIotHubTest export DEVICE_NAME=frdmimx93_test mosquitto_pub -h "${IOT_HUB_NAME}.azure-devices.net" -p 8883 -u "${IOT_HUB_NAME}.azure-devices.net/${DEVICE_NAME}/api-version=2016-11-14" -t "devices/${DEVICE_NAME}/messages/events/" -m '{"mes":"Hello Azure with i.MX93!"}' --capath /etc/ssl/certs/ --cert frdmimx93_test_cert.cer --key MyECCKey.pem -i ${DEVICE_NAME} -d -q 1 如果看到类似以下的输出，则表示成功。 Client frdmimx93_test sending CONNECT Client frdmimx93_test received CONNACK (0) Client frdmimx93_test sending PUBLISH (d0, q1, r0, m1, 'devices/frdmimx93_test/messages/events/', ... (34 bytes)) Client frdmimx93_test received PUBACK (Mid: 1, RC:0) Client frdmimx93_test sending DISCONNECT 按照以下文章“检查发送到 IoT 中心的消息和向设备发送消息”中的步骤，您还可以在 Azure IoT 中心端的 Cloud Shell 中检查接收到的消息。 如何使用安全元件 SE05x：使用 Eclipse Mosquitto 客户端连接到 Azure IoT 中心（日语博客） ========================= 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。） 本文解释了如何通过 PKCS#11 使用 i.MX 93 内置 EdgeLock® 安全隔离区 (ELE) 的加密加速器和密钥管理功能。 PKCS#11 是密码学中广泛使用的 API，并且可以与另一个广泛使用的库 OpenSSL 集成。因此，所有使用 PKCS#11 或 OpenSSL 进行身份验证的应用程序（例如 Eclipse Mosquitto ™等）都可以应用保护，而无需对应用程序本身进行任何修改。 它提供加密加速和密钥管理功能，这一点与 SE050 等安全元件相同，SE050 将在另一篇文章中介绍。 有关加密加速器和密钥管理的概述，以及与安全元件的一般比较和使用指南，请参阅以下文章。 本文解释了半导体硬件安全中常见的特性（安全元件、安全隔离区、TPM、HSM、TEE、TrustZone 等）（日语博客）。 预计时间：约 55 分钟（不包括 Yocto 构建时间） 使用 pkcs11 工具通过 ELE 进行操作：10 分钟 使用 OpenSSL 通过 ELE 运行：10 分钟 创建 PKCS#11 URI PEM 文件：5 分钟 与 Azure IoT 中心的云连接：30 分钟   i.MX 处理器 安全 日本博客

How to use the EdgeLock® Secure Enclave (ELE) on i.MX 93: Storing and using encryption keys via PKCS#11 (Japanese blog) This article explains how to use the cryptographic accelerator and key management functions of the i.MX 93's built-in EdgeLock ® Secure Enclave (ELE) via PKCS#11. PKCS#11 is a widely used API in cryptography and can be integrated with OpenSSL, another widely used library. Therefore, protection can be applied to all applications that perform authentication using PKCS#11 or OpenSSL (e.g., Eclipse Mosquitto ™ etc.) without any modifications to the application itself . The fact that it provides cryptographic acceleration and key management functions is something it shares with secure elements such as the SE050 , which are introduced in another article. For an overview of cryptographic accelerators and key management, as well as a general comparison and usage guidelines with secure elements, please refer to the following article. This article explains commonly heard features in semiconductor hardware security (Secure Element, Secure Enclave, TPM, HSM, TEE, TrustZone, etc.) (Japanese blog). Estimated time: Approximately 55 minutes (excluding Yocto build) Using ELE via pkcs11-tool: 10 minutes Using ELE via openssl: 10 minutes Creating a PKCS#11 URI PEM file: 5 minutes Cloud connectivity to Azure IoT Hub: 30 minutes Keita_Nagashima_0-1785473891452.png   Environment used for testing Hardware: FRDM i.MX 93 Development Board ( FRDM-IMX93 ) 32GB microSD card (If you are writing an image to an SD card and using it. It is also thought that 16GB will work.) software: Linux BSP Version L6.18.2-1.0.0 *The pre-built image on the FRDM-IMX93 webpage does not work correctly, so please build it using the following instructions. [Beginner's Guide] How to Build Yocto Linux BSP - i.MX FRDM Board Edition (Japanese Blog)   When I built it, I used the following commands when running repo init and imx-setup-release.sh: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-frdm source imx-setup-release.sh -b ./build     Overview of EdgeLock® Secure Enclave (ELE)   In i.MX 93, "EdgeLock® Secure Enclave (ELE)" is a security block that integrates numerous advanced security features provided by NXP, including cryptographic accelerators, key management, overall SoC monitoring, and access rights management.   Secure Boot is a representative feature for monitoring the entire SoC and managing access rights. For information on Secure Boot in i.MX 93 and how to use it, please refer to the following article. i.MX 93 Processor: Explaining the Secure Boot Signature and Authentication Mechanism (Japanese Blog) i.MX 93 Processor: How to Implement Secure Boot - Practical Guide   This article explains how to use cryptographic accelerator and key management functions via PKCS#11.     i.MX Security Middleware (SMW) Overview   NXP provides i.MX SMW (Security Middleware) as software for controlling the security hardware built into the i.MX processor. GitHub - nxp-imx/imx-smw: i.MX Security Middleware Library · GitHub   SMW provides hardware-independent APIs, including the PKCS#11 API, which will be discussed later. Since i.MX 93 has a built-in ELE, the part that actually controls the ELE is imx-secure-enclave. GitHub - nxp-imx/imx-secure-enclave: Secure Enclave Userspace Library · GitHub     Overview of PKCS#11 PKCS#11 (Public-Key Cryptography Standards #11) is an API specification for unified use of cryptographic hardware and software (e.g., HSMs, smart cards, USB tokens, etc.) from applications. It is also known as "Cryptoki". For this example, we will use pkcs11-tool as the application that uses PKCS#11. The relationship including imx-smw can be illustrated as follows: PKCS#11を使用するアプリケーション(pkcs11-tool etc.) ↓ (PKCS#11 API経由での使用) imx-smw ↓ imx-secure-enclave ↓ EdgeLock Secure Enclave Hardware     Furthermore, in a previous article on using SE050 via OpenSSL , we explained how to use it via openssl using the openssl provider included in Plug and Trust Middleware. SMW does not provide an openssl provider, but it is possible to use ELE via openssl because the PKCS#11 interface can be used from openssl by using the pkcs11-provider. GitHub - openssl-projects/pkcs11-provider: A pkcs#11 provider for OpenSSL 3.0+ · GitHub The relationship between not using an OpenSSL provider and using imx-smw + PKCS is illustrated below. When a provider is not used, the key exists as a file on the file system, and encryption is performed by software. When using imx-smw and pkcs11-provider, the key and encryption process are protected by ELE hardware. The key to be used is specified by a PKCS#11 URI located in the code or on the file system. *What is a URI? This is a standardized identifier (URI) used to specify private keys and certificates securely stored in hardware security modules (HSMs) or similar devices, instead of local file paths.   Note: Plug and Trust Middleware also provides a PKCS#11 API. 画像1.png   Using ELE via pkcs11-tool   The usage instructions are described in the PKCS11-Tool User Guide within SMW, but this explanation will focus specifically on the ECDSA signing and verification process.   First, run the following command to start nvm_daemon. nvm_daemon is a service that manages filesystem space for use with ELE. systemctl start nvm_daemon systemctl status nvm_daemon   You can also configure it to start automatically the next time you boot by executing the following command. systemctl enable nvm_daemon   To simplify subsequent commands, specify the location of libsmw_pkcs11 with the following command. The number at the end may vary depending on the SMW version, so please adjust it to match your installed version. export MODULE_PKCS11=/usr/lib/libsmw_pkcs11.so.5   The following command will check the tokens that can be verified via libsmw_pkcs11. pkcs11-tool --module $MODULE_PKCS11 -L   If you see a display similar to the example below, it is working correctly. Available slots: Slot 0 (0x0): Security Middleware Abstraction token label : smw token manufacturer : NXP Semiconductor token model : token flags : login required, PIN pad present, token initialized hardware version : 0.0 firmware version : 0.0 serial num : pin min/max : 0/0 uri : pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw   The following command will display a list of available objects. Nothing should be displayed at first. pkcs11-tool --module $MODULE_PKCS11 --login -O   The following command will generate an ECC key pair. pkcs11-tool --module $MODULE_PKCS11 \ --login \ --keypairgen \ --key-type EC:prime256v1 \ --id 02 \ --label "MyECCKey" \ --usage-sign \ --allowed-mechanisms "ECDSA-SHA256"   If you display the object list again, you should see the ECC key pair as shown below. Using slot 0 with a present token (0x0) Profile object 250360144 profile_id: CKP_BASELINE_PROVIDER (1) Public Key Object; EC EC_POINT 256 bits EC_POINT: 044104fe4c97a7a4f54702f9fc5740f62c0864e851098dc43cb4c9ba8633421e5bc362cdc559523118bb4fe4281851c051e24a88846a2d774eb3f928595761cf719e90 EC_PARAMS: 06082a8648ce3d030107 (OID 1.2.840.10045.3.1.7) label: MyECCKey ID: 02 Usage: verify Access: none Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=public Private Key Object; EC label: MyECCKey ID: 02 Usage: sign Access: sensitive, always sensitive Unique ID: uri: pkcs11:model=;manufacturer=NXP%20Semiconductor;serial=;token=smw;id=%02;object=MyECCKey;type=private   The following command will generate a suitable message.txt file, and then you can generate and verify a signature on it. echo hello > message.txt pkcs11-tool --module $MODULE_PKCS11 \ --login \ --sign \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --output-file signature.bin pkcs11-tool --module $MODULE_PKCS11 \ --login \ --verify \ --id 02 \ --mechanism ECDSA-SHA256 \ --input-file message.txt \ --signature-file signature.bin     Using ELE via openssl   Similarly, we will explain the entire process, focusing specifically on ECDSA signing and verification. This assumes that you have already started nvm_daemon and generated the ECC key pair using the procedure for pkcs11-tool described in the previous chapter.   Create an openssl.cnf file with the following content: The lines for `module` and `pkcs11-module-path` at the end may need to be changed to match your actual system. openssl_conf = openssl_init [openssl_init] providers = provider_sect [provider_sect] default = default_sect pkcs11 = pkcs11_sect [default_sect] activate = 1 [pkcs11_sect] module = /usr/lib/ossl-modules/pkcs11.so pkcs11-module-path = /usr/lib/libsmw_pkcs11.so.5 activate = 1   Use the following command to configure openssl to use the above configuration file. export OPENSSL_CONF=<作成したopenssl.cnfの絶対path>   Signature generation and verification can be done using the following commands. openssl pkeyutl -sign -inkey "pkcs11:object=MyECCKey;type=private" -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     Creating a PKCS#11 URI PEM file   In using the openssl provider, I used a URI that could be directly verified in the object list as the key.   However, the pkcs11-provider documentation , under "USE IN OLDER APPLICATIONS (URIs in PEM files)," states that this is a new method and may not be usable when using older applications.   In fact, the Mosquitto client, which will be discussed later, has code that prevents you from directly specifying a URI when using openssl 3.0 or later.   In such cases, you can use the CLI tool uri2pem.py to generate a file containing the URI and use it in the same way as specifying a regular key file.   Using uri2pem.py downloaded from the above page, generate a file containing the PKCS#11 URI with the following command. python3 uri2pem.py --out MyECCKey.pem "pkcs11:object=MyECCKey;type=private" Although I haven't been able to confirm the details, based on the contents of uri2pem.py, it seems that it's not possible to create pem files for URIs other than private keys. By specifying the generated "MyECCKey.pem" as the signing key, you can perform the same actions as before. openssl pkeyutl -sign -inkey MyECCKey.pem -in message.txt -out sig.bin -digest sha256 openssl pkeyutl -verify -pubin -inkey "pkcs11:object=MyECCKey;type=public" -in message.txt -sigfile sig.bin -digest sha256     Cloud connectivity to Azure IoT Hub via Eclipse Mosquitto ™ client using keys within ELE   We will attempt to establish a cloud connection to Azure IoT Hub using the Mosquitto client with the generated key.   Note: The RootCA certificate created using this procedure is for testing purposes only. It is recommended to delete the certificate from Azure IoT Hub after testing is complete.   In advance How to use Secure Element SE05x: Setting up Plug and Trust Middleware on the FRDM-IMX93 development board (Japanese blog) The chapter "Building and Installing the Mosquitto Client"   How to use Secure Element SE05x: Connecting to Azure IoT Hub using Eclipse Mosquitto client (Japanese blog) In the chapter "Creating an Azure IoT Hub",   Follow each step to complete the installation of the Mosquitto client and the creation of the Azure IoT Hub.     First, on the FRDM-IMX93 side, execute the following command to create a certificate request for the public key of MyECCKey and verify its contents. openssl req -new -key "pkcs11:object=MyECCKey" -outform PEM -subj /CN=frdmimx93_test -out frdmimx93_test.csr -sha256 openssl req -text -noout -in frdmimx93_test.csr   Next, move "frdmimx93_test.csr" to the host PC and execute the following: openssl ecparam -genkey -name prime256v1 -out rootCA_key_pair.pem openssl req -new -x509 -subj /CN=rootCA -key rootCA_key_pair.pem > rootCA_cert.cer openssl x509 -req -in frdmimx93_test.csr -days 365 -CA rootCA_cert.cer -CAkey rootCA_key_pair.pem -out frdmimx93_test_cert.cer Place the created "frdmimx93_test_cert.cer" back onto the FRDM-IMX93. Since it will be used later in conjunction with " MyECCKey.pem ", place it in the same directory where you created it. Additionally, you will register the created "rootCA_cert.cer" file in Azure IoT Hub and create a device named "frdmimx93_test". For instructions, please refer to the "Adding an Intermediate CA Certificate to Azure IoT Hub" section in the following article. How to use Secure Element SE05x: Connecting to Azure IoT Hub using Eclipse Mosquitto client (Japanese blog) Note: As mentioned above, the certificate registered here is for testing purposes only, so it is recommended to delete it after confirming its functionality.   Once you have completed these steps, you will be able to connect to Azure IoT Hub using the Mosquitto client.   Execute the following command. Please change IOT_HUB_NAME as appropriate. export IOT_HUB_NAME=ShinjiIotHubTest export DEVICE_NAME=frdmimx93_test mosquitto_pub -h "${IOT_HUB_NAME}.azure-devices.net" -p 8883 -u "${IOT_HUB_NAME}.azure-devices.net/${DEVICE_NAME}/api-version=2016-11-14" -t "devices/${DEVICE_NAME}/messages/events/" -m '{"mes":"Hello Azure with i.MX93!"}' --capath /etc/ssl/certs/ --cert frdmimx93_test_cert.cer --key MyECCKey.pem -i ${DEVICE_NAME} -d -q 1 If you see output similar to the following, it's a success. Client frdmimx93_test sending CONNECT Client frdmimx93_test received CONNACK (0) Client frdmimx93_test sending PUBLISH (d0, q1, r0, m1, 'devices/frdmimx93_test/messages/events/', ... (34 bytes)) Client frdmimx93_test received PUBACK (Mid: 1, RC:0) Client frdmimx93_test sending DISCONNECT By following the steps in the article below, "Checking messages sent to IoT Hub and sending messages to devices," you can also check received messages in Cloud Shell on the Azure IoT Hub side. How to use Secure Element SE05x: Connecting to Azure IoT Hub using Eclipse Mosquitto client (Japanese blog) ========================= We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This article explains how to use the cryptographic accelerator and key management functions of the i.MX 93's built-in EdgeLock® Secure Enclave (ELE) via PKCS#11. PKCS#11 is a widely used API in cryptography and can be integrated with OpenSSL, another widely used library. Therefore, protection can be applied to all applications that perform authentication using PKCS#11 or OpenSSL (e.g., Eclipse Mosquitto ™ etc.) without any modifications to the application itself . The fact that it provides cryptographic acceleration and key management functions is something it shares with secure elements such as the SE050, which are introduced in another article. For an overview of cryptographic accelerators and key management, as well as a general comparison and usage guidelines with secure elements, please refer to the following article. This article explains commonly heard features in semiconductor hardware security (Secure Element, Secure Enclave, TPM, HSM, TEE, TrustZone, etc.) (Japanese blog). Estimated time: Approximately 55 minutes (excluding Yocto build) Using ELE via pkcs11-tool: 10 minutes Using ELE via openssl: 10 minutes Creating a PKCS#11 URI PEM file: 5 minutes Cloud connectivity to Azure IoT Hub: 30 minutes   i.MX Processors Security Japanese Blog

i.MX8MM eMMC sd3 クロック DSE スルーレート設定 上記のパッド操作設定はリファレンスマニュアルには記載されていません。なぜ、そしてどのようにしてこれらの設定をテスト・トリミングすればよいのでしょうか? Re: i.MX8MM eMMC sd3 clk dse en slew rate setting こんにちは@NLFOHE お元気でお過ごしのことと思います。 実際には、そのパッドはレジスタ名 IOMUXC_SW_PAD_CTL_PAD_NAND_WE_B の下にあります。 Manuel_Salas_0-1785352172806.png MuxモードレジスタはuSDHC3（IOMUXC_SW_MUX_CTL_PAD_NAND_WE_B）として設定する必要があります。 Manuel_Salas_1-1785352244434.png よろしくお願いいたします。 サラス。 Re: i.MX8MM eMMC sd3 clk dse en slew rate setting こんにちは、サラスさん。 休暇期間のため、問題はまだ解決していません。この特定のクロック信号に対してSCCを使うためのアプリケーションノートはありますか?

S32K OTA Rollback 各位好，我想咨询一下，关于S32K3系列的HSE ABSwap OTA回滚机制。我了解到的是如果A区为稳定区，将A区切换到B区，B区如果出现Hardfault或看门狗超时等错误问题，OTA的错误计数器会累减，当错误计数器为0时，程序会认定B区为不稳定区从而切换片区回到A区。请问这个机制是正确的吗？如果不是，那么OTA的回滚机制是怎样的呢？ Re: S32K OTA Rollback 嗨@RootOf3 对于 S32K3 HSE AB Swap，回滚机制不基于 HSE 监控运行时故障，例如 HardFaults 或看门狗 RESET。 HSE 本身并不会根据应用程序运行时行为来判断新激活的应用程序是否稳定。AB 交换执行完毕后，新映像将变为活动状态，通常由用户引导加载程序/应用程序决定更新是否成功或是否应请求回滚。 安全启动也可以用作恢复策略的一部分。如果活动映像的身份验证失败，则可以根据配置的启动流程和客户的软件设计，将启动流程设计为执行备用映像或专用的恢复映像。一旦有效的恢复映像或备用映像正在运行，软件可以在需要时请求另一个 AB 交换。 综上所述，HSE 提供了安全启动、映像认证和 AB 交换的机制，但实际的回滚策略（包括如何检测运行时故障以及系统何时切换回之前的映像）是由用户引导加载程序/应用程序实现的。 此致， Lukas

S32K OTA Rollback Hello everyone, I'd like to inquire about the HSE ABSwap OTA rollback mechanism for the S32K3 series. My understanding is that if partition A is a stable partition, switching from partition A to partition B will cause errors such as Hardfault or watchdog timeout to occur in partition B. The OTA error counter will decrease, and when the error counter reaches 0, the program will consider partition B an unstable partition and switch back to partition A. Is this mechanism correct? If not, what is the OTA rollback mechanism? Re: S32K OTA Rollback Hi @RootOf3  For S32K3 HSE AB Swap, the rollback mechanism is not based on HSE monitoring runtime failures such as HardFaults or watchdog resets. HSE itself does not determine whether the newly activated application is stable based on the application runtime behavior. After the AB Swap is performed, the new image becomes active, and it is typically the responsibility of the user bootloader/application to decide whether the update was successful or whether a rollback should be requested. Secure Boot can also be used as part of the recovery strategy. If authentication of the active image fails, the boot flow can be designed to execute an alternate image or a dedicated recovery image, depending on the configured boot flow and the customer’s software design. Once a valid recovery or alternate image is running, the software can request another AB Swap if needed. So, in summary, HSE provides the mechanisms for Secure Boot, image authentication, and AB Swap, but the actual rollback policy, including how runtime failures are detected and when the system switches back to the previous image, is implemented by the user bootloader/application. Regards, Lukas

私はS32K312を使用しており、HSEファームウェアを使用して新しいNVMキーカタログを作成したいと考えています。 HSEのNVMキーCatlogに64バイトの公開鍵を1つ保存したいのですが、Catlogに書き込みしようとすると、HSE_SRV_RSP_NOT_ALLOWED問題に直面しています(簡単なこと:属性、ライフサイクル依存操作、キーマネジメントなどの制限により、この操作は許可されていません)。  CAN、このCASEの場合、どうすればよいか教えていただけますか? Re: I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware こんにちは、 @Amolniwateさん キーカタログはどのように設定していますか？ また、ユーザー権がある場合、単純鍵は認証されたもののみインポート可能です。スーパーユーザー権限を持っている場合、動作はスロットが空か既にプログラムされているかによって異なります。 空のスロット:シンプルなキーは認証の有無にかかわらずインポート可能です。 空でないスロット:プレーン/暗号化鍵はインポート(上書き)認証のみ可能です。 詳細については、HSE_BファームウェアリファレンスマニュアルRev. 2.7の表47および48を参照してください。 BR、VaneB

我正在使用S32K312，我想使用我的HSE固件创建新的NVM密钥目录。 我想将 1 个 64 字节的公钥存储在 HSE 的 NVM 密钥目录里，但是当我尝试写入目录时，遇到了HSE_SRV_RSP_NOT_ALLOWED 问题（简而言之，由于某些限制（属性、生命周期相关操作、密钥管理等），该操作不被允许）。 请问在这种情况下我应该怎么做？ Re: I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware 嗨@Amolniwate 你们是如何配置密钥目录的？ 此外，如果您拥有用户权限，则只能导入经过身份验证的明文密钥。如果您拥有超级用户权限，则行为取决于插槽是空的还是已被编程： 空槽位：可以导入纯文本密钥，无论是否进行身份验证。 非空槽位：明文/加密密钥只能通过身份验证导入（覆盖）。 有关更多详细信息，请参阅 HSE_B 固件参考手册第 2.7 版中的表 47 和表 48。 BR，VaneB

S32K344EVB-T172: オンボードのOpenSDAデバッガーに接続できません こんにちは、 私はS32K344EVB-T172を使用していますが、オンボードのOpenSDA/PEmicroデバッガに接続できません。 デバッグ用USBケーブルを接続しても、デバッグLEDが点灯せず、オンボードデバッガーがPCに認識されないため、デバッグセッションを開始できない場合があります。 私は既に以下のことを試しました： 複数のUSBデータケーブル 異なるUSBポート ボードをリセットして電源を入れ直す 外部ハードウェアがコネクテッドされていない状態でテストしています 以前にこの問題に遭遇した方はいますか？オンボードのOpenSDAデバッガに関して、推奨される復旧手順、ファームウェアのアップデート、またはハードウェア／ジャンパーのチェック方法はありますか？ よろしくお願いします。 Re: S32K344EVB-T172: Unable to Connect to the Onboard OpenSDA Debugger ご返信ありがとうございます。 はい、PEmicroドライバを最新バージョンに更新しました。以前はEVBのフラッシュとデバッグを正常に行えていましたが、最近、デバッグ用USBを接続してもデバッグLEDが点灯しないため、オンボードのOpenSDAデバッガーが検出されないことがあります。 S32K3X4EVB-T172クイックスタートガイドに従って、ジャンパーが正しく設定されていることも確認しました。追加のチェックやOpenSDAファームウェアの復旧手順が推奨されるか、あるいはハードウェアの問題を示している可能性はありますか? Re: S32K344EVB-T172: Unable to Connect to the Onboard OpenSDA Debugger こんにちは、 @SourabhJ さん PEmicroのドライバは最新バージョンに更新しましたか?以前、EVBの書き換えに成功しましたか？ また、 MCU自動車ボードのクイックスタートの「S32K3X4EVB-T172評価ボードのジャンパー設置」セクションで説明されている通りにジャンパーが設定されているかも確認していただけますか? BR、VaneB Re: S32K344EVB-T172: Unable to Connect to the Onboard OpenSDA Debugger こんにちは、 @SourabhJ さん LEDのD14とD15だけが点灯していないのか、それとも電圧レギュレーターの隣にある3つのLEDもオフなのか確認していただけますか? もしPEMicro MultilinkやSEGGER J-Linkのような外部デバッガにアクセスできるなら、基板のJ12(20ピンCortex Debug)コネクタで接続してみてはどうでしょうか?これにより、S32K344 MCUがオンボードデバッガに依存して正しく応答しているかどうかを確認できます。 また、この問題が起きる前に最後にボードにプログラムされたアプリケーションやファームウェアは何ですか?

导出 S32CT .mex配置到 EB Tresos 您好，NXP技术支持， 是否有办法导出/转换 S32CT 配置 .mex 文件？将文件转换成EB TRESOS可以读取/导入/使用的格式？我需要切换到 EB Tresos，但不想手动转移每个配置项。 我附上了一个示例 .mex 文件。我从我的项目中选取文件作为参考，引用。 Re: Exporting S32CT .mex configuration to EB Tresos 你好@DirkEtzler 遗憾的是，目前还没有自动转换工具或插件可以将 S32DS (.mex) 配置迁移到 EB tresos (.arxml) 格式。 S32 配置工具使用 .mex 文件格式，而 EB Tresos 遵循 .arxml 格式。AUTOSAR 标准在架构和约束方面有很大不同。   建议的方法是使用 .mex 文件在 EB Tresos 中手动重新创建配置。配置和生成的驱动程序代码作为参考，引用。您可以参考Tresos Training 提供的 RTD MCAL 指南来获取一些指导。   如果您在迁移过程中遇到任何问题，请提交您的查询，我们将很乐意为您提供帮助。   此致， 朱利安 Re: Exporting S32CT .mex configuration to EB Tresos 你好@Julián_AragónM ， 感谢您的快速回复。我会遵守规则，遇到问题时再发帖提问。