LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon.  Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks! Re: LX2162A USXGMII link never completes @yipingwang I really appreciate the detailed response! Everything you said makes sense and I've started learning more about the platform. I've started using the advice in AN13329.pdf. Some of the addresses and things aren't working (probably a version mismatch) but at least I can get the MC log as shown below: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ I've attempted to poke at the PCCC via uboot. Here are the relevant things: crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... I really hope 0x1ea10b0 is the right address. According the LX2162ARM.pdf, that *could* be the right address and decoding the bits shows: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI Is the right right register address (PCCC) to observe? Is there any other information I can provide? Thanks! Re: LX2162A USXGMII link never completes The LX2162A side is documented to support USXGMII on the paths you are using , but the symptom you show looks less like a missing Linux pcs-lynx write and more like the selected PCS instance is still not actually in USXGMII application mode, or MC firmware is programming the wrong 10G PCS selector. For SerDes1 protocol 3 , the LX2162A reference manual lists all four SerDes1 lanes as USXGMII / XFI , including USXGMII / XFI.3 for the first lane, which corresponds to the DPMAC3 use case you are testing on the Clearfog SFP path . For your future custom-carrier target, SerDes2 protocol 7 also documents lane 6 and lane 7 as USXGMII / XFI.13 and USXGMII / XFI.14 . The important catch is that the USXGMII / XFI entry is not automatically “USXGMII.” The reference manual says that between USXGMII and XFI on a lane, the default is XFI . The mode is selected through PCCC , the Protocol Configuration Register C, and its SXGMII*_XFI bits select 0b = USXGMII and 1b = XFI/SFI . So the first thing I would check is not the Linux BMCR write itself, but whether the specific SXGMII instance for DPMAC3 has its PCCC XFI-select bit cleared after MC/DPC initialization. There is also precedent for this exact class of failure being in MC firmware , not in the Linux PCS driver: one LX2162A ticket shows MC clearing the wrong 10G interface selector in PCCC for a USXGMII configuration, and an MC firmware engineering build, version 10.35.101 , resolved the issue . Another ticket notes that MC settings are done by MC firmware, with NXP providing MC as a binary . Since you are on MC 10.39.0 , you should be beyond that specific old fix, but the failure mode you see is still consistent with “MC did not put the intended PCS into USXGMII mode” or “the wrong PCS instance is being addressed.” What I would do next: Read PCCC before Linux changes anything. After RCW + MC + DPL/DPC load, but before the Linux PCS driver runs, read PCCC and confirm the relevant SXGMII*_XFI bit is 0 . For DPMAC3 / USXGMII/XFI.3 , expect the first SXGMII selector, not the selector for MAC13/14. If that bit remains 1 , the lane is still XFI/SFI and your VEND2/USXGMII PCS writes are not being applied to a live USXGMII PCS path. Check that the MDIO access is hitting the intended PCS management port. The SXGMII protocol-control register has an MDEV_PORT field used to match MDIO accesses, and the manual says software must wait at least 3 platform clocks after changing it before MDIO accesses to the SGMII/PCS target . If the MDIO address decode is wrong, writes can appear to “not persist” because you are reading a different or reset/default PCS window. Confirm the USXGMII AN registers are meaningful only after the mode select is correct. The USXGMII PCS CONTROL register has AUTO_NEGOTIATION_ENABLE at bit 12, and DEV_ABILITY / PARTNER_ABILITY are RW registers . The DEV_ABILITY lower vendor arbitrary speed field must be non-zero, because zero can cause auto-negotiation failure . But if PCCC still selects XFI, these BMCR/ability writes are not the real root problem. Do not treat QXGMII as a separate required external protocol unless the GPY245 board documentation explicitly says so. LX2162A documentation does contain QXGMII protocol-converter registers, including reset/powerdown control bits such as PD_QXGM and RST_QXGM . NXP community material for LS1028A also refers to a 10G_QXGMII Lynx SerDes driver path . But the documented LX2162A DPMAC interface you are selecting is still USXGMII / XFI , and NXP documentation separately states that LX2160-class devices support USXGMII and that “SXGMII” is not the same thing . In other words: “QXGMII” references in driver/community discussions may describe an internal converter/driver naming path, not necessarily a different MAC-to-PHY contract than the USXGMII mode you configured. For this Clearfog SFP test, keep the DPC simple. MAC_LINK_TYPE_PHY with enet_if = "USXGMII" is the more natural model for a managed external PHY over MDIO. I would not expect MAC_LINK_TYPE_BACKPLANE to fix a PHY-facing USXGMII setup unless you are intentionally using a backplane/KR-style flow. I would not conclude that protocol 3 is “primarily XFI-only.” The reference manual documents protocol 3 as USXGMII / XFI for DPMAC3’s SerDes1 lane . What I cannot verify from the retrieved material is a separate validation statement saying “protocol 3 + DPMAC3 + USXGMII was validated with GPY245.” The stronger, evidence-backed statement is: the hardware mode exists, defaults to XFI unless PCCC selects USXGMII, and there is known MC-firmware precedent for programming the wrong 10G PCS selector . For your specific readback: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 that is exactly the kind of result I would expect if the PCS instance is not fully enabled/selected for USXGMII, or the MDIO management window is not addressing the intended PCS instance. I would verify PCCC and the MC log first, before adding more Linux-side writes. LX2162A protocol 3 is documented for USXGMII / XFI on DPMAC3, but USXGMII depends on MC/PCCC selecting the USXGMII PCS; if VEND2/BMCR writes do not persist, first prove the correct PCCC bit is cleared for DPMAC3 and that MDIO is addressing the correct SXGMII PCS instance. Re: LX2162A USXGMII link never completes Yes. For SerDes1 ,  0x1ea10b0  is the right address for PCCC : LX2162A CCSR map lists SerDes 1 at  0x1EA_0000–0x1EA_FFFF  . The SerDes memory map lists Protocol Configuration Register C / PCCC at offset  0x10B0  . Therefore: 0x1EA0000+0x10B0=0x1EA10B00x1EA0000+0x10B0=0x1EA10B0 So your U-Boot read: Copy => md.l 0x1ea10b0 1 01ea10b0: 88889991   is observing the expected SerDes1 PCCC register. The important caveat is the naming: I would not describe those fields as physical SerDes lane A/B/C/D for your current setup. In the LX2162A SerDes1 protocol table, protocol  3  maps physical lane H / lane 0 to  USXGMII / XFI.3  , then lane G/lane 1 to  .4  , lane F/lane 2 to  .5  , and lane E/lane 3 to  .6  . PCCC field names such as  SXGMIIA_XFI  ,  SXGMIIB_XFI  , etc. are PCS/protocol-control fields, not necessarily the same naming convention as the physical lane letters. For your value  0x88889991  , the high nibbles decode like this: Copy PCCC = 0x88889991 bits 31:28 = 0x8 -> SXGMIIA_XFI = 1, CFG = 000 bits 27:24 = 0x8 -> SXGMIIB_XFI = 1, CFG = 000 bits 23:20 = 0x8 -> SXGMIIC_XFI = 1, CFG = 000 bits 19:16 = 0x8 -> SXGMIID_XFI = 1, CFG = 000 bits 15:12 = 0x9 -> SXGMIIE_XFI = 1, CFG = 001 bits 11:8 = 0x9 -> SXGMIIF_XFI = 1, CFG = 001   The key bit is the  _XFI  bit. The RM defines  0  as USXGMII mode and  1  as XFI/SFI mode for these fields . So the value you read strongly suggests the relevant USXFI/SXGMII PCS instances are still being selected as XFI/SFI , not USXGMII. That lines up with your symptom: Linux/restool may report  DPMAC_ETH_IF_USXGMII  , but if PCCC still has the relevant  _XFI  select bit at  1  , the underlying SerDes/PCS selection is still effectively in XFI/SFI mode. The RM also explicitly says that to enable 10G-SXGMII, software must set  PCCC[SGMIIa_XFI] = 0  . Your MC log extraction also looks sane. AN13329 says to read MCFBAL/MCFBAH at  0x8340020  , build the MC firmware base, then dump the log-buffer structure at offset  0x01000000  ; the structure contains the magic, log-buffer offset, and log-buffer length . Your  0x21e1000000  dump shows the expected  0x4d430100  magic and points to log offset  0x01400000  , which matches your later dump at  0x21e1400000  . What I would capture next: PCCC snapshots at each stage Copy md.l 0x1ea10b0 1 Capture it: immediately after reset / before MC boot if possible, after MC boot, after DPC/DPL apply, after Linux boots, after the DPMAC is probed/configured. Adjacent protocol config registers Copy md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9 contain other SGMII configuration fields, while PCCC is the SXGMII/XFI selector register . Confirm which PCCC field changes when you try forcing USXGMII If you can safely poke in U-Boot for experiment only, try clearing the candidate  _XFI  bit and reading it back immediately. For example, if dpmac3 corresponds to the first SXGMII/USXFI control field, clearing bit 31 would be the experimental check: Copy mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 If it immediately reads back as  0x88889991  , then either the write is blocked/overridden, or that field is not writable in the current block state. If it sticks until MC or Linux runs, then MC/Linux is likely restoring XFI/SFI mode. Full RCW SerDes decode You already have  SerDes1=3, SerDes2=11  ; that matches the dpmac3 lane being available as  USXGMII / XFI.3  under SerDes1 protocol 3 . Still, include the full RCW string and raw RCW dump when escalating, because MC firmware often keys off the complete protocol set. MC firmware + DPC/DPL artifacts Since your MC is  10.39.0  , include: MC firmware version, DPC source, DPL source, exact  dpmac@3  block, restool dpmac info dpmac.3  , the PCCC value after each step. My current read of your data: yes,  0x1ea10b0  is the correct SerDes1 PCCC address, and  0x88889991  looks like the relevant PCS selectors are still in XFI/SFI mode. That is consistent with XFI working through the SFP cage and USXGMII not accepting/retaining the expected PCS configuration.

Inquiry regarding whether data tampering can occur due to noise in the field Hello, NXP. We are currently working on a project using the S32K312 MCU. We are writing to inquire because we encountered a defective unit in the field. During the analysis of the defective unit, we compared the dump files of a normal unit with a good unit and found differences in specific areas between the two. jeongwoo_0-1786583945706.png The photo on the left is a normal DUMP file, and the one on the right is a high-quality DUMP file. The failure is related to a dark current issue. When accessed via Trace32, we confirmed that the Watchdog was continuously triggering a reset during the controller's sleep process. The image on the left shows the normal dump file, and the image on the right shows the defective dump file. Upon checking the .map file, the issue is related to the LIN section (Mcal_LIN). Our project does not use a LIN transceiver, and LIN-related functions have been blocked. We are considering two possibilities: 1. Data tampering caused by noise during the writing process 2. CodeFlash tampering caused by noise in the field Is it possible that noise generated in the field due to static electricity or power interruptions could cause the CodeFlash area to be tampered with?A reset by Wdg occurs when entering Sleep mode. Is there a way to identify the cause of this Wdg reset? Re: Inquiry regarding whether data tampering can occur due to noise in the field Hello @jeongwoo. This is an S-record, type S3, with a byte count of 0x25. The record starts at address 0x0046D0E0. Only 4 bytes differ in the data payload, at address 0x0046D0F8: 0x11 00 02 00 changed to 0x40 78 09 78, and the S-record checksum changes accordingly from 0x89 to 0x63. What is notable is that bits are flipped in both directions — from 1 to 0 and from 0 to 1. In NOR flash, bits can only be programmed from 1 to 0; flipping a bit from 0 to 1 requires a sector erase first. So the 0 to 1 transitions cannot be the result of a simple programming operation. To change bits from 0 to 1 without an erase, charge would need to be removed from the isolated floating gates, which requires both energy and a discharge path. EMI cannot provide this. ESD of sufficient energy to discharge a floating gate would almost certainly cause broader damage. Regarding SEU, we observe many bit flips across 4 separate bytes. A more likely explanation is that the defective unit was programmed from day one with a different binary, and the flash content has never changed since initial production programming. In that case the ECC checksums stored in flash would be consistent with the data and no ECC error would be reported when the flash is read. Could you confirm this? If the content was instead corrupted after programming, reading flash at address 0x0046D0F8 should trigger an ECC error — do you see ???? displayed at this location when reading from TRACE32? Additionally, could you read DCMROD4[12]? Regarding the watchdog reset, which watchdog do you mean? It could be the SWT, an external watchdog, or the POR_WDOG. An SWT (or external watchdog) reset is triggered when the watchdog is not serviced, typically because execution is stuck in a loop. If this is the case, could you disable the watchdog and attach the debugger to the MCU to capture where execution is halted? If it is a POR_WDOG reset, please read registers DCMROPP1–DCMROPP4, which will provide more detailed information about it. Regards, Daniel Re: Inquiry regarding whether data tampering can occur due to noise in the field Hello, thank you for your reply. In other words, are you saying that the 4-byte difference is likely not due to field factors? We do not currently have the original parts on hand, so it is difficult to perform the address reading and register verification you mentioned. 1. I would like to inquire if there are any similar cases in the field. If so, was it a case where multiple bytes were changed? 2. If firmware that has been modified due to noise is written during the process, could you tell me specifically what the causes of that writing noise might be? Re: Inquiry regarding whether data tampering can occur due to noise in the field Hello @jeongwoo, 1. I'm not aware of any similar cases. 2. This is just a hypothesis at this point — it needs to be tested first. If there is no ECC error at the affected address, the flash has most likely been programmed with this content from the start. If there is an ECC error, the record has been corrupted, but the corruption is overwhelmingly more likely to have occurred during programming rather than after the data was written to flash. Possible causes include power supply instability or an interruption during the flash write operation. After programming the image, do you verify the flash content? Do you use a Margin Read during verification? Do you keep logs from the production programming process? Is the flash ever modified at runtime, or is it programmed once in the factory and never touched again? Regards, Daniel

IMX95 uGuzzi ISP：AE算法无法达到最大曝光 我已经配置了 AE LIMITS，并相应地设置了最大曝光量。然而，在运行时，AE 算法最多只能达到 66666 次曝光，此时增益也达到了上限。通过 V4L2 读取的数据证实，AE 暴露量不到配置上限的一半。 LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png 通过实时控制手动配置曝光时，有效曝光量可达 150000，V4L2 曝光量也可达到上限。 我们怀疑这个问题与 RowTime 有关。我们修改了 AE Dister 中的 Row Time 参数，但此更改没有显示出任何明显效果；自动曝光性能与以前完全相同。 我们想知道需要进行哪些调整才能使 AE 算法在弱光条件下达到配置的最大曝光量。 Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure 根据目前的表现来看，AE 算法似乎受限于活动传感器模式帧持续时间，而不是绝对手动曝光能力。值 66666 us 对应于每秒 15 帧的一帧。因此，即使 AE LIMITS 最大值设置为 150000 us ，除非活动传感器定时允许帧周期超过 150 毫秒，或者驱动程序/辅助路径在编程曝光之前延长 VBLANK/帧长度，否则 AE 也无法应用它。 请检查传感器驱动程序是否公开并正确更新 V4L2_CID_EXPOSURE 、 V4L2_CID_VBLANK 、 V4L2_CID_HBLANK 和 V4L2_CID_PIXEL_RATE 。要使低光照 AE 达到 150000 us ，活动帧速率必须降低到大约 6.67 fps 或更低，或者 AE 控制路径必须动态增加 VBLANK/帧长度。如果通过 V4L2/CameraHelper 路径报告的活动曝光范围保持在约 66666 us 以内，则单独更改 AE Dister 中的行时间可能不会影响 AE。 请确认修改后的 AE 参数已保存到 config_ipa_uguzzi.yaml 引用的活动 DTP 文件中，并复制到 /usr/share/libcamera/ipa/nxp/neo/uguzzi/ ，且相机流程已重新启动或已应用相应的算法重新配置。实时控制更改通常是暂时的，除非保存到项目/DTP 或通过正确的重新配置路径应用。 我的建议：首先将其视为帧持续时间/垂直消隐曝光范围问题，然后验证 DTP/配置文件激活情况。手动曝光达到 150000 us 的事实很有用，但这并不能证明 AE 循环可以请求该值，除非 AE 可见的曝光范围和帧时间也进行了更新。

