在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 First, the chip I used is  MCXN947. I  have  downloaded and installed mcuxpresso-secure-provisioning-26.09-1_amd64-ubuntu26.deb  package in my ubuntu system。 So how to use this software  to  generare a sb formate file which has been signed and encrypted ? I  have watch the video  and  signed and encrypted  the  bin file ,   and write the sb  file  to the  chip sucsessfuly in windows system. Is there have  video to  operate on  ubuntu system?  Is there have the document about the  cmd line  to  signe and encryt  bin file   ? Thanks Re: 在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 Hi @justdomyself  Documentation: https://docs.mcuxpresso.nxp.com/secure/latest/ Chapter describing workflow for MCXN devices: https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#n23x-n24x-n52x-n53x-n54x-n94x-device-workflow Command line support: https://docs.mcuxpresso.nxp.com/secure/latest/08_command_line_operations.html See also  securep.exe print-cli-examples User experience on Ubuntu and Windows are very similar. If you find any problem, refer to Troubleshooting section: https://docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html

MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Ladies and Gentlemen, I am experiencing a reproducible problem with MCUXpresso IDE v25.6 Build 136 on Linux and an LPC-Link2 debug probe. When the LPC-Link2 is connected, it initially appears in DFU mode: 1fc9:000c NXP Semiconductors LPC4330FET180 (device firmware upgrade mode) Linux detects the DFU device correctly. For example: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ver=0100, devnum=19, cfg=1, intf=0, path="1-6", alt=0, name="DFU", serial="ABCD" The important observation is that the LPC-Link2 boot process itself works correctly. Running the LinkServer boot command manually from a terminal successfully boots the probe. It then re-enumerates as: 1fc9:0090 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.460 I can also boot the probe successfully using LinkFlash. However, if I start a debug session with the green Debug button while the LPC-Link2 is still in DFU mode, MCUXpresso IDE fails to boot the probe and reports: No bootable LPC-Link2 found The IDE's pre-launch command is: /usr/local/LinkServer_26.9.130/binaries/boot_link2 The IDE reports: Non-zero return code (1) from pre-launch command: .../boot_link2 and the corresponding dfu_boot invocation reports that no bootable LPC-Link2 was found. I have verified that the same DFU device is still visible from a normal terminal while MCUXpresso IDE is running: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ... If I boot the LPC-Link2 externally first (for example with LinkFlash), the blue Debug button works correctly and I can debug the target normally. I have tested both the original LinkServer version supplied with MCUXpresso IDE 25.6 and LinkServer 26.9.130. The behaviour is the same. I also restored the IDE's original/default LinkServer configuration, with no improvement. Therefore the problem does not appear to be: LPC-Link2 hardware USB enumeration Linux DFU support the LinkServer boot image the LinkServer boot mechanism itself The failure appears to be specifically in the automatic LPC-Link2 boot performed by MCUXpresso IDE as part of the green Debug launch sequence on Linux. As a workaround, I can start LinkFlash, let it boot the LPC-Link2, close LinkFlash, and then use the blue Debug button. This works, but it is obviously not the intended workflow. Has anyone seen this behaviour with MCUXpresso IDE 25.6 Build 136 on Linux? Is there a known fix or patch for the IDE's automatic LPC-Link2 boot procedure? I would particularly like to know whether this is a known IDE issue, since the LPC-Link2 and the LinkServer boot process itself are demonstrably working. Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Thank you. I checked this. My system has: dfu-util 0.11 The MCUXpresso IDE 25.6.136 installation itself does not contain a dfu-util binary, so it appears to use the system version: /usr/bin/dfu-util This is indeed version 0.11. I also checked the forum post you linked. The situation described there looks potentially relevant, since it specifically concerns dfu-util 0.11 and the parsing of the VID:PID returned by dfu-util -l. However, there is one important difference in my case: the same boot_link2 / dfu_boot command works correctly when I run it manually from a terminal. The problem occurs when MCUXpresso IDE invokes boot_link2 as the pre-launch command of the green Debug launch. Could the dfu_boot script included with LinkServer/MCUXpresso IDE 25.6.136 still contain the dfu-util 0.11 parsing problem described in the linked post? That topic is from 2024, is it possible, that this issue still present in 2026? bela@bela-ThinkPad-P70:~ $ find /usr/local/mcuxpressoide-25.6.136 -type f -name 'dfu-util*' -ls bela@bela-ThinkPad-P70:~ $ which dfu-util dfu-util --version /usr/bin/dfu-util dfu-util 0.11 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2021 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ bela@bela-ThinkPad-P70:~ $ Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Hi @jeanvaljean  Thank you for your post! Could you please review the dfu-util version your IDE is using?  Please review the post: Report dfu boot problem to LPC Link2 with lpscrypt under Linux Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Hi @jeanvaljean  Apologize the late reply. Yes, that topic could be affecting due the dfu version is still the same. Please try to implement the patches that are provided in the post I share before and let me know if that resolves the issue. 

