PN7150/NCI: Unable to update MIFARE Classic 1K Sector Trailer with Custom Embedded Key B Hello NXP Community, I am working with a MIFARE Classic 1K card and an NXP PN7150 NFC controller running over the standard NCI protocol layer. I am trying to implement a provisioning feature where I write a custom secret password into Key B of a target sector (Sector 7), but the card chip consistently rejects the write command. Here is the exact state of my card and the implementation details: Current Sector 7 State: The sector is currently blank/unformatted. A read dump shows it is in the factory default state with access bits FF078069 and both Key A and Key B set to 0xFFFFFFFFFFFF. The Goal: I want to keep Key A as the read key, preserve the open access bit layout, and overwrite Key B with a personal custom key payload (0x01 0x02 0x03 0x04 0x05 0x06). The Issue: When I attempt to write the 16-byte raw block layout string (FFFFFFFFFFFFFF078069010203040506) to Block 3 (Sector 7 Trailer), the write transaction fails. Note: i did the card NDEF format with an App and access bytes are showing 7F078840 Any guidance would be greatly appreciated!   Kind Regards   Re: PN7150/NCI: Unable to update MIFARE Classic 1K Sector Trailer with Custom Embedded Key B Hello @Saqib1 Hope you are doing well. Please consider that PN7150 is Not Recommended for New Designs; we recommend using PN7160 instead. Additionally, MIFARE Classic is also Not Recommended for New Designs; MIFARE DESFire Light can be considered. Before sending the write command make sure the authentication with Key A (FFFFFFFFFFFFh) on block 1Fh (Sector 7 trailer) is performed successfully. Now, after authentication on block 1Fh, please verify that the write command is being sent following the procedure described in the MIFARE Classic EV1 1K datasheet, section 12.3. The WRITE operation consists of two parts that must be sent sequentially: Part 1: Send the command byte and block address, including CRC: A0 + XX +CRC where XX is the block address (e.g., 1Fh for the Sector 7 Trailer). The card must respond with ACK before proceeding. Part 2: Only after receiving the ACK, send the 16 bytes of data including CRC: [16 bytes payload] + CRC. The card will respond with a final ACK to confirm the write was accepted. Regards, Eduardo.

PCF2123TS-1,118の外観バリエーションに関するお問い合わせ NXPチーム様：PCF2123TS-1,118チップ2リールの入荷検査中に、2種類の異なる外観タイプを発見しました。タイプ1：表面が光沢があり、ピン1のインジケータが小さく、側面のテクスチャは光沢があり、わずかに湾曲しています。タイプ2：表面が粗く、ピン1のインジケータが大きく、側面のテクスチャは粗く、直線的です。これらの違いは正常な状態でしょうか？ご回答をお待ちしております。よろしくお願いいたします。劉

