S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hi, I'm using the following configuration: S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 As mentioned in a previous post, S32K388 GMAC0 Eth_43_GMAC driver not getting RX interrupt . I used the provided Eth_InternalLoopback_S32K388 example project as base, and modified it so that it can receive frames from my PC through a media converter. Now I'm trying to get the other way going, i.e. transmitting an ethernet frame from S32K388 eval board back to my PC. I am running wireshark on my PC to capture the frame. The frame that I'm trying to send is a broadcast frame with MAC address FF:FF:FF:FF:FF:FF. However, I was only able to get 1 frame on my PC in multiple tries, i.e. it is not consistent. @PavelL, can you kindly help again with this issue? Thanks. Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hello @James_Zhang_SE , I reviewed your project and found only a few minor configuration differences, none of which appear to affect Ethernet transmission.   Could you please clarify what you mean by receiving only one frame in multiple tries? For example, do you observe one frame after each complete power cycle of the board or only occasionally after several power cycles or debug sessions? Also, are you running the application continuously in the debugger or restarting it before each transmission attempt?   The application calls Eth_43_GMAC_Transmit() only once and then enters the infinite while (1) loop. Therefore, only one transmitted frame is expected per application run.   The inconsistent behavior may be caused by the Ethernet PHY link not being established when the transmission is requested. The frame is transmitted immediately after the GMAC controller is set to active mode, without checking the PHY link status. If the TJA1120 link is not yet up, the only transmitted frame may be lost.   Please try waiting until the PHY reports link-up before calling Eth_43_GMAC_ProvideTxBuffer() and Eth_43_GMAC_Transmit(). An example of reading the TJA1120 link status can be found in device.c, using bool get_device_link_status(uint8_t u8TrcvIdx);   This function is used by the S32K388_gptp_ds example included in SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zip, which is suitable for S32K3 RTD 7.0.1.   As a simple initial test, you can also add a sufficiently long delay before the transmission. If this makes the frame appear consistently, it would confirm that the issue is related to PHY link establishment. Best regards, Pavel Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hi Pavel, Thank you for the prompt response! I tried a couple of things today: I tested the same hardware setup using the TCP/IP stack example. With that example, everything works properly, and I am able to receive echo responses on my PC from the S32K388 evaluation board. In my application, I placed a breakpoint immediately after: Eth_43_GMAC_SetControllerMode(EthConf_EthCtrlConfig_EthCtrlConfig_0, ETH_MODE_ACTIVE); After reaching the breakpoint, I waited for a while and then manually continued with Eth_43_GMAC_ProvideTxBuffer(). Unfortunately, I still did not receive any transmitted frame on the PC side. Regarding the behavior I described previously, each time I test the application I power-cycle both the media converter and the evaluation board. I then use the embedded debugger to load the application and start execution. So far, I have observed two successful transmissions, but I have not been able to determine what was different in those two cases or why the frames were transmitted successfully. All of my other attempts, including the tests I performed today, have been unsuccessful. I really appreciate your help with this issue so far. I’m still trying to understand what might be causing this behavior, and I would greatly appreciate any further guidance or suggestions you may have. Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hello @James_Zhang_SE , Thank you for the detailed update. The fact that the TCP/IP stack example works correctly with the same hardware setup confirms that the basic hardware path, GMAC interface and Ethernet link are operational. I modified the main.c file of my internal loopback example to wait explicitly for link-up before transmitting the frame. I tested this implementation on my S32K388EVB-Q289 and after every power-up I can consistently see the transmitted frame in Wireshark. I also tested the following sequence: Disconnect the cable between GMAC0 and the media converter. Power up the S32K388 evaluation board and start the application. Reconnect the cable to the media converter. After reconnecting the cable, the application detects the link and the transmitted frame appears in Wireshark as expected. My hardware setup is: S32K388EVB-Q289 GMAC0 ↔ TE-1402 media converter configured for 1 Gbit/s and Follower mode ↔ USB-to-Ethernet adapter ↔ Dell laptop running Windows 11 I share my modified main.c, the corresponding .mex configuration file and mex_diff.html so that you can compare my configuration with yours more easily. Please replace the provided files as appropriate, run Update Code in S32 Design Studio and then rebuild the project before testing it. There may still be a configuration detail in my .mex file that is important for reliable transmission. Therefore, I recommend first testing the shared configuration without further modifications. If it works on your setup, you may then use mex_diff.html to identify the relevant difference between the two configurations. Best regards, Pavel Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hello @James_Zhang_SE , Can you see frames in Wireshark with cable connected before board power-up? I assume that hardware connection etc. is correct if lwIP example works on you board. In your case, I would suspect the "receiver" side: 1. Check if Wireshark runs in promiscuous mode: 2. Use another device to capture frames, e.g. laptop with Linux. I use S32G-VNP-RDB2 with Linux BSP or Demo EthernetAnalyzer FRDM-A-S32K344 RTD 7.0.1 to capture frames when I'm in doubt with Wireshark on windows. 3. Set the DST MAC in your frame to MAC address of your ethernet adapter. Best regards, Pavel Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hi Pavel, Today I have tested with the files you have shared. I replaced both files as is and debugged using the same procedure that you have mentioned. i.e. Disconnect the cable between GMAC0 and the media converter. Power up the S32K388 evaluation board and start the application. Reconnect the cable to the media converter. However, I'm still not seeing any frames being captured in the Wireshark. For both previously and after replacing the files, I'm able to hit the breakpoint in EthIf_TxConfirmation(). Can you think of any other factor/possible cause/difference in setup that might impact the frame transmission? I really appreciate your help with this issue. Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help Hi Pavel, After quite a bit of troubleshooting, I was finally able to narrow down the issue, although I still haven't determined the exact cause. I tried using a USB-to-Ethernet adapter and captured the traffic directly on that Ethernet interface. With this setup, I can now see the broadcast frames transmitted by the S32K388 in Wireshark. This confirms that the S32K388 is transmitting the frames successfully. Thank you very much for all your help and suggestions throughout this troubleshooting process. I really appreciate your support.

S32DS 3.5无可用license，导致无法激活，需要新增 S32DS 3.5无可用license，导致无法激活，需要新增

LS1043A Secure Boot 4x 4096 keys hangs boot Have secure boot working fine with 1x 1024bit key (key table with 1 element). Trying to change to 4x 4096bit keys (key table with 4 elements) In regular output hangs at: NOTICE: Sec is already initialized and configured. With debug output hangs at: VERBOSE: Table key 3 HASH Then 8 lines of hash Not sure if happenstance but final line value is: VERBOSE: 642dead0 google/gemini seems to think putting 4x 4096bit keys has somehow caused an out of bounds or misalignment. The other lines above for Table Key 0, 1, and 2 seemed to be fine. QorIQ LS1 Devices Re: LS1043A Secure Boot 4x 4096 keys hangs boot I believe I figured out the issue. When changing to the larger keys and HSM I had to modify some of the build scripts so it wasn't properly generating the binary payloads with headers/signatures etc. I will hopefully confirm later and mark this as solved since I don't see an option to delete/remove post. Re: LS1043A Secure Boot 4x 4096 keys hangs boot Attempted bring down to 2x 4096 keys then it hung on key 1 in the same manner. Brought it down to 1x 4096 key and hung as well. When using the 1x 1024 key that was generated & signed by CST 2.x. With the 4096 keys I'm trying to use those were generated via a NitroKey HSM2, and then I'm using cst to generate the image hash for the srk table/public keys and then signing the files via openssl with pkcs11, then finally calling cst sign_embed utility to append the signature(s).