用 MIMX8QP6AVUFFAB 替换 MIMX8QM6AVUFFAB 我们能否用 MIMX8QP6AVUFFAB 替换 MIMX8QM6AVUFFAB？ Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB 如果设计不使用 QuadMax 专用的计算/DSP 资源，并且 QP 特定的软件和硬件检查通过，则这种替换是可行的。

MIMX8QM6AVUFFABをMIMX8QP6AVUFFABに交換する MIMX8QM6AVUFFABをMIMX8QP6AVUFFABに置き換えられるか? Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB 代替は、設計がQuadMax専用の計算/DSPリソースを使わず、QP特有のソフトウェアおよびハードウェアチェックに合格した場合に実用的です。

MCUXpresso IDE 25.6 ビルド136 – Linux上でLPC-Link2が自動的に起動されません ご列席の皆様、 Linux上の MCUXpresso IDE v25.6 Build 136 とLPC-Link2デバッグプローブで再現可能な問題が発生しています。 LPC-Link2が接続されると、最初はDFUモードで表示されます: 1fc9:000c NXP Semiconductors LPC4330FET180 (device firmware upgrade mode) LinuxはDFUデバイスを正しく検出します。例えば： $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ver=0100, devnum=19, cfg=1, intf=0, path="1-6", alt=0, name="DFU", serial="ABCD" 重要な点は、 LPC-Link2のブートプロセス自体は正しく動作しているということである。 端末からLinkServerの起動コマンドを手動で実行すると、プローブが正常に起動します。すると、次のように再列挙されます。 1fc9:0090 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.460 また、LinkFlashを使ってプローブを正常に起動することもできます。 しかし、LPC-Link2がまだDFUモードのまま緑色の Debugボタン でデバッグセッションを開始すると、MCUXpresso IDEはプローブの起動に失敗し、次のように報告します: No bootable LPC-Link2 found IDEsの事前発射指令は以下の通りです: /usr/local/LinkServer_26.9.130/binaries/boot_link2 IDEの報告は以下の通りです: Non-zero return code (1) from pre-launch command: .../boot_link2 そして、対応するdfu_bootコマンドの実行結果から、起動可能なLPC-Link2が見つからなかったことが報告されます。 MCUXpresso IDEが稼働している間も、通常の端末から同じDFUデバイスがまだ見えることを確認しました: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ... 例えば、LPC-Link2を外部から起動した場合(例えばLinkFlashで)、 青いDebugボタンが正しく動作 し、ターゲットを通常通りデバッグできます。 MCUXpresso IDE 25.6に付属していたオリジナルのLinkServerバージョンとLinkServer 26.9.130の両方をテストしました。動作は同じです。 また、IDEsの元/デフォルトのLinkServer設定も復元しましたが、改善はありませんでした。 したがって、問題は次のようではないようです。 LPC-Link2ハードウェア USB列挙 Linux DFUサポート LinkServerのブートイメージ LinkServerのブートメカニズム自体 この失敗は、 Linuxの緑色のデバッグ起動シーケンスの一部としてMCUXpresso IDEによって自動的に行われるLPC-Link2ブートに特化したようです。 回避策として、LinkFlashを起動してLPC-Link2を起動させ、LinkFlashを閉じてから青いDebugボタンを使うことができます。これは機能するが、明らかに本来のワークフローではない。 Linux 上のMCUXpresso IDE 25.6 Build 136でこの挙動を見た方はいらっしゃいますか?IDEのLPC-Link2自動起動手順に関する既知の修正やパッチはありますか? 特に、LPC-Link2とLinkServerの起動プロセス自体が明らかに動作しているので、これが既知のIDE問題かどうか知りたいです。 Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux ありがとう。確認しました。 私のシステムには以下があります： dfu-util 0.11 MCUXpresso IDE 25.6.136インストール自体にはDFU-utilバイナリは含まれていないため、システムバージョンを使用しているようです: /usr/bin/dfu-util これは確かにバージョン0.11です。 あなたがリンクしてくれたフォーラムの投稿も確認しました。そこで説明されている状況は、dfu-util 0.11 と dfu-util -l によって返される VID:PID の解析に特に関係しているため、潜在的に関連性があるように思われます。 しかし、私の場合に重要な違いがあります。同じboot_link2/dfu_bootコマンドをターミナルから手動で実行すると正しく動作します。この問題は、MCUXpresso IDEが緑色のデバッグローンチの事前実行コマンドとしてboot_link2を呼び出したときに発生します。 LinkServer/MCUXpresso IDE 25.6.136に含まれているdfu_bootスクリプトは可能でしょうか?リンク先の投稿で説明されているdfu-util 0.11の解析問題はまだ残っていますか？ その話題は2024年のものですが、この問題が2026年になってもまだ存在している可能性はありますか? bela@bela-ThinkPad-P70:~ $ find /usr/local/mcuxpressoide-25.6.136-type f -name 'dfu-util*' -ls bela@bela-ThinkPad-P70:~ $ which dfu-util dfu-util --version /usr/bin/dfu-util dfu-util 0.11 著作権 2005-2009 Weston Schmidt、Harald Welte、および OpenMoko Inc. 著作権 2010-2021 トルモッド・ヴォルデンおよびシュテファン・シュミット このプログラムはフリーソフトウェアであり、保証は一切ありません バグがあれば http://sourceforge.net/p/dfu-util/tickets/ に報告してください bela@bela-ThinkPad-P70:~ $ Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux こんにちは、 @jeanvaljean 投稿ありがとうございます! IDEで使っているdfu-utilのバージョンを確認してもらえますか? 投稿をご確認ください:Linuxでlpscryptを使ってLPCのLink2にdfuブート問題を報告してください Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux こんにちは、 @jeanvaljean 返信が遅くなり申し訳ありません。 はい、その話題はDFU版が同じなので影響を与えるかもしれません。以前投稿した記事に記載されているパッチを適用してみて、問題が解決するかどうか教えてください。