T1042 DDR4 初始化失败 我有一个使用64位接口连接DDR4内存的T1042设计。我们已经发现接口最高字节中存在半字节间位交换错误的问题，我们知道这个问题无法通过软件设置进行补偿。我们将在PWB版本中实施修复。然而，由于其余位均正确，且交换操作符合参考手册的允许范围，我们希望改为以 32 位模式运行，以便我们仍能继续启动软件和完成设计的其余部分。我尝试使用QCVS DDR验证工具，但是内存无法初始化。我已经输入了设备的参数，并确保按照我的设计设置了DQ[0:31]的DQ映射值，但是ERR_DETECT寄存器中的ACE位仍然是1。处理器通过SPI接口接收RCW信号，DDR频率设置为800MHz。是否可以使用CodeWarrior/QCVS来验证它是否接收到了正确的RCW值？还有哪些其他设置可能导致32位模式工作无法正常工作？任何支持我都将不胜感激。谢谢。 QorIQ T1 设备 Re: T1042 DDR4 Initialization Failure 是否可以使用 CodeWarrior/QCVS 来验证它是否接收到了正确的 RCW 值？ [A] 是的，这是可能的，您可以连接 CCS，并读取DCFG_CCSR_RCWSR1-DCFG_CCSR_RCWSR16 与 SPI 闪存中的 RCW 进行比较。 还有哪些其他设置可能导致 32 位模式工作不正常？ [A]它是独立DDR4吗？一般规则请参考QCVS_DDR_User_Guide 。 硬件设计请参考…… AN5097，DDR4 同步动态随机存取存储器(SDRAM) 内存接口的硬件和布局设计考虑因素 谢谢！ Re: T1042 DDR4 Initialization Failure 你好，六月， 谢谢回复。我使用 CCS 读取了 RCW 状态寄存器，并确认 RCW 已按预期编程。 我使用的是独立DDR4内存，并且已经仔细阅读了用户指南和布局注意事项。 我已经确认我们有一个 650MHz 的时钟，可以以 1300MT/s 的速率运行，以满足勘误表 A-007864 中关于使用 32 位接口的要求。一位同事建议检查一下片选信号是否在切换。我发现，一旦QCVS工具开始向处理器发送配置信息，CS0信号就会被保持在足够低的水平。编程完成后，当尝试运行验证程序时，CS0信号不再完全钳位。我独立使用JTAG边界扫描工具确认信号连接正常，并且T1042 I/O能够将网络驱动到足够低的电平，以满足DDR4内存器件的VIL要求。我还确认了网络布线良好，信号完整性正常，并且没有与其他任何东西短路。似乎是内存控制器配置存在问题，导致片选信号无法正常工作。还有其他想法吗？谢谢。 Re: T1042 DDR4 Initialization Failure 没错，我指的是 D1_MCS0_B。 当我运行命令时 （bin）% ccs::reset_to_debug 我收到一条消息，提示“找不到库”。 Re: T1042 DDR4 Initialization Failure 请问您描述中的 CS0 是否指的是 D1_MCS0_B？ 请在您的 ccs 系统中运行该命令并更新完整的 ccs 日志。 （bin）% ccs::reset_to_debug 谢谢！ Re: T1042 DDR4 Initialization Failure 内存控制器现在设置为以 650MHz 或 1300MT/s 的频率运行。结果相同。我们尝试将DDR4内存设置为32位模式，因为64位接口的第8字节出现了意外的位交换（半字节之间的错误交换）。该设计原本计划采用 64 位 + ECC 编码，但目前我们尝试暂时采用 32 位 + ECC 编码作为替代方案。这意味着我们目前连接了 5 个 16 位芯片，但希望只使用其中 3 个芯片进行操作。 我尝试了多种设置组合，但QCVS工具的行为似乎没有任何改变。奇怪的是，我也尝试过使用GreenHills模拟器，其启动脚本中的值与QCVS类似，结果能够顺利通过DDR_SDRAM_CFG_2[D_INIT]清除的等待循环，这意味着初始化已经完成。然后，它在初始读写验证时失败，返回值全部为0x00，这很合理，因为它使用了次优的写入均衡值。我不明白为什么QCVS工具的行为会有所不同。 Re: T1042 DDR4 Initialization Failure 读取 RCW 状态寄存器后，请输入命令。 请将完整的 ccs 日志分享给我，而不是命令“ccs::reset_to_debug”的执行结果，例如： “我收到一条消息，提示‘找不到库’。” 完整日志从您使用 ccs 的第一个命令开始。 谢谢！ Re: T1042 DDR4 Initialization Failure 附件是一个 .txt 文件。采用RCW输出。我运行了您最后指定的命令“ccs::reset_to_debug”，它没有显示“找不到库”消息，但也没有显示任何其他信息。 我还对DDR配置寄存器进行了类似的捕获，并已附上。我没发现任何问题。事实上，这些值用GreenHills探针测试时似乎能够通过，D_INIT也会被清除；但是，当我用相同的值配合QCVS工具时，D_INIT却不会被清除。我不太清楚使用GH探针和CWTAP有什么区别。任何建议我都非常感激。 Re: T1042 DDR4 Initialization Failure ACE 错误是自动校准错误，当内存控制器在其训练序列中检测到错误时，就会设置该错误。如果将时钟频率从 800MHz 降低，训练结果会如何？ 同时，对于 64 位或 32 位总线宽度，DDR4 选择使用哪一种？计划将多少块 DDR4 连接到 T1042？ Re: T1042 DDR4 Initialization Failure “ccs::reset_to_debug” 工作正常。 请确认是否需要 errata_A009942 ，如果需要，请解压缩附件中的 hotfix Optimization.zip 文件，以覆盖 CodeWarrior PA 安装文件夹中现有的 Optimization 文件夹。解压缩后，C:\Freescale\CW_PA_v10.5.1\eclipse\Optimization\resources\QorIQ\DDR\templates\init\errata_A009942.py 文件将存在。 请确认以下一般指南： 创建一个新的 QCVS 项目 - 选择“自动配置”和“动态随机存取存储器(DRAM)” 动态随机存取存储器(DRAM) 速度等级 = 最大速度（例如，最大 3200 MT/s，请参阅数据手册）。 - “输出数据速率”选择“xxx MT/s”（当前工作速度，例如1300MT /s，此数据速率必须与 RCW 映像中配置的动态随机存取存储器(DRAM)速度相匹配） - “排名/芯片选择” 选择“x”                   (单 CS 或双 CS) - "tCL" 选择 "xx"（根据 动态随机存取存储器(DRAM) 数据手册中的速度分级表）   - "每个设备的动态随机存取存储器(DRAM) 配置" 选择“xx”    (参见 动态随机存取存储器(DRAM) 数据手册) - 填充正确的 CLK 到 QDS 偏移量（通过 EDA 工具测量 CLK 和 DQS 信号的长度，CLK 长度 - DQS 长度） CLK 时长减去 DQS 时长，例如： CLK 到 DRAM0 的长度 = 100 毫米 CLK 到 DRAM1 的长度 = 101 毫米 DQS[0] 长度 = 75 毫米 DQS[1] 长度 = 110 毫米 CLK 到 DQS[0] 的偏移量 = 100 毫米 - 75 毫米 = 25 毫米 CLK 到 DQS[1] 的偏移量 = 101 毫米 - 110 毫米 = -9 毫米 - CLK 走线长度必须等于或长于 DQS 走线长度，且相差不超过 10 英寸。 - 如果 MCK 走线长度短于 DQS 走线长度，则必须在 2.0 英寸以内。 DQ映射 - 控制器引脚： 如果您的实际电路板上使用了 DQ 位交换，则用户必须在 QCVS 中进行配置，以匹配实际的 PCB 布局。 TIMING_CFG_1_and_3： - tCL/tRCD/rRP/tRAS 此值参考 动态随机存取存储器(DRAM) 数据手册，以匹配当前工作速度速率。    - tWR（写入恢复时间，最后数据到预充电的最小间隔），此值参考 动态随机存取存储器(DRAM) 数据手册。        - tRRD（激活间隔）此值参考 动态随机存取存储器(DRAM) 数据手册。     TIMING_CFG_2： - tFAW（四激活窗口），此值参考 动态随机存取存储器(DRAM) 数据手册。 用户应确保板特定配置和动态随机存取存储器 (DRAM) 特定配置与实际硬件匹配。 对于其他大多数选项，请使用默认的 QCVS 预设值。 谢谢！ Re: T1042 DDR4 Initialization Failure 我目前正在与采购部门合作，办理保密协议，以便获取完整的勘误表文件。但是，我使用的是元器件 T1042NXE7MQB，Google/NXP 论坛搜索似乎表明勘误表 A009942 适用。 请提供您提到的“Optimization.zip”文件。我没看到它被附加在任何地方。 Re: T1042 DDR4 Initialization Failure 你好，六月， 感谢您提供文件并给予持续支持。我按照您的指南设置了QCVS DDRv工具，今天也尝试了勘误表#A009942中的解决方法，但似乎并没有什么效果。我查看了脚本本身，发现它似乎只针对667MHz和800MHz这两个特定频率应用了这种变通方案。由于勘误表 #007864 指出，当内存宽度为 32 位或更低时，如果以 800MHz 的频率运行，DDR 接口可能会出现问题，因此我目前将内存运行频率设为 650MHz。650MHz频率下是否需要设置某个调试寄存器值？ 该设计采用单个 100MHz 时钟源，因此我可选的 DDR 内存频率似乎只有 650MHz、700MHz、750MHz 和 800MHz（DDR4）。对于 32 位模式，我是否应该使用 650MHz 以外的其他频率？ 我仍然对DQ映射值持怀疑态度。几个月前，您在另一篇帖子中帮我验证了这些值： T1042 DDR4 DQ MAP 寄存器设置 这是该设计与我们网站上另一个正在运行的T1042 DDR4实例之间的一个显著区别。他们使用了64位架构，只在最高有效字节上进行了少量位交换。我们的64位接口的最高有效位（MSB）存在已知的错误位交换，因此我们尝试使用32位模式作为临时解决方案。我们的交换操作比工作设计要多得多，包括字节通道内的完整半字节交换，但是接口的32位最低有效位似乎遵循T1042控制器允许的规则。已知不同的DQ映射交换组合均可正常工作吗？您能再看一下我们用来验证的数值吗？为方便起见，已包含寄存器值和原理图截图。DDR4 设备的另一端是直接的 1:1 映射，因此为了清晰起见，交换只出现在 T1042 端。 再次感谢大家一直以来的支持。 Re: T1042 DDR4 Initialization Failure 抱歉，我漏看了附件。 Re: T1042 DDR4 Initialization Failure @dbevans42 脚本中应应用 650 MHz 的 A-009942，您可以添加一行与 667 相同的代码来包含它。 请提供DDR器件的部件原理图，以便确认DQ映射关系。 如果 DQ 映射与 MAP 相交，我们有一种调试模式，这是一种临时解决方案，直到您修复电路板为止。 将数据速率设置为 1200MT/s 设置 DDR_SDRAM_CFG_2[DDR_SLOW] = 1 将偏移量 0x8F04[27] 处的 DDR 寄存器设置为 1，或者将值 0x10 写入偏移量 0x8F04。 清除所有DDR_DQ_MAPn寄存器 谢谢！ Re: T1042 DDR4 Initialization Failure 不确定DDR4是否支持64位总线宽度。您指的是LPDDR4吗？ Re: T1042 DDR4 Initialization Failure 它是DDR4内存。这是一个分立式设计，不是 DIMM，所以我们有五个 1G x 16 位设备（64 位 + 8 位 ECC）。 Re: T1042 DDR4 Initialization Failure 我在9月24日星期四发给你的最后一封邮件中附上了DQ[0:31]和ECC的相关原理图截图。我再次附上整个 64 位接口的快照，并突出显示了错误的位交换。 感谢您提供的其他解决方法。 问题： 1）如果我在A009942脚本中添加 650MHz，应该写入什么值？它应该和 667MHz 一样吗？ 2) 您列出的新的1200MT/s变通方案是否旨在使 64 位模式即使在交换错误的情况下也能工作，还是我们需要继续尝试 32 位模式？ 3）是否可以使用DDRv工具来实现此解决方法？否则，我将在我们的 GreenHills 探测启动脚本中尝试一下，并将结果汇报给我们。 Re: T1042 DDR4 Initialization Failure 你好，六月， 我已将您列出的解决方法应用到我们的 GreenHills 探针启动脚本中，目前看来 DDR4 接口已正常工作。我们可以将代码加载到DDR4内存中并开始执行，我可以使用GH探针内存视图看到DDR4内存中已初始化的数据值。剧本已附上，供审阅。 问题： 1）能否提供更多关于调试模式的详细信息？ 2）调试模式的解决方法是否只能在 1200MT/s 的速度下运行，还是可以运行得更快？ 3）DQ映射寄存器的功能是否存在缺陷？我需要确保 DQ 映射寄存器确实像宣传的那样工作，并且如果我在新版本中修复了错误的 DQ57 和 DQ63 互换，它仍然可以在没有调试模式的情况下工作。 4）32位模式是否存在漏洞/问题？32 位模式在没有调试变通方法的情况下无法工作，这说不通，因为我们遵循了这些位的映射规则。 5) 是否有办法运行变通调试模式并使用 QCVS DDRv 工具来获取正确的写入电平值？

