Compile & Deployment DeepLabV3 with Ara Model Zoo v1.0.0   Compile & Deployment DeepLabV3 with Ara Model Zoo v1.0.0

仅可使用钥匙扣/智能卡登录 我在一家制造公司工作，我们正在考虑在车间配备个人电脑，以便员工能够查看零件图纸、确认任务完成情况等等。由于我们希望尽可能减少员工的痛苦，但又要记录谁签署了任务，因此我们正在寻找最佳方式，让员工使用他们已有的门禁卡来开门和打卡。如果这不可行，我们当然愿意考虑其他方案，让员工可以使用某种物理令牌登录，而无需接触键盘或鼠标，更不用说记住用户名和密码了。我研究过智能卡，但它们似乎需要输入密码，而我们希望尽可能避免使用密码。我们了解其中固有的网络安全风险，这些设备将被锁定，只能执行特定任务，而不能访问网络的其他部分。 移动设备上的智能卡

キーフォブ/スマートカードでのみログインできます 私は製造会社で働いており、従業員が部品図面を見たり、タスク完了のサインをしたりできるように、工場の現場にPCを設置しようと考えています。できるだけ手間を軽くしつつ、誰がタスクにサインしたかの記録も残したいため、従業員がすでに持っているアクセスコントロールバッジを使ってドアへのアクセスや出退勤をする最適な方法を検討しています。もしそれが現実的でなければ、従業員が物理的なトークンでログインし、キーボードやマウスに触れることなく、ユーザー名やパスワードを覚える必要もない、他の選択肢も検討しています。スマートカードについて調べてみましたが、PINコードが必要なようで、できれば避けたいと思っています。私たちは固有のセキュリティリスクを理解しており、これらのデバイスは特定のタスクしか実行できず、ネットワークの他の部分にアクセスできないようにロックダウンされます。 モバイルのスマートカード

Login with keyfob/smartcard only I work in a manufacturing company and we're looking at putting PCs out on the shop floor for employees to be able to do things like look at parts drawings, sign off that tasks are completed etc. As we want this to be as painless as possible but still have a record of who is signing off on the tasks, we are looking at the best way for the employees to use the access control badges they already have for accessing doors and clocking in and out. If that's not feasible we're certainly open to other options that would allow the employees to log in with some kind of physical token and never have to touch a keyboard or mouse let alone remember user names and passwords. I've looked into smart cards, but it appears that they require a PIN which we want to avoid if at all possible. We understand the inherant security risks and these devices would be locked down to only be able to do specific tasks and not have access to another parts of the network. Smart Cards on Mobile

LEARNING I am new to NXP S32K144. What is the recommended development environment for a beginner, and what should I learn first? Re: LEARNING Hello @JASAMANG , For a beginner, I recommend using S32 Design Studio for S32 Platform together with an S32K144 evaluation board. In addition to the IDE, please install the S32K1 Real-Time Drivers (RTD) package. For the current development flow, the recommended combination is S32 Design Studio v3.6.0 with S32K1 RTD 3.0.0. The RTD package can be installed through Help > S32DS Extensions and Updates. I suggest following this learning path: Import and run an existing S32K144 RTD example, such as a blinking LED or GPIO example. Learn the basic project structure, build process, flashing, and debugging. Become familiar with the S32 Configuration Tools, particularly pin, clock, and peripheral configuration. Continue with GPIO, interrupts, timers, PWM, and ADC. Once these fundamentals are clear, proceed to motor-control examples and tools such as FreeMASTER and MCAT. Starting from an existing example is generally easier than creating the complete application from scratch. For RTD installation guidance, please refer to the S32K1 RTD offline installation guide. Although the article demonstrates an older S32DS/RTD combination, it explains the package dependencies and the general offline installation flow. Always verify the required S32DS version and dependent packages in the release notes of the RTD version you download. You may also find this discussion useful: Install SDK/RTD into S32 Design Studio. It explains the difference between the legacy SDK and RTD and provides links to both AUTOSAR and non-AUTOSAR blinking LED examples You may also find useful examples and technical articles in the S32K Knowledge Base.  If you encounter a problem, I recommend searching the S32K Community forum first. Many common questions and issues have already been discussed and answered there.  Also, please create a dedicated thread if you encounter a specific issue. This helps keep us the discussions clear and makes it easier for other users to find relevant information.   We actively monitor threads for seven days after the last reply. After that period,  we only receive subscription emails for updates and those can occasionally be missed. For any related questions after this period, please create a new thread and refer to the original one.   If a response answers your question, please click “Accept as Solution.” For any related questions please create a new thread and refer to the original one.   Best regards, Pavel

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

