USB init failed: -22 Hi , I have been trying to flash my wic.b2z image to an emmc using uuc tool through a usb port.While flashing an USB init failed: -22 error occured.I am using an imx8mp porcessor. Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot: 0 ## Checking Image at 43800000 ... Unknown image format! Run fastboot ... USB init failed: -22 u-boot=>     i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 Hello,  Please share the complete process and the boot config of your board to analyze what can cause the issue.   Re: USB init failed: -22 U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000) DDRINFO: start DRAM init DDRINFO: DRAM rate 4000MTS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done SEC0:  RNG instantiated Normal Boot Trying to boot from BOOTROM Boot Stage: USB boot Find img info 0x48022fa0, size 1064 Need continue download 1024 NOTICE:  Do not release JR0 to NS as it can be used by HAB NOTICE:  BL31: v2.10.0  (release):automotive-15.0.0_1.1.0 NOTICE:  BL31: Built : 08:52:12, Nov  4 2024 U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000) CPU:   i.MX8MP Lite[4] rev1.1 1600 MHz (running at 1200 MHz) CPU:   Industrial temperature grade (-40C to 105C) at 35C Reset cause: POR Model: NXP i.MX8MPlus LPDDR4 EVK board DRAM:  6 GiB tcpc_init: Can't find device id=0x50 setup_typec: tcpc port2 init failed, err=-19 tcpc_init: Can't find device id=0x50 setup_typec: tcpc port1 init failed, err=-19 Core:  284 devices, 36 uclasses, devicetree: separate MMC:   FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from nowhere... OK [*]-Video Link 0adv7535_mipi2hdmi adv7535@3d: Can't find cec device id=0x3c fail to probe panel device adv7535@3d fail to get display timings probe video device failed, ret -19         [0] lcd-controller@32e80000, video         [1] mipi_dsi@32e60000, video_bridge         [2] adv7535@3d, panel adv7535_mipi2hdmi adv7535@3d: Can't find cec device id=0x3c fail to probe panel device adv7535@3d fail to get display timings probe video device failed, ret -19 In:    serial Out:   serial Err:   serial SEC0:  RNG instantiated MMC: no card present Detect USB boot. Will enter fastboot mode! Net:   Could not get PHY for FEC0: addr 1 Could not get PHY for FEC0: addr 1 eth1: ethernet@30bf0000 [PRIME] Fastboot: Normal Boot from USB for mfgtools *** Warning - Use default environment for                                mfgtools , using default environment Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot:  0 ## Checking Image at 43800000 ... Unknown image format! Run fastboot ... USB init failed: -22 u-boot=> Re: USB init failed: -22 Hello,  Please try again flashing the last pre-build image (Linux 6.18.20_2.0.0) and the last version of the uuu tool.  Regards. 

S32K344 – HSE_BファームウェアをインストールしたアプリケーションでPFLASH Block 2が利用可能ですか? こんにちは、 S32K344 (HSE_FW_S32K344_0_2_55_0、0.2.55.0 ビルド pb150130 (2025 年 1 月 30 日)) を中心とした配電ユニットを開発中です。タイプ：標準FW構成）デュアルバンクブートローダーとセキュアファームウェアアップデート付き。Flashレイアウトのある一点で行き詰まっており、明確な回答をいただけると幸いです。 問題点 NVMの設定領域(アプリケーションが書き込むランタイムパラメータ)は現在、実行中のコードと同じブロック内のPFLASHブロック0に存在しています。実行時にそれらに書き込むと、コア上で書き込み中の読み取り停止が発生し、プログラム/消去操作の間、ユニットがフリーズします。これは私たちのアプリケーションには受け入れられません(PDUはセーフティに関わる負荷を駆動します)。 最も簡単な解決策は、これらの領域を実行コードを含まないブロックに移動することです。ブロック2(0x600000–0x6FFFFF、セクター368–381)が自然な候補です。アプリケーションバンクでは使用されておらず、HSEがデータを保存するブロックでもありません。 これまでに確認したこと – S32K3xxリファレンスマニュアルにはPFLASHブロック構造が説明されていますが、HSE予約については何も触れていません。 – 公開されているHSE Basic FW FAQによると、ブロック0と1はアプリケーションに対して保証されており、HSEファームウェアはブロック3の一部(FULL_MEM構成で176KB)を予約しています。ブロック2については全く言及されていません。 – 私たちが検討したHSEデモアプリケーションやRTDの例もBlock 2を使用していないため、そこから何も推測できません。 – HSEファームウェアリファレンスマニュアルv2.4のNDA/DocStoreアクセス申請を提出しましたが、この内容はこの内容をカバーしていると理解しています。リクエストは保留中です。 質問 HSE_Bファームウェアをインストールした場合、Block 2はFULL_MEM設定のアプリケーション(コードとデータ)に完全に利用可能でしょうか?AB_SWAPについてはどうでしょうか？ アプリケーションコアから実行時にブロック2を消去・プログラミングすることに関して、HSE関連の制限はありますか?HSE、SBAF、またはセキュアブートによってロックまたは監視されているセクター）？ HSEファームウェア、SBAF、アプリケーション間のPFLASHブロックの完全な割り当てを説明した公開文書はありますか?もしなければ、NDA申請が処理される間にHSEファームウェア リファレンス・マニュアルへのアクセスを手伝ってもらえませんか? 確定的な答えが出るまでは、設計は意図的にブロック0と1に限定されており、そのため読み書きの問題が残ります。 ご協力ありがとうございます。 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? 共有していただきありがとうございます 😉 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? こんにちは、 @manu_fenixecu さん、 A1。はい、ブロック2は完全にユーザーフラッシュです。 S32K344、S32K314、およびS32K324のフラッシュメモリのレイアウトについては、HSE-B FW RM v2.7の図33（FULL_MEM）および図34（AB_SWAP）を参照してください。 A2.HSE-B FW RM v2.7、セクション14.6.4.2(HSE_CONFIG_GPR3)— アプリケーションはビット27を読み取るべきです。 A3。公開されている唯一の参考資料は、S32K3xx RM rev12、表198（「HSE_Bファームウェア使用機能フラグが有効になっている場合の構成の詳細」）です。HSE-B FW RMはNDAなしに共有できません。HSE関連のサポートについては、この公開コミュニティではなくサポートチケットを使用してください。 よろしくお願いいたします。 ダニエル

NFCチップの書き込み方法 iPhone 12 Pro Maxを使ってNFC 215チップに書き込みを試みています。私はNXPタグライターアプリを使用しています。NXPタグライターアプリで「新規」→「Webサイト」をクリックし、URIタイプとURIデータとともに説明情報を入力します。次に「保存して書き込む」をクリックすると、「NDEF 記録がデータセットに正常に保存されました」という通知が表示されます。アプリを閉じてチップをタップしても何も反応しません。別の電話でも試してみましたが、やはりうまくいきませんでした。何かアイデアや提案はありますか? nfc error.PNGnfc error.PNGnfcエラー.PNG Re: How to write nfc chip こんにちは、@Erik3さん 「データセットに保存されました」というメッセージは、データがアプリ内にローカルに保存されただけで、まだチップに書き込まれていないことを意味します。お試しください： TagWriterで「My Datasets」に行き、エントリを選択して「Write」→タップ→ 書き込み確認が表示されるまで、iPhoneをチップに近づけてください また、NFC TagInfoアプリを使ってチップをスキャンし、その現在の内容や状態を確認できます。