KW47-EVKボードのBluetoothチャンネルサウンディング例はどこにありますか? daughterカード(KW47-001-M10)を搭載したKW47-EVKボードのBluetoothチャンネルサウンディング例はどこにありますか? https://github.com/nxp-mcuxpresso/ のリポジトリを調べましたが、KW47-EVKボードの具体的な例は見つかりませんでした。また、FRDM-MCXW72FRDM-MCXW72のチャネルサウンディングの例も見つけました:実践形式 8: チャネルサウンディング FRDMから電話への対応。   NXP AIのヘルプも利用してみましたが、存在しないリンクが表示されました。 私はEclipseベースのMCUXpressoと、d8terカード(KW47-001-M10)のKW47-EVKボード用SDKをインストールしています。 前もって感謝します！--ポール

T1042 DDR4 Initialization Failure I have a T1042 design using 64-bit interface to DDR4.  We already found an issue with an improper bit swap between nibbles in the uppermost byte of the interface which we know cannot be compensated for in SW settings.  We are going to implement a fix in a PWB revision.  However since the rest of the bits are correct and the swapping falls into what is allowed according to the reference manual we are hoping to instead operate in 32-bit mode so that we can still proceed bringing up SW and the rest of the design.  I have tried this using QCVS DDR validation tool, however I cannot get the memory to initialize.  I have input the parameters of the device and made sure to set the DQ mapping values according to my design for DQ[0:31] however I continue to get bit ACE= 1 in the ERR_DETECT register.  The processor is getting the RCW via SPI interface and the DDR frequency is set to 800MHz.  Is there a way to use CodeWarrior/QCVS to verify it received the correct RCW value?  What are some other settings to consider for 32-bit mode operation that could explain why it is not working?  I would greatly appreciate any support.  Thank you. QorIQ T1 Devices Re: T1042 DDR4 Initialization Failure   Is there a way to use CodeWarrior/QCVS to verify it received the correct RCW value?  [A] Yes, that's possible, you could connect the CCS, and read out the DCFG_CCSR_RCWSR1-DCFG_CCSR_RCWSR16 to compare with the RCW in the SPI flash. What are some other settings to consider for 32-bit mode operation that could explain why it is not working? [A]Is it discrete DDR4? For the generally rule, please refer to  QCVS_DDR_User_Guide. For the HW design, please refer to the AN5097, Hardware and Layout Design Considerations for DDR4 SDRAM Memory Interfaces Thanks Re: T1042 DDR4 Initialization Failure Hello June, Thanks for the reply.  I was able to use CCS to read the RCW status registers and confirm the RCW is programmed as expected. I am using discrete DDR4 and have been through the user guide and layout considerations. I have confirmed that we have a 650MHz clock for operation at 1300MT/s to satisfy Errata A-007864 for using a 32-bit interface.  A colleague suggested checking that the chip select is toggling.  I found that once the QCVS tool starts sending the configuration to the processor, the CS0 signal is held sufficiently low.  After programming is complete and it attempts to run the validation routine the CS0 signal is no longer being fully asserted.  I independently using a JTAG boundary scan tool to confirm that the signal is connected as expected and that the T1042 I/O can drive the net low enough to satisfy the VIL for the DDR4 memory device.  I also confirmed the net looks good in terms of routing for signal integrity and that it is not shorted to anything.  It seems that there is something about the memory controller configuration that is not allowing the chip select signal to function correctly.  Any other ideas?  Thank you. Re: T1042 DDR4 Initialization Failure Could you please confirm whether the CS0 in your description refers to D1_MCS0_B? Please in your ccs run the command and update the full ccs log. (bin)  % ccs::reset_to_debug Thanks Re: T1042 DDR4 Initialization Failure Correct, I am referring to D1_MCS0_B. When I run command (bin)  % ccs::reset_to_debug I get a message that says "Library not found." Re: T1042 DDR4 Initialization Failure The memory controller is now set for 650MHz or 1300MT/s operation.  Same result.  We are attempting to use 32-bit mode for DDR4 because there is unintended bit swap on byte 8 of 64-bit interface (mistaken swap between nibbles).  The design was intended to be 64-bit + ECC but we are attempting to run 32-bit + ECC as a temporary  workaround.  That means that we currently have 5x 16-bit chips connected but are hoping to operate using only 3 of them. I've tried many combinations of settings but nothing seems to change behavior in QCVS tool.  What is a bit odd is that I have also tried using a GreenHills emulator with similar values to QCVS in its startup script and I get past the wait loop for DDR_SDRAM_CFG_2[D_INIT] to clear, implying initialization is completing.  Then it fails on initial write/read verification with all 0x00 which makes sense since it is using suboptimal write leveling values.  I do not understand why the QCVS tool has different behavior. Re: T1042 DDR4 Initialization Failure ACE error is automatic calibration error which is set if the memory controller detects an error during its training sequence. So if you lower the clock speed from 800MHz, how about the training result? Meanwhile for 64bit or 32bit bus width, which one is selected to use for DDR4? how many pcs DDR4 is planed to connect to T1042 Re: T1042 DDR4 Initialization Failure Attached is a .txt with the RCW output.  I ran the command you specified "ccs::reset_to_debug" at the end and it did not give the "library not found" message, but it did not display any other info. I have also done a similar capture for the DDR config registers and attached that.  I cannot find anything wrong.  In fact these values used with GreenHills probe actually seem to pass and get D_INIT to clear, however D_INIT does not clear when I use the same values with QCVS tool.  I'm not sure what the difference is between using GH probe vs CWTAP.  I'd appreciate any ideas. Re: T1042 DDR4 Initialization Failure Please input the command after you read out the RCW status registers. Please share the full ccs log to me instead of the command " ccs::reset_to_debug" result, such as "I get a message that says "Library not found."" The full log start from the first command you use the ccs. Thanks Re: T1042 DDR4 Initialization Failure I am currently working with my procurement to get NDA in place so that I can get full errata documentation.  However, I am using component T1042NXE7MQB and Google/NXP forum search seems to suggest that errata A009942 applies. Can you please provide the referenced "Optimization.zip," I do not see it attached anywhere. Re: T1042 DDR4 Initialization Failure "ccs::reset_to_debug" work correctly. Please confirm if errata_A009942 is needed, if it's needed, please unzip the attached hotfix Optimization.zip to override existing Optimization folder within the CodeWarrior PA installation folder. there will be present C:\Freescale\CW_PA_v10.5.1\eclipse\Optimization\resources\QorIQ\DDR\templates\init\errata_A009942.py Confirm the general guide as below: creating a new QCVS project   - choose "Auto configuration" and "Discrete DRAM"   - DRAM Speed Rating = Max speed                  (e.g., max 3200 MT/s, see datasheet).        - "Output data rate" choose "xxx MT/s"           (Current working speed, e.g. 1300MT/s, this data rate must match the DRAM speed configured in RCW image)   - "Rank/Chip select" choose "x"                  (single CS or dual CS)   - "tCL" choose "xx"                              (according to speed bin table in DRAM data sheet)   - "DRAM configuration per device" choose "xx"    (see DRAM data sheet)   - fill the proper CLK-to-QDS skews               (measure lengths of CLK and DQS signals via EDA tool, CLK length - DQS length) CLK length minus DQS length, example: CLK-to-DRAM0 length = 100 mm CLK-to-DRAM1 length = 101 mm DQS[0] length = 75 mm DQS[1] length = 110 mm CLK-to-DQS[0] skew = 100 mm - 75 mm = 25 mm CLK-to-DQS[1] skew = 101 mm - 110 mm = -9 mm  - CLK trace length must be equal to or longer than DQS trace length within 10 inches. - If MCK trace length is shorter than DQS trace length, it must be within 2.0 inches. DQ mapping - Controller pins: If DQ bit swapping is used on your actual board, user must configure this in QCVS to match the actual PCB layout. TIMING_CFG_1_and_3:   - tCL/tRCD/rRP/tRAS  this value refers to DRAM datasheet to match the current working speed rate.      - tWR (Write Recovery Time, Last data to precharge minimum interval), this value refers to DRAM datasheet.          - tRRD(Activate-to-activate interval) this value refers to DRAM datasheet.     TIMING_CFG_2:   - tFAW(Four Activate Window), this value refers to DRAM datasheet. user should ensure those board-specific and DRAM-specific configurations match the actual hardware. for other most of options, use the default QCVS preset value. Thanks Re: T1042 DDR4 Initialization Failure Sorry miss the attachment. Re: T1042 DDR4 Initialization Failure Hello June, Thanks for providing the files and the continued support.  I followed your guidelines for QCVS DDRv tool set up and I tried out the errata #A009942 workaround today and it did not seem to make a difference.  I looked into the script itself and it only seems to be applying the workaround for specific frequencies of 667MHz and 800MHz.  I am currently running at 650MHz due to errata #007864 which claims there might be issues with the DDR interface when running at 800MHz for width 32-bit or less.  Is there a debug register value that needs to be set for 650MHz?  This design is using a single 100MHz clock source so my only options for DDR frequency appear to be 650MHz, 700MHz, 750MHz, and 800MHz for DDR4.  Should I be using a different frequency other than 650MHz for 32-bit mode? I am still suspicious of the DQ map values.  You actually helped me verify the values a few months ago in another post:  T1042 DDR4 DQ MAP Register Settings This is a noted difference between this design and the other instance of working T1042 DDR4 on our site.  They used 64-bit and only had minor bit swapping on the most significant byte.  We have a known bad bit swap on the MSB of our 64-bit interface which is why we are attempting 32-bit mode as workaround.  We have a lot more swapping than the working design including a full nibble swap within a byte lane, however the 32-bit LSBs of the interface appear to follow the rules for what is allowed by the T1042 controller.  Are different combinations of the DQ map swapping known to be working?  Can you take another look  at the values we are using to verify?  Register value and schematic captures included for convenience.  The other end at the DDR4 device is a direct 1:1 mapping, so the swapping appears only at the T1042 side for clarity. Thanks again for the continued support. Re: T1042 DDR4 Initialization Failure It is DDR4.  This is a discrete design, not DIMM, so we have five 1G x 16-bit devices (64-bit + 8-bit ECC). Re: T1042 DDR4 Initialization Failure Not sure DDR4 has 64BIT BUS WIDTH product. Do you mean LPDDR4? Re: T1042 DDR4 Initialization Failure @dbevans42  A-009942 at 650 MHz should be applied in the script, you could add one more line  same as 667 to include this. Please kindly share the DDR device part schematics to confirm the DQ mapping. If the DQ mapping cross the MAP, we have one debug mode, it is a temporary solution till you fix your board. set the data rate to 1200MT/s set DDR_SDRAM_CFG_2[DDR_SLOW] = 1 set DDR register at offset 0x8F04[27] = 1, or write a value of 0x10 to offset 0x8F04. clear all DDR_DQ_MAPn registers Thanks Re: T1042 DDR4 Initialization Failure Hello June, I was able to implement the workaround you listed within our GreenHills probe startup script and from what we can tell the DDR4 interface is now working.  We can load code into DDR4 and start executing and I am able to see the initialized data value in DDR4 using the GH probe memory view.  Script attached for review. Questions: 1) Can you provide more detail on the debug mode? 2) Does the debug mode workaround only function at 1200MT/s or can it be run faster? 3) Is there a bug in the function of the DQ map registers?  I need to be sure that the DQ map registers actually work as advertised and that if I fix the mistaken DQ57 and DQ63 swap in a new spin that it will still work without the debug mode. 4) Is there a bug/issue with 32-bit mode?  It does not make sense that 32-bit mode without debug workaround does not work since we follow the mapping rules for those bits. 5) Is there a way to run workaround debug mode and use QCVS DDRv tool to get correct write leveling values? Re: T1042 DDR4 Initialization Failure My last post to you on Thursday 9/24 I attached the relevant schematic screenshots for DQ[0:31] and ECC.  I'm including the snapshots again of the whole 64-bit interface with the erroneous bit swap highlighted. Thank you for the additional workaround.       Questions: 1) If I add 650MHz to the A009942 script what value should be written?  Should it be the same as 667MHz? 2) Is the new 1200MT/s workaround you listed meant to make 64-bit mode work even with the erroneous swap, or do we need to continue trying 32-bit mode? 3) Is there a way to do the workaround using the DDRv tool?  Otherwise I will try it within our GreenHills probe startup script and report back with results.

Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Hi, I'm validating the external active-tamper loop on the i.MX8DXL EVK (MCIMX8DXL-WEVK) via U-Boot. From the board schematic, I've confirmed J20 (TAMPER header, 1x3) is wired as: - Pin 1 = TAMPER_IN4 (net SNVS.TAMPER_IN4, ball AJ13) - Pin 2 = GND - Pin 3 = TAMPER_OUT0 (net SNVS.TAMPER_OUT0, ball AP22) These are dedicated SNVS pins, not shared with SAI2/SAI3 like TAMPER_OUT1-4/IN0-3. Available U-Boot commands: tamper_pin_cfg, snvs_cfg (with sub-registers hp.lock, hp.secvio_intcfg, hp.secvio_ctl, lp.lock, lp.secvio_ctl, lp.tamper_filt_cfg, lp.tamper_det_cfg, lp.tamper_det_cfg2, lp.tamper_filt1_cfg, lp.tamper_filt2_cfg, lp.act_tamper1_cfg through lp.act_tamper5_cfg, lp.act_tamper_ctl, lp.act_tamper_clk_ctl, lp.act_tamper_routing_ctl1, lp.act_tamper_routing_ctl2), snvs_sec_status, snvs_clear_status. Since TAMPER_OUT0/TAMPER_IN4 form an active tamper pair, my questions: 1. Which lp.act_tamperN_cfg channel (1-5) corresponds to TAMPER_OUT0? 2. What values for lp.act_tamper_routing_ctl1/routing_ctl2 route TAMPER_OUT0's pattern to be checked against TAMPER_IN4? 3. What value for lp.act_tamper_clk_ctl enables the pattern clock for this channel? 4. What value for lp.act_tamper_ctl globally enables active tamper detection for this channel? Goal: closing a jumper across J20 pins 1-3 should read as secure in snvs_sec_status, and opening it should trigger a violation. I've attempted several values on hardware (routing 4, 5, 10; various clock/detector settings) — all were either rejected by the SECO firmware (error res:9 / SC_ERR_PARM) or accepted with no observable change in snvs_sec_status's SNVS a4(1) (LPTDSR) register when physically toggling the loop. Is there a reference test procedure or app note for external active tamper validation on i.MX8DXL? Thanks! Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Hello, 1. lp.act_tamper1_cfg drives TAMPER_OUT0. 2. The i.MX8DXL SNVS has 5 Active Tamper (AT) output sources and up to 8 External Tamper (ET) input detectors. Please use this configuration: lp.act_tamper_routing_ctl1 = 0x00010000 # ET5 (TAMPER_IN4) to AT1 (TAMPER_OUT0) lp.act_tamper_routing_ctl2 = 0x00000000 # ET6-ET8 not used 3. That value changes the clock divider, use 0x00 for maximum frequency configuration. lp.act_tamper_clk_ctl = 0x00000000 4. Use lp.act_tamper_ctl = 0x00010001: Bit 0: AT1EN enable AT1 LFSR pattern generator Bit 16: AT1_OUT_EN drive TAMPER_OUT0 pad with AT1 pattern There is no application note available for this processor but you can use this from an i.MX7 that can be used as reference: /* Config ET5 (pin in et4) <-> (pin out et5) AT 1 * /* reset */ write32(0, &svregs->lp.act_tamper_clk_ctl); write32(0, &svregs->lp.act_tamper_ctl); write32(0, &svregs->lp.tamper_det_cfg); write32(0, &svregs->lp.tamper_det_cfg2) /* Deault value for LFSR */ write32(0x84000000 | 0x00001111, &svregs->lp.act_tamper1_cfg) /* Set the clock at max freq */ write32(0x00000000, &svregs->lp.act_tamper_clk_ctl); /* ET5 (pin et4) takes ref from AT1 (pin et5) */ write32(0x00010000, &svregs->lp.act_tamper_routing_ctl1); write32(0x0, &svregs->lp.act_tamper_routing_ctl2) /* activate out pad of AT1 and enable it, AT1 output on pin et5 */ write32(0x00010000 | 0x00000001, &svregs->lp.act_tamper_ctl) /* Configuring IRQs and secviols */ write32(0x8000003f, &svregs->hp.secvio_intcfg); write32(0x4000003f, &svregs->hp.secvio_ctl); write32(0x0000003f, &svregs->lp.secvio_ctl) /* Activating detector for ET5 */ write32(0x00000000, &svregs->lp.tamper_det_cfg); write32(0x00000004, &svregs->lp.tamper_det_cfg2); Best regards. Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) Thank you for the configuration. I applied it exactly on a fresh power cycle: snvs_dgo_cfg 0 0 20000000 0 80000000 0 snvs_cfg 0 8000003f 4000003f 0 3f 0 0 4 0 0 84001111 0 0 0 0 10001 0 10000 0 Readback matches your values: SNVS e8(2) = 00010000 00000000, SNVS 48(2) = 00000000 00000004, SNVS e0 = 00010001, DGO 20 = 20000000, DGO 40 = 80000000. Result: LPTDSR (SNVS a4) = 00000004 (ET5D set). It reads 00000004 both with no jumper and with an insulated jumper connected between J20 pin 1 (TAMPER_IN4) and pin 3 (TAMPER_OUT0). It also stays 00000004 after snvs_clear_status 107ff ff. So detection asserts with the loop open, but I never get a clean 00000000 state with the loop closed. Questions: 1. Does the TAMPER_OUT0 / TAMPER_IN4 loop on this EVK need a pad or pull setting (for example DGO tamper_pull_ctl), or a different act_tamper_clk_ctl value, for a wired-jumper loop? 2. Is snvs_clear_status expected to clear LPTDSR while the tamper condition is still present? 3. Is any other setting needed for the loop to be seen as closed? Thanks again.

