MC705J1ACDWE 代金引換の確認が必要です ネタバレ （ハイライトして読む） MC705J1ACDWE製品は販売終了（EOL）となりました。この製品のウェハ拡散位置（COD）をご確認いただけますでしょうか。よろしくお願いいたします。 MC705J1ACDWE製品は販売終了（EOL）となりました。この製品のウェハ拡散位置（COD）をご確認いただけますでしょうか。よろしくお願いいたします。 回复： MC705J1ACDWE Need comfirm COD ご返信とご支援ありがとうございます。 さらに、別の情報源から入手した元のラベル情報には「Diffused In:TH」と記載されています。この情報を使って確認することは可能でしょうか？ Re: MC705J1ACDWE Need comfirm COD ご不便をおかけし申し訳ありません。この終末期/廃止型ファミリの部品番号に関する情報は提供できません。 よろしくお願いいたします。 回复： MC705J1ACDWE Need comfirm COD 情報源の確認を手伝ってもらえますか? この問い合わせについて、製品販売代理店にお問い合わせください。これにより、対応するCODを見つけるのに役立ちます。 よろしくお願いいたします。

MC705J1ACDWE Need comfirm COD Spoiler (Highlight to read) MC705J1ACDWE 这个产品已经EOL，请帮忙确认一下此产品的晶圆扩散地（COD），谢谢。 MC705J1ACDWE 这个产品已经EOL，请帮忙确认一下此产品的晶圆扩散地（COD），谢谢。 回复： MC705J1ACDWE Need comfirm COD 感谢您的回复和支持。 另外，我从其他方面拿到一个原厂的标签信息，看到Diffused In:TH,我这边还是可以按照这个进行确认，对吧？ Re: MC705J1ACDWE Need comfirm COD 很抱歉给您带来不便，目前没有关于此停产/已淘汰系列零件编号的信息可以分享。 顺祝商祺！ 回复： MC705J1ACDWE Need comfirm COD 您能帮我们确认一下您的消息来源吗？ 请您联系您的产品代理商以获取有关此询价的更多信息？这样可以帮助您找到对应的货到付款方式。 顺祝商祺！

imx7dがimx6qに依存する理由 最近、ビルドのカーネルサイズを小さくしようとしていたところ、`busfreq-imx.c`が`platsmp.c`に依存していることを発見しました。`scu_base`と`imx_smp_ops`の定義ファイル。 しかし、なぜかimx7dによる「platsmp」コンパイルのサポートはコミットによって削除されています ``` 「ARM: imx: imx7dにSMPサポートを追加」に戻す これはコミット e34645f45805d8308866de7b69f117f554605bb6 を元に戻すものです。 NXPのベンダーツリーでは使用されていません。 署名者: Dong Aisheng 「`」 また、ベンダー固有の busfreq 実装は下記のコミットで追加されていますが、makefile で platsmp を選択していません。 ``` Arm: imx: i.MX7Dのパワーマネージメントサポートを追加 このパッチでは、i.MX7Dのパワーマネージメントサポートが追加され、以下の内容が含まれています。 低消費電力アイドル、FastMixオフでサスペンド、A7-M4 AMP パワー マネージメントサポート。 署名者: Anson Huang [Aisheng: 重複しているimx7d_init_late定義を削除] 署名者: Dong Aisheng [Leo: a2faac398("アセンブラのコマンドラインフラグの代わりに.archディレクティブを使用する")に合わせて更新しました] 署名者: Li Yang 「`」 何か見落としているのでしょうか、それともこれはBSPの隠れたバグなのでしょうか？ 私は6.18.37-2.1.xを使用しています。私のビルドにおけるBSP i.MX7Dual ソフトウェア不具合の疑い Re: why imx7d depends on imx6q こんにちは、 これはソースコードのバグのようです。 以前の設定を使って回避策を試してみて、問題が解決するか試してみることはできますか? よろしくお願いいたします。 Re: why imx7d depends on imx6q はい、今はdefconfigでimx6デバイスを選択するか、下記のパッチを適用する必要があります。 ``` diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile インデックス2F22af122C6e..CDC66BDA1C 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -44,7 +44,7 @@ obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o obj-$(CONFIG_HAVE_IMX_SRC) += src.o obj-$(CONFIG_HAVE_IMX_DDRC) += ddrc.o obj-$(CONFIG_HAVE_IMX_MU) += mu.o -ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),) +ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A)$(CONFIG_SOC_IMX7D_CA7),) obj-$(CONFIG_SMP) += headsmp.o platsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o endif 「`」 次のBSPで修正されると本当に嬉しいです。

フォーマット済みキースロットサイズよりも短いキーをインポートした場合の HSE の動作 こんにちは、 HSE（健康・安全・環境）に関する行動について質問があります。 HSE_SRV_ID_EXPORT_KEYでインポートされる鍵長が、HSE_SRV_ID_FORMAT_KEY_CATALOGSでキーカタログをフォーマットする際に指定された鍵長より小さい場合、その鍵を使った暗号化/復号、MAC生成、署名生成/検証などの暗号操作は信頼できるとみなせるのでしょうか? 例えば、128ビットのAESキーが256ビット用にフォーマットされたAESキースロットにインポートされた場合、そのキーを使ったAES-128の暗号化/復号、CMAC生成、PBKDF2の操作が正しく確実に動作することが期待できますか? 現在、S32K358_HSE_FW_2.40.0を使用しています。また、インポートされたキーがキーカタログのフォーマットで指定されたキー長より短い場合、HSEファームウェアのバージョン間やHSE_B、HSE_M、HSE_H間で挙動が異なるのかも明確にしていただけると助かります。 よろしくお願いします。 Re: HSE Behavior When Importing a Key Shorter Than the Formatted Key Slot Size こんにちは、 @wodudwo さん。 キーグループは、そのグループに定義された最大キーサイズより小さいキーを含むことがあります。これはHSEサービスAPIリファレンスマニュアルのhseFormatKeyCatalogsSrv_t説明に明記されています。 特定のタイプのすべての鍵に対して最大鍵サイズを持つ単一の鍵グループを作るか、異なる鍵サイズごとに複数のグループを作成することができます。2つ目の選択肢は、カタログ容量が限られて多くのキーが必要な場合に好ましい場合があります。なぜなら、無駄なスペースを減らし、利用可能なキーカタログメモリをより効率的に利用できるからです。 この動作は、すべてのHSEファームウェアバージョンおよびHSEモジュールバリアント（B/M/H）で一貫しています。 よろしくお願いいたします。 ルーカス