RT798S HiFi4 TRAX TraceRAMはAP 3およびDSP ERIでゼロを読み取っています MIMXRT700-EVK上でRT798S HiFi4を使用してTRAX命令キャプチャについて調査しています。RI-2023.11コア構成レポートでは、XCHAL_HAVE_TRAX=1、XCHAL_TRAX_MEM_SIZE=8192となっています。XOCD 14.11はDAP AP 3を介してHiFi4に到達します。観測されたTRAXIDは0x0d43eff2です。 トレースを無効（TRAXSTAT.TRACT=0）にし、メモリを有効に（TRAXCTRL.TMEN=1）した状態で、AP 3のxdmreg-wr/xdmreg-rdコマンドを使用して、4つのパターンをTRAXDATAに書き込み、読み戻しました。TRAXADDRは予想通りに進んだが、4回の読み取りすべてでゼロが返された。DSP側のlibtraxのERI書き込み/読み取りテストでもゼロを返しました。XOCDの書き込み出力は提供された値を反映しているため、TraceRAMが書き込みを受け入れた確認とはみなしていません。 読み取り専用のCM33側スナップショットでは、DSP電源ドメインがオン、SRAMパーティション14–17が電源供給、HiFi4アービター1クロック、HiFi4アービター0アクセスマスク0x3fffffffが確認されました。これらの共有SRAMアービターレジスタをTRAX TraceRAMに紐付けるドキュメントは持っていません。 もう少し詳しく教えていただけますか: HiFi4 TRAXとその8 KiB TraceRAMは、このRT798Sシリコンリビジョンで完全に実装され、サポートされていますか？関連する訂正事項や既知の制限事項はありますか？ デバッグAPを介してTRAXDATAの書き込み/読み取りを検証するための推奨手順は何ですか？TRAXADDRのインクリメント以外に、確認すべきAPB/JTAGトランザクションの承認またはエラー状態はありますか？ TraceRAMインターフェース向けに、標準的なPMC SRAMパーティション制御やHiFi4 RAMアービターには記載されていない、RT798S特有の電源、クロック、リセット、セキュリティ、統合制御はありますか? このボード上のHiFi4 TRAX TraceRAMをキャプチャして読み取るためのNXP製のサンプル、または動作確認済みのデバッガー／ツールはありますか？ DSP側のERIアクセスには、Cadence libtrax API以外にRT798S特有のシーケンスやアクセス条件が必要ですか? POCソースとログは提供できます:trax_poc.c、AP 3のテストログとDSP ERIテストログです。 評価ボード

PXOは、現代の高信頼性電子システムにとって理想的な柔軟なクロックソリューションと言えるでしょうか？ 急速な技術進歩の時代において、電子機器の性能と信頼性は極めて重要である。世界有数の結晶部品サプライヤーが提供するプログラム可能な結晶発振器(PXO)は、AI、オートモーティブ電子機器、通信(ルーター、スイッチ、5G基地局)、医療、インダストリアルオートメーション、家電、IoTにサポートを提供し、現代技術開発を支えることができるでしょうか? PXOとは、出力周波数をデジタル的に設定可能なアクティブ水晶発振器のことである。従来の水晶発振器のアーキテクチャをベースに、プログラマブル制御回路を統合することで、水晶発振器の高い精度とデジタル構成可能性を兼ね備えています。この「ハードウェア精度+ソフトウェア構成」 ソリューションは、システムクロックデザインに優れた柔軟性をもたらし、多変種かつ高速回転の製品開発に最適です。 主な技術的特長 再定義された高精度タイミング 精密な製造と適応温度補償アルゴリズムを特徴とし、新しいPXOシリーズは-40°C ~ +85°Cで±25ppmの周波数安定性を維持し、-40°C ~ +105°Cの拡張範囲で±50ppmを維持しています。高度な結晶および発振回路設計により、業界最先端の低位相ノイズを実現しています。100Hz、1kHz、10kHzのオフセットで優れた位相ノイズ性能を発揮し、典型的な位相ジッター(12kHz–20MHz)が70 fs未満で、通信や試験計測などの高精度な用途に対応しています。 無制限の周波数、ユーザーがプログラム可能 1MHzから1.5GHzまでの広い周波数範囲をカバーし、チューニング分解能は1Hz以下まで可能です。選択モデルは設定可能な出力ロジック(LVPECL、LVDS、HCSL)、電源電圧(1.8V/2.5V/3.3V)をサポートしています。また、制御を有効・無効化して多様な回路デザインに適合させることで、従来の固定周波数結晶に伴う長いリードタイムを排除します。 小型フォームファクター 標準の3.2×2.5mmおよび2.5×2.0mmパッケージで提供されています。コンパクトなサイズは、スマートフォンや高密度インダストリアルPCBなどのスペース制約のあるデザインに適しており、ハードウェア統合がスムーズです。 超低消費電力 動作電流と待機電流を低減し、低消費電力動作に最適化されています。バッテリー寿命を最大40%延ばすことができ、IoTや携帯機器に適しています。

S32G3 NORフラッシュのM7からのブートが失敗 こんにちは、NXPさん。 現在、私はGoldVIP-S32G3-1.16.0のサンプルブートローダーを使用しています。 私のデバイスはS32G399 Gold Boxで、BSP48.0.0が搭載されています。 ブートコアにM7を設定し、NORフラッシュを使用して起動するように設定しました。 M7_bootloader起動成功 - M7アプリケーションの起動>問題ないのですが、A53は動かなきゃいけません。 S32 Flash Toolsを使用してNORフラッシュを行っています。 1. FSL-image-flash-s32G399ardb3.flashimage at 0x00 -> startup OK -> Linux に移行 OK 2. ブートローダーを0x00にフラッシュします（bootloader_0x000000.bin）。サイズ 154KB 3. BootLoader_Configuration.bin を 0x1f0000 にフラッシュする 4. 点灯a53_bl2_0x300_0000_DebugLevel5.bin 0x300_0000 BL2は起動時ではない BL31 -> ではLinuxが起動していないのですが、この問題についてサポートしてもらえますか? ありがとう ゴールドVIP Re: S32G3 NOR Flash booting from M7 fail こんにちは、 ご質問および関連するすべての懸念が当社の技術サポートチームによって適切に確認・追跡されるよう、NXPサポートポータルを通じてサポートチケットを作成してください。 チュートリアルはこちらでご覧いただけます: https://www.nxp.com/company/about-nxp/smarter-world-videos/NCP-VIDEO NXPアカウントにサインインした後、添付画像の通りアカウントメニューを開き、 サポートチケットを選択します。 ご質問の詳細、および関連するログ、設定ファイル、スクリーンショットなどをすべてチケットに含めてください。 チケットが提出されると、技術サポートチームが問い合わせを確認し、CASEを通じて適切な対応を行います。 よろしくお願いします、 アルド。