S32K322 LCU/Emios I would like to understand the encoder implementation and principle differences between the S32K144 and S32K322. With the S32K144, the initial angle is communicated through the PWM and then provided to the count to the ABI interface for further processing. We also have a fault-detection mechanism to detect A, B, and I signal/wire disconnections using the quadrature decoder functionality through FTM. However, with the S32K322, the same logic is not working as expected, particularly because we are currently unable to detect the direction correctly. For example, when the I-pulse wire is disconnected, the absolute count becomes zero. This results in incorrect switching, after which the absolute count gradually varies and eventually reaches 4095 pulses. In the S32K144, even when the I-pulse is disconnected, the A and B signals with a single output are still able to provide the proper count, allowing us to detect the fault. Could you please provide examples or clarify the expected behavior for the following cases? A-pulse wire disconnected B-pulse wire disconnected I-pulse wire disconnected A and B pulse wires disconnected A, B, and I pulse wires disconnected It would also be helpful if you could explain how the encoder count and direction are expected to behave in each of these scenarios for both the S32K144 and S32K322. Regards, Thiru S32K3 S32K1 BRUSHLESS-DC-MOTOR-CONTROL  Re: S32K322 LCU/Emios Hi, The S32K322 does not include the FTM peripheral that is present on the S32K144. On the S32K3 family, the quadrature encoder functionality is built around the cooperation of the LCU, TRGMUX, and eMIOS modules. This is a fundamentally different architecture from the FTM-based quadrature decoder available on S32K144. On S32K322, PHA and PHB are decoded by the LCU into separate CW and CCW pulse streams, which are counted by two eMIOS channels. The application obtains the incremental position from the difference between these counters. A useful starting point for the S32K3 quadrature decoder design is Application Note AN13767, specifically Section 4.2.5, which describes the LUT truth table used for direction detection, TRGMUX routing, and eMIOS edge-counter configuration. Additional information can be found on the S32K344 motor-control kit page and in the related community discussion: AN13767: Application Note AN13767 S32K344 Motor Control Kit: S32K344 BLDC/PMSM Development Kit Community discussion: Quadrature decoder on S32K344 Based on the LCU LUT implementation, if either the A or B signal is disconnected, the remaining channel can still generate transitions that produce CW or CCW pulses at the LCU output. As a result, the corresponding eMIOS counter continues counting and direction information may still be available. However, the pulse rate is reduced, resulting in approximately four times fewer counts per revolution compared to normal operation. If both A and B signals are disconnected, no valid quadrature transitions are present at the LCU inputs. Consequently, neither CW nor CCW pulses are generated and the eMIOS counters remain unchanged. Regarding the index (I) signal, the NXP motor-control kit implementation does not use the index signal. Position and direction are derived solely from the A and B quadrature signals, while the position offset is calibrated during rotor alignment. Furthermore, the index signal is not connected to the MCU in this implementation. Therefore, the behavior observed when disconnecting the I signal appears to be application-specific. BR, Petr Re: S32K322 LCU/Emios I could not fully understand the LCU LUT logic described in the application note. I have the following questions: 1. Detection of A/B signal disconnection: I understand that detecting A or B signal disconnection based only on the absolute count may not be reliable, since the absolute count can remain at 0 or 4095 when either the A or B signal is disconnected. At the same time, defining a fixed threshold based on the CW/CCW counter also seems difficult because the rotor can rotate forward and backward, causing the counter to roll over. The CW/CCW counter can therefore exceed 4095 and continue up to 65535 (uint16), depending on the rollover condition. In this scenario, what would be the recommended logic or threshold for detecting A/B signal disconnection? Could you please suggest a suitable diagnostic approach for this scenario, considering the counter rollover condition?

IW416 Wi-Fi RF Test Mode – PN9 / Payload Pattern for EN 300 328 Hello, We are evaluating IW416 for EN 300 328 regulatory testing using AN14114 Rev.7.0 Our certification laboratory has requested continuous modulated transmission using a PN9 data sequence. However, in the Wi-Fi TX continuous command, AN14114 only describes a fixed payload pattern: echo "tx_continuous= " and gives this example: echo "tx_continuous=1 0 0xAAA 0 3 0x8" Could you please confirm: 1. Does IW416 Wi-Fi RF Test Mode support direct PN9/PRBS9 generation? 2. If not, what payload pattern does NXP recommend for EN 300 328 testing? 3. Can 0xAAA be used as the recommended alternative to PN9 for Continuous Packet Mode? 4. Are these settings correct for continuous modulated transmission? - transmit mode = 0 - cs mode = 0 - active subchannel = 3 Thank you.

フラッシュドライブ # 今 マーケット で一番良いフラッシュドライブはどれか ## どうか教えて Re: Flash Drives こんにちは、@ reedjhn9 あなたの質問の意味がよく分かりませんでした。具体的に、使用している製品と知りたい具体的な問題について教えていただけますか?

TJA1410_10Base_T1s 您好，NXP 我正在使用 S32K5 和 TJA1410 测试 10BASE-T1S。目前，我可以在 TX 引脚上看到波形，RX 和 ED 引脚上也有波形，这表明 MDI 可以接收到信号。但是，TX 引脚无法向 MDI 发送数据。 TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp 此致敬礼。 显龙 以太网 PHY Re: TJA1410_10Base_T1s 你好@wuxianlong ， 你是如何测量MDI的？MDI是差分接口，所以你需要使用差分示波器探头。MDI 需要正确的差分终端匹配 - 请参阅 AN14787 - 应用笔记 10BASE-T1S 以太网 PMD 收发器 TJA1410，修订版 1.0，第 3.3 章。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 希望你一切安好。我写信给您是关于您目前拥有的一款产品——NPI（新产品导入）——S32K5——该产品尚未正式发布。 请注意，已获准提前体验此类产品的客户已指派了现场工程师。您指定的现场工程师应作为您解决有关本产品任何问题、疑虑或疑问的主要支持渠道。 我们的在线支持团队将在该产品正式发布后，提供更广泛的支持服务。在此之前，我们将无法提供所需的帮助。 感谢您的理解。 感谢您的理解。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 嗨， @PavelL 我没有使用差分探头。当我发射（TX）时，示波器上的 MDI 没有波动——它保持平坦/水平。但是，当 PC 发送数据时，MDI 明显显示出差分波形。感觉TJA1410没有正确切换到发射模式，芯片仍然处于正常模式。是否有方法可以验证PHY的当前模式？目前，我们的 TJA1410 未连接到 SMI 接口——我们应该对此采取哪些预防措施？ 此致， 显龙 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 由于 S32K5 是 NPI 设备，请注意，我们目前无法在我们这边验证完整的 S32K5 和 TJA1410 设置。   TJA1410 的工作模式不是通过 SMI 接口选择的。正常模式和传输模式之间的转换由 TX 引脚上接收到的命令控制。因此，观察 TX 上的数据活动并不一定能确认 TJA1410 已进入发射模式。前面的 TRANSMIT 命令及其时序也必须符合 TJA1410 数据表中规定的时序。   请根据 TJA1410 数据表中的图 10 验证从正常模式到传输模式的转换。特别地，请捕获 TX 命令以及差分 VLINE 信号和 ED 输出。这应该可以确认 TJA1410 是否识别 TRANSMIT 命令并激活其 MDI 发射器。   顺祝商祺！ 帕维尔