LPC55S28 ISP_CMD_EN は ISP コマンドを無効にしません こんにちは、 私はCMPAとCFPA設定が付いたLPC55S28 MCUを持っています。以下のコマンドを使用して、Python経由でblhostからこれらの値を直接読み取って取得しました。つまり、これらは実際のMCUから直接来たものです。これはMCUのフルパワーサイクル後のことです。 CMPAデータはUSB経由で読み取られます。 uv run Python -m spsdk.apps.blhost -u 0x3972,0x3333 read-memory 0x0009E400 512 -f cmpa_dump.bin CMPAをyamlにパースし、 UV run Python -m spsdk.apps.pfr parse -f lpc55s28 -t cmpa -b cmpa_dump.bin -o parsed_cmpa.yaml そして、CFPAについても住所は異なるものの同様のことが行われる。私はアドレス0x9DE00からCFPAを読み取りました。これはおそらくスクラッチバージョンだと思います。しかし、スクラッチの場合、CMPA_PROG_IN_PROGRESS がゼロ以外の値を読み取るという点を除けば、ping と pong は一致しています。でも、0x00はピンポンとトンのためです。 以下に、添付されているファイルの概要を示します。詳細は全文ファイルを添付しています CMPA:ピン、DFLT NIDEN = USE_DAP、障害 DEGEN = USE_DAP、無効化 TAPEN = USE_DAP、無効化 ISP_CMD_EN = USE_DAP、無効化 FA_ME_CMD_EN = FIXED_STATE、有効 SEC_BOOT_EN = ENABLE_0 CFPA:PIN、DFLT NIDEN = USE_DAP、障害 DEGEN = USE_DAP、無効化 TAPEN = USE_DAP、無効化 ISP_CMD_EN = USE_DAP、無効化 FA_ME_CMD_EN = FIXED_STATE、有効 私の理解では、これらの設定ではblhostを使用してメモリを読み取ることはできないはずです。CMPA、CFPA、アプリケーションフラッシュ、アプリケーションRAMを読み取れ、DAP認証なしでblhost経由で実行ファイルを全てダンプできます。 質問: 1.ISP_CMD_ENが無効になっていると、内部メモリへの読み書きができないということですか?PFRかアプリケーションメモリのいずれかです。安全な.sbファイルを送信する機能はまだ必要ですブートローダーにファイルを転送する必要がある。 2. ISP_CMD_ENは、ブートローダー経由でUSBから.SBファイルをロードする機能を無効にしますか？ 3. .SBファイルを使用したUSBブートローダーの機能を維持しつつ、ISPコマンドによるメモリへの読み書き機能を無効にするには、どのような設定が必要ですか？ 4. なぜMCUはCMPAやCFPAで無効になっているのに、blhost ISPコマンドを許可しているのでしょうか? こちらのリンク先のフォーラム投稿を読みました。 https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC55-Disable-ISP-and-SWD-to-utilize-code-protection/ta-p/1654157 しかし、設定ではISPが完全に無効になっており、ブートローダーも完全に無効になっています。ISP_CMD_ENが無効になっているにもかかわらず、なぜ私の設定でblhost経由でISPコマンドが許可されているのか、そのフォーラムの投稿には説明がないと思います。 Re: LPC55S28 ISP_CMD_EN not disabling ISP commands こんにちは、 @guitardenver 重要な点は、ISP_CMD_EN はすべての blhost コマンドに対するグローバルな有効/無効ビットではないということです。これは「Debug Mailbox Enter ISP Mode」コマンドでISPモードに入力できるかどうかを制御します。デバイスが別の許可されたブートパスを介してROM ISPに入ると、USB blhostコマンドはROMブートローダーによって個別に処理されます。 1. メモリの読み書き: ISP_CMD_EN を無効にしても、ReadMemory や WriteMemory は無効になりません。これらのコマンドは、保護されていないメモリにもアクセス可能です。 2. SB ファイルのダウンロード: ISP_CMD_EN は ROM ReceiveSBFile コマンドを直接無効にしません。したがって、これはUSB SBファイルの更新を制御するものとして扱うべきではありません。 3. 生のメモリアクセスをブロックしながらSB更新:LPC55S28リファレンス・マニュアルによると、ReadMemoryおよびWriteMemoryコマンドを無効にしつつ、USB ISPをSB更新のために利用可能に保つ設定は現在存在しません。 4. blhost がまだ機能する理由: この動作は、必ずしも CMPA/CFPA 設定が無視されていることを意味するものではありません。デバイスは既にROM ISPに入っているが、ISP_CMD_ENはISPへの別のパスを制御する。 BR ハリー Re: LPC55S28 ISP_CMD_EN not disabling ISP commands こんにちは、ハリーさん。 ISP_CMD_ENの役割を明確にしていただき、またROM ISPハンドラが一度起動されるとコマンドレベルのフィルタリング機能がないことを確認していただき、ありがとうございます。 当初の設計上の前提は、LPC55S28の認証済みROMブートローダーが、セカンダリのフラッシュブートローダーを必要とせずに、USB経由で(署名済みSB2経由)本番現場での更新インターフェースとして機能するというものでした。1コンテナを使わずに。しかし、あなたの返信からすると、USB ROM ISPインターフェースを公開することで、実質的にメモリのバックドアが広く開かれているようです。物理的なUSBアクセス権があれば、誰でも生の読み取りメモリ、書き込みメモリ、フラッシュ消去領域コマンドを発行できます。 Secure Bootは変更されたコードや署名されていないコードの実行を防ぎますが、攻撃者は現場で暗号化されていないフラッシュIPやプローブSRAMをダンプすることが可能です。 それを踏まえ、 NXPがお客様にこれを安全な商用製品にどのように展開することを期待しているのか、いくつか具体的な質問があります。 PRINCE + Open USB ISP: もしアプリケーション全体でPRINCEフラッシュ暗号化を有効にして静止時のIP保護をした場合、 NXPは現場でUSB ISPを有効にしておくことについてどのようなセキュリティ立場を取っていますか? 具体的には、 ROMブートローダー内で内部SRAMへの任意の読み書きアクセスは、鍵を漏らしたりブートロジックを回避したりする現実的な攻撃対象になるのでしょうか?もしそうでなければ、私が取るのはこの方法だと思います。 推奨されるフィールドアップデートアーキテクチャ：露出したUSBポートを介してROM ISPをアクティブにしたままにすることがセキュリティ上のアンチパターンとみなされる場合、 NXPが推奨するフィールドアップデートのアーキテクチャは何ですか？ NXPは、ROM ISPを完全に無効化（ DEFAULT_ISP_MODE = DISABLE）し、ROM IAP APIを使用してSBコンテナを消費するカスタムデュアルバンク/セカンダリブートローダーを実装することを推奨していますか？ Re: LPC55S28 ISP_CMD_EN not disabling ISP commands こんにちは、 @guitardenver 追加のご質問ありがとうございます。AN12283 – LPC55Sxx セキュアブート、特にセクション5、5.6、5.7を参照することをお勧めします。 AN12283では、セキュアブート、ROM ISPのreceive-sb-fileコマンドによるSB2/SB2.1ファームウェアのアップデート、およびPRINCEフラッシュ暗号化の使用方法について説明しています。また、PRINCEキーはオンチップPUFからソフトウェアアクセスできない内部ハードウェアバスを通じて提供されるとも記載されています。 重要な点の1つは、実際のセキュアブートの設定を確認することです。AN12283によると、SEC_BOOT_EN = 00はプレーンイメージを意味し、01、10、11は署名付きイメージを意味します。以前のSPSDK出力でSEC_BOOT_EN = ENABLE_0と表示されていたので、まずはその生の値を確認することをお勧めします。 セキュアブート、SB2.1アップデート、およびPRINCE構成の詳細については、AN12283を参照してください。 LPC55Sxx セキュアブート BR ハリー

