[S32K566 SAF] BISTテスト後、MCUがリセット状態のままになる こんにちは、チームの皆様。 お客様がSAFを使用している際に、BIST後にMCUが常にリセット状態のままになるという問題が発生しました。電源を切る以外にMCUを起動する方法はありません。そのため、お客様は回避策と根本原因を知りたいと考えています。しかし、これに関する説明は一切ありません。 よろしくお願いいたします。 ジュンジエ SAFETY_SW Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは、 @MariusC さん。 ご対応ありがとうございます。 BSSM契約：なし お客様 NXPについて*: PATAC プロジェクト名*: ゾーンコントローラ お客様お問い合わせ担当者*（氏名とメールアドレス）：Liek Li（[email protected]） ソフトウェアおよびハードウェア情報：顧客はS32k566 A0サンプルに基づいてセーフティ機能を開発しています。 SWパッケージ情報*: SW32K5_RTD_R23-11_0.8.0 + SW32K5_SAF_0.8.0_HF01_D2602 HW*（ボード/チップセット/プラットフォーム）：S32K566 CVB ソフトウェアバージョン*: 0.8.0 よろしくお願いいたします。 ジュンジエ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjie 、 お客様へのより良いサポートのために、以下の情報をご提供ください。 直接のお客様をサポートしている場合は、以下の情報を提供してください。 BSSM契約：あり／なし お客様 NXPについて*: プロジェクト名*: お客様お問い合わせ担当者*（氏名とメールアドレス）： ソフトウェアおよびハードウェア情報： ソフトウェアパッケージ情報*: ハードウェア*（ボード/チップセット/プラットフォーム）： ソフトウェアバージョン*: *必須 Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjie この問題には、起動初期段階で複数の原因が考えられます（例：BISTの終了/復元が完了しない）。 考えられる原因としては、破壊的リセットイベントがラッチされたままになり、繰り返しリセットを行うと破壊的リセットエスカレーションしきい値（DRET）に達し、電源投入リセットが行われるまでデバイスがリセット状態のままになることが挙げられます。 根本原因を特定するには、リセットサイクル直後に取得した以下のレジスタダンプ/ログ（16進数値/スクリーンショット）が役立ちます。 MC_RGM_DES（破壊イベント情報ステータス） MC_RGM_FES（機能/外部イベント情報ステータス） MC_RGM_DRET、MC_RGM_FRET（増加閾値） Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは、 @DenisSas MCUが繰り返しリセットされ、電源を切る以外にデバッガーがMCUに接続できませんでした。しかし、電源投入後、 MC_RGMに信号がありません。SAFドライバのSAFサンプルを実行した場合にも、この問題が発生する可能性があります。 よろしくお願いいたします。 ジュンジエ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん ご説明いただきありがとうございます。 私はこの行動について引き続き調査しています。現時点では、SAFのサンプルシナリオを再現するためのS32K5ボードにすぐにアクセスすることはできませんが、デバッガが接続される前にMCUがリセットループに入る理由を理解するために、SAFの初期化フローと初期リセットシーケンスをレビューしています。 Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは、 @DenisSas 最新情報を教えていただけますか？お客様から、起動時間の評価とアプリの起動プロセスの最適化を行っているため、このチケットをクローズするようにとの要望がありました。ありがとう！ よろしくお願いいたします。 ジュンジエ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん s32k566については、弊社側でも同様の問題が発生しているため、検証チームと連絡を取っています。月曜日に彼らとの会合が予定されているので、その後情報をお伝えします。 よろしくお願いします、 デニス Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは、 @DenisSas 最新情報をお知らせいただきありがとうございます。もう少し詳しい内容を教えていただけますでしょうか？ハードウェアの問題でしょうか、それともソフトウェア構成の問題でしょうか、それともSBAFの問題でしょうか？ハードウェアの問題やSBAFの問題ではない場合、顧客はBISTレジスタに直接書き込むことでBISTを構成し、BISTを動作させたいと考えています。もう一つ質問なのですが、アップデートのロードマップを入手できますか？ よろしくお願いいたします。 ジュンジエ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん BIST実行時間 8.3ms これは暫定的なBIST執行計画であることをご了承ください。カットA0にはCPEに対してLBISTを実行できないというエラーがあるため、カットB0で修正されます。 SAF側では、LBIST5とLBIST11（CPEとHSE）を使用せずに実行されるSAFデモ例において、BISTの実行がまもなく完了します。 BootROMの実行時間（HSEの有無による違い）については、設計担当者からの回答を待っています。 敬具、 ラドスラフ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん 問題はハードウェア（A0のエラー、LBIST CPEが動作しない）とソフトウェアの両方にあります。BISTを動作させるためにBISTレジスタを直接書き込むことはお勧めしません。 ロードマップは、2026年5月29日にリリースされるSAF ZE 0.8.1の最新版まで保留される予定です。機能デモは本日より来週、別途公開されます。この修正策は、CPEなしで動作するようにすることです。 よろしくお願いします、 デニス Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは、 @RadoslavB アップデートありがとうございます。お客様が起動時間を評価できるのは本当に大変役立ちます。 よろしくお願いいたします。 ジュンジエ Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん この問題は会議で発見され、現在BISTの所有者がSAFデモ例と連携させるために必要な更新作業を行っています。 ご辛抱いただきありがとうございます。 よろしくお願いいたします。 デニス Re: [S32K566 SAF] MCU will be stucked in reset after bist test こんにちは@Junjieさん 念のためお知らせしておきますが、この問題はまだ解決しておらず、現在SBAFチームによる調査中です。 よろしくお願いいたします、デニス

FRDM-K64FでMCUxpresso 25.6を使用した場合、SDカードのシンボルが未定義になる こんにちは、 SDカードソフトがうまく動かずに困っています。 必要なのは、いくつかのアイテムを電源を入れるだけで、SDカードの他のアクティブなマネジメントは不要です。ただ、後でログが必要になるかもしれませんが... データ型sd_card_tを使用しようとしていますが、「不明な型名」エラーが発生します。 以前にfsl_sd.hを含めましたそして fsl_sdhc.h。しかし、そうすると、どちらの場合でも多くの関数に対して複数定義のメッセージが表示されます。だから、fsl_sd.h.は必要ないと思った。SDKには含まれていないので、元の複数定義エラーはGitHubから両方ダウンロードしました。fsl_sdhc.h があります。SDKからも「未知型名」のメッセージが出続けています。言うまでもなく、SDカードのサンプルは非常に使いづらいと感じています！ どんなご支援でも大変ありがたく思います！ Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F こんにちは、 @ve3id さん。 投稿ありがとうございます。 プロジェクト内のSDKコンポーネントを管理し、ドライバを追加してください。> SDHCとミドルウェア>記憶->SDMMC Stack->SD sdcard_polling例では以下の構成要素が含まれています。 「SDK コンポーネント管理」に入るには、プロジェクトを右クリックして「SDK Management -> SDK Components 管理」に行く必要があります これで問題が解決するかどうか教えてください。 Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 迅速な返信ありがとう、カルロス。でももう返信は済ませたので、他に何かあるかもしれませんね?これがSDマネジメントのための私の窓口です: Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 私はSDK_2.11.0_FRDM -K64Fを使用しています。 削除して「ダウンロード・インストールsdks」タブを使って同じバージョンの新しいものをビルド・ダウンロードしましたが、同じ問題が起きました。 よろしくお願いします。 ナイジェル Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F こんにちは、 @ve3id さん。 ご説明ありがとうございます。 どのSDKバージョンを使っているのか教えていただけますか? バージョン2.11.0で試してみましたが、私の環境では再現できませんでした。

NXPRDLIB_REM_GEN_INTFS usage Hi. I'd like to know what is the exact purpose of the NXPRDLIB_REM_GEN_INTFS define in NXP Reader Library. From what I can see, if it's defined a software API interface is built with the project, otherwise it's replaced by some binary equivalent, since then only the function prototypes are available... Is this correct? If so, where are the binary libs? What are pros/cons in selecting binary over software API? Thank you in advance, Peppe NFC Reader Library Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m  Thats a bug in the Doxygen-Doku: /* DEBUG build mode */ /*#define NXPBUILD__PH_DEBUG*/ /**< DEBUG build definition */ #define NXPRDLIB_REM_GEN_INTFS Thus, the correct answer is still pending... Re: NXPRDLIB_REM_GEN_INTFS usage Hello, According to the API documentation of the reader library the definition you are seeing it's for build debug purposes Regards, Estephania Re: NXPRDLIB_REM_GEN_INTFS usage Hi Estephania, thank you for your interest. Starting e.g. at PN7462AU-FW_v05.21.00_Full file root that definition is enabled in some NFC Reader Library examples: $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS and in some PN7462AU PSP examples too: $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS and it is checked in many places in NFC Reader Library sources: $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ (...) Best regards, Peppe Re: NXPRDLIB_REM_GEN_INTFS usage Hello, Which version of the library are you using ? Could you please help me with that information and the file where you are seeing this definition ? I was not able to locate the definition you are referring to neither in the  API documentation nor in the library, so it would help me a lot. Regards, Estephania