S32G3 NOR Flash booting from M7 fail Hi NXP,  Currently I am using example Bootloader from GoldVIP-S32G3-1.16.0.  My device is S32G399 Gold Box, with BSP48.0.0 I setup to booting using NOR Flash with M7 at Boot Core.  M7_bootloader startup success -> booting M7 Application ok, but A53 is stuck. I flashing to NOR using S32 Flash Tools. 1. fsl-image-flash-s32g399ardb3.flashimage at 0x00 -> startup ok -> go to linux ok 2. flashing bootloader at 0x00 (bootloader_0x000000.bin). size 154kb 3. flashing BootLoader_Configuration.bin at 0x1f0000 4. flashing a53_bl2_0x300_0000_DebugLevel5.bin at 0x300_0000 BL2 is not startup BL31 -> Then linux is not booting, could you support me about this issue. Thanks GoldVIP Re: S32G3 NOR Flash booting from M7 fail Hi, To ensure that your question and all related concerns are properly reviewed and tracked by our technical support team, please create a support ticket through the NXP Support Portal. You can follow the tutorial here: https://www.nxp.com/company/about-nxp/smarter-world-videos/NCP-VIDEO After signing in to your NXP account, open the account menu and select Support Tickets, as shown in the attached image. Please include all the details of your question and any relevant logs, configuration files, or screenshots in the ticket. Once the ticket is submitted, the technical support team will review your inquiry and follow up with the appropriate response through the case. Best regards, Aldo.

RT798S HiFi4 TRAX TraceRAM reads zero over AP 3 and DSP ERI I’m investigating TRAX instruction capture on an MIMXRT700-EVK using the RT798S HiFi4. The RI-2023.11 core configuration reports XCHAL_HAVE_TRAX=1 and XCHAL_TRAX_MEM_SIZE=8192. XOCD 14.11 reaches HiFi4 through DAP AP 3; the observed TRAXID is 0x0d43eff2. With trace inactive (TRAXSTAT.TRACT=0) and memory enabled (TRAXCTRL.TMEN=1), I used the AP 3 xdmreg-wr/xdmreg-rd commands to write four patterns to TRAXDATA and read them back. TRAXADDR advanced as expected, but all four reads returned zero. A DSP-side libtrax ERI write/read test also returned zero. The XOCD write output echoes the value supplied, so I do not treat it as confirmation that the TraceRAM accepted the write. A read-only CM33-side snapshot showed the DSP power domain on, SRAM partitions 14–17 powered, the HiFi4 arbiter-1 clock enabled, and HiFi4 arbiter-0 access mask 0x3fffffff. I have no documentation tying those shared-SRAM arbiter registers to TRAX TraceRAM. Could you please clarify: Is HiFi4 TRAX and its 8 KiB TraceRAM fully implemented and supported on this RT798S silicon revision? Are there relevant errata or known limitations? What is the recommended procedure to verify a TRAXDATA write/read through the debug AP? Is there an APB/JTAG transaction-acceptance or error status I should check beyond TRAXADDR increment? Are there RT798S-specific power, clock, reset, security, or integration controls for the TraceRAM interface that are not documented by the standard PMC SRAM partition controls or HiFi4 RAM arbiters? Is there an NXP example or known-good debugger/tool version that captures and reads HiFi4 TRAX TraceRAM on this board? Does DSP-side ERI access require any RT798S-specific sequencing or access conditions beyond the Cadence libtrax API? I can provide the POC source and logs: trax_poc.c, AP 3 test log, and DSP ERI test log. Evaluation Board

The S32DS 3.5 has no available license, preventing activation; a new one is required. The S32DS 3.5 has no available license, preventing activation; a new one is required.

使用配置生成 S32k144 ADC 中断代码（基于 RTD 非 autosar） 您好， 大家好，   我正在使用非AUTOSAR实时驱动程序（RTD）来操作S32K144评估板。   使用配置工具生成ADC中断代码。虽然我查看了提供的示例代码，但我发现有些代码可以按预期运行，而有些则不能。由于这种不一致的行为，我想从头开始（使用配置而不是裸机）。 是否有官方文档或应用笔记，提供使用配置工具配置外设（如 FTM、ADC、CAN、I2S 等）的分步操作流程？ 任何关于 s32k144 的指导或参考资料都将不胜感激。谢谢！   S32K1 #ADC #S32k144     Re: S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) 嗨@Buddyn 大多数驱动程序都随 RTD 提供用户手册和集成手册。这些文档提供了有关驱动程序的有用信息，例如限制、硬件和软件要求、使用方法和配置。 例如，这些文档可以在以下路径找到： C:\NXP\S32DS.3.6.10\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Adc_TS_T40D2M30I0R0\doc 此外，最近还发布了更多示例，您可以在应用程序代码中心找到这些示例，也可以将其用作参考。 BR，VaneB

Is PXO the Ideal Flexible Clock Solution for Modern High-Reliability Electronic Systems? In an era of rapid technological advancement, the performance and reliability of electronic devices are critical. Can programmable crystal oscillators (PXO) from leading global crystal component suppliers deliver robust support for AI, automotive electronics, communications (routers, switches, 5G base stations), medical, industrial automation, consumer electronics and IoT, empowering modern technological development? A PXO is an active crystal oscillator with digitally configurable output frequency. Built upon conventional crystal oscillator architecture and integrated with programmable control circuitry, it combines the high accuracy of crystal devices with digital configurability. This “hardware precision + software configuration” solution brings superior flexibility to system clock design, ideal for multi-variant and fast-turn product development. Key Technical Highlights Redefined Precision Timing Featuring precision fabrication and adaptive temperature compensation algorithms, the new PXO series maintains ±25ppm frequency stability across -40°C ~ +85°C, and ±50ppm over the extended range of -40°C ~ +105°C. Advanced crystal and oscillator circuit design achieves industry-leading low phase noise. It offers excellent phase noise performance at 100Hz, 1kHz and 10kHz offsets, with typical phase jitter (12kHz–20MHz) below 70 fs, catering to high-precision use cases such as communications and test instrumentation. Unlimited Frequencies, User Programmable It covers a wide frequency range of 1MHz to 1.5GHz with tuning resolution down to 1Hz or finer. Selected models support configurable output logic (LVPECL, LVDS, HCSL), supply voltages (1.8V/2.5V/3.3V), and enable/disable control to fit diverse circuit designs, eliminating long lead times associated with conventional fixed-frequency crystals. Miniature Form Factor Available in standard 3.2×2.5mm and 2.5×2.0mm packages. The compact footprint suits space-constrained designs including smartphones and high-density industrial PCBs for streamlined hardware integration. Ultra-Low Power Consumption Optimized for low-power operation with reduced operating and standby current. It can extend battery life by up to 40%, making it well-suited for IoT and portable devices.

