Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
DSPI 通信超时问题 我正在使用带有SPI EEPROM的MPC5775B微控制器。在我的应用中,CAN 消息通过中断持续接收,与 EEPROM 的 SPI 通信也是通过中断驱动的。 在 CAN 总线流量较大的情况下(例如,每 1 毫秒接收 5 个 CAN ID),任何 EEPROM 读取操作都会开始超时。我正在使用DSPI_MasterTransferBlocking() API,超时时间为10 毫秒。我还尝试大幅增加超时值,但读取操作仍然失败。 有趣的是,这种行为取决于读取的数据量。当我尝试从 EEPROM 中读取几个字节时,SPI 传输超时。但是,当我读取整个 EEPROM 页(256 字节)时,读取操作成功完成。 我还观察到,如果 CAN 通信停止,EEPROM 读取操作可以顺利完成,没有任何问题。我已验证中断优先级,CAN 和 SPI 中断都配置为相同的优先级(优先级 0)。 我想了解: 为什么在 CAN 中断负载较大时,小尺寸 SPI EEPROM 读取操作会超时,而大尺寸(256 字节)页面读取却能成功完成? 这是否与中断饥饿、DSPI_MasterTransferBlocking() 的实现或 CAN 和 DSPI 中断处理程序之间的交互有关? 在 MPC5775B 上同时使用中断驱动的 DSPI 传输和高频 CAN 中断是否存在任何已知的限制或推荐配置? 此外,我在调试过程中通过在 DSPI_MasterTransferBlocking() 函数内部设置断点来调试这个问题。 status_t DSPI_MasterTransferBlocking(dspi_instance_t instance, const void * sendBuffer, void * receiveBuffer, uint16_t 帧, uint32_t 超时) { DEV_ASSERT((uint32_t)实例 < (SPI_INSTANCE_COUNT + DSPI_INSTANCE_COUNT)); status_t status; dspi_state_t * state = DSPI_state[instance]; 如果 (state->status == DSPI_IN_PROGRESS) { 返回 STATUS_BUSY; } state->isBlocking = true; (void)OSIF_SemaWait(&(state->dspiSemaphore), 0); status = DSPI_MasterTransfer(instance, sendBuffer, receiveBuffer, frames); 如果(状态 == STATUS_SUCCESS) { status = OSIF_SemaWait(&(state->dspiSemaphore), timeout); 如果(状态 != STATUS_SUCCESS) { (void)DSPI_AbortTransfer(实例); state->status = DSPI_TRANSFER_FAIL; 返回状态; } } 返回 STATUS_SUCCESS; } dspi 传输状态显示成功,但 dspi 传输后出现“OSIF_SemaWait”超时。 Re: DSPI Communication timeout issue 你好, 根据描述,DSPI 传输本身似乎已成功启动,因为 DSPI_MasterTransfer() 返回 STATUS_SUCCESS。超时发生在 DSPI_MasterTransferBlocking() 等待 OSIF_SemaWait() 获取传输完成通知的时候。 因此,该症状更有可能与中断/完成处理路径有关,而不是与基本的 DSPI 启动失败有关。在阻塞式 DSPI API 中,传输开始后,调用者会等待 DSPI 中断/回调路径版本信号量。如果在超时时间到期之前信号量没有版本,API 将报告超时并中止传输。 该问题仅在 CAN 中断负载较高时才会出现,这是一个重要的线索。如果 CAN 和 DSPI 中断配置为相同的优先级,则持续的 CAN 中断活动可能会延迟 DSPI 中断服务。对于短的 EEPROM 读取,DSPI 事务完成得非常快,因此最终的 DSPI 中断和信号量版本对时间非常敏感。较长的 256 字节页面读取会使 DSPI 事务保持活动状态更长时间,并可能允许驱动程序的中断处理路径以不同的方式进行,这可以解释为什么较大的传输会完成而较小的传输会超时。 建议检查的项目: 配置 DSPI 中断的优先级高于 CAN RX 中断,然后重复测试。 尽量缩短 CAN ISR 的执行时间。如果可能,将 CAN 帧处理从 ISR 移到任务/主循环上下文中。 确认在故障情况下是否已进入 DSPI ISR。 验证 DSPI 传输完成回调或完成路径是否版本 state->dspiSemaphore。 [[ ## completed ##]] 切换 GPIO 或使用跟踪点: CAN RX ISR 入口/出口 DSPI ISR 出入口 DSPI 传输完成回调 在 OSIF_SemaWait() 之前和之后 检查阻塞式 DSPI API 是否不是从 ISR 或任何 DSPI 中断无法运行的上下文中调用的。 作为诊断实验,尝试基于轮询的 DSPI 传输或基于 DMA 的 DSPI 传输。如果轮询/DMA 在相同的 CAN 负载下工作,则进一步证明问题出在中断调度/完成处理上,而不是 SPI 总线本身。 对于 EEPROM 访问,还要确认小读取序列是否按照 EEPROM 协议保持所需的命令/地址/虚拟/读取阶段和片选行为。然而,由于故障是在信号量等待时报告的,因此首先应该关注的是 DSPI 完成中断路径。 综上所述,最可能的方向是 CAN 中断负载过高时中断饥饿或 DSPI 完成处理丢失/延迟。第一个实际测试应该是将 DSPI 中断优先级提高到 CAN 之上,并检测 DSPI ISR/回调在失败情况下是否发布信号量。 顺祝商祺! Peter
記事全体を表示
DSPI通信タイムアウトの問題 私は MPC5775B マイクロコントローラと SPI EEPROMを使っています。私のアプリケーションでは、CANメッセージは 割り込みで連続的に受信され、EEPROMとのSPI通信も 割り込み駆動型です。 CANバストラフィックが重(例:1msごとに5つのCAN IDが受信される)では、EEPROMの読み取り操作はタイムアウトし始めます。私はタイムアウトを10msとしてDSPI_MasterTransferBlocking() APIを使用しています。タイムアウト値を大幅に増やしてみましたが、それでも読み取り操作は失敗します。 興味深いことに、その動作は読み込まれるデータ量によって変化する。EEPROMから数バイトだけ読み取ろうとすると、SPI転送がタイムアウトします。しかし、EEPROMのページ全体(256バイト)を読み取った場合は、読み取り操作は正常に完了します。 また、CANトラフィックが停止されるとEEPROMの読み取り操作が問題なく成功することも観察しました。割り込みの優先順位を確認したところ、CANとSPIの両方の割り込みは同じ優先度レベル(優先度0)で設定されています。 理解したいのは以下の点です。 なぜ小さなSPI EEPROMの読み取り操作はCAN割り込み負荷が重い場合にタイムアウトするのに、より大きな(256バイト)ページ読み込みは正常に完了するのでしょうか? これは割り込み飢餓、DSPI_MasterTransferBlocking()、またはCANとDSPI割り込みハンドラ間の相互作用に関連しているのでしょうか? MPC5775B上で割り込み駆動のDSPI転送と高周波CAN割り込みを同時に使用する場合の既知の制限や推奨される構成はありますか? さらに、デバッグ中に DSPI_MasterTransferBlocking() 内にブレークポイントを設定することで問題をデバッグしました。 status_t DSPI_MasterTransferBlocking(dspi_instance_t instance, const void * sendBuffer、 void * receiveBuffer、 uint16_t フレーム、 uint32_t タイムアウト) ヤージュ DEV_ASSERT((uint32_t)instance < (SPI_INSTANCE_COUNT + DSPI_INSTANCE_COUNT)); status_t ステータス; dspi_state_t * state = DSPI_state[instance]; if (state->status == DSPI_IN_PROGRESS) ヤージュ STATUS_BUSY を返します。 } state->isBlocking = true; (void)OSIF_SemaWait(&(state->dspiSemaphore), 0); status = DSPI_MasterTransfer(instance, sendBuffer, receiveBuffer, frames); if (status == STATUS_SUCCESS) ヤージュ status = OSIF_SemaWait(&(state->dspiSemaphore), timeout); if (status != STATUS_SUCCESS) ヤージュ (void)DSPI_AbortTransfer(instance); state->status = DSPI_TRANSFER_FAIL; ステータスを返します。 } } STATUS_SUCCESS を返します。 } dspi転送ステータスは成功しているが、dspi転送後の「OSIF_SemaWait」がタイムアウトしている。 Re: DSPI Communication timeout issue こんにちは、 説明に基づくと、DSPI_MasterTransfer() が STATUS_SUCCESS を返すため、DSPI 転送自体は正常に開始されたようです。タイムアウトは、DSPI_MasterTransferBlocking() が転送完了通知を OSIF_SemaWait() で待機している間に発生します。 したがって、この症状は、基本的なDSPI起動の失敗というよりも、割り込み/完了処理パスに関連している可能性が高い。ブロッキングDSPI APIでは、転送が開始されると、呼び出し元はDSPI割り込み/コールバックパスがセマフォを解放するまで待機します。タイムアウトが経過する前にセマフォが解放されない場合、APIはタイムアウトを報告し、転送を中止します。 この問題がCAN割り込み負荷が重い場合にのみ発生するという事実は重要な手がかりです。CANとDSPI割り込みが同じ優先度で設定されている場合、連続的なCAN割り込み活動はDSPI割り込みのサービス遅延を引き起こすことがあります。短いEEPROM読み込みの場合、DSPIトランザクションは非常に速く完了するため、最終的なDSPI割り込みとセマフォの解放はタイミングに敏感です。256バイトのページ読み込みが長くなるほどDSPIトランザクションが長く活性化され、ドライバの割り込み処理経路の進行が異なるため、大きな転送は完了し短い転送がタイムアウトする理由が説明できます。 推奨されるチェック項目: DSPI割り込みをCAN RX割り込みよりも高い優先度で設定し、テストを繰り返します。 CAN ISRはできるだけ短く保ちましょう。可能であれば、CANフレームプロセッシングをISRからタスク/メインループのコンテキストに移してください。 DSPI ISRが失敗したCASEに入力されているか確認してください。 DSPI転送完了コールバックまたは完了パスが状態->dspiSemaphoreを解放することを確認します。 GPIOを切り替えるか、トレースポイントを使用します。 CAN RSのISR入退入は可能 DSPI ISRへのエントリー/イグジット DSPI転送完了コールバック OSIF_SemaWait() の前と後 ブロッキングDSPI APIがISRやDSPI割り込みが実行できないコンテキストから呼び出されていないか確認してください。 診断実験として、ポーリング方式のDSPI転送、またはDMA方式のDSPI転送を試してみてください。ポーリングやDMAが同じCAN負荷で動作する場合、問題はSPIバス自体ではなく割り込みスケジューリング/完了処理にあることをさらにサポートしています。 EEPROMアクセスの場合、小規模読み取りシーケンスがEEPROMプロトコルに従って必要なコマンド/アドレス/ダミー/読み取りフェーズおよびチップセレクト動作を保持していることも確認してください。しかし、エラーはセマフォ待機時に報告されるため、まずはDSPI完了割り込みパスに着目すべきである。 まとめると、最も可能性の高い方向は割り込みスターベーション、または高CAN割り込み負荷下でのDSPI完了の失敗/遅延処理です。最初の実用的なテストは、DSPI割り込みの優先度をCANより上に上げ、DSPI ISR/コールバックが失敗したCASEにセマフォをポストするかどうかを測定することです。 よろしくお願いいたします。 ピーター
記事全体を表示
如何禁用 MPC5777C 中的一个核心 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 尊敬的各位, 请问如何禁用 MPC 5777C 中的 Core 0? 您有什么想法吗? 谢谢! 卢卡斯 Re: How to disable one of the cores in MPC5777C 要正确禁用 MPC5777C 中的一个内核,通常需要配置 MC_ME(模式进入)模块,以便在启动序列期间辅助内核保持 RESET 状态。修改 BAM(启动辅助模块)是防止其自动启动的另一种可靠方法。当我需要从研究复杂的微控制器数据手册中短暂休息一下时,我经常浏览David L Moss 囚犯搜索网站,以了解当地的公共记录。如果您需要具体的寄存器地址或示例代码以使 MC_ME 配置在您的设置中正常工作,请告诉我。 Re: How to disable one of the cores in MPC5777C 禁用 MPC5777C 上的一个核心通常涉及调整 RESET配置字或在启动序列期间停止辅助核心。您需要参考参考手册中的 RGM 模块部分,以确保核心保持安全停止状态,不会触发信号,从而导致故障。虽然调试硬件寄存器需要时间,但我最近也在查阅一些本地法律文件,并发现了一个有用的资源,即梅萨法院记录,如果您需要交叉参考,引用任何合规性数据,这可能会有所帮助。 希望通过调整寄存器就能解决您的核心问题,而无需完全重写闪存! Re: How to disable one of the cores in MPC5777C <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢! 顺祝商祺! 卢卡斯·佩雷拉·多斯·桑托斯 高级软件开发工程师 手机: 49 (0)160 97710766 < 49 (0)160 97710766> lilium.com | Facebook <>| 推特 <> | LinkedIn <> 百合有限公司 |腓特烈港大街 1 号 | 82205 吉尔金 <>Stra %C3% 9Fe 1 %7C 82205+Gilching&entry=gmail&source=g> 慕尼黑地方法院注册号:HRB 216921 | 增值税号:DE299517739 | 首席执行官:Daniel Wiegand Re: How to disable one of the cores in MPC5777C <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 核心一旦启用,就只能停止运行。 如果要将它们RESET,则必须执行系统RESET。 要使核心进入停止模式(不执行任何操作,但仍有时钟信号),必须执行“wait”指令。 请参阅具体的核心参考手册。 Peter Re: How to disable one of the cores in MPC5777C 要禁用 MPC5777C 上的某个内核,通常需要修改复位配置或在早期初始化期间停止辅助内核。管理这些多核硬件配置有时会感觉像在没有正确参考,引用编号的情况下查找旧的parkercountycourt.org 一样复杂。务必清除所有待处理的处理器间中断,以免主核心因等待响应而停滞。查阅参考手册中关于 RGM 寄存器的部分,应该可以得到特定启动模式所需的确切十六进制值。             .    
記事全体を表示
件名:MC33774A AFE(RD33774CNC3EVB)用のスタンドアロン評価ソフトウェア/GUI 私は、RD33774CNC3EVB(MC33774A拠点のCMU)とRD-K358BMU評価ボードと協力しています。 MC33774A AFEを、BMSシステム全体を統合することなく、単独で評価および検証したいと考えています。私の目標は、以下のような機能を検証することです。 - セル電圧測定 - 温度測定 - 診断および障害報告 - 受動的な細胞バランス調整 - レジスタ設定 - BMUとAFE間の通信 私には以下の質問があります。 1. NXPはMC33774A向けに独立した評価用GUIやPCソフトウェアを提供していますか? 2. BMUを通じて、FreeMASTERプロジェクトやデモンストレーション用GUI、またはその他のグラフィカルツールでMC33774Aを監視・設定できるものはありますか? 3. 最小限のソフトウェア開発でMC33774Aを評価できるリファレンスアプリケーションや例ファームウェアはありますか? 4. BMUおよびCMU評価ボードのみを使ってMC33774A評価する推奨セットアップを説明したアプリケーションはありますか? 私の目的は、AFEを完全なBMSシステムに統合する前に、その機能検証を行うことです。 サポートありがとうございます。 RD33774CNC3EVB 、 MC33774 、 MC33665A Re: Subject: Standalone Evaluation Software / GUI for MC33774A AFE (RD33774CNC3EVB) サンケット様、 1. NXPはMC33774A向けに独立した評価用GUIやPCソフトウェアを提供していますか? [A] はい、MC33774A 用の EvalGUI 7 があります。特にRD33774ADSTEVBと併用してください。GUIは、MCUとSPI間の通信をTPLトランシーバに、さらにTPL経由でMC33774Aに通信するためのSPIインターフェースと連携することを想定しています。UM11816を参照してください。 もしRD33774CNC3EVB専用のGUIがあるかどうかを尋ねているなら、CTNインターフェース経由でMCUと通信するためのMC33665A TPLからCANトランシーバーへの接続が入っている場合、残念ながら存在しません。 2. BMUを通じて、FreeMASTERプロジェクトやデモンストレーション用GUI、またはその他のグラフィカルツールでMC33774Aを監視・設定できるものはありますか? [A] BMUとCMUのボードについては、ソフトウェアバンドルを丸ごと用意しています。ただし、 S32DSのIDEが必要です。 こちらのリンクをご参照ください。FreeMASTER用のデモプロジェクトが含まれています。 右側のリリースノートをご参照ください。 3. 最小限のソフトウェア開発でMC33774Aを評価できるリファレンスアプリケーションや例ファームウェアはありますか? [A] 上記のEVB用のソフトウェアをご覧ください。しかし、2枚のボードでは不十分です。MC33774A 1個につき最低4個のセルを備えた独自のバッテリーパックが必要です。または、 BATT-18EMULATOR をご利用ください。これは、RD33774CNC3EVB に搭載された各 MC33774A に対して18個のセルをエミュレートします。 UM11943を参照してください。 4. BMUおよびCMU評価ボードのみを使ってMC33774A評価する推奨セットアップを説明したアプリケーションはありますか? [A] はい、あります。ただし、前述のとおり、バッテリーパックまたはバッテリーエミュレーターのいずれかが必要です。UM11943およびこちらのリンクを参照してください。 敬具、 ヨゼフ
記事全体を表示
The S32DS software has expired. I would like to inquire: The license for the S32DS software is about to expire. How can I renew it? Re: The S32DS software has expired. Hello, It is now extended. Best regards, Peter
記事全体を表示
S32DS软件已过期。 我想咨询一下:S32DS软件的许可证即将到期。我该如何续订? Re: The S32DS software has expired. 你好, 现在已扩展。 顺祝商祺! Peter
記事全体を表示
lx2080(yocto image and debug) i need information regarding how to configure lx2080a nxp image build using yocto and if we want use custom bord  then how to make changes Re: lx2080(yocto image and debug) Layerscape Yocto BSP v26.06: The release includes both source code and prebuilt images as listed below: Source Release files are on https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk Branch: walnascar-lsdk Linux BSP Supported boards, Features, Known Issues, please refer to Release Notes Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf Please modify RCW, u-boot, ATF and Linux dts for your custom board, and rebuild images. Porting steps: Modify rcw and rebuild rcw: $ bitbake rcw -c patch -f Go rcw source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/, please modify XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw according to your custom board. $ bitbake rcw Modify and rebuild u-boot: $ bitbake u-boot -c patch -f Please go to u-boot source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/, modify u-boot source code according to your custom board. $ bitbake u-boot Modify and rebuild atf: $ bitbake qoriq-atf -c patch -f Please go to atf source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/, please modify atf source code according to your custom board. $ bitbake qoriq-atf Modify Linux dts file and rebuild Linux Kernel: $ bitbake virtual/kernel -c patch -f Please go to Linux Kernel folder build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git, please modify dts file arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts according to custom board. $ bitbake virtual/kernel Re: lx2080(yocto image and debug) for lx2080a  yocto (linux 24.04)image building(rcw->tfa->uboot-linux path) and flashing image via sd card or emmc or norflash   . code warrire tap jtag debugger can we use. 
記事全体を表示
i.MX93 AHAB セキュアブート、RSA-PSS署名、およびHSMモード こんにちは、 i.MX93-evkプラットフォームでのRSA-PSS署名認証に関してCSTで遭遇した問題を報告したいと思います。これはバグだと思います。以下に、私がこの発見に至るまでの手順を説明します。 現在、i.MX93-EVKプラットフォーム上でセキュアブート手順を実装しており、標準で文書化されたCST v4.0.1を使って動作させることに成功しました。 次に、CST の外で OpenSSL を直接使用して、さまざまなバイナリに署名したいと考えました (注: これは PKCS#11 の設定ではなく、OpenSSL CLI/API で独自の RSA キーを使用しているだけです)。私が実現したかったことをまさに説明している以下の手順書を見つけました: AHABデバイスでのコード署名のためのHSMモードの使用.pdf これは、コード署名ツール(CST)が提供するahab_pki_treeツールを使用して生成されたキーと、以下のパラメータでうまく機能します。 既存のCAキーを使用する:n キータイプ: rsa-pss 鍵長:4096ビット ダイジェストアルゴリズム: sha384 しかし、私がCST以外でバイナリに署名したい理由は、すでに他の様々な成果物の署名に使用しているRSA鍵を持っているからです。このキーを使用してさまざまなバイナリファイルに署名し、リンク先のプロセスで説明されているように署名済みハッシュを再統合しようとすると、次のエラーが発生します(CST v4.0.1)。 [ERROR] CST: The signature file spl_data.sig is not valid 全てが正しいことを再確認した後、OpenSSLを使用して署名を検証するテストも以下のように行いました。 $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 予想と実際: OpenSSLが署名が有効なPSS署名であることを確認したので、CSTも再統合時にそれを受け入れると予想していました。しかし、CSTはそれを無効として拒否します。 CSTのソースコードを詳しく調べ始めたところ、OpenSSLによる検証は成功しているにもかかわらず、署名が無効であると誤って報告されていた理由が分かりました。 CSTが署名を確認する際、以下の処理を行います。 OpenSSL API呼び出しを使用して、公開鍵から「公開鍵アルゴリズム」フィールドを取得します。 このフィールドに基づいて、別の OpenSSL API 呼び出しを使用して、基本的に「指定された署名ファイルは、使用されている公開鍵アルゴリズムに対応していますか?」と問い合わせます。 NXPのドキュメントで「RSA-PSS」キーと呼ばれているものを生成・使用する場合、「公開鍵アルゴリズム」フィールドは rsassaPssと等しく、上記のチェックは正しく動作します。 しかし、汎用RSA鍵を使用する場合、「公開鍵アルゴリズム」フィールドはrsaEncryptionとなり、CSTはこれをPKCS#1 v1.5と誤って解釈しますが、実際にはPKCS#1 v2.1(PSS)形式で署名することも可能です。 私は、自分の署名がPSS署名であることをCSTのソースコードにハードコーディングすることで、この誤った仮定を検証しました。その結果、CSTによって署名が正常に検証され、最終バイナリに再挿入されることができました。その後、閉じた状態のデバイスでは期待どおりに動作しました。 必要であれば、特に関連するOpenSSLの各種関数呼び出しに関して、さらに詳しい情報を提供いたします。 これがCSTの既知の制限なのか、それとも汎用RSAキーで署名を生成・使用している点に何か見落としているのか確認してもらえますか? 余談ですが、HSDKも試しました。これはNXPがAHABベースのプラットフォーム向けに推奨している新しいツールのようですが、署名したいバイナリをエクスポートして手動で署名し、CSTの手順に似た方法で再挿入する方法が見つかりませんでした。これは実現可能かどうかご存知ですか? よろしくお願いいたします。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode こんにちは、 実際、あなたが使っている文書は正しいです。これは、まだCSTを利用しているお客様に推奨されるアプローチです。AHABおよび特に新しいi.MX9ファミリーのお客様には、セキュリティのイネーブルメントのためにSPSDKへの移行を推奨しています。 SO、あなたが踏んだ手順やツールの変更点をCAN共有してください。必要ならSO内部チームと確認・共有CAN。 また、SPSDKについては、以下も参考にしてください。 https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html お役に立てば幸いです。 よろしくお願いいたします。 アルド。
記事全体を表示
RW612 OTBR Thread認証アーキテクチャに関する質問 NXPチームの皆様、こんにちは。   Thread Group認証のコンポーネントに気づきました:   「NXP RW612無線MCUと統合トライラジオOTBR」 (Thread 1.4)   また、以下の個別の認定も見つけました。   - NXP i.MX IW610 トライラジオ OTBRを搭載したMPU - NXP i.MX MPU(IW612 トライラジオ OTBR搭載) - NXP RW612 ワイヤレスMCU(統合トライラジオOTBR)   RW612 OTBR認証に使用されている認証アーキテクチャについて、より深く理解したいと考えています。   もう少し詳しく教えていただけますか:   1. 認証はRW612を単独のMCU/RTOSベースのThreadボーダールーターとして取得したものか?   2. 認証された構成では、外部のRCP/NCPデバイスが使用されましたか?   3. 認証時に使用されたソフトウェアプラットフォーム(FreeRTOS、Zephyr、または他のプラットフォーム)は?   4. 認証済みRW612 OTBR実装を説明する公開リファレンス・デザインやドキュメントはありますか?   私たちの目標は、RW612 OTBR認証がLinuxホストベースのOTBRアーキテクチャではなく、独立したMCUベースのThread Border Routerソリューションであるかどうかを理解することです。   再開まで今しばらくお待ちください。   よろしくお願いいたします。 チョ・ギョンファン   Re: Question about RW612 OTBR Thread Certification Architecture こんにちは、 あなたの調子が良いといいのですが。私の名前はリカルドで、このCASEを任されました。 A1:はい。RW612 OTBR認証は、真のスタンドアロン型シングルチップソリューションです。 A2: いいえ。i.MX MPU + IW610/IW612 OTBR認証(LinuxホストにRCPモードで外部IW6xx無線コプロセッサを搭載)とは異なり、RW612認証は外部RCPやNCPデバイスを一切使用しません。 A3:確認させてください。 A4: テスト構成、テストレポート、認証範囲の詳細については、Thread Groupに直接お問い合わせください。 連絡先は threadgroup.org。 よろしくお願いいたします。 リカルド
記事全体を表示
Is it possible to reprovision the i.MX93 board? I have already provisioned my FRDM i.MX93 board using EdgeLock 2GO, and the provisioning completed successfully.Now I would like to reprovision the same board with a new or updated set of secure objects, such as a key pair and X.509 certificate.Is reprovisioning supported on an already provisioned i.MX93 device?If yes, could you please clarify the recommended procedure? Specifically, do the previously provisioned secure objects need to be deleted or reset before provisioning again, or can they be updated through EdgeLock 2GO?Also, are there any restrictions or irreversible settings that I should be aware of before attempting reprovisioning? The logs:-- ERROR: iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque failed: 0xffffc180 ERROR: iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate failed: 0xffffffff ERROR: iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque failed: 0xffffc180 ERROR: iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate failed: 0xffffffff ERROR: iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque failed: 0xffffc180 ERROR: iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate failed: 0xffffffff ERROR: iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants failed with 0xffffffff Status(oem-prov-app): FAILURE FRDM-Training Hands-On Training Security Yocto Project Re: Is it possible to reprovision the i.MX93 board? Hello, It is possible to reprovision, EdgeLock 2GO is designed for full lifecycle management, including updating, rotating, or revoking certificates and keys after initial deployment. Could you please share which steps did you follow for secure provisioning? You need to be aware of procedures that involves burned configurations in fuses such as keys, life cycle, etc. Best regards. Re: Is it possible to reprovision the i.MX93 board? Thanks for confirming reprovisioning is supported at the service level. To clarify: this isn't a fresh provisioning attempt — it's a reprovisioning attempt on a board that already provisioned successfully once (lifecycle OEM_OPEN, ELE firmware 2.0.5-7a34cee, with a key and certificate object already present from the first pass). On this second pass, oem-prov-app fails inside iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate(), at the mbedtls_pk_setup_opaque() call, returning MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180). Versions: el2go-agent 6.4.2-r0, smw 5.3-r0, mbedtls 3.6.5-r0. Two questions: 1.Does reprovisioning require explicitly erasing the existing key object (via psa_destroy_key or the SMW key-storage API) before rerunning oem-prov-app, or should the agent overwrite it in place at the same key ID? We're currently not doing any explicit erase step. 2.Is there a known compatibility issue between el2go-agent 6.4.2-r0 and smw 5.3-r0 specifically on the reprovisioning/update path — since we saw this same error during initial bring-up too, and suspected a version mismatch there as well? Also — can you confirm the provisioned key and cert objects live in ELE-managed NVM rather than fuses, so a failed reprovisioning attempt doesn't leave that key ID permanently unusable? Re: Is it possible to reprovision the i.MX93 board? Hello, Thank you for the information. 1. Yes, perform a key store reprovisioning using a signed message. A key store re-provisioning results in erasing all the key stores handled by the HSM. 2. No, there are no compatibility issues reported. 3. That is correct, application keys and certificates are stored in ELE-managed NVM, not in fuses. Best regards.
記事全体を表示
Flashing Issue on IMX95EVK's M7 core Hello, I am trying to run an M7 application on IMX95LPD5EVK-19 following AN14748, but I cannot flash flash.bin with UUU. The board is detected briefly, then SDPS boot fails immediately. Hardware: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) Boot switch (SW7[1:4]): 1001 (Serial Download) Target: eMMC Host: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 SDKs tried (MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 Both produce the same result. Command: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   Error: Success 0 Failure 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   Steps followed (per AN14748): Set SW7 = 1001 with board powered off Connect USB to host Run sudo uuu -b emmc flash.bin Power-cycle board Fails at SDPS boot every time Please share the steps to flash and the BSP version supported for M7 core for this version of the board. Re: Flashing Issue on IMX95EVK's M7 core Hello, The latest supported BSP for A1 revision is Linux 6.12.20. Also, you could try to build the the whole binary from scratch (Uboot+SPL+ATF+Firmware+M-SDK). #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### In your case be careful with the latest supported BSP version.  $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (optional if the associated mx95evk.cfg file has been changed) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) #### Build OEI #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (for i.MX 95 A1 only) #### Extract Firmware #### $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit (this will close the terminal so re-open the terminal) #### Copy the resulting binaries to imx-mkimage #### $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all You may use the resulting binary to flash your EVK, we tested this in standalone mode and it is working correctly. Best regards. Re: Flashing Issue on IMX95EVK's M7 core if boot from EMMC, SW7-3 should be 1 according to Quick Start Guide IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core Hello, Thank you for the update. Please try with sudo command. Best regards. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have followed the exact steps given by you. But there is a same flashing error. It goes till 60% and failed after sometime. Can you please check the below screenshots and let me know whether the commands are right. Thanks, Gaurav Re: Flashing Issue on IMX95EVK's M7 core why there is usb error no device?does it happen at 60% booting process? Re: Flashing Issue on IMX95EVK's M7 core Hello, I found a new resource that suggest use Linux 6.12.3_1.0.0/SDK25.03.00 for A1 silicon revision, please try again with this software versions. What do you see in Cortex-A console when you see the error log? Best regards. Re: Flashing Issue on IMX95EVK's M7 core And I am working on the lf-6.12 version for all the repos. Switch position for download mode is "1 0 0 1" Can you please also confirm the supported version of M7 SDK? Re: Flashing Issue on IMX95EVK's M7 core can this issue be reproduced as failed at 60% process all the time? Re: Flashing Issue on IMX95EVK's M7 core Hi @db16122 , Thanks for replying. Yes while flashing the firmware it is getting failed gets stuck at 60% for sometime and getting failed after that.  Thanks, Gaurav C. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas , I have tried with sudo command as well but there is no change and it is still failing. Please check the below screenshot. Thanks, Gaurav C. Re: Flashing Issue on IMX95EVK's M7 core Yes, it is happening everytime. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have tried with SDK 25.03 and i am only getting some failure logs on /dev/ttyUSB3 while flashing the binary. I have also copied the file like below. cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 Do you think there exists a file for mx95a1-ahab-container.img as well? Please also go through the screenshot, it is showing the SOC IMX95(A0) while I am having A1 revision. Thanks Gaurav Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I am able to resolve this issue using document AN14748 and SDK25.03.00  Thanks for your suggestions and valuable time. Thanks, Gaurav
記事全体を表示
Question about RW612 OTBR Thread Certification Architecture Hello NXP Team,   I noticed the Thread Group certified component:   "NXP RW612 Wireless MCU With Integrated Tri-Radio OTBR" (Thread 1.4)   I also found separate certifications for:   - NXP i.MX MPU With IW610 Tri-Radio OTBR - NXP i.MX MPU With IW612 Tri-Radio OTBR - NXP RW612 Wireless MCU With Integrated Tri-Radio OTBR   I would like to better understand the certification architecture used for the RW612 OTBR certification.   Could you please clarify:   1. Was the certification achieved using RW612 as a standalone MCU/RTOS-based Thread Border Router?   2. Was an external RCP/NCP device used in the certified configuration?   3. Which software platform was used during certification (FreeRTOS, Zephyr, or another platform)?   4. Is there any public reference design or documentation describing the certified RW612 OTBR implementation?   Our goal is to understand whether the RW612 OTBR certification represents a standalone MCU-based Thread Border Router solution rather than a Linux-host-based OTBR architecture.   Thank you for your support.   Best regards, Kyonghwan Cho   Re: Question about RW612 OTBR Thread Certification Architecture Hello, Hope you are doing well. My name is Ricardo and I have been assigned this case. A1: Yes. The RW612 OTBR certification is a true standalone, single-chip solution. A2: No. Unlike the i.MX MPU + IW610/IW612 OTBR certifications (which use a Linux host with an external IW6xx radio co-processor in RCP mode), the RW612 certification does not use any external RCP or NCP device. A3: Let me confirm. A4: For specific details on the test configuration, test reports, or certification scope, please contact the Thread Group directly at threadgroup.org. Best Regards, Ricardo Re: Question about RW612 OTBR Thread Certification Architecture Hello @KyonghwanCho , Thank you for your patience. I have the confirmation that the SW platform used was FreeRTOS. Also, please check below OTBR user guide and build guide ot-nxp/examples/br/README-OTBR.md at release/v1.4.0.5_26.03 · NXP/ot-nxp ot-nxp/src/rw/rw612/README.md at release/v1.4.0.5_26.03 · NXP/ot-nxp Best Regards, Ricardo
記事全体を表示
关于 RW612 OTBR 线程认证架构的问题 您好,NXP团队,   我注意到了线程组认证的元器件:   “NXP RW612 无线 MCU 集成三频 OTBR” (线程 1.4)   我还找到了以下方面的单独认证:   - NXP i.MX MPU 搭载 IW610 三频 OTBR - NXP i.MX MPU 搭载 IW612 三频 OTBR - NXP RW612 无线 MCU,集成三频 OTBR   我想更好地了解 RW612 OTBR 认证所使用的认证架构。   请问您能否澄清一下:   1. 是否使用 RW612 作为独立组网 \(SA\) 的基于 MCU/RTOS 的线程边界路由器获得认证?   2. 认证配置中是否使用了外部 RCP/NCP 设备?   3. 认证过程中使用了哪个软件平台(FreeRTOS、Zephyr 或其他平台)?   4. 是否有公开的参考设计或文档描述了经过认证的 RW612 OTBR 实现?   我们的目标是了解 RW612 OTBR 认证是否代表基于 MCU 的独立组网 \(SA\)线程边界路由器解决方案,而不是基于 Linux 主机的 OTBR 架构。   感谢您的支持。   顺祝商祺! 赵京焕   Re: Question about RW612 OTBR Thread Certification Architecture 你好, 希望你一切都好。我叫里卡多,这个案子交给了我。 A1:是的。RW612 OTBR 认证是一个真正的独立组网 (SA)单芯片解决方案。 A2:不。与 i.MX MPU + IW610/IW612 OTBR 认证(使用带有外部 IW6xx 无线电协处理器的 Linux 主机,RCP 模式)不同,RW612 认证不使用任何外部 RCP 或 NCP 设备。 A3:让我确认一下。 A4:有关测试配置、测试报告或认证范围的具体详情,请直接联系 Thread Group,网址为threadgroup.org 。 顺祝商祺! 里卡多
記事全体を表示
IMX95EVK M7 核心的刷写问题 你好, 我正在尝试运行一个 M7 应用程序 IMX95LPD5EVK-19 下列的 AN14748 ,但我无法刷机。 flash.bin 用 UUU。短暂检测到电路板后,SDPS 启动立即失败。 硬件: IMX95LPD5BB-19 修订版 A1 (2024 NXP BV) 启动开关(SW7[1:4]): 1001(序列号下载) 目标: eMMC 主持人: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 尝试过的 SDK(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 两者产生的结果相同。 命令: 光盘 IMX95LPD5EVK/版本_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo 呜呜呜 -b EMMC flash.bin   错误: 成功 0 失败 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: 启动 -f flash.bin   执行步骤(根据 AN14748): 在电路板断电的情况下,将 SW7 设置为 1001 将 USB 连接到主机 跑步 sudo uuu -b emmc flash.bin 电源循环板 每次 SDPS 启动都失败 请分享一下该版本板上 M7 内核的刷写步骤以及支持的电路板支持包。版本。 Re: Flashing Issue on IMX95EVK's M7 core 你好, A1 版本的最新支持 电路板支持包。 是 Linux 6.12.20。 另外,您还可以尝试从头开始构建整个二进制文件(Uboot+SPL+ATF+固件+M-SDK)。 ## ## Download and extract ARM GCC toolchain ## ## $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### 请注意使用最新支持的电路板支持包。版本。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin ## ## Build Uboot ## ## $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build ATF ## ## $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build SM ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (如果关联的 mx95evk.cfg 文件已更改,则此步骤可选的) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (MCUXpresso 测试配置) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=tcm DEBUG=1 (仅适用于 i.MX 95 A1) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept ## ## M7 SDK compilation ## ## $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For ITCM ## ## $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For DDR ## ## $ exit(这将关闭终端,请重新打开终端) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-启动.bin ./iMX95 $ cp ../uboot-imx/spl/u-启动-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 您可以使用生成的二进制文件来刷写您的 EVK,我们已经在独立组网 \(SA\) 模式下测试过,它可以正常工作。 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 如果从 EMMC 启动,则根据快速入门指南,SW7-3 应为 1。 IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core 你好, 谢谢你的更新。 请尝试使用 sudo 命令。 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas 我完全按照您给出的步骤操作了。 但是仍然存在同样的闪烁错误。进度达到 60% 后,过了一段时间就失败了。 请您查看以下截图,并告诉我这些命令是否正确。 谢谢, 高拉夫 Re: Flashing Issue on IMX95EVK's M7 core 为什么会出现“USB 设备错误”?这种情况是否发生在启动过程进行到 60% 时? Re: Flashing Issue on IMX95EVK's M7 core 这个问题是否可以重现,即每次进程进行到 60% 时都会失败? Re: Flashing Issue on IMX95EVK's M7 core 我正在为所有仓库开发 lf-6.12 版本。下载模式的开关位置为“ 1 0 0 1” 请问能否确认一下支持的M7 SDK版本? Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas , 我也尝试过使用 sudo 命令,但没有任何改变,仍然失败。 请查看以下截图。 谢谢! 高拉夫·C. Re: Flashing Issue on IMX95EVK's M7 core 你好, 我找到一个新资源,建议对 A1 芯片版本使用 Linux 6.12.3_1.0.0/SDK25.03.00,请尝试使用这些软件版本再试一次。 当您查看错误日志时,Cortex-A 控制台中显示了什么? 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 你好@db16122 , 谢谢回复。 是的,刷固件时会失败,卡在 60% 一段时间后就失败了。 谢谢! 高拉夫·C.
記事全体を表示
i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, I'd like to report an issue I encountered with CST regarding RSA-PSS signature verification on an i.MX93-evk platform, which I believe is a bug. Below, I describe the steps that led me to this discovery. I'm currently implementing the secure boot procedure on an i.MX93-EVK platform and successfully got it working with the standard, documented procedure using CST v4.0.1. I then wanted to sign the various binaries outside of CST, using OpenSSL directly (note: this is not a PKCS#11 setup, I'm just using my own RSA key with the OpenSSL CLI/API). I came across the following procedure, which describes exactly what I wanted to achieve: Using HSM mode for code signing in AHAB devices.pdf This works well with keys generated using the ahab_pki_tree tool provided by the Code Signing Tool (CST), with the following parameters: use an existing CA key: n key type: rsa-pss key length: 4096-bit digest algorithm: sha384 However, the reason I want to sign binaries outside of CST is that I already have an RSA key that is used for signing various other artifacts. When I use this key to sign the various bin files and then try to reintegrate the signed hashes as described in the linked procedure, I get the following error (CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid After double-checking that everything was correct, I also tested verifying my signature using OpenSSL as follows: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK Expected vs actual: since OpenSSL confirms the signature is a valid PSS signature, I expected CST to accept it during reintegration as well. Instead, CST rejects it as invalid. I started digging into the CST source code and found why it was incorrectly reporting the signature as invalid, even though it was successfully verified by OpenSSL. When CST checks the signature, it does the following: Using OpenSSL API calls, it retrieves the "Public Key Algorithm" field from the public key. Based on this field, it uses another OpenSSL API call to essentially ask: "Does the given signature file correspond to the public key algorithm used?" When generating/using what the NXP documentation calls "RSA-PSS" keys, the "Public Key Algorithm" field is equal to rsassaPss and the checks above work correctly. However, when using a generic RSA key, the "Public Key Algorithm" field is equal to rsaEncryption, and CST wrongly assumes this means the signature format is PKCS#1 v1.5, even though it's entirely possible to sign using the PKCS#1 v2.1 (PSS) format. I confirmed this incorrect assumption by hardcoding into the CST source code that my signature was a PSS one, and I was then able to get my signature successfully verified and reinserted by CST into the final binary. It then worked as expected on my closed device. I'm happy to provide more details if needed, especially regarding the various OpenSSL function calls involved. Could you confirm whether this is a known limitation of CST, or if I might be missing something in how I'm generating/using the signature with a generic RSA key? As a side question, I also tried using SPSDK, which seems to be the new tool NXP is promoting for AHAB-based platforms, but I couldn't find a way to export the binaries to be signed, sign them manually, and then reinsert them, similar to the CST procedure. Do you know if this is feasible? Thanks in advance. Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, Actually the document that you are using is correct, is the aproach we suggest for customers that are still using CST. For AHAB, and specially new i.MX9 familly we suggest customers to move to the SPSDK as this is the tool we are using for enablement on security. Even so you can share the steps you have followed and the changes you made to the tool, so I can review and share with internal team if needed. Also, for the SPSDK you may have a look to the following: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html Hope this helps, Best regards/Saludos, Aldo.
記事全体を表示
i.MX93 AHAB 安全启动、RSA-PSS 签名和 HSM 模式 你好, 我想报告我在 i.MX93-evk 平台上使用 CST 进行 RSA-PSS 签名验证时遇到的问题,我认为这是一个 bug。下面我将描述我得出这一发现的步骤。 我目前正在 i.MX93-EVK 平台上实施安全启动程序,并已使用 CST v4.0.1 按照标准、有记录的程序成功使其工作。 然后,我想在 CST 之外对各种二进制文件进行签名,直接使用 OpenSSL(注意:这不是 PKCS#11 设置,我只是使用我自己的 RSA 密钥和 OpenSSL CLI/API)。我找到了以下步骤,它恰好描述了我想要实现的目标:在 AHAB 设备中使用 HSM 模式进行代码签名.pdf 这对于使用代码签名工具 (CST) 提供的ahab_pki_tree工具生成的密钥效果很好,参数如下: 使用现有 CA 密钥:否 密钥类型:rsa-pss 密钥长度:4096 位 摘要算法:sha384 但是,我想要在 CST 之外对二进制文件进行签名的原因是,我已经有一个 RSA 密钥,该密钥用于对各种其他工件进行签名。当我使用此密钥对各种 bin 文件进行签名,然后尝试按照链接中的步骤重新集成签名哈希值时,出现以下错误(CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid 在仔细检查确认一切无误后,我还使用 OpenSSL 测试了签名验证,步骤如下: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 预期与实际情况:由于 OpenSSL 确认该签名是有效的 PSS 签名,我预期 CST 在重新集成期间也会接受它。CST 却将其判定为无效并拒绝接受。 我开始深入研究 CST 源代码,并发现了它错误地将签名报告为无效的原因,即使 OpenSSL 已成功验证了该签名。 CST 检查签名时,会执行以下操作: 它使用 OpenSSL API 调用,从公钥中检索“公钥算法”字段。 根据该字段,它使用另一个 OpenSSL API 调用来询问:“给定的签名文件是否与所使用的公钥算法相符?” 当生成/使用 NXP 文档中称为“RSA-PSS”的密钥时,“公钥算法”字段等于rsassaPss ,并且上述检查工作正常。 然而,当使用通用 RSA 密钥时,“公钥算法”字段等于rsaEncryption ,CST 错误地认为这意味着签名格式为 PKCS#1 v1.5,即使完全可以使用 PKCS#1 v2.1 (PSS) 格式进行签名。 我通过在 CST 源代码中硬编码我的签名是 PSS 签名来证实了这个错误的假设,然后我成功地让 CST 验证了我的签名并将其重新插入到最终的二进制文件中。然后它在我的封闭设备上运行正常。 如有需要,我很乐意提供更多细节,特别是关于所涉及的各种 OpenSSL 函数调用。 能否确认这是否是 CST 的已知限制,或者我在使用通用 RSA 密钥生成/使用签名时是否遗漏了某些内容? 另外,我还尝试使用 SPSDK,这似乎是 NXP 为基于 AHAB 的平台推广的新工具,但我找不到导出要签名的二进制文件、手动签名,然后再重新插入的方法,类似于 CST 过程。你知道这是否可行吗? 先行致谢。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode 你好, 实际上,您正在使用的文档是正确的,这是我们建议仍然使用 CST 的客户采用的方法。对于 AHAB,特别是新的 i.MX9 系列,我们建议客户迁移到 SPSDK,因为这是我们用于启用网络安全的工具。 即便如此,您仍然可以分享您遵循的步骤以及您对工具所做的更改,以便我进行审核,并在需要时与内部团队分享。 另外,关于SPSDK,您可以参考以下内容: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html 希望这能帮到你。 此致敬礼/Saludos, 阿尔多。
記事全体を表示
是否可以对 i.MX93 板进行重新配置? 我已使用 EdgeLock 2GO 成功配置了我的 FRDM i.MX93 板。现在我想使用一组新的或更新的安全对象(例如密钥对和 X.509 证书)重新配置同一块板。已配置的 i.MX93 设备是否支持重新配置?如果支持,请问推荐的步骤是什么?具体来说,之前配置的安全对象是否需要在重新配置之前删除或 RESET,还是可以通过 EdgeLock 2GO 进行更新?此外,在尝试重新配置之前,我是否需要注意任何限制或不可逆的设置? 日志:-- 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 失败,错误代码为 0xffffffff 状态(oem-prov-app):失败 FRDM 培训 动手实践培训 安全 Yocto Project Re: Is it possible to reprovision the i.MX93 board? 你好, EdgeLock 2GO 可进行重新配置,其设计旨在实现完整的生命周期管理,包括在初始部署后更新、轮换或撤销证书和密钥。 请问您能否分享一下您在安全配置过程中遵循了哪些步骤? 您需要了解与熔丝中烧毁的配置相关的程序,例如键、生命周期等。 顺祝商祺! Re: Is it possible to reprovision the i.MX93 board? 感谢您确认服务级别支持重新配置。澄清一下:这不是一次全新的配置尝试,而是对已经成功配置过一次的板子进行的重新配置尝试(生命周期 OEM_OPEN,ELE 固件 2.0.5-7a34cee,第一次配置时已经存在密钥和证书对象)。 在第二次尝试中,oem-prov-app 在 iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内部的 mbedtls_pk_setup_opaque() 调用处失败,返回 MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180)。版本:el2go-agent 6.4.2-r0,smw 5.3-r0,mbedtls 3.6.5-r0。 两个问题: 1.重新配置是否需要在重新运行 oem-prov-app 之前显式擦除现有密钥对象(通过 psa_destroy_key 或 SMW 密钥存储 API),还是代理应该在相同的密钥 ID 处就地覆盖它?我们目前没有执行任何显式擦除步骤。 2. el2go-agent 6.4.2-r0 和 smw 5.3-r0 之间是否存在已知的兼容性问题,尤其是在重新配置/更新路径上?因为我们在初始启动时也看到了同样的错误,并怀疑是版本不匹配导致的。 另外,能否确认已配置的密钥和证书对象位于 ELE 管理的 NVM 中,而不是熔丝中,这样即使重新配置失败,也不会导致该密钥 ID 永久无法使用? Re: Is it possible to reprovision the i.MX93 board? 你好, 谢谢你提供的信息。 1. 是的,使用签名消息执行密钥库重新配置。密钥存储重新配置会导致 HSM 处理的所有密钥存储被擦除。 2. 没有,没有报告任何兼容性问题。 3. 没错,应用程序密钥和证书存储在 ELE 管理的 NVM 中,而不是存储在熔丝中。 顺祝商祺!
記事全体を表示
IMX95EVKのM7コアにおけるフラッシュの問題 こんにちは、 IMX95LPD5EVK-19 follow AN14748 でM7アプリケーションを実行しようとしていますが、フラッシュできません flash.binUUUと共に。ボードは短時間検出されるが、その後すぐにSDPSの起動に失敗する。 ハードウェア: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) ブートスイッチ(SW7[1:4]): 1001(シリアルダウンロード) ターゲット: eMMC ホスト: Ubuntu Linux うーん: libuuu_1.5.243-0-g230f1b1 試したSDKs(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 どちらも同じ結果を生み出す。 コマンド: CD IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo ううう -b emmc flash.bin   エラー: 成功 0 失敗 1 1:2-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   実施された手順(AN14748に基づく): ボードの電源をオフにした状態で、SW7を1001に設定します。 USBをホストに接続します 走る sudo uuu -b emmc flash.bin 電源サイクルボード SDPSの起動に毎回失敗する このバージョンのボードにおけるM7コアのフラッシュ手順とサポートされているBSPバージョンを教えてください。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 A1版向けに最新サポートされているBSPはLinux 6.12.20です。 また、バイナリ全体を一から作るのも手です(Uboot+SPL+ATF+Firmware+M-SDK)。 #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### あなたの場合は、サポートされている最新のBSPバージョンに注意してください。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ CD Uboot-IMX $ make -j $(nproc --all) きれいに $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ CD ... $ CD IMX-ATF $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ CD ... $ CD IMX-SM $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg(関連するmx95evk.cfgファイルが変更されている場合は任意) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (i.MX 95 A1 のみ) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --車載承認 $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --自動承認 #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit(これで端末が閉鎖されるSO、再開してください) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 生成されたバイナリを使用してEVKをフラッシュすることができます。スタンドアロンモードでテストしたところ、正常に動作しました。 よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core クイックスタートガイドによると、EMMCからブートする場合、SW7-3は1になるはずです。 IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、@JorgeCasさん 私はあなたが指示した手順を正確に実行しました。 しかし、同じ点滅エラーが発生します。60%まで進んだ後、しばらくして失敗した。 CAN、以下のスクリーンショットを確認して、コマンドが正しいか教えてもらえますか? ありがとう、 ガウラヴ Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 最新情報のご提供ありがとうございます。 sudoコマンドを使って試してみてください。 よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core USBエラー「デバイスが見つかりません」が表示されるのはなぜですか?起動プロセスの60%の時点で発生しますか? Re: Flashing Issue on IMX95EVK's M7 core CANこの問題が常に60%のプロセスで失敗していると再現されることはありますか? Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 新しいリソースで、A1シリコンリビジョンにはLinux 6.12.3_1.0.0/SDK25.03.00を使うことを勧められました。このソフトウェアバージョンでもう一度試してみてください。 Cortex-Aコンソールでエラーログを見ると何が見えますか? よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 @JorgeCas さん。 sudoコマンドも試してみましたが、変化はなく、依然として失敗します。 下記のスクリーンショットをご確認ください。 ありがとうございます ガウラヴ・C Re: Flashing Issue on IMX95EVK's M7 core そして、すべてのリポジトリ向けにlf-6.12バージョンの開発に取り組んでいます。ダウンロードモードのスイッチ位置は「1 0 0 1」です。 サポートされているM7 SDKsのバージョンも確認していただけますか? Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 @db16122 さん。 ご返信ありがとうございます。 はい、ファームウェアの書き込み中にエラーが発生し、60%のところでしばらく止まった後、エラーになります。 ありがとうございます ガウラヴ・C
記事全体を表示
lx2080(yocto镜像和调试) 我需要了解如何使用 Yocto 配置 LX2080A NXP 镜像版本,以及如果要使用自定义板卡,应该如何进行更改。 Re: lx2080(yocto image and debug) Layerscape Yocto 电路板支持包。 v26.06: 该版本包含源代码和预编译镜像,具体内容如下: 源代码版本文件位于https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk 分支: walnascar-lsdk Linux BSP 支持的开发板、功能、已知问题,请参阅版本说明 Layerscape Yocto软件开发工具包用户指南: UG10374.pdf Layerscape Linux SDK 用户指南: UG10381.pdf 请修改 RCW、u-boot、ATF 和 Linux dts 以适应您的定制板,并重新构建镜像。 移植步骤: 修改 rcw 并重新构建 rcw: $ bitbake rcw -c patch -f 请打开 rcw 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/,并根据您的自定义板修改 XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw。 $ bitbake rcw 修改并重新编译 u-启动: $ bitbake u-启动 -c patch -f 请进入 u-启动 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/,根据您的定制板修改 u-启动 源代码。 $ bitbake u-boot 修改并重新构建 atf: $ bitbake qoriq-atf -c patch -f 请前往 atf 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/,请根据您的定制板修改 atf 源代码。 $ bitbake qoriq-atf 修改Linux dts文件并重新构建Linux内核: $ bitbake virtual/kernel -c patch -f 请进入 Linux 内核文件夹 build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git,请根据定制板修改 dts 文件 arch/arm64/启动/dts/freescale/fsl-lx2160a-rdb.dts。 $ bitbake 虚拟/内核
記事全体を表示
SPC入力がWUUに伝わらず、デバイスが起動しない [MCXN947との連携] SPCでは、低電力モードとアクティブモードの両方で、電圧検出割り込みを有効にしています(リセットは無効)。アクティブモードはリセットを無効にし、バンドギャップを有効にしています。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a WUUでSPCをウェイクアップソースとして有効にしました(WUU->MEビットが設定されています)。 SPC割り込みはアクティブモードで動作しますが、電源オフモードでは動作しません。つまり、プロセッサはSPC割り込みを処理するためにウェイクアウトしません。 MCX N Re: SPC input to WUU not waking device おそらく動作しているとは思うが、アクティブモードとパワーダウンモードでは反応に大きな違いがある。アクティブモードでは、SPC割り込みはより迅速に応答し、繰り返し発生しますが、パワーダウンモードからは、割り込みが発生するまでに非常に時間がかかり、一度しか発生しません。 Re: SPC input to WUU not waking device こんにちは、 @robert_hines さん。 電源オフモードからのウェイクアップレイテンシは、アクティブモードの割り込み応答時間よりも長くなると予想されます。電源オフモードでは、MCUの大部分が静的状態にあります。より深い低消費電力モードに入る際のトレードオフの一つは、そのモードの入り出時にレイテンシが増えることです。 割り込みが一度だけ発生する問題については、アプリケーションコードの処理に問題があるのではないかと疑っています。SDKに含まれるpower_mode_switch例を参照し、実装とあなたのコードを比較していただけますか? それでも問題が解決しない場合は、FRDM-MCXN947ボード上で問題を再現できる簡単なプロジェクトを提供してください。喜んでさらに詳しく調査いたします。 よろしくお願いします。 BR アリス Re: SPC input to WUU not waking device 状況は以下のとおりです。 - FreeRTOSへの移植 - 低電力タイマーを使用して、PM_EnterLowPower()で電源オフモードに移行します。 - IRQHandlers は setFromISR() と portYIELD_FROM_ISR() を使用します - 高優先度タスクがISRで設定されたイベントビットを待機している場合、xEventGroupWaitBits() - 一部の割り込みはWUUを経由して電源オフモードで利用可能にしており、外部ピンの一部(正常に動作しているようです)や、SPCが遅い/応答しない点を除き、問題なく動作する内部モジュール(VBAT、LPTMR、TDET、SPC)も含まれます。 - SPC割り込みはIRQHandlerで無効化され、イベントビットの設定を待つ高優先度タスクで処理された後に再有効化されます。この待機タスクはイベント情報ビットのプロセッシング後に再び PM_EnterLowPower() を呼び出します。 問題は、SPC割り込みが他の割り込みと同じように応答しないことだ。プロセッサが起動しても再びスリープに戻り、再びトリガーされません。アクティブモードで電源が切れても、発火は続けます(PM_EnterLowPower()でプロセッサを再び電源オフモードに戻せません)。
記事全体を表示