PIC CLBのユーレカ 特定のPIC MCU(例:pic16f13145ファミリ)には、Configurable Logic Blockと呼ばれるFPGA風のプログラム可能なロジックがあります。 私が使用しているpic16f13115は、それぞれ4入力ルックアップテーブルとDフリップフロップを備えた32個のセルで構成されています。 ツールの使い方を学ぶために、今日はPWM明るさ制御付き6つのLEDのチャーリープレックス対応を実装し、シミュレーションしました。ロジックCADキャンバスを使用する代わりに、Verilogを使用して回路を定義しました。 私は時間の半分くらいを壁に頭を打ち付けて過ごしていた。少しずつ、Verilogを正しく記述し、合成（ビルド）を行い、そしてシミュレーションを実行できるようにした。 CLBでプログラムされたロジックがCPUがスリープ状態でも動作するのは素晴らしい。セーフティに関わるアプリケーションに最適です。例えば、複雑な割り込みトリガーロジックの実装に利用できます。CLBロジックをペリフェラルに接続する際の柔軟性は非常に高いです。これは、PICの定番となっている、扱いにくいCLCプログラマブルロジックよりもはるかに柔軟性が高い。 私のEureka体験を共有したかっただけです。 パワー

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

S32K3X8EVB-Q289HWUMのオープンボードデバッガを用いた外部MCU(S32K358)のプログラミング こんにちは、 外部MCU S32K358を、S32K3X8EVB-Q289HWUMボードのオンボードデバッガと20ピンのCortex Debug D ETMコネクタに接続し、J55ケーブルケーブルを使ってプログラムしようとしています。しかし、エラーが発生します。コントローラーをうまくプログラムするために実際に何をすればいいのか教えてください。 Yash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpeg CMD>VC オブジェクトファイルのCRC-16をデバイス範囲と照合しています... ブロック 00400000-0042F4B7 ... 計算されたCRC-16がブロックと一致しません。(ファイル = $A9EE、デバイス = $EDEF) デバイスのフラッシュメモリの検証エラー Flashプログラミング中にエラーが発生しました。 情報: DAP IDCODE = 0x6BA02477 情報：DAPの電源投入に成功しました。DP CTRL/STAT = 0xF0000000 リセットスクリプトを開始します (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac)... REM MC_MEモジュールで選択したコアのクロックを有効にする 200ミリ秒遅延します... 終わり。 REM RAMとDMAを初期化します。 REM DMA TCD の初期化: REM 使用する各コアに対して、有効な実行可能コードをRAMにコピーします。 REM MC_ME で必要なコアを有効にする: 20ミリ秒遅延します... 終わり。 20ミリ秒遅延します... 終わり。 リセットスクリプト (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac)完了しました。 PEmicro GDB 起動失敗: フラッシュプログラミング中にエラーが発生しました。デバッグセッションを終了します。 PEエラー：デバイスへのダウンロード中にエラーが発生しました。デバッグセッションを終了します。 127.0.0.1 経由で「127.0.0.1」から切断されました。ポート「53100」による6224からの切断 PEエラー: エラー: 応答を送信しようとしましたが、接続が既に閉じられています。 127.0.0.1 経由で「127.0.0.1」から切断されました。ポート「53104」による7224からの切断 情報: DAP IDCODE = 0x6BA02477 ターゲットとの接続が切断されました。 よろしくお願いいたします。 ヤシュ・グプタ Re: Programming External MCU (S32K358) using open board debugger of S32K3X8EVB-Q289HWUM ハイ まず第一に、オンボードデバッガーの使用はお勧めしません。S32K3X8EVBのオンボードデバッガは、評価ボード上でMCUのプログラミングとデバッグを行うために設計されています。このデバッガを使って外部カスタムS32K358ボードをプログラムまたはデバッグすることは、PEmicroによる公式推奨のユースケースではありません。したがって、NXPはこの構成での適切な動作を保証することはできません。 オンボードデバッガに関する制限事項については、以前に「 S32K142-Q48のプログラム/デバッグに関する問題」という議論の中で言及しました。PEmicroがS32K3オンボードデバッガの制限を変更したかどうかは把握していません。 たとえPEmicroにそのような制限がなくても、オンボードS32K358がデバッグャインターフェース回路を通じて電源供給されていないか(オンボードVDD_HV_A、VDD_HV_B、V11などを測定して確認)、またはJTAG_TCLK/SWD_CLKラインがオンボードS32K358から切り離されているかを必ず確認してください。 さらに、オンボードのデバッガインターフェースの信号電圧がカスタムボードの電圧と一致しているかも確認する必要があります。 よろしくお願いいたします ロビン