S32K344 – 安装 HSE_B 固件的应用程序是否可以使用 PFLASH Block 2？ 你好， 我们正在围绕 S32K344 (HSE_FW_S32K344_0_2_55_0, 0.2.55.0 版本 pb150130 (2025 年 1 月 30 日)) 开发配电单元。类型：标准固件配置）具有双库引导加载程序和安全固件更新。我们在 Flash 布局的某一点上遇到了困难，希望能得到一个明确的答案。 问题 我们的 NVM 配置区域（应用程序写入的运行时参数）目前位于 PFLASH 块 0 中，与正在执行的代码位于同一块中。在运行时向它们写入数据会触发内核的读写停顿，从而在编程/擦除操作期间冻结单元。对于我们的应用来说，这是不可接受的（PDU 驱动与功能安全相关的负载）。 显而易见的解决方法是将这些区域移动到不包含已执行代码的块中。块 2（0x600000–0x6FFFFF，扇区 368–381）是自然的候选者：它没有被我们的应用程序银行使用，而且它也不是 HSE 存储其数据的块。 我们目前已核查的内容 – S32K3xx 参考手册描述了 PFLASH 块结构，但没有提及 HSE 预留。 – 公开的 HSE 基本固件常见问题解答指出，第 0 和 1 块保证供应用程序使用，并且 HSE 固件保留了第 3 块的一部分（在 FULL_MEM 配置中为 176 KB）。它完全没有提到第二区。 – 我们看到的 HSE 演示应用程序和 RTD 示例也没有使用 Block 2，因此我们无法从中推断出任何信息。 – 我们已提交 HSE 固件参考手册 v2.4 的 NDA / DocStore 访问请求，据我们了解，该手册涵盖了此内容。请求正在处理中。 问题 安装 HSE_B 固件后，在 FULL_MEM 配置下，Block 2 是否完全可供应用程序（代码和数据）使用？AB_SWAP 呢？ 在运行时从应用程序核心擦除/编程 Block 2 是否存在任何与 HSE 相关的限制（例如，（由 HSE、SBAF 或安全启动锁定或监测的扇区）？ 是否有公开文档描述了 HSE 固件、SBAF 和应用程序之间完整的 PFLASH 块分配情况？如果不行，能否请哪位好心人帮我们在保密协议申请处理期间获取 HSE 固件参考手册？ 在得到确切答案之前，我们的设计特意限制在模块 0 和 1 内，这就给我们留下了边读边写的问题。 提前感谢您的帮助。 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? 谢谢分享 😉 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? 你好@manu_fenixecu ， A1. 是的，Block 2 完全是用户闪存。 有关 S32K344、S32K314 和 S32K324 的闪存布局，请参阅 HSE-B FW RM v2.7 中的图 33（FULL_MEM）和图 34（AB_SWAP）。 A2. HSE-B FW RM v2.7，第 14.6.4.2 节 (HSE_CONFIG_GPR3) — 应用程序应读取第 27 位。 A3.唯一公开的参考资料是 S32K3xx RM rev12，表 198（“启用 HSE_B 固件使用功能标志时的配置详细信息”）。没有签署保密协议，HSE-B FW RM 不能共享。如需 HSE 相关支持，请使用支持工单，而不是在此公共社区中提问。 此致， 丹尼尔

在调用 mlockall(MCL_FUTURE) 的进程中使用 iMX8MP GPU 会导致内核 BUG() 一位客户报告了一个与使用 iMX8MP GPU（使用 EGL 绘图）相关的问题。当初始化 GPU 的进程先前调用 mlockall(MCL_FUTURE) 时，一旦 CMA 区域被映射到用户空间，内核就会报告以下 BUG()： Kernel BUG at remap_pfn_range_internal+0x23c/0x2c8 Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP CPU: 0 PID: 3197 Comm: galcore_window_ Tainted: G O 6.6.142-7.7.0-devel #1-Torizon Hardware name: Toradex Verdin iMX8M Plus WB on Verdin Development Board (DT) pc : remap_pfn_range_internal+0x23c/0x2c8 x27: 00000000a2100000 x20: 0068000000000fcb x19: 0000007f90000000 ^^^^^^^^^^^^^^^^^^^^^^ the PTE already present Call trace: remap_pfn_range_internal+0x23c/0x2c8 remap_pfn_range+0x24/0x58 dma_direct_mmap+0xf4/0x150 dma_mmap_attrs+0x18/0x3c _CMAFSLMapUser+0x9c/0x150 [galcore] gckOS_LockPages+0xe4/0x148 [galcore] gckKERNEL_MapVideoMemory+0x90/0x1dc [galcore] gckVIDMEM_NODE_LockCPU+0x1b4/0x250 [galcore] _LockVideoMemory.isra.0+0x1f4/0x28c [galcore] gckKERNEL_Dispatch+0x210/0x1730 [galcore] gckDEVICE_Dispatch+0xcc/0x220 [galcore] drv_ioctl+0x340/0x444 [galcore] __arm64_sys_ioctl+0xac/0xf0 Kernel panic - not syncing: Oops - BUG: Fatal exception mlockall(MCL_FUTURE) 通常用于实时应用程序，而报告此问题的客户正在使用 CODESYS 来驱动其 HMI。 我们利用人工智能辅助分析了该问题，并找到了该问题触发原因的合理解释： galcore 驱动程序中的 CMA 分配器不包含 .mmap() 方法。钩。在 _CMAFSLMapUser() 执行期间，它调用 mmap() 获取 vma，然后使用该 vma 通过 find_vma() 定位 CMA 区域。mmap() 的调用方式导致内核延迟分配 SHM 区域以满足请求。正常情况下，当找到 CMA 区域并重新映射时，此分配会在片刻后被丢弃。 但是，当 MCL_FUTURE 处于活动状态时，内核不能再延迟分配 SHM 区域，因此它会在 mmap() 返回之前填充整个区域。在这种情况下，该地址上有有效的页面，而稍后对 remap_pfn_range() 的调用最终会默默地丢弃内存管理维护信息，这正是 BUG() 所阻止的。 我将附上一个 zip 文件，其中包含一个程序的源代码，该程序可以稳定地重现该问题，而无需运行 CODESYS。AI代理建议使用以下补丁来修复此问题： diff -uNr a/hal/kernel/inc/gc_hal_options.h b/hal/kernel/inc/gc_hal_options.h --- a/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:00:44.596621860 +0000 +++ b/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:01:15.643862002 +0000 @@ -1471,9 +1471,17 @@ * Enable this macro can replace the /dev/zero by anon_inode: * [galcore] in /proc/ /maps. * Without the macro, run 'cat /proc/ /maps' will print "/dev/zero". + * + * It is also what gives the allocators an ->mmap handler, which is + * required so that the reservation made by vm_mmap() is created as a + * device mapping (VM_IO | VM_PFNMAP) rather than as ordinary anonymous + * memory. Without it, a process that has called mlockall(MCL_FUTURE) + * gets the range pre-faulted inside vm_mmap(), and the subsequent + * remap_pfn_range() then hits BUG_ON(!pte_none()) in remap_pte_range(). + * See tmp_mmap() in gc_hal_kernel_allocator.c. */ #ifndef gcdANON_FILE_FOR_ALLOCATOR -# define gcdANON_FILE_FOR_ALLOCATOR 0 +# define gcdANON_FILE_FOR_ALLOCATOR 1 #endif /* diff -uNr a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c --- a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:00:44.605314869 +0000 +++ b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:01:15.644216883 +0000 @@ -400,7 +400,13 @@ gcmkHEADER_ARG("Allocator=%p Mdl=%p Cacheable=%d", Allocator, Mdl, Cacheable); #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 4, 0) +#if gcdANON_FILE_FOR_ALLOCATOR + /* Same as the gfp, dma and reserved_mem allocators: go through the + * allocator's anon file so that its ->mmap handler runs. */ + userLogical = (gctPOINTER)vm_mmap(Allocator->anon_file, +# else userLogical = (gctPOINTER)vm_mmap(gcvNULL, +# endif 0L, Mdl->numPages * PAGE_SIZE, PROT_READ | PROT_WRITE, diff -uNr a/hal/os/linux/kernel/gc_hal_kernel_allocator.c b/hal/os/linux/kernel/gc_hal_kernel_allocator.c --- a/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:00:44.603242857 +0000 +++ b/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:01:15.644041018 +0000 @@ -104,6 +104,36 @@ static int tmp_mmap(struct file *fp, struct vm_area_struct *vma) { + /* + * Declare the reservation as a device mapping with raw PFNs, before + * mmap() returns it to the caller. remap_pfn_range() sets both flags + * anyway; setting them here only makes them effective from the moment + * the VMA is created, and that is what matters: + * + * - the kernel treats VM_IO | VM_PFNMAP as VM_SPECIAL, documented in + * include/linux/mm.h as "Special vmas that are non-mergable, + * non-mlock()able". mmap_region() therefore clears VM_LOCKED from + * this VMA and leaves mm->locked_vm alone, and __mm_populate() + * skips it outright ("if (vma->vm_flags & (VM_IO | VM_PFNMAP)) + * continue;" in mm/gup.c). + * + * - so a process that has called mlockall(MCL_FUTURE) no longer has + * this range pre-faulted inside vm_mmap(). Every other mapping in + * that process keeps being locked and pre-faulted as before; only + * device memory, which is neither pageable nor swappable and gains + * nothing from being pre-faulted, is left out. + * + * - and the allocator's own remap_pfn_range(), a few microseconds + * later, therefore finds an empty range instead of one the kernel + * has just populated, so it no longer trips + * BUG_ON(!pte_none(ptep_get(pte))) in remap_pte_range(). + */ +#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0) + vm_flags_set(vma, VM_IO | VM_PFNMAP); +#else + vma->vm_flags |= VM_IO | VM_PFNMAP; +#endif + return 0; } 上游驱动程序使用了一种不同的机制来绕过这个问题。其他 galcore 分配器使用相同的模式（调用 vm_mmap 获取 vma），因此很可能容易受到相同的 BUG() 的影响。 请您调查并修复 galcore 驱动程序？这个问题导致实际应用场景无法正常运行，直接影响到我们的客户。 谢谢！ 拉斐尔 Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() 嗨@rbeims 让我先运行一下测试，然后再和GPU团队确认。 此致， 志明