[S32K566 SAF] MCU will be stucked in reset after bist test Hi Teams          Customer use SAF and found MCU will be always stucked in reset after bist. There is no way to boot MCU except power-off. so customer want to know the workaround way and route cause. But there are no any descriptions for this.  Best Regards Junjie  Safety_SW Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @MariusC  Thanks for your support. BSSM Contract:  No Customer Company*: PATAC Project Name*: Zonal Controller Customer Contact Point* (Name & Email): Liek Li  ([email protected]) Software & Hardware Information: Customer is developing the safety feature based on S32k566 A0 sample  SW Package Info*: SW32K5_RTD_R23-11_0.8.0 + SW32K5_SAF_0.8.0_HF01_D2602 HW* (Board/Chipset/Platform):S32K566 CVB SW Version*: 0.8.0 Best Regards Junjie Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hello @Junjie , Please provide the following information so we can help your customer better: If you are supporting a Direct Customer, please provide: BSSM Contract: Yes / No Customer Company*: Project Name*: Customer Contact Point* (Name & Email): Software & Hardware Information: SW Package Info*: HW* (Board/Chipset/Platform): SW Version*: *required Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie  The problem can have multiple causes at this early boot stage (e.g., BIST exit/restore not completing). A possible cause is that a destructive reset event stays latched, so repeated resets hit the destructive reset escalation threshold (DRET), keeping the device in reset until a power‑on reset. To pinpoint the root cause, the following register dumps/logs would be helpful, captured immediately after a reset cycle (hex values/screenshots). MC_RGM_DES (Destructive Event Status) MC_RGM_FES (Functional/External Event Status) MC_RGM_DRET, MC_RGM_FRET (escalation thresholds) Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @DenisSas        MCU is repeat reset and debugger could not attach the MCU, except power-off. But once power-on, There is no signal on MC_RGM. you can also get this issue if run the SAF example in SAF driver. Best Regards Junjie Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie, Thank you for the clarification. I’m continuing to investigate this behavior. At the moment I don’t have immediate access to an S32K5 board to reproduce the SAF example scenario, but I am reviewing the SAF initialization flow and the early reset sequence to understand why the MCU enters a reset loop before the debugger can attach. Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie, For s32k566, we are in contact with the Validation team, as the problem is also present on our side. There is a planned meeting with them on Monday, so i will come back with info afterwards. Best regards, Denis Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @DenisSas  Could I have some updates? Customer push us to close this ticket because customer is doing evaluate the boot time and optimize app boot process. Thank you! Best Regards Junjie  Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie, The issue is HW (errata for A0, LBIST CPE not working) and SW. I would not suggest trying to write BIST registers directly to make BIST work. The roadmap would be waiting until the new release of SAF ZE 0.8.1, coming 29 May 2026. The functional demo comes separately next week from today. The fix means making it work without CPE. Best regards, Denis Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @DenisSas        Thanks for your update, and could you please share more details about it? It is hardware issue or softeware configure issue or sbaf issue? customer want to configure the bist by writing bist registers directly to make bist work if it is not hardware issue and sbaf issue. For another question,Can we get the update roadmap? Best Regards Junjie Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie , BIST execution time 8.3ms Please be aware this is preliminary BIST exec. time as there is Errata for cut A0 where it is not possible to run LBIST for CPE, this will be fixed with cut B0. On SAF side we are about to finish BIST execution in SAF Demo example running without LBIST5 and LBIST11 (CPE and HSE). Regarding BootRom execution times with and without HSE, I'm waiting for response from architect. Kind Regards, Radoslav Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @RadoslavB       Thanks for your update, It is really great helpfull to let customer evaluate the startup-time . Best Regards Junjie  Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie, The issue was found in the meeting, now the BIST owner is doing the necessary updates to make it work with the SAF demo example. Thank you for your patience. Regards, Denis Re: [S32K566 SAF] MCU will be stucked in reset after bist test Hi @Junjie, As a heads-up, the problem is still present and is currently under investigation with the SBAF team. Kind regards, Denis

Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi, I am having trouble getting the SD card software going. All I need to do is get a few items on power-up, no other active management of the SD Card,although I might need logging later on.. I am trying to use data type sd_card_t, and am getting 'unknown type name' error. I have previously included fsl_sd.h and fsl_sdhc.h. but when I do that I get a multiple definition message for many functions in either.  So I assumed that we don't need fsl_sd.h.   It isn't even in my SDK, so for the original multiple definiiton error I downloaded both from github.  Now I have fsl_sdhc.h from the SDK and am still getting the 'unknown type name' message.  Needless to say I am finding the SD card examples very hard to use! Any help would be very much appreciated! Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi @ve3id  Thank you for your post, Please Manage the SDK components in you project and add drivers-> sdhc and middleware->memories->SDMMC Stack->SD At the sdcard_polling example the following components are included: To enter into manage the SDK components you need right click the project and go to SDK Managment -> Manage SDK Components Let me know if this solves the issue.  Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Thank you for the quick reply, Carlos, but I have already done that, so maybe there is something else? Here is my window for the SD management: Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hi @ve3id  Thanks for clarifying, Could you please share which SDK version you are using?  I tried with 2.11.0 and I'm not able to replicate it at my end.  Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F I am using SDK_2.11.0_FRDM-K64F I removed it, and built and downloaded a new one of the same version using the "download and install sdks' tab and still have the same problem. thanks Nigel

熱狂期 TEM説明S32 Design Studio for ARM v2018 注文番号S32-DS-ARM_v2018_169264627 EBF4-DE52-80C0-FD65は、承認された有効期限を延長することができますか? Re: 激活码过期 こんにちは、 お客様のS32DSライセンスが延長されました。

NVT4857UKAZの代替部品 これはソフトウェアに直接関係ない話ですが、最近、 NVT4857UKAZ はすでにEOLに達しており、ピン・ツー・ピン対応の交換部品が入手できないことが判明しました。i.MX95ベースのデバイスではSDカード**サポート**が必須機能であるため、この状況を踏まえた代替手段を理解しようとしています。交換可能な選択肢や設計方法について、おすすめを教えていただけますか? Re: Alternative part for NVT4857UKAZ こんにちは！ NVT4858を代替と呼んでください。 ただし、NVT4858はそのまま交換できるものではないことにご注意ください。したがって、新しいデバイスに対応するためにハードウェアとソフトウェアの両方の改造が必要になる場合があります。 移行の影響を評価するために、仕様や設計要件を慎重に確認することをお勧めします。 お役に立てば幸いです！ Re: Alternative part for NVT4857UKAZ こんにちは！ NVT4858を代替と呼んでください。 ただし、NVT4858はそのまま交換できるものではないことにご注意ください。したがって、新しいデバイスに対応するためにハードウェアとソフトウェアの両方の改造が必要になる場合があります。 移行の影響を評価するために、仕様や設計要件を慎重に確認することをお勧めします。 お役に立てば幸いです！

IMX6Q U-BooT Hi, I have a custom camera with an IMX6q processor. I have working firmware on an old bootloader and an old kernel. I need to update the bootloader and kernel. But I can't get past the kernel loading stage. The UART log is always empty. Please help. Re: IMX6Q U-BooT Hello @CAT5000  Hope you are doing very well. Please specify the current BSP version and the new one. Also, your Software changes related to the UART where is defined for Console. Best regards, Salas. Re: IMX6Q U-BooT Working bootloader version U-Boot 2018.03 (Apr 22 2021 - 04:17:10 -0400) CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C) at 30C Reset cause: POR Model: Freescale i.MX6 Quad SABER Smart Device Board Board: MX6-SabreSD Watchdog enabled DRAM: 2 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x21 MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... Card did not respond to voltage My board is a reference board with SabreSD I have all the schematics and data I'm not good at this kind of task, but I'd like to update the firmware to try out the new features. Re: IMX6Q U-BooT Hello! Actually, we have a guide for porting our processors to the last BSP version. Please take a look to the UG10165 (i.MX Porting Guide). There are described the changes that you need to do in U-boot. Also, if you have the Sabre board, you can simply download the last version Pre-compiled image from Embedded Linux for i.MX Applications Processors and flash to your board. Best regards,  Salas.