使用主机上的 SPIGen 无法驱动 FRDMPT2001EVM 上的 DRVEN 和 RESETB 引脚。 你好， 我按照 KTFRDMPT2001EVMUG.pdf 配置了 FRDM-KL25Z 板，并用电缆将其连接到我的 PC。FRDM-KL25Z 板上的蓝色 LED 灯亮起。在主机上的 SPIGen 中加载 *.spi 文件后，我可以正常下载并读取/写入寄存器。然而，DRVEN 和 RESETB 引脚仍然保持默认状态。我无法使用 SPIGen 面板/GUI 中的按钮将板上的相应引脚拉高或拉低。 我应该如何解决这个问题？感谢你的回复！ PT2001 FRDM-KL25Z Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 嗨 Lex（ @LexLiu ）， 请问您能否帮忙解决一下使用 SPIGen SW 驱动 FRDMPT2001EVM 上的 DRVEN 和 RESETB 引脚时遇到的问题？ 谢谢您！ BRs，托马斯 Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 这个问题我还没解决。你能帮助我吗？

Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC Hello, I configured the FRDM-KL25Z board according to KTFRDMPT2001EVMUG.pdf and connected it to my PC with a cable. The blue LED on the FRDM-KL25Z board turns on. After loading the *.spi file in SPIGen on the host PC, I can download normally and read/write registers. However, the DRVEN and RESETB pins remain in their default state. I cannot use the buttons in the SPIGen panel/GUI to drive the corresponding pins on the board high or low. How should I solve this issue? Thank you for your reply! PT2001  FRDM-KL25Z  Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC Hi Lex (@LexLiu), Could you please help with this question regarding the problem with driving both the DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen SW? Thanks! BRs, Tomas Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC I haven't solved this problem yet. Can you help me?