frdm-i.mx93 无法在 M33 之后启动准备就绪；Linux 和 Windows 上的 UUU SDPS 启动超时 您好，恩智浦技术支持、 我正在请求帮助恢复 FRDM-i.MX93 主板。在 “M33 准备就绪” 之后，板在早期的 SPL 启动期间会立即停止，并且不会继续运行 BL31 或完全 U-Boot。在 SDPS 启动期间，UUU 恢复也会因超时而失败。 董事会详情： 板：FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的串行输出： U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok 重建的 2025 SPL 也出现了同样的停止点： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000） PMIC：PCA9451A PMIC：过载电压模式 DDR：3733MTS DDR：3733 MTS DDR：3733MTS M33 准备好了 使用的硬件设置： P1 = 外部电源，使用 45 W USB-C 墙式适配器进行测试 P16 = 调试串行控制台 P13 = microSD 卡插槽 P2 = 用于 UUU / 串行下载器模式的 USB-C 连接 我还测试了用墙壁适配器供电，而不是用电脑 USB 供电。行为没有改变。 测试的主机系统： Linux Mint / Ubuntu 主机 Windows 主机 已测试的 UUU 版本： uuu 1.5.141 uuu 1.5.243 主要问题是电路板达到 SPL，初始化 PMIC 和 DDR，然后打印 “M33 准备就绪”，然后什么也没发生。它永远不会达到 “正常启动”、“正在尝试从 BOOTROM 启动”、“注意：BL31” 或完整 U-Boot。从 SD 和 eMMC 启动时会发生这种情况。 在 USB 串行下载器模式下，UUU 会检测到主板： sudo ./uuu-lsusb 连接的已知 USB 设备 路径芯片 Pro Vid Pid bcdVersion 5:2 MX93 SDPS： 0x1FC9 0x014E 0x0001 但是，在 SDPS 启动期间，UUU 会失败。使用的命令是 sudo ./uuu-V-b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst 在 Linux 系统上，故障是 启动 cmd: sdps: boot-scanterm-f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT 在 Windows 系统中，故障是 启动 cmd: sdps: 启动-scanterm-f。\ imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 14% 失败 HID (W)：LIBUSB_ERROR_TIMEOUT (-7) 在 Linux 和 Windows 上进行了测试，结果相同。 测试过的图像： 我测试了恩智浦官方 frdm-i.mx93 Rev 4.0 演示映像包： LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 启动映像哈希值为： 7aba6102e5ec64add64add632cd6667e77fa3f6f6f6f6f6f6fd72c314e4c01f2964c0fc056a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 我还测试了自己的 Yocto 镜像 imx93frdm，它使用相同的启动映像哈希值。 我验证了 SD 启动选择是否有效。在未插入 SD 卡的 SD 启动模式下，没有串行输出。在插入 SD 卡的 SD 启动模式下，SPL 在 “M33 准备就绪” 时开始和停止。因此，SD 启动开关似乎正在工作。 我还验证了恩智浦官方的 .wic映像包含预期偏移量为 32 KiB/0x8000 的启动映像。使用的命令 wic=nxp.wic 启动=imx -启动-imx93frdm-sd.bin-flash_singleBoot xxd -l 64 -s $((32*1024))"$WIC" xxd -l 64 -s 0"$BOOT" cmp-n " $ (stat-c%s " $BOOT ") "-i $ ((32*1024)): 0 " $WIC " " $BOOT " & & echo " " NXP WIC 包含 32K 的启动映像" 恩智浦 WIC 不包含 32K 的启动映像 " 结果： 恩智浦 WIC 包含 32K 的启动映像 因此，SD 映像似乎正确包含了启动容器。 为了排除只有 2024.04 SPL 映像是问题所在，我使用 Flexbuild/U-Boot 构建了一个更新的启动映像。内置映像中的 SPL 显示： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000）恩智浦 FRDM-IMX93 我将这个新的 flash.bin 文件写入 SD 卡，偏移量为 32 KiB： sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync 然后，主板打印了新的 SPL 标语，确认它正在执行新的 SD 启动映像： U-Boot SPL 2025.04（2026 年 4 月 26 日-16:21:54 +0000） PMIC：PCA9451A PMIC：过载电压模式 DDR：3733MTS DDR：3733 MTS DDR：3733MTS M33 准备好了 但是，它仍然在同一时间停止了，没有继续使用BL31/Full U-Boot。 eMMC 状态： 最初，eMMC 启动到足以登录 Linux 的程度，但由于根文件系统中缺少 /bin/sh，根登录被中断。在尝试恢复过程中，eMMC 使用 .wic 文件从 SD Linux 重写。图像之后，在 “M33 准备就绪” 之后，eMMC 启动也会停止。但是，使用恩智浦官方镜像启动SD时以及重建的2025 SPL也会出现同样的停止点，因此当前的问题似乎早于Linux/rootFS。 我所相信的已经被排除： 串行端口错误：串行端口正常工作并显示 SPL 输出。 电脑电源不良：使用外置 45 W 墙式适配器测试。 错误的 SD 启动开关：没有 SD 卡的 SD 启动模式没有输出。 SD 映像中缺少启动映像：经过验证的启动映像存在于恩智浦官方 WIC 中的 0x8000/32 KiB。 Linux/rootFS 问题：故障发生在 BL31/Full U-Boot/Linux 之前。 UUU 的主机操作系统问题：UUU SDPS 启动超时出现在 Linux 和 Windows 上。 只有旧的 2024 SPL 是坏的：重建的 2025.04 SPL 也在 "M33 准备就绪 "后停止。 你能帮忙确定这是否是已知的 frdm-i.mx93 提前启动问题吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你在使用我们发布的 BSP 版本吗？ 适用于i.MX应用处理器的嵌入式Linux|恩智浦半导体 您正在使用并选择哪个版本的 BSP？ 劳动节回来后，我会尝试在我们的电路板上进行测试，我将在下周三回到办公室然后进行测试，然后给你回复我的测试结果。 祝您有美好的一天 顺祝商祺！ Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我使用的是 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93。图像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我回到办公室将在我们的板上进行测试，然后告诉你结果。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你想出来了吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 我也遇到了同样的问题…… 我从未见过 BL31 使用我的 imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap 版本启动。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 您好，我目前也遇到了同样的问题。请问您找到解决方法了吗？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到同样的问题。是否有任何更新需要进行哪些操作才能使 imx93 从 SD 卡启动，或者使 UUU 正常工作？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我们注意到该主板上的内存芯片与其他frdm-imx93主板有所不同。或许这有助于找到问题所在。 正常工作的板是微米级的，而故障板的品牌我不认识。   IMG_7007.jpegIMG_7007.jpeg   Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到了同样的问题。 这应该标记为高优先级，因为唯一可用的映像是出厂时在 eMMC 上提供的映像！如果重新刷写固件，我的 FRDM-IMX93 就彻底报废了，直到找到解决方案为止，我怀疑这与 DDR 内存时序有关。 我的程序也卡在了“M33 prepare ok”这里，这表明DDR配置/时序存在问题，而且我的主板也和上面@SynchronicIT帖子中的一样，使用了相同的“无名”DDR IC（制造商标志带有“J”）。 为什么这些电路板可以出厂时就带有 eMMC 上的可用镜像，而 NXP 提供的所有可用镜像都无法使用？ 当我通过（出厂预装的）eMMC启动时（启动正常），u-boot 版本为： U-Boot SPL 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） 而从 NXP 下载的最新版本 (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip)“imx-boot-imx93frdm-sd.bin-flash_singleboot”文件是 u-boot 版本： U-Boot SPL 2024.04+gde16f4f1722+p0（2024年9月2日 10:44:35 +0000） 下面显示的是正常工作的工厂镜像 eMMC 的完整输出，以及不正常工作的 SD 卡刷入镜像和 UUU 上传的 u-boot 的完整输出。 * 工作正常（出厂预装eMMC）* U-Boot SPL 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） PMIC：PCA9451A PMIC：过驱动电压模式 DDR：3733MTS 找到匹配的 DRAM 2CS_2GB DRAM M33 准备就绪 正常启动 尝试从 BOOTROM 启动 启动阶段：主启动 图像偏移量 0x8000，页面大小 0x200，ivt 偏移量 0x0 通过 ROM_API 从 0x57800 加载镜像 注意：TRDC 初始化完成 通知：BL31：v2.12.0（版本）：lf-6.18.2-1.0.0 通知：BL31：建造时间：2026年2月10日 07:53:18 U-Boot 2025.04-g99518e6b6f20（2026年2月2日 05:52:54 +0000） 重置状态：POR CPU：NXP i.MX93(52) Rev1.2 A55，频率 1700 MHz CPU：工业级温度范围（-40℃至105℃），工作温度24℃ 型号：NXP FRDM-IMX93 动态随机存取存储器(DRAM)：2 GiB 板：V1.0（ADC2：684，ADC3：271） TCPC：供应商 ID [0x1fc9]，产品 ID [0x5110]，地址 [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0：0 型，5000 mV，3000 mA [E] PDO 1：0 型，9000 mV，3000 mA [] PDO 2：0 型，12000 mV，3000 mA [] PDO 3：0 型，15000 mV，3000 mA [] PDO 4：0 型，20000 mV，3250 mA [] PDO 5：类型 3，未定义 请求 PDO 4：20000 mV，750 mA 源接受请求 PD源已准备就绪！ tcpc_pd_receive_message：轮询 ALERT 寄存器，TCPC_ALERT_RX_STATUS 位失败，返回值为 -62 TCPC：供应商 ID [0x1fc9]，产品 ID [0x5110]，地址 [I2C2 0x50] 核心：229 个设备，32 个微类，设备树：独立 MMC：FSL_SDHC：0，FSL_SDHC：1 从 MMC 加载环境... 从 MMC(0) 读取... *** 警告 - CRC 校验错误，使用默认环境 视频链接设置失败 输入：串行 输出：串口 错误：串行 构建信息： - ELE固件版本2.0.5-7a34cee 切换到分区 #0，确定 mmc0（第 0 部分）是当前设备 UID：4a7ff07fa81b46d8b2b59146dfa5af84 闪存目标是 MMC:0 网络：eth0：以太网@42890000，eth1：以太网@428a0000 [PRIME] Fastboot：正常 正常启动 按任意键停止自动启动：0 u-boot=> * 无法正常工作 * U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok - 悬挂 - Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到了同样的问题。我无法通过 uuu.exe 刷入任何镜像，输出相同的“HID(W): LIBUSB_ERROR_TIMEOUT (-7)”错误。我主板上的内存芯片也是“J”牌的，而不是美光的。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 补充一点关于具体 DDR 部件信息的数据，因为我认为替换的内存是关键，但我还没有看到确切的部件编号公布。 **板：** FRDM-IMX93，SCH-94611 REV B2（电路板标签 DRQ30063390） **SoC：** i.MX93(52) Rev1.2SOC 0xa1009300，LC 0x2040010 **PMIC：** PCA9451A **DDR：**原理图和用户指南指定使用 LPDDR4x Micron MT53E1G16D1FW-046。我板上实际安装的芯片标记为**JSL4BAG167ZAMF** — 而不是 Micron。这与本帖中其他人报告的情况一致（故障主板上使用“J”品牌的DDR内存，而正常工作的主板上使用Micron品牌的DDR内存）。 **问题出在DDR训练/验证环节，而非M33/ELE环节。**将正常工作的工厂 eMMC 启动程序与出现故障的公共电路板支持包。启动程序进行比较，就能清楚地看出这一点： 工作正常（工厂 eMMC、U-Boot SPL 2025.04，BL31 lf-6.18.2-1.0.0): ``` DDR：3733MTS 找到匹配的 动态随机存取存储器\(DRAM\) 2CS_2GB 动态随机存取存储器\(DRAM\) M33 准备就绪 正常启动 ... ``` 失败 (LF_v6.6.36-2.1.0)公开版本（U-启动 SPL 2024.04，2024 年 9 月 2 日）： ``` DDR：3733MTS DDR：3733MTS M33 准备就绪 - 悬挂 - ``` 正常工作的引导加载程序中存在“找到 动态随机存取存储器\(DRAM\) ... 动态随机存取存储器\(DRAM\) 匹配”这一行，而故障的引导加载程序中则不存在这一行。主板卡在了 DDR 验证即将完成的时刻，也就是 BL31 / 正常启动之前。所以这看起来像是 6.6.36 版本。DDR配置/时序与替换的DDR部件不匹配，而不是下游部件的问题。 正常工作的 eMMC 引导加载程序还报告 **ELE 固件版本 2.0.5-7a34cee**，比 6.6.36 代码包，软件包中提供的版本更新——注意，以防修复取决于 DDR 时序和 ELE 版本。 **为了节省时间，我已经排除了以下可能性**： - 版本：我自己的 Yocto imx93frdm 构建生成的 imx-启动 与工厂代码包，软件包 (sha256 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f) 字节级完全相同，所以这不是构建问题。 - SD 刷写：已验证启动容器大小为 32 KiB (0020 0287 magic)，有效的 MBR (55aa)，以及引导加载程序区域中的两个 FIT magic。 - 启动开关：SD 模式下，如果没有卡，则不会有串行输出；插入卡后，SPL 可以运行——因此 USDHC2/SD 选择是正确的。 - 电源：使用多个 USB-C 电源时结果相同。 - 主机/USB：在两个不同的 Linux 主机上，UUU SDPS 启动失败，出现 HID(W): LIBUSB_ERROR_TIMEOUT 错误。 - 硬件本身很好：板启动其出厂 eMMC 映像到 Linux，因此 DDR *可以* 由正确的引导加载程序进行训练。 **问题：** 1.适用于 REV B2 板卡的修正版 DDR 配置（非 Micron (JSL4BAG167ZAMF) DDR）是否已在任何当前公开的 电路板支持包。中提供？例如，6.6.52-2.2.0 或 6.12.x 版本——还是仅限于目前在 eMMC 上提供的较新的引导加载程序 (lf-6.18.2)？ 2. 如果尚未有公开版本，是否可以发布更新后的 FRDM-IMX93 DDR 时序接头（或 lf-6.18.2 FRDM 引导加载程序），以便 SD 卡启动可以在这些板上工作？ 如果这有助于缩小问题范围，我很乐意在这个板上运行诊断程序或测试候选引导加载程序/时序配置。 谢谢， jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 后续提供可行的解决方案，希望能帮助本帖中其他使用相同板/DDR组合的用户。 摘要：此次故障是公共 LF6.6.36-2.1.0 版本中的 DDR 训练问题。较新的 FRDM-IMX93 板上的电路板支持包，这些板配备了替代的（非 Micron）LPDDR4X 内存。升级到 **LF6.18.2 (Whinlatter) 电路板支持包。** 即可解决此问题——板可以训练其 DDR 并从 SD 卡正常启动。 板/DDR（参考，引用）： - FRDM-IMX93，SCH-94611 REV B2 - 原理图上标明的是 Micron MT53E1G16D1FW 芯片；实际安装的芯片标记为 JSL4BAG167ZAMF（非 Micron 替代芯片）。 最终确认根本原因的是：工厂 eMMC 镜像（可以正常启动）使用了较新的引导加载程序——U-Boot SPL 2025.04。BL31 lf-6.18.2，内核 6.18.2 — 其 SPL 打印“找到 动态随机存取存储器\(DRAM\) 2CS_2GB 动态随机存取存储器\(DRAM\) 匹配”，然后“M33 准备正常”。公开的 LF6.6.36SPL（U-启动 2024.04）不打印`动态随机存取存储器\(DRAM\) 已匹配`，并卡在`M33 准备正常`。 所以是 6.6.36DDR 配置不会训练这种替代内存，而 6.18.2 配置会。 工作流程——构建并启动 LF6.18.2 电路板支持包。： mkdir imx-bsp-6.18.2 && cd imx-bsp-6.18.2 仓库 init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml 仓库同步 发行版。=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-frdm source sources/meta-imx/tools/imx-setup-版本.sh -b 版本-frdm bitbake imx-image-core   请注意，机器名称为 `imx93-11x11-lpddr4x-frdm`（此电路板支持包。的原生名称——与 6.6.36 不同，不需要单独的 meta-imx-frdm 层）。 然后将生成的 `.wic.zst` 烧录到 SD 卡（解压缩并使用 dd 命令烧录到整个卡设备），将启动开关设置为 SD 卡（SW1 = 1 1 0 0），然后启动。REV B2 / JSL DDR 板的结果： DDR：3733MTS 找到匹配的 动态随机存取存储器\(DRAM\) 2CS_2GB 动态随机存取存储器\(DRAM\) M33 准备就绪 正常启动 ... NXP FRDM-IMX93 登录： `free -h` 确认全部 2GB 内存已训练完毕并可用。 NXP方面仍存在疑问：是否有计划将更新后的FRDM DDR配置向后移植到LF6.6.36-2.1.0？分支，供需要继续使用 6.6.36 版本的人使用？对于能够升级到 6.18.2 的用户来说，上述方法有效。 希望这能帮到其他人，省去调试的麻烦。 jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 嗨，丽塔， 请问这件事有任何最新进展吗？我们被这个问题困住了。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我已使用演示镜像 images LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 在我们的 93FRDM REV B 版本板上进行了测试， 使用 UUU uuu 工具版本 uuu_1.5.243 分别在SD卡和eMMC上尝试，下载和启动都成功，没有重现您遇到的错误。 .\uuu.exe -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Rita_Wang_0-1786613213510.pngRita_Wang_0-1786613213510.png Rita_Wang_1-1786613222942.pngRita_Wang_1-1786613222942.png Rita_Wang_2-1786613231468.pngRita_Wang_2-1786613231468.png Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 看来问题出在REV B2板上。请在REV B2上尝试一下 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 大家好。 @Rita_Wang这不是“修改”的问题。我桌上有两块主板，版本相同，但LP DDR芯片不同。 然而，以下是你们团队的原话： LFU-956 imx93_frdm：为 i.MX93 FRDM 添加 2CS 2GB 动态随机存取存储器(DRAM) 支持 FRDM-IMX93 使用 Micron MT53E1G16D1FW 1CS 动态随机存取存储器(DRAM)，但该芯片已停产。它将替换为 JSC JSL4BAG167ZAMF 2CS 动态随机存取存储器(DRAM)。对 1G 动态随机存取存储器\(DRAM\) 的支持将被取消。 在 i.MX93 FRDM 上添加 2CS 2GB 动态随机存取存储器\(DRAM\) 支持，以支持基于 1CS 和 2CS 动态随机存取存储器\(DRAM\) 的 FRDM-IMX93 板。 这是因为这两个芯片（见附图）具有不同的时序参数。正如@jjudk所说，唯一的解决办法是升级到新版本的固件。 就我而言，我只能继续使用旧版本。因此，我直接挑选了所需的补丁（请看这里： https ://github.com/nxp-imx/uboot-imx/commit/4c35a6086aedca2f6220382920242ad81ae372f6 ） 如果还有人遇到问题，我可以提供预编译好的版本。 -加布里埃尔

FRDM-i.MX93はM33準備完了以降に起動できません。LinuxとWindowsでUUU SDPSの起動がタイムアウトします。 こんにちは、NXPサポート様 FRDM-i.MX93ボードの復旧についてご協力をお願いします。ボードは、SPLブートの初期段階で「M33 prepare ok」の直後に一貫して停止し、BL31または完全なU-Bootに進みません。UUUリカバリもSDPSの起動中にタイムアウトで失敗します。 役員の詳細： ボード: FRDM-i.MX93 シリアルログに表示されるSoC：0xa1009300 シリアルログに表示されたLC: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的なシリアル出力： U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 再構築された2025 SPLでも、同じ停止ポイントが発生します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 使用したハードウェア構成： P1 = 外部電源、45W USB-Cウォールアダプターでテスト済み P16 = デバッグ用シリアルコンソール P13 = microSDカードスロット P2 = UUU / シリアルダウンローダーモード用のUSB-C接続 PCのUSB電源ではなく、壁のコンセント用アダプターから電源を供給するテストも行いました。行動に変化は見られなかった。 テスト対象のホストシステム： Linux Mint / Ubuntu ホスト Windowsホスト UUUのバージョンをテストしました： ううう 1.5.141 ううう 1.5.243 主な問題は、ボードがSPLに到達し、PMICとDDRを初期化して「M33 prepare ok」と出力した後、何も起こらないことです。「Normal Boot」、「Trying to boot from BOOTROM」、「NOTICE: BL31」、または完全な U-Boot に到達しません。これは、SDカードとeMMCの両方から起動した場合に発生します。 USBシリアルダウンローダーモードでは、ボードはUUUによって検出されます。 sudo ./uuu-lsusb コネクテッド Known USB Devices パスチッププロビデオPID Bcdバージョン 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 しかし、SDPSの起動中にUUUが失敗します。使用されたコマンドは次のとおりです。 sudo ./uuu-V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Linuxでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 HID(W)エラー:LIBUSB_ERROR_TIMEOUT Windowsでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7) これはLinuxとWindowsの両方でテストされ、同じ結果が得られました。 テスト対象画像： NXP公式FRDM-i.MX93 Rev 4.0デモイメージパッケージをテストしました。 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ブートイメージのハッシュ値は次のとおりです。 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 私は、同じブートイメージハッシュを使用するimx93frdm用の独自のYoctoイメージもテストしました。 SDカードからの起動選択が機能することを確認しました。SDカードが挿入されていないSDブートモードでは、シリアル出力はありません。SDカードを挿入したSDブートモードでは、SPLは起動して「M33 prepare ok」で停止します。SDカードブートスイッチは正常に動作しているようです。 また、公式のNXP .wicファイルも確認しました。イメージには、想定される32 KiB / 0x8000オフセットにブートイメージが含まれています。使用したコマンド: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WICには32Kにブートイメージが含まれています" || echo "NXP WICには32Kにブートイメージは含まれていません" 結果: NXP WICには32Kのブートイメージが含まれています つまり、SDカードイメージにはブートコンテナが正しく含まれているようです。 2024.04 SPLイメージだけが問題の原因ではないことを確認するため、Flexbuild/U-Bootを使用してより新しいブートイメージを作成しました。構築されたイメージ内のSPLは以下を示します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) NXP FRDM-IMX93 私は以下の方法で、この新しい flash.bin ファイルを SD カードの 32 KiB オフセットに書き込みました。 sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync 同期 その後、ボードは新しいSPLバナーを印刷し、新しいSDブートイメージが実行されていることを確認した。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK しかし、それでも同じ箇所で停止し、BL31/完全なU-Bootまでは進みませんでした。 eMMCの状態： 当初、eMMCはLinuxログイン画面まで起動したが、ルートファイルシステムに/bin/shが存在しなかったため、rootログインができなかった。復旧試行中に、eMMCは.wicファイルを使用してSD Linuxから書き換えられた。画像。その後、eMMCブートも「M33 prepare ok」の後に停止します。しかし、同じ停止ポイントは、公式のNXPイメージを使用したSDブートと、再構築された2025 SPLを使用した場合にも発生するため、現在の問題はLinux/rootfsよりも前の段階にあるようです。 私が除外されたと考えること： シリアルポートが間違っています：シリアル接続は正常に動作し、SPL出力が表示されます。 PCの電源不良：45Wの外部ACアダプターを使用してテストしました。 SDカードブートスイッチの設定が間違っています：SDカードが入っていない状態でSDブートモードにすると、何も出力されません。 SDイメージにブートイメージがありません：公式NXP WICの0x8000 / 32 KiBにブートイメージが存在することが確認されています。 Linux/rootfsの問題：BL31/完全なU-Boot/Linuxの前に障害が発生します。 UUUのホストOSの問題：UUU SDPSの起動タイムアウトがLinuxとWindowsの両方で発生します。 古い2024 SPLだけが問題で、再構築された2025.04 SPLも「M33 prepare ok」の後に停止します。 これがFRDM-i.MX93の既知の早期起動問題かどうか、確認にご協力いただけますでしょうか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 弊社がリリースしたBSPバージョンをご利用ですか？ i.MXアプリケーション・プロセッサ向け組み込みLinux | NXP Semiconductors どのバージョンのBSPを使用していますか？また、どのバージョンを選択していますか？ 労働者の休暇から戻り次第、当社のボードでテストしてみます。来週の水曜日にオフィスに戻り、テストを実施してから、テスト結果をご報告します。 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私はLF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93を使用しています。画像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows オフィスに戻りましたので、ボードでテストを行い、結果をお知らせします。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 解決できましたか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 同じ問題が発生しています... 私のimx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgapビルドでは、BL31が起動を開始したのを見たことがありません。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows こんにちは、私も現在同じ問題を抱えています。解決策は見つかりましたか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題に直面しています。imx93がSDカードから起動できるようにするため、あるいはUUUが正常に動作するようにするために必要なアップデートはありますか？ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 他のFRDM-IMX93ボードと比較して、このボード上のメモリチップに違いがあることに気づきました。これが問題解決の手がかりになるかもしれません。 正常に動作する基板にはミクロン製の部品が使われており、故障した基板には見覚えのないメーカーの部品が使われている。   IMG_7007.jpegIMG_7007.jpeg   Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題を抱えています。 これは最優先事項としてマークされるべきです。なぜなら、唯一正常に動作するイメージは、工場出荷時にeMMCに搭載されているものだけだからです！もしそれを再フラッシュしたら、解決策が見つかるまでFRDM-IMX93は起動不能な状態になってしまうでしょう。これはDDRメモリのタイミングに関係しているのではないかと疑っています。 私も「M33 prepare ok」で止まってしまいます。これはDDRの設定/タイミングの問題を示しています。私のボードにも、上記の@SynchronicITさんの投稿と同じ「ノーネーム」DDR IC（メーカーロゴに「J」が付いているもの）が搭載されています。 なぜこれらのボードはeMMCで動作イメージを付けて出荷できるのに、NXPのどの画像も動作しないのでしょうか? 工場出荷時に搭載されているeMMC経由で起動した場合（これは正常に動作します）、u-bootのバージョンは以下のとおりです。 U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) 一方、NXPからの最新ダウンロード（LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip）では、「imx-boot-imx93frdm-sd.bin-flash_singleboot」ファイルはU-Bootのバージョンです。 U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) 以下は、正常に動作する工場出荷時イメージのeMMC、および動作しないSDカードに書き込まれたイメージとUUUにアップロードされたu-bootからの完全な出力です。 * 動作確認済み（工場出荷時設定のeMMC搭載） * U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DRAM 2CS_2GB DRAMが一致しました M33準備OK 通常起動 BOOTROMから起動しようとしています ブートステージ:プライマリブート 画像オフセット 0x8000、ページサイズ 0x200、IVT オフセット 0x0 ROM_APIを使用して0x57800からイメージをロードします 通知：TRDC初期化完了 お知らせ：BL31：v2.12.0（リリース）：lf-6.18.2-1.0.0 お知らせ：BL31：製造日時：2026年2月10日 07:53:18 U-Boot 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) リセットステータス: POR CPU:NXP i.MX93(52) Rev1.2 A55、1700 MHz CPU:インダストリアル温度グレード(-40°Cから105°C)、24°Cで対応 モデル:NXP FRDM-IMX93 DRAM:2 GiB ボード:V1.0(ADC2:684、ADC3:271) TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x52] 無駄。CC1でのPower3.0 PDO 0:タイプ0、5000 mV、3000 mA [E] PDO 1:タイプ0、9000 mV、3000 mA [] PDO 2:タイプ0、12000 mV、3000 mA [] PDO 3:タイプ0、15000 mV、3000 mA [] PDO 4:タイプ0、20000 mV、3250 mA [] PDO 5:タイプ3、未定義 PDO 4を要請:20000 mV、750 mA ソース受理リクエスト PDソース準備完了! tcpc_pd_receive_message:ALERTレジスタのポーリング、TCPC_ALERT_RX_STATUSビット失敗、ret = -62 TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x50] コア:229デバイス、32 uクラス、devicetree:別々 MMC: FSL_SDHC: 0, FSL_SDHC: 1 MMCからの読み込み環境...MMC(0)から読み上げています... *** 警告 - CRCが悪い、デフォルト環境を使用しています ビデオリンクの設定に失敗しました 掲載: シリアル 出力: シリアル エラー: シリアル ビルド情報: - ELEファームウェアバージョン2.0.5-7a34cee パーティション#0に切り替える、OK MMC0(パート0)は電流装置です UID: 4a7ff07fa81b46d8b2b59146dfa5af84 フラッシュターゲットはMMC:0です ネット:eth0: ethernet@42890000、eth1: ethernet@428a0000 [プライム] 速攻:通常 通常起動 自動起動を停止するには、任意のキーを押してください: 0 u-boot=> *動作しません* U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK - 下がる - Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題を抱えています。uuu.exe を介してイメージをフラッシュしようとしましたが、同じ「HID(W): LIBUSB_ERROR_TIMEOUT (-7)」エラーが出力されました。私のマザーボードに搭載されているメモリチップも、Micron製ではなく「J」ブランドのものです。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows DDR部品の具体的な情報を含むデータポイントをもう一つ追加します。というのも、交換されたメモリがこの問題の鍵となると思うのですが、正確な部品番号がまだ投稿されていないからです。 **ボード:** FRDM-IMX93、SCH-94611 REV B2(ボードラベルDRQ30063390) **SoC:** i.MX93(52) Rev1.2,SOC 0xa1009300、LC 0x2040010 **PMIC:** PCA9451A **DDR:** 回路図およびユーザーガイドにはLPDDR4x Micron MT53E1G16D1FW-046と明記されています。私の基板に実際に取り付けられているチップには、**JSL4BAG167ZAMF**と刻印されています。Micron製ではありません。これはこのThreadの他の方々の報告と一致しています(故障している基板には「J」ブランドのDDRと、動作する基板ではMicronが比較的)。 **失敗はDDRのトレーニング・検証時に発生しており、M33/ELEではありません。**正常に動作する工場出荷時のeMMCブートと、失敗するパブリックBSPブートを比較すると、次の点が明らかになります。 動作中 (工場出荷時の eMMC、U-Boot SPL 2025.04、BL31 lf-6.18.2-1.0.0): 「`」 DDR: 3733MTS DRAM 2CS_2GB DRAMが一致しました M33準備OK 通常起動 ... 「`」 失敗しました (LF_v6.6.36-2.1.0一般公開、U-Boot SPL 2024.04 2024年9月2日): 「`」 DDR: 3733MTS DDR: 3733MTS M33準備OK - 下がる - 「`」 正常に動作するブートローダーには「found DRAM ... DRAM matched」という行が存在し、不具合のあるブートローダーには存在しない。ボードは、DDR検証が完了する直前、つまりBL31/通常起動の直前のまさにその時点で停止します。これは6.6.36のようです。DDRの構成/タイミングが、交換されたDDR部品と一致していないことが原因であり、下流側の何かに問題があるわけではありません。 動作するeMMCブートローダーは、6.6.36パッケージに付属しているものよりも新しいELEファームウェアバージョン2.0.5-7a34ceeも報告しており、修正がDDRのタイミングとELEバージョンの両方に依存している可能性があることに注意してください。 **私が除外できたこと**、サイクルを節約するために: - ビルド:私自身のYocto imx93frdmビルドは、純正パッケージ(sha256 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f)と同一バイトのimx-bootを生成するため、これはビルドの問題ではありません。 - SD フラッシュ: ブート コンテナが 32 KiB (0020 0287 マジック) で検証され、有効な MBR (55aa) とブートローダー領域に 2 つの FIT マジックが確認されました。 - ブートスイッチ:カードなしのSDモードではシリアル出力はなし;カードを使うとSPLが動作するため、USDHC2/SDの選択は正しいです。 - 電源：複数のUSB-C電源で同じ結果が得られました。 - ホスト/USB:UUU SDPSの起動がHID(W: LIBUSB_ERROR_TIMEOUT)で2つの異なるLinuxホストで失敗します。 - ハードウェア自体は良好です。ボードは工場出荷時のeMMCイメージをLinuxに起動するため、DDRは正しいブートローダーで学習可能です。 **質問:** 1.非Micron (JSL4BAG167ZAMF) DDRを搭載したREV B2ボード用の修正済みDDR構成は、現在公開されているBSP（例：）で入手できますか？6.6.52-2.2.0 または 6.12.x リリースでしょうか？それとも、現在 eMMC に搭載されている新しいブートローダー (lf-6.18.2) のみでしょうか？ 2. もしまだ公開されていない場合、更新されたFRDM-IMX93のDDRタイミングヘッダー(またはlf-6.18.2 FRDMブートローダー)を公開して、SO、これらのボードでSDブートが動作するようにすることは可能でしょうか? もしそれが問題の絞り込みに役立つのであれば、このボード上で診断を実行したり、候補となるブートローダーやタイミング設定をテストしたりしても構いません。 ありがとう、 jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 同じ基板とDDRの組み合わせを持つ他の方の参考になればと思い、このThreadで動作する解決策を続けてお知らせします。 概要:この失敗は公開版LF6.6.36-2.1.0におけるDDRトレーニングの問題です。代替品（Micron製ではない）LPDDR4Xを搭載した新しいFRDM-IMX93ボード上のBSP。**LF6.18.2 (Whinlatter) BSP** に移行すると問題が解決し、ボードが DDR をトレーニングして SD から正常に起動します。 ボード／DDR（参考用）： - FRDM-IMX93、SCH-94611 REV B2 回路図ではMicron MT53E1G16D1FWが指定されていますが、実際に取り付けられているチップはJSL4BAG167ZAMF（Micron製以外の代替品）と表示されています。 根本原因を確認できたのは、工場出荷時のeMMCイメージ（正常に起動する）が新しいブートローダーであるU-Boot SPL 2025.04を使用していることだった。BL31 lf-6.18.2、カーネル6.18.2 — そのSPLは`M33 prepare ok`の前に`found DRAM 2CS_2GB DRAM matched`と出力します。公開LF6.6.36SPL (U-Boot 2024.04)`DRAM matched` と表示されず、`M33 prepare ok` でハングアップします。つまり6.6.36DDR構成ではこの置換メモリはトレーニングされませんが、6.18.2構成ではトレーニングされます。 作業手順 — LF6.18.2 BSPをビルドして起動する： mkdir imx-bsp-6.18.2 && cd imx-bsp-6.18.2 リポ init -u https://github.com/nxp-imx/imx-manifest-b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml リポジトリ同期 DISTRO=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-frdm ソースソース/meta-imx/tools/imx-setup-release.sh -b build-frdm Bitbake imx-image-core   マシン名は `imx93-11x11-lpddr4x-frdm` であることに注意してください（これはこの BSP に固有のもので、6.6.36 とは異なり、別途 meta-imx-frdm レイヤーは必要ありません）。 その後、得られた「.wic.zst」をSDにフラッシュし(解凍とddをカードデバイス全体にフラッシュ)、起動スイッチをSDに設定(SW1 = 1 1 0 0)して起動します。REV B2 / JSL DDRボードでの結果： DDR: 3733MTS DRAM 2CS_2GB DRAMが一致しました M33準備OK 通常起動 ... NXP FRDM-IMX93 ログイン: `free -h`を実行すると、2GBすべてが学習済みで利用可能であることが確認できます。 NXPへの質問：更新されたFRDM DDR構成をLF6.6.36-2.1.0にバックポートする予定はありますか？6.6.36 を使い続ける必要がある人向けのブランチですか？バージョン6.18.2に移行できる場合は、上記の手順で問題ありません。 これが誰かのデバッグ作業の手間を省くのに役立てば幸いです。 jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows こんにちは、リタさん。 この件について何か進展はありますか？私たちはこの問題で行き詰まっています。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows デモイメージ LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 を使用して、当社の 93FRDM REV B バージョンボードでテストを行いました。 UUU uuuツールリリースuuu_1.5.243を使用する SDカードとeMMCの両方で試しましたが、ダウンロードと起動は成功し、発生したエラーは再現されませんでした。 .\uuu.exe -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Rita_Wang_0-1786613213510.pngRita_Wang_0-1786613213510.png Rita_Wang_1-1786613222942.pngRita_Wang_1-1786613222942.png Rita_Wang_2-1786613231468.pngRita_Wang_2-1786613231468.png Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows どうやら問題はREV B2基板にあるようです。REV B2で試してみてください Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows やあみんな。 @Rita_Wangこれは「改訂」の問題ではありません。私の机の上には、同じリビジョンだがLP DDRチップが異なる2枚の基板がある。 しかし、あなたのチームからの発言をそのまま引用すると次のようになります。 LFU-956 imx93_frdm:i.MX93 FRDM に 2CS 2GB DRAM サポートを追加する FRDM-IMX93はMicron MT53E1G16D1FW 1CS DRAMを使用していますが、これは既に生産終了しています。JSC JSL4BAG167ZAMF 2CS DRAMに交換します。そして1G DRAMのサポートは終了します。 i.MX93 FRDM上で2CS 2GB DRAMサポートを追加し、1CSおよび2CS DRAMベースのFRDM-IMX93ボードの両方をサポートします。 それは、添付画像にある2つのチップのタイミングパラメータが異なるためです。@jjudkさんが述べたように、これを機能させる唯一の方法は、ファームウェアを新しいバージョンにアップデートすることです。 私の場合は、古いものを使い続けなければなりませんでした。そのため、必要なパッチだけを抜き出しました（こちらをご覧ください： https://github.com/nxp-imx/uboot-imx/commit/4c35a6086aedca2f6220382920242ad81ae372f6 ）。 もしまだ問題がある方がいれば、完成品をお渡しできます。 -ガブリエレ