IMX6Q U-Boot 您好，我有一台定制相机，搭载IMX6q处理器。 我有一个可以在旧版引导加载程序和旧版内核上运行的固件。 我需要更新引导加载程序和内核。 但我始终无法通过内核加载阶段。 UART 日志始终为空。 请帮忙。 Re: IMX6Q U-BooT 你好@CAT5000 希望你一切都好。 请指定当前 BSP 版本和新版本。 此外，您的软件更改与 UART 相关，其中 UART 已在控制台中定义。 顺祝商祺！ 萨拉斯。 Re: IMX6Q U-BooT 您好！ 实际上，我们有将我们的处理器移植到最新 BSP 版本的指南。 请参考UG10165 （i.MX 移植指南）。 这里描述了需要在 U-boot 中进行的更改。 另外，如果您有 Sabre 开发板，您可以直接从Embedded Linux for i.MX Applications Processors下载最新版本的预编译镜像，然后刷写到您的开发板上。 此致， 萨拉斯。 Re: IMX6Q U-BooT 工作引导加载程序版本 U-Boot 2018.03（2021年4月22日 - 04:17:10 -0400） CPU：Freescale i.MX6Q rev1.3 996 MHz（运行频率为 792 MHz） CPU：汽车级温度等级（-40℃至125℃），工作温度30℃ 复位原因：POR 型号：飞思卡尔 i.MX6 Quad SABER 智能设备板 板：MX6-SabreSD 已启用看门狗 动态随机存取存储器(DRAM)：2 GiB PMIC：PFUZE100！开发版本号=0x10 版本号=0x21 MMC：FSL_SDHC：0，FSL_SDHC：1，FSL_SDHC：2 从MMC加载环境... 卡未响应电压 我的主板是参考板，搭载 SabreSD 卡。 我拥有所有原理图和数据。 我不擅长这类任务，但我很想更新固件，体验一下新功能。

ファルコンモードのOP-TEE || iMX8MP_EVK こんにちは、 i.MX8MP EVKで、OP-TEEとFalcon Modeの両方を有効にしたいです。 マシン: imx8mpevk リポジトリ: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml 現在、私はmeta-imx-fastboot（lf-6.12.20-2.0.0-secure）を使用して、Falcon Mode経由で高速起動を実現しています。しかし、ファルコンモードが有効になっている場合、OP-TEEは無効になります。 私の要望としては、 OP-TEEとファルコンモードの両方を同時に有効にする必要があります。 i.MX8MP EVKのファルコンモードでOP-TEEを有効にする方法を教えていただけますか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @Sanjiv_Mns 現在、meta-imx-fastbootレイヤーはOP-TEEをサポートしていません。原理的には可能であるはずだが、まだ実現されていない。 説明: デフォルトの BSP では、OP-TEE の開始アドレスとサイズは、 rom_pointerに基づいて U-Boot の適切なブート ステージ中に計算されます (参照: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13) 。 SPLにおけるrom_pointerは、U-Boot本体とは異なる意味/値を持つ。SO、 ft_add_optee_node 関数はSPLからさらに変更なしで実行できません。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa OP-TEE→LinuxブートフローでSPLを達成するためにさらに進める方法→教えていただけませんか?これを確実に動作させるために必要な正しい手順と構成要素を理解したいです。 また、 STM32MP プラットフォームで同様のフローが実装されているリンクも見つけました。 https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ この方法が私のユースケースに適用できるのか、それとも一部を再利用したり、同じブートシーケンスを実現するために適応できるのか教えていただけますか? Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @Sanjiv_Mns i.MX 8MPでOP-TEEをFalconモードで有効化して実行することに成功しました。 i.MX 8MPのブートフローは、SPL -> ATF -> OP-TEE -> Linux となります 手順は以下の通りです。 1. meta-imx-fastboot レイヤーの conf/layer.conf ファイル から次の行を削除します。 MACHINE_FEATURES:remove = "optee" 2.imx-boot mkimageのソースコードにおいて、 iMX8M/mkimage_fit_atf_kernel.shスクリプトを修正し、OP-TEEバイナリをFITイメージに追加する。 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. カーネルデバイスツリーに、OP-TEEノード（ファームウェアと予約済みメモリ）を手動で追加します。imx8mp.dtsiデバイスツリーを編集して、以下の手順を実行してください。 - ルートノード（"/")に以下のOP-TEEファームウェアノードを追加します。 firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - OP-TEEの予約済みメモリ領域をreserved-memoryノードの下に追加します。 optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; }; 4. イメージを作成し、ブートデバイスに書き込みます。 5. OP-TEEが起動しLinuxがドライバーをプローブしたかを確認するには、以下を実行します: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6.OP-TEEをテストしたいなら xtestを実行することができます。 root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! イネーブルメント中に問題があれば、ぜひ教えてください。 ありがとうございます エレナ Re: OP-TEE in Falcon Mode || iMX8MP_EVK こんにちは、 @elena_popa この作業は既に完了しており、現在私のi.MX8MPボードで正常に起動しています。 現在の起動フローは以下のとおりです。 SPL → ATF → OP-TEE → Linux すべて想定通りに動作しています。@elena_popaさん、コメントありがとうございます。   [ 0.412349] OPEE:導管方法のプロービング。 [ 0.412373] optee: リビジョン 4.6 (788dc101B05ae47b) [ 0.412678] optee: 動的共有メモリが有効です [ 0.413062] optee: 初期化されたドライバ