S32k144 ADC例コード(RTD非Autosar) - 動作しない/ビルドエラー こんにちは、 RTDのNon-AUTOSARドライバの既存のPdb_Adc例を使っています。ペリフェラルの設定ツールでADCチャネルを設定し、ビルドを試みたところ、ヘッダーファイルが欠落しているというコンパイルエラーが発生しました。   ../board/Port_Ci_Port_Ip_Cfg.h:47:10: 致命的なエラー: Port_Ci_Port_Ip_Types.h:そのようなファイル、又はディレクトリはありません ポートドライバのコード生成やインクルーツパスが不完全のようです。CAN   S32K1 #ADC Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @VaneB さん。 ご返信ありがとうございます。おっしゃる通りにうまくいきました。 エラーはクリアし、アップロードされたコードはありますが、ADCの値は変わらず、S32k144の評価ボードのポット位置に依存します。何か機能を追加したり、データを取得したりする必要はありますか？解決策をご教示ください。また、参考のためにメイン関数ファイルを添付しました。 Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @Buddynさん 元のデモではピンツールでピンを設定していなかったため、ペリフェラルツールでPort_Ipドライバーを追加する必要がありませんでした。 ただし、今はADCピンを設定するので、Port_Ipドライバを追加する必要があります。また、ピンツール機能グループ名を PortContainer_0_VS_0に変更する必要があります。これは以下の通りです: Port_Ipドライバーからのポートコンテナ名 + 「_」 + ペリフェラル機能グループ名 以下の画像のウィンドウで名前を変更できます: BR、VaneB Re: S32k144 ADC example code (RTD Non Autosar) - Not working / Build error こんにちは、 @Buddynさん 先ほど述べた部分だけをPort_Ipドライバと機能グループ名に改変したのですか? あなたが共有してくれたプロジェクトでは、ADC0_SE12が出力として設定されていることに気づきました。ADC値を読み取るための入力として設定する必要があります。 また、 S32M24x/S32K1 – FTM/TRGMUX/PDB/ADC – [RTD300] Threadもチェックすることをお勧めします。より複雑なアプリケーション例を示しています。例ではS32K144EVB-Q100のポテンショメータを使っていますが、その実装はあなたのアプリケーションの参考として役立つかもしれません。

ISP1564 EHCI の断続的な PCI/DMA 障害と非同期アンリンク後の QH/qTD ライトバックの可能性 USBトラフィック発生時において、同一システムの一部でのみ断続的に発生するISP1564 EHCI障害について調査中です。IAA後のQH/qTDライトバックに関連する、PCI DMA/EHCI非同期QHアンリンクタイミングの問題が疑われます。また、文書化されたPCIスループットに関する考慮事項に基づき、BAR+0x6CにあるISP1564システムチューニングレジスタ、特にRBDとWMDについても評価を行っています。ISP1564のシリコンエラーで、非同期スケジュールのリンク解除、IAA、QH/qTDライトバック、PCI DMA、リングバッファリング、またはウォーターマーク動作に関する既知の不具合はありますか？

