GUI Guider 2.0で選択されたイメージ保存タイプがFlashの場合、表示できません。 Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 こんにちは、 @sk-l さん。 CAN you please provide a more detailed description of the issue?It would be very helpful if you CAN also attach screenshots or relevant pictures for reference.   ありがとう。   BR ハリー Re: GUI Guider 2.0 图片存储类型选择Flash,无法显示 skl_2-1786613588252.png skl_0-1786612933574.png skl_1-1786612993765.png 画像/アニメーション画像、 カラーフォーマットはI4、ストレージタイプはフラッシュメモリ、シミュレーション中は表示されません。 カラーフォーマットはI4、ストレージタイプはc配列、画像は正常に表示されます。

I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT エラー こんにちは、NXP チームの皆様、 .wicファイルを使用してi.MX93ボードにファームウェアを書き込もうとしています。画像ファイルは当チームより提供されました。弊社には、同じハードウェアリビジョン（ SCH-96411 REV_B2 ）のi.MX93ボードが2枚あります。 1枚の基板では、.wicファイルの書き込みに成功しました。画像。しかし、同じイメージを2枚目の基板に書き込もうとすると、エラーが発生します。 私たちは両方をテストしました。 emmc_all（eMMC書き込み用） sd_all(SDカード使用) どちらの場合も、同じ問題が第2ボードで発生します。 トラブルシューティングや解決にサポートをご協力いただけるとありがたいです。追加のログ、エラーメッセージ、またはボード情報が必要な場合はお知らせください。 Providing both uuu command and debugProviding both uuu command and debugProviding both uuu command and debuguuuコマンドとデバッグの両方を提供します uuu supported listuuu supported listuuu supported listuuu サポート対象リスト i.mx93 usb identifiedi.mx93 usb identifiedi.mx93 usb identifiedi.mx93 USBが識別されました Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 回路図の識別は良いですが、93 i.MX トップマークを確認することをお勧めします。両者が最高評価を共有していることを確認してください。 Linuxから最新の既成イメージリリースをダウンロードしてください。 最後に、両方のデバイスをシリアルダウンロードでフラッシュしようとしているとのことですが、ヒューズが切れている箇所はありますか？ よろしくお願いします。 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error こんにちは 添付画像をご確認ください。ICの部品番号にいくつか変更点があることに気づきました。 SDカードを外部でフラッシュしてからi.MX93ボードに挿入するという方法も試しましたが、やはり同じ問題が発生します。 さらに、eMMCには既にイメージファイルが存在しており、ボードはそのイメージファイルから正常に起動できることをお知らせいたします。しかし、新しいイメージをフラッシュしようとすると、エラーが発生します。 デバッグログを添付しましたので、下記をご覧ください。1つの観察結果は、ボードに付属していたプリロードイメージがU-Boot SPL 2025.04を示していることです。一方、私たちが使用しようとしているイメージはU-Boot SPL 2024.04を示しています。 最新の Linux 6.18.20_2.0.0(i.MX93 EVK、FRDM) リリースをダウンロードしました。しかし、 14x14のEVK WIC画像 しか見つけられず、 11x11のFRDM WIC画像 パッケージは見つけられませんでした。14x14の画像が当ボードに正しいものか、それとも別の11x11 FRDM画像があるのか確認いただけますか? SDカードブート: U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK eMMCブート: U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS が DRAM 2CS_2GB と一致する DRAM を検出しました M33準備OK 通常のブート BOOTROMから起動しようとしています ブートステージ:プライマリブート 画像オフセット 0x8000、ページサイズ 0x200、IVT オフセット 0x0 ROM_APIを使用して0x57800からイメージをロードします 通知：TRDC初期化完了 お知らせ：BL31：v2.12.0（リリース）：lf-6.18.2-1.0.0 お知らせ：BL31：製造日時：2026年2月10日 07:53:18 /****************************************************/ ヒューズが飛んだことについてですが、ヒューズがプログラムされているのか、基板上で飛んだのかをどうやって確認できるか教えていただけますか? ありがとう。 Issue board - imx93Issue board - imx93問題掲示板 - imx93 Working board - imx93Working board - imx93作業用ボード - imx93 Re: I.MX93 - UUU emmc/sdcard LIBUSB_ERROR_TIMEOUT Error 私も同様の問題を抱えており、私の理解では、FRDMシリーズを製造している中国のメーカーがDDR RAM ICを変更したようです。これにはDDRの再学習とyou-bootへのアップデートが必要で、これはボードソフトウェア用に行われ、nxpのu-bootリポジトリにコミットされましたが、ウェブサイト上のBSP、Yoctoレイヤー、バイナリイメージは更新されていませんでした。 基本的に新しいボードは内蔵のU-Bootのみで動作し、開発者がBSPで作るもの(および2024年以降のU-boot)は、ddr設定の無効により起動すらできません。 この問題を確認するには、ボードのU-Bootから起動し、キーボードで停止し、SDカードからカスタムLinuxカーネルとDTを手動でロードする方法があります。

Clock_Ip_Init() 呼び出し時の外部データアボート こんにちは、 RTDとS32 DSのmexツールを使ってペリフェラルクロックを初期化しようとしています。(注:私はM7プロジェクトでコードを生成していますが、実際にはA53プロジェクトのためにビルドして実行しています) しかし、Clock_Ip_Init() 関数内で外部データによる異常終了が発生しました。具体的には、コールスタックは次のようになります。 Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref()。 これはCMUペリフェラルメモリへの書き込みを初めて試みた試みのようです。この障害は、メモリ0x4005'C028上のLDR命令で発生しており、S32G3メモリマップによれば、この命令はCMUメモリ領域内に正しく配置されています。 現時点ではMMUは有効になっていませんが、私の理解では、外部のデータアボートはCPU/MMUの外で発生し、 おそらくセキュアアクセス か 「ロックされた」 周辺機器に関連しているようです。 Clock_Ip_Init() を呼び出す前に、何らかの方法で CMU を A53 コアから「アクセス可能」にする必要がある、という理解で合っていますか？もしそうなら、その手順についてアドバイスをいただけますか? よろしくお願いいたします。 ジョニー デバイス = S32G399A コンパイラ = S32DS_GCC _11_4 コア = Cortex A53 Re: External Data Abort when calling Clock_Ip_Init() こんにちは、 jonnyWHIS お問い合わせいただきありがとうございます。 S32DS IDEのS32G A53コア上でベアメタルコードを作成するつもりですか? BR ジョーイ