S32K3MCU 发送慢通道 无法接收数据。 大家好 我正在使用 S32K311 的 SENT 接口接收数据，我遇到了这样一种情况：快通道正常接收数据，但慢通道无法接收任何数据。 我监测了 SENT 错误通知功能，没有发现任何异常。 MCU 型号为 S32K311 RTD 版本：S32DS 3.6.2RTD6.0.0 发送传感器：Sensata 压力传感器增强型慢速消息 首先，我知道 SENT 逻辑是在“Flexio_Sent_Ip_ProcessSerialMsg”函数中处理的，随后，在外层函数中，它会监测“Data->SerialState”和“FastMsgCount”变量，以确定慢通道是否已完成接收数据。 于是，我捕获了相关的比特信息。 bit(x)：已发送快速通道状态半字节位 S: " STATUS_SENT_SERIAL_SHORT" 。 E：" STATUS_SENT_SERIAL_ENHANCED" 我发现慢速通道的解析逻辑反复跳转，无法正常解析。 在特定情况下，SENT 的处理逻辑是否存在错误？ 谢谢！ Re: S32K3MCU SENT slow channel Cannot receive data. SOC端有任何错误日志吗？ Re: S32K3MCU SENT slow channel Cannot receive data. 你好@khty ， 能否分享一下Sensata传感器的发送配置信息？从你的图片中，我可以看到第 8 位 C 位被设置为 0；我假设使用的是 8 位消息 ID，12 位数据格式。 由于您的快速通道已正确接收，并且没有报告 SENT 错误通知，因此我了解到问题与处理功能有关。 我尚未发现任何关于频道接收速度慢的已知问题；但是，我已经与内部团队展开了讨论，让我尝试获取有关此问题的更多信息。 最后，您能否提供至少 18 个连续的 SENT 帧的完整捕获文件？这样我们就可以进一步检查RTD状态机的行为是否与预期的增强型串行解码序列相匹配。 此致， 朱利安 Re: S32K3MCU SENT slow channel Cannot receive data. 您好，感谢您快速回复我的问题。 Sensata提供的传感器配置信息如下图所示： 关于您最后一个要求，我需要至少连续 18 个 SENT 帧的完整捕获数据。我已经将其放在“bitChange.xlsx”文件中。文件在附录中。 我在表格中显示了每个捕获的状态半字的第二位和第三位。 表格中，每一列代表一条已发送的消息。每个大的黑色方框内包含一条 slowChannel 消息。蓝色区域为ID区域，绿色区域为CRC校验区域，黄色区域为数据区域。底部的信息为人工分析结果。 如果您需要任何其他信息，请告诉我，我会尽快回复。 Re: S32K3MCU SENT slow channel Cannot receive data. 发送的快速错误通知和慢速错误通知均未报告任何故障。 您可以读取记录在“bitchange.xlsx”中的数据。用于分析，因为它包含我记录的快速通道的每个状态半字的第 2 位和第 3 位的信息。Bit1 和 Bit0 信息被丢弃，因为它们在慢速信道中没有意义。 同时，我手动解析了慢速频道信息，并用黑色方块进行了标识。 在“bitchange.xlsx”中，“State”行中的数据对应于代码中的“ Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState ”。它负责检测和识别慢通道是“短”还是“增强”。“计数”代表“ Flexio_Sent_Ip_axFastData[Instance][ChannelId].FastMsgCount ”，它负责计算慢速通道的接收长度。 我认为我们没有收到任何慢通道数据的原因是代码无法正确识别慢通道是“短”通道还是“增强”通道。您可以阅读“bitchange.xlsx”来发现识别状态在“ STATUS_SENT_SERIAL_IDLE ”、“ STATUS_SENT_SERIAL_SHORT ”和“ STATUS_SENT_SERIAL_ENHANCED ”之间不断跳转。 当识别状态发生转换时，“ Flexio_Sent_Ip_ProcessSerialMsg ()”函数返回“ STATUS_FLEXIO_SENT_IP_ERROR ”，但该返回值仅重置了上层函数“ Flexio_Sent_Ip_DmaDataProcessing ()”中的SerialState和FastMsgCount ，并未调用SentFastErrorNotif ()。因此，我无法通过快速错误通知获取任何错误信息。 在“bitChange.xlsx”中 我们可以从 T 列开始，此时SerialState = STATUS_SENT_SERIAL_IDLE ， FastMsgCount = 0。 当我们收到 U 列时， Flexio_Sent_Ip_ProcessSerialMsg()认为 bit3 == 1，因此它将其视为慢通道的开始信号，并将SerialState设置为STATUS_SENT_SERIAL_SHORT ， FastMsgCount设置为 1。 当我们收到 V 列时， Flexio_Sent_Ip_ProcessSerialMsg () 认为 bit3 == 0，因此它保持SerialState = STATUS_SENT_SERIAL_SHORT并将FastMsgCount加 2。 当我们收到 W 列时， Flexio_Sent_Ip_ProcessSerialMsg () 认为 bit3 == 1。此时，由于FastMsgCount == 2，不满足跳转到STATUS_SENT_SERIAL_ENHANCED 的条件，只能返回STATUS_FLEXIO_SENT_IP_ERROR 。在Flexio_Sent_Ip_DmaDataProcessing () 中，它会重置SerialState和FastMsgCount 。 顺便说一下，我使用 DMA 接收 SENT 数据，目前只确认了 DMA 接收方式存在问题。目前，我无法确认中断和轮询方法是否也存在同样的问题。 Re: S32K3MCU SENT slow channel Cannot receive data. 嗨@khty ， 感谢您提供的补充信息。这样就更清楚了。 这似乎表明解析增强型慢消息时可能存在 RTD 问题，但是，由于我没有特定的硬件配置，因此我无法重现该问题。 我已经将此信息转发给内部团队，如有任何新消息，我会及时通知您。 此致， 朱利安

DDR 工具发送 pmic_set 命令失败。 您好， 目前，我正在尝试在 DDR Tool 中调整 PCA9450C 的 BUCK6 输出电压，但我遇到了一个问题。 我将以下命令烧录到 i.MX8M Plus 开发板上，并确认 PCA9450C 确实已连接到 I2C1： 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x000001C6 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x000001C6 # I2C1_SDA 焊盘 sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 下载完 .ds 文件后文件执行后，UART 控制台返回了以下日志： PMIC 在 DDR 脚本中初始化 I2C_I2SR(0x30a2000c):0x81 总线还没准备好 错误：PMIC 寄存器[0x1e]初始化失败，值为[0x11] 用示波器检查 I2C1 SCL 和 SDA 线时，我发现两条线都被拉低并锁存。只有在断电重启后，它们才会恢复到默认的高电平状态。 此外，我已经验证，如果我注释掉 #sysparam 命令，就可以在 I2C 总线上成功观察到默认的 PMIC 初始化波形，并且 UART 日志正确地表明 PCA9450 已被检测到。 Re: Failed to send the pmic_set command in the DDR Tool. 我找到了根本原因。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) 和 IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) 寄存器未配置。我建议将这些细节添加到应用笔记中，以供将来参考。谢谢！” Re: Failed to send the pmic_set command in the DDR Tool. 注释掉#sysparam后，我使用示波器捕获了 i.MX8M Plus 写入 PCA9450C 的默认配置。捕获到的序列如下： 0x25W，0x00 0x25R，0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 基于这些发现，我将这些命令添加到了 .ds 文件中。文件： # 2. IOMUX 配置。（SION=1，ODE=1，内部上拉） 内存集 0x30330200 32 0x00000010 # I2C1_SCL 多路复用器 (SION=1) 内存集 0x30330204 32 0x00000010 # I2C1_SDA 多路复用器 (SION=1) 内存集 0x30330460 32 0x00000176 # I2C1_SCL 焊盘 内存集 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC 地址 sysparam set pmic_set 0x0C29 # 将 BUCK1 和 BUCK3 设置为 0.85V，将 BUCK2 设置为 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V 系统参数设置 pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59（通过 PMIC_STBY_REQ 进行 DVS 控制） sysparam set pmic_set 0x1E11 # BUCK6 设置为 1.025V 然而，UART 控制台仍然卡在这个阶段。与之前略有不同，它不再抛出任何错误信息，而是直接停止运行： 下载完成 等待目标板启动…… 使用示波器检查 I2C1 SCL 和 SDA 线时，其行为与之前相同：两条线都被拉低并锁定，只有在断电重启后才会恢复到默认的高电平状态。 Re: Failed to send the pmic_set command in the DDR Tool. 如果禁用预配置的 PMIC 初始化，则需要手动完成所有操作。 在i.MX 93 EVK板上，默认的 PMIC I2C 总线是 I2C 2。 要将其更改为 I2C 1，您需要设置正确的引脚复用： 然后你需要发送正确的命令：（例如） 命令说明： 数量 Command Value 说明 0 pmic_cfg 0x0025 I2C总线1 （0 代表 I2C1，1 代表 I2C2，2 代表 I2C3，3 代表 I2C4……） PMIC 地址 0x25 1 pmic_set 0x0C29 寄存器=0x0C BUCKxOUT_DVS0/1 预设降压电压1=0.8V，preset_buck2=0.7V，预设降压3=0.8VPCA9451_BUCK123_DVS 值=0x29 2 pmic_set 0x1118 寄存器=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 值=0x18 3 pmic_set 0x1718 寄存器=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 值=0x18 4 pmic_set 0x1428 寄存器=0x14 将 VDDQ 设置为 1.1V PCA9451_BUCK2OUT_DVS0 值=0x28 BUCK6 设置将位于寄存器 0x1D 和 0x1E 中。 希望对您有所帮助。 伯恩哈德。 Re: Failed to send the pmic_set command in the DDR Tool. 哦，对了，就是著名的DAISY收银机。抓得好！ 选择自定义配置时，所有设置都需要手动完成。你说得对，在引脚配置方面，DAISY 寄存器并不是重点。对于 UART 引脚复用设置，除了标准的引脚复用和焊盘设置外，它还出现在 RX 信号的 ds 中。但对于 I2C，固件会在后台进行默认配置，您在 ds 文件中看不到这些设置。 顺便提一下，对于 i.MX 93，I2C1 和 I2C2 没有 DAISY 链寄存器，但 I2C3-8 有。 我会将您的反馈意见反馈给我们的工具组，这个细节应该包含在配置工具的用户手册中。或者，或者此外，I2C 接口设置应该出现在 ds 文件中。 问候， 伯恩哈德。