如果我使用的是树莓派 Pico 2W，如何在 Arduino IDE 中查看 Serial.prints 的输出？ 我花了很多时间试图弄明白这件事，但最终一无所获。我尝试运行一个简单的代码，让内置 LED 闪烁，同时在 Serial.print 中打印“hello”。LED 指示灯闪烁，但 pico 没有在串口监视器中输出任何内容。我发现 pico 在上传后会断开连接，然后重新连接，但连接的是不同的端口。我猜我的板是从 COM 5/4 重新连接到 COM 11，但是如果我尝试进入“工具”->“端口”->“COM 11”，LED 指示灯停止闪烁，IDE 显示错误信息，我的笔记本电脑发出类似板断开连接又重新连接的声音。我能做些什么吗？我考虑过从 Arduino IDE 切换到 VS Code，但是没有关于如何在 Windows 上进行切换的教程，而 GPT 也没有教会我太多东西。 Kinetis W系列MCU

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チームに確認させてください。 よろしくお願いします、 志明 Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() こんにちは、 @Zhiming_Liu さん、バグを再現できましたか？はいの場合、修正が貴社のBSPに実装される予定時期を教えていただけますか？ よろしくお願いいたします。

How can I see the Serial.prints in Arduino IDE if I am using a raspberry pi pico 2w? I spent a lot of hours trying to figure this out and I didn't manage to do anything. I tried to run a simple code that makes the built in LED blink while also writing "hello" at Serial.print. The LED blinks, but the pico does't print anything in the serial monitor. I found out the pico disconnects after the upload and then reconnects again, but on a different port. I guess mine reconnects from com 5/4 to com 11 but if I try to go to Tools -> Port -> COM 11 the LED stops blinking, the IDE shows me an error message and my laptop makes the sound as if the board was disconnected and connected again. Is there something I can do about this? I took into consideration switching from arduino ide to vs code, but there are no tutorials on how to do that for windows and GPT didn't teach me much. Kinetis W Series MCUs