LX2162A USXGMIIリンクが完了しない みなさん、こんにちは。 私はSolidrun社製のLX2162A SoMを所有しています。Clearfogの開発キットを使用していますが、近いうちにカスタムキャリアに移行する予定です。 Solidrunは基本的なRCW/DCP/DPLを提供しており、その機能は確認済みです。私の場合、DPC3のDPCはSFPケージで動作し、SFP DACケーブルと様々なSFPモジュールでXFIリンクが接続されています。 RCW "rcw_2000_650_2900_3_11_0_auto" は SerDes1=3、SerDes2=11 に設定され、私は QorIQ カーネル (lf-6.6.52-2.2.0) と mc-utils (10.39.0) を使用していますが、両方に Solidrun のパッチが適用されています。U-Bootやその他のものもパッチが適用されています。すべてのパッチはここから取得されます： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 私はMaxLinear GPY245-EKV-1（および-2）開発キットを持っており、PHYをデバイスに接続するためにDACケーブル経由のUSXGMIIを必要としています。どうやらこれはごく普通のことらしい。最終的にはこのPHYチップはSerDes2=7のレーン6とレーン7に統合される予定ですが、テストのためにはClearfogのSFPケージを使用する必要があります。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 私は、dpmac3がDPC経由でこのUSXGMIIリンクを使用するように設定しようとしているだけです。 mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （MAC_LINK_TYPE_BACKPLANEも試してみました） 「restool dpmac info dpmac.3」で確認済み「DPMAC イーサネットインターフェース:DPMAC_ETH_IF_USXGMII」と表示されます。 LinuxではMaxLinearドライバーを追加し、いくつかの点を修正しました: gpy_update_interface() の修正 (LKML、Daniel Golle)。これはUSXGMIIインターフェースで-EINVALを戻す際にクラッシュphy_state_machine。 pcs-lynx.c の lynx_pcs_config_usxgmii() 関数にパッチを適用しました。mdiobus_c45_modify() を介して MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) も書き込む必要があります。この関数はこれまで MII_ADVERTISE しか書き込んでおらず、レプリケータブロック自体で AN を有効にしたことがなかったためです。このギャップは、このフォーラムの別の投稿（「LS1028A 10g-qxgmii phy 起動」）と一致しており、同じ症状（MMD31.0/Replicator）が報告されています。コントロールレジスタが0に固定され、ビット12を手動で設定した後、ANが作動しました。 こちらがDPMAC3 Linuxデバイスツリーのエントリーです: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; ここで、`gpy245_0`はMDIOノードです。PHYへのMDIOトラフィックは正常に動作しています。 lynx_pcsドライバーにリードバックを表示するプリントアウトを追加しました: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 質問： このPCSインスタンスのMDIO_MMD_VEND2レジスタへの書き込みが持続しないような場合、LX2162AファミリSoCのUSXGMIIが設定を受け入れる前に、SerDes/PCSブロックの有効化、プロトコル固有の初期化など、追加のステップが必要になるのでしょうか?プロトコル3はdpmac3上のUSXGMII向けに完全に検証済みですか、それとも主にXFI向けに設計・テストされていますか？ その他の質問： GPY245とUSXGMIIについて、私はよく理解していないのかもしれません。これをQXGMIIと呼ぶ人もいますが、LX2162Aが本当に動作するのかはわかりません。 Solidrunに問い合わせる必要があるかもしれないが、彼らのパッチはどれもLX2162Aの性能を制限するものではないようだ。 ありがとう！ Re: LX2162A USXGMII link never completes LX2162A側は、あなたが使っているパス上でUSXGMIIをサポートするドキュメントがありますが、あなたが示している症状はLinux pcs-lynxの書き込みが欠けているというより、選択したPCSインスタンスがまだUSXGMIIアプリケーションモードに入っていないか、MCファームウェアが間違った10G PCSセレクタをプログラムしているように見えます。 SerDes1プロトコル3の場合、LX2162Aリファレンスマニュアルでは4つのSerDes1レーンすべてがUSXGMII / XFIとして記載されており、最初のレーンにはUSXGMII / XFI.3と記載されています。これはClearfog SFPパス上でテストしているDPMAC3のユースケースに対応しています。将来のカスタムキャリアのターゲットとして、SerDes2プロトコル7はレーン6とレーン7をUSXGMII / XFI.13およびUSXGMII / XFI.14として記録しています。 重要な注意点は、USXGMII / XFI のエントリが自動的に「USXGMII」になるわけではないということです。リファレンス・マニュアルには、USXGMIIとXFIのレーン内のデフォルトはXFIと書かれています。モードは、プロトコル構成レジスタCであるPCCCによって選択され、そのSXGMII*_XFIビットによって0b = USXGMII、1b = XFI/SFIが選択されます。まず最初に確認すべきは、LinuxのBMCR書き込み自体ではなく、DPMAC3の特定のSXGMIIインスタンスがMC/DPC初期化後にPCCC XFIセレクトビットがクリアされているかどうかです。 この正確な故障クラスは、LinuxのPCS**ドライバ**ではなくMCファームウェアに起きている前例もあります。あるLX2162Aチケットでは、USXGMII構成でMCがPCCCの10G**インターフェースセレクタ**を間違ったクリアしている様子があり、MCのファームウェアエンジニアリングビルドバージョン10.35.101で問題が解決されました。別のチケットでは、MCの設定はMCファームウェアによって行われ、NXPはMCをバイナリとして提供していると記載されています。MC 10.39.0 を使用しているため、その特定の古い修正は適用されていないはずですが、発生している障害モードは依然として「MC が意図した PCS を USXGMII モードにしなかった」または「間違った PCS インスタンスが処理されている」というエラーと一致しています。 次に私がすること： Linuxが何かを変える前にPCCCを読んでください。 RCW + MC + DPL/DPCのロード後、LinuxのPCSドライバーが動作する前に、PCCCを読み取り、該当するSXGMII*_XFIビットが0であることを確認します。DPMAC3 / USXGMII/XFI.3 用、最初のSXGMIIセレクタを期待してください。MAC13/14のセレクタではありません。そのビットが1のままの場合、レーンは依然としてXFI/SFIであり、VEND2/USXGMII PCS書き込みはアクティブなUSXGMII PCSパスに適用されません。 MDIOアクセスが意図したPCS管理ポートに届いているか確認してください。 SXGMIIプロトコル制御レジスタにはMDIOアクセスをマッチングするためのMDEV_PORTフィールドがあり、マニュアルにはMDIOがSGMII/PCSターゲットにアクセスするまで、ソフトウェアは変更後少なくとも3プラットフォームクロックを待つ必要があると記載されています。もしMDIOアドレスデコードが間違っていると、書き込みが「永続しない」ように見えることがあります。これは異なる、またはリセット/デフォルトのPCSウィンドウを読み取っているからです。 USXGMII ANレジスタが意味を持つのは、モード選択が正しく行われた後のみであることを確認してください。 USXGMII PCS CONTROLレジスタのビット12にはAUTO_NEGOTIATION_ENABLEがあり、DEV_ABILITY / PARTNER_ABILITYはRWレジスタです。DEV_ABILITY下位ベンダーの任意の速度フィールドはゼロでなければならず、ゼロは自動交渉失敗を引き起こす可能性があります。しかし、PCCCが依然としてXFIを選択する場合、これらのBMCR/能力書き込みは本当の根本的な問題ではない。 GPY245ボードのドキュメントに明確に記載されていない限り、QXGMIIを別の必須外部プロトコルとして扱わないでください。 LX2162Aドキュメントには、PD_QXGMやRST_QXGMなどのリセット/電源停止制御ビットを含むQXGMIIプロトコルコンバータレジスタが含まれています。NXPコミュニティの資料LS1028Aでは10G_QXGMII Lynx SerDesドライバーパスも言及されています。しかし、選んでいるDPMACインターフェースLX2162Aドキュメントは依然としてUSXGMII / XFIであり、NXPのドキュメントにはLX2160クラスのデバイスがUSXGMIIをサポートし、「SXGMII」は同じ意味ではないと別途記載されています。言い換えれば、「QXGMII」という言及は、ドライバ/コミュニティの議論において、あなたが設定したUSXGMIIモードとは必ずしも異なるMAC-to-PHY契約ではなく、内部のコンバータ/ドライバの命名パスを指している可能性があります。 このClearfog SFPテストでは、DPCはシンプルなものにしてください。 MAC_LINK_TYPE_PHY enet_if = 「USXGMII」のモデルは、MDIO上で管理される外部PHYのより自然なモデルです。バックプレーン/KRスタイルのフローを意図的に使用していない限り、MAC_LINK_TYPE_BACKPLANE が PHY 側の USXGMII 設定を修正するとは期待できません。 プロトコル3が「主にXFI専用」であるとは結論付けません。リファレンス・マニュアルでは、プロトコル3をDPMAC3のSerDes1レーン用にUSXGMII / XFIとして記載しています。取得した資料から確認できないのは、「プロトコル3 + DPMAC3 + USXGMIIはGPY245で検証された」という別の検証文です。より強力な証拠に基づく主張は、ハードウェアモードは存在し、PCCCがUSXGMIIを選択しない限りデフォルトでXFIに移行すること、そしてMCファームウェアで誤った10G PCSセレクタをプログラムする前例が存在することが知られています。 具体的な読み上げ内容については、以下をご覧ください。 ADV=0xd601 BMCR=0x1a00 を書き込んだ リードバック ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 これは、PCSインスタンスがUSXGMIIで完全に有効化・選択されていないか、MDIOマネジメントウィンドウが意図したPCSインスタンスに対応していない場合に予想される結果です。Linux側の書き込みを追加する前に、まずPCCCとMCログを確認したほうがいいでしょう。 LX2162Aプロトコル3はDPMAC3上のUSXGMII / XFIについて文書化されていますが、USXGMIIはMC/PCCCがUSXGMII PCSを選択することに依存しています。VEND2/BMCR書き込みが永続化されない場合は、まずDPMAC3の正しいPCCCビットがクリアされていること、およびMDIOが正しいSXGMII PCSインスタンスをアドレス指定していることを確認してください。 Re: LX2162A USXGMII link never completes @yipingwang詳細なご回答、本当にありがとうございます！ あなたの言うことはすべて納得でき、プラットフォームについてもっと学び始めています。AN13329.pdfに記載されているアドバイスを実践し始めました。いくつかのアドレスや機能がうまくいかず(おそらくバージョンの不一致です)、少なくとも以下に示すようにMCログは入手できます: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 私はubootを介してPCCCを操作しようと試みました。関連する事項は以下のとおりです。 crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 0x1ea10b0が正しいアドレスであることを心から願っています。LX2162ARM.pdfによると、それが正しい住所である可能性はあり、ビットを解読すると次のようになります: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 正しいレジスタアドレス（PCCC）を観察すべきでしょうか？他に提供できる情報はありますか? ありがとう！ Re: LX2162A USXGMII link never completes はい。のために SerDes1 、  0x1ea10b0  正しい住所は PCCC : LX162A CCSRマップリスト SerDes 1 で  0x1EA_0000–0x1EA_FFFF  。 SerDesのメモリマップには、 プロトコル構成レジスタC / PCCC オフセットで  0x10B0  。 したがって： 0x1EA0000+0x10B0=0x1EA10B0 0 x 1 E A 0000 + 0 x 10 B 0 = 0 x 1 E A 10 B 0 あなたのUブートにはこう書かれていました: コピー => md.l 0x1ea10b0 1 01ea10b0: 88889991   予想どおりに観測している SerDes1 PCCC 登録する。 重要な注意点は命名法です。私はそれらの分野を物理的とは表現しません。 SerDesレーンA/B/C/D 現在の設定の場合。LX2162A SerDes1プロトコルテーブルでは、プロトコル  3  地図 物理レーンH / レーン0 に  USXGMII / XFI.3  、その後レーンG/レーン1から  .4  、レーンF/レーン2から  .5  、そしてレーンE/レーン3から  .6  。PCCCフィールド名など  SXGMIIA_XFI  、  SXGMIIB_XFI  などは PCS/プロトコル制御フィールドであり、必ずしも物理レーン文字と同じ命名規則ではありません。 価値  0x88889991  上位ニブルは次のようにデコードされます。 コピー PCCC = 0x88889991 ビット31:28 = 0x8 -> SXGMIIA_XFI = 1、CFG = 000 ビット 27:24 = 0x8 -> SXGMIIB_XFI = 1、CFG = 000 ビット 23:20 = 0x8 -> SXGMIIC_XFI = 1、CFG = 000 ビット 19:16 = 0x8 -> SXGMIID_XFI = 1、CFG = 000 ビット15:12 = 0x9 -> SXGMIIE_XFI = 1、CFG = 001 ビット11:8 = 0x9 -> SXGMIIF_XFI = 1、CFG = 001   重要な部分は  _XFI  少し。RMは定義する  0  として USXGMIIモード そして  1  として XFI/SFIモード これらの分野については 。つまり、あなたが読んでいる値は、関連するUSXFI/SXGMIIのPCSインスタンスが依然として XFI/SFI として選択されていることを強く示唆しています。USXGMIIとして選ばれているわけではありません。 これはあなたの症状と一致します。Linux/restoolは報告するかもしれませんが  DPMAC_ETH_IF_USXGMII  PCCCが関連する  _XFI  selectビットを  1  保持しているなら、基盤となるSerDes/PCSの選択は実質的にXFI/SFIモードのままです。RMはまた、10G-SXGMIIを有効にするにはソフトウェアが設定しなければならないと明記しています  PCCC[SGMIIa_XFI] = 0  。 あなたのMCログ抽出結果も問題なさそうです。AN13329では、MCFBAL/MCFBAHを以下のように読むように指示されています。  0x8340020  MCファームウェアベースを構築し、オフセットでログバッファ構造をダンプします。  0x01000000  ; この構造体には、マジックナンバー、ログバッファオフセット、およびログバッファ長が含まれます。 。あなたの  0x21e1000000  ダンプには予想どおりの結果が表示されます  0x4d430100  魔法とログオフセットへのポイント  0x01400000  これは、後であなたがダンプした内容と一致します。  0x21e1400000  。 次に私が撮影したいもの： PCCCの各段階におけるスナップショット コピー md.l 0x1ea10b0 1 それを捉える： リセット直後／可能であればMC起動前に、 MCブート後、 DPC/DPL適用後、 Linuxが起動した後、 DPMACのプローブ/設定が完了した後。 隣接するプロトコル設定レジスタ コピー md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9は他のSGMII構成フィールドを含み、PCCCはSXGMII/XFIセレクタレジスタ です。 USXGMIIを強制しようとしたときにどのPCCCフィールドが変わるか確認してください 実験用にU-Bootを安全に挿入できるなら、候補ビットをクリアしてすぐに読み返してみてください  _XFI  。例えば、dpmac3が最初のSXGMII/USXFI制御フィールドに対応する場合、ビット31をクリアすることが実験的な確認となる。 コピー mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 すぐに読み返せば  0x88889991  その場合、書き込みがブロック/上書きされているか、現在のブロック状態ではそのフィールドに書き込みができません。もしMCやLinuxが動くまで固定されるなら、MC/LinuxはXFI/SFIモードを復元している可能性が高いです。 RCW SerDesの完全デコード あなたは既に  SerDes1=3, SerDes2=11  ; dpmac3 レーンが利用可能であることと一致します  USXGMII / XFI.3  SerDes1プロトコル3の下で 。ただし、MCファームウェアはプロトコルセット全体に基づいてキーを生成することが多いため、エスカレーションを行う際には、完全なRCW文字列と生のRCWダンプを含めてください。 MCファームウェア + DPC/DPLアーティファクト あなたのMCは  10.39.0  、 含む： MCファームウェアバージョン、 DPCソース、 DPLソース、 ちょうど  dpmac@3  ブロック、 restool dpmac info dpmac.3  、 各ステップ後のPCCC値。 私の現在の読めたデータ: はい、  0x1ea10b0  正しいSerDes1 PCCCアドレスであり  0x88889991  関連するPCSセレクタはまだXFI/SFIモードのようです。 これは、XFIがSFPケージを介して動作し、USXGMIIが期待されるPCS構成を受け入れ/保持しないという状況と一致しています。