无法从 T2081 处理器访问 MT29F64G08AECAB 8GB 与非闪存 你好， 我有一个T2081 NXP 处理器，通过IFC连接到外部与非闪存 MT29F64G08AECAB 。 我的目标是在 Code Warrior 上对该与非 Flash 进行诊断测试，或者直接读取该设备的设备和制造商 ID（我已经为此编写了代码）。 为了实现这个目标，我已经完成了以下工作： 1. 在生成的T2081QDS_init_core.tcl 中配置 与非 IFC 的 LAW，起始地址为 0xFF800000，大小为 1MB 。 ## LAW3 到 IFC - 与非 # LAWBARH 内存 [CCSR_ADDR 0x000C30] = 0x00000000 # 律师协会 内存 [CCSR_ADDR 0x000C34] = 0xFF800000 # LAWAR 内存 [CCSR_ADDR 0x000C38] = 0x81F00013 2. 还配置了与 NAND 对应的CSPR 和 FTIM 寄存器，如下所示： 设置 NAND_CS 5 # 与非闪存，地址0xFF800000，容量1MB，8位与非，ECC禁用 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 # AMASK mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 请注意，处理器到与非 有 2 个片选信号（CS5 和 CS6），目前我正在尝试访问前 4GB，因此只配置了 CS5 。 3. 已配置TLB： 1M TLB 条目 5：0xFF800000 - 0xFF8FFFFF，适用于 与非 缓存禁止、受保护的缓存 寄存器${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. 由于在安装目录中找不到对 MT29F64G08AECAB 的设备支持，我按照手册为该设备（4GB）创建了一个 .xml 文件，我已将其附在此处。 完成上述步骤后，当我在 CodeWarrior 上运行 与非 设备的诊断测试时，出现以下错误： Nisarga_R_0-1786096350786.png 作为替代方案，我尝试编写一个简单的 C 代码来从该设备读取设备 ID。所以我用 CodeWarrior 编写了以下代码，并附在这里。因此，当我读取 IFC_NAND_MDR 寄存器时，我得到了 0x124E0000，这与设备 ID 不匹配。 我想知道是不是我做错了什么或者遗漏了什么，因为我无法运行诊断测试或读取设备 ID 。 我已附上相应的 T2081QDS_init_core.tcl 文件以及相应的原理图供您参考。 问候， 尼萨加 R   QorIQ T2 设备 Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor 我正在和内部团队讨论。 谢谢！

rt1189 ブートフロー 1.図に示すように、「画像の認証」プロセスは、SHA-512ハッシュ化の段階でハッシュ値を検証するのでしょうか？ yanyanwang_0-1786097643048.png 2. ハッシュ値を設定した場合、BootROMはイメージの整合性を検証しますか？BootROMの検証に失敗した場合、リカバリーモードに入るのでしょうか？ Re: rt1189 Boot Flow yanyanwang_0-1786444750281.png yanyanwang_1-1786444764361.png 上の図に示すように、イメージに署名するだけで暗号化しない場合、ブートROMの検証フローを通過できるでしょうか？さらに、oem_closeが有効になっている場合でも、ブートROM検証フローに入ることは可能でしょうか？     Re: rt1189 Boot Flow 1. 署名認証機能が有効である場合にのみハッシュ検証が有効ですか?ハッシュ検証はどのように独立して有効化できるのでしょうか?デバイスはどのようにしてOEM_CLOSEDライフサイクル状態に移行できますか? 2. リカバリーブートヒューズを有効にする。 3. 私の目標は暗号化されていない画像を使うことです。ブートROMはイメージハッシュを計算し、検証する必要があります。ハッシュ検証が失敗した場合、ブートROMはリカバリブートフローに入り、LPSPI NORフラッシュからリカバリイメージを起動する必要があります。 Re: rt1189 Boot Flow 下記に、お客様からの2つのご質問に対する回答を記載いたします。 1. 署名のみ(暗号化されていない)イメージがBootROM検証フローを通過できますか?はい。RT1180 AHABでは、署名(認証)がセキュアブートの必須部分であり、画像の真正性と整合性を確保しています。一方、暗号化(OTFAD/IEE)は独立した任意のアンチクローン機能であり、検証の前提条件ではありません。したがって、署名のみのイメージは通常どおり完全な AHAB 署名検証フローを通過します。これは、NXP の公式 SPSDK rt118x_secure_boot サンプルにおける標準的なアプローチでもあります。 2. oem_close (OEM_CLOSED) が有効になっている場合でも、検証フローは実行されますか？はい、そして本人確認が必須となります。 おすすめ: oem_closeを実行する前に、署名済みイメージをOEM_OPEN状態でプログラムし、ELEイベントなしで正常に起動することを確認すると、デバイスを閉じてください(SRKHはフュージョンされると不可逆的です)。部品のブリックを防ぐためです。 (参照:i.MX RT1180セキュリティリファレンスマニュアル。会社のアカウントを通じてNDAに署名した後、オンラインの営業担当者にリクエストを提出してください。) Re: rt1189 Boot Flow こんにちは@yanyanwangさん A1：はい。RT1180はAHABを2つの認証層で使用しています: 署名レイヤー：ECDSA（SHA-256 / SHA-384）は、コンテナヘッダーとイメージ配列エントリ（各イメージのハッシュを格納する）を検証します。 ハッシュ層：ROMはロードされたイメージ本体のダイジェストを再計算し、イメージ配列エントリに格納されているハッシュと比較します。 図中のSHAハッシュ段階はまさにこの必須の整合性チェックであり、ハッシュ値を検証するものです。 A2: ROMは常にハッシュを計算・比較しますが、失敗が強制されるかどうかはデバイスのライフサイクルによって異なります。アウトオブファブのデフォルトはOpen構成で、認証は実行されますが、すべての認証エラーは無視され、画像は実行されます。デバイスをOEM_CLOSEDに移動して初めて 、ハッシュの不一致が起動をブロックします。 リカバリーモードに入るかどうかは、リカバリーブートヒューズの状態によって決まります。有効化されると、プライマリブート認証の失敗がリカバリーデバイスから再ロードおよび再認証が引き起こされます。有効化されていない場合、フローはシリアルダウンローダー/フェイタルモード/リセットループに移行します。 よろしくお願いします、 ギャビン Re: rt1189 Boot Flow multicore_triggerとcm7_helloworldという2つのデモを使用した際、CM7 ITCMのECCは有効にしませんでした。私はSPTツールを使用して、メモリから実行することを目的としたCM33イメージとCM7イメージを1つのイメージに統合し、その後、統合したイメージをUART経由でNORフラッシュに書き込みました。しかし、起動プロセスが失敗しました。マニュアルによると、コンテナには最大8つのOEM画像エントリーを含めることができます。今回のテストでは、CM33画像とCM7画像の2枚のみを使用しました。CM7 ITCM ECCは有効になっていませんでした。 CM33イメージもCM7イメージも起動しなかった。しかし、コンテナヘッダーを確認したところ、CM33イメージしか存在しないことがわかりました。CM33イメージ自体は単独で使っても問題なく正常に起動できます。 CM7イメージが想定どおりに含まれなかった、あるいは処理されなかった理由、そしてCM7 ITCM ECC構成の欠如がブートROMによるCM7イメージの処理方法に影響を与えるかどうかを理解したいと考えています。 質問2： 8つのCM7イメージと1つのCM33イメージを1つのコンテナに統合した場合、ブートROMは起動プロセス中にどのような動作をしますか？ CM7コアは1つしかないのに、ブートROMはどのCM7イメージを起動するかをどのように判断するのでしょうか？もし8枚の画像エントリすべてがCM7の画像なら、Boot ROMは8枚すべての画像を読み込むのか、1枚だけを選択するのか、それとも選択はCM33アプリケーションに任せるのか? Boot ROMは、同じコンテナ内の複数のCM7イメージエントリをどのように識別し、処理するのですか？どのCM7イメージを実行するかを決定するために使用される優先順位、イメージインデックス、コアID、ロードアドレス、エントリポイント、またはその他のメカニズムはありますか？ また、CM7 ITCM ECCが有効になっている場合と無効になっている場合における、ブートROMの正確な動作についても理解しておきたい。 CM7 ITCM ECCが有効になっている場合、ブートROMはCM7 ITCM ECCメモリを初期化し、NORフラッシュからCM7イメージをCM7 ITCMにコピーし、その後CM7をリセット状態から解放するのでしょうか？それとも、Boot ROMはCM7イメージだけを読み込み、CM33アプリケーションはCM7のリセット解除と起動を担当しているのでしょうか? CM7 ITCM ECCが有効になっていない場合、ブートROMは、ロードアドレスがCM7 ITCM内にあるCM7イメージを検出したときにどのような動作をしますか？Boot ROMはCM7イメージをスキップしたり、ロードに失敗したり、CM7をリセット状態にしたり、コンテナのブートプロセス全体を失敗させたりしますか？ 特に、以下のコンテナがサポートされているかどうかを確認したいです。 画像0：CM33 画像1：CM7 画像2：CM7 画像3：CM7 画像4：CM7 画像5：CM7 画像6：CM7 画像7：CM7 画像8：CM7 もしサポートされている場合、ブートROM起動時にこれら8つのCM7イメージは具体的にどのように処理されるのでしょうか？また、実際に実行されるCM7イメージを選択する役割を担うコンポーネントはどれでしょうか？ 最後に、最大8つのOEMイメージエントリがコンテナに8つの異なるイメージを保存できるのか、それともBoot ROMが特定のコアに対して特定のイメージを選択して起動する仕組みを提供しているのかを明確にしたいと思います。