TJA1445がスリープモードの場合、CANHとCANLは低レベルになります。 こんにちは、 TJA1445をスリープモードでテストする際、ウェイクアップソースモードをWUFに設定し、VBATVCCをデフォルトで0、CPNCを1、PNCOKを1に設定した場合、スリープモードに入った後にCANHとCANLが2.5Vではなく低レベル（0V）になるのはなぜですか？この時点でCANの状態は「CANオフライン」ですか？TJA1445がスリープモードに入ったときにCANHとCANLが2.5Vになるように設定するにはどうすればよいですか？現在のテスト環境では、CANメッセージを1つ送信するだけではTJA1445をウェイクアップするには不十分です。 liugaosong_0-1788782128664.pngliugaosong_0-1788782128664.pngliugaosong_0-1788782128664.png CH1はINHピン、CH2はCANHピンです。ご覧のとおり、スリープモードは低レベルです。 Re: TJA1445 休眠时CANH和CANL为低电平 PN関連のレジスタが電源障害前に設定されていれば、VCC/VIOをオフにしてBATのみを残すことができます。  そして、バス上でWUPに一致するメッセージが見つかった場合、CANオフラインからCANオフラインバイアスに移行できます。WUFに一致する別のメッセージを受信すると、PNウェイクアップを開始できます。 WUPメッセージの要件は、ほとんどのメッセージで一般的に満たされています。つまり、特定のフレームを2つ連続して送信すれば、デバイスを起動するのに十分です。     Re: TJA1445 休眠时CANH和CANL为低电平 こんにちは、 ボードがスリープモードになり、VCCがオフになった場合、TJA1445は1フレームでウェイクアップできないのでしょうか？CANオフラインからCANオフラインバイアスへのプロセスを経る必要があるのでしょうか？このとき、CANHとCANLは2.5Vになるのでしょうか、それともCANステータスが常にCANオフラインモードのままTJA1445はスリープモードに入るのでしょうか？

Flash Drives # which is best flash drive avialble now in the market ## Please tell me Re: Flash Drives Hi@reedjhn9 I didn't quite understand your question. Could you describe it in more detail—specifically, the product you are using and the exact issue you want to know about?

USB初期化失敗: -22 こんにちは、 USBポート経由でuucツールを使用してwic.b2zイメージをeMMCに書き込もうとしています。書き込み中にUSB初期化失敗：-22エラーが発生しました。imx8mpプロセッサを使用しています。 bootcmd_mfg を実行します: mfgtool_args を実行します。iminfo が${initrd_addr}の場合、test が${tee}の場合、bootm が${tee_addr} ${initrd_addr} ${fdt_addr}の場合、booti が${loadaddr} ${initrd_addr} ${fdt_addr}の場合、fi を実行します。それ以外の場合は、echo "fastboot を実行します..." を実行します。fastboot 0 を実行します。fi を実行します。 自動起動を停止するには、任意のキーを押してください: 0 ## 43800000 番地の画像を確認中... 不明な画像フォーマット！ fastbootを実行... USB初期化失敗: -22 u-boot=>     i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 こんにちは、 問題の原因を分析するために、ボードの起動設定と全過程を共有してください。 Re: USB init failed: -22 U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0(2024年11月15日 - 04:02:13 +0000) DDRINFO: DRAM initを起動 DDRINFO:DRAMレート4000MTS DDRINFO:ddrphyのキャリブレーション完了 DDRINFO: ddrmix設定完了 第0節:RNGのインスタンス化 ノーマルブート BOOTROMからの起動を試みています 起動段階:USB起動 img info 0x48022fa0、サイズ1064を探せます ダウンロードを続ける必要があります 1024 注意:JR0はHABで使用可能なのでNSにリリースしないでください 通知:BL31: v2.10.0(リリース):オートモーティブ-15.0.0_1.1.0 お知らせ：BL31：製造日時：2024年11月4日 08:52:12 U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0(2024年11月15日 - 04:02:13 +0000) CPU:i.MX8MP Lite[4] rev1.1 1600 MHz(1200 MHzで動作) CPU:インダストリアル温度グレード(-40°Cから105°C)で35°Cに対応 リセット原因:POR(POR) モデル:NXP i.MX8MPlus LPDDR4 EVKボード DRAM:6 GiB tcpc_init: デバイスIDが見つからない=0x50 setup_typec: tcpc port2 init 失敗、err=-19 tcpc_init: デバイスIDが見つからない=0x50 setup_typec: tcpc port1 init 失敗、err=-19 コア:284デバイス、36 uクラス、デバイスツリー:別々 MMC: FSL_SDHC: 1, FSL_SDHC: 2 どこからともなく環境を読み込む...了解 [*]-ビデオリンク0adv7535_mipi2hdmi adv7535@3d:cecデバイスID=0x3cが見つかりません プローブ失敗 パネル装置adv7535@3d 表示タイミングが取得できない プローブ映像装置故障、退位-19 [0] LCD-controller@32e80000、ビデオ [1] mipi_dsi@32e60000、video_bridge [2] adv7535@3d、パネル adv7535_mipi2hdmi adv7535@3d: cecデバイスIDが見つからない=0x3c プローブ失敗 パネル装置adv7535@3d 表示タイミングが取得できない プローブ映像装置故障、退位-19 出演:連続ドラマ 終了:連続ドラマ えっと:連続 第0節:RNGのインスタンス化 MMC:カードは提示されていません USB起動検出。Fastbootモードに入る! ネット:FEC0のPHYが取得できませんでした:addr 1 FEC0: addr 1のPHYが取得できませんでした eth1:ethernet@30bf0000【プライム】 速攻:通常 mfgtoolsのUSBから起動 警告 - mfgtoolsのデフォルト環境をご利用ください 、デフォルト環境を使用 実行bootcmd_mfg:実行mfgtool_args;もし情報が ${initrd_addr}なら;もしテストなら ${tee} =はい;次にbootm ${tee_addr} ${initrd_addr} ${fdt_addr};そうでなければbooti ${loadaddr} ${initrd_addr} ${fdt_addr};fi;そうでなければエコー「Run fastboot ...";ファストブート0;FI; どのキーを押してもオートブートを止める:0 ## 43800000で画像確認中... 不明な画像フォーマット! fastbootを実行... USB初期化失敗: -22 u-boot=> Re: USB init failed: -22 こんにちは、 最後のプリビルドイメージ(Linux 6.18.20_2.0.0)と uuu ツールの最終バージョンを再度フラッシュしてみてください。 敬具。