KW47-EVK板的蓝牙通道发声示例在哪里？ KW47-EVK 板及其子卡 (KW47-001-M10)的蓝牙通道发声示例在哪里？ 我在https://github.com/nxp-mcuxpresso/ 的仓库中查找过，但找不到任何针对 KW47-EVK 开发板的具体示例。我还找到了FRDM-MCXW72的通道探测示例：FRDM-MCXW72：动手实践 8：FRDM 到电话的通道探测。 我还使用了 NXP AI 的帮助功能，但它给出的链接并不存在。 我已经安装了基于 Eclipse 的 MCUXpresso，以及适用于 KW47-EVK 板和子卡 (KW47-001-M10) 的 SDK。 提前致谢！——保罗

在调用 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团队确认。 此致， 志明 Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() @Zhiming_Liu ，你好，请问你成功复现了这个bug吗？如果可以，请问预计何时能在BSP中实现该修复？谢谢。

BMS SDK dereferences NULL_PTR Hi, in the Phy 665a driver within BMS SDK, pxReqLowConfig is dereferenced, even if it is NULL_PTR (RequestQueueLow sideband not used for gateway device 0 configuration). Call stack: Level,Function,Stack Frame,Source,PC,Return Address,Stack Used 0," ","32 @ 0x2040DF00","exceptions.c:101:10",0x0060E874,"[0x2040DF18]: 0x0066D3E0",248 0,"Prv_Phy_665a_SpiPackMessageBatchInactiveSync","24 @ 0x2040DF20","CDD_Phy_665a_MsghSpi.c:2379:104",0x0066D3DE,"[0x2040DF34]: 0x0066D60A",216 0,"Prv_Phy_665a_SpiPackMessageBatch","24 @ 0x2040DF38","CDD_Phy_665a_MsghSpi.c:2551:18",0x0066D606,"[0x2040DF4C]: 0x0066DA8A",192 0,"Prv_Phy_665a_IO_SendMessageSpi","24 @ 0x2040DF50","CDD_Phy_665a_MsghSpi.c:3231:26",0x0066DA86,"[0x2040DF64]: 0x00666D34",168 0,"Phy_665a_IO_SendMessage","40 @ 0x2040DF68","CDD_Phy_665a.c:2037:30",0x00666D30,"[0x2040DF8C]: 0x0066E7FC",144 0,"Bms_TD_Send","24 @ 0x2040DF90","CDD_Bms_common.c:353:22",0x0066E7F8,"[0x2040DFA4]: 0x005D54E6",104 Version Information: * Project : BMS GEN2 SDK AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : * Dependencies : * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 0.9.1 * Build Version : S32K3_BMS_GEN2_SDK_0_9_1_D2601_ASR_REL_4_7_REV_0000_20260120 S32 SDK for S32K1