LX2162A USXGMII 链路始终无法建立连接。 大家好， 我有一个由Solidrun公司生产的LX2162A系统模块。我目前使用的是Clearfog开发套件，但很快会换成定制的载体。 Solidrun 提供基本的 RCW/DCP/DPL，我已经验证了其功能。就我而言，dpmac3 的 DPC 适用于 SFP 笼，我可以通过 SFP DAC 电缆和各种 SFP 模块获得 XFI 连接。 RCW“rcw_2000_650_2900_3_11_0_auto”设置为SerDes1=3，SerDes2=11，我使用的是QorIQ内核（lf-6.6.52-2.2.0）和mc-utils（10.39.0），但两者都应用了一些Solidrun补丁。Uboot和其他一些东西也被打上了补丁。所有补丁均来自此处： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 我有一套 MaxLinear GPY245-EKV-1（和 -2）开发套件，需要通过 DAC 电缆使用 USXGMII 将 phy 连接到设备。这似乎很正常。最终，这款物理芯片将被集成到 SerDes2=7 的第 6 道和第 7 道中，但我必须使用 Clearfog 上的 SFP 插槽进行测试。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 我只是想配置 dpmac3 通过 DPC 使用这个 USXGMII 链路： mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （我也尝试过 MAC_LINK_TYPE_BACKPLANE） 已通过“restool dpmac info dpmac.3”确认显示“DPMAC 以太网接口：DPMAC_ETH_IF_USXGMII”。 在Linux系统中，我添加了MaxLinear驱动程序并修复了一些问题： gpy_update_interface() 修复（LKML，Daniel Golle）。这导致 USXGMII 接口返回 -EINVAL，使 phy_state_machine 崩溃。 已修复 pcs-lynx.c 中的 lynx_pcs_config_usxgmii() 函数。同时通过 mdiobus_c45_modify() 写入 MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART)，因为该函数只写入了 MII_ADVERTISE，而从未在复制器块本身上启用 AN。这一问题与本论坛上的另一篇帖子（“LS1028A 10g-qxgmii phy 启动”）相吻合，该帖子也发现了相同的症状（MMD31.0/复制器）。控制寄存器卡在 0)，手动设置第 12 位后，AN 开始工作。 这是 DPMAC3 Linux 设备树条目： &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; 其中 `gpy245_0` 是 MDIO 节点。MDIO 到物理层的流量正常。 我在 lynx_pcs 驱动程序中添加了一个打印输出，用于显示读取结果： mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 问题： 鉴于对该 PCS 实例上的 MDIO_MMD_VEND2 寄存器的写入似乎不会持久，在 LX2162A 系列 SoC 上的 USXGMII 接受配置之前，是否需要已知的额外步骤（SerDes/PCS 块使能、协议特定的初始化或类似步骤）？协议 3 是否已针对 dpmac3 上的 USXGMII 进行了全面验证，还是主要针对 XFI 进行设计/测试？ 其他问题： 也许我不了解 GPY245 和 USXGMII。我看到有些人称之为 QXGMII，但我不知道 LX2162A 是否能够实现这个功能。 或许我需要联系 Solidrun，但他们所有的补丁似乎都没有限制 LX2162A 的功能。 谢谢！ Re: LX2162A USXGMII link never completes LX2162A 端的文档显示，它支持您所使用的路径上的 USXGMII ，但您所描述的症状看起来不像缺少 Linux pcs-lynx 写入，而更像是所选的 PCS 实例实际上仍未处于 USXGMII 应用程序模式，或者 MC 固件正在对错误的 10G PCS 选择器进行编程。 对于SerDes1 协议 3 ，LX2162A 参考手册将所有四个 SerDes1 通道列为 USXGMII / XFI，其中第一个通道为 USXGMII / XFI.3，这对应于您在 Clearfog SFP 路径上测试的 DPMAC3 用例。对于您未来的自定义载波目标， SerDes2 协议 7还将通道 6 和通道 7 记录为 USXGMII / XFI.13 和 USXGMII / XFI.14。 需要注意的是，USXGMII / XFI 条目不会自动显示为“USXGMII”。参考手册指出，在同一通道上，USXGMII 和 XFI 之间的默认值为 XFI。模式是通过协议配置寄存器 C (PCCC)选择，其 SXGMII*_XFI 位选择 0b = USXGMII 和 1b = XFI/SFI。因此，我首先要检查的不是 Linux BMCR 写入本身，而是DPMAC3 的特定 SXGMII 实例在 MC/DPC 初始化后是否清除了其 PCCC XFI 选择位。 MC 固件中出现此类故障并非 Linux PCS 驱动程序中的故障，此前也有过先例：一个 LX2162A 工单显示，MC 在 USXGMII 配置的 PCCC 中清除了错误的 10G 接口选择器，而 MC 固件工程版本 10.35.101 解决了该问题。另一张工单指出，MC 设置由 MC 固件完成，NXP 以二进制形式提供 MC。由于您使用的是 MC 10.39.0，因此您应该已经过了那个特定的旧修复程序，但您看到的故障模式仍然与“MC 没有将预期的 PCS 置于 USXGMII 模式”或“正在处理错误的 PCS 实例”一致。 接下来我会这样做： 在 Linux 进行任何更改之前，请阅读 PCCC。 在 RCW + MC + DPL/DPC 加载之后，但在 Linux PCS 驱动程序运行之前，读取 PCCC 并确认相关的 SXGMII*_XFI 位为 0。适用于 DPMAC3 / USXGMII/XFI.3预计会是第一个 SXGMII 选择器，而不是 MAC13/14 选择器。如果该位保持为 1，则该通道仍然是 XFI/SFI，并且您的 VEND2/USXGMII PCS 写入不会应用于活动的 USXGMII PCS 路径。 检查 MDIO 访问是否连接到预期的 PCS 管理端口。 SXGMII 协议控制寄存器有一个 MDEV_PORT 字段，用于匹配 MDIO 访问。手册中指出，软件在更改该字段后必须至少等待 3 个平台时钟周期，然后才能对 SGMII/PCS 目标进行 MDIO 访问。如果 MDIO 地址解码错误，写入操作可能会“无法持久”，因为您正在读取不同的或重置/默认的 PCS 窗口。 确认 USXGMII AN 寄存器只有在模式选择正确后才有意义。 USXGMII PCS CONTROL 寄存器的第 12 位具有 AUTO_NEGOTIATION_ENABLE，而 DEV_ABILITY / PARTNER_ABILITY 是 RW 寄存器。DEV_ABILITY 下供应商任意速度字段必须非零，因为零会导致自动协商失败。但如果 PCCC 仍然选择 XFI，那么这些 BMCR/能力写入并不是真正的根本问题。 除非 GPY245 板文档明确说明，否则不要将 QXGMII 视为单独的必需外部协议。 LX2162A 文档确实包含 QXGMII 协议变流器寄存器，包括 RESET/掉电控制位，例如 PD_QXGM 和 RST_QXGM。NXP 社区关于 LS1028A 的资料也提到了 10G_QXGMII Lynx SerDes 驱动程序路径。但是您选择的已记录的 LX2162A DPMAC 接口仍然是 USXGMII / XFI，NXP 文档单独指出 LX2160 类设备支持 USXGMII，“SXGMII”不是同一回事。换句话说：“QXGMII”在驱动程序/社区讨论中的引用可能描述的是内部转换器/驱动程序命名路径，不一定与您配置的USXGMII模式不同的MAC到PHY协议。 对于本次 Clearfog SFP 测试，请保持 DPC 简单。 MAC_LINK_TYPE_PHY with enet_if = "USXGMII"  是 MDIO 上管理外部 PHY 的更自然模型。除非您有意使用背板/KR 风格的流程，否则我不认为 MAC_LINK_TYPE_BACKPLANE 可以修复面向 PHY 的 USXGMII 设置。 我不会得出协议 3“主要仅限 XFI”的结论。参考手册将协议 3 记录为 DPMAC3 的 SerDes1 通道的 USXGMII / XFI。我无法从检索到的材料中证实的是，有单独的验证声明称“协议 3 + DPMAC3 + USXGMII 已通过 GPY245 验证”。更有力、有证据支持的说法是：硬件模式存在，默认为 XFI，除非 PCCC 选择 USXGMII，并且已知 MC 固件有先例对错误的 10G PCS 选择器进行编程。 针对您具体的回读： 写入 ADV=0xd601 BMCR=0x1a00 回读 ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 如果 PCS 实例未完全启用/选择用于 USXGMII，或者 MDIO 管理窗口未指向预期的 PCS 实例，则这正是我所期望的结果。在添加更多 Linux 端写入之前，我会先验证 PCCC 和 MC 日志。 LX2162A 协议 3 已记录在案，适用于 DPMAC3 上的 USXGMII / XFI，但 USXGMII 依赖于 MC/PCCC 选择 USXGMII PCS；如果 VEND2/BMCR 写入没有持久性，首先要证明 DPMAC3 的正确 PCCC 位已清除，并且 MDIO 正在寻址正确的 SXGMII PCS 实例。 Re: LX2162A USXGMII link never completes @yipingwang非常感谢您的详细解答！ 你说的都很有道理，我已经开始更多地了解这个平台了。我已经开始使用 AN13329.pdf 中的建议。部分地址和功能似乎无法正常工作（可能是版本不匹配），但至少我可以获取如下所示的 MC 日志： => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 我尝试通过 uboot 来操作 PCCC。以下是相关内容： crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 我真心希望 0x1ea10b0 是正确的地址。根据 LX2162ARM.pdf 文件，那*可能*是正确的地址，解码后显示： A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 是否应该观察正确的寄存器地址（PCCC）？我还能提供其他信息吗？ 谢谢！ Re: LX2162A USXGMII link never completes 是的。为了 SerDes1 ，  0x1ea10b0  是正确的地址 PCCC ： LX2162A CCSR 地图列表 SerDes 1 在  0x1EA_0000–0x1EA_FFFF  。 SerDes 内存映射列表 协议配置寄存器 C / PCCC 偏移量  0x10B0  。 所以： 0x1EA0000+0x10B0=0x1EA10B0 0 x 1 E A 0000 + 0 x 10 B 0 = 0 x 1 E A 10 B 0 所以你的 U-Boot 读取到： 复制 => md.l 0x1ea10b0 1 01ea10b0: 88889991   正在观察预期情况 SerDes1 PCCC 登记。 需要特别注意的是命名：我不会将这些领域描述为物理领域。 SerDes 通道 A/B/C/D 适用于您当前的配置。在 LX2162A SerDes1 协议表中，协议  3  地图 物理车道 H / 车道 0 到  USXGMII / XFI.3  然后，从 G 车道/1 车道到  .4  ，F车道/2车道至  .5  以及 E 车道/3 号车道  .6  。PCCC 字段名称，例如  SXGMIIA_XFI  ，  SXGMIIB_XFI  等是 PCS/协议控制字段，其命名约定不一定与物理通道字母相同。 您的价值  0x88889991  高位进位解码如下： 复制 PCCC = 0x88889991 位 31:28 = 0x8 -> SXGMIIA_XFI = 1，CFG = 000 位 27:24 = 0x8 -> SXGMIIB_XFI = 1，CFG = 000 位 23:20 = 0x8 -> SXGMIIC_XFI = 1，CFG = 000 位 19:16 = 0x8 -> SXGMIID_XFI = 1，CFG = 000 位 15:12 = 0x9 -> SXGMIIE_XFI = 1，CFG = 001 位 11:8 = 0x9 -> SXGMIIF_XFI = 1，CFG = 001   关键在于  _XFI  少量。RM定义  0  作为 USXGMII 模式 和  1  作为 XFI/SFI 模式 这些领域 。因此，您读到的值强烈表明，相关的 USXFI/SXGMII PCS 实例仍然被选中。 XFI/SFI 不是 USXGMII。 这与您的症状相符：Linux/restool 可能会报告  DPMAC_ETH_IF_USXGMII  但如果PCCC仍然拥有相关  _XFI  选择位  1  底层 SerDes/PCS 选择仍然有效地处于 XFI/SFI 模式。RM 还明确指出，要启用 10G-SXGMII，软件必须进行设置  PCCC[SGMIIa_XFI] = 0  。 你的MC日志提取看起来也正常。AN13329 指示阅读 MCFBAL/MCFBAH  0x8340020  构建 MC 固件基础，然后转储偏移量的日志缓冲区结构。  0x01000000  该结构体包含魔数、日志缓冲区偏移量和日志缓冲区长度 。你的  0x21e1000000  转储文件显示了预期结果  0x4d430100  魔法和指向日志偏移量的指针  0x01400000  这与你之后的转储文件相符。  0x21e1400000  。 接下来我要拍摄的内容： 每个阶段的PCCC快照 复制 md.l 0x1ea10b0 1 捕捉它： immediately after RESET / before MC 启动 if possible, MC启动后， DPC/DPL申请后， Linux启动后， 在 DPMAC 探测/配置之后。 相邻协议配置寄存器 复制 md.l 0x1ea10a0 1 # PCC8 md.l 0x1ea10a4 1 # PCC9 md.l 0x1ea10b0 1 # PCCC PCC8/PCC9 包含其他 SGMII 配置字段，而 PCCC 是 SXGMII/XFI 选择器寄存器。 。 确认尝试强制使用 USXGMII 时，哪个 PCCC 字段发生了变化。 如果可以安全地在 U-Boot 中进行实验，请尝试清除候选路径。  _XFI  截取一段并立即读出来。例如，如果 dpmac3 对应于第一个 SXGMII/USXFI 控制字段，则清除第 31 位将作为实验性检查： 复制 mw.l 0x1ea10b0 0x08889991 1 md.l 0x1ea10b0 1 如果它立即读取为  0x88889991  那么，要么写入操作被阻止/覆盖，要么该字段在当前阻塞状态下不可写。如果这种情况一直持续到 MC 或 Linux 运行，那么 MC/Linux 很可能正在恢复 XFI/SFI 模式。 完整的RCW SerDes解码 你已经拥有  SerDes1=3, SerDes2=11  这与 dpmac3 通道可用相符  USXGMII / XFI.3  在 SerDes1 协议 3 下 。不过，升级问题时，仍需提供完整的 RCW 字符串和原始 RCW 转储，因为 MC 固件通常会根据完整的协议集进行调整。 MC固件+DPC/DPL制品 因为你的MC是  10.39.0  ， 包括： MC固件版本 DPC源， DPL来源， 精确的  dpmac@3  堵塞， restool dpmac info dpmac.3  ， 每一步之后的PCCC值。 我目前对您数据的解读： 是的，  0x1ea10b0  是正确的 SerDes1 PCCC 地址，并且  0x88889991  看起来相关的 PCS 选择器仍然处于 XFI/SFI 模式。 这与 XFI 通过 SFP 插槽工作，而 USXGMII 不接受/保留预期的 PCS 配置的情况一致。

FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hello NXP Support, I am requesting help recovering an FRDM-i.MX93 board. The board consistently stops during early SPL boot immediately after “M33 prepare ok” and does not continue to BL31 or full U-Boot. UUU recovery also fails during SDPS boot with a timeout. Board details: Board: FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS Typical serial output: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok The same stop point also occurs with a rebuilt 2025 SPL: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok Hardware setup used: P1 = external power supply, tested with 45 W USB-C wall adapter P16 = debug serial console P13 = microSD card slot P2 = USB-C connection for UUU / serial downloader mode I also tested powering from a wall adapter instead of PC USB power. The behavior did not change. Host systems tested: Linux Mint / Ubuntu host Windows host UUU versions tested: uuu 1.5.141 uuu 1.5.243 The main issue is that the board reaches SPL, initializes PMIC and DDR, and prints “M33 prepare ok”, then nothing else happens. It never reaches “Normal Boot”, “Trying to boot from BOOTROM”, “NOTICE: BL31”, or full U-Boot. This happens when booting from both SD and eMMC. In USB Serial Downloader mode, the board is detected by UUU: sudo ./uuu -lsusb Connected Known USB Devices Path Chip Pro Vid Pid BcdVersion 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 However, UUU fails during SDPS boot. The command used was: sudo ./uuu -V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst On Linux, the failure is: Start Cmd:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT On Windows, the failure is: Start Cmd:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% Fail HID(W): LIBUSB_ERROR_TIMEOUT (-7) This was tested on both Linux and Windows, with the same result. Images tested: I tested the official NXP FRDM-i.MX93 Rev 4.0 demo image package: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 The boot image hash is: 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot I also tested my own Yocto image for imx93frdm, which uses the same boot image hash. I verified that SD boot selection works. In SD boot mode with no SD card inserted, there is no serial output. In SD boot mode with an SD card inserted, SPL starts and stops at “M33 prepare ok”. So the SD boot switch appears to be working. I also verified that the official NXP .wic image contains the boot image at the expected 32 KiB / 0x8000 offset. Commands used: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WIC contains boot image at 32K" || echo "NXP WIC does NOT contain boot image at 32K" Result: NXP WIC contains boot image at 32K So the SD image appears to contain the boot container correctly. To rule out only the 2024.04 SPL image being the issue, I built a newer boot image using Flexbuild/U-Boot. The SPL inside the built image shows: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) NXP FRDM-IMX93 I wrote this new flash.bin to the SD card at 32 KiB offset using: sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync The board then printed the new SPL banner, confirming it was executing the new SD boot image: U-Boot SPL 2025.04 (Apr 26 2026 - 16:21:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok However, it still stopped at the same point and did not continue to BL31/full U-Boot. eMMC status: Originally, the eMMC booted far enough to reach Linux login, but root login was broken because /bin/sh was missing in the root filesystem. During recovery attempts, the eMMC was rewritten from SD Linux using a .wic image. After that, eMMC boot also stops after “M33 prepare ok”. However, the same stop point occurs from SD boot using the official NXP image and also with the rebuilt 2025 SPL, so the current issue appears to be earlier than Linux/rootfs. What I believe has been ruled out: Wrong serial port: serial works and shows SPL output. Bad PC power: tested with external 45 W wall adapter. Wrong SD boot switch: SD boot mode with no SD card gives no output. Missing boot image in SD image: verified boot image exists at 0x8000 / 32 KiB in the official NXP WIC. Linux/rootfs issue: the failure happens before BL31/full U-Boot/Linux. Host OS issue for UUU: UUU SDPS boot timeout occurs on both Linux and Windows. Only the old 2024 SPL being bad: a rebuilt 2025.04 SPL also stops after “M33 prepare ok”. Could you please help determine whether this is a known FRDM-i.MX93 early boot issue? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Are you using the BSP version we released? Embedded Linux for i.MX Applications Processors | NXP Semiconductors Which version BSP are you using and choose?  I will try to test on our board when I back from Labor holiday, I will back to office on Next Wednsday then will test, then give you reply my test result. Wish you have a nice day Best Regards Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I'm using the LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 image Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am back to office and will test on our board, then tell you the result. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Did you figure it out?  Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang  Having the same issue... I have never seen the BL31 to start booting with my imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap build. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi, I'm currently having the same issue. May I ask if you've figured out the solution yet? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Same issue here. Is there any update what's needed to allow the imx93 to boot from SD or alternatively let UUU work properly? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows We noticed there's a difference in the memory chip on the board in respect to other frdm-imx93 boards. Perhaps this helps finding the issue.  Working board has micron and faulty board has a brand I don't recognize.   IMG_7007.jpegIMG_7007.jpeg   Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I am having the same issue. This should be marked as HIGH PRIORITY as the only working image is the one factory supplied on the eMMC! If that's re-flashed, I'll have a bricked FRDM-IMX93 until a solution is found, which I suspect is related to DDR memory timings. I too hang at "M33 prepare ok" which indicates DDR config/timing issues and my board also has the same 'no-name' DDR IC as @SynchronicIT post above (manufacturer logo with a 'J'). How is it that these boards can be shipped out with a working image on eMMC but none of the available images from NXP work? When I boot via (factory loaded) eMMC - which WORKS - the u-boot version is: U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) whereas the LATEST download from NXP (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip), the "imx-boot-imx93frdm-sd.bin-flash_singleboot" file is u-boot version: U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) Below is the full output from working factory image eMMC and also from non-working SD flashed image and UUU uploaded u-boot. * WORKING (factory loaded eMMC) * U-Boot SPL 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot Trying to boot from BOOTROM Boot Stage: Primary boot image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from 0x57800 by ROM_API NOTICE: TRDC init done NOTICE: BL31: v2.12.0(release):lf-6.18.2-1.0.0 NOTICE: BL31: Built : 07:53:18, Feb 10 2026 U-Boot 2025.04-g99518e6b6f20 (Feb 02 2026 - 05:52:54 +0000) Reset Status: POR CPU: NXP i.MX93(52) Rev1.2 A55 at 1700 MHz CPU: Industrial temperature grade (-40C to 105C) at 24C Model: NXP FRDM-IMX93 DRAM: 2 GiB BOARD: V1.0(ADC2:684,ADC3:271) TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0: type 0, 5000 mV, 3000 mA [E] PDO 1: type 0, 9000 mV, 3000 mA [] PDO 2: type 0, 12000 mV, 3000 mA [] PDO 3: type 0, 15000 mV, 3000 mA [] PDO 4: type 0, 20000 mV, 3250 mA [] PDO 5: type 3, undefined Requesting PDO 4: 20000 mV, 750 mA Source accept request PD source ready! tcpc_pd_receive_message: Polling ALERT register, TCPC_ALERT_RX_STATUS bit failed, ret = -62 TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x50] Core: 229 devices, 32 uclasses, devicetree: separate MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... Reading from MMC(0)... *** Warning - bad CRC, using default environment Fail to setup video link In: serial Out: serial Err: serial BuildInfo: - ELE firmware version 2.0.5-7a34cee switch to partitions #0, OK mmc0(part 0) is current device UID: 4a7ff07fa81b46d8b2b59146dfa5af84 flash target is MMC:0 Net: eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME] Fastboot: Normal Normal Boot Hit any key to stop autoboot: 0 u-boot=> * NOT WORKING * U-Boot SPL 2024.04+gde16f4f1722+p0 (Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 prepare ok -- HANG -- Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I've got the same issue. I was not able to flash any image via uuu.exe, with the same "HID(W): LIBUSB_ERROR_TIMEOUT (-7)" error output. The memory chip on my board is also the "J" branded one, not Micron. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Adding another data point with the specific DDR part information, since I think the substituted memory is the key to this and I haven't seen the exact part numbers posted yet. **Board:** FRDM-IMX93, SCH-94611 REV B2 (board label DRQ30063390) **SoC:** i.MX93(52) Rev1.2, SOC 0xa1009300, LC 0x2040010 **PMIC:** PCA9451A **DDR:** The schematic and User Guide specify LPDDR4x Micron MT53E1G16D1FW-046. The chip actually fitted on my board is marked **JSL4BAG167ZAMF** — not Micron. This matches what others in this thread have reported (the "J"-branded DDR on failing boards vs Micron on working ones). **The failure is at DDR training/validation, not M33/ELE.** Comparing the working factory eMMC boot against the failing public BSP boot makes this clear: Working (factory eMMC, U-Boot SPL 2025.04, BL31 lf-6.18.2-1.0.0): ``` DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot ... ``` Failing (LF_v6.6.36-2.1.0 public release, U-Boot SPL 2024.04 Sep 02 2024): ``` DDR: 3733MTS DDR: 3733MTS M33 prepare ok -- hang -- ``` The `found DRAM ... DRAM matched` line is present on the working bootloader and absent on the failing one. The board hangs at exactly the point where DDR validation would complete, before BL31 / Normal Boot. So this looks like the 6.6.36 DDR configuration/timings not matching the substituted DDR part, rather than anything downstream. The working eMMC bootloader also reports **ELE firmware version 2.0.5-7a34cee**, which is newer than what ships in the 6.6.36 package — noting in case the fix depends on both the DDR timings and the ELE version. **What I've been able to rule out**, to save cycles: - Build: my own Yocto imx93frdm build produces a byte-identical imx-boot to the factory package (sha256 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f), so this is not a build issue. - SD flashing: verified the boot container at 32 KiB (0020 0287 magic), valid MBR (55aa), and two FIT magics in the bootloader region. - Boot switch: SD mode with no card gives no serial output; with a card, SPL runs — so USDHC2/SD selection is correct. - Power: same result on multiple USB-C supplies. - Host/USB: UUU SDPS boot fails with HID(W): LIBUSB_ERROR_TIMEOUT at the same point on two different Linux hosts. - Hardware itself is good: the board boots its factory eMMC image to Linux, so the DDR *can* be trained by the correct bootloader. **Questions:** 1. Is the corrected DDR configuration for the REV B2 boards with the non-Micron (JSL4BAG167ZAMF) DDR available in any current public BSP — e.g. 6.6.52-2.2.0 or the 6.12.x releases — or is it only in the newer bootloader (lf-6.18.2) currently shipped on eMMC? 2. If it's not yet in a public release, would it be possible to publish the updated FRDM-IMX93 DDR timing headers (or the lf-6.18.2 FRDM bootloader) so SD boot works on these boards? I'm happy to run diagnostics or test candidate bootloaders/timing configs on this board if that would help narrow it down. Thanks, jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Following up with a working resolution, in case it helps others on this thread with the same board/DDR combination. Summary: the failure is a DDR training issue in the public LF6.6.36-2.1.0 BSP on the newer FRDM-IMX93 boards that ship with substituted (non-Micron) LPDDR4X. Moving to the **LF6.18.2 (Whinlatter) BSP** resolves it — the board trains its DDR and boots cleanly from SD. Board / DDR (for reference): - FRDM-IMX93, SCH-94611 REV B2 - Schematic specifies Micron MT53E1G16D1FW; chip actually fitted is marked JSL4BAG167ZAMF (non-Micron substitute) What confirmed the root cause: the factory eMMC image (which boots fine) uses a newer bootloader — U-Boot SPL 2025.04, BL31 lf-6.18.2, kernel 6.18.2 — and its SPL prints `found DRAM 2CS_2GB DRAM matched` before `M33 prepare ok`. The public LF6.6.36 SPL (U-Boot 2024.04) does not print `DRAM matched` and hangs at `M33 prepare ok`. So the 6.6.36 DDR configuration does not train this substituted memory, while the 6.18.2 one does. The working path — build and boot the LF6.18.2 BSP: mkdir imx-bsp-6.18.2 && cd imx-bsp-6.18.2 repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-whinlatter -m imx-6.18.2-1.0.0.xml repo sync DISTRO=fsl-imx-xwayland MACHINE=imx93-11x11-lpddr4x-frdm source sources/meta-imx/tools/imx-setup-release.sh -b build-frdm bitbake imx-image-core   Note the machine name is `imx93-11x11-lpddr4x-frdm` (native to this BSP — no separate meta-imx-frdm layer needed, unlike 6.6.36). Then flash the resulting `.wic.zst` to SD (decompress and dd to the whole card device), set the boot switch to SD (SW1 = 1 1 0 0), and boot. Result on the REV B2 / JSL DDR board: DDR: 3733MTS found DRAM 2CS_2GB DRAM matched M33 prepare ok Normal Boot ... NXP FRDM-IMX93 login: `free -h` confirms the full 2GB is trained and available. Still open for NXP: is there any plan to backport the updated FRDM DDR configuration to the LF6.6.36-2.1.0 branch, for anyone who needs to stay on 6.6.36? For those able to move to 6.18.2, the above works. Hope this saves someone the debugging. jjudk Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi Rita, Do you have any update on this? We are stuck on this. Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows I have test on our 93FRDM REV B version board with the demo images images LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93， Using the UUU uuu tool Release uuu_1.5.243 Try both on the SD Card and emmc, download and boot up success, do not reproduce the error you met.  .\uuu.exe -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singleboot imx-image-full-imx93frdm.rootfs.wic.zst Rita_Wang_0-1786613213510.pngRita_Wang_0-1786613213510.png Rita_Wang_1-1786613222942.pngRita_Wang_1-1786613222942.png Rita_Wang_2-1786613231468.pngRita_Wang_2-1786613231468.png Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Seems like the issue is with the REV B2 boards. Please try it on a REV B2 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows Hi everyone. @Rita_Wang  it's not a matter of "revision." I have two boards on my desk with the same revision but different LP DDR chips. However, verbatim from your team:  LFU-956 imx93_frdm: Add 2CS 2GB DRAM support on i.MX93 FRDM FRDM-IMX93 use Micron MT53E1G16D1FW 1CS DRAM but it is EOL. It will replace with JSC JSL4BAG167ZAMF 2CS DRAM. And 1G DRAM support will de dropped. Add 2CS 2GB DRAM support on i.MX93 FRDM to support both 1CS and 2CS DRAM based FRDM-IMX93 boards. That's because those two chips (see attached pics) have different timing parameters. As @jjudk  stated, the only way to make it work is to move to a new version of firmware. In my case, I had to stick with an older one. Therefore, I just cherry-picked the needed patch (take a look here: https://github.com/nxp-imx/uboot-imx/commit/4c35a6086aedca2f6220382920242ad81ae372f6) If someone still has issues, I can provide you all with a pre-built. -Gabriele