SPD 1.0.3 — eMcem.xdm XDM 架构错误，位于第 717 行（EB Tresos 导入失败） 我报告的是S32K3功能安全外设驱动程序（SPD）1.0.3版本中的一个错误。具体来说，是 eMcem 模块的 XDM 配置文件存在问题，导致无法将其导入 Elektrobit (EB) Tresos Studio。 环境 ┌─────────────────────┬──────────────────────────────────────────────┐ │ 项目 │ 版本 / 路径 │ ├───────────────────┼──────────────────────────────────────────────┤ │ MCU │ S32K344 (S32K3XX) │ ├───────────────────┼──────────────────────────────────────────────┤ │ SPD │ S32K3_SPD 1.0.3 (S32K3_SAF_1.0.3_D2306) │ ├───────────────────┼──────────────────────────────────────────────┤ │ RTD │ SW32K3_RTD 4.4 R21-11 3.0.0P01 │ ├───────────────────┼──────────────────────────────────────────────┤ │ EB Tresos │ 29.0.0（安装在 C:\EB\tresos） │ ├───────────────────┼──────────────────────────────────────────────┤ │ S32 设计工作室 │ 3.6.0│ └─────────────────────┴────────────────────────────────────────────┘ 问题描述 尝试将 eMcem 模块 (eMcem_TS_T40D34M10I3R0) 导入到 EB Tresos 项目中时，XDM 解析器抛出以下错误： ▎ “标签‘a’的属性‘a’无效”位于config/eMcem.xdm文件的第717行 这样就完全阻止了 eMcem 模块被导入到任何 EB Tresos 项目中。 根本原因分析 文件 C:\NXP\S32K3_SPD_1.0.3\eclipse\plugins\eMcem_TS_T40D34M10I3R0\config\eMcem.xdm 的第 715-718 行 RecoveryTimeoutEnabled 参数块中包含无效的 XDM 架构结构： 代码有误（第 715-718 行）： VariantPreCompile 问题在于嵌套的 位于 元素内。根据 XDM 模式（ http://www.tresos.de/_projects/DataModel2/08/attribute.xsd ）， 元素不能 包含另一个 元素作为子元素。 同一文件中所有其他出现位置（例如，第 684-687 行的 ReactionType 参数）使用的正确结构是： 正确代码： VariantPreCompile 这是整个 eMcem.xdm 文件中唯一出现这种格式错误的嵌套的地方（20 多个其他 IMPLEMENTATIONCONFIGCLASS 块都已正确形成）。这显然是SPD包装过程中的复制粘贴错误。 验证 -来自同一 SPD 1.0.3 包的 Bist 模块 (bist_t40d34m10i3R0) 和 SafetyBase 模块 (SafetyBase_t40d34m10i3R0) 没有这个错误 —— 他们的 .xdm文件结构正确，并导入到 EB Tresos 中，没有任何 错误。 - 我确认 Bist.xdm 文件中 内没有嵌套 。 为什么会陷入僵局 eMcem 插件中的 META-INF/CRYPTOMANIFEST.MF 和 META-INF/CRYPTOMANIFESTSIG.MF 文件包含关键插件文件的 DSA 加密签名（密钥 ID：Freescale，提供商：dreisoft.tresos.launcher2.CryptoKeyProvider），其中包括 config/eMcem.xdm。对 .xdm 文件的任何修改文件（即使是单行修复）也会破坏 DSA 签名验证，导致 EB Tresos 因许可证/完整性错误而拒绝该模块。 这将造成无法挽回的死锁： - 由于存在错误，无法导入 — XDM 架构验证失败 - 无法修复此错误——DSA 签名验证失败→许可证错误 - 无法移除签名 — EB Tresos 启动失败（插件完整性检查） 申请它 请提供以下信息之一： 1.一个与我们环境兼容的 SPD 热修复版本（或者至少是一个经过修正的 eMcem.xdm 文件，其中包含更新的 CRYPTOMANIFEST 签名）。 2.包含此修复程序的更新版 SPD（例如 1.0.4 或更高版本）。 3. 许可证重新激活或变通方案，允许我们对 eMcem.xdm 应用必要的单行修复，而不会触发 DSA 签名验证失败。 4. 确认是否存在可解决此问题的更新版 SPD，并提供下载/升级说明。 这个问题阻碍了我们的 S32K344 功能安全软件集成，特别是 EB Tresos 中的 eMcem（扩展微控制器错误管理器）模块配置。 补充说明 SPD 1.0.3发布说明中提到与 RTD 3.0.0 兼容。/ 3.0.0P07。我们正在使用 RTD 4.4 (SW32K3_RTD_4.4_R21-11_3.0.0_P01)。能否请您确认一下 SPD 1.0.3 和 RTD 4.4 的兼容性，并告知是否有更新的版本可以兼容？ RTD 4.x 集成是否需要 SPD 版本？ --- 谢谢你的帮助。如果您需要任何其他信息或日志，请告诉我。 顺祝商祺！ Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 你好@WuDiDi ， SPD 1.0.4 中也存在此问题。 我看到这个问题在 SPD 1.0.5 和 SPD 1.0.6 中已经修复了： danielmartynek_0-1786090704875.png SPD 版本 1.0.5 与 S32K3_S32M27x 实时驱动程序 ASR R21-11 版本 5.0.0 和 4.0.0 兼容。 除 S32K3E 系列（S32K39x 和 S32K36x）外，所有衍生型号均支持 4.0.0 版本。 SPD 版本 1.0.6 与 S32K3 实时驱动程序版本 7.0.0 兼容。+ 6.0.0。 能否更新到更新的RTD/SPD版本？ 自 1.0.3 版本以来，许多 RTD、SPD 错误已被修复。 请注意，NXP 不提供针对过时软件版本的热修复程序。 关于 SPD 1.0.3 的兼容性，我们只能保证与发行说明中明确指定的 RTD 版本兼容。无法保证与其他RTD版本兼容。 此致， 丹尼尔 Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 嗨，丹尼尔， 谢谢你的解释。我目前使用的是 SPD 1.0.5 (D2503) 和 RTD 4.0.0。P01 适用于 S32K342，因此版本兼容性应该没问题。 我有一个关于实现范围的具体问题：SPD 1.0.5 Demo 项目 (S32_SPD_Demo) 只提供了 S32K344/S32K358/S32K388/S32K396 的 TresosProject 配置，而没有提供 S32K342 的配置。我正在将其适配到 S32K342。 请您确认以下关于S32K342的信息： 1. 锁步故障注入：S32K342 是否支持通过 DCM/EIM 机制进行锁步故障注入？S32K342 是单核锁步设备——我在 DCM 故障中看到了 EMCEM_DCM_NCF_3_LC_ERR 和 EMCEM_DCM_NCF_0_PLTFRM_CM7_0_LUP。 列表。这些注射点正确吗？ 2. LBIST/MBIST：Bist_TS_T40D34M10I5R0 插件具有 S32K342 EPD 变体。Bist_SpecificTables_S32K3XX.c 中的 LBIST MISR 黄金签名和 MBIST 分区表对于 S32K342 芯片是否已经正确？我们需要什么？ 针对 S32K342 的具体调整？ 3. 是否有专门针对 S32K342 功能安全验证（LBIST/MBIST/锁步 FI）的 应用笔记或 参考手册可以分享？ Re: SPD 1.0.3 — eMcem.xdm XDM Schema Bug at Line 717 (EB Tresos Import Failure) 你好@WuDiDi ， 后续问题与原话题无关。 请您为他们创建一个新帖子好吗？ 谢谢！ BR，丹尼尔

