Deep Sleep Mode of iMX937 I am using iMX95lpddr5 evk, triggered the deep sleep mode want to know about the state, clock frequency and power consumption of suspended and non suspended cores among A55, M7 and M33. Re: Deep Sleep Mode of iMX937 On i.MX95 LPDDR5 EVK, “deep sleep” maps to the i.MX 95 Suspend / DSM-style low-power cases . The A55 is suspended/power-gated; M33 is not running application workload, typically shown as clock-gated/idle ; M7 depends on whether you suspend it too or keep it as the wake/real-time core. The power numbers in AN14449 are SoC rail/group totals , not per-core power. Low-power case Cortex-A55 state / freq Cortex-M33 state / freq Cortex-M7 state / freq DDR state Reported power System in DSM Suspend; clock not detectable Clock gating; clock not detectable Suspend; clock not provided Retention 25.65 mW GROUP_SOC_FULL total  Linux Suspend + CM7 WFI Suspend / 0 Clock gating or idle / 0 WFI / 400 MHz Retention 178.48 mW GROUP_SOC_FULL total  Linux Suspend + CM7 CoreMark (TCM) Suspend / 0 Clock gating or idle / 0 CoreMark / 400 MHz Retention 197.24 mW GROUP_SOC_FULL total  Linux Suspend + CM7 FlexCAN transaction Suspend / 0 Clock gating or idle / 0 FlexCAN / 800 MHz Active, 6400 MT/s 659.71 mW GROUP_SOC_FULL total  Linux Suspend + CM7 NETC / Ethernet Suspend / 0 Clock gating or idle / 0 NETC / 800 MHz Active, 6400 MT/s 956.17 mW GROUP_SOC_FULL total  Linux Suspend + WoL A55 suspended M33 idle/low-power context wake-capable configuration; exact core table not in the retrieved chunk depends on WoL setup 342.72 mW GROUP_SOC_FULL total  A few interpretation notes: The i.MX 95 Reference Manual describes Suspend as the maximum-power-saving mode where unnecessary clocks/supplies are off, the Cortex-A55 CPU is fully power-gated, PHYs that can be powered down are off, and VDD_SOC is reduced to suspend voltage. In System in DSM , AN14449 explicitly says the usage is CA55=Suspend, CM33=Clock gating, CM7=Suspend, DDR=Retention , and also notes that because CA55 and CM33 are not working, clocks cannot be detected. For Linux suspend with M7 kept active, the non-suspended core is CM7 ; its clock is either 400 MHz for WFI/CoreMark retention cases or 800 MHz for FlexCAN/NETC cases, while A55 and M33 show 0 MHz in the case tables. The published power data is not isolated per A55/M7/M33 core . AN14449 reports rail/group measurements such as GROUP_SOC_FULL and GROUP_DRAM; for example, DSM reports vdd_arm as 0 mW and vdd_soc as 3.85 mW within a GROUP_SOC_FULL sum of 25.65 mW, but that is still rail-level, not individual-core power. Takeaway: if M7 is also suspended, DSM is about 25.65 mW; if M7 stays alive during Linux suspend, total SoC power rises from about 178–197 mW at 400 MHz to about 660–956 mW at 800 MHz depending on the peripheral workload. Re: Deep Sleep Mode of iMX937 For I.Mx95, there are several power mode including RUN mode, Lower power RUN mode, IDLE mode, SUSPEND mode and Battery Backed Secure Module mode. For detailed power consumption data, please refer to IMX95AEC datasheet. For i.Mx937, the device is at preproduction phase and only factsheet is available right now. Not sure about how the test data come from and what the deep sleep mode you refer to...

关于GUI Guider v2.0.0的UI编辑器Bug反馈 我在使用GUI Guider v[你的版本号]时，遇到了几个影响开发效率的Bug，想向开发团队反馈一下： 拖动布局导致布局丢失：当我在UI编辑器中拖动控件进行布局调整时，操作偶尔会失败，并且最新的布局改动会丢失，界面回退到之前的状态。 控件名称重复且无法删除：在操作过程中，有时会出现多个控件名称一致的情况，并且这些控件无法通过右键菜单或Delete键删除。唯一能解决的办法是重新登录软件，这些“幽灵”控件才会消失。 Re: 关于GUI Guider v2.0.0的UI编辑器Bug反馈 您好@CN10086 非常感谢您分享这些反馈意见。 如果您能提供更多详细信息，例如屏幕截图、视频或重现步骤，我们将不胜感激。 BR 哈里

CodeWarrior for LA1224 plugin Hello,  I am currently In the middle of evaluating LA1224-RDB and I have some questions regarding the software environment. As I understand I can have a Linux app running on the existing NxP image on LX2160A for evaluation purposes. Furthermore I suppose LA1224 is running baremetal with freertos. I saw that I can have firmware for LA1224 in a Linux directory on the LX2160A. Is this given from NxP? What does it support? I suppose that if I want to develop something further than the given firmware I have to get a codewarrior license and TAP. I have downloaded CW_ARMv8_v2020.06_b200629GA_Win_Setup.exe however the LP1224 is not available. After searching the NxP site I read that I need an extra toolchain on top of CW_ARMv8. What is the full url to download the add on?  I read CodeWarrior for LA1224 and only a partial url is given "com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip" Any further information on how to work on those processors is welcome. Kind Regards N. Alexopoulos Re: CodeWarrior for LA1224 plugin Please download pack com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip from the following link. https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US Please prepare a clean installation environment. Please install CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe first. Then open CodeWarrior IDE in a new worksapce path. Then install the service pack com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip from Help->Install New Software->Add->Archive in CodeWarrior IDE.

Display resolution setup on imx8qm with AAOS 15 Hi Team, We are using AAOS 15.0.0_2.1.0 on i.MX8QM MEK. After flashing the board, the physical displays resolution is always set to 1024x600, while we want the display to run at 1920x1080. And we have multi display setup which has android main default display and passenger display. We verified that 1920x1080 is available in the supported display modes, but the active display mode after boot remains 1024x600. We also tried setting the preferred display mode to 1920x1080 from Android, but after reboot the display still comes up in 1024x600. Could you please advise: What determines the default physical display resolution during boot? How can we force the physical display resolution to 1920x1080@60Hz after boot? Is there any configuration required for ro.boot.displaymode, Display HAL, HWC3, or DRM to make 1920x1080 the default active mode? Any guidance would be appreciated. Re: Display resolution setup on imx8qm with AAOS 15 Hello, Please refer to the Android Automotive documentation we have available here: https://www.nxp.com/docs/en/user-guide/UG10176.pdf Especifically have a look to the chapter 8.3.4 Configuring the primary display resolution of the document above. Best regards/Saludos, Aldo.

S32DS license ActivationId Hello, When I opened the S32DS, I got the following information:  S32 Design Studio for ARM ActivationId: 1A99-90A8-2F06-339B Evaluation Days: 14 Feature Version: 2.2 Feature Status: Evaluation (14 days) What procedures are required to extend the license validity period? Wishing you good business wishes!  回复： S32DS license ActivationId ActivationId: 1A99-90A8-2F06-339B Please help activate and extend the usage period, thank you. Re: S32DS license ActivationId Hi,  your S32DS license has been extended. Please activate S32DS again with your old code. 