Ibis Lx2160a 型号 嗨，大家好 我想知道如何才能获得适用于 lx2160a 的 ibis 型号，有人可以帮帮我吗？ 非常感谢您 元 Re: Ibis model for Lx2160a IBIS模型不公开，请在此处创建案例： https://support.nxp.com/s/?language=en_US  并分享你的保密协议。 谢谢！

ホストPC上のSPIGenを使用してFRDMPT2001EVMのDRVENピンとRESETBピンを駆動できません こんにちは、 KTFRDMPT2001EVMUG.pdfに従ってFRDM-KL25Zボードを設定し、ケーブルでPCに接続しました。FRDM-KL25Z基板上の青色LEDが点灯します。ホストPCのSPIGenで*.spiファイルを読み込んだ後、通常通りレジスタをダウンロードし読み書きできるようになりました。しかし、DRVENとRESETBのピンはデフォルトのままです。 SPIGenパネルやGUIのボタンを使って、基板上の対応するピンを高くまたは低く動かすことはできません。 この問題をどう解決すればいいでしょうか？お返事ありがとうございます！ PT2001 FRDM-KL25Z Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC こんにちは、Lex（ @LexLiu ） SPIGen SWでFRDMPT2001EVMのDRVENピンとRESETBピンの両方を駆動する際の問題について、この質問についてご協力いただけますか? よろしくお願いします！ BRs、トーマス Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 私はまだこの問題を解決していません。助けてくれないか?

mcxn947 加密区指定可范围么，程序内部フラッシュ加密区 暗号化や署名は特定のフラッシュ空間の範囲に適用できますか? 暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか（読み戻されるデータは暗号文ですか？書き込まれるデータは平文ですか？）？ OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか? Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 こんにちは、 まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。 正しい 上記の観点に基づくと： そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。 つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。 もう少し詳しく説明させてください。 はい、SBファイルは暗号化されているため、フラッシュメモリに書き込む前にROMで復号化する必要があります。しかし、SBファイルはOEMと製造工場間のファームウェアを保護するために、完全に独立して暗号化されています。 フラッシュメモリのプログラミング（内蔵型か外付け型かを問わず）はまた別の話で、全く使用されないか、あるいは異なるアルゴリズム、初期ベクトルなどを用いて使用されます。 よろしくお願いいたします。 リボル Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。   上記の観点に基づくと： そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。 つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。                           Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 こんにちは、 MCXNデバイスの場合： 暗号化や署名は特定のフラッシュ空間の範囲に適用できますか? SECツール： - アプリケーション全体に署名 - 暗号化領域は製品のライフ期間中に一度設定され、FUTUREのアップデート(アプリの拡張)のために予約を取る必要があります。 暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか（読み戻されるデータは暗号文ですか？書き込まれるデータは平文ですか？）？ 暗号化／復号化はリアルタイムで行われます。アプリがフラッシュメモリから読み込む場合、そのことを気にする必要はありません。透過的に処理されます。アプリケーション自体から暗号化されたフラッシュ領域に書き込むことについては、調査が必要です。注意点があるかはわかりません。 OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか? 前述のとおり、暗号化には適切なサイズのメモリ領域を指定する必要があります。もしアプリケーションが暗号化領域を超えた場合、OTAは動作しますが、暗号化圏外のアプリ部分だけが動作し、IPアドレスは暗号化で保護されません。 よろしくお願いいたします。 リボル