Which Timer from the FS32K144UAT0VLLT has Input Capture functionality? manager: Question: (1) The FS32K144UAT0VLLT datasheet shows that it has 8 independent TIMEs, but I only see FTM0, FTM1, and FTM2. What else is also a TIME? (2) Which TIME function of FS32K144UAT0VLLT has the Input capture function? Thanks! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Robin_Shen Hello, additional question: 1. In Table 47-1, FTM instances and features of S32K-RM Rev14.2, what is the parameter “Fault inputs”? 2. How many pages in the S32K-RM Rev14.2 manual show that each FTM has input capabilities?What about the capture function? Thanks! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ Hi S32K-RM Rev14.2的Table 47-1. FTM instances and features 表格里S32K144只看到支持FTM0-FTM3. 你提到的应该是指每个FTM支持8 Channels通道。 都支持Input capture功能。 如果你要看FTM instances的功能区别也是看这个表格列出的功能才是某些FTM不支持的。 Best Regards, Robin Re: FS32K144UAT0VLLT哪个Time具备Input capture功能？ A1. This refers to the number of external fault inputs supported. Taking the S32K144 as an example, Table 47-1 shows that it supports 4 inputs. You can see these 4 inputs, FTM0_FLT0\1\2\3, in the table on the left. Table 47-1. FTM instances and features Table 47-2. FTM signal descriptions.png A2. The features supported by each FTM are usually not specifically listed. Refer to Table 47-5.The Channel Modes Selection configuration register can be used to implement the input capture mode mentioned in 47.5.5 Input Capture Mode.