S32K396 and FS26 REG_CORRUPT Dear All, I'm trying to get rid of the REG_CORRUPT' flag on the FS26 - the two snip pictures attached show a read of all the relevant registers. Immediately prior to the first 'AE' read command, I have just done a successful first kick of the watchdog to take the FS state machine out of INIT_FS such that the fail-safe register state is assessed for correctness, and you can see from the 0x28 answer that we are in debug mode with the REG_CORRUPT bit set. I am certain the watchdog kick was successful because I read FS_DIAG_SAFETY1 straight after the kick - returned value is 0x0103 - no error flags, just ABIST1_OK and LBIST_STATUS = OK. After the 0xAE command, I issue an 0xAF attempting to write 0x1800 to the register to clear the OTP_CORRUPT and REG_CORRUPT bits, and then I do a read of all 12 FS registers in order starting at register 0x41 (obviously the command is 0x82 when shifted). I have looked at the values returned from these registers and I can't see a consistency problem with the returned values (obviously taking into account the bits that we're not supposed to write to and bits that are held/reserved/0/1). You can see from a final read of FS_STATES at the end that REG_CORRUPT is still set. Sorry to ask such a direct question, but what am I missing? Kind Regards, Andrew Snip1.pngSnip1.png Snip2.pngSnip2.png    Re: S32K396 and FS26 REG_CORRUPT Dear Erika, Thanks for responding - I have checked that many times already, which is why I posted the complete state of the registers in the images of my original posting. Please let me know if you think there's an issue with how these are configured. As far as I can tell, the registers are correct (taking into account only the bits that are writable according to the datasheet). I assume the chip itself takes care that the read-only bits are in a valid state, and I assume the bits that are specified as '0' or 'reserved' are not writable. Is it possible that a write to one of those bits can cause the REG_CORRUPT bit to remain asserted? Kind Regards, Andrew Re: S32K396 and FS26 REG_CORRUPT Hello! For REG_CORRPUT bit, it will be asserted shown as below, meaning when FS registers are configured, a NOT register is must to be configured together With XOR rules. ErikaC_0-1785954434399.pngErikaC_0-1785954434399.png Please check if there are some register configuration did not follow the rules that cause this bit asserted ? Re: S32K396 and FS26 REG_CORRUPT Dear all, Responding to my own question in the hope this may help someone in future..... I'm not going to post excerpts from the datasheet because that would breach the NDA which I have signed in order to access this product data information. However, please look carefully at the bits that are defined as '0' or 'RESERVED' by the product information. The solution to my issue concerned the bit that is defined as 'RESERVED'. It is essential that software does write '1' to this location to prevent the REG_CORRUPT bit being set. I would suggest the datasheet is amended to clarify the necessary bit state and properly define what software must do - as is the case with other similar bits. Kind Regards, Andrew