使用 S32K3X8EVB-Q289HWUM 的开放式板调试器对外部 MCU (S32K358) 进行编程 你好， 我正在尝试使用连接到 20 针 Cortex Debug D ETM 连接器的 S32K3X8EVB-Q289HWUM 板的板载调试器，以及 J55 电缆，对我的外部 MCU S32K358 进行编程。但我遇到了错误。请告诉我我究竟需要做些什么才能成功对我的控制器进行编程。 Yash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpeg CMD>VC 正在验证目标文件 CRC-16 校验值是否与设备范围匹配…… 区块 00400000-0042F4B7 ... 计算出的 CRC-16 值与数据块不匹配。（文件 = $A9EE，设备 = $EDEF） 验证设备闪存时出错 Flash编程过程中发生错误。 信息：DAP IDCODE = 0x6BA02477 信息：DAP 已成功启动。DP CTRL/STAT = 0xF0000000 启动 RESET 脚本 (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac)... REM 启用 MC_ME 模块中选定内核的时钟 延迟200毫秒…… 完毕。 REM 初始化 RAM 和 DMA： REM 初始化 DMA TCD： REM 将有效的可执行代码复制到每个要使用的核心的 RAM 中。 REM 启用 MC_ME 中所需的内核： 延迟20毫秒…… 完毕。 延迟20毫秒…… 完毕。 重置脚本 (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac)完全的。 PEmicro GDB 启动失败：闪存编程期间出错。调试会话结束。 PE错误：下载到设备时出错。调试会话结束。 通过 127.0.0.1 与“127.0.0.1”断开连接。通过端口“53100”与6224断开连接 PE-ERROR：错误：尝试发送响应，但连接已关闭。 通过 127.0.0.1 与“127.0.0.1”断开连接。通过端口“53104”与7224断开连接 信息：DAP IDCODE = 0x6BA02477 目标设备已断开连接。 问候， 亚什·古普塔 Re: Programming External MCU (S32K358) using open board debugger of S32K3X8EVB-Q289HWUM HI 首先，我不建议使用板载调试器。S32K3X8EVB 板载调试器设计用于在评估板上对 MCU 进行编程和调试。使用此调试器对外部定制的 S32K358 板进行编程或调试并非 PEmicro 官方推荐的使用场景；因此，NXP 无法保证在此配置下正常运行。 关于板载调试器的局限性，之前在“ S32K142-Q48 的程序/调试问题”讨论中已经提到过。我不知道 PEmicro 是否更改了 S32K3 板载调试器的限制。 即使 PEmicro 没有此类限制，您仍然必须确保板载 S32K358 没有通过调试器接口电路供电（通过测量板载 VDD_HV_A、VDD_HV_B、V11 等进行验证），或者 JTAG_TCLK/SWD_CLK 线已与板载 S32K358 断开。 此外，您还需要验证板载调试器接口的信号电压是否与您的定制板上的电压相匹配。 此致敬礼， Robin

在调用 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团队确认。 此致， 志明

S32 Design Studio for Power Architecture 版本 2.1激活码即将开始 您好，我的产品为S32 Design Studio for Power Architecture Version 2.1，激活码B9B6-A787-E3B4-585C即将于9.28日继续，请帮我续期或允许重新申请

S32 Design Studio for Power Architecture Version 2.1激活码即将到期 您好，我的产品为S32 Design Studio for Power Architecture Version 2.1，激活码 B9B6-A787-E3B4-585C 即将于9.28日到期，请帮我续期或允许重新申请