USB 初始化失败：-22 您好， 我尝试使用 uuc 工具通过 USB 端口将 wic.b2z 镜像刷入 eMMC 存储。刷写过程中出现 USB 初始化失败：-22 错误。我使用的是 imx8mp 处理器。 运行 bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr} ; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr} ; else booti ${loadaddr} ${initrd_addr} ${fdt_addr} ; fi; else echo "运行 fastboot ..."; fastboot 0; fi; 按任意键停止自动启动：0 正在检查 43800000 处的图像... 未知图像格式！ 运行 fastboot... USB 初始化失败：-22 u-boot=>     i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 你好， 请提供完整的操作流程和主板的启动配置，以便我们分析问题原因。 Re: USB init failed: -22 U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0（2024年11月15日 - 04:02:13 +0000） DDRINFO：启动 DRAM 初始化 DDRINFO：DRAM 速率 4000MTS DDRINFO：DDRPHY 校准完成 DDRINFO：ddrmix 配置完成 SEC0：RNG 实例化 正常启动 尝试从 BOOTROM 启动 启动阶段：USB 启动 查找图像信息 0x48022fa0，大小 1064 需要继续下载 1024 注意：请勿将 JR0 释放给 NS，因为它可能被 HAB 使用。 注意：BL31：v2.10.0（版本）：automotive-15.0.0_1.1.0 通知：BL31：构建时间：2024年11月4日 08:52:12 U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0（2024年11月15日 - 04:02:13 +0000） CPU：i.MX8MP Lite[4] rev1.1 1600 MHz（运行频率为 1200 MHz） CPU：工业级耐温等级（-40℃至105℃），工作温度35℃ 复位原因：POR 型号：NXP i.MX8MPlus LPDDR4 EVK 板 动态随机存取存储器(DRAM)：6 GiB tcpc_init：找不到设备 ID=0x50 setup_typec：tcpc port2 初始化失败，错误代码=-19 tcpc_init：找不到设备 ID=0x50 setup_typec：tcpc port1 初始化失败，错误代码=-19 核心：284 个设备，36 个微类，设备树：独立 MMC：FSL_SDHC：1，FSL_SDHC：2 环境正在加载，但不知从何而来……好的 [*]-视频链接 0adv7535_mipi2hdmi adv7535@3d：找不到 CEC 设备 ID=0x3c 探测面板设备 adv7535@3d 失败 无法获取显示时序 探测视频设备故障，返回码 -19 [0] lcd-controller@32e80000，视频 [1] mipi_dsi@32e60000，视频桥 [2] adv7535@3d，面板 adv7535_mipi2hdmi adv7535@3d：找不到 CEC 设备 ID=0x3c 探测面板设备 adv7535@3d 失败 无法获取显示时序 探测视频设备故障，返回码 -19 输入：串行 输出：串口 错误：串行 SEC0：RNG 实例化 MMC：未持有卡片 检测 USB 启动。即将进入fastboot模式！ 网络：无法获取 FEC0 的 PHY：地址 1 无法获取 FEC0 的 PHY：地址 1 eth1：以太网@30bf0000 [PRIME] Fastboot：正常 从 USB 启动 mfgtools *** 警告 - 请使用 mfgtools 的默认环境 使用默认环境 运行 bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr} ; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr} ; else booti ${loadaddr} ${initrd_addr} ${fdt_addr} ; fi; else echo "运行 fastboot ..."; fastboot 0; fi; 按任意键停止自动启动：0 ## 正在检查 43800000 处的图像... 未知图像格式！ 运行 fastboot... USB 初始化失败：-22 u-boot=> Re: USB init failed: -22 你好， 请尝试再次刷入最新的预编译镜像（ Linux 6.18.20_2.0.0 ）和最新版本的uuu工具。 此致敬礼

S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? Hello, We are developing a Power Distribution Unit around the S32K344 (HSE_FW_S32K344_0_2_55_0, 0.2.55.0 build pb150130 (30 janvier 2025). Type : Standard FW configuration) with a dual-bank bootloader and secure firmware update. We are stuck on one point of the flash layout and would appreciate a definitive answer. The problem Our NVM configuration regions (runtime parameters written by the application) currently live in PFLASH Block 0, in the same block as the executing code. Writing to them at runtime triggers read-while-write stalls on the core, which freezes the unit for the duration of the program/erase operation. This is not acceptable for our application (the PDU drives safety-relevant loads). The obvious fix is to move these regions to a block that does not contain executed code. Block 2 (0x600000–0x6FFFFF, sectors 368–381) is the natural candidate: it is not used by our application banks, and it is not the block where HSE stores its data. What we have checked so far – The S32K3xx Reference Manual describes the PFLASH block structure but does not say anything about HSE reservations. – The public HSE Basic FW FAQ states that Blocks 0 and 1 are guaranteed for the application, and that the HSE firmware reserves part of Block 3 (176 KB in FULL_MEM configuration). It does not mention Block 2 at all. – The HSE demo application and RTD examples we looked at do not use Block 2 either, so we cannot infer anything from them. – We have submitted an NDA / DocStore access request for the HSE Firmware Reference Manual v2.4, which we understand covers this. The request is pending. Questions With HSE_B firmware installed, is Block 2 entirely available to the application (code and data) in FULL_MEM configuration? What about AB_SWAP? Is there any HSE-related restriction on erasing/programming Block 2 at runtime from the application core (e.g. sectors locked or monitored by HSE, SBAF or secure boot)? Is there a public document that describes the full PFLASH block allocation between HSE firmware, SBAF and the application? If not, could someone help us get access to the HSE Firmware Reference Manual while our NDA request is processed? Until we have a confirmed answer, our design is deliberately confined to Blocks 0 and 1, which leaves us with the read-while-write issue. Thank you in advance for your help. Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? Hello @manu_fenixecu, A1. Yes, Block 2 is entirely user flash. Refer to HSE-B FW RM v2.7, Figure 33 (FULL_MEM) and Figure 34 (AB_SWAP) for the flash memory layout of S32K344, S32K314, and S32K324. A2. HSE-B FW RM v2.7, Section 14.6.4.2 (HSE_CONFIG_GPR3) — the application should read bit 27. A3. The only publicly available reference is the S32K3xx RM rev12, Table 198 ("Configuration details when the HSE_B firmware usage feature flag is enabled"). The HSE-B FW RM cannot be shared without an NDA in place. For HSE-related support, please use support tickets rather than this public community. Regards, Daniel Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? Thank you for sharing 😉