dpaa2_net: FS table with 1 entries full hi creating 1 dpni and dpdmux. on Port 0 creating 2 RXQ . Adding rte_flow as below  memset(&udp_spec, 0, sizeof(udp_spec)); memset(&udp_mask, 0, sizeof(udp_mask)); udp_spec.hdr.dst_port = rte_cpu_to_be_16(udp_port); udp_mask.hdr.dst_port = 0xffff; pattern[0].type = RTE_FLOW_ITEM_TYPE_UDP; pattern[0].spec = &udp_spec; pattern[0].mask = &udp_mask; pattern[1].type = RTE_FLOW_ITEM_TYPE_END; action[0].type = RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf = &queue; action[1].type = RTE_FLOW_ACTION_TYPE_END; struct rte_flow *flow = rte_flow_create(port_id, &attr, pattern, action, &error); Creating 2 flow on port 0 for RXQ 0 and RXQ 1  create_udp_queue_flow(port_id, 5000, 0); create_udp_queue_flow(port_id, 5001, 1); Getting below error. dpaa2_net: FS table with 1 entries full Re: dpaa2_net: FS table with 1 entries full Hello, The logs and restool output tell a clear story. The DPNI object was provisioned with only 1 fs_entry , which gets consumed by the first flow rule ( UDP 5000 → RXQ 0 ). Any subsequent rte_flow_create() call fails immediately because the hardware FS table has no room left. Port 0 started with 2 RX queues and 7 TX queues UDP port 5000 -> RXQ 0 created dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1) Flow create failed: unknown fslmc: dpaa2_get_qbman_swp(): New Portal 0x17ffebbc0 (2) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) is affined for eth rx to thread 8602root@localhost:/home/user# restool dpni info dpni.1 dpni version: 8.2 dpni id: 1 plugged state: plugged endpoint state: 0 endpoint: dpdmux.0.2, link is down link status: 0 - down mac address: ce:8a:4d:82:e7:dc max frame length: 1536 dpni_attr.options value is: 0x80000310 Unrecognized options found... num_queues: 16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries: 16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 10:53 AM     DPAA2 Flow Steering Table Full — Root Cause & Fix The logs and restool output tell a clear story. The DPNI object was provisioned with only 1 fs_entry , which gets consumed by the first flow rule ( UDP 5000 → RXQ 0 ). Any subsequent rte_flow_create() call fails immediately because the hardware FS table has no room left. Root Cause dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1)   Confirmed by restool : fs_entries: 1 ← only 1 hardware flow-steering slot   The DPNI was created (either via DPL or restool dpni create ) without explicitly setting fs-entries , so it defaulted to 1. Fix — Recreate the DPNI with More FS Entries Option 1 — Dynamically via restool (no reflash needed): # Destroy the existing DPNI restool dpni destroy dpni.1 # Recreate it with sufficient FS entries (e.g., 16 or 64) restool dpni create \ --options=DPNI_OPT_HAS_KEY_MASKING \ --num-queues=16 \ --fs-entries=64 \ --num-rx-traffic-classes=8 \ --num-tx-traffic-classes=16 # Re-bind to the DPDMUX endpoint restool dpdmux connect dpdmux.0.2 --endpoint=dpni.X Replace dpni.X with the newly created ID shown after dpni create . Option 2 — Edit the DPL (Data Path Layout) file: Find the dpni@1 object block in your DPL ( .dts / .dpl ) and increase fs_entries : dpni@1 { compatible = "fsl,dpni"; ... fs_entries = <64>; /* was 1, increase as needed */ ... }; Then reload the DPL: restool dprc load dprc.1  Your DPNI already has qos_entries: 64 and qos_key_size: 56 , so the hardware supports it — only the provisioned FS table size was too small. Quick Validation After Fix # Confirm new fs_entries value restool dpni info dpni. | grep fs_entries # Expected: fs_entries: 64 (or whatever you set)   Then retry your DPDK application — the Flow create failed error should be gone.   regards       Re: dpaa2_net: FS table with 1 entries full root@localhost:/home/user# restool dpni info dpni.1 dpni version: 8.2 dpni id: 1 plugged state: plugged endpoint state: 0 endpoint: dpdmux.0.2, link is down link status: 0 - down mac address: ce:8a:4d:82:e7:dc max frame length: 1536 dpni_attr.options value is: 0x80000310 Unrecognized options found... num_queues: 16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries: 16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 Re: dpaa2_net: FS table with 1 entries full ./dpdk-multirxq-sample-prog  -l 1-3 -n 1 --log-level=fslmc,8 --huge-dir /dev/hugepages --proc-type=auto -b fslmc:dpio.16 -b fslmc:dpio.17 -b fslmc:dpio.18 -b fslmc:dpio.19 -b fslmc:dpio.20 -b fslmc:dpio.21 -b fslmc:dpio.22 -b fslmc:dpio.23 -b fslmc:dpmcp.38 -b fslmc:dpmcp.39 EAL: Detected 16 lcore(s) EAL: Detected 1 NUMA nodes EAL: Auto-detected process type: PRIMARY fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) EAL: Multi-process socket /var/run/dpdk/rte/mp_socket fslmc: fslmc_get_container_group(): Container: dprc.2 has VFIO iommu group id = 11 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: **Devargs matched dpmcp.39 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: **Devargs matched dpio.18 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: **Devargs matched dpio.16 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: Skipping invalid device (power) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: **Devargs matched dpio.22 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: **Devargs matched dpio.20 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: **Devargs matched dpio.19 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: **Devargs matched dpmcp.38 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: **Devargs matched dpio.17 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: **Devargs matched dpio.23 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: **Devargs matched dpio.21 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: FSLMC Bus scan completed fslmc: List of devices scanned on bus: fslmc: dpni.1 fslmc: dpseci.1 fslmc: dpseci.2 fslmc: dpseci.3 fslmc: dpseci.4 fslmc: dpseci.5 fslmc: dpseci.6 fslmc: dpseci.7 fslmc: dpseci.8 fslmc: dpseci.9 fslmc: dpseci.10 fslmc: dpseci.11 fslmc: dpseci.12 fslmc: dpseci.13 fslmc: dpseci.14 fslmc: dpseci.15 fslmc: dpseci.16 fslmc: dpcon.32 fslmc: dpcon.33 fslmc: dpcon.34 fslmc: dpcon.35 fslmc: dpcon.36 fslmc: dpcon.37 fslmc: dpcon.38 fslmc: dpcon.39 fslmc: dpbp.2 fslmc: dpbp.3 fslmc: dpbp.4 fslmc: dpbp.5 fslmc: dpbp.6 fslmc: dpbp.7 fslmc: dpbp.8 fslmc: dpbp.9 fslmc: dpbp.10 fslmc: dpbp.11 fslmc: dpbp.12 fslmc: dpbp.13 fslmc: dpbp.14 fslmc: dpbp.15 fslmc: dpbp.16 fslmc: dpbp.17 fslmc: dpio.16 fslmc: dpio.17 fslmc: dpio.18 fslmc: dpio.19 fslmc: dpio.20 fslmc: dpio.21 fslmc: dpio.22 fslmc: dpio.23 fslmc: dpio.24 fslmc: dpio.25 fslmc: dpio.26 fslmc: dpio.27 fslmc: dpio.28 fslmc: dpio.29 fslmc: dpio.30 fslmc: dpio.31 fslmc: dpci.0 fslmc: dpci.1 fslmc: dpmcp.37 fslmc: dpmcp.38 fslmc: dpmcp.39 fslmc: dpdmai.0 fslmc: dpdmai.1 fslmc: dpdmai.2 fslmc: dpdmai.3 fslmc: dpdmai.4 fslmc: dpdmai.5 fslmc: dpdmai.6 fslmc: dpdmai.7 fslmc: dpdmux.0 fslmc: dprc.2 EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-2048kB EAL: No available hugepages reported in hugepages-32768kB EAL: No available hugepages reported in hugepages-64kB EAL: Probing VFIO support... EAL: VFIO support initialized fslmc: fslmc_get_container_group(): Container: dprc.2 has VFIO iommu group id = 11 fslmc: fslmc_vfio_setup_group(): VFIO Container FD is [0x1B] fslmc: fslmc_map_dma(): --> Map address: 0x140000000, size: 1073741824 fslmc: rte_fslmc_vfio_dmamap(): Installed memory callback handler fslmc: rte_fslmc_vfio_dmamap(): Total 1 segments found. fslmc: Unable to map region (errno = 22) fslmc: dpmcp.38 Blacklisted, skipping fslmc: dpmcp.39 Blacklisted, skipping fslmc: Device (dprc.2) abstracted from VFIO fslmc: Device (dpni.1) abstracted from VFIO fslmc: Device (dpseci.1) abstracted from VFIO fslmc: Device (dpseci.2) abstracted from VFIO fslmc: Device (dpseci.3) abstracted from VFIO fslmc: Device (dpseci.4) abstracted from VFIO fslmc: Device (dpseci.5) abstracted from VFIO fslmc: Device (dpseci.6) abstracted from VFIO fslmc: Device (dpseci.7) abstracted from VFIO fslmc: Device (dpseci.8) abstracted from VFIO fslmc: Device (dpseci.9) abstracted from VFIO fslmc: Device (dpseci.10) abstracted from VFIO fslmc: Device (dpseci.11) abstracted from VFIO fslmc: Device (dpseci.12) abstracted from VFIO fslmc: Device (dpseci.13) abstracted from VFIO fslmc: Device (dpseci.14) abstracted from VFIO fslmc: Device (dpseci.15) abstracted from VFIO fslmc: Device (dpseci.16) abstracted from VFIO fslmc: Device (dpcon.32) abstracted from VFIO fslmc: Device (dpcon.33) abstracted from VFIO fslmc: Device (dpcon.34) abstracted from VFIO fslmc: Device (dpcon.35) abstracted from VFIO fslmc: Device (dpcon.36) abstracted from VFIO fslmc: Device (dpcon.37) abstracted from VFIO fslmc: Device (dpcon.38) abstracted from VFIO fslmc: Device (dpcon.39) abstracted from VFIO fslmc: Device (dpbp.2) abstracted from VFIO fslmc: Device (dpbp.3) abstracted from VFIO fslmc: Device (dpbp.4) abstracted from VFIO fslmc: Device (dpbp.5) abstracted from VFIO fslmc: Device (dpbp.6) abstracted from VFIO fslmc: Device (dpbp.7) abstracted from VFIO fslmc: Device (dpbp.8) abstracted from VFIO fslmc: Device (dpbp.9) abstracted from VFIO fslmc: Device (dpbp.10) abstracted from VFIO fslmc: Device (dpbp.11) abstracted from VFIO fslmc: Device (dpbp.12) abstracted from VFIO fslmc: Device (dpbp.13) abstracted from VFIO fslmc: Device (dpbp.14) abstracted from VFIO fslmc: Device (dpbp.15) abstracted from VFIO fslmc: Device (dpbp.16) abstracted from VFIO fslmc: Device (dpbp.17) abstracted from VFIO fslmc: dpio.16 Blacklisted, skipping fslmc: dpio.17 Blacklisted, skipping fslmc: dpio.18 Blacklisted, skipping fslmc: dpio.19 Blacklisted, skipping fslmc: dpio.20 Blacklisted, skipping fslmc: dpio.21 Blacklisted, skipping fslmc: dpio.22 Blacklisted, skipping fslmc: dpio.23 Blacklisted, skipping fslmc: dpaa2_create_dpio_device(): LX2160 Platform Detected fslmc: Device (dpio.24) abstracted from VFIO fslmc: Device (dpio.25) abstracted from VFIO fslmc: Device (dpio.26) abstracted from VFIO fslmc: Device (dpio.27) abstracted from VFIO fslmc: Device (dpio.28) abstracted from VFIO fslmc: Device (dpio.29) abstracted from VFIO fslmc: Device (dpio.30) abstracted from VFIO fslmc: Device (dpio.31) abstracted from VFIO fslmc: Device (dpci.0) abstracted from VFIO fslmc: Device (dpci.1) abstracted from VFIO fslmc: Device (dpdmai.0) abstracted from VFIO fslmc: Device (dpdmai.1) abstracted from VFIO fslmc: Device (dpdmai.2) abstracted from VFIO fslmc: Device (dpdmai.3) abstracted from VFIO fslmc: Device (dpdmai.4) abstracted from VFIO fslmc: Device (dpdmai.5) abstracted from VFIO fslmc: Device (dpdmai.6) abstracted from VFIO fslmc: Device (dpdmai.7) abstracted from VFIO fslmc: Device (dpdmux.0) abstracted from VFIO PMD: dpni.1: netdev created, connected to dpdmux.0 fslmc: dpaa2_get_qbman_swp(): New Portal 0x17fff3280 (1) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 1 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17fff3280 (1) is affined to thread 8602 Port 0 started with 2 RX queues and 7 TX queues UDP port 5000 -> RXQ 0 created dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1) Flow create failed: unknown fslmc: dpaa2_get_qbman_swp(): New Portal 0x17ffebbc0 (2) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) is affined for eth rx to thread 8602 Re: dpaa2_net: FS table with 1 entries full Thanks resolved 

IMX95 uGuzzi ISP:AEアルゴリズムは最大露出を達成できません AE制限を設定し、最大露出を適切に設定しました。しかし、実行時において、AEアルゴリズムは最大でも66666の露出しか達成できず、この時点でゲインは上限に達します。V4L2による測定結果から、AE曝露量が設定された上限値の半分以下であることが確認されました。 LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png Live Controlで手動で露出を設定すると、有効な露出は150000に達することがあり、V4L2露出も上限に達することがあります。 この問題はRowTimeに関連していると思われます。AEディスター内の行時間パラメータを変更しましたが、この変更には目に見える影響はありません。自動露出性能は以前とまったく変わりません。 低照度条件下でAEアルゴリズムが設定された最大露出値に達するようにするには、どのような調整が必要かを知りたいです。 Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure 現在の挙動から判断すると、AEアルゴリズムは絶対的な手動露出能力ではなく、アクティブセンサーモードのフレーム持続時間によって制限されているようです。値 66666 us は15fpsの1フレームに対応します。したがって、AE LIMITSの最大値を 150000 us に設定しても、アクティブセンサーのタイミングが150msを超えるフレーム期間を許すか、ドライバー/ヘルパーパスが露出をプログラムする前にVBLANK/フレーム長を延長しない限り、AEはこれを適用できません。 センサードライバーが V4L2_CID_EXPOSURE 、 V4L2_CID_VBLANK 、 V4L2_CID_HBLANK 、 V4L2_CID_PIXEL_RATE を露出し正しく更新しているかを確認してください。低照度AEが 150000 us に達するためには、アクティブフレームレートを約6.67fps以下に下げるか、AE制御パスでVBLANK/フレーム長を動的に増加させる必要があります。AE Dister で行時間を変更しても、V4L2/CameraHelper パスで報告されるアクティブ露出範囲が約 66666 us に制限されている場合は、AE に影響しない可能性があります。 また、変更されたAEパラメータが config_ipa_uguzzi.yaml で参照されるアクティブなDTPファイルに保存され、 /usr/share/libcamera/ipa/nxp/neo/uguzzi/ にコピーされ、カメラパイプラインが再起動されるか、または対応するアルゴリズムの再構成が適用されていることを確認してください。ライブコントロールの変更は、プロジェクト/DTPに保存するか、適切な再構成パスを通じて適用しない限り、通常は一時的なものです。 私の推奨事項は、まずフレーム持続時間/VBLANKの露出範囲の問題として対処し、次にDTP/プロファイルの有効化を確認することです。手動露出が 150000 us に達するという事実は有用ですが、AEが認識できる露出範囲とフレームタイミングも更新されない限り、AEループがその値を要求できることを証明するものではありません。