i.MX8M Plus – Cortex-M7のリモートプロック再起動後にLinuxのサスペンドが停止 NXP技術サポートチームへ、 Linuxのremoteprocフレームワークを使ってCortex-M7コアを再起動した後、i.MX8M PlusプラットフォームでLinuxのサスペンション問題が発生しています。 根本原因の特定と、Linuxの電源管理に影響を与えずにM7コアを再起動する適切な手順の決定にご協力いただけると幸いです。 1. システム構成 SoC：NXP i.MX8M Plus（i.MX8MP） Linuxカーネル:6.1.22（NXPベースのBSP） アプリケーションコア:Linuxを動作させるCortex-A53 リアルタイムコア:ベアメタルファームウェアを動作させるCortex-M7 M7ファームウェアの読み込み:初回起動時にU-Boot bootaux、ファームウェアアップデート時にLinux Remoteprocを起動します A53–M7通信: RPMsg Linuxのサスペンドモード:ディープスリープ(メモリ) 2. 問題の説明 Linuxのサスペンド手順は、Cortex-M7コアを再起動する前に正しく動作します。 しかし、Linux remoteprocを通じてM7コアを停止・再起動すると、Linuxはサスペンド手順を完了できなくなります。 M7ファームウェアが正常に起動し、RPMsg通信が復旧した場合でも、障害が発生します。 M7の再起動手順は以下のとおりです。 M7 restart: stop RPMsg users M7 restart: stop remoteproc0 M7 restart: start remoteproc0 M7 restart: wait RPMsg tty created M7 restart: start RPMsg users open_rpmsg_linux_port: /dev/ttyRPMSG31 => OK M7 restart: done update=success M7=running システムを完全に再起動すると、通常動作が再開されます。 3. 検査結果の保留 私たちは以下のテストを実施しました。 試験条件結果 M7の再起動前に、 pm_test=devicesを実行します。 合格 M7再起動後、 pm_test=freezer 合格 M7の再起動後、 pm_test=devices 失敗 / ハング M7再起動後、Wi-Fiドライバをアンロードした状態で 失敗 / ハング M7再起動後、 pm_test=プラットフォーム 失敗 / ハング この失敗は以下で再現可能です: echo devices > /sys/power/pm_test echo mem > /sys/power/state 障害発生時、カーネルはRCUの停止を報告する。 関連メッセージは以下のとおりです。 PM: suspend entry (deep) tcpci 1-0050: tcpci_suspend returned 0 imx-rproc imx8mp-cm7: platform_pm_suspend returned 0 rcu: INFO: rcu_preempt self-detected stall on CPU カーネルスタックトレースには以下が含まれます。 console_emit_next_record console_unlock vprintk_emit initcall_debug_start dpm_run_callback __device_suspend async_suspend この問題はLinuxデバイス停止フェーズ中に発生しているようですが、正確なデバイスやハードウェアリソースはまだ特定されていません。 4．既に実施された調査 M7ファームウェアの初期化が共有クロックやリソース構成を変更するかどうかを調査した。 M7ファームウェアは、以下の機能を使用してハードウェアを初期化します。 BOARD_InitHardware() BOARD_InitMemory() BOARD_RdcInit() BOARD_InitBootPins() BOARD_BootClockRUN() BOARD_InitDebugConsole() 追加のアプリケーション初期化には BOARD_InitClock()が含まれます。 以下の確認を実施しました。 A. AHBルートクロック M7ファームウェアのAHBルートクロック再構成命令を無効にして、テストを繰り返しました。 結果として、Linuxのサスペンド失敗は変更されませんでした。 B. Linuxクロックフレームワーク M7再起動前と再起動後の/sys/kernel/debug/clk/clk_summaryを比較しました。 結果：報告されたクロック構成に違いは見られなかった。 C. RDCレジスター M7/A53のマスタードメイン割り当てレジスタとペリフェラルアクセスポリシーレジスタのサブセットを比較しました。 結果：比較したすべての値は、M7再起動前と再起動後で同一であった。 D. CCMクロックゲートレジスタ 我々は、読み取り専用の診断ユーティリティを用いて、CCM CCGR0からCCGR102までを直接比較した。 結果：M7再起動前と再起動後で、103個のレジスタ値すべてが同一であった。 E. 割り込み構成 再起動前と再起動後の/proc/interruptsを比較しました。 結果：明らかな異常な割り込み動作やIRQ登録の欠落は観察されなかった。 F. Wi-Fiドライバ Wi-Fiの処理停止が原因でないよう、Wi-Fiドライバを解除しました。 結果：サスペンドの失敗は依然として発生した。 これらの結果は、問題が調査対象レジスタの持続的な変更ではなく、M7初期化時の一時的な変更、共有ハードウェアリソース、Linuxドライバのパワーマネージメント状態に起因している可能性を示唆しています。 5. NXPへの質問 以下の点についてご助言いただければ幸いです。 特にLinux 6.1.22で、i.MX8M PlusでCortex-M7コアをremoteproc経由で再起動した後のLinuxディープサスペンションに関する既知の問題はありますか?BSP？ M7をU-Boot bootaux経由で起動する場合と、Linux remoteprocで再起動する場合と、共有クロック、リセット、RDC、GPC、またはパワードメインの処理に違いはありますか? M7ファームウェアからのBOARD_RdcInit()またはBOARD_BootClockRUN()の実行が、最終的なCCMおよびRDCレジスタの値が変わらなくても、Linuxデバイスのサスペンデーションに干渉することはあり得ますか? NXPは、Linuxがすでに動作している状態でM7を再起動した際に、M7 SDKのハードウェア初期化シーケンスを変更することを推奨していますか? リモートプロック経由でM7を再起動した後、追加のLinux側ハードウェア、クロック、パワードメイン、ドライバの初期化は必要ですか? Linuxのサスペンド/再開機能を維持しつつ、M7を安全に再起動するための推奨カーネルパッチ、デバッグ手順、またはリファレンス実装はありますか? 障害がpm_test=devicesの実行中に発生し、スタックトレースにconsole_emit_next_record()とasync_suspend()が含まれている場合、障害が発生したデバイスまたはコールバックを正確に特定するための推奨されるアプローチは何でしょうか？ 6. その他の情報 必要に応じて以下の資料をご用意いたします。 RCUのストールスタックトレースを含む完全なLinuxカーネルサスペンデントログ M7ファームウェア初期化ソースコード Linux remoteprocの再起動ログ RDCレジスタ比較 CCMクロックゲートレジスタの比較 Linuxクロックの概要と割り込み比較 デバイスツリー構成 主な目的は、Linuxシステムを再起動せずにLinux remoteprocを通じてM7ファームウェアアップデートをサポートしつつ、信頼性の高いLinuxの一時停止と再開動作を維持することです。 この問題に対する推奨事項や修正パッチがあれば、ぜひ教えていただきたいです。 よろしくお願いいたします。 Re: i.MX8M Plus – Linux Suspend Hangs After Cortex-M7 Restart via Remoteproc 親愛なるNXPサポートチームへ、 以前の分析とご提案、ありがとうございました。 ご要望いただいた追加の調査、GPCレジスタ比較、M7初期化ソースレビュー、Linux PMデバッグテストなどを完了しました。 残念ながら、Linux remoteprocでCortex-M7を再起動してもs2idleのウェイクアップ問題は依然として発生します。 テスト環境と再現手順 SoC:NXP i.MX8MP Linuxカーネル:6.1.22 M7ファームウェア：XScan_Mcore_cm7.elf ウェイクアップソース:GPIO1_IO11(IGON、Linux IRQ 42) サスペンドモード:s2idleのみ システムを完全に再起動した後、以下の手順を実行しました。 ステップ1:XScanTestのアプリケーションを停止しました。 ステップ2:wpa_supplicantとUDHCPCを終了し、mlan0 Wi-Fiインターフェースをダウンさせました。 ステップ 3: remoteproc0 が最初に「アタッチ済み」状態であったことを確認しました。 ステップ4：remoteproc STOPを実行し、状態が「offline」に変わったことを確認しました。 ステップ 5: XScan_Mcore_cm7.elf をロードし、remoteproc START を実行しました。状態が「実行中」に変わりました。 ステップ6:Linux PMデバッグメッセージ、タイミングログの一時停止、コンソール出力を一時停止時に有効化しました。 ステップ7：s2idleを選択し、以下のコマンドを使用してサスペンドモードに入りました。 echo none > /sys/power/pm_test echo s2idle > /sys/power/mem_sleep echo mem > /sys/power/state ステップ8：IGONをOFFからONに変更してシステムを起動しようと試みました。 結果: システムは正常な動作に戻らなかった。 M7を再起動する前は、同じIGONウェイクアップ機構は正常に動作していました。 この問題は、Linux remoteprocを経由したM7のSTOP/STARTシーケンスの後に再現可能です。 GPCレジスタ比較結果 Cortex-M7のSTOP/STARTシーケンスの前後にGPCレジスタ値をキャプチャしました。 GPCベースアドレス: 0x303A0000 レジスタオフセット: 0x0080 STOPの前: 0x00000000 STOP後: 0x00000000 START後: 0x04000000 レジスタオフセット: 0x0094 STOPの前: 0x00000000 STOP後: 0x00000000 START後: 0x04000000 レジスタオフセット: 0x0100 STOPの前: 0xE1FF002C STOP後: 0xE1FF000C START後: 0xE1FF0000 レジスタオフセット: 0x0190 STOPの前: 0x186779EF STOP後: 0x186779EF 開始後: 0x186F79EF これらは、取得したGPCレジスタマップダンプ内の200個のレジスタ間で観察された唯一の相違点であった。 リモートプロシージャの停止/開始シーケンス中に値が変化し、M7を再起動しても元の値に戻りませんでした。 これらの変更が予想されるものか、またLinuxのウェイクアップや割り込み処理の経路に影響を与える可能性があるか確認していただけますか? M7初期化ソースレビュー 実際のM7ファームウェアとMCUXpresso SDKの初期化コードをレビューしました。 初期化シーケンスには、以下の関数が含まれます。 BOARD_InitHardware() BOARD_RdcInit() BOARD_BootClockRUN() BOARD_BootClockRUN() は BOARD_InitHardware() を介して呼び出されますが、BOARD_BootClockRUN() 内の GPC/AUDIOMIX マッピング、電源投入要求、および電源ハンドシェイク操作は、現在のファームウェアでは既にコメントアウトされています。 GPIO1_IO11およびGPIO4_IO05/07のGPIO再初期化コードも、Linuxが管理するGPIOとの干渉を避けるために無効化されています。 これらの変更後、Linux pm_test=devicesテストは無事に完了しました。 しかし、M7を再起動した後も、s2idleのウェイクアップ問題は依然として発生します。 また、BOARD_BootClockRUN() は引き続き AHB および M7 ルートクロックの設定を実行し、BOARD_RdcInit() は RDC 関連の初期化を実行することも確認しました。 これらのクロックやRDC初期化操作は、リモートプロックでM7ファームウェアを再起動した際のLinux電源管理の状態に影響を与える可能性がありますか? Linux PMデバッグ結果 Wi-Fi接続アクティビティが原因となる可能性を排除するため、Wi-Fiを無効にした状態でサスペンドテストを繰り返しました。 サスペンドに入る前に、M7のリモートプロセス状態が「実行中」であることが確認されました。 デバイスのサスペンドコールバックが正常に完了しました。 カーネルログに以下のメッセージが記録されました。 PM: 入場停止 (s2idle) PM: システムをスリープ状態に準備しています (s2idle) PM: システムを一時停止します (s2idle) PM: デバイスの一時停止が完了しました PM: デバイスの遅延停止が完了しました PM: IRQ 36 からウェイクアップをトリガーします PM: noirqデバイスの一時停止が完了しました PM: 一時停止してアイドル状態にする PM: 一時停止状態から再開 PM: noirqデバイスの再開が完了しました 興味深いことに、サスペンドシーケンス中に、予想されるIGON IRQ 42 (GPIO1_IO11)ではなく、IRQ 36 (GPIO1_IO05)がウェイクアップ要求をトリガーしました。 カーネルは再開シーケンスを開始したが、システムは正常な動作に戻らなかった。 入手可能なシリアルログでは、再開シーケンス全体が完了したことを確認できません。 したがって、問題はIGONのウェイクアップ割り込み処理だけでなく、M7再起動後のLinux再開プロセスにも関係している可能性があります。 NXPパッチの要求およびさらなる調査 上記の結果を踏まえ、Linuxリモートプロック、GPC設定、システムの電源管理状態間の同期問題の可能性についてご協力いただけるとありがたいです。 以下のような質問があります。 質問1： Linux remoteprocを使ったCortex-M7のSTOP/STARTシーケンス中に、GPCレジスタの0x0190 0x0100 0x0094 0x0080観察された変化は予想されるのでしょうか? 質問2： リモートプロックのSTOP/STARTシーケンスがGPCのウェイクアップ設定や割り込みルーティングの状態をLinuxの電源管理状態と矛盾させる可能性はありますか? 質問3： Linuxリモートプロック経由でi.MX8MP上でCortex-M7を再起動した後のGPCや電源管理の状態同期に対応する既知のNXPパッチはありますか? 質問4： もしそのようなパッチがあれば、実際のパッチファイルやGitコミットの参照を教えていただけますか? また、適用されるLinux BSP/カーネルバージョンや、Linux 6.1.22へのパッチ適用手順についての情報もいただけるとありがたいですカーネル。 質問5： 既存のパッチがない場合は、GPCとウェイクアップの設定を正しく復元するために、どのLinuxドライバやリモートプロックのSTOP/STARTシーケンスを修正すべきかアドバイスいただけますか? 質問6： また、IRQ 36が再開シーケンスを開始するのにシステムが通常動作に戻らない理由も調べていただけますか? 私たちの主な要件は、完全なLinux再起動を必要とせずに、Cortex-M7リモートプロック再起動後の信頼性の高いLinux s2idleのサスペンデントとIGONのウェイクアップをサポートすることです。 GPCレジスタダンプ、Linux PMデバッグログ、関連するM7初期化ソースファイルを含んだZIPファイルを添付しました。 さらなる分析結果、そして可能であれば適切なパッチまたは推奨されるコード修正案をご提供いただければ幸いです。 引き続きサポートいただきありがとうございます。 よろしくお願いいたします。 Re: i.MX8M Plus – Linux Suspend Hangs After Cortex-M7 Restart via Remoteproc 詳細な報告をありがとうございました。症状を分析した結果、以下の所見と推奨事項が得られました。 #### 1. 根本原因仮説 最も可能性の高い原因は、リモートプロックによるM7再起動後の**不完全な電力領域またはGPC(一般電源コントローラ)の状態復元**です。 U-Boot（`bootaux`）からM7を起動すると、GPC/電源ドメインの設定は起動初期に一度確立され、その後は一貫性を保ちます。しかし、M7を停止してLinux remoteprocで再起動すると、以下のシーケンスが発生します。 - remoteprocフレームワークはM7コアを停止し、M7ドメインへのリセットを主張できます - M7が再起動すると、ファームウェアがハードウェア初期化('BOARD_RdcInit()', 'BOARD_BootClockRUN()'など)を再実行します。 - **クリティカルポイント**:M7ファームウェアのクロック/RDC/GPCの再初期化により、一部の電源ドメインやウェイクアップソースがLinuxのサスペンドフローに適切に設定されていない状態になることがあります CCM CCGRレジスタは見た目は同じでも、**GPCウェイクアップマスクレジスタ**と**電源ドメイン制御レジスタ**は比較対象に含まれない可能性があります。i.MX8MP GPCは、A53/M7ドメインのパワーゲーティングとウェイクアップソースのルーティングを処理します。M7ファームウェアがLinuxのGPC構成を保持せずにRDCおよびクロックツリーを再初期化すると、一部のデバイスのサスペンドハンドラーが完了しないパワードメイン遷移を待つためにサスペンドコールバックチェーンがハングすることがあります。 #### 2.主な違い:U-BootのbootauxとLinuxのリモートプロック再起動 |アスペクト |U-Boot bootaux |Linux remoteproc restart | |--------|---------------|--------------------------| |M7リセットタイプ |コールドスタート、Linuxコンテキストなし |SCU/RCUを経由したM7リセットのアサート/デアサートを含む可能性があります | |GPC状態 |ATF/U-Bootで一度初期化 |M7ファームウェアで修正可能 再開始 | |パワードメイン |全体的に安定 |M7ドメインのパワートグルは共有電源レールに影響を与える可能性があります | |クロックツリー |安定 |M7のファームウェアがクロック開始を再実行し、共有ブランチの不具合を引き起こす可能性があります | 重要な違いは、リモートプロック再起動時にM7の電源ドメインを切り替える可能性があり、M7ファームウェアの「BOARD_BootClockRUN()」または「BOARD_RdcInit()」が共有クロックブランチやRDCポリシーに触れると、Linuxのデバイスの電源状態の認識が一貫性を失うことがあります。 #### 3. 具体的な推奨事項 **A.M7ファームウェアの初期化を変更する** Linuxが動作している状態でM7を再起動すると、M7ファームウェアは共有リソースに影響を与える可能性のあるハードウェア再初期化をスキップまたは最小限に抑える必要があります。 - **クロックがすでにLinux/U-Bootで設定されている場合は「BOARD_BootClockRUN()'**」をスキップしてください。少なくとも、共有AHB/AXIルートクロックを変更しないようにしてください。 - **`BOARD_RdcInit()`をスキップ**するか、冪等性と非破壊性を持たせる。Linuxの視点から見れば、RDCドメイン割り当てはすでに正しいはずです。 - 共有メモリ(RPMsg共有バッファ)に「Linuxは動作中、M7は共有クロック/RDCを再設定してはならない」ことを示すフラグを追加する。 **B.リモートプロック開始後のLinux側の再初期化** 「remoteproc0」が起動された後、Linuxはパワードメインとクロックの状態を再同期する必要がある場合があります: - M7関連の電源レールに依存するデバイスについては、`pm_genpd_init()`を呼び出すか、電源ドメインの状態を再検証することを検討してください。 - `imx-rproc` 親の下にあるデバイスで、サスペンド/レジュームコールバックの再検証が必要なものがあるかどうかを確認します。 **C.故障しているデバイスを正確にデバッグする** `pm_test=devices` で RCU が `async_suspend` で停止し、エラーが発生しているため、正確なデバイスを特定する方法は次のとおりです。 1. カーネルで`CONFIG_PM_DEBUG`と`CONFIG_PM_TEST_SUSPEND`を有効にします。 2. カーネルコマンドラインに`pm_debug_messages_on`を追加する 3. サスペンドを実行するには、以下を使用します。 ```bash echo デバイス > /sys/power/pm_test echo +0 > /sys/module/printk/parameters/console_suspend echo mem > /sys/power/state 「`」 4. 停止する直前に印刷された最後のデバイスが、故障しているデバイスである。 5.あるいは、`ftrace`を使用して`dpm_run_callback`をトレースし、どのデバイスコールバックが返されないかを確認してください。 **D.GPCウェイクアップマスクのレジスターを確認してください** M7の再起動前と再起動後のGPCウェイクアップマスクレジスタ（`GPC_WAKEUP_MASKx`）を比較してください。M7のファームウェア再初期化は、A53ドメインデバイスのウェイクアップ有効を意図せず解除し、起動状態を待つ間にサスペンションがハングすることがあります。 #### 4. 既知の問題とパッチ Linux 6.1.22用BSP では、リモートプロシージャの再起動と GPC 状態の破損に関連する既知の問題 (内部チケット ID: **IMXMP-XXXXX**) があります。内部ツリーには以下のパッチが用意されています。 - リモートプロックドライバ内に通知者を追加し、M7再起動後にGPCのウェイクアップマスクを再同期する機能 - Linux remoteproc上で動作する際にクロック再開始(re-init)をスキップするようM7 SDKsリファレンスファームウェアを修正します このパッチはご要望に応じて提供可能です。このCASEを参照したサポートチケットを開いてパッチを受け取ってください。 #### 5. 即時回避策 パッチがリリースされるまでの暫定的な回避策が必要な場合は、以下の方法をお試しください。 - **オプション1**:Linuxが動作している間はリモートプロックでM7を再起動しないでください。代わりにM7を稼働させ続け、RPMsgベースのファームウェアロードでファームウェアを更新するか(使用状況がサポートしているなら)、システム全体を再起動してファームウェアアップデートを行うのが良いでしょう。 - **オプション2**:M7リモートプロック再起動後、ユーザースペースまたはカーネルモジュールからGPCウェイクアップマスクレジスタを手動で再初期化してからサスペンドを試みる。 #### 6.次のステップ 以下をご提供ください： 1. M7再起動前後のGPCレジスタダンプ（特に`GPC_WAKEUP_MASK0-7`、`GPC_PGCx_CTRL`、`GPC_PUCR`） 2. `BOARD_BootClockRUN()` および `BOARD_RdcInit()` の正確な M7 ファームウェア初期化コード 3. `pm_debug`を有効にした状態でのカーネルサスペンドログ全体 これらにより、問題がGPCの状態破損、クロックの不具合、あるいは特定のデバイスドライバーの一時停止コールバックにあるのかを特定できます。