why imx7d depends on imx6q Recently while trying to reduce kernel size on my builds i discovered that `busfreq-imx.c` is depending on `platsmp.c` file for definitions of `scu_base and `imx_smp_ops`. But for some reason imx7d support for compiling `platsmp` is removed by commit ``` Revert "ARM: imx: add smp support for imx7d" This reverts commit e34645f45805d8308866de7b69f117f554605bb6. It's not used by NXP vendor tree. Signed-off-by: Dong Aisheng ``` and vendor specific busfreq implementation is added by below commit but it's not selecting platsmp in makefile. ``` ARM: imx: add i.MX7D power management support This patch adds i.MX7D power management support, including low power idle, suspend with FastMix off, A7-M4 AMP power management support. Signed-off-by: Anson Huang [ Aisheng: remove duplicated imx7d_init_late definition ] Signed-off-by: Dong Aisheng [ Leo: updated to align with a2faac398("use .arch directives instead of assembler command line flags" ] Signed-off-by: Li Yang ``` Am i missing something or is this some hidden bug in BSP ? I'm using 6.18.37-2.1.x BSP on my builds   i.MX7Dual Suspected Software Defect Re: why imx7d depends on imx6q Hello, This seems to be a bug in source code. Could you use a previous configuration as a workaround to see if solves the issue? Best regards. Re: why imx7d depends on imx6q Yes right now i either have to select an imx6 device in defconfig or apply the patch below; ``` diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 2f22af122c6e..cdc66bdaba1c 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -44,7 +44,7 @@ obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o obj-$(CONFIG_HAVE_IMX_SRC) += src.o obj-$(CONFIG_HAVE_IMX_DDRC) += ddrc.o obj-$(CONFIG_HAVE_IMX_MU) += mu.o -ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),) +ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A)$(CONFIG_SOC_IMX7D_CA7),) obj-$(CONFIG_SMP) += headsmp.o platsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o endif ``` It would be really nice to have it fixed in next BSP

HSE Behavior When Importing a Key Shorter Than the Formatted Key Slot Size Hello, I have a question regarding HSE behavior. If the key length imported using HSE_SRV_ID_EXPORT_KEY is smaller than the key length specified when formatting the key catalog using HSE_SRV_ID_FORMAT_KEY_CATALOGS, can cryptographic operations using that key, such as encryption/decryption, MAC generation, and signature generation/verification, be considered reliable? For example, if a 128-bit AES key is imported into an AES key slot formatted for 256 bits, can AES-128 encryption/decryption, CMAC generation, and PBKDF2 operations using that key be expected to work correctly and reliably? I am currently using S32K358_HSE_FW_2.40.0. I would also appreciate it if you could clarify whether the behavior differs across HSE firmware versions or between HSE_B, HSE_M, and HSE_H when the imported key is shorter than the key length specified during key catalog formatting. Thank you. Re: HSE Behavior When Importing a Key Shorter Than the Formatted Key Slot Size Hi @wodudwo  A key group can contain a key that is smaller than the maximum key size defined for that group. This is explicitly stated in the HSE Service API Reference Manual in the description of hseFormatKeyCatalogsSrv_t. You can either have a single key group with the maximum key size for all keys of a given type, or create multiple groups for different key sizes. The second option may be preferable when the catalog space is limited and many keys are required, since it can reduce wasted space and use the available key catalog memory more efficiently. This behavior is consistent across all HSE firmware versions and HSE module variants (B/M/H). Regards, Lukas

导入长度小于格式化钥匙槽尺寸的钥匙时，HSE 的行为 你好， 我有一个关于健康、安全和环境行为方面的问题。 如果使用 HSE_SRV_ID_EXPORT_KEY 导入的密钥长度小于使用 HSE_SRV_ID_FORMAT_KEY_CATALOGS 格式化密钥目录时指定的密钥长度，那么使用该密钥进行的加密操作（例如加密/解密、MAC 生成和签名生成/验证）是否可靠？ 例如，如果将一个 128 位 AES 密钥导入到格式化为 256 位的 AES 密钥槽中，使用该密钥的 AES-128 加密/解密、CMAC 生成和 PBKDF2 操作能否正常可靠地工作？ 我目前使用的是 S32K358_HSE_FW_2.40.0。如果导入的密钥长度短于密钥目录格式化期间指定的密钥长度，那么能否说明一下，不同 HSE 固件版本之间，或者 HSE_B、HSE_M 和 HSE_H 之间的行为是否有所不同？ 谢谢！ Re: HSE Behavior When Importing a Key Shorter Than the Formatted Key Slot Size 嗨@wodudwo 密钥组可以包含小于为该组定义的最大密钥长度的密钥。HSE 服务 API 参考手册中 hseFormatKeyCatalogsSrv_t 的描述中明确说明了这一点。 你可以为给定类型的所有键创建一个最大键长键组，也可以为不同的键长创建多个键组。当目录空间有限且需要很多键时，第二种选择可能更可取，因为它可以减少浪费的空间并更有效地利用可用的键目录内存。 所有 HSE 固件版本和 HSE 模块变体（B/M/H）均表现出一致的这种行为。 此致， Lukas