启用 Falcon 模式下的安全启动（内核版本 6.12.49）|| iMX8MP_EVK 大家好， 请问您能帮我启用Falcon模式下的安全启动吗？ 我已成功借助 meta-imx-fastboot GitHub 代码库实现了 Falcon 模式。但是，我发现 meta-imx-fastboot 的实现会 在 Falcon 模式启动过程中 有意移除 OP-TEE 。 由于我的用例也需要用到 OP-TEE，我在 NXP 论坛上提出了一个问题， @elena_popa提供了一个保留并启用 OP-TEE 的解决方案。我附上了论坛链接供您参考。 目前，我在启用 安全启动 时遇到了问题 ，因为我找不到任何关于我的当前内核版本在 Falcon 模式下启用安全启动的文档。 环境详情： 主板： i.MX8M Plus EVK（i.MX8MP EVK） 内核版本： 6.12.49 Yocto 环境：基于 Yocto 的 NXP 电路板支持包。 启动模式：猎鹰模式 要求：猎鹰模式 + OP-TEE + 安全启动 Yocto Project Re: Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK 你好， 请问您遇到了什么错误？ 顺祝商祺！

Re: S32G274A LLCE CAN 現在、自社開発のボードはマルチコアモードで動作しています。1つのA53コアは他のデバイスとのネットワーク通信タスクに使用され、他の複数のA53コアはバス通信ドライバを実行します。各バスタイプはそれぞれ別のA53コアを使用します。問題が発生しました。現在のLLCE CANリカバリ操作は、LLCE CANモードを停止してから再開するように構成されています。実際のほとんどのシナリオでは通信は復旧できますが、バスリカバリが頻繁に実行される場合があり、他のA53コアの正常な動作に影響を与えます（ネットワーク通信タスクが中断されます）。質問は、LLCE CANバスリカバリにはどのような方法があるか、また、LLCE CANを別のコアで実行しても他のコアに影響を与えるのはなぜか、ということです。バージョン情報は、S32G_LLCE_1_0_9、SW32G_RTD_4.4_4.0.2_P04_D2312です。 Re: S32G274A LLCE CAN こんにちは、 @JACK_Q こんにちは ソフトウェアおよびハードウェアのテスト環境について、詳細な説明をいただけますでしょうか？ 1. あなたのシステムでは、MコアとAコアは同時に使用されていますか？M7コアはどのようなタスクを実行しますか？どのソフトウェアパッケージに依存していますか？ 2. あなたの説明によると、A53側の各コアはそれぞれ独自のタスクを実行しているようですが、どのようなソフトウェアが動作していますか？Linux BSPでしょうか？ BR チェイン

Difference between S32K1_S32M24X and S32K1 RTD packages? I am developing for the S32K116. I noticed while going through the S32DS Extensions an dUpdates that I have two S32K1 packages installed: "S32K1_S32M24X Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP06" and "S32K1 Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP06" What is the difference between the two? If they do the same for my case, which one should I keep/uninstall? I tried removing one of them (the S32K1 one) but then my projects couldn't load their .mex files anymore. Re: Difference between S32K1_S32M24X and S32K1 RTD packages? Hi @daniel_meier  Although the packages may appear similar, they have dependencies between themselves and with S32DS, and are not intended to be treated as standalone components that can be used independently of one another. Therefore, we recommend reinstalling the package and keeping both packages installed to ensure proper project functionality. BR, VaneB

Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK Hi Team, Could you please help me enable Secure Boot in Falcon Mode? I have successfully achieved Falcon Mode with the help of the meta-imx-fastboot GitHub repository. However, I observed that the meta-imx-fastboot implementation intentionally removes OP-TEE during the Falcon Mode boot flow. Since OP-TEE is also required for my use case, I raised a query on the NXP forum, where @elena_popa provided a solution to retain and enable OP-TEE. I have attached the forum link for reference. Currently, I am facing an issue with enabling Secure Boot, as I could not find any document for Secure Boot with falcon mode for my current kernel version. Environment details: Board: i.MX8M Plus EVK (i.MX8MP EVK) Kernel Version: 6.12.49 Yocto Environment: Yocto-based NXP BSP Boot Mode: Falcon Mode Requirement: Falcon Mode + OP-TEE + Secure Boot Yocto Project Re: Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK Hello, Could you please share which error are you getting? Best regards.

mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Can encryption and signing be applied to a specified range of flash space? How does the program's own read/write behavior within the encrypted flash region differ from before (is the data read back ciphertext? is the data written plaintext?)? During OTA upgrades, how can the architecture be made to match the chip's encryption/decryption without conflicts? Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Hello, To be clear first: once encryption is enabled, when a program running on the chip writes to flash, the data it writes is plaintext, but what is ultimately stored in flash is ciphertext; when the ciphertext in flash is read by a program running on the chip, it comes out as plaintext. Correct Based on above viewpoint : Then, the SB file read by your Secure Provisioning software is ciphertext, and what is sent over serial ISP to the chip’s factory ISP ROM bootloader must also be ciphertext (otherwise there would be a logical flaw). The factory ISP ROM bootloader decrypts the ciphertext received over serial into plaintext, and then writes the plaintext data into flash, but ultimately the data stored in flash is encrypted again, becoming ciphertext. In other words, during ISP programming, the factory ISP ROM bootloader first decrypts and then encrypts, going through a decrypt-then-encrypt round trip. Let me put more light into this: yes SB file is encrypted and must be decrypted by ROM before writing to Flash. But SB file is encrypted completely independently, to protect the firmware between the OEM and manufacturing facility. Programming flash, either internal or external, is different story and either is not used at all or is used with different algorithm, initial vector, etc. Regards, Libor Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 To be clear first: once encryption is enabled, when a program running on the chip writes to flash, the data it writes is plaintext, but what is ultimately stored in flash is ciphertext; when the ciphertext in flash is read by a program running on the chip, it comes out as plaintext.   Based on above  viewpoint : Then, the SB file read by your Secure Provisioning software is ciphertext, and what is sent over serial ISP to the chip’s factory ISP ROM bootloader must also be ciphertext (otherwise there would be a logical flaw). The factory ISP ROM bootloader decrypts the ciphertext received over serial into plaintext, and then writes the plaintext data into flash, but ultimately the data stored in flash is encrypted again, becoming ciphertext. In other words, during ISP programming, the factory ISP ROM bootloader first decrypts and then encrypts, going through a decrypt-then-encrypt round trip.                           Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Hi, For MCXN devices: Can encryption and signing be applied to a specified range of flash space? SEC tool: - signs whole application - encryption region is configured once in the product lifetime, you need to make a reserve for future updates (increased size of app) How does the program's own read/write behavior within the encrypted flash region differ from before (is the data read back ciphertext? is the data written plaintext?)? Encryption/decryption is on-the-fly. App reading from flash does not need to care, it is transparent. About writing to encrypted flash region from the application itself, you need to investigate, I'm not sure if there are any caveats. During OTA upgrades, how can the architecture be made to match the chip's encryption/decryption without conflicts? As mentioned above, you need to specify reasonable size of memory region for encryption. If you application exceeds the encrypted region, OTA will work, only the part of the app that will be outside of encrypted area will still work, only your IP won't be protected by the encryption. Regards, Libor