Programming External MCU (S32K358) using open board debugger of S32K3X8EVB-Q289HWUM Hello,  I am trying to program my external MCU S32K358 using an onboard debugger of S32K3X8EVB-Q289HWUM board connected at 20-pin Cortex Debug D ETM connector, along with cable J55 cable. But I get errors. Please let me know what I actually need to do to successfully program my controller. Yash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpegYash2530_0-1789183591258.jpeg CMD>VC Verifying object file CRC-16 to device ranges ... block 00400000-0042F4B7 ... Calculated CRC-16 does not match block. (File = $A9EE, Device = $EDEF) Error verifying flash of device Error occured during Flash programming. INFO: DAP IDCODE = 0x6BA02477 INFO: DAP successfully powered up. DP CTRL/STAT = 0xF0000000 Starting reset script (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac) ... REM Enable clocks for selected cores in MC_ME module Delaying for 200mS ... Done. REM Initialize RAM and DMA: REM Initialize DMA TCD: REM Copy valid executable code to RAM for each core to be used. REM Enable required cores in MC_ME: Delaying for 20mS ... Done. Delaying for 20mS ... Done. Reset script (C:\NXP\S32DS.3.6.7\eclipse\plugins\com.pemicro.debug.gdbjtag.pne_6.1.8.202603121731\supportFiles_ARM\NXP\S32K3xx\S32K358.mac) completed. PEmicro GDB Launch Failure : Error during flash programming. Terminating debug session. PE-ERROR: Error downloading to the device. Terminating debug session. Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "53100" from 6224 PE-ERROR: Error : Attempted to send response but connection already closed. Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "53104" from 7224 INFO: DAP IDCODE = 0x6BA02477 Target Disconnected. Regards, Yash Gupta Re: Programming External MCU (S32K358) using open board debugger of S32K3X8EVB-Q289HWUM Hi First of all, I do not recommend using the onboard debugger. The onboard debugger on the S32K3X8EVB is designed for programming and debugging the MCU on the evaluation board itself. Using this debugger to program or debug an external custom S32K358 board is not an officially recommended use case by PEmicro; therefore, NXP cannot guarantee proper operation in this configuration. Limitations regarding the onboard debugger were previously mentioned in the "Program/Debug issue with S32K142-Q48" discussion. I am not aware if PEmicro has changed the limitations for the S32K3 onboard debugger. Even if there are no such limitations from PEmicro, you must still ensure that the onboard S32K358 is not being powered through the debugger interface circuitry (verify by measuring onboard VDD_HV_A, VDD_HV_B, V11, etc.) or that the JTAG_TCLK/SWD_CLK lines are disconnected from the onboard S32K358. Additionally, you need to verify that the signal voltage of the onboard debugger interface matches the voltage on your custom board. Best Regards, Robin

S32 Design Studio for Power Architecture バージョン 2.1激活码即将到期 您好,我的产品为S32 Design Studio for Power Architecture Version 2.1,激活码 B9B6-A787-E3B4-585C 即将于9.28日到期,请帮我续期或允许重新申请

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?

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

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チームに確認させてください。 よろしくお願いします、 志明

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関連のサポートについては、この公開コミュニティではなくサポートチケットを使用してください。 よろしくお願いいたします。 ダニエル

i.MX RT1170 は、スペクトラム拡散クロックを有効にした後、起動に失敗しました。 MCUXpressoを使用してRT1170 EVKでSSCを有効にしようとしています。 参照番号：AN12879 手順： 1. ベースプロジェクト:SDKの例evkmimxrt1170_semc_cm7 2. IDEを使ってSSCを設定する IDE_Clocking.pngIDE_Clocking.png source_diff.pngsource_diff.png 3. 起動に失敗しました Boot_Failed.pngBoot_Failed.png 4. 時々正常に起動できる(~ 1/50) 何か手順を飛ばしてしまったでしょうか？ よろしくお願いします。 見た Re: i.MX RT1170 Failed to boot after Spread Spectrum Clocking is enabled ここで行われた変更点を、単にデモコードを投稿するだけでなく詳しく教えてもらえますか?この投稿から3年経った今、私がこの元の投稿で詳述したのと同じ問題を抱えている状況では、何が必要なのかを判断するのは難しい。 よろしくお願いします。 Re: i.MX RT1170 Failed to boot after Spread Spectrum Clocking is enabled こんにちは、 @SeenFan さん。 SDRAMはDCDと起動ROMで初期化できます。その後、起動ROMがアプリケーションコードをSDRAMにコピーします。一番重要なのはキャッシュの問題だと思います。こちらのリンクを参照してください。 https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/How-to-move-CM4-core-project-to-SDRAM-in-RT1176/ta-p/1363185 2. SDRAMでのデバッグ https://community.nxp.com/t5/MCUXpresso-IDE/Running-and-debugging-program-in-SDRAM/mp/1405167 3. i.MXRTでキャッシュされていないメモリを使用する https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/Using-NonCached-Memory-on-i-MXRT/ta-p/1183369 よろしくお願いいたします。 ジン Re: i.MX RT1170 Failed to boot after Spread Spectrum Clocking is enabled こんにちは、ジンさん SDRAM上のプログラムを検索して実行したい場合。 注意すべき点は何ですか？ よろしくお願いします。 見た Re: i.MX RT1170 Failed to boot after Spread Spectrum Clocking is enabled こんにちは、ジンさん それは動作します。どうもありがとう。 よろしくお願いします。 見た Re: i.MX RT1170 Failed to boot after Spread Spectrum Clocking is enabled こんにちは、 @SeenFan さん。 これは、RT1170 FlexSPIがデフォルト設定時にクロックソースとしてPLL2を使用するためです。PLL2の周波数を変更すると、FlexSPIが次の命令を取得できなくなる場合があります。これを解決するには、fsl_clock.cをSRAMに変換できます。私のデモコードを参照してください。 よろしくお願いいたします。 ジン