LPC55S28 ISP_CMD_EN 未禁用 ISP 命令 你好， 我有一个 LPC55S28 MCU，附带 CMPA 和 CFPA 设置。我直接通过 python 使用 blhost 读取这些值，命令如下。所以这些数据直接来自实际的MCU。这是在MCU完全断电重启之后的情况。 通过USB接口读取CMPA数据。 UV run Python -m spsdk.apps.blhost -u 0x3972,0x3333 read-memory 0x0009E400 512 -f cmpa_dump.bin CMPA 解析为 yaml，且 UV run Python -m spsdk.apps.pfr parse -f lpc55s28 -t cmpa -b cmpa_dump.bin -o parsed_cmpa.YAML 然后，对于地址不同的 CFPA，情况也一样。我从地址 0x9DE00 读取了 CFPA，我认为这是临时版本。但除了 CMPA_PROG_IN_PROGRESS 读取到非零值之外，ping 和 pong 都匹配。但乒乓球的比赛就0x00了。 以下是附件全部文件的摘要。完整文件附上以获取更多细节 CMPA：PI，DLFT NIDEN = USE_DAP，残疾 DEGEN = USE_DAP，失效 TAPEN = USE_DAP，已停用 ISP_CMD_EN = USE_DAP，失效 FA_ME_CMD_EN = FIXED_STATE，启用 SEC_BOOT_EN = ENABLE_0 CFPA：PIN和DLT NIDEN = USE_DAP，残疾 DEGEN = USE_DAP，失效 TAPEN = USE_DAP，已停用 ISP_CMD_EN = USE_DAP，失效 FA_ME_CMD_EN = FIXED_STATE，启用 据我了解，在这种设置下，我应该无法使用 blhost 读取内存。我可以读取CMPA、CFPA、应用程序闪存和应用程序RAM，我可以通过blhost转储整个可执行文件，而无需DAP认证。 问题： 1.如果 ISP_CMD_EN 被禁用，是否意味着您无法读取和写入内部存储器？可以是 PFR 或应用程序内存。我仍然需要发送安全 .sb 文件的功能。不过，这些文件会被传输到引导加载程序。 2. ISP_CMD_EN 是否会禁用通过引导加载程序经由 USB 加载 .SB 文件的功能？ 3. 我需要进行哪些设置才能保留使用 .SB 文件的 USB 引导加载程序功能，但禁用通过 ISP 命令读取和写入内存的功能？ 4. 为什么我的MCU仍然允许blhost ISP命令，即使CMPA和CFPA已经禁用了该命令？ 我已阅读此链接中的论坛帖子： https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC55-Disable-ISP-and-SWD-to-utilize-code-protection/ta-p/1654157 但是设置中完全禁用了 ISP，这也会完全禁用引导加载程序。我认为那篇论坛帖子并没有解释为什么即使禁用了 ISP_CMD_EN，我的设置仍然允许通过 blhost 发送 ISP 命令。 Re: LPC55S28 ISP_CMD_EN not disabling ISP commands 嗨@guitardenver 关键在于 ISP_CMD_EN 不是所有 blhost 命令的全局启用/禁用位。它控制是否可以通过调试邮箱进入 ISP 模式命令。一旦设备通过另一条允许的启动路径进入 ROM ISP，USB blhost 命令将由 ROM 引导加载程序单独处理。 1. 内存读/写：禁用 ISP_CMD_EN 本身并不会禁用 ReadMemory 或 WriteMemory。这些命令仍然可以访问未受保护的内存。 2. SB 文件下载：ISP_CMD_EN 不会直接禁用 ROM ReceiveSBFile 命令。因此，不应将其视为 USB SB 文件更新的控制手段。 3. 阻止原始内存访问的同时进行 SB 更新：根据 LPC55S28 参考手册，目前没有配置可以在禁用 ReadMemory 和 WriteMemory 命令的同时保持 USB ISP 可用于 SB 更新。 4. 为什么 blhost 仍然有效：这种行为并不一定意味着您的 CMPA/CFPA 设置被忽略。该设备已进入 ROM ISP，而 ISP_CMD_EN 控制进入 ISP 的不同路径。 BR 哈里 Re: LPC55S28 ISP_CMD_EN not disabling ISP commands 嗨，哈里， 感谢您澄清了 ISP_CMD_EN 的作用，并确认 ROM ISP 处理程序一旦进入就缺少命令级过滤。 我们最初的设计假设是，LPC55S28 的认证 ROM 引导加载程序旨在作为生产现场通过 USB（经由签名的 SB2.1容器）进行更新的接口，而无需额外的闪存引导加载程序。然而，从您的回复来看，暴露 USB ROM ISP 接口实际上留下了一个完全开放的内存后门：任何拥有物理 USB 访问权限的人都可以发出原始的读取内存、写入内存和擦除闪存区域的命令。 虽然安全启动可以防止执行修改/未签名的代码，但攻击者仍然可以转储未加密的闪存 IP 或探测现场的SRAM 。 鉴于此，我有一些关于恩智浦希望客户如何在安全的商业产品中部署这项技术的具体问题： PRINCE + 开放式 USB ISP：如果我们启用 PRINCE 闪存加密来保护整个应用闪存中的静态 IP， NXP 对于在现场启用 USB ISP 的网络安全立场是什么？具体来说，在 ROM 启动加载程序内部对内部 SRAM 的任意读/写访问是否会构成实际的攻击面，从而导致密钥泄露或绕过启动逻辑？如果不会，那么我认为我会选择这条路。 推荐的现场更新架构：如果通过暴露的 USB 端口保持 ROM ISP 活动被认为是一种不安全的反模式，那么NXP 推荐的现场更新架构是什么？ NXP 是否建议完全禁用 ROM ISP（ DEFAULT_ISP_MODE = DISABLE ）并使用 ROM IAP API 实现自定义双存储体/辅助引导加载程序来使用 SB 容器？ Re: LPC55S28 ISP_CMD_EN not disabling ISP commands 嗨@guitardenver 感谢您提出的其他问题。我建议参考 AN12283 – LPC55Sxx 安全启动，特别是第 5、5.6 和 5.7 节。 AN12283 记录了安全启动、通过 ROM ISP receive-sb-file 命令进行 SB2/SB2.1 固件更新以及 PRINCE 闪存加密的使用。它还指出，PRINCE 密钥由片上 PUF 通过软件无法访问的内部硬件总线提供。 重要的一点是，要确认你的实际安全启动配置。根据 AN12283，SEC_BOOT_EN = 00 表示明文图像，而 01、10 和 11 表示签名图像。由于您之前的 SPSDK 输出显示 SEC_BOOT_EN = ENABLE_0，我建议您先检查其原始值。 有关安全启动、SB2.1 更新和 PRINCE 配置的详细信息，请参阅 AN12283。 LPC55Sxx 安全启动 BR 哈里