Failed to send the pmic_set command in the DDR Tool. Hi, Currently, I am trying to adjust the BUCK6 output voltage of the PCA9450C in the DDR Tool, but I have run into an issue. I flashed the following commands onto the i.MX8M Plus board and confirmed that the PCA9450C is indeed connected to I2C1: memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x000001C6 # I2C1_SCL PAD memory set 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 After downloading the .ds file, the UART console responded with the following logs: PMIC is initialized in DDR script I2C_I2SR(0x30a2000c):0x81 bus is not ready Error: PMIC reg[0x1e] initilaization failed with value[0x11] When checking the I2C1 SCL and SDA lines with an oscilloscope, I observed that both lines are pulled low and latched. They only return to their default pulled-high state after a power cycle. Furthermore, I have verified that if I comment out the #sysparam commands, I can successfully observe the default PMIC initialization waveforms on the I2C bus, and the UART log correctly indicates that the PCA9450 has been detected. Re: Failed to send the pmic_set command in the DDR Tool. I have found the root cause. The IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) and IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) registers were not configured. I suggest adding this details to the application note for future reference. Thanks!" Re: Failed to send the pmic_set command in the DDR Tool. After commenting out #sysparam I used an oscilloscope to capture the default configurations that the i.MX8M Plus writes to the PCA9450C. The captured sequence is as follows: 0x25W, 0x00 0x25R, 0x31 0x25W, 0x0C, 0x29 0x25W, 0x11, 0x1C 0x25W, 0x12, 0x14 0x25W, 0x10, 0x59 0x25W, 0x1E, 0x14 Based on these findings, I appended these commands to the .ds file: # 2. IOMUX config. (SION=1, ODE=1, internal pull up) memory set 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) memory set 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) memory set 0x30330460 32 0x00000176 # I2C1_SCL PAD memory set 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMIC address sysparam set pmic_set 0x0C29 # BUCK1&3 set to 0.85V, BUCK2 set to 0.9V sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam set pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (DVS control through PMIC_STBY_REQ) sysparam set pmic_set 0x1E11 # BUCK6 set to 1.025V However, the UART console still gets stuck at this stage. Slightly different from before, it no longer throws any error messages, and just stops here: Download is complete Waiting for the target board boot... When checking the I2C1 SCL and SDA lines with an oscilloscope, the behavior remains the same as before: both lines are pulled low and latched, and they only return to their default pulled-high state after a power cycle. Re: Failed to send the pmic_set command in the DDR Tool. If you disable the pre-configured PMIC initialisation, you need to do everything by hand. On the i.MX 93 EVK board, the default PMIC I2C Bus is I2C2. To change it to I2C1, you need to set the right pinmux: Then you need to send the right commands: (example) Explanation of the commands: # Command Value Description 0 pmic_cfg 0x0025 I2C bus 1 (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) PMIC address 0x25 1 pmic_set 0x0C29 register=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS value=0x29 2 pmic_set 0x1118 register=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 value=0x18 3 pmic_set 0x1718 register=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 value=0x18 4 pmic_set 0x1428 register=0x14 Set VDDQ to 1.1V PCA9451_BUCK2OUT_DVS0 value=0x28 BUCK6 settings would be in registers 0x1D and 0x1E. Hope it helps, Bernhard. Re: Failed to send the pmic_set command in the DDR Tool. Oh yes, the famous DAISY register. Good catch!  When a custom configuration is selected, EVERYTHING needs to be set by hand. And you're right, the DAISY registers are not really in the focus when it comes to pin configurations. For the UART pin mux settings it appears in the ds for the RX signal, besides the  standard pin mux and pad settings. But for I2C the firmware is doing it as a default configuration in the background, you don't see the settings in the ds file. As a side note, for the i.MX 93, the DAISY chain register does not exist for I2C1 and I2C2, but it does for I2C3-8. I feed you input back into our tool group, this detail should be part of the User's Manual for the Config Tool. Alternatively, or in addition, the I2C interface settings should appear in the ds file. Regards, Bernhard.

OP-TEE in Falcon Mode || iMX8MP_EVK Hi, I want to enable OP-TEE along with Falcon Mode on the i.MX8MP EVK. Machine: imx8mpevk Repository: https://github.com/nxp-imx/imx-manifest Branch: imx-linux-walnascar XML: imx-6.12.34-2.1.0.xml Currently, I am using meta-imx-fastboot (lf-6.12.20-2.0.0-secure) to achieve fast boot via Falcon Mode. However, when Falcon Mode is enabled, OP-TEE gets disabled. As per my requirement, I need both OP-TEE and Falcon Mode to be enabled simultaneously. Could you please guide me on how to enable OP-TEE in Falcon Mode on the i.MX8MP EVK? i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Security Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  Currently, the meta-imx-fastboot layer does not support OP-TEE. It should be possible in principle, but it is not implemented yet. Explanation: In the default BSP, the OP-TEE start address and size are calculated during the U-Boot proper boot stage based on the rom_pointer (see: https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13). The rom_pointer has different meaning/values in the SPL, compared to U-Boot proper. So, the ft_add_optee_node function cannot be executed from SPL without further changes. Thanks, Elena Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa  Could you please guide me on how to proceed further to achieve the SPL → OP-TEE → Linux boot flow? I’d like to understand the correct steps and components involved to make this work reliably. I also came across the following link where a similar flow was implemented on STM32MP platforms: https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ Could you please let me know whether this approach is applicable to my use case, or if parts of it can be reused or adapted for achieving the same boot sequence on my platform? Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @elena_popa I have already completed this activity, and it is now booting successfully on my i.MX8MP board. The current boot flow is: SPL → ATF → OP-TEE → Linux Everything is working as expected. Thank you for your comments @elena_popa   [ 0.412349] optee: probing for conduit method. [ 0.412373] optee: revision 4.6 (788dc101b05ae47b) [ 0.412678] optee: dynamic shared memory is enabled [ 0.413062] optee: initialized driver Re: OP-TEE in Falcon Mode || iMX8MP_EVK Hi @Sanjiv_Mns  I managed to enable and run OP-TEE in Falcon Mode for i.MX 8MP.  The boot flow on i.MX 8MP will be: SPL -> ATF -> OP-TEE -> Linux Here are the steps: 1. Remove the following line in the conf/layer.conf of the meta-imx-fastboot layer. MACHINE_FEATURES:remove = "optee"  2. In imx-boot mkimage source code, modify the iMX8M/mkimage_fit_atf_kernel.sh script to add the OP-TEE binary into the FIT image. 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. In the kernel device tree, add manually the OP-TEE nodes (firmware and reserved memory). Edit the imx8mp.dtsi device tree and: - add the following OP-TEE firmware node in the root node ("/"). firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - add the OP-TEE reserved memory regions under the reserved-memory node: optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; };  4. Build the image and write it on the boot device. 5. To check that OP-TEE has started and Linux probed the driver, run: root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6. If you want to test the OP-TEE you can run xtest. root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! Please, let me know if you have issues during enablement. Thanks, Elena

カーネル6.6.92ではPN7160が応答しません 当チームはPN7160をカーネル6.6.92に移植しました。 しかし現在、NFCタグを 読み取ることができません 。 以下は、当社の被試験デバイス（DUT）に関する情報です。 カーネルバージョン: 6.6.92 OS: ヨクト・スカースギャップ PN7160 ドライバーパッチファイル: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch（NFCのGitHubリポジトリからクローンし、カーネル6.6に対応するように修正しました） nfcDemoApp レシピ: recipes-nfc.7z (NFC GitHub からクローンし、ビルドエラーを修正するために変更しました) カーネルログ: nfc-log.txt この問題を解決するためのアドバイスをいただけますか? 回复： PN7160 no response with kernel 6.6.92 libnfc-nxp.conf ファイルで LOGLEVEL を 0x03 に設定してください。次に、nfcDemoAppを実行したときのログを送ってください。確認のため、libnfc-nci.confとlibnfc-nxp.confも送ってください。