mlockall(MCL_FUTURE)を呼び出すプロセスでiMX8MP GPUを使用すると、カーネルBUG() あるお客様がiMX8MPのGPU使用(EGLによる描画)に関する問題を報告しました。以前mlockall(MCL_FUTURE)と呼ばれていたGPU初期化プロセスが、CMA領域がユーザースペースにマッピングされると、カーネルは以下のBUG()を報告します: Kernel BUG at remap_pfn_range_internal+0x23c/0x2c8 Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP CPU: 0 PID: 3197 Comm: galcore_window_ Tainted: G O 6.6.142-7.7.0-devel #1-Torizon Hardware name: Toradex Verdin iMX8M Plus WB on Verdin Development Board (DT) pc : remap_pfn_range_internal+0x23c/0x2c8 x27: 00000000a2100000 x20: 0068000000000fcb x19: 0000007f90000000 ^^^^^^^^^^^^^^^^^^^^^^ the PTE already present Call trace: remap_pfn_range_internal+0x23c/0x2c8 remap_pfn_range+0x24/0x58 dma_direct_mmap+0xf4/0x150 dma_mmap_attrs+0x18/0x3c _CMAFSLMapUser+0x9c/0x150 [galcore] gckOS_LockPages+0xe4/0x148 [galcore] gckKERNEL_MapVideoMemory+0x90/0x1dc [galcore] gckVIDMEM_NODE_LockCPU+0x1b4/0x250 [galcore] _LockVideoMemory.isra.0+0x1f4/0x28c [galcore] gckKERNEL_Dispatch+0x210/0x1730 [galcore] gckDEVICE_Dispatch+0xcc/0x220 [galcore] drv_ioctl+0x340/0x444 [galcore] __arm64_sys_ioctl+0xac/0xf0 Kernel panic - not syncing: Oops - BUG: Fatal exception mlockall(MCL_FUTURE)はリアルタイムアプリケーションで一般的に使われており、問題を報告した顧客はCODESYSを使ってHMIを駆動しています。 AIを活用した分析を実施した結果、問題が発生する理由として考えられる説明が明らかになりました。 galcoreドライバーのCMAアロケーターには.mmap()が含まれていません。フック。_CMAFSLMapUser() の実行中に、mmap() を呼び出して vma を取得し、それを使用して find_vma() を使用して CMA 領域を特定します。mmap() の呼び出し方法により、カーネルは要求を満たすために SHM 領域を遅延的に割り当てることになります。通常の場合、CMAが見つかって再マッピングされると、この割り当てはすぐに破棄されます。 しかし、MCL_FUTUREがアクティブなとカーネルはもはやSHM領域を怠惰に割り当てることができなくなり、mmap()が戻る前にエリア全体を埋め尽くします。この場合、このアドレスには有効なページがあり、後のremap_pfn_range()への呼び出しはメモリ管理のハウスキーピング情報を静かに破棄することになり、これはまさにBUG()が防いでいることです。 CODESYSを実行せずに問題を再現できるプログラムのソースコードを含むzipファイルを添付します。AIエージェントは、この問題を修正するために以下のパッチを提案しました。 diff -uNr a/hal/kernel/inc/gc_hal_options.h b/hal/kernel/inc/gc_hal_options.h --- a/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:00:44.596621860 +0000 +++ b/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:01:15.643862002 +0000 @@ -1471,9 +1471,17 @@ * Enable this macro can replace the /dev/zero by anon_inode: * [galcore] in /proc/ /maps. * Without the macro, run 'cat /proc/ /maps' will print "/dev/zero". + * + * It is also what gives the allocators an ->mmap handler, which is + * required so that the reservation made by vm_mmap() is created as a + * device mapping (VM_IO | VM_PFNMAP) rather than as ordinary anonymous + * memory. Without it, a process that has called mlockall(MCL_FUTURE) + * gets the range pre-faulted inside vm_mmap(), and the subsequent + * remap_pfn_range() then hits BUG_ON(!pte_none()) in remap_pte_range(). + * See tmp_mmap() in gc_hal_kernel_allocator.c. */ #ifndef gcdANON_FILE_FOR_ALLOCATOR -# define gcdANON_FILE_FOR_ALLOCATOR 0 +# define gcdANON_FILE_FOR_ALLOCATOR 1 #endif /* diff -uNr a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c --- a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:00:44.605314869 +0000 +++ b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:01:15.644216883 +0000 @@ -400,7 +400,13 @@ gcmkHEADER_ARG("Allocator=%p Mdl=%p Cacheable=%d", Allocator, Mdl, Cacheable); #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 4, 0) +#if gcdANON_FILE_FOR_ALLOCATOR + /* Same as the gfp, dma and reserved_mem allocators: go through the + * allocator's anon file so that its ->mmap handler runs. */ + userLogical = (gctPOINTER)vm_mmap(Allocator->anon_file, +# else userLogical = (gctPOINTER)vm_mmap(gcvNULL, +# endif 0L, Mdl->numPages * PAGE_SIZE, PROT_READ | PROT_WRITE, diff -uNr a/hal/os/linux/kernel/gc_hal_kernel_allocator.c b/hal/os/linux/kernel/gc_hal_kernel_allocator.c --- a/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:00:44.603242857 +0000 +++ b/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:01:15.644041018 +0000 @@ -104,6 +104,36 @@ static int tmp_mmap(struct file *fp, struct vm_area_struct *vma) { + /* + * Declare the reservation as a device mapping with raw PFNs, before + * mmap() returns it to the caller. remap_pfn_range() sets both flags + * anyway; setting them here only makes them effective from the moment + * the VMA is created, and that is what matters: + * + * - the kernel treats VM_IO | VM_PFNMAP as VM_SPECIAL, documented in + * include/linux/mm.h as "Special vmas that are non-mergable, + * non-mlock()able". mmap_region() therefore clears VM_LOCKED from + * this VMA and leaves mm->locked_vm alone, and __mm_populate() + * skips it outright ("if (vma->vm_flags & (VM_IO | VM_PFNMAP)) + * continue;" in mm/gup.c). + * + * - so a process that has called mlockall(MCL_FUTURE) no longer has + * this range pre-faulted inside vm_mmap(). Every other mapping in + * that process keeps being locked and pre-faulted as before; only + * device memory, which is neither pageable nor swappable and gains + * nothing from being pre-faulted, is left out. + * + * - and the allocator's own remap_pfn_range(), a few microseconds + * later, therefore finds an empty range instead of one the kernel + * has just populated, so it no longer trips + * BUG_ON(!pte_none(ptep_get(pte))) in remap_pte_range(). + */ +#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0) + vm_flags_set(vma, VM_IO | VM_PFNMAP); +#else + vma->vm_flags |= VM_IO | VM_PFNMAP; +#endif + return 0; } 上流ドライバーはこの問題を回避する別のメカニズムを使用しています。他の galcore アロケータも同じパターン (vm_mmap を呼び出して vma を取得する) を使用しているため、同じ BUG() の影響を受ける可能性があります。 この件について調べて、galcoreドライバーを直してもらえますか?この問題は実際のユースケースが正常に動作することを妨げており、直接的にお客様に影響を及ぼしています。 ありがとうございました。 ラファエル Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() こんにちは@rbeims  テストを実行してからGPUチームに確認させてください。 よろしくお願いします、 志明