T1042 DDR4初期化失敗 私は64ビットインターフェースでDDR4に接続したT1042デザインを持っています。インターフェースの最上位バイトのニブル間で不適切なビットスワップの問題が既に見つかりましたが、これはSW設定では補正できないことがわかっています。PWBの改訂版で修正を実施する予定です。しかし、他のビットは正しく、スワッピングもリファレンスマニュアルで許可されている範囲に入っているため、代わりに32ビットモードで動作させて、SWや他の設計を引き続き表示できるようにしたいと考えています。QCVS DDRの検証ツールを使って試しましたが、メモリの初期化ができません。デバイスのパラメータを入力し、DQのマッピング値を自分のデザイン通りに設定しましたが、ERR_DETECTレジスタでビットACE= 1が出続けています。プロセッサはSPIインターフェース経由でRCWを取得し、DDR周波数は800MHzに設定されています。CodeWarrior/QCVSを使用して、正しいRCW値が受信されたことを確認する方法はありますか？32ビットモードの動作で考慮すべき他の設定は何でしょうか?なぜ動作しないのか説明がつきます。どんなサポートでも大変ありがたいです。ありがとう。 QorIQ T1デバイス Re: T1042 DDR4 Initialization Failure CodeWarrior/QCVSを使用して、正しいRCW値が受信されたことを確認する方法はありますか？ [A] はい、可能です。CCSを接続して、DCFG_CCSR_RCWSR1-DCFG_CCSR_RCWSR16を読み取って、SPIフラッシュのRCWと比較できます。 32ビットモードの動作で考慮すべき他の設定は何でしょうか?なぜ動作しないのか説明がつきます。 [A]これはディスクリートDDR4ですか？一般的なルールについては、 QCVS_DDR_User_Guideを参照してください。 ハードウェア設計については、 AN5097、DDR4 SDRAMメモリインターフェースのハードウェアおよびレイアウト**デザイン**の考慮事項 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure こんにちは、ジューンさん。 ご返信ありがとうございます。CCSを使用してRCWステータスレジスタを読み取り、RCWが想定どおりにプログラムされていることを確認できました。 私はディスクリートDDR4を使っており、ユーザーガイドやレイアウトの考慮事項も確認済みです。 32ビットインターフェース使用に関するエラッタA-007864を満たすため、1300MT/sで動作するための650MHzクロックがあることを確認しました。同僚が、チップセレクトがトグルしているかどうか確認するように提案した。QCVSツールがプロセッサに設定を送信し始めると、CS0信号は十分に低く保たれることがわかりました。プログラミングが完了し、検証ルーチンを実行しようとすると、CS0信号が完全にアサートされなくなる。JTAGの境界スキャンツールを独自に使い、信号が期待通りに接続されていること、そしてT1042のI/Oが正味を十分に低くしてDDR4メモリデバイスのVILを満たすことができるかを確認しました。信号の整合性に関するルーティングの面でも、ネットワークが良好であり、どこにも短絡していないことも確認しました。どうやらメモリコントローラの設定に何か問題があり、チップセレクト信号が正しく機能しないようです。他に何かアイデアはありますか?ありがとう。 Re: T1042 DDR4 Initialization Failure 説明中のCS0がD1_MCS0_Bを指しているのか確認していただけますか? ご使用のCCSでコマンドを実行し、CCSのログ全体を更新してください。 (bin) % ccs::reset_to_debug よろしくお願いします。 Re: T1042 DDR4 Initialization Failure その通りです。私が言及しているのはD1_MCS0_Bのことです。 コマンドを実行すると (bin) % ccs::reset_to_debug 「ライブラリが見つかりません」というメッセージが表示されます。 Re: T1042 DDR4 Initialization Failure メモリコントローラは650MHzまたは1300MT/sの動作に設定されています。結果は同じだった。64ビットインターフェースのバイト8で意図しないビットスワップ(ニブル間の誤スワップ)が発生しているため、DDR4で32ビットモードを使おうとしています。設計は64ビット+ECCを想定していましたが、一時的な回避策として32ビット+ECCを運用しようとしています。つまり、現在5台の16ビットチップが接続されていますが、そのうち3台だけで動作させることを目指しています。 様々な設定の組み合わせを試してみましたが、QCVSツールの動作に変化は見られません。少し奇妙なのは、QCVSと同様の値をスタートアップスクリプトに設定したGreenHillsエミュレーターを使ってみたところ、DDR_SDRAM_CFG_2[D_INIT]がクリアされるまでの待機ループを通過できたことです。これは初期化が完了していることを示唆しています。そして、初期書き込み/読み出し検証で全て0x00となり失敗します。これは、最適ではない書き込みレベル設定値を使用しているため当然の結果です。QCVSツールだけ動作が異なる理由が分かりません。 Re: T1042 DDR4 Initialization Failure RCWステータスレジスタを読み出した後、コマンドを入力してください。 コマンド「ccs::reset_to_debug」の結果ではなく、完全なccsログを共有してください。 「ライブラリが見つかりません」というメッセージが表示されます。 完全なログは、ccs を使用した最初のコマンドから始まります。 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure ACEエラーは、メモリコントローラがトレーニングシーケンス中にエラーを検出した場合に設定される自動キャリブレーションエラーです。では、クロック速度を800MHzから下げた場合、トレーニング結果はどうでしょうか? 一方、DDR4では64ビットまたは32ビットのバス幅のどちらが採用されるのでしょうか？T1042にはDDR4が何個接続される予定ですか？ Re: T1042 DDR4 Initialization Failure 添付ファイルは.txtファイルです。RCW出力による。最後に指定したコマンド「ccs::reset_to_debug」を実行しましたが、「ライブラリが見つかりません」というメッセージは表示されませんでしたが、その他の情報も表示されませんでした。 DDR構成レジスタについても同様のキャプチャを行い、添付しました。問題は見つかりません。実際、GreenHillsプローブで使用したこれらの値は正常に動作し、D_INITもクリアされるようですが、同じ値をQCVSツールで使用した場合はD_INITがクリアされません。GHプローブとCWTAPの違いがよく分かりません。何かアイデアがあれば教えてください。 Re: T1042 DDR4 Initialization Failure 現在、調達部門と協力してNDAを成立させ、完全な訂正書を作成できるようにしています。しかし、コンポーネントT1042NXE7MQBを使っていて、GoogleやNXPフォーラム検索ではエラッタA009942適用されるようです。 参照された「Optimization.zip」を教えていただけますか?どこにも添付されていないようです。 Re: T1042 DDR4 Initialization Failure 「ccs::reset_to_debug」は正しく動作します。 errata_A009942 が必要かどうか確認してください。必要な場合は、添付のホットフィックス Optimization.zip を解凍して、CodeWarrior PA インストールフォルダ内の既存の Optimization フォルダを上書きしてください。C:\Freescale\CW_PA_v10.5.1\eclipse\Optimization\resources\QorIQ\DDR\templates\init\errata_A009942.py が存在します。 以下の一般的なガイドラインをご確認ください。 新しいQCVSプロジェクトを作成する - 「自動設定」と「離散DRAM」を選択する - DRAM速度定格 = 最大速度 (例: 最大3200 MT/s、データシートを参照) - 「出力データレート」で「xxx MT/s」を選択してください（現在の動作速度、例： 1300MT /s。このデータレートはRCWイメージで設定されているDRAM速度と一致している必要があります）。   - 「ランク/チップ選択」で「x」を選択                   (シングルCSまたはデュアルCS)   - 「tCL」は「xx」を選択します（DRAMデータシートの速度ビン表に従って）。   - 「デバイスごとのDRAM構成」で「xx」を選択してください（DRAMデータシートを参照）。   - 適切な CLK-to-QDS スキューを埋める               (EDA ツールを使用して CLK 信号と DQS 信号の長さを測定します。CLK の長さ - DQS の長さ) CLKの長さからDQSの長さを引いた値。例： CLK-DRAM0間の長さ = 100 mm CLK-DRAM1間の長さ = 101 mm DQS[0]の長さ = 75 mm DQS[1]の長さ = 110 mm CLK-to-DQS[0]のスキュー = 100 mm - 75 mm = 25 mm CLK-to-DQS[1]のスキュー = 101 mm - 110 mm = -9 mm - CLK配線の長さは、DQS配線の長さと10インチ以内で等しいか、それ以上でなければなりません。 - MCKの配線長がDQSの配線長より短い場合、その差は2.0インチ以内でなければなりません。 DQマッピング - コントローラピン: 実際のボードでDQビットスワッピングが使われている場合、ユーザーはQCVSで実際のPCBレイアウトに合わせて設定する必要があります。 タイミングCFG_1と3: - tCL/tRCD/rRP/tRAS この値は、現在の動作速度に合わせるためにDRAMデータシートを参照します。      - tWR (書き込み回復時間、プリチャージの最小間隔となる最後のデータ)。この値はDRAMデータシートを参照してください。          - tRRD（アクティブ化間隔）この値はDRAMデータシートを参照します。     タイミングCFG_2:   - tFAW（4つのアクティブウィンドウ）、この値はDRAMデータシートを参照します。 ユーザーは、これらのボード固有の構成やDRAM固有の構成が実際のハードウェアと一致していることを確認する必要があります。 その他のほとんどのオプションについては、QCVSのデフォルト値を使用してください。 よろしくお願いします。 Re: T1042 DDR4 Initialization Failure 添付ファイルが見当たらなくて申し訳ありません。 Re: T1042 DDR4 Initialization Failure こんにちは、ジューンさん。 ファイルの提供と継続的なサポートに感謝します。QCVS DDRvツールの設定に関するガイドラインに従い、本日、エラータ#A009942の回避策を試してみましたが、効果は見られませんでした。スクリプト自体を調べてみたところ、667MHzと800MHzという特定の周波数に対してのみ回避策が適用されているようです。現在、訂誤#007864により、幅32ビット以下の800MHzで動作するとDDRインターフェースに問題がある可能性があるとされ、現在650MHzで動作しています。650MHzの場合、設定する必要のあるデバッグレジスタ値はありますか？ この設計は単一の100MHzクロックソースを使用しているため、DDR周波数の選択肢はDDR4用に650MHz、700MHz、750MHz、800MHzしかないように思えます。32ビットモードの場合、650MHz以外の周波数を使用すべきでしょうか？ 私は依然としてDQマップの値に疑念を抱いています。数ヶ月前の別の投稿で、 T1042 DDR4 DQ MAPレジスタ設定の値を確認するのを手伝っていただきました。 これは、当サイトで動作しているT1042 DDR4の他の例とこの設計との違いが顕著です。彼らは64ビットを使用し、最上位バイトでわずかなビットスワップを行っただけだった。64ビットインターフェースのMSBで既知の悪いビットスワップがあり、そのため32ビットモードを回避策として試みています。動作設計よりも多くのスワップがあり、1バイトレーン内での完全なニブルスワップも含まれますが、インターフェースの32ビットLSBはT1042コントローラーで許可されているルールに従っているようです。DQマップの入れ替えに関する様々な組み合わせが機能することが知られていますか？検証に使っている値をもう一度見ていただけますか?便宜上、レジスタ値と回路図のキャプチャを添付しています。DDR4デバイスのもう一方の端は直接1:1のマッピングなので、スワッピングはT1042側にのみ表示されています。 改めて、サポートありがとうございます。 Re: T1042 DDR4 Initialization Failure @dbevans42 スクリプトには650 MHzのA-009942を適用し、667と同じラインをもう1行追加すれば良いでしょう。 DQマッピングを確認するため、DDRデバイスの部品回路図をご提供いただけますでしょうか。 DQマッピングがMAPを横切る場合、デバッグモードが1つありますが、これはボードを修正するまでの暫定的な解決策です。 データレートを1200MT/sに設定する DDR_SDRAM_CFG_2[DDR_SLOW] = 1 に設定します オフセット0x8F04[27]のDDRレジスタを1に設定するか、オフセット0x8F04に0x10の値を書き込みます。 DDR_DQ_MAPnレジスタをすべてクリアします よろしくお願いします。 Re: T1042 DDR4 Initialization Failure DDR4です。これはDIMMではなく離散設計なので、1G x 16ビットのデバイスが5台(64ビット+8ビットECC)です。 Re: T1042 DDR4 Initialization Failure DDR4に64ビットバス幅の製品があるかどうかはわかりません。LPDDR4のことですか? Re: T1042 DDR4 Initialization Failure 9月24日（木）に投稿した前回のメッセージでは、DQ[0:31]とECCに関する回路図のスクリーンショットを添付しました。誤ったビットスワップをハイライトした64ビットインターフェース全体のスナップショットを再度含めます。 追加の回避策を教えていただきありがとうございます。 質問: 1) A009942スクリプトに650MHzを追加する場合、どのような値を書き込むべきですか？667MHzと同じであるべきでしょうか？ 2) あなたが挙げた新しい1200MT/sの回避策は、誤ったスワップが発生しても64ビットモードが動作するようにするためのものですか、それとも引き続き32ビットモードを試す必要がありますか？ 3) DDRvツールを使用して回避策を実行する方法はありますか？そうでなければ、GreenHillsプローブの起動スクリプト内で試してみて、結果を報告します。 Re: T1042 DDR4 Initialization Failure こんにちは、ジューンさん。 GreenHillsのプローブ起動スクリプト内でご紹介いただいた回避策を実装でき、DDR4インターフェースが動作しているようです。DDR4にコードを読み込んで実行を開始でき、GHプローブメモリビューを使ってDDR4で初期化されたデータ値を確認できます。確認のため、スクリプトを添付しました。 質問: 1) デバッグモードについてもう少し詳しく教えてもらえますか? 2) デバッグモードの回避策は1200MT/sでしか動作しないのか、それとももっと速く動かせるのか? 3) DQマップレジスタの機能にバグはありますか？DQマップレジスタが宣伝どおりに動作すること、そして新しいスピンでDQ57とDQ63の入れ替わりの誤りを修正した場合でも、デバッグモードなしでも正常に動作することを確認する必要があります。 4) 32ビットモードにバグや問題はありますか？デバッグ回避策なしの32ビットモードが機能しないのは理にかなっていません。なぜなら、それらのビットのマッピング規則に従っているからです。 5) 回避策としてデバッグモードを実行し、QCVS DDRvツールを使用して正しい書き込みレベル値を取得する方法はありますか？