dpaa2_net: エントリが 1 つある FS テーブルがいっぱいです こんにちは、1つのdpniとdpdmuxを作成しています。 ポート0で2つのRXQを作成しています。 以下のようにrte_flowを追加します memset(&udp_spec, 0, sizeof(udp_spec)); memset(&udp_mask, 0, sizeof(udp_mask)); udp_spec.hdr.dst_port= rte_cpu_to_be_16(udp_port); udp_mask.hdr.dst_port= 0xffff; pattern[0].type = RTE_FLOW_ITEM_TYPE_UDP; パターン[0].spec= &udp_spec; パターン[0].マスク= &udp_mask; pattern[1].type = RTE_FLOW_ITEM_TYPE_END; アクション[0].タイプ= RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf= &キュー; アクション[1].タイプ= RTE_FLOW_ACTION_TYPE_END; struct rte_flow *flow = rte_flow_create(port_id, &attr、 パターン、 アクション、 ＆エラー）; ポート0でRXQ 0とRXQ 1用に2つのフローを作成します。 create_udp_queue_flow(port_id, 5000, 0); create_udp_queue_flow(port_id, 5001, 1); 以下のエラーが発生しています。 dpaa2_net: エントリが 1 つある FS テーブルがいっぱいです Re: dpaa2_net: FS table with 1 entries full こんにちは、 ログと restool 排出量は、明確な事実を物語っている。DPNIオブジェクトには1つの fs_entry のみがプロビジョニングされており、これは最初のフロールール（ UDP 5000 → RXQ 0 ）によって消費されます。ハードウェアファイルシステムテーブルに空き容量がないため、後続の rte_flow_create() 呼び出しは即座に失敗します。 ポート0は2つのRXキューと7つのTXキューから始まりました。UDPポート5000 -> RXQ 0が作成されました dpaa2_net: 1エントリのFSテーブルが完全に作成されました dpaa2_net: フローの作成失敗、コード返却(-1) フロー作成失敗:不明 fslmc: dpaa2_get_qbman_swp(): 新しいポータル 0x17ffebbc0 (2) affined Thread - 8602 fslmc: dpaa2_configure_stashing(): ポータル= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) はeth rxからThreadへの対応 8602root@localhost:/ホーム/ユーザー# restool DPNI Info DPNI.1 DPNI バージョン:8.2 DPNI ID:1 plugged state: plugged endpoint state: 0 endpoint: dpdmux.0.2, リンクはダウン リンク状態: 0 - ダウンMAC アドレス: CE:8A:4D:82:E7:DC 最大フレーム長:1536 dpni_attr.options 値は: 0x80000310 認識されないオプションが見つかり...num_queues:16 num_cgs:24 num_rx_tcs:8 num_tx_tcs:16 mac_entries:16 vlan_entries:16 qos_entries:64 fs_entries:1 qos_key_size:56 fs_key_size:56 午前10時53分     DPAA2フロー制御テーブルが満杯 - 根本原因と解決策 ログと restool 排出量は、明確な事実を物語っている。DPNIオブジェクトには1つの fs_entry のみがプロビジョニングされており、これは最初のフロールール（ UDP 5000 → RXQ 0 ）によって消費されます。ハードウェアファイルシステムテーブルに空き容量がないため、後続の rte_flow_create() 呼び出しは即座に失敗します。 根本的な原因 dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1)   restool によって確認済み： fs_entries: 1 ← only 1 hardware flow-steering slot   DPNIは(DPLまたは restool dpni create を通じて)明示的に fs-entries を設定しずに作成されたため、デフォルトは 1でした。 修正 — より多くのFSエントリを使用してDPNIを再作成する オプション1 — restool 経由で動的に（再フラッシュ不要）： # Destroy the existing DPNI restool dpni destroy dpni.1 # Recreate it with sufficient FS entries (e.g., 16 or 64) restool dpni create \ --options=DPNI_OPT_HAS_KEY_MASKING \ --num-queues=16 \ --fs-entries=64 \ --num-rx-traffic-classes=8 \ --num-tx-traffic-classes=16 # Re-bind to the DPDMUX endpoint restool dpdmux connect dpdmux.0.2 --endpoint=dpni.X dpni.X 、 dpni create 後に表示される新しく作成された ID に置き換えてください。 オプション2 — DPL（データパスレイアウト）ファイルを編集する： DPLファイル（.dts /.dpl ）内の dpni@1 オブジェクトブロックを探してください。そして fs_entries 増やします。 dpni@1 { compatible = "fsl,dpni"; ... fs_entries = <64>; /* was 1, increase as needed */ ... }; 次に、DPLを再読み込みします。 restool dprc load dprc.1 あなたのDPNIにはすでに qos_entries: 64 と qos_key_size: 56 があるので、ハードウェアも対応しています。プロビジョニングされたFSテーブルのサイズが小さすぎただけです。 修正後のクイック検証 # Confirm new fs_entries value restool dpni info dpni. | grep fs_entries # Expected: fs_entries: 64 (or whatever you set)   その後、DPDKアプリケーションを再試すと、 Flow create failed エラーは消えているはずです。   よろしくお願いします。       Re: dpaa2_net: FS table with 1 entries full root@localhost:/home/user# restool DPNI info DPNI.1 DPNIバージョン: 8.2 dpni ID: 1 プラグ状態: プラグ済み エンドポイントの状態: 0 エンドポイント: dpdmux.0.2、リンクがダウンしています リンク状態: 0 - ダウン MACアドレス: ce:8a:4d:82:e7:dc 最大フレーム長: 1536 dpni_attr.options の値は 0x80000310 です。 認識できないオプションが見つかりました... num_queues: 16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries: 16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 Re: dpaa2_net: FS table with 1 entries full ./DPDK-MultirXq-Sample-prog -L 1-3 -n 1 --log-level=FSLMC8 --Huge-dir /dev/hugepages --proc-type=auto -b FSLMC:DPIO.16 -b FSLMC:DPIO.17 -b FSLMC:DPIO.18 -b FSLMC:DPIO.19 -b FSLMC:DPIO.20 -b FSLMC:DPIO.21 -b FSLMC:DPIO.22 -b FSLMC:DPIO.23 -b FSLMC:DPCCP.38 -b FSLMC:DPMCP.39 EAL:16個のlcoreを検出 EAL:NUMAノード1つ検出 EAL:自動検出プロセスタイプ:PRIMARY fslmc: rte_fslmc_parse(): parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 EAL:マルチプロセスソケット /var/run/dpdk/rte/mp_socket fslmc: fslmc_get_container_group(): コンテナ: dprc.2 はVFIO iommuグループID = 11 fslmc: rte_fslmc_parse(): parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: **Devargs が dpmcp.39 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: **Devargs が dpio.18 に一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: **Devargs が dpio.16 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: 無効なデバイス（電源）をスキップします fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: **Devargs が dpio.22 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: **Devargs が dpio.20 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: **Devargs が dpio.19 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: **Devargs が dpmcp.38 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: **Devargs が dpio.17 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: **Devargs が dpio.23 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: **Devargs が dpio.21 と一致しました fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.16) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.17) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.18) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.19) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.20) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.21) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.22) を解析中 fslmc: rte_fslmc_parse(): dev=(dpio.23) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.38) を解析中 fslmc: rte_fslmc_parse(): dev=(dpmcp.39) を解析中 fslmc: FSLMCバスのスキャンが完了しました fslmc: バス上でスキャンされたデバイスのリスト: fslmc: dpni.1 fslmc: dpseci.1 fslmc: dpseci.2 fslmc: dpseci.3 fslmc: dpseci.4 fslmc: dpseci.5 fslmc: dpseci.6 fslmc: dpseci.7 fslmc: dpseci.8 fslmc: dpseci.9 fslmc: dpseci.10 fslmc: dpseci.11 fslmc: dpseci.12 fslmc: dpseci.13 fslmc: dpseci.14 fslmc: dpseci.15 fslmc: dpseci.16 fslmc: dpcon.32 fslmc: dpcon.33 fslmc: dpcon.34 fslmc: dpcon.35 fslmc: dpcon.36 fslmc: dpcon.37 fslmc: dpcon.38 fslmc: dpcon.39 fslmc: dpbp.2 fslmc: dpbp.3 fslmc: dpbp.4 fslmc: dpbp.5 fslmc: dpbp.6 fslmc: dpbp.7 fslmc: dpbp.8 fslmc: dpbp.9 fslmc: dpbp.10 fslmc: dpbp.11 fslmc: dpbp.12 fslmc: dpbp.13 fslmc: dpbp.14 fslmc: dpbp.15 fslmc: dpbp.16 fslmc: dpbp.17 fslmc: dpio.16 fslmc: dpio.17 fslmc: dpio.18 fslmc: dpio.19 fslmc: dpio.20 fslmc: dpio.21 fslmc: dpio.22 fslmc: dpio.23 fslmc: dpio.24 fslmc: dpio.25 fslmc: dpio.26 fslmc: dpio.27 fslmc: dpio.28 fslmc: dpio.29 fslmc: dpio.30 fslmc: dpio.31 fslmc: dpci.0 fslmc: dpci.1 fslmc: dpmcp.37 fslmc: dpmcp.38 fslmc: dpmcp.39 fslmc: dpdmai.0 fslmc: dpdmai.1 fslmc: dpdmai.2 fslmc: dpdmai.3 fslmc: dpdmai.4 fslmc: dpdmai.5 fslmc: dpdmai.6 fslmc: dpdmai.7 fslmc: dpdmux.0 fslmc: dprc.2 EAL: IOVAモード「VA」を選択しました EAL:hugepages-2048kBで利用可能な巨大ページは報告されていません EAL: hugepages-32768kBに報告された利用可能な巨大ページはありません EAL:巨大ページは報告されていません。巨大ページ-64kBで報告されています EAL:VFIOサポートを調査中... EAL:VFIOサポート開始 fslmc: fslmc_get_container_group(): コンテナ: dprc.2 はVFIO iommuグループID = 11 FSLMC: fslmc_vfio_setup_group(): VFIO Container FDは[0x1B] FSLMC: fslmc_map_dma(): --> 地図アドレス:0x140000000、サイズ:1073741824 fslmc: rte_fslmc_vfio_dmamap(): メモリコールバックハンドラをインストールしました fslmc: rte_fslmc_vfio_dmamap(): 合計1セグメントが見つかりました。 fslmc: 領域をマッピングできませんでした (errno = 22) fslmc: dpmcp.38 ブラックリストに登録されているためスキップします fslmc: dpmcp.39 ブラックリストに登録されているためスキップします fslmc: VFIOから抽象化されたデバイス(dprc.2) fslmc: デバイス (dpni.1)VFIOから抜粋 fslmc: デバイス (dpseci.1)VFIOから抜粋 fslmc: VFIOから抽象化されたデバイス(dpseci.2) fslmc: デバイス (dpseci.3)VFIOから抜粋 fslmc: デバイス (dpseci.4)VFIOから抜粋 fslmc: デバイス (dpseci.5)VFIOから抜粋 fslmc: デバイス (dpseci.6)VFIOから抜粋 fslmc: デバイス (dpseci.7)VFIOから抜粋 fslmc: デバイス (dpseci.8)VFIOから抜粋 fslmc: デバイス (dpseci.9)VFIOから抜粋 fslmc: デバイス (dpseci.10)VFIOから抜粋 fslmc: デバイス (dpseci.11)VFIOから抜粋 fslmc: デバイス (dpseci.12)VFIOから抜粋 fslmc: デバイス (dpseci.13)VFIOから抜粋 fslmc: デバイス (dpseci.14)VFIOから抜粋 fslmc: デバイス (dpseci.15)VFIOから抜粋 fslmc: デバイス (dpseci.16)VFIOから抜粋 fslmc: デバイス (dpcon.32)VFIOから抜粋 fslmc: デバイス (dpcon.33)VFIOから抜粋 fslmc: デバイス (dpcon.34)VFIOから抜粋 fslmc: デバイス (dpcon.35)VFIOから抜粋 fslmc: デバイス (dpcon.36)VFIOから抜粋 fslmc: デバイス (dpcon.37)VFIOから抜粋 fslmc: デバイス (dpcon.38)VFIOから抜粋 fslmc: デバイス (dpcon.39)VFIOから抜粋 fslmc: VFIOから抽象化されたデバイス(dpbp.2) fslmc: デバイス (dpbp.3)VFIOから抜粋 fslmc: デバイス (dpbp.4)VFIOから抜粋 fslmc: デバイス (dpbp.5)VFIOから抜粋 fslmc: デバイス (dpbp.6)VFIOから抜粋 fslmc: デバイス (dpbp.7)VFIOから抜粋 fslmc: デバイス (dpbp.8)VFIOから抜粋 fslmc: デバイス (dpbp.9)VFIOから抜粋 fslmc: デバイス (dpbp.10)VFIOから抜粋 fslmc: デバイス (dpbp.11)VFIOから抜粋 fslmc: デバイス (dpbp.12)VFIOから抜粋 fslmc: デバイス (dpbp.13)VFIOから抜粋 fslmc: デバイス (dpbp.14)VFIOから抜粋 fslmc: デバイス (dpbp.15)VFIOから抜粋 fslmc: デバイス (dpbp.16)VFIOから抜粋 fslmc: デバイス (dpbp.17)VFIOからの抽象化 FSLMC: DPIO.16 ブラックリスト入り、スキップ FSLMC: DPIO.17 ブラックリスト入り、スキップ FSLMC:DPIO.18 ブラックリスト入り、スキップ FSLMC: DPIO.19 ブラックリスト入り、スキップ FSLMC:DPIO.20 ブラックリスト入り、スキップ中 FSLMC:DPIO.21 ブラックリスト入り、スキップ中 FSLMC: DPIO.22 ブラックリスト入り、スキップ FSLMC: DPIO.23 ブラックリスト入り、スキップ fslmc: dpaa2_create_dpio_device(): LX2160プラットフォーム検出 FSLMC: デバイス(DPIO.24)VFIOから抜粋 fslmc: デバイス (dpio.25)VFIOから抜粋 fslmc: デバイス (dpio.26)VFIOから抜粋 fslmc: デバイス (dpio.27)VFIOから抜粋 fslmc: デバイス (dpio.28)VFIOから抜粋 fslmc: デバイス (dpio.29)VFIOから抜粋 fslmc: デバイス (dpio.30)VFIOから抜粋 fslmc: デバイス (dpio.31)VFIOから抜粋 fslmc: デバイス (dpci.0)VFIOから抜粋 fslmc: デバイス (dpci.1)VFIOから抜粋 fslmc: デバイス (dpdmai.0)VFIOから抜粋 fslmc: デバイス (dpdmai.1)VFIOから抜粋 fslmc: VFIOから抽象化されたデバイス(dpdmai.2) fslmc: デバイス (dpdmai.3)VFIOから抜粋 fslmc: デバイス (dpdmai.4)VFIOから抜粋 fslmc: デバイス (dpdmai.5)VFIOから抜粋 fslmc: デバイス (dpdmai.6)VFIOから抜粋 fslmc: デバイス (dpdmai.7)VFIOから抜粋 fslmc: デバイス (dpdmux.0)VFIOから抜粋 PMD: dpni.1:NetDevが作成され、DPDMUX.0に接続されました fslmc: dpaa2_get_qbman_swp(): 新しいポータル0x17fff3280(1) 関連スレッド - 8602 fslmc: dpaa2_configure_stashing(): Portal=1 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17fff3280 (1) はスレッド8602に関連しています ポート0は2つのRXキューと7つのTXキューから始まりました UDPポート5000 -> RXQ 0の作成 dpaa2_net:1エントリ満員のFS表 dpaa2_net:フローの作成失敗、返却コード(-1) フロー作成失敗:不明 fslmc: dpaa2_get_qbman_swp(): 新しいポータル0x17ffebbc0(2) 関連スレッド - 8602 fslmc: dpaa2_configure_stashing(): Portal= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) はスレッド8602へのeth rxに適しています Re: dpaa2_net: FS table with 1 entries full 解決しました。ありがとうございます。

关于现场噪声是否会导致数据篡改的调查 你好，恩智浦。我们目前正在进行一个使用 S32K312 MCU 的项目。 我们写信询问是因为我们在现场遇到了一台有缺陷的设备。在对故障单元进行分析时，我们将正常单元和正常单元的转储文件进行了比较，发现两者在某些特定方面存在差异。 jeongwoo_0-1786583945706.png 左边的照片是普通的 DUMP 文件，右边的照片是高质量的 DUMP 文件。 故障与暗电流问题有关。通过 Trace32 访问后，我们确认看门狗在控制器睡眠过程中不断触发 RESET。 左图显示的是正常的转储文件，右图显示的是有缺陷的转储文件。 检查 .map 文件时文件问题与 LIN 部分 (Mcal_LIN) 有关。我们的项目不使用 LIN 收发器，并且 LIN 相关功能已被禁用。 我们正在考虑两种可能性： 1. 写入过程中噪声引起的数据篡改 2. 现场噪声引起的CodeFlash篡改 现场静电或电源中断产生的噪声是否有可能导致 CodeFlash 区域被篡改？进入睡眠模式时，Wdg 会进行重置。有什么方法可以确定导致 Wdg 重置的原因吗？ Re: Inquiry regarding whether data tampering can occur due to noise in the field 你好@jeongwoo 。 这是一个 S 记录，类型为 S3，字节数为 0x25。 记录从地址 0x0046D0E0 开始。 数据有效载荷只有 4 个字节不同，地址为 0x0046D0F8：0x11 00 02 00 变为 0x40 78 09 78，S 记录校验和也相应地从 0x89 变为 0x63。 值得注意的是，比特位在两个方向上都发生了翻转——从 1 到 0 和从 0 到 1。 在 NOR 闪存中，位只能从 1 编程到 0；将位从 0 翻转到 1 需要先进行扇区擦除。 因此，0 到 1 的转换不可能是简单的编程操作的结果。 要在不擦除的情况下将位从 0 更改为 1，需要从隔离的浮栅中移除电荷，这既需要能量也需要放电路径。EMI无法提供这项服务。足以使浮栅放电的静电放电几乎肯定会造成更广泛的损害。关于 SEU，我们观察到 4 个独立字节中发生了多次比特翻转。 更可能的解释是，这台有缺陷的机器从一开始就被编程使用了不同的二进制文件，并且自最初的生产编程以来，闪存内容从未改变过。在这种情况下，存储在闪存中的 ECC 校验和将与数据一致，读取闪存时不会报告 ECC 错误。你能确认一下吗？如果内容在编程后损坏，则读取地址 0x0046D0F8 处的闪存时应该会触发 ECC 错误——从 TRACE32 读取时，您是否在该位置看到 ???? 显示？另外，您能阅读一下 DCMROD4[12] 吗？ 关于看门狗重置，你指的是哪个看门狗？可能是 SWT、外部看门狗或 POR_WDOG。 当看门狗未得到服务时，通常会触发 SWT（或外部看门狗）RESET，这是因为程序执行陷入了循环。如果情况确实如此，能否禁用看门狗并将调试器连接到 MCU，以捕获程序执行停止的位置？如果是 POR_WDOG RESET，请读取寄存器 DCMROPP1–DCMROPP4，其中将提供有关 RESET 的更多详细信息。 此致， 丹尼尔 Re: Inquiry regarding whether data tampering can occur due to noise in the field 您好，谢谢您的回复。 换句话说，您的意思是说这 4 字节的差异很可能不是由字段因素造成的吗？我们目前没有原件，因此很难执行您提到的地址读取和寄存器验证。 1.我想了解一下该领域是否有类似的案例。如果是这样，是否涉及多个字节的更改？ 2. 如果在写入过程中写入了因噪声而修改过的固件，您能否具体告诉我，造成写入噪声的原因可能是什么？ Re: Inquiry regarding whether data tampering can occur due to noise in the field 你好@jeongwoo ， 1. 我不知道有任何类似案例。 2. 这目前只是一个假设——需要先进行检验。 如果受影响的地址处没有 ECC 错误，则闪存很可能从一开始就被编程了此内容。 如果出现 ECC 错误，则记录已损坏，但损坏极有可能发生在编程过程中，而不是在数据写入闪存之后。可能的原因包括电源不稳定或闪存写入操作期间中断。 完成镜像编程后，您是否检查过闪存内容？ 验证过程中是否使用边际读取？ 你们会保留生产编程过程的日志吗？ 闪光灯在运行时是否会被修改，还是在工厂编程一次后就再也不会被修改？ 此致， 丹尼尔

IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure I have configured AE LIMITS with the maximum exposure set accordingly. However, during runtime, the AE algorithm only reaches 66666 exposure at most,and the gain hits its upper limit at this point. Readings via V4L2 confirm that AE exposure reaches less than half of the configured upper limit. LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png When manually configuring exposure via Live Control, the valid exposure can reach 150000,V4L2 exposure can also reach the upper limit. We suspect this issue is related to RowTime. We modified the Row Time parameter inside AE Dister, but this change shows no visible effect; the auto exposure performance remains exactly the same as before. We would like to know what adjustments are required to allow the AE algorithm to reach the configured maximum exposure under low-light conditions. Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure Based on the current behavior, the AE algorithm appears to be limited by the active sensor mode frame duration rather than by the absolute manual exposure capability. The value 66666 us corresponds to one frame at 15 fps. Therefore, even if the AE LIMITS maximum is set to 150000 us , AE will not be able to apply it unless the active sensor timing allows a frame period longer than 150 ms, or unless the driver/helper path extends VBLANK/frame length before programming exposure. Please check whether the sensor driver exposes and correctly updates V4L2_CID_EXPOSURE , V4L2_CID_VBLANK , V4L2_CID_HBLANK , and V4L2_CID_PIXEL_RATE . For low-light AE to reach 150000 us , the active frame rate must be reduced to about 6.67 fps or lower, or the AE control path must dynamically increase VBLANK/frame length. Changing Row Time in AE Dister alone may not affect AE if the active exposure range reported through the V4L2/CameraHelper path remains capped at about 66666 us . Please also confirm that the modified AE parameters are saved into the active DTP file referenced by config_ipa_uguzzi.yaml , copied to /usr/share/libcamera/ipa/nxp/neo/uguzzi/ , and that the camera pipeline is restarted or the corresponding algorithm reconfiguration is applied. Live Control changes are generally temporary unless saved into the project/DTP or applied through the proper reconfiguration path. My recommendation: treat this first as a frame-duration/VBLANK exposure-range issue, then verify DTP/profile activation. The fact that manual exposure reaches 150000 us is useful, but it does not prove the AE loop is allowed to request that value unless the AE-visible exposure range and frame timing are also updated.