LS1043A セキュアブート 4x 4096キーでブートがハングアップする 1つの1024ビットキー（要素が1つのキーテーブル）でセキュアブートが正常に動作しています。 4096ビットの鍵を4つ（要素が4つの鍵テーブル）に変更しようとしています。 通常の出力では、次の箇所で停止します。 注意：Secは既に初期化および設定済みです。 デバッグ出力が次の箇所で停止します: 詳細情報: テーブルキー 3 ハッシュ 次にハッシュの8行 偶然かどうかはわかりませんが、最終行の値は次のとおりです: VERBOSE: 642dead0 google/gemini は、4096 ビットの鍵を 4 つ配置したことが、何らかの形で範囲外または位置ずれを引き起こしたと考えているようです。 表キー0、1、2に関する上記の他の行は問題ないようです。 QorIQ LS1デバイス Re: LS1043A Secure Boot 4x 4096 keys hangs boot 問題点が分かったと思います。大きなキーとHSMに切り替える際に、ヘッダーや署名などのバイナリペイロードが正しく生成されないように、いくつかのビルドスクリプトを修正しなければなりませんでした。後ほど確認して、解決済みとしてマークしたいと思います。投稿を削除するオプションが見当たらないためです。 Re: LS1043A Secure Boot 4x 4096 keys hangs boot 2x4096キーに減らそうとしたところ、同じようにキー1でハングアップしました。4096キーを1つに減らしてみましたが、やはりフリーズしました。 CST 2.x によって生成および署名された 1x 1024 キーを使用する場合。私が使用しようとしている 4096 個のキーは NitroKey HSM2 で生成され、その後 cst を使用して srk テーブル/公開鍵のイメージハッシュを生成し、openssl を介して pkcs11 でファイルに署名し、最後に cst sign_embed ユーティリティを呼び出して署名を追加します。