i.MX8DXL EVK (J20) の TAMPER_OUT0/TAMPER_IN4 アクティブタンパーループ用の正しい snvs_cfg 値 こんにちは、 U-Boot を介して、i.MX8DXL EVK (MCIMX8DXL-WEVK) 上の外部アクティブタンパーループを検証しています。 基板の回路図から、J20（TAMPERヘッダー、1x3）の配線が以下のようになっていることを確認しました。 - ピン 1 = TAMPER_IN4 (ネット SNVS.TAMPER_IN4、ボール AJ13) - ピン2 = GND - ピン3 = TAMPER_OUT0 (ネットSNVS.TAMPER_OUT0、ボールAP22) これらは専用のSNVSピンであり、TAMPER_OUT1-4/IN0-3のようにSAI2/SAI3と共有されていません。 使用可能な U-Boot コマンド: tamper_pin_cfg、snvs_cfg (サブレジスタ hp.lock、hp.secvio_intcfg、hp.secvio_ctl、lp.lock、lp.secvio_ctl、lp.tamper_filt_cfg、lp.tamper_det_cfg、lp.tamper_det_cfg2、lp.tamper_filt1_cfg、lp.tamper_filt2_cfg、lp.act_tamper1_cfg ～ lp.act_tamper5_cfg、lp.act_tamper_ctl、lp.act_tamper_clk_ctl、lp.act_tamper_routing_ctl1、lp.act_tamper_routing_ctl2 を含む)、snvs_sec_status、snvs_clear_status。 TAMPER_OUT0/TAMPER_IN4はアクティブなタンパーペアを形成するため、私の質問は次のとおりです。 1. どのlp.act_tamperN_cfgチャネル(1-5)がTAMPER_OUT0に対応しているか? 2. lp.act_tamper_routing_ctl1/routing_ctl2ルートTAMPER_OUT0のパターンの値をTAMPER_IN4と比較してチェックする価値は? 3. このチャネルのパターンクロックを可能にするlp.act_tamper_clk_ctlの値は何? 4. このチャネルのアクティブ改ざん検出を可能にするグローバルなlp.act_tamper_ctl価値は何でしょうか? 目標：J20ピン1～3間のジャンパーを閉じるとsnvs_sec_statusでセキュアと表示され、ジャンパーを開くと違反が発生するようにする。 ハードウェア上でいくつかの値を試しました（ルーティング4、5、10、さまざまなクロック/検出器設定）が、すべてSECOファームウェアによって拒否されるか（エラーres:9 / SC_ERR_PARM）、物理的にループを切り替えたときにsnvs_sec_statusのSNVS a4(1)（LPTDSR）レジスタに目に見える変化がないまま受け入れられました。 i.MX8DXLにおける外部アクティブタンパー検証に関するリファレンステスト手順またはアプリケーションノートはありますか？ よろしくお願いします！ Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) こんにちは、 1. lp.act_tamper1_cfg は TAMPER_OUT0 を駆動します。 2. i.MX8DXL SNVSは、5つのアクティブタンパー（AT）出力ソースと最大8つの外部タンパー（ET）入力検出器を備えています。 この設定を使用してください。 lp.act_tamper_routing_ctl1 = 0x00010000 # ET5 (TAMPER_IN4) から AT1 (TAMPER_OUT0) へ lp.act_tamper_routing_ctl2 = 0x00000000 # ET6-ET8 は使用されていません 3. その値はクロック分周器を変更します。最大周波数設定には0x00を使用してください。 lp.act_tamper_clk_ctl = 0x00000000 4. lp.act_tamper_ctl = 0x00010001 を使用します。 ビット0：AT1ENはAT1 LFSRパターンジェネレーターを有効化します。 ビット16：AT1_OUT_ENがTAMPER_OUT0パッドをAT1パターンで駆動する このプロセッサに関するアプリケーションノートはありませんが、i.MX7から参照として利用できます。 /* Config ET5 (pin in et4) <-> (pin out et5) AT 1 * /* reset */ write32(0, &svregs->lp.act_tamper_clk_ctl); write32(0, &svregs->lp.act_tamper_ctl); write32(0, &svregs->lp.tamper_det_cfg); write32(0, &svregs->lp.tamper_det_cfg2) /* Deault value for LFSR */ write32(0x84000000 | 0x00001111, &svregs->lp.act_tamper1_cfg) /* Set the clock at max freq */ write32(0x00000000, &svregs->lp.act_tamper_clk_ctl); /* ET5 (pin et4) takes ref from AT1 (pin et5) */ write32(0x00010000, &svregs->lp.act_tamper_routing_ctl1); write32(0x0, &svregs->lp.act_tamper_routing_ctl2) /* activate out pad of AT1 and enable it, AT1 output on pin et5 */ write32(0x00010000 | 0x00000001, &svregs->lp.act_tamper_ctl) /* Configuring IRQs and secviols */ write32(0x8000003f, &svregs->hp.secvio_intcfg); write32(0x4000003f, &svregs->hp.secvio_ctl); write32(0x0000003f, &svregs->lp.secvio_ctl) /* Activating detector for ET5 */ write32(0x00000000, &svregs->lp.tamper_det_cfg); write32(0x00000004, &svregs->lp.tamper_det_cfg2); よろしくお願いいたします。 Re: Correct snvs_cfg values for TAMPER_OUT0/TAMPER_IN4 active tamper loop on i.MX8DXL EVK (J20) 設定していただきありがとうございます。電源を入れた直後に正確に適用しました。 snvs_dgo_cfg 0 0 20000000 0 80000000 0 snvs_cfg 0 8000003f 4000003f 0 3f 0 0 4 0 0 84001111 0 0 0 0 10001 0 10000 0 読み戻しはあなたの値と一致します: SNVS e8(2) = 00010000 00000000、SNVS 48(2) = 00000000 00000004、SNVS e0 = 00010001、DGO 20 = 20000000、DGO 40 = 80000000。 結果: LPTDSR (SNVS a4) = 00000004 (ET5D セット)。ジャンパーなしでも、J20ピン1(TAMPER_IN4)とピン3(TAMPER_OUT0)の間に絶縁ジャンパー接続した場合も、どちらも00000004読み取ります。snvs_clear_status 107ff ff の後も 00000004 のままです。つまり、ループを開いた状態で検出は主張しますが、ループを閉じているとクリーンな0000000状態は一度も得られません。 質問: 1.このEVKのTAMPER_OUT0 / TAMPER_IN4ループでは、ワイヤードジャンパーループの場合、パッドまたはプル設定（例えばDGO tamper_pull_ctl）や、異なるact_tamper_clk_ctl値が必要ですか？ 2. 改ざん状態がまだ存在する間に、snvs_clear_statusはLPTDSRをクリアすることが期待されていますか？ 3. ループが閉じていると認識されるために、他に何か設定が必要ですか？ 再度、感謝します。

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 Re: Using iMX8MP GPU on a process that call mlockall(MCL_FUTURE) causes kernel BUG() Hi @Zhiming_Liu , did you manage to reproduce the bug? If yes, do you have an ETA when the fix will be implemented in your BSP? Thanks.  