i.MX8QXP C0: クラッシュ証拠キャプチャ SCwatchdogresetCortex-M4監視A35クラスタ全体にラムーブ こんにちは、NXPチームの皆さん、 プラットフォームの詳細: SoC: i.MX8QXP C0、MEKリファレンスに基づくカスタムボード BSP: NXP Linux 6.6.3 [状態完全タグ、例:lf-6.6.3-1.0.0]、ヨクト・スカースギャップ SCFWバージョン：[scu_rmを実行し、ブートログを確認してバージョンを貼り付けてください] SECO/AHAB: [有効/無効、バージョン] U-Boot: [2024.04/tag] Cortex-M4(CM4_0):現在使用されておらず、ファームウェアはインストールされていません ユースケース:生産オートモーティブ向けインストゥルメントクラスター;A35はLinux/Weston HMIを動作させています 問題提起： 実稼働環境では、A35 複合システムがクラッシュしたり、ハードハングアップ（カーネルパニック／ロックアップ）を起こしたりするケースが時折発生します。現在では持続的なクラッシュの証拠もなく、自律的な復旧もありません。クラスターは手動で電源を入れ直すまで停止状態のままで、フィールドやDVの発生はデバッグできません。我々は、(a) pstore/ramoops を使用したウォッチドッグリセット後のパニックログの永続化、および (b) A35 パーティションのみをリセットできる機能を備えた CM4_0 による A35 の監視を実装したいと考えています。 i.MX8QXP C0において、システムウォッチドッグ（imx-sc-wdt、SCFWによって処理される）が作動した場合、どのようなタイプのリセットが実行されますか？（SoC/ボード全体のリセット、またはAクラスタパーティションのリセット）これはSCFWボードファイルまたはsc_pm API経由で設定可能ですか？ Re: i.MX8QXP C0: crashevidence capture ramoops across SCwatchdogresetCortex-M4 supervision A35 clus こんにちは、 はい、SCFWが管理する仮想監視犬を使ってパーティションをリセットすることもできます SC_TIMER_WDOG_ACTION_PARTITION 動作はLinux/A35パーティションのみをリセットします。 また、SCFW sc_pm APIを介してA35パーティション上で sc_pm_reset_partition() を呼び出すことで、CM4_0ファームウェアから直接同じ効果を得る方法もあります。これにより、CM4_0はウォッチドッグメカニズムとは独立した完全な監視制御が可能になります。 この件については、あなたが使っている特定のバージョンのSCFW移植ガイドで詳しく知ることができます。 よろしくお願いいたします。 アルド。