How to Test TX PAUSE Frames with DPDK enetc4 VF Driver on i.MX95 / i.MX9x Series This post walks through end-to-end steps to enable and verify TX PAUSE frame (IEEE 802.3x flow control) generation on the i.MX95 / i.MX9x series using DPDK 25.11 with the enetc4 VF driver and a Spirent traffic generator. I also share an optional debug patch that lowers the PAUSE trigger threshold for quick lab reproduction and adds register readback prints to dmesg. --- Overview -------- On i.MX95 the ENETC4 Ethernet controller uses a PF/VF split: - The kernel PF driver (fsl_enetc4, Linux 6.18+) owns the MAC, PHY negotiation, and PAUSE configuration. - The DPDK VF driver (net/enetc, DPDK 25.11) owns the receive rings in the DPDK application. When the link partner negotiates PAUSE, the kernel PF configures the MAC and notifies the DPDK VF via a mailbox message. The VF then enables congestion signaling on its Rx rings. When incoming traffic fills those rings past the configured threshold, the hardware automatically emits PAUSE frames toward the sender. The trigger chain looks like this: High-rate ingress traffic fills VF Rx rings --> ICM fill level crosses PPAUONTR threshold --> MAC emits IEEE 802.3x PAUSE frame to link partner --> link partner pauses its transmitter --- Hardware Setup -------------- - i.MX95 EVK (or any i.MX9x board with ENETC4) - 10G SFP+ DAC cable or fiber between i.MX95 ENETC4 port and Spirent TestCenter port - Spirent TestCenter (or equivalent traffic generator with flow control capture) Software versions used in this guide: - Kernel: Linux 6.18+ with fsl_enetc4 PF driver - DPDK: 25.11 (net/enetc VF PMD) - ethtool: 6.x --- Step 1 — Enable PAUSE on the Kernel PF Interface ------------------------------------------------- The kernel PF interface (typically eth1 for ENETC4 port 1) must have TX PAUSE enabled before the link comes up so that phylink can negotiate it with the link partner. # Identify the kernel PF interface ip link show | grep -E "eth[0-9]" # Enable TX and RX PAUSE (autoneg lets the link partner also advertise PAUSE, it is off since we are using spirent) ethtool -A eth1 tx on rx on autoneg off # Bring the link up ip link set eth1 up # After link is up, verify PAUSE was negotiated ethtool -a eth1 Expected output: Pause parameters for eth1: Autonegotiate: off RX: on TX: on If TX shows "off" after link up, the link partner may not have advertised PAUSE capability. Try forcing it: ethtool -A eth1 tx on rx on autoneg off --- Step 2 — Verify ethtool Statistics Are Available ------------------------------------------------- Confirm that the ethtool stats interface is working before starting traffic: ethtool -S eth1 | grep -E "txpf|rxpf|pause" You should see counters like txpf_frames and rxpf_frames (both 0 at this point). If you see "no stats available", verify your kernel build includes the ethtool ops for enetc4. --- Step 3 — Bind the DPDK VF to igb_uio ----------------------------------- note bootargs: must have iommu_passthrough=1 # Load the VFIO driver modprobe igb_uio echo 1 > /sys/bus/pci/devices/0002\:00\:10.0/sriov_numvfs echo igb_uio > /sys/bus/pci/devices/0002\:00\:12.0/driver_override echo 0002:00:12.0 > /sys/bus/pci/drivers/fsl_enetc_vf/unbind echo 0002:00:12.0 > /sys/bus/pci/drivers/igb_uio/bind ip link set eth1 vf 0 trust on --- Step 4 — Allocate Hugepages ----------------------------- # 4 x 1 GB hugepages (recommended for 10G line-rate testing) echo 4 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages mount -t hugetlbfs none /dev/hugepages # Verify allocation grep HugePages /proc/meminfo # HugePages_Total: 4 # HugePages_Free: 4 --- Step 5 — Start testpmd ------------------------ For PAUSE testing the goal is to build up backpressure in the VF Rx rings so the ICM congestion threshold is crossed. Use rxonly mode with a small Rx descriptor count so the ring fills up quickly under load. testpmd \ -l 0-3 -n 4 \ -a 0002:00:12.0 \ -- \ --rxd=256 \ --txd=512 \ --nb-cores=2 \ --rxq=1 --txq=1 \ --forward-mode=rxonly \ --stats-period=5 Inside the testpmd prompt: testpmd> set fwd rxonly testpmd> start testpmd is now receiving and the DPDK VF Rx rings will fill under high-rate ingress traffic, generating the congestion signal that drives PAUSE frame emission. --- check stats via: ethtool --include-statistics -a eth1 Step 6 — Configure Spirent TestCenter --------------------------------------- Spirent port sending TO i.MX95 (ingress traffic): - Frame size: 64 bytes or smaller (smaller frames fill rings faster) - Rate: 100% line rate (10 Gbps) - Frame type: Ethernet II / IPv4 - Destination MAC: MAC address of the i.MX95 ENETC4 VF interface - Destination IP: IP address assigned to the i.MX95 interface Spirent port receiving FROM i.MX95 (PAUSE capture): - Port Properties → Flow Control → Enable IEEE 802.3x PAUSE - Enable Capture → Filter EtherType: 0x8808 - Results → Port Results → watch "Flow Control Frames Received" This counter increments every time a PAUSE frame arrives from i.MX95. - Optional: Results → Flow Analysis → check "Pause Duration (quanta)" Expected value: ~32767 (0x7FFF) Alternative capture without Spirent license: # On any PC with a tap on the wire tcpdump -i eth0 'ether proto 0x8808' -v # PAUSE frame: dst 01:80:c2:00:00:01, EtherType 0x8808, opcode 0x0001 --- Step 7 — Verify PAUSE Frames Are Being Sent --------------------------------------------- Start Spirent at 100% line rate, then on the i.MX95 host run: watch -n 1 'ethtool -S eth1 | grep -E "txpf|rxpf"' Expected output when PAUSE is active: txpf_frames: <-- TX PAUSE frames sent by i.MX95 On Spirent, "Flow Control Frames Received" should be incrementing at the same time. --- Optional — Debug Patch for Faster Lab Reproduction ---------------------------------------------------- I am attaching a patch file to this post. This useful for bring-up and debug — this is not required for production use. Adds dev_info() prints to enetc4_set_tx_pause() and enetc_set_congestion_mode() in the kernel driver. After link-up you will see in dmesg: fsl_enetc4 0000:00:00.0: enetc4_set_tx_pause: tx_pause=1 fsl_enetc4 0000:00:00.0: PPAUONTR = 0x00001000 fsl_enetc4 0000:00:00.0: PPAUOFFTR = 0x00000400 fsl_enetc4 0000:00:00.0: PM_CMD_CFG(0) = 0x000000c3 TX_EN=1 RX_EN=1 TXP=0 fsl_enetc4 0000:00:00.0: set_congestion_mode: enable=1 num_rx_rings=1 fsl_enetc4 0000:00:00.0: ring[0] readback rbmr=0x00000010 This confirms the kernel PF configured the MAC and set the RBMR congestion mode bit on the PF rings. The DPDK VF should receive the same setting via mailbox. also Lowers the PAUSE trigger threshold to PPAUONTR=4096 bytes so that PAUSE frames are generated at much lower traffic rates — useful for quick lab tests without needing a full 10G line-rate traffic generator. Also adds ICM register definitions (PRXBCR, PRXBCHWMR) so you can observe the ICM fill level via ethtool -S. After applying this patch, check ICM fill level during traffic: ethtool -S eth1 | grep -E "prxbcr|prxbchwmr" # prxbcr_bytes: # prxbchwmr_bytes: When prxbchwmr_bytes >= 4096, the threshold has been crossed and PAUSE should fire. --- Key Register Reference (ENETC4) --------------------------------- Note: ENETC4 register offsets start at 0x5000 for MAC/PM registers. This is different from ENETC v1 which uses 0x8000. Use ethtool -S for PM counters since PF BAR0 is IOMMU-protected on i.MX95. Register Offset Description PM_CMD_CFG(0) 0x5008 MAC config register (TXP = BIT 15) PM_TXPF(0) 0x5218 TX PAUSE frames sent (64-bit) PM_RXPF(0) 0x5118 RX PAUSE frames received (64-bit) PPAUONTR 0x108 ICM fill level threshold to START PAUSE PPAUOFFTR 0x10C ICM fill level threshold to STOP PAUSE PRXBCR 0x128 Current ICM RX fill level (live, read-only) PRXBCHWMR 0x12C ICM RX peak fill since boot (read-only) For VF Rx ring registers, VF BAR0 is accessible via devmem2: # Check RBMR of VF ring 0 — BIT 4 = CM (congestion mode) # Replace VF_BAR0 with your actual address (find via /sys/bus/pci/devices/.../resource0) devmem2 w # Expected when PAUSE is active: 0x00000010 --- Environment ----------- SoC: i.MX95, i.MX943 (i.MX9x series with ENETC4) Kernel: Linux 6.18+ (fsl_enetc4 PF driver) DPDK: 25.11 (net/enetc VF PMD) Tool: testpmd, ethtool 6.x, Spirent TestCenter Hope this helps. Happy to answer questions on the setup.

Lab 1 – Low Power is a Superpower