电池管理系统 SDK 取消引用 NULL_PTR 您好， 在 电池管理系统 SDK 中的 Phy 665a 驱动程序中，即使 pxReqLowConfig 为 NULL_PTR（ RequestQueueLow 边带未用于网关设备 0 配置），也会取消引用它。 调用堆栈： Level,Function,Stack Frame,Source,PC,Return Address,Stack Used 0," ","32 @ 0x2040DF00","exceptions.c:101:10",0x0060E874,"[0x2040DF18]: 0x0066D3E0",248 0,"Prv_Phy_665a_SpiPackMessageBatchInactiveSync","24 @ 0x2040DF20","CDD_Phy_665a_MsghSpi.c:2379:104",0x0066D3DE,"[0x2040DF34]: 0x0066D60A",216 0,"Prv_Phy_665a_SpiPackMessageBatch","24 @ 0x2040DF38","CDD_Phy_665a_MsghSpi.c:2551:18",0x0066D606,"[0x2040DF4C]: 0x0066DA8A",192 0,"Prv_Phy_665a_IO_SendMessageSpi","24 @ 0x2040DF50","CDD_Phy_665a_MsghSpi.c:3231:26",0x0066DA86,"[0x2040DF64]: 0x00666D34",168 0,"Phy_665a_IO_SendMessage","40 @ 0x2040DF68","CDD_Phy_665a.c:2037:30",0x00666D30,"[0x2040DF8C]: 0x0066E7FC",144 0,"Bms_TD_Send","24 @ 0x2040DF90","CDD_Bms_common.c:353:22",0x0066E7F8,"[0x2040DFA4]: 0x005D54E6",104 版本信息： * Project : BMS GEN2 SDK AUTOSAR 4.7 * Platform : CORTEXM * Peripheral : * Dependencies : * * Autosar Version : 4.7.0 * Autosar Revision : ASR_REL_4_7_REV_0000 * Autosar Conf.Variant : * SW Version : 0.9.1 * Build Version : S32K3_BMS_GEN2_SDK_0_9_1_D2601_ASR_REL_4_7_REV_0000_20260120 S32K1系列的S32SDK

Raspberry Pi Pico 2Wを使っている場合、Arduino IDEでSerial.printsを見るにはどうすればいいですか? 何時間もかけて解決しようと試みましたが、結局何もできませんでした。内蔵LEDを点滅させながら、Serial.printに「hello」と書き込む簡単なコードを実行してみました。LEDは点滅するが、ピコはシリアルモニターに何も出力しない。アップロード後にピコが切断され、その後別のポートで再接続されることが分かりました。私のはcom 5/4からcom 11に再接続されるようですが、Tools -> Port -> COM11に行こうとするとLEDが点滅し、IDEにエラーメッセージが表示され、ノートPCは基板が外されて再接続されたかのような音を出します。これについて何かできることはありますか?Arduino IDEからVS Codeに切り替えることも考えましたが、Windows用のチュートリアルがなく、GPTもあまり教えてくれませんでした。 Kinetis Wシリーズ・マイクロコントローラ

Inquiry on PCF2123TS-1,118 Appearance Variation Dear NXP team: During incoming inspection of two reels of PCF2123TS-1,118 chips, we discovered two different appearance types: Type 1: Glossy surface, smaller pin 1 indicator; glossy and slightly curved side texture. Type 2: Rough surface, larger pin 1 indicator; rough and straight side texture. Are these differences normal? We look forward to your reply. Thank you! Sincerely, Ms. Liu

Where are Bluetooth Channel Sounding Examples for the KW47-EVK board Where are Bluetooth Channel Sounding Examples for the KW47-EVK board with the daughter card (KW47-001-M10)?  I've looked in the repos at https://github.com/nxp-mcuxpresso/ but cannot find any specific examples for the KW47-EVK board. I've also found a Channel Sounding example for the FRDM-MCXW72 FRDM-MCXW72: Hands-On 8: Channel Sounding FRDM to Phone.  I also used the NXP AI help, but it came up with links that did not exist. I have the Eclipse based MCUXpresso installed along with the SDKs for the KW47-EVK board with the daughter card (KW47-001-M10). Thanks in advance! --Paul

Inquiry on PCF2123TS-1,118 Appearance Variation 尊敬的恩智浦团队：在对两卷PCF2123TS-1,118芯片进行来料检验时，我们发现了两种不同的外观类型：类型1：表面光亮，引脚1指示器较小；侧面纹理光亮且略微弯曲。类型2：表面粗糙，引脚1指示器较大；侧面纹理粗糙且平直。请问这些差异是否属于正常现象？期待您的回复。谢谢！此致，刘小姐