S32K322 LCU/Emios S32K144とS32K322のエンコーダの実装方法と原理の違いについて理解を深めたいです。 S32K144では、初期の角度がPWMを通じて伝達され、その後カウントがABIインターフェースに提供されてさらなるプロセッシングが行われます。また、FTMを介した直交デコーダ機能を使用して、A、B、I信号／配線の断線を検出する故障検出メカニズムも備えています。 しかし、S32K322では、同じロジックが期待どおりに動作せず、特に方向を正しく検出できないことが問題となっています。 例えば、Iパルス線が切断されると、絶対カウントはゼロになる。これによりスイッチングが誤作動し、その後、絶対カウントが徐々に変化し、最終的に4095パルスに達する。 S32K144では、Iパルスが切断された場合でも、単一出力のA信号とB信号によって適切なカウント値が得られるため、故障を検出することが可能です。 以下のケースで期待される挙動を例示したり、明確にしていただけますか? Aパルスワイヤーが切断されました Bパルスワイヤーが外れています Iパルスワイヤが切断されました AとBのパルスワイヤーが切断されています A、B、Iパルスワイヤが切断されている また、S32K144とS32K322の両方で、これらのシナリオでエンコーダのカウントと方向がどのように振る舞うかについても説明していただけると助かります。 よろしくお願いいたします。 ティル S32K3 S32K1 ブラシレスDCモータ  Re: S32K322 LCU/Emios こんにちは、 S32K322にはS32K144上にあるFTMペリフェラルは含まれていません。S32K3ファミリでは、直交エンコーダの機能はLCU、TRGMUX、eMIOSモジュールの連携を中心に構築されています。これは、S32K144に搭載されているFTMベースの直交デコーダとは根本的に異なるアーキテクチャである。 S32K322では、PHAとPHBはLCUによって別々のCWおよびCCWパルスストリームにデコードされ、2つのeMIOSチャネルでカウントされます。アプリケーションはこれらのカウンターの差からインクリメンタル位置を得ます。 S32K3直交デコーダデザインの有用な出発点は、アプリケーションノートAN13767、特に4.2.5節で、方向検出、TRGMUXルーティング、eMIOSエッジカウンタ構成に使用されるLUT真理表を説明しています。追加情報はS32K344モータ制御キットのページおよび関連するコミュニティディスカッションでご覧いただけます。 AN13767: アプリケーションノートAN13767 S32K344モーター制御キット: S32K344 BLDC/PMSM開発キット コミュニティディスカッション： S32K344の直交デコーダ LCUのLUT実装に基づき、A信号またはB信号のいずれかが切断されても、残ったチャネルはLCU出力でCWまたはCCWパルスを生成するトランジションを生成できます。その結果、対応するeMIOSカウンターはカウントを継続し、方向情報が引き続き取得できる場合があります。しかし、パルスレートが低下するため、通常動作時と比較して1回転あたりのカウント数が約4分の1に減少する。 A信号とB信号の両方が切断されている場合、LCU入力には有効な直交位相遷移は存在しません。その結果、CWパルスもCCWパルスも生成されず、eMIOSカウンタは変化しない。 インデックス(I)信号に関しては、NXPモーター制御キットの実装ではインデックス信号は使用されていません。位置と方向はAおよびBの直交信号のみから導かれ、位置のずれはローターアライメント時に校正されます。さらに、この実装ではインデックス信号はMCUに接続されていません。したがって、I信号を切断した際に観察される挙動はアプリケーション固有のものと考えられます。 BR、ペトル Re: S32K322 LCU/Emios アプリケーションノートに記載されているLCUのLUTロジックを完全には理解できませんでした。 私には以下の質問があります。 1. A/B信号切断の検出: 絶対カウントだけでAまたはB信号の切断を検出するのは信頼性が低いことは理解しています。なぜなら、AまたはBの信号が切断された場合でも絶対カウントが 0または4095 のままになるからです。 同時に、 CW/CCWカウンター に基づいて固定しきい値を定義するのは難しいです。なぜならローターが前後に回転し、カウンターが転がってしまうからです。したがって、CW/CCWカウンターはロールオーバー条件に応じて 4095を超え、最大65535(uint16)まで続きます。 このシナリオにおいて、 A/B信号の切断を検出するための推奨されるロジックまたは閾値は何でしょうか？ カウンターローバーの状態を考慮し、この状況に適した診断方法を提案していただけますか?

Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() A customer reported an issue related to the use of the iMX8MP GPU (drawing using EGL). When the process that initializes the GPU previously called mlockall(MCL_FUTURE), as soon as the CMA area is mapped into userspace, the kernel reports the following BUG(): Kernel BUG at remap_pfn_range_internal+0x23c/0x2c8 Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP CPU: 0 PID: 3197 Comm: galcore_window_ Tainted: G O 6.6.142-7.7.0-devel #1-Torizon Hardware name: Toradex Verdin iMX8M Plus WB on Verdin Development Board (DT) pc : remap_pfn_range_internal+0x23c/0x2c8 x27: 00000000a2100000 x20: 0068000000000fcb x19: 0000007f90000000 ^^^^^^^^^^^^^^^^^^^^^^ the PTE already present Call trace: remap_pfn_range_internal+0x23c/0x2c8 remap_pfn_range+0x24/0x58 dma_direct_mmap+0xf4/0x150 dma_mmap_attrs+0x18/0x3c _CMAFSLMapUser+0x9c/0x150 [galcore] gckOS_LockPages+0xe4/0x148 [galcore] gckKERNEL_MapVideoMemory+0x90/0x1dc [galcore] gckVIDMEM_NODE_LockCPU+0x1b4/0x250 [galcore] _LockVideoMemory.isra.0+0x1f4/0x28c [galcore] gckKERNEL_Dispatch+0x210/0x1730 [galcore] gckDEVICE_Dispatch+0xcc/0x220 [galcore] drv_ioctl+0x340/0x444 [galcore] __arm64_sys_ioctl+0xac/0xf0 Kernel panic - not syncing: Oops - BUG: Fatal exception mlockall(MCL_FUTURE) is commonly used by real time applications, and the customer who reported the issue is using CODESYS to drive their HMI. We executed an AI-assisted analysis of the issue, and uncovered a plausible explanation for the reason the issue is being triggered: The CMA allocator in the galcore driver doesn't include an .mmap() hook. During the _CMAFSLMapUser() execution, it calls mmap() to get a vma, which is then used to locate the CMA area using find_vma(). The way mmap() is called causes the kernel to lazilly allocate a SHM area to fullfil the request. In normal cases, this allocation gets discarded moments later when the CMA are is found and remapped. However, when MCL_FUTURE is active the kernel cannot lazilly allocate the SHM area anymore, so it goes and populates the entire area before mmap() returns. In this case we have valid pages on this address, and the later call to remap_pfn_range() would end up silently discarding the memory management housekeeping information, which is exactly what the BUG() prevents. I'll attach a zip file which contains the source code of a program that reproduces the issue consistently without the need to run CODESYS. The AI agent suggested the following patch to fix it: diff -uNr a/hal/kernel/inc/gc_hal_options.h b/hal/kernel/inc/gc_hal_options.h --- a/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:00:44.596621860 +0000 +++ b/hal/kernel/inc/gc_hal_options.h 2026-09-04 13:01:15.643862002 +0000 @@ -1471,9 +1471,17 @@ * Enable this macro can replace the /dev/zero by anon_inode: * [galcore] in /proc/ /maps. * Without the macro, run 'cat /proc/ /maps' will print "/dev/zero". + * + * It is also what gives the allocators an ->mmap handler, which is + * required so that the reservation made by vm_mmap() is created as a + * device mapping (VM_IO | VM_PFNMAP) rather than as ordinary anonymous + * memory. Without it, a process that has called mlockall(MCL_FUTURE) + * gets the range pre-faulted inside vm_mmap(), and the subsequent + * remap_pfn_range() then hits BUG_ON(!pte_none()) in remap_pte_range(). + * See tmp_mmap() in gc_hal_kernel_allocator.c. */ #ifndef gcdANON_FILE_FOR_ALLOCATOR -# define gcdANON_FILE_FOR_ALLOCATOR 0 +# define gcdANON_FILE_FOR_ALLOCATOR 1 #endif /* diff -uNr a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c --- a/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:00:44.605314869 +0000 +++ b/hal/os/linux/kernel/allocator/freescale/gc_hal_kernel_allocator_cma.c 2026-09-04 13:01:15.644216883 +0000 @@ -400,7 +400,13 @@ gcmkHEADER_ARG("Allocator=%p Mdl=%p Cacheable=%d", Allocator, Mdl, Cacheable); #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 4, 0) +#if gcdANON_FILE_FOR_ALLOCATOR + /* Same as the gfp, dma and reserved_mem allocators: go through the + * allocator's anon file so that its ->mmap handler runs. */ + userLogical = (gctPOINTER)vm_mmap(Allocator->anon_file, +# else userLogical = (gctPOINTER)vm_mmap(gcvNULL, +# endif 0L, Mdl->numPages * PAGE_SIZE, PROT_READ | PROT_WRITE, diff -uNr a/hal/os/linux/kernel/gc_hal_kernel_allocator.c b/hal/os/linux/kernel/gc_hal_kernel_allocator.c --- a/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:00:44.603242857 +0000 +++ b/hal/os/linux/kernel/gc_hal_kernel_allocator.c 2026-09-04 13:01:15.644041018 +0000 @@ -104,6 +104,36 @@ static int tmp_mmap(struct file *fp, struct vm_area_struct *vma) { + /* + * Declare the reservation as a device mapping with raw PFNs, before + * mmap() returns it to the caller. remap_pfn_range() sets both flags + * anyway; setting them here only makes them effective from the moment + * the VMA is created, and that is what matters: + * + * - the kernel treats VM_IO | VM_PFNMAP as VM_SPECIAL, documented in + * include/linux/mm.h as "Special vmas that are non-mergable, + * non-mlock()able". mmap_region() therefore clears VM_LOCKED from + * this VMA and leaves mm->locked_vm alone, and __mm_populate() + * skips it outright ("if (vma->vm_flags & (VM_IO | VM_PFNMAP)) + * continue;" in mm/gup.c). + * + * - so a process that has called mlockall(MCL_FUTURE) no longer has + * this range pre-faulted inside vm_mmap(). Every other mapping in + * that process keeps being locked and pre-faulted as before; only + * device memory, which is neither pageable nor swappable and gains + * nothing from being pre-faulted, is left out. + * + * - and the allocator's own remap_pfn_range(), a few microseconds + * later, therefore finds an empty range instead of one the kernel + * has just populated, so it no longer trips + * BUG_ON(!pte_none(ptep_get(pte))) in remap_pte_range(). + */ +#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 3, 0) + vm_flags_set(vma, VM_IO | VM_PFNMAP); +#else + vma->vm_flags |= VM_IO | VM_PFNMAP; +#endif + return 0; } The upstream driver uses a different mechanism which bypasses this issue. Other galcore allocators use the same pattern (calling vm_mmap to get a vma) and thus are likely succeptible to the same BUG(). Could you please look into this and fix the galcore driver? This issue prevents a real use case from working properly, and is affecting our customer directly. Thank you, Rafael Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() Hi @rbeims  Let me run the test and then check with the GPU team. Best Regards, Zhiming

TJA1445 休眠时CANH和CANL为低电平 Hi,     测试TJA1445进入Sleep模式时，唤醒源模式为WUF，VBATVCC默认为0，CPNC配置为1，PNCOK配置为1，为什么进入Sleep模式后，CANH和CANL为低电平0v，不是2.5V，此时CAN state是CAN Offline吗？如何配置可以当TJA1445进入Sleep后，CANH和CANL为2.5V，因为当前环境测试下来，CAN唤醒时，只发一帧CAN报文，是无法唤醒TJA1445的， liugaosong_0-1788782128664.pngliugaosong_0-1788782128664.pngliugaosong_0-1788782128664.png CH1是INH引脚，CH2是CANH，可以看到休眠是低电平。 Re: TJA1445 休眠时CANH和CANL为低电平 如果在掉电前设置好PN相关的寄存器，是可以关掉VCC/VIO，只保留BAT的。  然后总线上如果有满足WUP的报文，可以从CAN Offline进入CAN OfflinBias。再收到符合WUF的报文就可以PN唤醒了， WUP报文的要求正常一般报文都能满足，相当于连续发两帧特定帧报文就能唤醒     Re: TJA1445 休眠时CANH和CANL为低电平 Hi, 板子休眠，VCC是关了的，TJA1445做不到一帧唤醒吗？必须要要经过从CAN Offline进入CAN OfflinBias吗？这时候CANH和CANL能不能是2.5V，还是说TJA1445进入Sleep模式，CAN状态一定是在CAN Offline模式。

U盘 目前市面上最好的U盘是哪一款？ ＃＃ 请告诉我 Re: Flash Drives 你好@ reedjhn9 我不太明白你的问题。您能否更详细地描述一下——具体来说，您正在使用的产品以及您想了解的具体问题？