LPC55S28 ISP_CMD_EN not disabling ISP commands Hello,  I have an LPC55S28 MCU with the attached CMPA and CFPA settings. I got these value directly from reading via blhost via python with the commands below. So these came directly from the actual MCU. This was after a full power cycle of the MCU.  CMPA read via USB.  uv run python -m spsdk.apps.blhost -u 0x3972,0x3333 read-memory 0x0009E400 512 -f cmpa_dump.bin CMPA parse into yaml with uv run python -m spsdk.apps.pfr parse -f lpc55s28 -t cmpa -b cmpa_dump.bin -o parsed_cmpa.yaml Then the same thing for CFPA with different address. I read the CFPA from address 0x9DE00, which I think is the scratch version. But the ping and pong match other than the fact that the CMPA_PROG_IN_PROGRESS reads something non-zero for the scratch. But 0x00 for ping and pong. Below is a summary of the full files attached. Full files attached for more details CMPA: PIN, DFLT NIDEN = USE_DAP, DISABLED DEGEN = USE_DAP, DISABLED TAPEN = USE_DAP, DISABLED ISP_CMD_EN = USE_DAP, DISABLED FA_ME_CMD_EN = FIXED_STATE, ENABLED SEC_BOOT_EN = ENABLE_0 CFPA: PIN, DFLT NIDEN = USE_DAP, DISABLED DEGEN = USE_DAP, DISABLED TAPEN = USE_DAP, DISABLED ISP_CMD_EN = USE_DAP, DISABLED FA_ME_CMD_EN = FIXED_STATE, ENABLED From my understanding, with these settings, I should not be able to use blhost to read memory. I can read CMPA, CFPA, application flash, application RAM, I can dump my entire executable via blhost with no DAP authentication.  Questions: 1. If ISP_CMD_EN is disabled, does that mean you can not read and write to internal memory? Either PFR or application memory. I still need the ability to send secure .sb files to the bootloader though.  2. Does ISP_CMD_EN disable the ability to load .SB files via USB over the bootloader? 3. What settings do I need to keep USB bootloader functionality with .SB files, but disable the ability to read and write to memory over ISP commands? 4. Why is my MCU still allow blhost ISP commands even though the CMPA and CFPA have it disabled? I have read the forum post at this link: https://community.nxp.com/t5/LPC-Microcontrollers-Knowledge/LPC55-Disable-ISP-and-SWD-to-utilize-code-protection/ta-p/1654157 But the settings have it completely disable ISP, which disables the bootloader completely. I I don't think that forum post shows why my settings are still allowing ISP commands over the blhost, when the ISP_CMD_EN is disabled.  Re: LPC55S28 ISP_CMD_EN not disabling ISP commands Hi @guitardenver  The key point is that ISP_CMD_EN is not a global enable/disable bit for all blhost commands. It controls whether ISP mode can be entered through the Debug Mailbox Enter ISP Mode command. Once the device has entered ROM ISP through another permitted boot path, USB blhost commands are handled separately by the ROM bootloader. 1. Memory read/write: Disabling ISP_CMD_EN does not by itself disable ReadMemory or WriteMemory. These commands can still access memory that is not otherwise protected. 2. SB file download: ISP_CMD_EN does not directly disable the ROM ReceiveSBFile command. Therefore, it should not be treated as the control for USB SB-file updates. 3. SB update while blocking raw memory access: According to the LPC55S28 reference manual, there is currently no configuration that can keep USB ISP available for SB updates while disabling ReadMemory and WriteMemory commands. 4. Why blhost still works: This behavior does not necessarily mean your CMPA/CFPA settings are being ignored. The device has already entered ROM ISP, while ISP_CMD_EN controls a different path into ISP. BR Harry Re: LPC55S28 ISP_CMD_EN not disabling ISP commands Hi Harry, Thanks for clarifying the role of ISP_CMD_EN and confirming that the ROM ISP handler lacks command-level filtering once entered. Our original design assumption was that the LPC55S28's authenticated ROM bootloader was intended to serve as the production field update interface over USB (via signed SB2.1 containers) without needing a secondary flash bootloader. However, from your reply, it appears that exposing the USB ROM ISP interface effectively leaves a wide-open memory backdoor: anyone with physical USB access can issue raw read-memory, write-memory, and flash-erase-region commands. While Secure Boot prevents modified/unsigned code from executing, an attacker could still dump unencrypted flash IP or probe SRAM in the field. Given that, I have a few specific questions on how NXP expects customers to deploy this in a secure commercial product: PRINCE + Open USB ISP: If we enable PRINCE flash encryption across the entire application flash to protect IP at rest, what is NXP's security stance on leaving USB ISP enabled in the field? Specifically, does arbitrary read/write access to internal SRAM while inside the ROM bootloader present a realistic attack surface for compromising keys or bypassing boot logic? If not, this is the path I think I would take. Recommended Field-Update Architecture: If leaving ROM ISP active over an exposed USB port is considered an insecure anti-pattern, what is NXP's recommended architecture for field updates? Does NXP recommend disabling ROM ISP entirely (DEFAULT_ISP_MODE = DISABLE) and implementing a custom dual-bank / secondary bootloader using the ROM IAP API to consume SB containers? Re: LPC55S28 ISP_CMD_EN not disabling ISP commands Hi @guitardenver  Thanks for the additional questions. I would recommend referring to AN12283 – LPC55Sxx Secure Boot, especially Sections 5, 5.6 and 5.7. AN12283 documents the use of Secure Boot, SB2/SB2.1 firmware updates through the ROM ISP receive-sb-file command, and PRINCE flash encryption. It also states that the PRINCE keys are provided by the on-chip PUF through an internal hardware bus that is not software accessible. One important point is to confirm your actual Secure Boot configuration. According to AN12283, SEC_BOOT_EN = 00 means Plain image, while 01, 10, and 11 mean Signed image. Since your previous SPSDK output showed SEC_BOOT_EN = ENABLE_0, I recommend checking its raw value first. Please refer to AN12283 for the detailed Secure Boot, SB2.1 update, and PRINCE configuration. LPC55Sxx Secure Boot BR Harry