LSDK 25.12 udev 自动加载与 /boot/modules 布局的竞争 NXP团队您好， 我们使用的环境如下： * 平台：i.MX8MP * 发行版：Debian 13 / trixie * LSDK 版本：LSDK-25.12_DEBIAN-13_LF-6.12.20 * 内核版本：6.12.20 * systemd / udev: 257.x * kmod / libkmod：34.x 我们遇到了一个间歇性的冷启动问题，其中某些内核模块无法通过 udev 自动加载。就我们而言，受影响的设备主要是音频编解码器/音频链和 WLAN 模块。 症状包括： * `snd_soc_wm8962` 未加载 音频编解码器和音频平台设备仍然不受限制 `aplay -l` 报告没有声卡 * 无线局域网接口缺失 * 启动后手动运行 `modprobe` 或 `udevadm trigger --action=add` 可以恢复设备。 经过调试，我们发现该问题似乎与此 flexbuild 版本使用的内核模块布局有关。 在 `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild 标签中，`configs/debian/debian_post_config.sh`创建以下符号链接： ```sh ln -sf /boot/modules /lib/modules ``` 此外，`tools/create_bootpartition` 会将内核模块复制到启动分区： ```sh cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir ``` 因此，在运行时，`/lib/modules` 依赖于 `/boot/modules`，而 `/boot` 稍后由 `boot.mount` 挂载。 我们还注意到 `src/system/启动.mount`包含： ```ini [Unit] Description=启动分区 Before=systemd-modules-load.service [山] What=UUID=PARTUUID 地点=/启动 类型=ext4 选项=默认值 [安装] WantedBy=local-fs.target ``` 这似乎是为了确保在由 `systemd-modules-load.service` 处理的静态模块加载路径之前挂载 `/boot`。 然而，我们的问题并非出在 `systemd-modules-load.service` 上。受影响的音频/WLAN模块由udev通过设备`MODALIAS`事件动态加载。 在启动失败的情况下，我们观察到受影响的设备事件是在 `boot.mount` 之前由 udev 处理的。已完成。此时，`/lib/modules` 指向 `/boot/modules`，但 `/boot` 尚未挂载。因此，libkmod 无法访问模块别名/索引文件或相应的 `.ko` 文件，所以 udev 模块自动加载路径失败。由于 udev 事件已被处理，除非我们手动重新触发 udev 或运行 `modprobe`，否则驱动程序不会再加载。 我们对失败路径的理解是： ```文本 内核设备添加事件 → udev 接收到 MODALIAS 事件 → udev/libkmod 尝试访问 /lib/modules → /lib/modules 指向 /boot/modules。 → /boot 尚未挂载 → 模块别名/索引文件或 .ko 文件文件不可用 → 模块自动加载失败 ``` 我们想确认以下事项： 1. 对于 LSDK 25.12 Debian 13 版本，`/lib/modules -> /boot/modules` 的布局是否符合预期？ 2. 早期 udev 的 `MODALIAS` 处理和后期的 `boot.mount` 处理之间存在竞争关系吗？这是该布局的已知问题或已知局限性吗？ 3. 我们注意到，当前的上游 flexbuild 主分支似乎已经改变了这种架构：内核模块不再通过 `create_bootpartition` 复制到启动分区，并且 `debian_post_config.sh` 中不再创建 `/lib/modules -> /boot/modules` 符号链接。 这种架构变更是否与避免这种早期启动模块自动加载竞争有关？ 4. 对于 LSDK 25.12 Debian 13，NXP 针对此问题推荐的修复方案或变通方法是什么？ 请与我们联系，告知我们我们的理解是否正确，以及该版本是否有官方补丁或推荐的更新途径。 谢谢。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: LSDK 25.12 udev autoload race with /boot/modules layout 您好， Q1：这样做的初衷是将内核映像和模块放在启动分区上，这样在升级内核时，只需要替换启动分区，而无需修改根文件系统。这种布局是故意设计的，并非错误。 Q2：你的推理是正确的；这是这种布局固有的局限性。 Q3：构建镜像时，您可以进行一次性调整，将根文件系统中的 `/boot/modules` 内容移动到 `/lib/modules`，并删除符号链接： rm -f /lib/modules mkdir -p /lib/modules cp -a /boot/modules/* /lib/modules/ 同时， 1. 修改构建脚本中的 `tools/create_bootpartition`，并删除 `cp -rf .../lib/modules $bootpartdir` 这行； 2. 修改 `debian_post_config.sh` 文件，并删除 `ln -sf /boot/modules /lib/modules` 这行； 3. 配置 `bld linux / modules_install` 目标，将模块安装到根文件系统中（参见 `main` 分支中 ` linux-modules`目标的实现）。 此致， 志明

S32K3MCU SENT slow channel Cannot receive data. Hello everyone I am using the SENT interface of the S32K311 to receive data, and I have encountered a situation where the fast channel receives data normally, but the slow channel is unable to receive any data. And I monitor the SENT error notification function, there are no exceptions. The MCU is S32K311 RTD version :S32DS 3.6.2 RTD6.0.0 SENT Sensor: Sensata Pressure Sensor Enhanced Slow message Firstly, I know that the SENT logic is processed in the "Flexio_Sent_Ip_ProcessSerialMsg" function, and subsequently, in the outer layer function, it monitors the "Data->SerialState" and "FastMsgCount" variables to determine if the slow channel has completed receiving data. So, I captured the relevant bit information. bit(x) : SENT Fast Channel Status Nibble bit S : "STATUS_SENT_SERIAL_SHORT". E : "STATUS_SENT_SERIAL_ENHANCED" I discovered that the parsing logic for the slow channel is repeatedly jumping and cannot be parsed normally. Does the processing logic of SENT have any errors when in a certain situation? thanks Re: S32K3MCU SENT slow channel Cannot receive data. any error log from SOC side？ Re: S32K3MCU SENT slow channel Cannot receive data. Hello @khty, Could you share the Sensata sensor's sent configuration? From your images, I can see bit C in position 8 is set as 0; I assume 8-bit message ID, 12-bit data format is being used. Since your fast channel is received correctly and no SENT error notification is reported, I understand the issue is related to the processing function. I've not been able to find any known issues regarding slow channel reception; however, I've triggered a discussion with the internal team, let me try and get further information regarding this issue. Finally, are you able to provide a full capture of at least 18 consecutive SENT frames? This way we can further check whether the RTD state machine behavior matches the expected enhanced serial decoding sequence. Best regards, Julián Re: S32K3MCU SENT slow channel Cannot receive data. hello，and thank you for your quick response to my question. The sensor configuration information provided by Sensata is shown in the following figure: For your last request, a full capture of at least 18 consecutive SENT frames.I have provided it in the "bitChange.xlsx" file in the appendix. I have displayed the second and third bits of each captured status half-word in the table. In the table, each column represents a SENT message. Each large black square frame encompasses one slowChannel message. The blue area is the ID region, the green area is the CRC region, and the yellow area is the data region.And the information at the bottom is the result of manual analysis. If you need any additional information, please let me know, and I will respond as soon as possible. Re: S32K3MCU SENT slow channel Cannot receive data. The FAST Error Notification and SLOW Error Notification of SENT have reported no faults. You can read the data recorded in "bitchange.xlsx" for analysis, as it contains information on the 2 and 3 bits of each status half-word of the fast channel that I have recorded. Bit1 and Bit0 information are discarded because they have no meaning in the slow channel. At the same time, I have manually parsed the slow channel information and identified it with black squares. In "bitchange.xlsx", the data in the "State" row corresponds to "Flexio_Sent_Ip_axFastData[Instance][ChannelId].SerialState" in the code. This is responsible for detecting and identifying whether the slow channel is "Short" or "Enhanced". The "count" represents "Flexio_Sent_Ip_axFastData[Instance][ChannelId].FastMsgCount", which is responsible for counting the receive length of the slow channel. I believe the reason we are not receiving any Slow Channel data is that the code cannot correctly identify whether the slow channel is "Short" or "Enhanced". You can read "bitchange.xlsx" to discover that the identification state is constantly jumping between "STATUS_SENT_SERIAL_IDLE", "STATUS_SENT_SERIAL_SHORT", and "STATUS_SENT_SERIAL_ENHANCED". When the identification state transitions, the "Flexio_Sent_Ip_ProcessSerialMsg()" function returns "STATUS_FLEXIO_SENT_IP_ERROR", but this return value is only resetting SerialState and FastMsgCount in the upper-level function "Flexio_Sent_Ip_DmaDataProcessing()", and it does not call SentFastErrorNotif(). Therefore, I cannot obtain any error information through the fast Error Notification. In “bitChange.xlsx” We can start from column T, at this time SerialState = STATUS_SENT_SERIAL_IDLE, FastMsgCount = 0. When we receive column U, Flexio_Sent_Ip_ProcessSerialMsg()  believes bit3 == 1, so it considers this a start signal for slow channel and sets SerialState = STATUS_SENT_SERIAL_SHORT and FastMsgCount = 1. When we receive column V,Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 0, so it keeps SerialState = STATUS_SENT_SERIAL_SHORT and increments FastMsgCount = 2. When we receive column W, Flexio_Sent_Ip_ProcessSerialMsg() believes bit3 == 1. At this point, since FastMsgCount == 2, it does not meet the condition to jump to STATUS_SENT_SERIAL_ENHANCED, and can only return STATUS_FLEXIO_SENT_IP_ERROR. In Flexio_Sent_Ip_DmaDataProcessing(), it resets SerialState and FastMsgCount. By the way, I am using DMA to receive SENT data, and I have only confirmed that there is an issue with the DMA reception method. At present, I cannot confirm whether the interrupt and polling methods also have the same problem. Re: S32K3MCU SENT slow channel Cannot receive data. Hi @khty, Thank you for the additional information. This makes it clearer.  This does seem to point to a potential RTD issue for parsing enhanced slow messages, however, since I lack the specific HW setup, I have not been able to reproduce the issue. I've forwarded this information to the internal team, and I will keep you updated on any new information. Best regards, Julián

LSDK 25.12 udev autoload race with /boot/modules layout Hi NXP team, We are using the following environment: * Platform: i.MX8MP * Distribution: Debian 13 / trixie * LSDK release: LSDK-25.12_DEBIAN-13_LF-6.12.20 * Kernel: 6.12.20 * systemd / udev: 257.x * kmod / libkmod: 34.x We encountered an intermittent cold boot issue where some kernel modules are not automatically loaded by udev. In our case, the affected devices are mainly the audio codec/audio chain and WLAN module. The symptoms include: * `snd_soc_wm8962` is not loaded * the audio codec and audio platform devices remain unbound * `aplay -l` reports no sound cards * the WLAN interface is missing * manually running `modprobe` or `udevadm trigger --action=add` after boot can recover the devices After debugging, we found that the issue seems related to the kernel module layout used by this flexbuild release. In the `LSDK-25.12_DEBIAN-13_LF-6.12.20` flexbuild tag, `configs/debian/debian_post_config.sh` creates the following symlink: ```sh ln -sf /boot/modules /lib/modules ``` Also, `tools/create_bootpartition` copies the kernel modules into the boot partition: ```sh cp -rf $KERNEL_OUTPUT_PATH/$KERNEL_BRANCH/tmp/lib/modules $bootpartdir ``` Therefore, at runtime, `/lib/modules` depends on `/boot/modules`, and `/boot` is mounted later by `boot.mount`. We also noticed that `src/system/boot.mount` contains: ```ini [Unit] Description=Boot Partition Before=systemd-modules-load.service [Mount] What=UUID=PARTUUID Where=/boot Type=ext4 Options=defaults [Install] WantedBy=local-fs.target ``` This appears to ensure that `/boot` is mounted before the static module loading path handled by `systemd-modules-load.service`. However, our issue is not from `systemd-modules-load.service`. The affected audio/WLAN modules are loaded dynamically by udev through device `MODALIAS` events. In failing boots, we observed that the affected device events are processed by udev before `boot.mount` has completed. At that moment, `/lib/modules` points to `/boot/modules`, but `/boot` has not been mounted yet. As a result, libkmod cannot access the module alias/index files or the corresponding `.ko` files, so the udev module auto-loading path fails. Since the udev event has already been processed, the driver is not loaded later unless we manually retrigger udev or run `modprobe`. Our understanding of the failing path is: ```text kernel device add event → udev receives the MODALIAS event → udev/libkmod tries to access /lib/modules → /lib/modules points to /boot/modules → /boot is not mounted yet → module alias/index files or .ko files are not available → module auto-loading fails ``` We would like to confirm the following: 1. Is the `/lib/modules -> /boot/modules` layout expected for the LSDK 25.12 Debian 13 release? 2. Is the race between early udev `MODALIAS` handling and the later `boot.mount` a known issue or known limitation of this layout? 3. We noticed that the current upstream flexbuild main branch appears to have changed this architecture: kernel modules are no longer copied into the boot partition by `create_bootpartition`, and the `/lib/modules -> /boot/modules` symlink is no longer created in `debian_post_config.sh`. Is this architecture change related to avoiding this kind of early boot module auto-loading race? 4. For LSDK 25.12 Debian 13, what is NXP’s recommended fix or workaround for this issue? Please let us know whether our understanding is correct and whether there is an official patch or recommended update path for this release. Thanks. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: LSDK 25.12 udev autoload race with /boot/modules layout Hi, Q1: The original intention behind this was to place the kernel image and modules together on the boot partition, so that when upgrading the kernel, only the boot partition needs to be replaced, without having to modify the root filesystem. This layout is intentional and is not a bug. Q2:Your line of reasoning is correct; this is an inherent limitation of this layout. Q3: When building the image, you can make a one-time adjustment to move the contents of `/boot/modules` to `/lib/modules` in the root filesystem and remove the symbolic links: rm -f /lib/modules mkdir -p /lib/modules cp -a /boot/modules/* /lib/modules/ At the same time, 1. modify `tools/create_bootpartition` in the build script and remove the line `cp -rf .../lib/modules $bootpartdir`;  2. Modify `debian_post_config.sh` and remove the line `ln -sf /boot/modules /lib/modules`;  3. Configure the `bld linux / modules_install` target to install modules into the root filesystem (see the implementation of the `linux-modules` target in the `main` branch). Best Regards, Zhiming

DDRツールでpmic_setコマンドの送信に失敗しました。 こんにちは、 現在、DDR ToolでPCA9450CのBUCK6出力電圧を調整しようとしていますが、問題が発生しました。 以下のコマンドをi.MX8M Plusボードに書き込み、PCA9450Cが確かにI2C1に接続されていることを確認しました: メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x000001C6 # I2C1_SCL PAD メモリセット 0x30330464 32 0x000001C6 # I2C1_SDA PAD sysparam set pmic_cfg 0x004A sysparam set pmic_set 0x1E11 .dsファイルをダウンロードした後ファイルに対して、UARTコンソールは以下のログを出力しました。 PMICはDDRスクリプトで初期化されます I2C_I2SR(0x30a2000c):0x81 バスはまだ準備ができていません エラー: PMIC reg[0x1e] の初期化が値[0x11]で失敗しました オシロスコープでI2C1のSCLとSDAラインをチェックしたところ、両方のラインがプルダウンされてラッチされていることが確認できました。それらは電源を再投入した後にのみ、デフォルトのプルアップ状態に戻ります。 さらに、#sysparam コマンドをコメントアウトすると、I2Cバス上のデフォルトのPMIC初期化波形を正常に観察でき、UARTログもPCA9450が検出されたことを正しく示しています。 Re: Failed to send the pmic_set command in the DDR Tool. 根本原因を突き止めました。IOMUXC_I2C1_SDA_IN_SELECT_INPUT (0x303305A4) および IOMUXC_I2C1_SCL_IN_SELECT_INPUT (0x303305A8) レジスタが設定されていません。この詳細は将来の参考のためにアプリケーションノートに添付することをお勧めします。ありがとう！" Re: Failed to send the pmic_set command in the DDR Tool. #sysparamをコメントアウトした後、オシロスコープを使用して、i.MX8M Plus が PCA9450C に書き込むデフォルト設定をキャプチャしました。キャプチャされたシーケンスは以下のとおりです。 0x25W、0x00 0x25R、0x31 0x25W、0x0C、0x29 0x25W、0x11、0x1C 0x25W、0x12、0x14 0x25W、0x10、0x59 0x25W、0x1E、0x14 これらの調査結果に基づき、私は.dsファイルに以下のコマンドを追加しました。ファイル： # 2. IOMUX 設定。(SION=1、ODE=1、内部プルアップ) メモリ設定 0x30330200 32 0x00000010 # I2C1_SCL MUX (SION=1) メモリセット 0x30330204 32 0x00000010 # I2C1_SDA MUX (SION=1) メモリセット 0x30330460 32 0x00000176 # I2C1_SCL PAD メモリセット 0x30330464 32 0x00000176 # I2C1_SDA PAD sysparam set pmic_cfg 0x0025 # PMICアドレス sysparam set pmic_set 0x0C29 # BUCK1&3を0.85Vに設定、BUCK2を0.9Vに設定 sysparam set pmic_set 0x111C # BUCK1 DVS0 = 0.95V sysparam セット pmic_set 0x1214 # BUCK1 DVS1 = 0.85V sysparam set pmic_set 0x1059 # BUCK1CTRL = 0x59 (PMIC_STBY_REQ を介した DVS 制御) sysparam set pmic_set 0x1E11 # BUCK6 を 1.025V に設定 しかし、UARTコンソールはこの段階で依然として停止してしまう。以前とは少し異なり、エラーメッセージは表示されなくなり、ここで停止します。 ダウンロードが完了しました ターゲットボードの起動を待っています... オシロスコープでI2C1のSCL線とSDA線をチェックしたところ、動作は以前と同じで、両方の線ともプルダウンされてラッチされており、電源を入れ直した後にのみデフォルトのプルアップ状態に戻ります。 Re: Failed to send the pmic_set command in the DDR Tool. 事前設定されたPMIC初期化を無効にすると、すべて手動で行う必要があります。 i.MX 93 EVKボードでは、デフォルトのPMIC I2CバスはI2C2です。 I2C 1に変更するには、適切なピンマルチプレクサを設定する必要があります。 次に、適切なコマンドを送信する必要があります。（例） コマンドの説明： 件 コマンド バリュー 説明 0 pmic_cfg 0x0025 I2Cバス1 (0はI2C1、1はI2C2、2はI2C3、3はI2C4…) PMICアドレス0x25 1 pmic_set 0x0C29 レジスタ=0x0C BUCKxOUT_DVS0/1 preset_buck1=0.8V、preset_buck2=0.7V、preset_buck3=0.8VPCA9451_BUCK123_DVS 値=0x29 2 pmic_set 0x1118 レジスタ=0x11 BUCK1OUT_DVS0=0.9V PCA9451_BUCK1OUT_DVS0 値=0x18 3 pmic_set 0x1718 レジスタ=0x17 BUCK3OUT_DVS0=0.9V PCA9451_BUCK3OUT_DVS0 値=0x18 4 pmic_set 0x1428 レジスタ=0x14 VDDQを1.1Vに設定 PCA9451_BUCK2OUT_DVS0値=0x28 BUCK6の設定は、レジスタ0x1Dと0x1Eに格納されます。 お役に立てば幸いです。 ベルンハルト。 Re: Failed to send the pmic_set command in the DDR Tool. ああ、そうそう、あの有名なDAISYレジスターですね。よく気づいたね！ カスタム設定を選択した場合、すべてを手動で設定する必要があります。おっしゃる通り、ピン構成に関しては、DAISYレジスタはあまり重要視されません。UARTピン多重化設定については、標準のピン多重化設定とパッド設定に加えて、RX信号のdsに表示されます。しかし、I2Cに関してはファームウェアがバックグラウンドでデフォルト設定として処理するため、dsファイルに設定内容は表示されません。 補足として、i.MX 93の場合、I2C1とI2C2にはDAISYチェーンレジスタは存在しませんが、I2C3～8には存在します。 この詳細はツールグループにフィードバックします。この詳細は設定ツールのユーザーマニュアルの一部になるべきです。あるいは、または追加して、I2Cインターフェースの設定がdsファイルに表示されるはずです。 よろしくお願いいたします。 ベルンハルト。

猎鹰模式下的 OP-TEE || iMX8MP_EVK 您好， 我想在 i.MX8MP EVK 上启用OP-TEE 和 Falcon 模式。 机器： imx8mpevk 代码库： https://github.com/nxp-imx/imx-manifest 分支： imx-linux-walnascar XML： imx-6.12.34-2.1.0.xml 目前，我使用meta-imx-fastboot (lf-6.12.20-2.0.0-secure)通过 Falcon 模式实现快速启动。但是，当启用猎鹰模式时，OP-TEE 将被禁用。 根据我的要求，我需要同时启用 OP-TEE 和 Falcon 模式。 请问如何在 i.MX8MP EVK 的 Falcon 模式下启用 OP-TEE？ i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 安全 Yocto Project Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 目前 meta-imx-fastboot 层不支持 OP-TEE。理论上是可行的，但目前尚未实现。 说明：在默认的 电路板支持包。 中，OP-TEE 的起始地址和大小是在 U-Boot 的正确启动阶段根据rom_pointer计算的（参见： https://github.com/nxp-imx/uboot-imx/blob/lf-6.12.20-2.0.0/arch/arm/mach-imx/dt_optee.c#L13） 。 与 U-Boot 本身相比，SPL 中的rom_pointer具有不同的含义/值。因此，如果不进行进一步修改，就无法从 SPL 执行ft_add_optee_node函数。 谢谢！ 埃琳娜 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 请问如何才能进一步实现SPL → OP-TEE → Linux启动流程？我想了解使其可靠运行所需的正确步骤和元器件。 我还找到了以下链接，其中在STM32MP平台上实现了类似的流程： https://patchwork.ozlabs.org/project/uboot/cover/[email protected]/ 请问这种方法是否适用于我的使用场景，或者其中的部分内容是否可以重复使用或修改，以在我的平台上实现相同的启动顺序？ Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@elena_popa 我已经完成了这项操作，现在它在我的 i.MX8MP 开发板上启动成功了。 当前启动流程如下： SPL → ATF → OP-TEE → Linux 一切运行正常。感谢你的评论@elena_popa   [ 0.412349] optee：探测管道方法。 [ 0.412373] optee：修订版 4.6 (788dc101b05ae47b) [ 0.412678] optee：动态共享内存已启用 [ 0.413062] optee：已初始化驱动程序 Re: OP-TEE in Falcon Mode || iMX8MP_EVK 嗨@Sanjiv_Mns 我成功地在 Falcon 模式下为 i.MX 8MP 启用并运行了 OP-TEE。 i.MX 8MP 的启动流程为：SPL -> ATF -> OP-TEE -> Linux 步骤如下： 1. 删除 meta-imx-fastboot 层的 conf/layer.conf 中的以下行。 MACHINE_FEATURES:remove = "optee" 2.在imx-boot mkimage 源代码中，修改iMX8M/mkimage_fit_atf_kernel.sh脚本，将 OP-TEE 二进制文件添加到 FIT 镜像中。 6a7,9 > # keep backward compatibility > [ -z "$TEE_LOAD_ADDR" ] && TEE_LOAD_ADDR="0xfe000000" > 19a23,41 > [ -z "$BL32" ] && BL32="tee.bin" > PAD=../scripts/pad_image.sh > > if [ ! -f $BL32 ]; then > BL32=/dev/null > else > echo "Building with TEE support, make sure $BL31 is compiled with spd. If you do not want tee, please delete $BL32" >&2 > if [ $TEE_COMPRESS_ENABLE ]; then > echo "Start compress $BL32" >&2 > rm -f $BL32.lz4 > lz4 -9 $BL32 $BL32.lz4 >&2 > BL32=$BL32.lz4 > ./$PAD $BL32 >&2 > fi > echo "$BL32 size: " >&2 > ls -lct $BL32 | awk '{print $5}' >&2 > LOADABLES="$LOADABLES, \"tee-1\"" > fi > 71a94,103 > tee-1 { > description = "TEE firmware"; > data = /incbin/("$BL32"); > type = "firmware"; > arch = "arm64"; > compression = "none"; > load = <$TEE_LOAD_ADDR>; > entry = <$TEE_LOAD_ADDR>; > }; > 87c119 < loadables = "kernel","dtb"; --- > loadables = "tee-1","kernel","dtb"; 3. 在内核设备树中，手动添加 OP-TEE 节点（固件和保留内存）。编辑imx8mp.dtsi设备树并： - 在根节点（“/”）中添加以下 OP-TEE 固件节点。 firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; }; }; - 在保留内存节点下添加 OP-TEE 保留内存区域： optee_core@56000000 { reg = <0 0x56000000 0 0x1e00000>; no-map; }; optee_shm@57e00000 { reg = <0 0x57e00000 0 0x200000>; no-map; }; 4. 构建镜像并将其写入启动设备。 5. 要检查 OP-TEE 是否已启动以及 Linux 是否已探测到驱动程序，请运行： root@imx8mp-lpddr4-evk:~# dmesg | grep optee [ 0.000000] OF: reserved mem: 0x0000000057e00000..0x0000000057ffffff (2048 KiB) nomap non-reusable optee_shm@57e00000 [ 0.000000] OF: reserved mem: 0x0000000056000000..0x0000000057dfffff (30720 KiB) nomap non-reusable optee_core@56000000 [ 2.581777] optee: probing for conduit method. [ 2.590862] optee: revision 4.8 (e7ed997213779e3d) [ 2.596363] optee: dynamic shared memory is enabled [ 2.601567] optee: initialized driver 6.如果你想测试 OP-TEE，你可以运行xtest 。 root@imx8mp-lpddr4-evk:~# xtest Run test suite with level=0 TEE test application started over default TEE instance ###################################################### # # regression+pkcs11+regression_nxp # ###################################################### * regression_1001 Core self tests o regression_1001.1 Core self tests regression_1001.1 OK o regression_1001.2 Core dt_driver self tests regression_1001.2 OK o regression_1001.3 Core transfer list self tests ..... +----------------------------------------------------- 49354 subtests of which 0 failed 161 test cases of which 0 failed 0 test cases were skipped TEE test application done! 如果您在启用过程中遇到任何问题，请告诉我。 谢谢！ 埃琳娜