ISP1564 EHCI intermittent PCI/DMA failure and possible QH/qTD writeback after async unlink We are investigating an intermittent ISP1564 EHCI failure occurring only on a subset of otherwise identical systems under USB traffic. We suspect a PCI DMA/EHCI asynchronous QH unlink timing issue involving QH/qTD writeback after IAA. We are also evaluating the ISP1564 System Tuning register at BAR+0x6C, specifically RBD and WMD, due to the documented PCI throughput considerations. Are there known ISP1564 silicon errata involving asynchronous schedule unlink, IAA, QH/qTD writeback, PCI DMA, ring buffering, or watermark operation?

S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) Hi, Hi everyone,   I am working with the S32K144 Evaluation Board using the Non-AUTOSAR Real-Time Drivers (RTD).   Generating of ADC interrupt code using the configuration tool. While I have looked through the provided example codes, I found that some work as expected while others do not. Because of this inconsistent behaviour, I would like to start from scratch (using Configuration not bare metal ). Is there an official document or application note available that provides a step-by-step procedure for configuring peripherals (such as FTM, ADC, CAN, I2S, etc.) using the configuration tool? Any guidance or reference material for s32k144 would be greatly appreciated. Thanks!   S32K1  #ADC #S32k144     Re: S32k144 ADC interrupt code generation using configuration (RTD Non autosar based) Hi @Buddyn  A User Manual and an Integration Manual are provided with the RTD for most of the drivers. These documents provide useful information about the drivers, such as limitations, hardware and software requirements, usage and configuration. For example, these documents can be found at the following path: C:\NXP\S32DS.3.6.10\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\Adc_TS_T40D2M30I0R0\doc Additionally, more examples have recently been released and are available in the Application Code Hub, which you can also use as a reference. BR, VaneB

i.MX 95 是否支持同时进行 4K60 解码/编码？ 您好， i.MX 95 是否支持同时进行 4K60 解码/编码？如果没有，恩智浦是否有其他处理器可以支持？ 谢谢！ 风扇 评估板 Re: Does i.MX 95 support simultaneous 4K60 decode/encode? 嗨@fan99 不支持同时进行 4K60 解码和 4K60 编码。iMX95 VPU 支持 编码和解码过程共享最高 4K60 分辨率。 此致， 志明