MCALサポートEBに関する問い合わせ こんにちは S32k3144マイクロコントローラのMCALサポートについてお尋ねしたいのでご連絡ください。このデバイスはEB(Elektrobit)の設定ツールによるMCAL実装をサポートしているのか、またはライセンスが必要なのか、ご説明いただけますか? 利用可能なスタックや互換性について、何かドキュメントやアドバイスがあれば大変ありがたいです。 Re: Inquiry regarding MCAL support EB こんにちは、 S32K344 / K314はNXPリアルタイム・ドライバ(RTD)/AUTOSAR MCALでサポートされており、設定やコード生成のためのEB tresos Studioとの統合も含まれています。NXPはRTD/MCALソフトウェアを標準ソフトウェアとして提供しており、本番環境で利用可能で無料で提供されています。 EB tresos Studio自体を使用するには、有効なElektrobitライセンスが必要ですのでご注意ください。EBトレソのライセンス条件はElektrobitが管理しているため、商業利用の詳細についてはElektrobitまたはお近くのNXP担当者にお問い合わせください。 S32K3 RTDパッケージには、MCALドライバ、EB tresosプラグイン、ドキュメント、開発と統合をサポートするサンプルプロジェクトが含まれています。 よろしくお願いいたします。 ピーター

Missing Std_Types.h I have just upgraded to S32DS version 3.5 and have setup my pins and drivers. I have generated the necessary files but when I try and compile I get the following error message: Std_Types.h: No such file or directory This file is included in one of the generated files Port_Ci_Port_Lp.h /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" What am I doing wrong? Version 3.5 feels like a massive backward step from 3.4 which was super easy to use 😞 Andy Re: Missing Std_Types.h just looking for dir like this.  Re: Missing Std_Types.h for anyone who may read this in future: add them mannualy may sovle this problem. Re: Missing Std_Types.h I've had to go back to DS3.4 with SDK RTM 4.0.2 to get something that mostly works as advertised.  However, the more I use the NXP SDK, the more I hate it... Re: Missing Std_Types.h Any updates on this? @ArkAndyFraserdid you manage to solve the problem with the missing Std_Types.h file being included in the generated RTD files? I couldn't find  the Std_Types.h file even in the examples provided by NXP. Re: Missing Std_Types.h 3.6 Didn't improve things either.  These jokers don't bother to regression test.

ADKP保护后的S32K3 AES密钥配置 各位同事好， 我们已在 S32K 平台上启用基于 SHE 的安全启动。此外，我们还通过对 ADKP 密码进行编程来保护 JTAG 接口，并将生命周期推进到OEM。 请问我是否可以将 AES 密钥（密钥目录已针对 AES 密钥进行了调整）重新配置到已启用 ADKP 保护且OEM 中启用了生命周期管理的设备？ 或者我们需要将生命周期设置为IN_FIELD吗？ 另外，请指定要更新的密钥的OWNER 类型应该是什么？ 谢谢！ 布尚 Re: S32K3 AES Key Provisioning after ADKP protection 你好@Bhushan1312 密钥也可以在 OEM_PROD 或 IN_FIELD 生命周期中更新，但这取决于用户权限、主机身份 (HID) 和密钥所有者。 在 HSE 固件参考手册修订版中。2.8，请参见： 表 42. 主要集团所有者 6.2.3.2关键选择 这一部分很重要： “• 如果主机被授予超级用户 (SU) 权限，则目标密钥句柄的所有者必须与主机身份 (HID) 匹配（请参阅执行权限（超级用户与用户））” 如果主机具有用户权限，则目标密钥句柄的所有者必须为 HSE_KEY_OWNER_CUST（如果 LC 为 CUST_DEL），或 HSE_KEY_OWNER_OEM（如果 LC 为 OEM_PROD）。 然后是表 47、48 和 49，它们解释了在将密钥导入空槽或更新密钥时，是否需要根据用户权限进行身份验证和加密。 例如，如果您使用 CUST 拥有的授权密钥提升到超级用户权限，您也可以在 OEM_PROD 中导入或更新 CUST 密钥。 但是，在生命周期推进到 OEM_PROD 之前，您无法导入 OEM 拥有的密钥。那是因为您还没有OEM授权密钥。 此致， Lukas

S32G3におけるKMSの実現可能性 KMS機能はHSEデモアプリケーションでカスタムロジックで実装できますか?それとも HSE_FWTYPE = 9 / HSE_FWTYPE = 22 の使用は必須ですか? Re: Feasibility of KMS in S32G3 こんにちは、 @Pranathi06 投稿ありがとうございます。 デモアプリで言及されているKMSサービスはカスタムHSEのFW使用を目的としており、これがHSE_FWTYPE = 9(22)の理由です。プレミアムソフトに機能が含まれているため、詳細は地元のNXP担当者に問い合わせることをおすすめします(対応できない場合は support.nxp.com を通じてチケットを提出してください)。 BR チェイン  Re: Feasibility of KMS in S32G3 こんにちは、 @Pranathi06 ご返信ありがとうございます。 申し訳ありませんが、貴社のKMS実装がどのような規格/仕様を参照しているのかが不明なため、明確な確認を提供できない可能性があります。ご不便をおかけして申し訳ございません。 私の意見では、まず最新の標準HSE FW APIドキュメント(HSEのFWパッケージから入手可能なキーのインポート/エクスポート/生成など、標準HSEファイアメントでサポートされているすべてのAPI/サービスを含む)を確認し、その後、あなたの暗号スタックやカスタムアプリケーションに基づいて、KMSで定義された全機能が現在の標準HSE FWであるS32G3に基づいて正しく実装可能かどうかを分析することをお勧めします BR チェイン   Re: Feasibility of KMS in S32G3 KMS機能はHSEデモアプリケーション[標準]のカスタムロジックで実装できますか?

