为什么 imx7d 依赖于 imx6q 最近，我在尝试减小版本中的内核大小时发现，`busfreq-imx.c` 依赖于 `platsmp.c`。文件用于定义 `scu_base` 和 `imx_smp_ops`。 但不知何故，imx7d 对编译 `platsmp` 的支持已被提交移除。 ``` 撤销“ARM：imx：为imx7d添加smp支持” 这将撤销提交 e34645f45805d8308866de7b69f117f554605bb6。 NXP 供应商树中未使用此功能。 签字人：董爱生 ``` 下面的提交添加了厂商特定的总线频率实现，但它没有在 Makefile 中选择 platsmp。 ``` Arm：imx：添加 i.MX7D 电源管理单元支持 此补丁增加了对 i.MX7D 电源管理单元的支持，包括 低功耗待机，FastMix 关闭时进入睡眠状态，A7-M4 AMP 电源 管理单元支持。 签字人：Anson Huang [爱生：删除重复的 imx7d_init_late 定义] 签字人：董艾生 [ Leo：已更新以符合 a2faac398 的要求（“使用 .arch 指令而不是汇编器命令行标志” ] 签字人：李阳 ``` 是我遗漏了什么，还是电路板支持包中存在某种隐藏的bug？ 我使用的是 6.18.37-2.1.x 版本。我的版本中使用了电路板支持包。   i.MX7 双核 疑似软件缺陷

MC705J1ACDWE 代金引換の確認が必要です ネタバレ （ハイライトして読む） MC705J1ACDWE製品は販売終了（EOL）となりました。この製品のウェハ拡散位置（COD）をご確認いただけますでしょうか。よろしくお願いいたします。 MC705J1ACDWE製品は販売終了（EOL）となりました。この製品のウェハ拡散位置（COD）をご確認いただけますでしょうか。よろしくお願いいたします。 回复： MC705J1ACDWE Need comfirm COD ご返信とご支援ありがとうございます。 さらに、別の情報源から入手した元のラベル情報には「Diffused In:TH」と記載されています。この情報を使って確認することは可能でしょうか？ Re: MC705J1ACDWE Need comfirm 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 很抱歉给您带来不便，目前没有关于此停产/已淘汰系列零件编号的信息可以分享。 顺祝商祺！

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 ソフトウェア不具合の疑い

フォーマット済みキースロットサイズよりも短いキーをインポートした場合の 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 ハリー

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

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 哈里

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

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 チェイン 

技術的実現可能性評価: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 陈银