dpaa2_net：文件系统表已满，包含 1 个条目 嗨，正在创建 1 个 dpni 和 dpdmux。 在端口 0 上创建 2 个 RXQ。 添加 rte_flow，如下所示 memset(&udp_spec, 0, sizeof(udp_spec)); memset(&udp_mask, 0, sizeof(udp_mask)); udp_spec.hdr.dst_port= rte_cpu_to_be_16(udp_port); udp_mask.hdr.dst_port= 0xffff; pattern[0].type = RTE_FLOW_ITEM_TYPE_UDP; pattern[0].spec= &udp_spec; 图案[0].掩码= &udp_mask; pattern[1].type = RTE_FLOW_ITEM_TYPE_END; 操作[0].类型= RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf= &队列 操作[1].类型= RTE_FLOW_ACTION_TYPE_END; struct rte_flow *flow = rte_flow_create(port_id, &attr， 图案， 行动， ＆错误）; 在端口 0 上为 RXQ 0 和 RXQ 1 创建 2 个流 创建 UDP 队列流（端口 ID，5000，0）； 创建 UDP 队列流（端口 ID，5001，1）； 出现以下错误。 dpaa2_net：文件系统表已满，包含 1 个条目 Re: dpaa2_net: FS table with 1 entries full 你好， 日志和 restool 输出清楚地说明了情况。DPNI 对象仅配置了1 个 fs_entry ，该 fs_entry 被第一个流规则（ UDP 5000 → RXQ 0 ）消耗。任何后续的 rte_flow_create() 调用都会立即失败，因为硬件 FS 表没有剩余空间。 端口 0 启动，有 2 个 RX 队列和 7 个 TX 队列，UDP 端口 5000 -> RXQ 0 创建 dpaa2_net：FS 表已满，包含 1 个条目 dpaa2_net：创建流失败，返回代码 (-1) 流创建失败：未知 fslmc：dpaa2_get_qbman_swp()：新 Portal 0x17ffebbc0 (2) 关联线程 - 8602 fslmc：dpaa2_configure_stashing()：Portal= 2 CPU= 1 SDEST= 0 fslmc：DPAA Portal=0x17ffebbc0 (2) 已关联到线程 8602 的以太网接收 root@localhost:/home/user# restool dpni info dpni.1 dpni 版本：8.2 dpni ID：1 已插入状态：已插入 端点状态：0 端点：dpdmux.0.2，链路已断开 链路状态：0 - 断开 MAC 地址： ce:8a:4d:82:e7:dc 最大帧长度：1536 dpni_attr.options 值为：0x80000310 发现无法识别的选项... num_queues：16 num_cgs：24 num_rx_tcs：8 num_tx_tcs：16 mac_entries：16 vlan_entries：16 qos_entries：64 fs_entries：1 qos_key_size：56 fs_key_size：56 上午10:53     DPAA2 流量控制表已满 — 根本原因及解决方法 日志和 restool 输出清楚地说明了情况。DPNI 对象仅配置了1 个 fs_entry ，该 fs_entry 被第一个流规则（ UDP 5000 → RXQ 0 ）消耗。任何后续的 rte_flow_create() 调用都会立即失败，因为硬件 FS 表没有剩余空间。 根本原因 dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1)   经 restool 确认： fs_entries: 1 ← only 1 hardware flow-steering slot   DPNI 是通过 DPL 或 restool dpni create 创建的，但没有显式设置 fs-entries ，因此其默认值为1 。 修复——使用更多文件系统条目重新创建 DPNI 选项 1 — 通过 restool 动态更新（无需重新刷写固件）： # Destroy the existing DPNI restool dpni destroy dpni.1 # Recreate it with sufficient FS entries (e.g., 16 or 64) restool dpni create \ --options=DPNI_OPT_HAS_KEY_MASKING \ --num-queues=16 \ --fs-entries=64 \ --num-rx-traffic-classes=8 \ --num-tx-traffic-classes=16 # Re-bind to the DPDMUX endpoint restool dpdmux connect dpdmux.0.2 --endpoint=dpni.X 将 dpni.X 替换为 dpni create 后显示的新创建的 ID。 选项 2 — 编辑 DPL（数据路径布局）文件： 在您的 DPL（.dts /.dpl ）文件中找到 dpni@1 对象块。 并增加 fs_entries ： dpni@1 { compatible = "fsl,dpni"; ... fs_entries = <64>; /* was 1, increase as needed */ ... }; 然后重新加载DPL： restool dprc load dprc.1 您的 DPNI 已经设置了 qos_entries: 64 和 qos_key_size: 56 ，因此硬件支持它——只是配置的 FS 表大小太小了。 修复后快速验证 # Confirm new fs_entries value restool dpni info dpni. | grep fs_entries # Expected: fs_entries: 64 (or whatever you set)   然后重试您的 DPDK 应用程序—— Flow create failed 错误应该会消失。   此致问候       Re: dpaa2_net: FS table with 1 entries full root@localhost:/home/user# restool dpni info dpni.1 DPNI 版本：8.2 dpni id：1 已连接状态：已连接 端点状态：0 端点：dpdmux.0.2，链路已断开 链路状态：0 - 已断开 MAC地址：ce:8a:4d:82:e7:dc 最大帧长度：1536 dpni_attr.options 的值为：0x80000310 发现无法识别的选项…… 队列数量：16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries：16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 Re: dpaa2_net: FS table with 1 entries full ./dpdk-multirxq-sample-prog -l 1-3 -n 1 --log-level=fslmc,8 --huge-dir /dev/hugepages --proc-type=auto -b fslmc:dpio.16 -b fslmc:dpio.17 -b fslmc:dpio.18 -b fslmc:dpio.19 -b fslmc:dpio.20 -b fslmc:dpio.21 -b fslmc:dpio.22 -b fslmc:dpio.23 -b fslmc:dpmcp.38 -b fslmc:dpmcp.39 EAL：检测到 16 个逻辑核心 EAL：检测到 1 个 NUMA 节点 EAL：自动检测到的进程类型：主进程 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) EAL：多进程套接字 /var/run/dpdk/rte/mp_socket fslmc：fslmc_get_container_group()：容器：dprc.2 具有 VFIO iommu 组 ID = 11 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：**Devargs 与 dpmcp.39 匹配 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：**Devargs 与 dpio.18 匹配 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：**Devargs 匹配 dpio.16 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：跳过无效设备（电源） fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：**Devargs 匹配 dpio.22 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：**Devargs 匹配 dpio.20 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：**Devargs 匹配 dpio.19 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：**Devargs 与 dpmcp.38 匹配 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：**Devargs 匹配 dpio.17 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：**Devargs 匹配 dpio.23 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：**Devargs 匹配 dpio.21 fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.16) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.17) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.18) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.19) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.20) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.21) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.22) fslmc：rte_fslmc_parse()：正在解析 dev=(dpio.23) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.38) fslmc：rte_fslmc_parse()：正在解析 dev=(dpmcp.39) fslmc：FSLMC 总线扫描完成 fslmc：总线上扫描到的设备列表： fslmc：dpni.1 fslmc：dpseci.1 fslmc：dpseci.2 fslmc：dpseci.3 fslmc：dpseci.4 fslmc：dpseci.5 fslmc：dpseci.6 fslmc：dpseci.7 fslmc：dpseci.8 fslmc：dpseci.9 fslmc：dpseci.10 fslmc：dpseci.11 fslmc：dpseci.12 fslmc：dpseci.13 fslmc：dpseci.14 fslmc：dpseci.15 fslmc：dpseci.16 fslmc：dpcon.32 fslmc：dpcon.33 fslmc：dpcon.34 fslmc：dpcon.35 fslmc：dpcon.36 fslmc：dpcon.37 fslmc：dpcon.38 fslmc：dpcon.39 fslmc：dpbp.2 fslmc：dpbp.3 fslmc：dpbp.4 fslmc：dpbp.5 fslmc：dpbp.6 fslmc：dpbp.7 fslmc：dpbp.8 fslmc：dpbp.9 fslmc：dpbp.10 fslmc：dpbp.11 fslmc：dpbp.12 fslmc：dpbp.13 fslmc：dpbp.14 fslmc：dpbp.15 fslmc：dpbp.16 fslmc：dpbp.17 fslmc：dpio.16 fslmc：dpio.17 fslmc：dpio.18 fslmc：dpio.19 fslmc：dpio.20 fslmc：dpio.21 fslmc：dpio.22 fslmc：dpio.23 fslmc：dpio.24 fslmc：dpio.25 fslmc：dpio.26 fslmc：dpio.27 fslmc：dpio.28 fslmc：dpio.29 fslmc：dpio.30 fslmc：dpio.31 fslmc：dpci.0 fslmc：dpci.1 fslmc：dpmcp.37 fslmc：dpmcp.38 fslmc：dpmcp.39 fslmc：dpdmai.0 fslmc：dpdmai.1 fslmc：dpdmai.2 fslmc：dpdmai.3 fslmc：dpdmai.4 fslmc：dpdmai.5 fslmc：dpdmai.6 fslmc：dpdmai.7 fslmc：dpdmux.0 fslmc：dprc.2 EAL：已选择 IOVA 模式“VA” EAL：hugepages-2048kB 中未报告可用巨页。 EAL：在 hugepages-32768kB 中未报告可用巨页。 EAL：hugepages-64kB 中未报告可用巨页。 EAL：正在探测 VFIO 支持…… EAL：VFIO 支持已初始化 fslmc：fslmc_get_container_group()：容器：dprc.2 具有 VFIO iommu 组 ID = 11 fslmc：fslmc_vfio_setup_group()：VFIO 容器文件描述符为 [0x1B] fslmc：fslmc_map_dma()：--> 映射地址：0x140000000，大小：1073741824 fslmc：rte_fslmc_vfio_dmamap()：已安装内存回调处理程序 fslmc：rte_fslmc_vfio_dmamap()：共找到 1 个段。 fslmc：无法映射区域（错误号 = 22） fslmc：dpmcp.38 已列入黑名单，跳过 fslmc：dpmcp.39 已列入黑名单，跳过 fslmc：从 VFIO 抽象出来的设备 (dprc.2) fslmc：设备 (dpni.1)摘自 VFIO fslmc：设备 (dpseci.1)摘自 VFIO fslmc：从 VFIO 抽象出来的设备 (dpseci.2) fslmc：设备 (dpseci.3)摘自 VFIO fslmc：设备 (dpseci.4)摘自 VFIO fslmc：设备 (dpseci.5)摘自 VFIO fslmc：设备 (dpseci.6)摘自 VFIO fslmc：设备 (dpseci.7)摘自 VFIO fslmc：设备 (dpseci.8)摘自 VFIO fslmc：设备 (dpseci.9)摘自 VFIO fslmc：设备 (dpseci.10)摘自 VFIO fslmc：设备 (dpseci.11)摘自 VFIO fslmc：设备 (dpseci.12)摘自 VFIO fslmc：设备 (dpseci.13)摘自 VFIO fslmc：设备（dpseci.14）摘自 VFIO fslmc：设备（dpseci.15）摘自 VFIO fslmc：设备 (dpseci.16)摘自 VFIO fslmc：设备（dpcon.32）摘自 VFIO fslmc：设备（dpcon.33）摘自 VFIO fslmc：设备（dpcon.34）摘自 VFIO fslmc：设备（dpcon.35）摘自 VFIO fslmc：设备（dpcon.36）摘自 VFIO fslmc：设备（dpcon.37）摘自 VFIO fslmc：设备（dpcon.38）摘自 VFIO fslmc：设备（dpcon.39）摘自 VFIO fslmc：从 VFIO 抽象出来的设备 (dpbp.2) fslmc：设备 (dpbp.3)摘自 VFIO fslmc：设备（dpbp.4）摘自 VFIO fslmc：设备（dpbp.5）摘自 VFIO fslmc：设备 (dpbp.6)摘自 VFIO fslmc：设备 (dpbp.7)摘自 VFIO fslmc：设备（dpbp.8）摘自 VFIO fslmc：设备（dpbp.9）摘自 VFIO fslmc：设备（dpbp.10）摘自 VFIO fslmc：设备（dpbp.11）摘自 VFIO fslmc：设备（dpbp.12）摘自 VFIO fslmc：设备（dpbp.13）摘自 VFIO fslmc：设备（dpbp.14）摘自 VFIO fslmc：设备（dpbp.15）摘自 VFIO fslmc：设备（dpbp.16）摘自 VFIO fslmc：设备（dpbp.17）摘自 VFIO fslmc：dpio.16 已列入黑名单，跳过 fslmc：dpio.17 已列入黑名单，跳过 fslmc：dpio.18 已列入黑名单，跳过 fslmc：dpio.19 已列入黑名单，跳过 fslmc：dpio.20 已列入黑名单，跳过 fslmc：dpio.21 已列入黑名单，跳过 fslmc：dpio.22 已列入黑名单，跳过 fslmc：dpio.23 已列入黑名单，跳过 fslmc：dpaa2_create_dpio_device()：检测到 LX2160 平台 fslmc：设备（dpio.24）摘自 VFIO fslmc：设备（dpio.25）摘自 VFIO fslmc：设备（dpio.26）摘自 VFIO fslmc：设备（dpio.27）摘自 VFIO fslmc：设备（dpio.28）摘自 VFIO fslmc：设备（dpio.29）摘自 VFIO fslmc：设备（dpio.30）摘自 VFIO fslmc：设备（dpio.31）摘自 VFIO fslmc：设备 (dpci.0)摘自 VFIO fslmc：设备 (dpci.1)摘自 VFIO fslmc：设备 (dpdmai.0)摘自 VFIO fslmc：设备（dpdmai.1）摘自 VFIO fslmc：从 VFIO 抽象出来的设备 (dpdmai.2) fslmc：设备（dpdmai.3）摘自 VFIO fslmc：设备（dpdmai.4）摘自 VFIO fslmc：设备（dpdmai.5）摘自 VFIO fslmc：设备 (dpdmai.6)摘自 VFIO fslmc：设备 (dpdmai.7)摘自 VFIO fslmc：设备 (dpdmux.0)摘自 VFIO PMD：dpni.1：网络设备已创建，已连接到 dpdmux.0 fslmc：dpaa2_get_qbman_swp()：新传送门 0x17fff3280 (1) 关联线程 - 8602 fslmc：dpaa2_configure_stashing()：Portal= 1 CPU= 1 SDEST= 0 fslmc：DPAA Portal=0x17fff3280 (1) 与线程 8602 关联 端口 0 初始有 2 个接收队列和 7 个发送队列。 UDP 端口 5000 -> RXQ 0 已创建 dpaa2_net：文件系统表已满，包含 1 个条目 dpaa2_net：创建流程失败，返回代码（-1） 流程创建失败：未知 fslmc：dpaa2_get_qbman_swp()：新传送门 0x17ffebbc0 (2) 关联线程 - 8602 fslmc：dpaa2_configure_stashing()：Portal= 2 CPU= 1 SDEST= 0 fslmc：DPAA Portal=0x17ffebbc0 (2) 已关联到 eth rx 线程 8602 Re: dpaa2_net: FS table with 1 entries full 谢谢，问题已解决。

現場のノイズによるデータ改ざんの可能性についての調査 こんにちは、NXP。現在、S32K312 MCUを使ったプロジェクトに取り組んでいます。 現場で不具合のある製品に遭遇したため、お問い合わせさせていただきます。不良ユニットの解析中に、正常ユニットのダンプファイルと正常ユニットのダンプファイルを比較したところ、両者の特定の領域に違いが見られました。 jeongwoo_0-1786583945706.png 左の写真は通常のDUMPファイルで、右の写真は高品質なDUMPファイルです。 この不具合は、暗電流の問題に関連しています。Trace32経由でアクセスしたところ、コントローラの スリープ処理中にウォッチドッグが継続的にリセットをトリガーしていることを確認しました。 左側の画像は正常なダンプファイルを示しており、右側の画像は欠陥のあるダンプファイルを示しています。 .mapを確認するとこの問題はLINセクションに関連しています(Mcal_LIN)。私たちのプロジェクトではLINトランシーバーは使っておらず、LIN関連機能はブロックされています。 私たちは2つの可能性を検討しています。 1. 書き込みプロセス中のノイズによるデータ改ざん 2. 現場のノイズによるCodeFlashの改ざん 現場で静電気や停電によるノイズがCodeFlashエリアの改ざんを引き起こす可能性はありますか?Wdgによるリセットはスリープモードに入ると発生します。このWdgリセットの原因を特定する方法はありますか？ Re: Inquiry regarding whether data tampering can occur due to noise in the field こんにちは、 @jeongwoo さん。 これはSレコードで、タイプはS3、バイト数は0x25です。 レコードはアドレス0x0046D0E0から始まります。 データペイロードではアドレス0x0046D0F8の4バイトのみが異なり、0x11 00 02 00が0x40 78 09 78に変更され、Sレコードのチェックサムもそれに合わせて0x89から0x63に変更されます。 注目すべき点は、ビットが1から0、そして0から1へと両方向に反転されることである。 NORフラッシュでは、ビットは1から0までしかプログラムできません。0から1に少し切り替えるには、まずセクター消去が必要です。 したがって、0から1への遷移は単純なプログラミング操作の結果ではありえません。 消去せずにビットを0から1に変更するには、分離された浮遊ゲートから電荷を除去する必要があり、そのためにはエネルギーと放電経路の両方が必要となる。EMIはこれを提供できません。浮遊ゲートを放電させるのに十分なエネルギーを持つESDは、ほぼ確実に広範囲にわたる損傷を引き起こすだろう。SEUに関しては、4つの異なるバイトにわたって多数のビット反転が観測された。 より可能性の高い説明としては、欠陥のあるユニットは最初から異なるバイナリでプログラムされており、初期生産時のプログラミング以降、フラッシュメモリの内容は一度も変更されていないということが考えられる。その場合、フラッシュに保存されたECCチェックサムはデータと整合し、フラッシュを読み取ってもECCエラーは報告されません。これを確認していただけますか?プログラミング後に内容が破損した場合、アドレス 0x0046D0F8 のフラッシュを読み取ると ECC エラーが発生するはずです。TRACE32 から読み取ったときに、この場所に ???? が表示されますか？さらに、DCMROD4[12]を読んでいただけますか? ウォッチドッグリセットについてですが、どのウォッチドッグのことでしょうか？それはSWT、外部ウォッチドッグ、またはPOR_WDOGのいずれかである可能性があります。 SWT（または外部ウォッチドッグ）のリセットは、ウォッチドッグが処理されない場合にトリガーされます。これは通常、実行がループに陥っていることが原因です。もしそうなら、ウォッチドッグを無効にしてデバッガをMCUに接続して、実行が停止する部分をキャプチャすることはできますか?POR_WDOGリセットの場合は、レジスタDCMROPP1～DCMROPP4を読み取ってください。より詳細な情報が得られます。 よろしくお願いいたします。 ダニエル Re: Inquiry regarding whether data tampering can occur due to noise in the field こんにちは、ご返信ありがとうございます。 つまり、4バイトの差はフィールド要因によるものではない可能性が高いということですか？現在、元の部品は手元にないため、ご指摘の住所確認や登録簿の確認が難しいです。 1.この分野で同様の事例があるかどうかを伺いたいです。もしそうなら、複数のバイトが変更されたケースだったのでしょうか? 2. ノイズのためにファームウェアが修正された場合、その書き込みノイズの具体原因を教えてもらえますか? Re: Inquiry regarding whether data tampering can occur due to noise in the field こんにちは、 @jeongwoo さん。 1. 同様の事例は私の知る限りありません。 2. これは現時点では単なる仮説であり、まずは検証する必要がある。 該当アドレスでECCエラーが発生していない場合、フラッシュメモリには最初からこの内容が書き込まれている可能性が高い。 ECCエラーが発生した場合、レコードが破損していることを意味しますが、その破損はデータがフラッシュメモリに書き込まれた後よりも、プログラミング中に発生した可能性が圧倒的に高いです。考えられる原因としては、電源の不安定性や、フラッシュ書き込み処理中の中断などが挙げられます。 イメージをプログラムした後、フラッシュメモリの内容を確認しますか？ 検証時にマージン読み取りを使用していますか？ 実稼働中のプログラミングプロセスに関するログは保存していますか？ フラッシュメモリは実行時に変更されることはありますか？それとも工場で一度プログラムされた後は二度と変更されないのでしょうか？ よろしくお願いいたします。 ダニエル

virtual machine vm mc9s08qg8 does nxp support vm on windows 11 ? i want to build a vm and download cw(classic IDE) v5.2 so i can use my wiztronics burner board! Is this possible with NXP software. Do u support this action!!!!!!!! Re: virtual machine vm mc9s08qg8 Hello The usage of Virtual machines is not recommended, we cannot guarantee proper functionality when running tools in the IDE inside a virtual machine; The recommended path is to install the tool natively on a supported OS and using the corresponding version, In this case for windows 11 the CodeWarrior version is 11.1 Best Regards

ls104x 更高版本的 Linux 6.+ NXP 官方是否为 LS104X 芯片提供了更高版本的 Linux 6.0 或更高版本？能否提供下载链接？ Re: ls104x higher version of Linux 6.+ 请参考以下链接。 https://github.com/nxp-qoriq/yocto-sdk 分支 版本 蚁鼻 YP 6.0-lf-6.18.20 惠尼拉特 YP 5.3-lf-6.18.2 瓦尔纳斯卡 YP 5.2-lf-6.12.49 斯泰黑德 YP 5.1-lf-6.12.3 疤痕裂缝 YP 5.0-lf-6.6.52 南比尔德 YP 4.3-lf-6.6.3 米克尔多尔 YP 4.2–lf-6.1.55 朗代尔 YP 4.1–lf-6.1.1

MC33XS2410 - NRNDステータス こんにちは！ 現在、24Vオートモーティブ環境向けの比例ソレノイドドライバを含むデザインに取り組んでいます。MC33XS2410は私たちに非常に適しており、事前設計テストのために評価ボードも取得しました。 しかし、NXPのウェブサイトの製品ページでNRNDの状態を確認したのは最近のことで、他の場所では見られませんでした。 この状況についてもう少し詳しく教えてもらえますか?本当に新しいデザインにはもう推奨されていないのでしょうか?私たちのアプリケーションに考慮できる代替案はありますか? 前もって感謝します！ Re: MC33XS2410 - NRND Status MC33XS2410はNRNDステータスです。 ピン・ツー・ピン対応部品はご用意していませんが、NXPのハイサイドスイッチ部品については以下のリンクからご覧ください。 ハイサイド・スイッチ | NXP Semiconductors

ls104x higher version of Linux 6.+ Does NXP officially have a higher version of Linux 6.0 or above for the LS104X chip? Can you provide a download link Re: ls104x higher version of Linux 6.+ Please refer to the following link. https://github.com/nxp-qoriq/yocto-sdk Branch Version wrynose YP 6.0-lf-6.18.20 whinlatter YP 5.3-lf-6.18.2 walnascar YP 5.2-lf-6.12.49 styhead YP 5.1-lf-6.12.3 scarthgap YP 5.0-lf-6.6.52 nanbield YP 4.3-lf-6.6.3 mickledore YP 4.2–lf-6.1.55 langdale YP 4.1–lf-6.1.1

虚拟机 vm mc9s08qg8 NXP支持Windows 11上的虚拟机吗？我想建一个 vm 然后下载 cw（经典 IDE）v5.2 这样我就可以使用我的 wiztronics 烧录板了！这能用NXP软件实现吗？你支持这一行动吗!!!!!!! Re: virtual machine vm mc9s08qg8 Hello 不建议使用虚拟机，我们无法保证在虚拟机内运行 IDE 中的工具时能够正常运行； 推荐的做法是在受支持的操作系统上以原生方式安装该工具，并使用相应的版本。在本例中，Windows 11 的 CodeWarrior 版本为 11.1。 顺祝商祺！