技術的実現可能性評価:i.MX8M Pluにおける32ビットアプリケーションおよび32ビットQt GUIのサポート こんにちは、NXP技術サポートチームの皆様、 [プロジェクトの背景] 私たちはi.MX8M Plusプラットフォームをベースにした量産プロジェクトを開発しています。 現在のソフトウェアスタックは以下の通りです: - ターゲットSoC:i.MX8M Plus(Cortex-A53、ARMv8-A 64ビット) - BSP / Yoctoバージョン:Yocto Project 5.0(Scarthgap)/ meta-imx - Linuxカーネル:6.6(AArch64) 【顧客要望】 エンドクライアントから新たな要件が出ました。これは、この64ビットのLinux OS環境上で32ビットLinuxアプリケーションと32ビットQt GUIアプリケーションの両方を動かす必要があるということです(古いプラットフォームからの32ビット依存やコードベースのためです)。 この要件が商業的かつ技術的に実現可能かどうかを評価するために、NXPの公式な立場を以下の点について明確にしていただけますか。 1. 32ビットアプリケーションおよび32ビットQtの実現可能性: NXPは公式に32ビットユーザー空間アプリケーション、特に32ビットQt GUIアプリケーションを、Yocto Multilibやその他の公式メカニズムを介して64ビットのi.MX8M Plusカーネル上で実行することをサポートしていますか? 2. 32ビットハードウェアアクセラレーションおよびQtライブラリの利用可能性: もしこれが可能なら: a) NXPは32ビットユーザー空間GPUアクセラレーションバイナリ(例:EGL/GLES用の32ビット版「imx-gpu-viv」)や、64ビットカーネル上でi.MX8M Plusと互換性のあるVPUバイナリを提供していますか? b) NXPはi.MX8ファミリ上で32ビットQtスタックをビルディングするための公式なYoctoレシピ、BSPサポート、または検証済みの設定を提供しているか? 3. パフォーマンスおよびレンダリングの制限(加速がない場合): i.MX8M Plusに32ビット専用GPUドライバが提供されていない場合、32ビットQtのGUIをソフトウェアレンダリング(例:LinuxFB、Mesa/llvmpipeソフトウェア)で動かすことは、NXPによって商用製品向けに公式に推奨されている、または本番環境対応と見なされているのでしょうか? 4. 公式推奨/解決策: i.MX8M Plus上でハードウェアアクセラレーションによる32ビットQtの動作がサポートされていない場合、NXPの公式声明と、従来の32ビットアプリケーション/Qtをi.MX8M Plusプラットフォームに移行するお客様向けの推奨アーキテクチャソリューションは何でしょうか? NXPからの正式な声明が、お客様向けの公式なエンジニアリングおよびアーキテクチャの基準となります。 お返事をお待ちしております！ ありがとうございます。よろしくお願いします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu こんにちは、 迅速かつ分かりやすいご説明をありがとうございました！ これにより、i.MX 8M Plus BSPの32ビットユーザー空間コンポーネントおよびGPU/マルチメディア加速に関するアーキテクチャ上の境界が完全に明確になりました。 NXPの公式推奨に従い、お客様のQtおよびアプリケーションスタック向けにネイティブAArch64展開を推進します。 改めてサポートありがとうございます!あなたの回答を解決済みとしてマークしました。 よろしくお願いします、 Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu こんにちは@DADAXIN I.mx8mp用のBSPは64ビット版です。AArch64専用にコンパイル・テストされており、Vivante GPUユーザー空間ライブラリ(EGL/OpenGL ES/Vulkan)、VPU、Qt 6(meta-qt6経由で提供)などのコンポーネントをカバーしています。i.MX 8M Plusでハードウェアアクセラレーションを使用した32ビットQtの利用は、BSPリリースの範囲外であり、サポート対象外の構成です。 私たちの推奨方法は、ネイティブのAArch64アプリケーション/Qtとして再コンパイルすることです。 32ビットソリューションが必須の場合は、以下のリンクから当社のプロフェッショナルサービスまでご連絡ください。 https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

技术可行性评估：在 i.MX8M 处理器上支持 32 位应用程序和 32 位 Qt GUI 您好，NXP技术支持团队， 【项目背景】 我们正在基于 i.MX8M Plus 平台开发一个生产项目。 我们目前的软件栈包括： - 目标SoC：i.MX8M Plus（Cortex-A53，ARMv8-A 64位） - 电路板支持包。 / Yocto 版本：Yocto Project 5.0 (Scarthgap) / meta-imx - Linux 内核：6.6 (AArch64) [客户需求] 我们的最终客户提出了一个新的要求：他们需要在 64 位 Linux 操作系统环境中运行 32 位 Linux 应用程序和 32 位 Qt GUI 应用程序（因为存在来自旧平台的遗留 32 位依赖项/代码库）。 为了评估这一要求在商业和技术上是否可行，请您澄清恩智浦对以下几点的官方立场： 1. 32 位应用程序和 32 位 Qt 的可行性： NXP 是否正式支持通过 Yocto Multilib 或任何其他官方机制在 64 位 i.MX8M Plus 内核上运行 32 位用户空间应用程序（特别是 32 位 Qt GUI 应用程序）？ 2. 32 位硬件加速和 Qt 库的可用性： 如果可行的话： a) NXP 是否提供 32 位用户空间 GPU 加速二进制文件（例如，用于 EGL/GLES 的 32 位版本的 `imx-gpu-viv`）和与 64 位内核上的 i.MX8M Plus 兼容的 VPU 二进制文件？ b) NXP 是否提供官方的 Yocto 配方、电路板支持包。支持或经过验证的配置，以便在 i.MX8 系列上构建 32 位 Qt 堆栈（`lib32-qtbase`、`lib32-qtdeclarative` 等）？ 3. 性能和渲染限制（如果没有加速）： 如果 NXP 没有为 i.MX8M Plus 提供 32 位专有 GPU 驱动程序，那么通过软件渲染（例如 LinuxFB、软件 Mesa/llvmpipe）运行 32 位 Qt GUI 是否被 NXP 正式推荐或认为适用于商业产品？ 4. 官方建议/解决方案： 如果不支持在 i.MX8M Plus 上运行硬件加速的 32 位 Qt，NXP 的官方声明和推荐的架构解决方案是什么？该方案适用于将传统 32 位应用程序/Qt 迁移到 i.MX8M Plus 平台的客户。 NXP 的正式声明将作为我们向客户提供的官方工程和架构基准。 期待你的答复！ 感谢并致意 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu 你好， 非常感谢您及时而清晰的解释！ 这完全阐明了 i.MX 8M Plus 电路板支持包。 在 32 位用户空间元器件和 GPU/多媒体加速方面的架构边界。 我们将遵循 NXP 的官方建议，推进为客户的 Qt 和应用程序堆栈部署原生 AArch64。 再次感谢您的支持！我已将您的回复标记为已接受的解决方案。 此致， Re: Technical Feasibility Assessment: Supporting 32-bit Applications and 32-bit Qt GUI on i.MX8M Plu 嗨@DADAXIN 我们为 I.mx8mp 提供的 电路板支持包。 是 64 位版本。它专门针对 AArch64 编译和测试，涵盖 Vivante GPU 用户空间库（EGL/OpenGL ES/Vulkan）、VPU 和 Qt 6（通过 meta-qt6 提供）等元器件。在 i.MX 8M Plus 上使用 32 位 Qt 并启用硬件加速超出了 电路板支持包。版本范围，因此不属于受支持的配置。 我们建议将其重新编译为原生 AArch64 应用程序/Qt。 如果必须使用 32 位解决方案，请点击以下链接联系我们的专业服务团队： https://www.nxp.com/support/support/nxp-engineering-services:SW-SUPPORT B.R