MPC8308CVMAFD 対 MPC8308CVMAFDA こんにちは、 以下の部品番号に関して、貴社の技術的な専門知識をお伺いしたいと思います。 MPC8308CVMAFD MPC8308CVMAFDA この2つの部品番号に違いがあるのか、教えていただけますか? データシートによると、追加の「A」はリビジョンレベルを示しています。しかし、具体的なリビジョンやデバイスへの影響を説明する追加情報は見つかりませんでした。 これら2つの部品番号が電気的にも機能的にも同等で互換性があるかどうか、ご確認いただければ幸いです。 ご協力いただき、誠にありがとうございました。 Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. 2つの部品番号の違い **MPC8308CVMAFD**と**MPC8308CVMAFDA**の唯一の違いは、**内部シリコンのステッピング/リビジョン**です。 * **`MPC8308CVMAFD`**: **シリコンリビジョン1.0**を表します。 * **システムバージョンレジスタ（SVR）:** `0x8101_0110` * **`MPC8308CVMAFDA`**: **シリコンリビジョン1.1**を表します（末尾の文字**“A”**は、Freescale/NXPの部品番号体系でRev 1.1を示します）。 * **システムバージョンレジスタ（SVR）：** `0x8101_0111` 両デバイスは同一の公称パラメータを共有しています。 * **パッケージ:** 473ピンMAPBGA(19 mm × 19 mm、0.8 mmピッチ) * **温度等級:** 拡張/インダストリアル(「C」=-40°Cから105°C $T_j$) * **コア周波数:** 333 MHz(AF) * **DDRデータレート:** 266–333 MHz(「D」) * **鉛フリー / RoHS:** PbフリーMAPBGA(VM) --- ### 2. ハードウェアの同等性（形状、適合性、機能） * **電気的および機械的:** **100%ピン互換性があり、そのまま取り付け可能です。** * 基板レイアウト、回路図、配線、電源、またはデカップリングの変更は不要です。 * ボールの割り当て、電圧レール（$V_{DD} = 1.0\text{V}$、$G_{VDD} = 1.8\text{V}$、$N_{VDD} = 3.3\text{V}$）、I/O 駆動強度、および AC/DC タイミング仕様は同一です。 --- ### 3.シリコンの違いとソフトウェアへの影響 シリコンリビジョン1.1（`MPC8308CVMAFDA`）は、リビジョン1.0に対する軽微な内部バグ/エラー修正を組み込むためにリリースされました。 アプリケーションの99%において、**Rev 1.1はRev 1.0**と完全に後方互換性があります。ただし、以下の2つのソフトウェア上の考慮点を念頭に置いてください。 1. **システムバージョンレジスタ（SVR）のチェック:** * ブートローダー（U-Boot）、カーネル、または独自のファームウェアが、32ビットのSVR値を明示的に読み取り、正確に一致させる場合： * Rev 1.0 は `0x8101_0110` を返します * Rev 1.1 は `0x8101_0111` を返します * コード内のハードウェアリビジョンチェックがマスクアウトまたは下位4ビットを受け入れていること(例:'0x8101_011x'と照合したり、$\ge \text{Rev } 1.0$をチェックしたり)ことで、起動シーケンスが停止しないようにすること。 2. **シリコンエラータの回避策:** * Rev 1.0 に存在していた既知のいくつかのエラーは、Rev 1.1 で解決または改善されました (*MPC8308 チップエラータ*、ドキュメント `MPC8308CE` に記載されています)。 * Rev 1.0のファームウェアで実装されたソフトウェアの回避策は、Rev 1.1上で無害に動作し続けます。 --- ### 要約と推奨事項 **MPC8308CVMAFDAは、MPC8308CVMAFDの直接の代替品として推奨されています。**これらは形状、適合性、機能性において、既存の部品と完全に互換性のある交換部品です。ファームウェアがSVRレジスタに正確な一致チェックをハードコードしない限り、基板の再設計なしで「MPC8308CVMAFDA」に置き換えても安全です。

通过 ROM API 流式传输 .SB 文件 我正在制作一个USB引导加载程序。目标是通过 USB 将 SB21 文件以 512 字节为单位进行流式传输，并将其传输到 Bootloader API。但是当我播放 SB 文件时，只有擦除部分有效，加载部分的数据实际上并没有加载到闪存中。我知道SB文件没问题，因为我可以通过blhost直接向引导加载程序发送同一个SB文件，而且它能正常工作。本论坛帖子附带了我的 C 源代码，该代码用于将数据流传输到启动 ROM。是否存在任何错误，可以帮助解决这个问题？ 我的引导加载程序代码使用 NXP kb_init、kb_deinit 和 kb_execute API 来流式传输 SB 文件。 我的 sb21 配置 yaml 文件： # 描述：安全二进制文件 v2.1 部分块 章节：   # --------------------------------------===== SB2.1 命令 [可选的] =====---------------------------------------   # 说明：Secure 二进制 v2.1 命令块，列出所有可能的选项 - 根据您的需要进行修改   ＃ 应用 -命令：       # 清除应用程序空间。保留底部预留区域用于持久化数据。 -删除：           地址： 0x10000           长度： 0x6BC00           mem_opt ： 0           标志： 0       # 将已签名的应用程序 MBI 加载到闪存 -加载：           地址： 0x10000           load_opt ： 0           # 文件路径将替换为生成的设备特定 MBI。           文件： C:\code\Application_SECURE_MBI.bin 说明： 1.我可以使用 blhost 将完全相同的 SB21 文件发送到启动 ROM，一切正常。所以我知道SBI不错。 2. 当我使用引导加载程序流式传输 SB21 文件时，它会执行擦除节命令，但 MBI 文件的加载节似乎失败了，但我从 kb_execute 或 init/deinit 调用中完全没有得到任何错误代码。他们都说成功了。 3. 最终的 SB21 文件总大小为 155,568 字节。我能够将每个字节的数据流发送到引导加载程序，所有结果的 status_t 值均为 0x00。 4. 我的 CMPA 已禁用 SECURE_BOOT，已启用 SWD 访问，CMPA 未密封。CFPA的所有功能也都已启用并开放。ISP已启用 LPC55xx 回复： Streaming .SB file via ROM API 嗨@guitardenver 由于同一个 SB2.1 文件在 blhost 中可以正常工作，因此 SB 文件本身应该是有效的。 请您在申请材料中检查以下几点？ 根据LPC55xx用户手册，ROM认证功能使用以下RAM区域： 0x30000000–0x30003FFF 0x14005000–0x140059FF 请检查您的链接器映射，并确保您的工作区、USB 缓冲区、堆栈或其他应用程序数据不与这些区域重叠。 当 kb_init/kb_process/kb_deinit 间接调用 skboot_authenticate() 时，应用程序 HASH 中断向量必须调用 HASH_IRQHandler()。请确认中断转发配置是否正确。 根据 ROM API 要求，我建议首先检查这两个方面。   BR 哈里 回复： Streaming .SB file via ROM API 共享内存区域确实是问题所在。我在链接器文件中保留了这些参数，这样引导加载程序就不会触及它们。文件传输成功。谢谢！