（TC358748）并行至CSI2视频桥接器出现故障 你好， 我正在做一个项目，需要将 FPGA 连接到我们定制的 i.MX8MP 板。我正在尝试修改 tc358746（并行 -> CSI2）驱动程序，以支持我们的 yocto lf-5.15.71 版本。 我希望视频管道（FPGA (YUV4:2:2) -> bridge (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0）目前以 YUV4:2:2 格式输出 1920x1080@30Hz，但我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 v4l-subdev1 不会出现在 v4l2 设备列表中。 请查看网桥的 media-ctl 输出和 dmesg 日志，非常感谢您能提供任何故障排除方面的见解。 root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath 你解决这个问题了吗？如果可以的话，能否分享一下您的TC358748 内核驱动代码和最新的设备树文件？因为我也遇到了同样的问题。非常感谢！ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你不能随意选择格式，这取决于你的桥接端设置。检查你的 TC358748 寄存器，看看你在那里设置的是什么格式，然后选择 imx8mp 端的正确格式。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好， 很抱歉回复晚了。我按照您建议的格式使用了数据，现在可以看到一些数据，但正如您从附件示例中看到的那样。它还不完美。我尝试了不同的 MEDIA_BUS_FMT 和 V4L2_PIX_FMT，也尝试了不同的频率（23.98、50、60 等）。 MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8。 V4L2_PIX_FMT_YUYV / UYVY / YUV422P。 但从 dmesg 日志中可以看到，有很多 CRC 错误。另外，我注意到从 media-ctl -p 中，除了桥接节点之外，其他节点都没有格式信息。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 或许你需要考虑一下格式。我检查了 CHNL_IMG_CTRL，它是 100000 字节的 YUV422_1P8P 格式，每个颜色元器件 8 位；单平面，YUV 交错打包字节。 https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c { 。姓名= "YUYV-16", .fourcc= V4L2_PIX_FMT_YUYV， 。深度= { 16 }, 。颜色= MXC_ISI_OUT_FMT_YUV422_1P8P， .memplanes= 1， .colplanes= 1， 。对齐= 3， .mbus_code= MEDIA_BUS_FMT_YUYV8_1X16， } 你应该从 ISI 选择此格式作为默认格式，并且也要检查你的桥接端。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 --> 这只是为了指示函数调用，在该行下面您可以看到启用 4 个数据通道和 1 个时钟通道的这些行。 tc358748 2-000e：CLW_CNTRL：0 0x140 tc358748 2-000e：D0W_CNTRL：0 0x144 tc358748 2-000e：D1W_CNTRL：0 0x148 tc358748 2-000e：D2W_CNTRL：0 0x14c tc358748 2-000e：D3W_CNTRL：0 0x150 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> 我们使用 148.5MHz。 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 --> hs-settle 值是根据以下公式设置的：（像素速率 * 每像素位数）/（通道数 * 2），即 148.5 pixclk * 16bpp / 2 * 4 通道 = 475.2 MBits/s所以 RX_HS_SETTLE 为 10。 此外，我们板上的数据通道也互换了。修改之后，当我使用 Gstreamer 或 v4l2-ctl 用上市，不用发布视频捕获时，会出现绿屏。 gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好@joanxie ， 是的，TC358748 的输入信号正常，我看到 TC358748 有信号输出。 要开始使用 GStreamer 进行捕获： gst-用上市，不用发布-1.0v4l2src 设备=/dev/video2 ！video/x-raw，宽度=1920，高度=1080！自动视频接收器 另一个问题是，当在 dts 中启用 ISI 节点时，系统会在几分钟后挂起。 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge 目前我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 您使用的是哪种 GStreamer 命令？您收到了什么消息？能否确认一下来自 TC358748 的信号是否完全正常？你检查过TC358748那边了吗？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查找他的注册表转储文件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 从imx8mp这边来看，我没有发现任何问题，连接设置正确。 [ 7.992257] mx8-img-md：已注册传感器子设备：tc358748 2-000e (1) [ 8.002921] mx8-img-md：创建链接 [mxc_isi.0]=> [mxc_isi.0.捕获] [ 8.018980] mx8-img-md：创建链接 [mxc-mipi-csi2.0] [[ ## completed ##]]=> [mxc_isi.0] [ 8.025519] mx8-img-md: 创建链接 [tc358748 2-000e] => [mxc-mipi-csi2.0] [ 8.032634] mxc-md 32c00000.总线:camera:mxc_md_create_links 实际上，isi0 是为 mipi csi0 设计的，在 mipi csi0 中添加 port@1 后，当前的 电路板支持包 应该会出现一些错误，所以你是否更改了任何 mipi 驱动程序？但由于您的设置正确，这应该不会影响您的数据捕获。您可以检查 FPGA 端，确认其是否设置了正确的时钟或发送了正确的数据，并仔细检查 TC358748 的寄存器。此外，请导出 MIPI CSI 和 ISI 寄存器，以检查是否存在任何错误位。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查收附件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 能否将日志文件和DTS文件发送给我？

Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 Hi NXP team, We are using LSDK-25.12_DEBIAN-13_LF-6.12.20 with FlexBuild to build a Debian-based product image for the i.MX8MP. To support our vulnerability assessment and conformity assessment under RED / EN 18031, we need to establish a repeatable process for identifying the software components and known vulnerabilities in the final shipping image. We have reviewed the FlexBuild 25.12 source tree and found that: SBOM-flexbuild.spdx.json contains only a single package entry describing the FlexBuild tool itself, rather than the contents of a built image. SCR.txt is an SDK-wide Software Content Register and does not represent the components actually installed in a specific target image. We could not identify any image-specific SBOM or CVE manifest generation mechanism in flex-builder. Based on these findings, could you please clarify the following? Does NXP currently provide an official or recommended method for generating an image-specific SBOM, such as a per-image SPDX document, from a FlexBuild Debian build? If this capability is planned, could you indicate the target release or expected availability? Does NXP currently provide or plan to provide Vigiles integration for the Debian Linux SDK / FlexBuild, equivalent to the meta-timesys workflow available for Yocto? If direct integration is not available, is manually creating and importing a CSV manifest, as described in the Vigiles FAQ, still the recommended approach for FlexBuild-based images? What are the official sources for security advisories, CVE applicability information, and security fixes for the following components included in this release? linux-imx lf-6.12.20-2.0.0 uboot-imx lf-6.12.20-2.0.0 imx-atf imx-optee-os NXP-provided firmware and binary packages, such as DDR, HDMI, VPU, and wireless firmware For example, should we rely on NXP security advisories, fixed-CVE lists in release notes, specific maintained Git branches, or another official source? What is the maintenance and security-update lifecycle for LSDK-25.12 and its associated lf-6.12.20 BSP components? In particular: For how long will security fixes be provided for this release? Which branches or repositories should be monitored for backported fixes? What upgrade cadence does NXP recommend for products requiring an ongoing vulnerability-management process? Our goal is to establish a repeatable and evidence-based SBOM and CVE assessment process for the actual shipping image. References to any official documentation, supported tools, or recommended procedures would be greatly appreciated. Thank you. Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 Hi @Chavira , Thank you for the clarification regarding the support status of the Debian distribution. We understand that the Debian integration itself is provided as a proof of concept. However, our remaining questions concern the underlying BSP components, which as far as we can tell are the same repositories and branches consumed by the Yocto BSP releases: - linux-imx (lf-6.12.20-2.0.0) - uboot-imx (lf-6.12.20-2.0.0) - imx-atf - imx-optee-os - NXP-provided firmware binaries (DDR, HDMI, VPU, wireless) Could you please confirm, independently of which build system or root filesystem is used: 1. Are security fixes for these components delivered through the lf-* release branches, and is the fixed-CVE information published in the Yocto BSP release notes the authoritative source for CVE remediation status of these components? 2. For the lf-6.12.20 generation specifically, which subsequent lf-* releases or branches should we monitor to obtain security fixes applicable to these components? 3. What is the maintenance duration for the lf-6.12.20 BSP component generation, and what upgrade cadence does NXP recommend for products that must maintain an ongoing vulnerability-management process? We are not asking NXP to support or validate our Debian-based image; we only need to identify the official sources of security-fix information for the NXP BSP components themselves, so that we can track and apply them in our own maintenance process. Thanks Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 Hi  @Leo_dev, Thank you for contacting NXP Support. Unfortunately, Debian is considered by NXP to be a proof of concept distribution and therefore does not receive the same level of support, validation, and long term maintenance as our Yocto based BSP releases. In fact, during boot, Debian displays a disclaimer indicating that the software is provided without any guarantee of functionality or support. As a result, issues encountered on Debian may not receive the same level of investigation or validation as those reproduced on a Yocto based image. For production development and fully supported use cases, we recommend using the Yocto BSP provided by NXP. All of our publicly available source code is hosted on GitHub and can be accessed through the following organization: https://github.com/nxp-imx Best regards, Chavira Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 Hi @Leo_dev, 1. Yes. Security fixes for NXP BSP components are typically delivered through the official lf- release branches. The i.MX Linux BSP release notes (RN00210) and associated manifests/change logs are the primary NXP references for tracking integrated fixes and CVE remediation status 2. For the LF6.12.20 generation, monitor subsequent BSP releases such as LF6.12.34_2.1.0, LF6.12.49_2.2.0, LF6.18.2_1.0.0, and newer releases, as security and maintenance fixes are carried forward into these branches. 3. For products requiring ongoing vulnerability management, NXP's recommended practice is to regularly track and evaluate newer BSP maintenance and quarterly releases to obtain security updates and bug fixes

CC-Link IEフィールド(1 Gbps)およびCC-Link IE TSN(クラスAおよびクラスB)サポート Layerscape LS1028A、i.MX 93、i.MX RT1170を用いて、 CC-Link IE Field(1 Gbps) および CC-Link IE TSN(クラスAおよびクラスB) のリモートデバイス通信を実装する計画です 確認いただけますか: これらのコントローラはCC-Link IE Field(1 GPS)およびCC-Link IE TSNをサポートしているのでしょうか? [[ ## completed ##]] Nxpはこれらの通信プロトコルに対してプロトコルスタックを提供しているのでしょうか? リファレンスデザインやサードパーティのソリューションは利用可能でしょうか? ご指導いただければ幸いです。ありがとう。 Re: CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support 以下の発表をご参照ください。 NXPがCC-LinkのIE TSNをリリース LS1028Aおよび i.MX RT1170はCC-Link IE TSNソリューションのサポートプラットフォームです。プロトコル・スタックのサポートのために、Port GmbHはインダストリアル通信フレームワーク(ICF)を提供しており、LS1028Aおよび i.MX RT1170プラットフォーム向けのCC-Link IE TSNマスターおよびリモートステーションスタックが含まれます。 よろしくお願いします。

CC-Link IE Field（1 Gbps）和 CC-Link IE TSN（A 类和 B 类）支持 我们计划使用 Layerscape LS1028A、i.MX 93 和 i.MX RT1170 实现CC-Link IE Field (1 Gbps)和CC-Link IE TSN (A 类和 B 类)远程设备通信。 请您确认一下： 这些控制器是否支持 CC-Link IE Field (1 Gps) 和 CC-Link IE TSN？ NXP是否为这些通信协议提供协议栈？ 是否有任何参考设计或第三方解决方案？ 非常感谢您的指导。谢谢。 Re: CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support 您可以参考以下公告： 恩智浦发布 CC-Link IE TSN LS1028A 和 i.MX RT1170 是 CC-Link IE TSN 解决方案支持的平台。对于协议栈支持，Port GmbH 提供工业通信框架 (ICF)，包括适用于 LS1028A 和 i.MX RT1170 平台的 CC-Link IE TSN 主站和远程站协议栈。 谢谢！

I want all the pin delays for the MIMX9352CVVXMAC. I want all the pin delays for the MIMX9352CVVXMAC. Re: 我想要MIMX9352CVVXMAC的所有的pindelay Please following the design guide in the IMX93HDG and refer to our EVK design. Re: 我想要MIMX9352CVVXMAC的所有的pindelay Are there any other versions? Re: 我想要MIMX9352CVVXMAC的所有的pindelay Sorry we do not have this excel for it. Re: 我想要MIMX9352CVVXMAC的所有的pindelay I want the Excel version Re: 我想要MIMX9352CVVXMAC的所有的pindelay Hi @ABC007 , Please following the IMX93HDG.pdf, I attach it to you. Hope can do help for you Wish you have a nice day Best Regards Rita

CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support We are planning to implement CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A And Class B) remote device communication using Layerscape LS1028A, i.MX 93, i.MX RT1170 Could you please confirm: Whether these controllers support CC-Link IE Field (1 Gps)and CC-Link IE TSN? Whether Nxp provides protocol stacks for these communication protocols? Whether any reference designs or third-party solutions are available? We would appreciate your guidance. Thank you. Re: CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support You may refer to the following announcement: NXP Unleashes CC-Link IE TSN LS1028A and i.MX RT1170 are supported platforms for CC-Link IE TSN solutions. For protocol stack support, Port GmbH provides an Industrial Communication Framework (ICF), including CC-Link IE TSN Master and Remote Station stacks for the LS1028A and i.MX RT1170 platforms. Thanks

Trouble with (TC358748) Parallel to CSI2 video bridge Hello, I am working on a project that requires interfacing an FPGA to our custom i.MX8MP board. I am trying to modify the tc358746 (Parallel -> CSI2) driver to support for our yocto lf-5.15.71 version. I want the video pipeline (FPGA (YUV4:2:2) -> bridge (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0) to output 1920x1080@30Hz with YUV4:2:2 format for now but I am unable to capture any frames using Gstreamer or v4l2-ctl. The v4l-subdev1 won't show up in the v4l2 device list Please find the media-ctl output and the dmesg log for the bridge, Any insights on troubleshooting the issue is greatly appreciated. root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath  Were you able to solve the problem? if possible, could you please share your TC358748 kernel driver code and latest devicetree file? Because I am having trouble with the same issue. Many thanks Re: Trouble with (TC358748) Parallel to CSI2 video bridge you couldn't choose any format you want, depends on what your bridge side, check your TC358748 register, what format did you set there, then choose the correct format of imx8mp side Re: Trouble with (TC358748) Parallel to CSI2 video bridge Hello, Sorry for the delayed response. I used the format as you suggested and now I see some data but as you can see from the attached sample. It is still not perfect. I tried different MEDIA_BUS_FMT and V4L2_PIX_FMT's and also tried different frequencies (23.98, 50, 60, etc). MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8. V4L2_PIX_FMT_YUYV / UYVY / YUV422P. But as you can see from the dmesg log there are a lot of CRC error's. Also I notice that from media-ctl -p other than the bridge node none of them have format information. Re: Trouble with (TC358748) Parallel to CSI2 video bridge maybe you need consider the format, I checked the CHNL_IMG_CTRL, which is 100000b - YUV422_1P8P with 8-bits per color component; 1-plane, YUV interleaved packed bytes https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c { .name = "YUYV-16", .fourcc = V4L2_PIX_FMT_YUYV, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_YUV422_1P8P, .memplanes = 1, .colplanes = 1, .align = 3, .mbus_code = MEDIA_BUS_FMT_YUYV8_1X16, } you should choose this format from ISI as default, and check your bridge side too Re: Trouble with (TC358748) Parallel to CSI2 video bridge checked your dts file settings 4 data lane for TC358748, but the logfile shows only 1 lane([ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1), pls double check it --> That is just to indicate the function call, below that line you can see these line which enables 4 data lanes and 1 clock lane. tc358748 2-000e: CLW_CNTRL: 0 0x140 tc358748 2-000e: D0W_CNTRL: 0 0x144 tc358748 2-000e: D1W_CNTRL: 0 0x148 tc358748 2-000e: D2W_CNTRL: 0 0x14c tc358748 2-000e: D3W_CNTRL: 0 0x150 in your csi&isi dump.txt, [ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 74250000MHz)) but in the gst-lauch-1.0.txt, [ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> We are using 148.5MHz. so what clock you set indeed? I checked your dts, you set 74.25M pixel clock, I suggest that you can measure the clock and set the hs-settle and clk-settle --> hs-settle value was set based on this (pixel rate * bits per pixel) / (number of lanes * 2) which is 148.5 pixclk *16bpp / 2 * 4 lane = 475.2MBits/s so RX_HS_SETTLE is 10. Also data lanes on our board were interchanged. So after this modification now I am getting a green screen when I launch video capture using Gstreamer or v4l2-ctl gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge checked your dts file settings 4 data lane for TC358748, but the logfile shows only 1 lane([ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1), pls double check it in your csi&isi dump.txt, [ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 74250000MHz)) but in the gst-lauch-1.0.txt, [ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) so what clock you set indeed? I checked your dts, you set 74.25M pixel clock, I suggest that you can measure the clock and set the hs-settle and clk-settle Re: Trouble with (TC358748) Parallel to CSI2 video bridge Hello @joanxie, Yes the input signals to TC358748 is okay and I see signals coming out of TC358748. To start capture using Gstreamer: gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-raw,width=1920,height=1080 ! autovideosink Another issue is when the ISI node is enabled in the dts the system hangs after few minutes. 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge for now but I am unable to capture any frames using Gstreamer or v4l2-ctl. > what kind gstreamer command do you use and what message do you get? could you confirm if your signal from TC358748 is total fine? did you check TC358748 side？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge Please find he register dump. Re: Trouble with (TC358748) Parallel to CSI2 video bridge from imx8mp side, I don't find any issue,  the connection set up correctly [ 7.992257] mx8-img-md: Registered sensor subdevice: tc358748 2-000e (1) [ 8.002921] mx8-img-md: created link [mxc_isi.0] => [mxc_isi.0.capture] [ 8.018980] mx8-img-md: created link [mxc-mipi-csi2.0] => [mxc_isi.0] [ 8.025519] mx8-img-md: created link [tc358748 2-000e] => [mxc-mipi-csi2.0] [ 8.032634] mxc-md 32c00000.bus:camera: mxc_md_create_links in fact isi0 is for mipi csi0, after you add port@1 in the mipi csi0, you should get some errors in the current bsp, so do you change any mipi driver? but since you set up correctly, this shouldn't affect your capture, you can check the FPGA side, to check if they set the correct clock or send the correct data, to double review the registers of TC358748, also pls dump the mipi csi and ISI registers to check any error bits Re: Trouble with (TC358748) Parallel to CSI2 video bridge Please find the attached files. Re: Trouble with (TC358748) Parallel to CSI2 video bridge could you send the logfile and dts file to me

(TC358748) CSI2ビデオブリッジの並列接続に問題があります こんにちは、 私は、FPGAを当社独自のi.MX8MPボードに接続する必要があるプロジェクトに取り組んでいます。私はtc358746(Parallel -> CSI2)ドライバをYocto lf-5.15.71バージョンにサポートしようとしています。 今のところ、ビデオパイプライン (FPGA (YUV4:2:2) -> ブリッジ (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0) から YUV4:2:2 フォーマットで 1920x1080@30Hz を出力したいのですが、Gstreamer や v4l2-ctl を使用してフレームをキャプチャすることができません。 v4l-subdev1はv4l2デバイスリストに表示されません ブリッジのmedia-ctl出力とdmesgログを探してください。問題のトラブルシューティングに関するご意見をいただけると大変ありがたいです。 root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: Sink <- "mxc_isi.0":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath 問題は解決できましたか？可能であれば、TC358748カーネルドライバーコードと最新のDevicetreeファイルを共有していただけませんか?私も同じ問題で困っています。どうもありがとうございます Re: Trouble with (TC358748) Parallel to CSI2 video bridge 任意のフォーマットを選択できるわけではありません。ブリッジ側の設定によります。TC358748レジスタを確認し、そこに設定したフォーマットを確認してから、imx8mp側の正しいフォーマットを選択してください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge こんにちは、 返信が遅くなり申し訳ありません。ご提案のフォーマットを使いましたが、添付のサンプルからもCANが見えるように、いくつかのデータが見えます。まだ完璧ではない。MEDIA_BUS_FMTとV4L2_PIX_FMTをいろいろ試してみたり、周波数もいろいろ試してみたりしました（23.98、50、60など）。 MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8。 V4L2_PIX_FMT_YUYV / UYVY / YUV422P。 しかし、dmesgログからもわかるように、CRCエラーが多くあります。また、media-ctl -pからはブリッジノード以外にフォーマット情報が一切表示されていないことに気づきました。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge フォーマットを考慮する必要があるかもしれません。CHNL_IMG_CTRLを確認したところ、100000バイトのYUV422_1P8Pで、カラーコンポーネントごとに8ビット、1プレーン、YUVインターリーブパックバイトでした。 https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c ヤージュ 。名前= "YUYV-16", .fourcc= V4L2_PIX_FMT_YUYV、 。深さ= { 16 }、 。色= MXC_ISI_OUT_FMT_YUV422_1P8P、 .memplanes= 1、 .colplanes= 1、 .align= 3、 .mbus_code= MEDIA_BUS_FMT_YUYV8_1X16、 } ISI のこのフォーマットをデフォルトとして選択し、ブリッジ側も確認してください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge TC358748のdtsファイル設定で4データレーンを確認しましたが、ログファイルには1レーンしか表示されていません（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1）。もう一度確認してください。 --> これは関数呼び出しを示すためのもので、その下のラインは4つのデータレーンと1つのクロックレーンを有効にしています。 tc358748 2-000e: CLW_CNTRL: 0 0x140 tc358748 2-000e: D0W_CNTRL: 0 0x144 tc358748 2-000e: D1W_CNTRL: 0 0x148 tc358748 2-000e: D2W_CNTRL: 0 0x14c tc358748 2-000e: D3W_CNTRL: 0 0x150 csi&isi dump.txt では、[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(ハードコード=>: 74250000MHz)) しかし、gst-lauch-1.0.txt では、[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> 148.5MHzを使用しています。 SO、実際にどの時計をセットしたのですか?DTSを確認しましたが、74.25Mピクセルクロックを設定しています。クロックを測定してhs-settleとclk-settleを設定することをお勧めします --> hs-settle 値は、(ピクセルレート * ピクセルあたりのビット数) / (レーン数 * 2) に基づいて設定され、148.5 pixclk * 16bpp / 2 * 4 レーン = 475.2Mbits/s となります。SO RX_HS_SETTLEは10です。 また、基板上のデータレーンも入れ替わっていました。SO、この改造の後、Gstreamerやv4l2-ctlでビデオキャプチャを起動すると緑色の画面が出ています [[ ## completed ##]] gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge TC358748のdtsファイル設定で4データレーンを確認しましたが、ログファイルには1レーンしか表示されていません（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1）。もう一度確認してください。 csi&isi dump.txt では、[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(ハードコード=>: 74250000MHz)) しかし、gst-lauch-1.0.txt では、[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) SO、実際にどの時計をセットしたのですか?DTSを確認しましたが、74.25Mピクセルクロックを設定しています。クロックを測定してhs-settleとclk-settleを設定することをお勧めします Re: Trouble with (TC358748) Parallel to CSI2 video bridge こんにちは、 @joanxie さん。 はい、TC358748への入力信号は正常で、TC358748から信号が出力されているのも確認できます。 Gstreamerを使用してキャプチャを開始するには： gst-launch-1.0v4l2src デバイス=/dev/video2 !video/x-raw、幅=1920、高さ=1080 !自動ビデオシンク もう一つの問題は、dtsでISIノードを有効にすると、数分後にシステムがハングアップすることです。 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge 今のところは、Gstreamerやv4l2-ctlを使ってフレームをキャプチャすることができません。 >どのgstreamerコマンドを使っていて、どんなメッセージが出ますか?TC358748からの信号が完全に正常かどうか確認してもらえますか?TC358748側を確認しましたか？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 登録ダンプファイルはこちらです。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge imx8mp側から見ると、問題は見当たらず、接続設定も正しく行われています。 [ 7.992257 ] mx8-img-md: 登録センサーサブデバイス: tc358748 2-000e (1) [ 8.002921] mx8-img-md: 作成されたリンク [mxc_isi.0]=> [mxc_isi.0.capture] [ 8.018980] mx8-img-md: リンク [mxc-mipi-csi2.0] を作成しました=> [mxc_isi.0] [ 8.025519] mx8-img-md: リンク [tc358748 2-000e] => [mxc-mipi-csi2.0] を作成しました [ 8.032634] mxc-md 32c00000.bus:camera:mxc_md_create_links 実際、ISI0はMIPI CSI0用で、MIPI CSI0に port@1 を加えると現在のBSPでエラーが出るはずです。では、MIPIドライバーは変更していますか?しかし正しく設定しているなら、キャプチャには影響しないはずです。FPGA側を確認して、正しいクロック設定やデータ送信をしているか確認し、TC358748のレジスタを再確認し、またmipi csiやISIレジスタもダンプしてエラービットをチェックしてください Re: Trouble with (TC358748) Parallel to CSI2 video bridge 添付ファイルをご確認ください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge ログファイルとDTSファイルを送ってもらえますか?

FlexBuild LSDK-25.12のイメージ固有のSBOMおよびCVE評価サポート こんにちは、NXPチームの皆様、 FlexBuildと組み合わせたLSDK-25.12_DEBIAN-13_LF-6.12.20を使って、i.MX8MP用のDebianベースの製品イメージを構築しています。RED / EN 18031に基づく脆弱性評価および適合性評価をサポートするために、最終出荷画像におけるソフトウェアコンポーネントおよび既知の脆弱性を特定するための繰り返し可能なプロセスを確立する必要があります。 FlexBuild 25.12のソースツリーを調査した結果、以下のことが判明しました。 SBOM-flexbuild.spdx.jsonは、ビルドイメージの内容ではなく、FlexBuildツール自体を説明するパッケージエントリが1つだけ含まれます。 SCR.txt SDK全体のソフトウェアコンテンツレジスタであり、特定のターゲットイメージに実際にインストールされたコンポーネントを表すものではありません。 フレックスビルダーでは、画像固有のSBOMやCVEマニフェスト生成メカニズムを特定できませんでした。 これらの調査結果を踏まえ、以下の点を明確にしていただけますか? NXPは現在、FlexBuild Debianビルドから画像ごとのSPDX文書のような画像固有のSBOMを生成する公式または推奨の方法を提供していますか? もしこの能力が計画されている場合、目標のリリースや予想される稼働状況を教えていただけますか? NXPは現在、Debian Linux SDKs / FlexBuild向けにVigiles統合を提供している、または提供する予定がありますか?これはYoctoで利用可能なmeta-timesysワークフローに相当します。 直接統合が利用できない場合、Vigiles FAQに記載されているように、CSVマニフェストを手動で作成してインポートする方法は、FlexBuildベースのイメージに対して依然として推奨されるアプローチですか？ このリリースに含まれる以下のコンポーネントのセキュリティアドバイザリー、CVE適用情報、セキュリティ修正の公式情報源は何ですか? Linux-IMX LF-6.12.20-2.0.0 uboot-imx lf-6.12.20-2.0.0 imx-atf imx-optee-os NXPが提供するファームウェアおよびDDR、HDMI、VPU、ワイヤレスファームウェアなどのバイナリパッケージ 例えば、NXPのセキュリティアドバイザリー、リリースノートの修正済みCVEリスト、特定の維持管理されているGitブランチ、あるいは他の公式ソースに頼るべきでしょうか? LSDK-25.12および関連するlf-6.12.20 BSPコンポーネントの保守およびセキュリティ更新のライフサイクルはどのようなものですか? 特に： このリリースのセキュリティ修正はどのくらいの期間提供されますか? バックポートされた修正を監視するために、どのブランチまたはリポジトリを監視すべきでしょうか？ NXPは、継続的な脆弱性マネジメントプロセスを必要とする製品に対してどのようなアップグレード頻度を推奨していますか? 私たちの目標は、実際の出荷イメージに対して、再現性があり、証拠に基づいたSBOMおよびCVE評価プロセスを確立することです。公式ドキュメント、サポートツール、推奨手順の参考文献があればぜひ教えていただけると助かります。 よろしくお願いします。 Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Chavira さん。 Debianディストリビューションのサポート状況についてのご説明ありがとうございます。 Debianとの統合自体は、概念実証として提供されていることを理解しています。しかし、残された疑問は基盤となるBSPコンポーネントに関するものであり、私たちが知る限り、Yocto BSPリリースで消費されているリポジトリやブランチと同じです。 - Linux-IMX(LF-6.12.20-2.0.0) - uboot-IMX(LF-6.12.20-2.0.0) - IMX-ATF - IMX-optee-OS - NXP提供のファームウェアバイナリ(DDR、HDMI、VPU、ワイヤレス) どのビルドシステムやルートファイルシステムが使われているかに関わらず、確認していただけますか: 1. これらのコンポーネントのセキュリティ修正はlf-*リリースブランチを通じて提供されるのか、またYocto BSPリリースノートに公開されている修正CVE情報は、これらのコンポーネントのCVE修復状況の権威ある情報源なのか? 2. lf-6.12.20世代に関して、これらのコンポーネントに適用されるセキュリティ修正を得るために、どの後続のlf-*リリースやブランチを監視すべきか? 3. lf-6.12.20 BSPコンポーネント生成のメンテナンス期間はどのくらいで、継続的な脆弱性マネジメントプロセスを維持する必要がある製品に対してNXPはどのアップグレードの頻度を推奨していますか? [[ ## completed ##]] 私たちはNXPにDebianベースのイメージのサポートや検証を求めているわけではありません。NXP BSPコンポーネント自体の公式なセキュリティ修正情報源を特定するSO、それをCAN追跡・適用できます。 よろしくお願いします。 Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Leo_dev さん。 NXPサポートまでご連絡いただきありがとうございます。 残念ながら、DebianはNXPによって概念実証ディストリビューションと見なされており、YoctoベースのBSPリリースと同じレベルのサポート、検証、長期的なメンテナンスを受けていません。 実際、起動時には、ソフトウェアが機能やサポートの保証なしに提供されていることを示す免責事項が表示されます。その結果、Debian上で直面する問題は、Yoctoベースのイメージで再現される問題と同じレベルの調査や検証を受けられない場合があります。 本番開発や完全にサポートされたユースケースには、NXPが提供するYocto BSPの使用を推奨します。 私たちの公開されているすべてのソースコードはGitHub上でホストされており、以下の組織を通じてアクセスCANです。 https://github.com/nxp-imx よろしくお願いします、 チャビラ Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 こんにちは、 @Leo_dev さん。 1. はい。NXP BSPコンポーネントのセキュリティ修正は通常、公式のlf-releaseブランチを通じて提供されます。i.MX Linux BSPリリースノート(RN00210)および関連するマニフェスト/変更ログは、統合修正やCVE修復状況の追跡における主要なNXP参照資料です 2. LF6.12.20世代については、LF6.12.34_2.1.0などの後続のBSPリリースを監視します。LF6.12.49_2.2.0、LF6.18.2_1.0.0、およびそれ以降のリリースでは、セキュリティや保守の修正がこれらのブランチに引き継がれます。 3.継続的な脆弱性管理が必要な製品に対して、NXPの推奨方法は、新しいBSPのメンテナンスや四半期ごとのリリースを定期的に追跡・評価し、セキュリティアップデートやバグ修正を取得することです

MIMX9352CVVXMACのすべてのピン遅延値が必要です。 MIMX9352CVVXMACのすべてのピン遅延値が必要です。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay IMX93HDGのデザインガイドに従い 、当社のEVK設計を参照してください。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 他のバージョンはありますか？ Re: 我想要MIMX9352CVVXMAC的所有的pindelay 申し訳ありませんが、このExcelファイルはご用意しておりません。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay Excel版が欲しいです Re: 我想要MIMX9352CVVXMAC的所有的pindelay こんにちは、 @ABC007 さん。 IMX93HDG.pdf に従ってください。添付しておきます。 HopeがCANあなたの助けになります 素敵な一日をお過ごしください よろしくお願いいたします。 リタ

FlexBuild LSDK-25.12 的图像特定 SBOM 和 常见漏洞与后门 评估支持 您好，NXP团队： 我们使用 LSDK-25.12_DEBIAN-13_LF-6.12.20 和 FlexBuild 为 i.MX8MP 版本基于 Debian 的产品映像。为了支持我们根据 RED / EN 18031 进行的漏洞评估和一致性评估，我们需要建立一个可重复的流程来识别最终交付映像中的软件组件和已知漏洞。 我们审查了 FlexBuild 25.12 的源代码树，发现： SBOM-flex版本.spdx.json 仅包含一个描述 Flex版本 工具本身的代码包，软件包条目，而不是已构建映像的内容。 SCR.txt 是 SDK 范围内的软件内容注册表，并不代表实际安装在特定目标映像中的元器件。 我们在 flex-builder 中没有发现任何针对特定图像的 SBOM 或 常见漏洞与后门 清单生成机制。 基于以上发现，请您澄清以下问题？ NXP 目前是否提供官方或推荐的方法，从 FlexBuild Debian 版本中生成特定于镜像的 SBOM（例如每个镜像的 SPDX 文档）？ 如果这项功能已列入计划，能否告知目标版本或预计可用时间？ NXP 目前是否提供或计划为 Debian Linux SDK / FlexBuild 提供 Vigiles 集成，类似于 Yocto 可用的 meta-timesys 工作流？ 如果无法直接集成，那么对于基于 FlexBuild 的镜像，手动创建和导入 CSV 清单（如 Vigiles FAQ 中所述）是否仍然是推荐的方法？ 此版本中包含的以下元器件的网络安全公告、常见漏洞与后门 适用性信息和网络安全修复的官方来源是什么？ [[ ## completed ##]] linux-imx lf-6.12.20-2.0.0 uboot-imx lf-6.12.20-2.0.0 imx-atf imx-optee-os NXP提供的固件和二进制软件包，例如DDR、HDMI、VPU和无线固件。 例如，我们应该依赖 NXP 网络安全公告、版本说明中的已修复 常见漏洞与后门 列表、特定维护的 Git 分支，还是其他官方来源？ LSDK-25.12 及其相关的 lf-6.12.20 电路板支持包。 元器件的维护和网络安全更新生命周期是什么？ [[ ## completed ##]] 尤其： 此版本将提供多长时间的网络安全修复？ 应该监测哪些分支或代码库以获取向后移植的修复程序？ NXP 建议对需要持续漏洞管理流程的产品采用怎样的升级节奏？ 我们的目标是为实际运输图像建立可重复且基于证据的 SBOM 和常见漏洞与后门 评估流程。如能提供任何官方文档、支持的工具或推荐流程的参考资料，我们将不胜感激。 谢谢！ Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 嗨@Chavira ， 感谢您澄清有关 Debian 发行版支持状态的问题。 我们了解到，Debian 集成本身只是作为概念验证而提供的。然而，我们剩下的问题与底层 电路板支持包。 元器件有关，据我们所知，这些元器件与 Yocto 电路板支持包。 版本所使用的存储库和分支相同： - linux-imx (lf-6.12.20-2.0.0) - uboot-imx (lf-6.12.20-2.0.0) - imx-atf - imx-optee-os - NXP提供的固件二进制文件（DDR、HDMI、VPU、无线） 请您确认一下，无论使用哪种版本系统或根文件系统： 1. 这些元器件的网络安全修复是否通过 lf-* 版本分支提供？Yocto 电路板支持包。版本说明中发布的已修复 常见漏洞与后门 信息是否是这些元器件 常见漏洞与后门 修复状态的权威来源？ 2. 对于 lf-6.12.20 版本，我们应该监测哪些后续的 lf-* 版本或分支，以获取适用于这些元器件的网络安全修复程序？ [[ ## completed ##]] 3. lf-6.12.20 电路板支持包元器件的维护周期是多久？NXP 建议对必须持续进行漏洞管理的产品采用怎样的升级节奏？ 我们并没有要求 NXP 支持或验证我们基于 Debian 的镜像；我们只需要确定 NXP 电路板支持包的元器件本身的网络安全修复信息的官方来源，以便我们可以在自己的维护过程中跟踪和应用这些修复。 谢谢！ Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 嗨@Leo_dev ， 感谢您联系恩智浦技术支持。 遗憾的是，NXP 将 Debian 视为概念验证发行版，因此它无法获得与我们基于 Yocto 的电路板支持包版本相同的支持、验证和长期维护。 事实上，在启动过程中，Debian 会显示一条免责声明，表明该软件不提供任何功能或支持保证。因此，在 Debian 上遇到的问题可能无法得到与在基于 Yocto 的镜像上重现的问题相同的调查或验证。 对于生产开发和完全支持的用例，我们建议使用 NXP 提供的 Yocto 电路板支持包。 我们所有公开可用的源代码都托管在 GitHub 上，可通过以下组织访问： https://github.com/nxp-imx 此致， 查维拉 Re: Image-specific SBOM and CVE assessment support for FlexBuild LSDK-25.12 嗨@Leo_dev ， 1. 是的。NXP BSP 组件的安全修复程序通常通过官方 lf- 版本分支提供。i.MX Linux BSP 版本说明 (RN00210) 及相关清单/变更日志是 NXP 用于跟踪集成修复和 CVE 修复状态的主要参考资料。 2. 对于 LF6.12.20 版本，请监测后续的 电路板支持包 版本，例如 LF6.12.34_2.1.0。LF6.12.49_2.2.0、LF6.18.2_1.0.0 及更新版本，因为安全性和维护性修复程序已传递到这些分支中。 3.对于需要持续进行漏洞管理的产品，恩智浦建议定期跟踪和评估最新的BSP维护和季度版本，以获取安全更新和漏洞修复。

我想要MIMX9352CVVXMAC的所有的pindelay 我想要MIMX9352CVVXMAC的所有的pindelay Re: 我想要MIMX9352CVVXMAC的所有的pindelay 请按照IMX93HDG 中的设计指南并参考我们的 EVK 设计。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 还有其他版本吗？ Re: 我想要MIMX9352CVVXMAC的所有的pindelay 抱歉，我们没有这个Excel表格。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 我想要Excel版本 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 你好@ABC007 ， 请参考 IMX93HDG.pdf 文件，我把它附在你身上。 希望对您有所帮助。 祝你今天过得愉快 顺祝商祺！ Rita