PCA9615 dI2C通信の両端の回路、つまりツイストワイヤ束を介して接続された2枚のPCB間の回路（DSDAPとDSDAM、DSCLPとDSCLM、2本のGND、および2本の5Vライン）について助けを求めてご連絡しました。この前にGeminiをテストすることに決め、残念ながらdI2C通信に関連する2つのPCBの部品を生成するためにAIに頼ってしまいました。dI2Cに関連する回路図の一部を添付します。当然のことながら、各ボード間には通信手段がありませんでしたが、私の怠惰と、正直に言うと愚かさ（教訓になりました）のせいで、多くの時間を無駄にしてしまいました。最終的にデモボードのデータシートとユーザーマニュアルを参照したところ、明らかな違いは正の線(DSCLPとDSDAP)とVDD(B)の間に600オームの抵抗があり、負極線(DSCLMとDSDAM)とVSSの抵抗が同じで、正負の線間は120オームで、正負の線間は100オームになると知っています(1/600 + 1/120 = 1/600 + 5/600 =100ですが、電気的には見えません。多分機械工学者だからでしょうか?この誤差(おそらく複数のエラーの一つ)は、それぞれのウィリーの間に600オームプルアップ抵抗、600オームプルダウン抵抗、120オーム抵抗が存在しないことによるものです(28 AWGツイストワイヤペアの特性インピーダンスは、内部データリンクやUSB/イーサネット構成で約100オームのケーブル、標準的な間隔構成では78 Ωから95 Ωの配線です。PVCまたはFEP絶縁線)を使い、代わりにPCA9615のdI2C側の接続線の両端に100オームのリサイザーを単純に設置するという、単純化され、おそらく誤ったバージョンだったのでしょうか? これは、AIが私に示してくれた結果と、データシートの図1、7、8、9に示されている結果との間の重要な相違点の1つです。もう一つの違いは、AIが2枚のプリント基板に対して異なるコンデンサ配置を提案したのに対し、デモボードには1種類の配置しかない点です（これはdI2C接続ラインの両側で使用されるものと思われます）。さらに、VDDAピンとVDDBピンそれぞれに2つのコンデンサがあるようです。どちらもセラミックコンデンサです（ただし、最初に思ったのは、2つの黄色のコンデンサはタンタルタイプだろうということでした）。デモのユーザーマニュアルに記載されているコンデンサ配置を使い、添付のAIが提供・示したものは無視してもいいのでしょうか? もう一つの問題は、マスター側(私が3.3Vマイクロコントローラを使っている)では、当初AIがイネーブルピンを5Vラインにコネクテッドするよう指示していたことですが、基板を作った後、両基板間で機能がなかったため、AIはマスター側のイネーブピンをマスターボードの3.3Vライン(VDD(A)にコネクテッドすべきだと判断しました。3.3Vのラインにコネクテッドされています。その後、テストとして、マスター基板上のイネーブルピンへの電源供給を完全に遮断するよう要求した。どの電源、もし全てをENピンに流すべきなら、アドバイスしてもらえますか?テスト中または最終動作中は、電気部品のホットスワップは一切行いません。 上記変更の実施を検討していますが、高価な基板を導入する前に、ぜひとも皆様のご意見を伺いたいと思っています。 Re: PCA9615 コンデンサに関してもう一つ補足すると、マスター基板上のVDDAピンとVDDBピンの両方には、デカップリングコンデンサのみが推奨されています。スレーブ基板にもデカップリングコンデンサが提案されたが、スレーブ基板のVDDBピンにもさらに2つのコンデンサが提案された。 Re: PCA9615 こんにちは！ 詳しい説明をありがとうございました。 なお、NXPはPCA9615ファミリの評価ボードを提供しており、実装の**リファレンス・デザイン**として利用できます。デザインには推奨される差動I²C終端ネットワーク、バイアス抵抗、デカップリングコンデンサ、ENピン接続が含まれており、NXPによって検証されているため、回路図をPCA9615評価基板および対応ユーザーマニュアルと比較することを強くお勧めします。 評価ボード回路図を基準に、カスタムPCA9615ベースのシステムを設計する際には、設定やレイアウトの問題のリスクを最小限に抑え、データシートやアプリケーションドキュメントの推奨事項に従うため、最良のアプローチとなることが多いです。 次のPCB改訂に取り組む前に、評価ボードの回路図を確認し、設計を適切に更新することをお勧めします。 https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL お役に立てば幸いです！

调用 Clock_Ip_Init() 时外部数据中止 您好， 我正在尝试使用RTD和S32 DS mex工具初始化一些外设时钟。（注意：我是在 M7 项目中生成代码，但实际构建和运行是在 A53 项目中进行的。） 然而，在 Clock_Ip_Init() 函数内部发生了外部数据中止。具体来说，调用堆栈如下所示： Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref()。 这似乎是首次尝试向 CMU 外围存储器写入数据。故障发生在内存0x4005'C028上的LDR指令中，根据 S32G3 内存映射，该内存正确地位于 CMU 内存区域内。 目前 MMU 尚未启用，但据我了解，外部数据中止发生在 CPU/MMU 之外，可能与安全访问或“锁定”的外围设备有关。 我的理解是，在调用 Clock_Ip_Init() 之前，需要以某种方式使 CMU 可以从 A53 内核“访问”，这种说法对吗？如果可以的话，您能否告知我具体的操作步骤？ 顺祝商祺！ 乔尼 设备 = S32G399A 编译器 = S32DS_GCC_11_4 核心 = 皮层 A53 Re: External Data Abort when calling Clock_Ip_Init() 嗨， jonnyWHIS 感谢您与我们联系。 您打算在 S32DS IDE 中创建可在 S32G A53 内核上运行的裸机代码吗？ BR 乔伊

iMX8 Nano 内核从 5.15 更新至 6.18 你好 在将 A53 内核从 5.15 移植到 6.18 时，遇到了 rpmsg 的问题。 # dmesg -T | grep -Ei 'rpmsg|rproc' [2024年10月8日星期二 15:42:28] imx rpmsg 驱动程序已注册。 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：错误 -ENOENT：启用时钟失败 [2024年10月8日星期二 15:42:29] imx-rproc imx8mn-cm7：使用驱动程序 imx-rproc 进行探测失败，错误代码为 -2 [2024年10月8日星期二 15:42:29] remoteproc remoteproc0：正在释放 imx-rproc 我遇到了这个错误。我在网上搜索这个错误时，有人建议我在 DTS 文件中添加一个虚拟时钟，如下所示。 imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7"; rsc-da = <0xb8000000>; clocks = <&clk IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; 内存区域 = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; 状态 = "正常"; } 请问是否只需要做这一项更改？更改的原因是什么？ 问候 亚杜纳特·R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 不——我不会将 clocks = <&clk IMX8MN_CLK_DUMMY>; 视为唯一需要的更改。或许可以解决眼前的 -ENOENT：启用时钟探测失败的问题，但对于 i.MX8M Nano 来说，重要的要求是，当 Linux 加载/启动 M7 固件时，Cortex-M7 根时钟必须保持启用状态。 原因： imx-rproc 节点应该有一个时钟条目；AN5317 显示了 i.MX8M remoteproc DTS 节点，其 compatible = "fsl,imx8mn-cm7" 和 clocks = <...> 属性，以及邮箱和内存区域条目。 您的错误意味着内核 6.18 imx-rproc 驱动程序尝试从该节点获取/启用时钟，但时钟查找失败并出现 -ENOENT 错误，因此在 remoteproc0 保持注册状态之前探测中止。 NXP 的 AMP 指南指出： “对于 i.MX 8M 平台，Linux 必须始终启用 M7/M4 的根时钟，才能加载固件代码并启动 Cortex M7/M4。”它还指出，NXP Linux 电路板支持包 在 M 内核从 U-Boot 启动时保持此根时钟启用；否则，如果 M 内核首先从 Linux 启动，则必须更新 drivers/clk/imx/clk-composite-8m.c 以跳过 M 内核时钟的门注册。 所以这一变化有两种可能的含义： 使用虚拟时钟作为兼容性替代方案 如果内核 6.18 imx-rproc 需要一个 clocks 属性，但实际的 M7 时钟并非有意通过通用时钟框架控制，则添加 IMX8MN_CLK_DUMMY 可以满足驱动程序的时钟句柄要求，并避免 -ENOENT。 真正的时钟控制修复 如果 Linux 实际上负责加载/启动 M7，那么仅使用虚拟时钟可能会掩盖探测错误，但不能保证 M7 时钟已启用。在这种情况下，您必须确保 M7/M4 根时钟保持开启状态，这可以通过 NXP 电路板支持包时钟驱动程序处理或 clk-composite-8m.c 文件来实现。AN5317 中描述的变更。 此外，还要检查 remoteproc/rpmsg DTS 的其余部分，而不仅仅是时钟线： imx8mn-cm7 { 兼容 = "fsl,imx8mn-cm7";         rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* 或您的 电路板支持包 使用的正确 M7 时钟 */ mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>; memory-region = , , , ;         status = "okay"; }; 内存区域列表很重要，因为 AN5317 指出此属性必须包含固件 ELF 使用的内存部分，以便 remoteproc 可以从 sysfs 重新加载它。 推荐检查路径： 如果从U-Boot启动 M7，请使用 NXP 流程，例如 prepare_mcore / bootaux，然后启动 Linux；AN5317 指出，这是 BSP 保持 M 内核根时钟启用的路径。 如果您从Linux remoteproc启动 M7，请确认您的 6.18 时钟驱动程序包含 NXP 处理，以保持 M 内核根时钟始终启用；否则，虚拟时钟可能只能修复探测，而不能修复运行时启动/加载。 将您的 DTS 与 NXP imx8mn-*-rpmsg.dts 进行比较对于同一个 BSP 版本，特别是时钟、mboxes、rsc-da 和保留内存布局。 虚拟时钟解释了立即出现的 -ENOENT 探测失败，但真正的设计要求是保持 i.MX8MN M7 根时钟启用；仅靠 DTS 是否足够取决于你的 6.18 BSP 时钟驱动程序是否已经保留了该时钟。

RT1171CVM8BでのモバイルSDRAM(1V8)サポート 私たちは新製品に使われるRT1171CVM8Bを調査しています。 このRTファミリーのメンバー i.MX モバイル(低消費電力、1.8V)SDRAMに対応していますか? データシート、リファレンスマニュアル、利用可能なアプリケーションノートや回路図からは、それがすぐには明確ではありません。これは1V8および3V3の両方で指定されているポートドライバ(NVCC_EMC1,2)によって推論されます。また、RT1060およびRT1050 i.MX の類似の質問や回答から肯定の推論も得られます。 EMCやSDRAMインターフェースの特殊な部分が1V8の部品で故障するようなトラブルは避けたいです。 そうでなければ、なぜデータシートに明確に記載されていないのでしょうか!? 敬具 ジョージ・ツァナトス。 Re: Support for mobile SDRAM (1V8) on RT1171CVM8B @georgetzanatos様、 RT1171はモバイルSDRAM(低消費電力1.8V SDRAM)をサポートしています。 現在のドキュメントにはこれを明確に記載していないことには同意します。データシートおよびリファレンスマニュアルでは、メモリプロトコルのサポートとI/O電圧モードが別々に説明されており、単一の「モバイルSDRAMサポート」文にまとめられているわけではありません。 ご心配は理解できます。RT1171のモバイル SDRAMを使っても構いません。重要な要件は、関連するNVCC_EMC1/2電源ドメインを1.8V動作用に設定し、SDRAMのI/O電圧レベルに合わせることです。   よろしくお願いいたします。 シェリー

T2081プロセッサからMT29F64G08AECAB 8GB NANDフラッシュにアクセスできない こんにちは、 私はT2081 NXPプロセッサを、IFC経由で外部NANDフラッシュMT29F64G08AECABに接続しています。 私の目標は、CodeWarrior上でこのNANDフラッシュの診断テストを実行するか、あるいはCodeWarrior上でこのデバイスのデバイスIDと製造元IDを読み取ることです（そのためのコードは既に作成済みです）。 この目標を達成するために、私は既に以下のことを実行しました。 1. 生成されたT2081QDS_init_core.tcl で、0xFF800000 から始まるサイズ 1MB のNAND IFC 用の LAW を設定しました。 ## LAW3からIFCへのNAND # ローバー mem [CCSR_ADDR 0x000C30] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000C34] = 0xFF800000 # 戦争 mem [CCSR_ADDR 0x000C38] = 0x81F00013 2. また、以下のようにNANDに対応するCSPRレジスタとFTIMレジスタを設定しました。 NAND_CS 5 を設定 # NANDフラッシュ、アドレス0xFF800000、サイズ1MB、8ビットNAND、ECC無効 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 #マスク mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 プロセッサからNANDへ向かうチップセレクトが2つあり(CS5とCS6)、今のところ最初の4GBにアクセスしようとしているので、CS5のみの設定をしています。 3. 設定済みのTLB: 細かい 1M TLB エントリ 5 : 0xFF800000 - 0xFF8FFFFF (NAND キャッシュ禁止、ガード付き) reg ${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. インストール済みディレクトリにはこのMT29F64G08AECABのサポートが見つからなかったため、マニュアルに従ってこのデバイス用の.xml(4GB分)を作成し、ここに添付しました。 これらすべてを実行した後、CodeWarriorでNANDデバイスの診断テストを実行すると、以下のエラーが表示されます。 Nisarga_R_0-1786096350786.png 代替案として、このデバイスからデバイスIDを読み取るための簡単なC言語コードを書いてみました。そこで、以下のコードをCode Warriorで書き、ここに添付しました。その結果、IFC_NAND_MDRレジスタを読み戻すと、デバイスIDと一致しない0x124E0000が返されます。 診断テストを実行できない、またはデバイスIDを読み取れないのは、私が何か間違ったことをしているか、何かを見落としているからでしょうか。 参考資料として、関連するT2081QDS_init_core.tclファイルと回路図を添付しました。 よろしくお願いいたします。 ニサルガR   QorIQ T2デバイス Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor 現在、社内チームと話し合っています。 よろしくお願いします。

Selection of FS2613 chip The FS2613 series chips are quite powerful, and the values and timings of each power rail are editable. However, we don't have much time for software development and prefer not to implement OTP ourselves. Are there any models that are factory-configured to be compatible with the S32K358? For example, like the one shown in the image below? Rio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 See attachment Re: 关于FS2613芯片的选型 Okay, for the MFS2633AMDB2AD model, what are the output voltages of each of the following channels after power-on by default? Where do VCORE, LDO1, LDO2, VREF, VBST, TRK1, and TRK2 originate? Re: 关于FS2613芯片的选型 MFS2633AMDB2AD Search | NXP Semiconductors You can choose this one! Re: 关于FS2613芯片的选型 The MFS2633AMDB2AD is discontinued. With the same specifications, I should replace it with the MFS2633HMDB2AD, right? Re: 关于FS2613芯片的选型 Yes! Re: 关于FS2613芯片的选型 Please submit a new ticket for new questions. Thank you! Re: 关于FS2613芯片的选型 How are PIN.17 FCCU1 and PIN.18 FCCU2 used on this chip? What truth table do the input values of these two pins form, triggering different protection mechanisms of the chip?

rt1189 启动流程 1.如图所示，“图像认证”过程是否会在 安全散列算法(SHA)-512 哈希阶段验证哈希值？ yanyanwang_0-1786097643048.png 2. 如果我设置了哈希值，BootROM 会验证镜像完整性吗？如果 BootROM 验证失败，它会进入恢复模式吗？ Re: rt1189 Boot Flow yanyanwang_0-1786444750281.png yanyanwang_1-1786444764361.png 如上图所示，如果我只对镜像进行签名而不进行加密，它是否能够通过 bootrom 验证流程？此外，启用 oem_close 后，它是否还能进入 bootrom 验证流程？     Re: rt1189 Boot Flow 以下是您两个问题的答案： 1. 仅签名（未加密）的镜像能否通过 BootROM 验证流程？是的。在 RT1180 AHAB 中，签名（认证）是安全启动的必要部分，可确保映像的真实性和完整性，而加密（OTFAD/IEE）是一个独立的、可选的防克隆功能，并非验证的先决条件。因此，仅签名的图像将正常地经过完整的 AHAB 签名验证流程，这也是 NXP 官方 SPSDK rt118x_secure_boot 示例中的标准方法。 2. 启用 oem_close (OEM_CLOSED) 后，是否仍会进入验证流程？是的，验证将成为强制性要求。 建议：在执行 oem_close 之前，请先将签名映像编程到 OEM_OPEN 状态，并确认其启动成功且无 ELE 事件，然后再关闭设备（SRKH 一旦熔丝就不可逆），以避免损坏设备。 （请参阅：i.MX RT1180 网络安全参考手册。）通过公司账户签署保密协议后，请向在线技术销售代表提交申请。） Re: rt1189 Boot Flow 1. 是否只有在启用签名认证功能时才启用哈希验证？如何独立启用哈希验证？如何将设备过渡到 OEM_CLOSED 生命周期状态？ 2. 我将启用恢复启动熔丝。 3. 我的目标是使用未加密的图像。启动ROM应计算并验证镜像哈希值。如果哈希验证失败，启动 ROM 应进入恢复启动流程，并从 LPSPI NOR Flash 启动恢复映像。 Re: rt1189 Boot Flow 嗨@yanyanwang ， A1：是的。RT1180 使用 AHAB 协议，并采用两层认证： 签名层：ECDSA（安全散列算法(SHA)-256 / 安全散列算法(SHA)-384）验证容器头和图像数组条目（存储每个图像的哈希值）。 哈希层：ROM 重新计算已加载图像主体的摘要，并将其与存储在图像数组条目中的哈希值进行比较。 图中所示的 安全散列算法(SHA) 哈希阶段正是这种强制性的完整性检查，它确实会验证哈希值。 A2： ROM始终会计算并比较哈希值，但是否强制执行错误取决于设备的生命周期：出厂默认配置为 Open，此时会运行身份验证，但所有身份验证错误都会被忽略，镜像仍然可以执行。只有在设备切换到 OEM_CLOSED 状态后，哈希值不匹配才会真正阻止启动。 是否进入恢复模式取决于恢复启动熔丝。如果启用，主启动身份验证失败将触发从恢复设备重新加载和重新身份验证；如果未启用，则流程将进入串行下载器/致命模式/RESET循环。 此致， 加文 Re: rt1189 Boot Flow 使用 multicore_trigger 和 cm7_helloworld 这两个演示程序时，我没有为 CM7 ITCM 启用 ECC。我使用 SPT 工具将 CM33 镜像和 CM7 镜像（旨在从内存运行）合并成一个镜像，然后通过 UART 将合并后的镜像编程到或非 Flash 中。然而，启动过程失败了。根据手册，一个容器最多可以包含 8 个 OEM 图像条目。在我的测试中，我只包含了两张图片：一张 CM33 图片和一张 CM7 图片。CM7 ITCM ECC 未启用。 CM33 和 CM7 镜像均未启动。但是，当我检查容器头时，发现其中只有 CM33 镜像。CM33 镜像本身单独使用时可以正常启动，不会出现任何问题。 我想了解为什么 CM7 镜像没有被包含或按预期处理，以及缺少 CM7 ITCM ECC 配置是否会影响 Boot ROM 处理 CM7 镜像的方式。 问题2： 如果我将 8 个 CM7 镜像和 1 个 CM33 镜像合并到一个容器中，启动过程中 Boot ROM 会执行什么操作？ 由于只有一个 CM7 内核，启动 ROM 如何确定应该启动哪个 CM7 镜像？如果所有 8 个图像条目都是 CM7 图像，启动 ROM 会加载所有 8 个图像、只选择一个图像，还是将选择权交给 CM33 应用程序？ Boot ROM 如何识别和处理同一容器中的多个 CM7 映像条目？是否存在优先级、映像索引、核心 ID、加载地址、入口点或其他机制来确定执行哪个 CM7 映像？ 我还想了解启用 CM7 ITCM ECC 和未启用 CM7 ITCM ECC 时启动 ROM 的确切行为。 启用 CM7 ITCM ECC 时，启动 ROM 是否会初始化 CM7 ITCM ECC 存储器，将 CM7 映像从 NOR Flash 复制到 CM7 ITCM，然后释放 CM7 的 RESET 状态？或者说，Boot ROM 只负责加载 CM7 镜像，而 CM33 应用程序负责解除 CM7 的 RESET 状态并启动它？ 当 CM7 ITCM ECC 未启用时，启动 ROM 在遇到加载地址位于 CM7 ITCM 中的 CM7 映像时会做什么？启动 ROM 是否会跳过 CM7 镜像、无法加载、使 CM7 保持重置状态，或者导致整个容器启动过程失败？ 我尤其想确认一下是否支持以下容器： 图片 0：CM33 图1：CM7 图2：CM7 图3：CM7 图4：CM7 图5：CM7 图6：CM7 图7：CM7 图8：CM7 如果支持，那么在启动 ROM 时，这 8 个 CM7 镜像究竟会发生什么？哪个元器件负责选择实际执行的 CM7 镜像？ 最后，我想澄清一下，最多 8 个 OEM 镜像条目是指容器可以简单地存储 8 个不同的镜像，还是 Boot ROM 也提供了一种机制，可以为给定的核心选择和启动特定的镜像。

iMX8 Nanoのカーネルを5.15から6.18にアップデート こんにちは A53コア用にカーネルを5.15から6.18に移植する際、rpmSGの問題に直面しています。 # dmesg -T |grep -Ei 'rpmsg|rproc' [2024年10月8日火曜日 15:42:28] IMX RPMSGドライバーが登録されました。 [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: error -ENOENT: クロックを有効にしられませんでした [2024年10月8日火曜日 15:42:29] imx-rproc imx8mn-cm7: ドライバ付きプローブ imx-rproc エラー -2 で失敗 [火曜日 2024年10月8日 15:42:29] remoteproc remoteproc0: releaseingimx-rproc このエラーが出ます。このエラーをオンラインで検索したところ、DTSにダミークロックを追加するように求められました。 IMX8Mn-CM7 { 互換性 = "FSL,IMX8mn-CM7"; RSC-DA = <0xb8000000>; クロック = <&CLK IMX8MN_CLK_DUMMY>; mbox-names = "tx", "rx", "rxdb"; mbox = <μ 0 1 &ミュー 1 1 μ 3 1>; memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "OK"; } これが唯一の変更なのでしょうか?この変更の理由は何ですか。 よろしくお願いいたします ヤドゥナス・R Re: iMX8 Nano Kernel updation from 5.15 to 6.18 いいえ、私は clocks = <&clk IMX8MN_CLK_DUMMY>; を唯一の必要な変更として扱うつもりはありません。これで即時の-ENOENT: Failed to Enable Clock probe failureを乗り越えられるかもしれませんが、i.MX8M Nanoの場合、重要な要件はLinuxがM7ファームウェアを読み込み/起動する際にCortex-M7のルートクロックが有効のままであるということです。 理由： imx-rproc ノードにはクロックエントリがあることが想定されています。AN5317 では、compatible = "fsl,imx8mn-cm7" と clocks = <...> プロパティ、さらに mailbox および memory-region エントリを持つ i.MX8M remoteproc DTS ノードが示されています。 あなたのエラーは、カーネル6.18のimx-rprocドライバーがそのノードからクロックを取得して有効化しようとした際、-ENOENTでクロック検索が失敗したため、リモートプローク0がレジスタジアムのままになる前にプローブが中止されたことを意味します。 NXPのAMPガイダンスには「i.MX 8Mプラットフォームでは、M7/M4のルートクロックを常にLinuxで有効にしてファームウェアコードを読み込み、Cortex M7/M4を起動させる必要があります」とあります。 また、NXP Linux BSPはU-BootからMコアを起動した際にこのルートクロックを有効にしているとも書かれています。それ以外の場合、MコアをLinuxブートから起動した場合、ドライバ/clk/imx/clk-composite-8m.cを更新してMコアクロックのゲート登録をスキップする必要があります。 したがって、この変化には二つの意味が考えられます。 ダミークロックを互換性回避策として使う カーネル6.18 imx-rprocがクロックの性質を必要としているが、実のM7クロックが共通クロックフレームワークで意図的に制御されていない場合、IMX8MN_CLK_DUMMYを追加することでドライバーのクロック処理要件を満たし、-ENOENTを回避できます。 実クロック制御の修正 もしLinuxが実際にM7の読み込みや起動を担当している場合、ダミークロックだけではプローブエラーを隠すかもしれませんが、M7クロックが有効になる保証はありません。その場合、NXP BSPクロックドライバーの処理かclk-composite-8m.cのいずれかでM7/M4のルートクロックがオンになっていることを確認してください変更内容はAN5317に記載されています。 クロックラインだけでなく、remoteproc/rpmsg DTSの残りの部分も確認してください。 imx8mn-cm7 { 互換性 = "fsl,imx8mn-cm7";      rsc-da = <...>; clocks = <&clk IMX8MN_CLK_DUMMY>; /* または、お使いのBSPで使用される正しいM7クロック */      mbox-names = "tx", "rx", "rxdb";      mboxes = <μ 0 1>, <μ 1 1>, <μ 3 1>;      memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>; status = "オーケー"; }; メモリ領域リストは重要で、AN5317ではこのプロパティがファームウェアELFで使用されるメモリセクションを含まなければならず、remoteprocがsysfsから再ロードできるとされています。 推奨されるチェックパス： M7をU-Bootから起動する場合は、NXPのprepare_mcore/bootauxなどのフローを使い、その後Linuxを起動します。AN5317によると、BSPはこの経路でMコアのルートクロックを有効にしています。 Linux remoteprocからM7を起動する場合、6.18クロックドライバーにNXP対応が含まれているか確認し、Mコアのルートクロックを常に有効にしてください。そうでなければ、ダミークロックはプローブのみを修正し、実行時の開始・ロードは修正されません。 作成したDTSファイルをNXP imx8mn-*-rpmsg.dtsと比較してください。同じ BSP リリースの場合、特にクロック、mboxes、rsc-da、および予約済みメモリレイアウト。 ダミークロックは即時の-ENOENTプローブ故障を説明しますが、実際の設計要件はi.MX8MN M7のルートクロックを有効にしておくことです。DTSだけで十分かどうかは、6.18 BSPクロックドライバーがすでにそのクロックを保持しているかどうかに依存します。

FS2613チップの選定 FS2613シリーズのチップは非常に高性能で、各電源レールの値とタイミングを編集できます。しかし、ソフトウェア開発にあまり時間をかけられないため、OTPを自社で実装することは避けたいと考えています。S32K358と互換性を持つように工場出荷時に設定されているモデルはありますか？例えば、下の画像に示されているようなモデルです。 Rio_Lee_0-1786090969347.png Re: 关于FS2613芯片的选型 添付ファイルを参照してください Re: 关于FS2613芯片的选型 さて、 MFS2633AMDB2ADモデルの場合、電源投入後の各チャンネルの出力電圧はデフォルトでどのくらいですか？ VCORE、LDO1、LDO2、VREF、VBST、TRK1、TRK2はどこから発生するのですか？ Re: 关于FS2613芯片的选型 MFS2633AMDB2AD 検索 | NXPセミコンダクターズ あなたはこれを選ぶことができます！ Re: 关于FS2613芯片的选型 MFS2633AMDB2ADは製造中止になりました。同じ仕様であれば、MFS2633HMDB2ADに交換すれば良いですよね？ Re: 关于FS2613芯片的选型 はい！ Re: 关于FS2613芯片的选型 このチップでは、PIN.17 FCCU1とPIN.18 FCCU2はどのように使用されますか？これらの2つのピンの入力値はどのような真理値表を形成し、チップのさまざまな保護メカニズムをトリガーしますか？ Re: 关于FS2613芯片的选型 新しいご質問については、新しいチケットを送信してください。よろしくお願いいたします。

S32DSのアクティベーションコードが必要です。 S32DSのインストールに必要なアクティベーションコードを取得するには、署名済みの秘密保持契約書（NDA）と会社のメールアドレスが必要です。会社のメールアドレスをお持ちでない場合は、申請方法をご確認ください。

重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 重新安装 S32DS 环境和 SDK 包导致之前的项目编译失败。 过去，我的项目使用了 S32DS V2.2 和 SDK RTM 2.0.0。现在，重新安装后，我使用的是 S32DS.ARM.2018.R1，并且也安装了 SDK RTM 2.0.0。但我现在无法编译这个项目。它似乎无法识别该项目本身。图片中可以看到细节。 Re: Reinstalling the S32DS environment and SDK package has caused previous projects to fail to compi 你好@yangcao1234 请注意，S32K1 SDK RTM 2.0.0 是专门为 S32DS for ARM 2018.R1 Update 6 发布的。它并非设计用于 ARM 2.2 的 S32DS，并且不能保证与该版本兼容。 BR，VaneB

PCA9615 我写信是为了寻求帮助，解决 dI2C 通信两端的电路问题——两个 PCB 板之间通过双绞线束进行通信（DSDAP 和 DSDAM；DSCLP 和 DSCLM；两条 GND；以及两条 5V 线）。在此之前，我决定测试 Gemini，因此很遗憾，我依靠 AI 来生成与 dI2C 通信相关的两个 PCB 的部分。附件是与 dI2C 相关的原理图部分。不出所料，各板之间没有任何沟通，但我的懒惰，以及我不得不说的愚蠢（吸取教训了），让我浪费了很多时间。我最终查阅了演示板的数据手册和用户手册，发现一个明显的区别是，正极线（DSCLP 和 DSDAP）与 VDD(B) 之间有 600 欧姆的电阻，负极线（DSCLM 和 DSDAM）与 VSS 之间也有 600 欧姆的电阻，而正负极线之间则有 120 欧姆的电阻，这显然导致正负极线之间的电阻为 100 欧姆（我知道 1/600 + 1/120 = 1/600 + 5/600 = 100，但我无法从电路角度理解——也许是因为我是机械工程师？）。这个错误（或许是多个错误之一）是否是由于在每对导线之间缺少一个600欧姆的上拉电阻、一个600欧姆的下拉电阻和一个120欧姆的电阻造成的？（28 AWG双绞线的特性阻抗约为100欧姆，用于内部数据链路和USB/以太网配置；对于使用PVC或FEP绝缘导线的标准间距配置，阻抗为78欧姆至95欧姆。） 这是人工智能给出的结果与我在数据手册的图1、图7、图8和图9中看到的结果之间的一个显著区别。另一个区别是，AI 为两个 PCB 建议了不同的电容排列方式，而演示板上只有一种排列方式（我假设这种排列方式用于 dI2C 连接线的两侧）。此外，VDDA 引脚和 VDDB 引脚似乎各有两个电容——都是陶瓷电容（尽管我最初的想法是那两个黄色电容应该是钽电容）。我可以使用演示用户手册中提供的电容配置，而忽略 AI 在附件中提供和显示的内容吗？ 另一个问题是，在主控端（我使用的是 3.3V 微控制器），最初 Ai 指示将使能引脚连接到 5V 线，但在电路板制作完成后，两个电路板都没有任何功能，这促使 AI 确定主控端的使能引脚应该连接到 3.3V 线（主板上的 VDD(A) 连接到 3.3V 线）。然后，它要求完全切断主PCB板上使能引脚的所有电源，作为一项测试。请问是否需要向 EN 引脚供电，以及供电方式是什么？在测试或最终运行期间，我不会对任何电气硬件进行热插拔。 我正在考虑实施上述更改，但在进一步投入资金购买昂贵的电路板之前，非常希望得到您的帮助。 Re: PCA9615 关于电容还有一点需要说明，建议主PCB上的VDDA和VDDB引脚都只使用去耦电容。建议在从机PCB板上使用去耦电容，同时还建议在从机PCB板上的VDDB引脚上额外添加两个电容。 Re: PCA9615 您好！ 感谢您的详细解释。 请注意，NXP 为 PCA9615 系列提供了一个评估板，可作为您实现的参考设计。我们强烈建议您将您的原理图与 PCA9615 评估板及其相关用户手册进行比较，因为该设计包含了 NXP 验证过的推荐差分 I²C 终端网络、偏置电阻、去耦电容和 EN 引脚连接。 在设计基于 PCA9615 的定制系统时，以评估板原理图为基准通常是最佳方法，因为它能最大限度地降低配置或布局问题的风险，并遵循数据手册和应用文档中提供的建议。 我们建议您在进行另一次 PCB 修改之前，先查看评估板原理图并相应地更新您的设计。 https://www.nxp.com/products/interfaces/ic-spi-i3c-interface-devices/ic-i3c-bus-repeaters-buffers-and-extenders/pca9616pw-demo-board:OM13523UL 希望这能帮到你！

imx95lpddr5 evk の全負荷状態をシミュレートするために i.MX95 LPDDR5 EVKボード上で、フルロード動作状態をシミュレートする方法。画像や事前コンパイルされたアプリケーションはありますか?私はLinuxのマルチメディアイメージを使っています。 Re: To simulate full load condition on the imx95lpddr5 evk こんにちは、 参考として、以下のアプリケーションノートをご利用ください: https://www.nxp.com/docs/en/application-note/AN14449.pdf 高負荷CPUテストを達成するためのユースケースはいくつかあります。 ぜひご覧になってみてください。 CA55 コアマーク eIQベンチマーク(GPU) eIQベンチマーク（NPU） よろしくお願いいたします。