Re: S32G274A LLCE CAN 当前自研板运行在多核模式下，1个A53核是用来和其他设备网络通信任务的，还有几个A53跑的是一些总线通信的驱动，每个类型的总线单独使用一个A53核。现在出现了一个问题是当前给LLCE CAN配置的恢复操作是设置LLCE CAN的模式先stop再start，在实际运行的场景大部分可以恢复通信的，但是有的时候会频繁的执行总线恢复以至于到影响其他的A53正常运行（网络通信任务中断）。想问的是LLCE CAN有那些方法可以总线恢复，还有是为什么LLCE CAN已经单独放置一个核运行还会影响到其他的核。以下是版本信息：S32G_LLCE_1_0_9；SW32G_RTD_4.4_4.0.2_P04_D2312 Re: S32G274A LLCE CAN Hello, @JACK_Q  您好 麻烦您详细介绍一下您的软硬件测试环境： 1. 在您的系统中，是M核和A核端同时使用吗？M7核运行什么任务？基于哪些软件包？ 2. A53端从您的描述来看，每个核都有自己的任务，请问是运行的什么软件？是否是Linux BSP？ BR Chenyin

Falconモードでセキュアブートを有効にする（カーネルバージョン6.12.49）|| iMX8MP_EVK チームの皆さん、こんにちは。 Falcon ModeでSecure Boot を有効にするのを手伝ってもらえます か? meta-imx-fastboot GitHubリポジトリ の助けを借りて、Falcon Modeの実現に成功しました 。しかし、meta-imx-fastbootの実装では 、Falcon Modeのブートフロー中に 意図的に OP-TEE が削除されていることがわかりました。 OP-TEEも私のユースケースに必要なので、NXPフォーラムで質問をしました。@elena_popa OP-TEEを保持・有効化するソリューションを提供してくれました。参考のためにフォーラム のリンク を添付しました。 現在、Secure Bootを有効にする際に問題に直面しています 現在のカーネルバージョンでファルコンモード付きのセキュアブートに関するドキュメントが見つからなかったためです。 環境詳細: ボード： i.MX8M Plus EVK（i.MX8MP EVK） カーネルバージョン: 6.12.49 Yocto Environment: Yocto拠点のNXP BSP ブートモード：ファルコンモード 要件：ファルコンモード + OP-TEE + セキュアブート Yocto Project Re: Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK こんにちは、 どのエラーが出ているのか教えていただけますか? よろしくお願いいたします。