关于 MCAL 支持 EB 的咨询 你好 我写信是为了咨询S32k3144微控制器的MCAL支持情况。请问该设备是否支持通过EB（Elektrobit）配置工具实现的MCAL，我能否将其用于生产环境，还是需要任何许可证？ 如果您能提供有关可用堆栈和兼容性的任何文档或指导，我们将不胜感激。 Re: Inquiry regarding MCAL support EB 你好， S32K344 / K314 受 NXP 实时驱动程序 (RTD) / AUTOSAR MCAL 支持，包括与 EB tresos Studio 集成，用于配置和代码生成。NXP 提供 RTD/MCAL 软件，该软件为标准软件，符合生产使用要求，并且免费提供。 请注意，EB tresos Studio 本身需要有效的 Elektrobit 许可证。EB tresos 的许可条款由 Elektrobit 管理，因此有关商业用途的详细信息，我们建议您联系 Elektrobit 或您当地的 恩智浦代表。 S32K3 RTD 软件包包括 MCAL 驱动程序、EB tresos 插件、文档和示例项目，以支持开发和集成。 顺祝商祺！ Peter

缺少 Std_Types.h 文件 我刚刚升级到 S32DS 版本 3.5，并且已经设置好了引脚和驱动器。 我已经生成了必要的文件，但是当我尝试编译时，出现以下错误信息： Std_Types.h: No such file or directory 该文件包含在生成的文件之一 Port_Ci_Port_Lp.h 中。 /*================================================================================================== * Project : RTD AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : PORT_CI * Dependencies : none * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 2.0.0 * Build Version : S32K1_RTD_2_0_0_D2308_ASR_REL_4_7_REV_0000_20230804 * * Copyright 2020-2023 NXP Semiconductors * * NXP Confidential. This software is owned or controlled by NXP and may only be * used strictly in accordance with the applicable license terms. By expressly * accepting such terms or by downloading, installing, activating and/or otherwise * using the software, you are agreeing that you have read, and that you agree to * comply with and are bound by, such license terms. If you do not agree to be * bound by the applicable license terms, then you may not retain, install, * activate or otherwise use the software. ==================================================================================================*/ #ifndef PORT_CI_PORT_IP_H #define PORT_CI_PORT_IP_H /** * @file Port_Ci_Port_Ip.h * * @defgroup Port_IPL Port IPL * @{ */ #if defined(__cplusplus) extern "C" { #endif /*================================================================================================== * INCLUDE FILES * 1) system and project includes * 2) needed interfaces from external units * 3) internal and external interfaces from this unit ==================================================================================================*/ #include "Std_Types.h" #include "Port_Ci_Port_Ip_Cfg.h" #include "Port_Ci_Port_Ip_Types.h" #include "Port_Ci_Port_Ip_Defines.h" #include "Devassert.h" 我做错了什么？ 3.5 版本感觉比 3.4 版本差远了，3.4 版本用起来超级方便。 😞 安迪 Re: Missing Std_Types.h 我只是在找类似这样的目录。 Re: Missing Std_Types.h 致未来可能读到这篇文章的任何人： 手动添加或许可以解决这个问题。 Re: Missing Std_Types.h 我不得不回退到DS3.4版本，搭配SDK RTM 4.0.2，才能得到一个基本能按预期运行的版本。然而，我越使用NXP SDK，就越讨厌它…… Re: Missing Std_Types.h 这件事有任何进展吗？ @ArkAndyFraser你解决 Std_Types.h 文件缺失的问题了吗？该文件是否包含在生成的RTD文件中？ 我找不到 Std_Types.h 文件。即使在 NXP 提供的示例中，文件也是如此。 Re: Missing Std_Types.h 3.6 情况也没有改善。这些家伙连回归测试都不做。

S32G3中KMS的可行性 能否通过 HSE Demo 应用程序中的自定义逻辑来实现 KMS 功能，还是必须使用HSE_FWTYPE = 9 / HSE_FWTYPE = 22 ？ Re: Feasibility of KMS in S32G3 你好， @Pranathi06 感谢分享。 演示应用程序中提到的 KMS 服务旨在使用自定义 HSE 固件，因此 HSE_FWTYPE = 9(22)。由于它是高级软件中包含的功能，我建议您联系当地的 恩智浦代表（如果无法联系，请通过 support.nxp.com 提交工单）以了解详细信息。 BR 陈银  Re: Feasibility of KMS in S32G3 你好， @Pranathi06 感谢您的回复。 抱歉，我不确定您的KMS实现指的是哪种标准/规范，我可能无法提供明确的确认，给您带来的不便敬请谅解。 依我之见，您首先可以查阅最新的标准 HSE 固件 API 文档（其中包含标准 HSE 固件支持的所有 API/服务，例如密钥导入/导出/生成等，这些内容可在 HSE 固件包中找到），以明确 HSE 固件支持的所有密钥管理服务。然后，根据您的加密协议栈/自定义应用程序，分析您 KMS 中定义的所有功能是否能够基于当前 S32G3 标准 HSE 固件正确实现。 BR 陈银   Re: Feasibility of KMS in S32G3 能否在 HSE Demo 应用程序[标准]中通过自定义逻辑实现 KMS 功能？

Inquiry regarding MCAL support EB hello I am writing to inquire about the MCAL support for the S32k3144 microcontroller. Could you please clarify as this device supports MCAL implementations through EB (Elektrobit) configuration tools can use for my production or need any license? Any documentation or guidance you can provide regarding the available stacks and compatibility would be greatly appreciated. Re: Inquiry regarding MCAL support EB Hello, The S32K344 / K314 is supported by NXP Real-Time Drivers (RTD) / AUTOSAR MCAL, including integration with EB tresos Studio for configuration and code generation. NXP provides the RTD/MCAL software as standard software that is qualified for production use and available free of charge. Please note that EB tresos Studio itself requires a valid Elektrobit license. Licensing terms for EB tresos are managed by Elektrobit, so for commercial usage details we recommend contacting Elektrobit or your local NXP representative. The S32K3 RTD package includes the MCAL drivers, EB tresos plugins, documentation, and example projects to support development and integration. Best regards, Peter