mcxn947加密区域可以指定范围，程序内部如何访问flash加密区域 能否对指定范围的闪存空间进行加密和签名？ 程序在加密闪存区域内的读/写行为与之前有何不同（读取回的数据是密文吗？写入的数据是明文吗？）？ 在 OTA 升级过程中，如何使架构与芯片的加密/解密相匹配而不发生冲突？ Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 你好， 首先要明确一点：一旦启用加密，当芯片上运行的程序向闪存写入数据时，写入的数据是明文，但最终存储在闪存中的是密文；当芯片上运行的程序读取闪存中的密文时，读取出来的却是明文。 正常 基于以上观点： 然后，您的安全配置软件读取的 SB 文件是密文，通过串行 ISP 发送到芯片的工厂 ISP ROM 引导加载程序的内容也必须是密文（否则就会出现逻辑缺陷）。工厂 ISP ROM 引导加载程序将通过串口接收的密文解密为明文，然后将明文数据写入闪存，但最终存储在闪存中的数据又会被加密，变成密文。 换句话说，在 ISP 编程期间，工厂 ISP ROM 引导加载程序首先进行解密，然后再进行加密，经历一个解密再加密的往返过程。 让我再详细解释一下： 是的，SB 文件已加密，必须先由 ROM 解密才能写入 Flash。但SB文件是完全独立加密的，以保护OEM厂商和制造工厂之间的固件安全。 对闪存（无论是内部闪存还是外部闪存）进行编程是另一回事，要么根本不使用闪存，要么使用不同的算法、初始向量等。 此致， 伦敦银行间同业拆借利率 (Libor) Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 首先要明确一点：一旦启用加密，当芯片上运行的程序向闪存写入数据时，写入的数据是明文，但最终存储在闪存中的是密文；当芯片上运行的程序读取闪存中的密文时，读取出来的却是明文。   基于以上观点： 然后，您的安全配置软件读取的 SB 文件是密文，通过串行 ISP 发送到芯片的工厂 ISP ROM 引导加载程序的内容也必须是密文（否则就会出现逻辑缺陷）。工厂 ISP ROM 引导加载程序将通过串口接收的密文解密为明文，然后将明文数据写入闪存，但最终存储在闪存中的数据又会被加密，变成密文。 换句话说，在 ISP 编程期间，工厂 ISP ROM 引导加载程序首先进行解密，然后再进行加密，经历一个解密再加密的往返过程。                           Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 您好， 对于 MCXN 设备： 能否对指定范围的闪存空间进行加密和签名？ 高效密码学标准\(SEC\)工具： - 签署整个申请 - 加密区域在产品生命周期内只需配置一次，您需要预留空间以备将来更新（应用程序体积增大）之需。 程序在加密闪存区域内的读/写行为与之前有何不同（读取回的数据是密文吗？写入的数据是明文吗？）？ 加密/解密是即时进行的。应用程序从闪存读取数据无需关心，它是透明的。关于从应用程序本身写入加密闪存区域的问题，你需要进行调查，我不确定是否存在任何注意事项。 在 OTA 升级过程中，如何使架构与芯片的加密/解密相匹配而不发生冲突？ 如上所述，您需要指定合理大小的加密内存区域。如果您的应用程序超出加密区域，OTA 更新仍可运行，但只有应用程序超出加密区域的部分仍可运行，您的 IP 地址将不再受加密保护。 此致， 伦敦银行间同业拆借利率 (Libor)

S32K1_S32M24X 和 S32K1 RTD 封装有什么区别？ 我正在为S32K116进行开发。 我在检查 S32DS 扩展和更新时注意到，我安装了两个 S32K1 软件包： “S32K1_S32M24X 实时驱动程序 AUTOSAR R21-11 版本 3.0.0”QLP06” 和 S32K1 实时驱动程序 AUTOSAR R21-11 版本 3.0.0QLP06“ 两者之间有什么区别？ 如果他们也对我的情况这样做，我应该保留哪个/卸载哪个？ 我尝试移除其中一个（S32K1），但之后我的项目就无法加载它们的 .mex 文件了。文件不再存在。 Re: Difference between S32K1_S32M24X and S32K1 RTD packages? 嗨@daniel_meier 虽然这些软件包看起来可能很相似，但它们彼此之间以及与 S32DS 之间存在依赖关系，因此不应被视为可以彼此独立使用的独立组件。 因此，我们建议重新安装该软件包，并保持两个软件包都已安装，以确保项目功能正常。 BR，VaneB

Re: S32G274A LLCE CAN The current self-developed board runs in multi-core mode. One A53 core is used for network communication tasks with other devices, and several other A53 cores run bus communication drivers, with each type of bus using a separate A53 core. A problem has arisen: the current LLCE CAN recovery operation is configured to stop and then start the LLCE CAN mode. In most actual scenarios, communication can be restored, but sometimes bus recovery is executed frequently, affecting the normal operation of other A53 cores (network communication tasks are interrupted). The questions are: what methods are available for LLCE CAN bus recovery, and why does having LLCE CAN running on a separate core still affect other cores? The version information is: S32G_LLCE_1_0_9; SW32G_RTD_4.4_4.0.2_P04_D2312 Re: S32G274A LLCE CAN Hello, @JACK_Q Hello Could you please provide a detailed description of your software and hardware testing environment? 1. In your system, are the M-core and A-core used simultaneously? What tasks does the M7 core run? Which software packages does it rely on? 2. From your description, each core on the A53 side has its own task. What software is it running? Is it a Linux BSP? BR Chenyin