PCA9617波形 该电路与 PCA9600 配合良好，但为了降低成本，我修改了电路板以使用 PCA9617 并检查了波形。 观察时钟波形，没有特别的失真， 所以看起来没有问题，但是在数据波形输出低电平的时候， 我观察到在时钟下降沿被拉高的波形。 我想知道这是否是由于时钟和数据之间的串扰造成的（安装 PCA9600DPZ 时没有问题）， 或者是修改电路板图案（图案切割/电缆焊接）的效果？ 我将非常感激您的意见。

IMX8MM + sn65dsi83 + yocto scarthgap = devicetree problem Hello, back to 4.19 warrior I have used this configuration of sn65dsi84 DSI to LVDS bridge in device tree: &i2c1 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c1>; status = "okay"; dsi_lvds_bridge: sn65dsi84@2c { compatible = "ti,sn65dsi83"; reg = <0x2c>; ti,dsi-lanes = <4>; ti,lvds-format = <2>; ti,lvds-channels = <1>; ti,lvds-bpp = <24>; ti,width-mm = <210>; ti,height-mm = <157>; ti,burst-mode; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lvds>; enable-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>; status = "okay"; display-timings { lvds { clock-frequency = <65000000>; hactive = <1024>; vactive = <768>; /* */ hfront-porch = <24>; hsync-len = <136>; hback-porch = <160>; /* */ vfront-porch = <3>; vsync-len = <6>; vback-porch = <29>; /* */ vsync-active = <0>; hsync-active = <0>; de-active = <1>; pixelclk-active = <1>; }; }; port { lvds_from_dsi: endpoint { remote-endpoint = <&dsi_to_lvds>; }; }; }; }; &mipi_dsi { status = "okay"; port@1 { dsi_to_lvds: endpoint { remote-endpoint = <&lvds_from_dsi>; }; }; }; &iomuxc { pinctrl_i2c1: i2c1grp { fsl,pins = < MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3 MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3 >; }; pinctrl_lvds: lvdsgrp { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x16 >; }; }; However, when I ported the device tree to yocto scarthgap (Linux 6.6) this definition is not working anymore: [ 1.290572] imx-drm display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops) [ 1.298317] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200 [ 1.305343] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e10000 to encoder DSI-34: -19 [ 1.316955] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi [ 1.325231] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -19 [ 1.332903] imx-drm display-subsystem: bound 32e10000.mipi_dsi (ops imx_sec_dsim_ops) [ 1.341048] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0 [ 1.348908] imx-drm display-subsystem: [drm] Cannot find any crtc or sizes Could anyone point me an example device tree setup for sn65dsi8(3/4/5) + imx8mm + Linux 6.6 Thanks in advance. Re: IMX8MM + sn65dsi83 + yocto scarthgap = devicetree problem Thank you for your solution! Best Regards, Pavel Re: IMX8MM + sn65dsi83 + yocto scarthgap = devicetree problem Hello @pavelko  I updated the post, please check it, also, thank you for the feedback! Best regards, Salas. Re: IMX8MM + sn65dsi83 + yocto scarthgap = devicetree problem Thank you for the answer. To accept it as an answer "port 1" in sn65dsi declaration shall be renamed to "port 2", as port 1 is used foe 2nd DSI output channel. and correct reg =<1> to reg=<2> accordingly. Thank you! Re: IMX8MM + sn65dsi83 + yocto scarthgap = devicetree problem Hello @pavelko  I hope you are doing very well. You can take a look into the sn65dsi83 binding in the linux kernel. Also, you can try with this modified device tree: &i2c1 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c1>; status = "okay"; dsi_lvds_bridge: sn65dsi84@2c { compatible = "ti,sn65dsi83"; reg = <0x2c>; enable-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH>; status = "okay"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; bridge_in: endpoint { remote-endpoint = <&mipi_dsi_out>; data-lanes = <1 2 3 4>; }; }; port@2 { reg = <2>; bridge_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; }; }; &mipi_dsi { status = "okay"; port@1 { reg = <1>; mipi_dsi_out: endpoint { remote-endpoint = <&bridge_in>; data-lanes = <1 2 3 4>; }; }; }; panel_lvds: panel { compatible = "panel-lvds"; data-mapping = "jeida-24"; width-mm = <210>; height-mm = <157>; panel-timing { clock-frequency = <65000000>; hactive = <1024>; vactive = <768>; hfront-porch = <24>; hsync-len = <136>; hback-porch = <160>; vfront-porch = <3>; vsync-len = <6>; vback-porch = <29>; hsync-active = <0>; vsync-active = <0>; de-active = <1>; pixelclk-active = <1>; }; port { panel_in: endpoint { remote-endpoint = <&bridge_out>; }; }; }; It should align with the 6.6 kernel version. Best regards, Salas.

How to create a U-Boot image for an i.MX8M Plus that includes an M7 processor image? I'm working on a project that is uses an i.MX8M Plus SOC on a Variscite SOM.  It uses the Android 14 release that comes mostly from NXP.  Our project also has a FreeRTOS app that runs on the M7 auxiliary processor in the SOC which communicates with our Android app. We need the FreeRTOS app to be started by U-Boot so that it is running when the Android OS comes up.  At this stage of development starting that M7 FreeRTOS app from U-Boot is a manual process executed by the developer when booting the system. When we follow the manual process, everything works fine, but that manual process is tedious and error prone. From what I've read on this link: i-MX8-Boot-process-and-creating-a-bootable-image it seems like that manual process we follow to boot the M7 processor from U-boot could "just happen" if I could figure out how to add the M7 image to our U-Boot image.  From that link it seems like the command to use is something like this: imx-mkimage -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 m4_0_image.bin 0 0x34FE0000 -p4 -m4 m4_1_image.bin 1 0x38FE0000 -out flash.bin‍‍ ... maybe it should be without the "ahab" container, and be for different "-soc"  and "-rev" but maybe the "-m4" stuff is relevant but maybe the option should be "-m7". However ... What the Android build system ACTUALLY does is quite a bit different.  It does use code equivalent to the code in this repository, but instead of building the "imx-mkimage" program, I see that it builds and runs something called "mkimage_imx8" in the "iMX8M" directory which seems to be tailored to the i.MX8M family.  When I read through the code for "mkimage_imx8" it seems like it doesn't support adding a container for M7 code. That brings me back to the question in the subject.  Can it be done, and if so how? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How to create a U-Boot image for an i.MX8M Plus that includes an M7 processor image? Not the answer I was hoping for, but it does explain everything I'm seeing. Post COVID we are all experts at plan-B. I'm guessing it will probably something similar to what you describe with the u-boot environment. Thanks for the definitive response. Rob Re: How to create a U-Boot image for an i.MX8M Plus that includes an M7 processor image? HI @rob_mclean! Thank you for contacting NXP Support! Unfortunately in iMX8MP SOC is not possible to compile a u-boot image with M core image embedded, It is possible in iMX8 but no in iMX8M. You can consult the chapter 4.5.13 of this guide. You can update your u-boot environment and create a command to run the M core before the Linux Image to avoid errors doing manually every time. Best Regards! Chavira

S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi, I received our customized board and used BSP41 to boot it up. The board has some modifications to GMAC and PFE configurations, which are set as follows: SGMII, SGMII, SGMII, and RGMII, respectively. For the SERDES configuration, I used mode 1 for SERDES0 and mode 3 for SERDES1. The hwconfig was set to: serdes0:mode=pcie&xpcs0,clock=ext,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=ext,fmhz=125;xpcs1_0:speed=1G;xpcs1_1:speed=1G. In this setup: GMAC and PFE2 do not have external PHYs. PFE0 and PFE1 are connected to external PHYs. I made the corresponding changes in TF-A device tree. However, when U-Boot initializes, I noticed that both XPCS0 and XPCS1 are in reset, init failed. I’ve attached a screenshot for reference. Could you please share any insights or suggestions on this issue?  The PFE0 and PFE1 external PHY has not power enabled yet, so the PHY was not found error is expected. Thanks, XD Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to configure XPCS1_0 Failed to update XPCS0 for SerDes1 Failed to configure XPCS1_1 Failed to update XPCS1 for SerDes1 s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed pci_s32cc pcie@40400000: Failed to get PHY 'serdes_lane0' In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: Revision Unknown: (0x496) Net: s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed eth_eqos ethernet@4033c000: Failed to get 'gmac_xpcs' PHY eth_eqos ethernet@4033c000: XPCS init failed. Check hwconfig. (err=-19) Enable protocol@14 failed clk_enable(clk_rx) failed: -71 eth_eqos ethernet@4033c000: Failed to start clocks. Check XPCS configuration (err=-71) eth0: ethernet@4033c000 Found PFE version 0x0101 (S32G3) pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 block was initialized pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block pfeng pfeng-base: PFE Platform started successfully (mask: 7) s32cc_serdes_phy serdes@44180000: Using mode 3 for SerDes subsystem s32cc_serdes_phy serdes@44180000: XPCS1 power good timeout s32cc_serdes_phy serdes@44180000: XPCS0 power good timeout s32cc_serdes_phy serdes@44180000: XPCS1 is in reset s32cc_serdes_phy serdes@44180000: XPCS init failed pfeng_netif pfe0: Failed to get 'emac0_xpcs' PHY Could not get PHY for pfeng-mdio-0: addr 0 pfeng_netif pfe0: PHY device not found pfeng_netif pfe0: PHY config failed (-19) s32cc_serdes_phy serdes@44180000: Using mode 3 for SerDes subsystem No space for a new XPCS instance s32cc_serdes_phy serdes@44180000: XPCS init failed pfeng_netif pfe1: Failed to get 'emac1_xpcs' PHY Could not get PHY for pfeng-mdio-1: addr 0 pfeng_netif pfe1: PHY device not found pfeng_netif pfe1: PHY config failed (-19) Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you very much for your help. We made some modifications and got PFE0 working. Additionally, we added an oscillator to generate a 100MHz clock for SerDes0, and it seems that this SerDes is now able to come out of reset. Thanks, XD Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello， @XD  OK, thanks for your detailed clarification, when finished the mdio debugging with PHY well connected, if still issues on serdes configuration, contact us any time, we could continue the discussion on it. Furthermore, for such kinds of network bring up issues, I suggest sharing the related schematic with us for further investigation also, since it may not be convenient to share via the community, you may create private support case later if needed. BR Chenyin Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Yes, the same clock=int were applied to both serdes, only the serdes1 has not init failure any more. However, I am still working on the mdio access external PHY issues on serdes1 pfe0 and pfe1. So cannot verify these two interfaces are fully working until solve the PHY issues. Thanks, XD Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  You are welcome. From the log, seems the serdes0 still init failed, while serdes1 looks fine after applying for the changes, is it right? BR Chenyin Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , The read VR_MII_DIG_CTRL1 is working, I attached the new output. Thanks, XD U-Boot 2022.04+g4744d0e2c8+p0 (May 27 2024 - 09:33:20 +0000) SoC: NXP S32G399A rev. 1.1 CPU: ARM Cortex-A53 r0p4 @ max 1300 MHz Model: NXP S32G399A-RDB3 DRAM: 3.5 GiB Core: 312 devices, 24 uclasses, devicetree: board MMC: FSL_SDHC: 0 Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed pci_s32cc pcie@40400000: Failed to get PHY 'serdes_lane0' In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: Revision Unknown: (0x495) Net: s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed eth_eqos ethernet@4033c000: Failed to get 'gmac_xpcs' PHY eth_eqos ethernet@4033c000: XPCS init failed. Check hwconfig. (err=-19) Enable protocol@14 failed clk_enable(clk_rx) failed: -71 eth_eqos ethernet@4033c000: Failed to start clocks. Check XPCS configuration (err=-71) eth0: ethernet@4033c000 Found PFE version 0x0101 (S32G3) pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 block was initialized pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block pfeng pfeng-base: PFE Platform started successfully (mask: 7) s32cc_serdes_phy serdes@44180000: Using mode 3 for SerDes subsystem read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 read VR_MII_DIG_CTRL1 s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS1 read VR_MII_DIG_CTRL1 s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS0 , eth1: pfe0, eth2: pfe1, eth3: pfe2 Hit any key to stop autoboot: 0 => pring hwconfig Unknown command 'pring' - try 'help' => print hwconfig hwconfig=serdes0:mode=pcie&xpcs0,clock=int,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=int,fmhz=125;xpcs1_0:speed=1G,an=0;xpcs1_1:speed=1G,an=0 => Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you for your reply. I did not change anything on code, just modified the hwconfig, changed both serdes "clock=ext" to "clock=int"  the previous hwconfig, serdes0:mode=pcie&xpcs0,clock=ext,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=ext,fmhz=125;xpcs1_0:speed=1G;xpcs1_1:speed=1G current hwconfig, serdes0:mode=pcie&xpcs0,clock=int,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=int,fmhz=100;xpcs1_0:speed=1G;xpcs1_1:speed=1G and here is the new log after applying the nxp-s32cc-xpcs.c change. However, I don't think that function was executed. I have printf in the code and patch it to bb file. => setenv hwconfig "serdes0:mode=pcie&xpcs0,clock=int,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=int,fmhz=100;xpcs1_0:speed=1G,an=0;xpcs1_1:speed=1G,an=0" => save Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done OK => reset resetting ... ERROR: read error from device: 0x34330408 register: ERROR: Failed to disable VR5510 watchdog NOTICE: Reset status: Destructive Reset (RUN) NOTICE: BL2: v2.10.0 (release):bsp41.0-2.10-dirty NOTICE: BL2: Built : 09:32:10, May 27 2024 NOTICE: BL2: Booting BL31 U-Boot 2022.04+g4744d0e2c8+p0 (May 27 2024 - 09:33:20 +0000) SoC: NXP S32G399A rev. 1.1 CPU: ARM Cortex-A53 r0p4 @ max 1300 MHz Model: NXP S32G399A-RDB3 DRAM: 3.5 GiB Core: 312 devices, 24 uclasses, devicetree: board MMC: FSL_SDHC: 0 Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed pci_s32cc pcie@40400000: Failed to get PHY 'serdes_lane0' In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: Revision Unknown: (0x496) Net: s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed eth_eqos ethernet@4033c000: Failed to get 'gmac_xpcs' PHY eth_eqos ethernet@4033c000: XPCS init failed. Check hwconfig. (err=-19) Enable protocol@14 failed clk_enable(clk_rx) failed: -71 eth_eqos ethernet@4033c000: Failed to start clocks. Check XPCS configuration (err=-71) eth0: ethernet@4033c000 Found PFE version 0x0101 (S32G3) pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 block was initialized pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block pfeng pfeng-base: PFE Platform started successfully (mask: 7) s32cc_serdes_phy serdes@44180000: Using mode 3 for SerDes subsystem s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS1 s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS0 , eth1: pfe0, eth2: pfe1, eth3: pfe2 Hit any key to stop autoboot: 0 git diff recipes-bsp/u-boot/u-boot-s32_2022.04.bb diff --git a/recipes-bsp/u-boot/u-boot-s32_2022.04.bb b/recipes-bsp/u-boot/u-boot-s32_2022.04.bb index aeb44d20..4ebf970c 100644 --- a/recipes-bsp/u-boot/u-boot-s32_2022.04.bb +++ b/recipes-bsp/u-boot/u-boot-s32_2022.04.bb @@ -8,4 +8,5 @@ LIC_FILES_CHKSUM += " \ # Support for generating default environment SRC_URI += " \ file://0001-env-Add-Makefile-rule-to-generate-default-environment-${PV}.patch \ + file://0001-nxp-changes.patch \ " git diff recipes-bsp/u-boot/u-boot-s32_2022.04.bb diff --git a/recipes-bsp/u-boot/u-boot-s32_2022.04.bb b/recipes-bsp/u-boot/u-boot-s32_2022.04.bb index aeb44d20..4ebf970c 100644 --- a/recipes-bsp/u-boot/u-boot-s32_2022.04.bb +++ b/recipes-bsp/u-boot/u-boot-s32_2022.04.bb @@ -8,4 +8,5 @@ LIC_FILES_CHKSUM += " \ # Support for generating default environment SRC_URI += " \ file://0001-env-Add-Makefile-rule-to-generate-default-environment-${PV}.patch \ + file://0001-nxp-changes.patch \ " Thanks, XD Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  Thanks for your reply. Yes, from the current log, seems the serdes1 status is correct, may I know what kind of modification you had made? For serdes0, the log shows it is not correct, by reviewing the code, would you mind trying the following modifications on u-boot  diff --git a/drivers/net/pcs/nxp-s32cc-xpcs.c b/drivers/net/pcs/nxp-s32cc-xpcs.c index 38acad9fe7..5f643b93a3 100644 --- a/drivers/net/pcs/nxp-s32cc-xpcs.c +++ b/drivers/net/pcs/nxp-s32cc-xpcs.c @@ -519,7 +519,7 @@ static bool is_not_in_reset(struct s32cc_xpcs *xpcs) { u32 val; - val = XPCS_READ(xpcs, SR_MII_CTRL); + val = XPCS_READ(xpcs, VR_MII_DIG_CTRL1); return !(val & SR_RST); } Thanks for sharing the new logs. BR Chenyin Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you for the confirmation. Currently, I am using BSP41 and have configured hwconfig to set both SerDes0 and SerDes1 to use the internal reference clock: "serdes0:mode=pcie&xpcs0,clock=int,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=int,fmhz=100;xpcs1_0:speed=1G;xpcs1_1:speed=1G" From the output (attached below), it appears that xpcs0 is still in reset, while xpcs1 shows some improvement. Does this indicate that xpcs1 is now functioning correctly, but the internal reference clock is not working for xpcs0? Is my understanding correct? Thanks, XD => setenv hwconfig "serdes0:mode=pcie&xpcs0,clock=int,fmhz=100;pcie0:mode=rc;xpcs0_0:speed=1G,an=0;serdes1:mode=xpcs0&xpcs1,clock=int,fmhz=100;xpcs1_0:speed=1G;xpcs1_1:speed=1G" => save Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done OK => reset resetting ... ERROR: read error from device: 0x34330408 register: ERROR: Failed to disable VR5510 watchdog NOTICE: Reset status: Destructive Reset (RUN) NOTICE: BL2: v2.10.0 (release):bsp41.0-2.10-dirty NOTICE: BL2: Built : 09:32:10, May 27 2024 NOTICE: BL2: Booting BL31 U-Boot 2022.04+g4744d0e2c8+p0 (May 27 2024 - 09:33:20 +0000) SoC: NXP S32G399A rev. 1.1 CPU: ARM Cortex-A53 r0p4 @ max 1300 MHz Model: NXP S32G399A-RDB3 DRAM: 3.5 GiB Core: 312 devices, 24 uclasses, devicetree: board MMC: FSL_SDHC: 0 Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Failed to configure XPCS1_0 Failed to update XPCS0 for SerDes1 Failed to configure XPCS1_1 Failed to update XPCS1 for SerDes1 s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed pci_s32cc pcie@40400000: Failed to get PHY 'serdes_lane0' In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: Revision Unknown: (0x496) Net: s32cc_serdes_phy serdes@40480000: Using mode 1 for SerDes subsystem s32cc_serdes_phy serdes@40480000: XPCS0 is in reset s32cc_serdes_phy serdes@40480000: XPCS init failed eth_eqos ethernet@4033c000: Failed to get 'gmac_xpcs' PHY eth_eqos ethernet@4033c000: XPCS init failed. Check hwconfig. (err=-19) Enable protocol@14 failed clk_enable(clk_rx) failed: -71 eth_eqos ethernet@4033c000: Failed to start clocks. Check XPCS configuration (err=-71) eth0: ethernet@4033c000 Found PFE version 0x0101 (S32G3) pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 block was initialized pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block pfeng pfeng-base: PFE Platform started successfully (mask: 7) s32cc_serdes_phy serdes@44180000: Using mode 3 for SerDes subsystem s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS1 s32cc_serdes_phy serdes@44180000: Unstable RX detected on XPCS0 Could not get PHY for pfeng-mdio-0: addr 0 pfeng_netif pfe0: PHY device not found pfeng_netif pfe0: PHY config failed (-19) Could not get PHY for pfeng-mdio-1: addr 0 pfeng_netif pfe1: PHY device not found pfeng_netif pfe1: PHY config failed (-19) , eth3: pfe2 Hit any key to stop autoboot: 0 Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  You are welcome. Currently, seems the bug I noticed is related with mode 5 only. BR Chenyin Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you for looking into this issue. Based on our hardware routing, I need to use Mode 1 on SerDes0 and Mode 3 on SerDes1. Could you confirm if the bug only affects Mode 5 on SerDes1, or if it occurs with every internal reference clock? If Mode 1 and Mode 3 are unaffected, I can continue using BSP41. Otherwise, I may need to merge my changes into BSP42, as this hardware version does not have an external clock. Thanks, XD Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  Thanks for your reply. I have checked the code, and found that in BSP41 there seems bug existed for Serdes1 Mode5 in U-boot.  May I know if it is convenient for use to try it on BSP42? BR Chenyin  Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you for your reply. We are using bsp41, here is the log after changing to the new hwconfig. Thanks, XD U-Boot 2022.04+g4744d0e2c8+p0 (May 27 2024 - 09:33:20 +0000) SoC: NXP S32G399A rev. 1.1 CPU: ARM Cortex-A53 r0p4 @ max 1300 MHz Model: NXP S32G399A-RDB3 DRAM: 3.5 GiB Core: 312 devices, 24 uclasses, devicetree: board MMC: FSL_SDHC: 0 Loading Environment from SPIFlash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB OK Disabling XPCS1_0 Failed to configure XPCS1_1 Failed to update XPCS1 for SerDes1 s32cc_serdes_phy serdes@40480000: Using mode 0 for SerDes subsystem pci_s32cc pcie@40400000: DBI R/W is not being enabled pci_s32cc pcie@40400000: PCI Device and Vendor IDs could not be set pci_s32cc pcie@40400000: DBI R/W is not being enabled s32cc_serdes_phy serdes@40480000: Failed to lock PCIe phy s32cc_serdes_phy serdes@40480000: PHY: Failed to power on serdes@40480000: -110. pci_s32cc pcie@40400000: Failed to power on PHY 'serdes_lane0' pci_s32cc pcie@40400000: Failed to set PCIe host settings s32cc_serdes_phy serdes@44180000: Using mode 5 for SerDes subsystem s32cc_serdes_phy serdes@44180000: XPCS INIT failed s32cc_serdes_phy serdes@44180000: Switch to PLLB failed s32cc_serdes_phy serdes@44180000: Failed to prepare SerDes for PCIE & XPCS @ 2G5 mode s32cc_serdes_phy serdes@44180000: XPCS init failed pci_s32cc pcie@44100000: Failed to get PHY 'serdes_lane0' In: serial@401c8000 Out: serial@401c8000 Err: serial@401c8000 Board revision: Revision Unknown: (0x495) Net: s32cc_serdes_phy serdes@40480000: Couldn't translate XPCS to lane eth_eqos ethernet@4033c000: Failed to get 'gmac_xpcs' PHY eth_eqos ethernet@4033c000: XPCS init failed. Check hwconfig. (err=-22) Enable protocol@14 failed clk_enable(clk_rx) failed: -71 eth_eqos ethernet@4033c000: Failed to start clocks. Check XPCS configuration (err=-71) eth0: ethernet@4033c000 Found PFE version 0x0101 (S32G3) pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 not used, skipped pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block pfeng pfeng-base: PFE Platform started successfully (mask: 6) s32cc_serdes_phy serdes@44180000: Using mode 5 for SerDes subsystem s32cc_serdes_phy serdes@44180000: XPCS INIT failed s32cc_serdes_phy serdes@44180000: Switch to PLLB failed s32cc_serdes_phy serdes@44180000: Failed to prepare SerDes for PCIE & XPCS @ 2G5 mode s32cc_serdes_phy serdes@44180000: XPCS init failed pfeng_netif pfe1: Failed to get 'emac1_xpcs' PHY Could not get PHY for pfeng-mdio-1: addr 0 pfeng_netif pfe1: PHY device not found pfeng_netif pfe1: PHY config failed (-19) , eth3: pfe2 Hit any key to stop autoboot: 0 => print hwconfig hwconfig=serdes0:mode=pcie,clock=ext;pcie0:mode=rc;serdes1:mode=pcie&xpcs1,clock=int,fmhz=100;pcie1:mode=rc;xpcs1_1:speed=2G5 => Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  I remember that the "clock=int" should be available, and according to the UM, the following hwconfig could be seen: Would you please help to share more logs for the setting issue you met?  (also BSP version used) BR Chenyin Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @chenyin_h , Thank you for your input. How can I make the change to use the internal reference clock? I tried changing the hwconfig from clock=ext to clock=int, but it didn’t help. It seems like the U-Boot code only recognizes the ext keyword. Maybe I missed something. Do you have any suggestions? Thanks, XD Re: S32G3 bsp41 XPCS are in reset and init failed on the customized board Hello, @XD  Thanks for @jiajun_cheng 's kindly input, yes, from the log, it seems like the case we ever supported You mentioned that both PCIE0_CLK_P/N and PCIE1_CLK_P/N are grounded, then you may have to use the internal clock to driver. BR Chenyin 回复： S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi @jiajun_cheng , Thank you for you suggestions. According to the schematics, both PCIE0_CLK_P/N and PCIE1_CLK_P/N are grounded. Does the XPCS share the same clock as the PCIE? If so, is it possible to use the internal reference clock to feed into the SERDES instead? Thanks, XD 回复： S32G3 bsp41 XPCS are in reset and init failed on the customized board Hi, @XD : I have also been debugging our custom board recently, although the interfaces used are slightly different, I only used (gmac0 & pfe2) I also encountered the same log. In our hardware, it was caused by the routing and PCIE0_CLK_P. So I suggest you look at the hardware reasons first: 1. Is the serdes clock 125/100mhz 2. Is the power supply normal

imx8mm with 24-Bit RGB TTL Display Hello NXP Team, I am looking for a solution to connect a 24 bit RGB display with a resolution of 480x272 and a pixel clock/DCLK of typ. 9 MHz (8-12 MHz) to the MIPI-DSI interface of the imx8mm. I have 2 questions: Can you suggest a solution how I can connect the display to the MIPI-DSI interface (bridge/Converter and so on)? Do you know the minimum pixel clock that a MIPI-DSI interface can provide? Is it even possible to connect such a slow/small display to the MIPI-DSI-Interface? Many thanks for your support! Dirk Re: imx8mm with 24-Bit RGB TTL Display Hi @dirkbender! At the moment we don't have any documentation or solution using a small display on iMX Processors. We have an Application Note using the iMXRT 1170 with a small display using Mipi DSI protocol.

NXP_C45_TJA11XX Driver Soft Reset Issue Hello everyone, We're doing a bring-up of a custom board that has TI TDA4 SoC and TJA1120 PHY on it. After including the nxp_c45_tja11xx driver in our Linux build, we got an error during boot inside the nxp_c45_soft_reset function. If we make a change to the phy_read_mmd_poll_timeout macro call so that its last parameter (sleep_before_read) is true instead of false as is the case by default, this issue disappears. We also tried using shorter sleep (1000 us) before phy_read_mmd_poll_timeout and this also works. It seems that without any sleep between MDIO write and read, the software tries to read the PHY register while it's still in reset and fails. But, strangely, this wasn't noticed by anyone so far. Could this be somehow caused by our board, or is this perhaps a bug in the driver? Note: We are using the revision 1 of TJA1120A Phy. Best Regards, Dusan   Re: NXP_C45_TJA11XX Driver Soft Reset Issue Patch sent: https://lkml.org/lkml/2025/1/16/837 Re: NXP_C45_TJA11XX Driver Soft Reset Issue Hello @rm_ , that would be great. Please do. Best regards, Pavel Re: NXP_C45_TJA11XX Driver Soft Reset Issue Hello @PavelL, I'm working with Dusan on this. Shall we create a patch with fix and send it to driver maintainer(s)? Best Regards, Milos Re: NXP_C45_TJA11XX Driver Soft Reset Issue Hello @DusanStanisic99 , that might be a small bug in the driver. Your observation seems to be correct to me. Please refer to TJA1120's application note, AN13663, page 30 - where startup timing is depicted. Best regards, Pavel

PCA9617 waveform This circuit works fine with the PCA9600, but to reduce costs, I modified the board to use a PCA9617 and checked the waveform. Looking at the clock waveform, there is no particular distortion, so there doesn't seem to be a problem, but at the point where the data waveform is outputting Low, I observed a waveform that was pulled High at the falling edge of the clock. I wonder if this is due to crosstalk between the clock and data (there is no problem when the PCA9600DPZ is installed), or is it an effect of modifying the board pattern (pattern cutting/cable soldering)? I would appreciate your opinions. Re: PCA9617 waveform HI yuji0935  I think it's an effect of modifying the board pattern  (pattern cutting/cable soldering)about this glitch. Thanks! BR

PCA9617波形 この回路はPCA9600で問題なく動作しますが、コストを下げるために、PCA9617を使用するようにボードを変更し、波形を確認しました。 クロック波形を見ると、特に歪みはありませんが、 なので問題なさそうですが、データ波形がLowを出力しているポイントでは、 クロックの立ち下がりエッジでHighに引っ張られた波形を観察しました。 これはクロックとデータ間のクロストークによるものなのでしょうか(PCA9600DPZを装着していれば問題ありません)、 それとも基板のパターン修正(パターンカット/ケーブルはんだ付け)の影響ですか? ご意見を頂戴いたします。

IW612 PCM/I2S support I am developing an embedded audio application that is using the IW612 for Bluetooth communication. The IW612 has a PCM/I2S interface - is this interface only intended for use with SCO audio, or can it be used in other cases, such as for audio streaming with A2DP? Re: IW612 PCM/I2S support Dear @skordal , >> is this interface only intended for use with SCO audio? Yes, PCM/I2S is only used for SCO or eSCO. >>About A2DP UART interface is used for A2DP. Thanks! Regards, weidong

i.MX8MM ECSPI slave mode restriction I am currently using the i.MX8MM ECSPI Slave in PIO mode. The issue is that in Slave mode, the burst length appears to be limited to 512 bytes. While it's not clear whether using DMA mode instead of PIO mode would remove the transmission data size limitation, I have applied a kernel patch to try using DMA mode. Can I get sample code or materials related to SPI data transmission and reception in Slave mode(using DMA)? I am referring to the AN13633 document, but I would appreciate any comments if there are other helpful resources available. Let me know if you would like me to help you find specific resources or documentation about implementing DMA mode for ECSPI on i.MX8MM. Re: i.MX8MM ECSPI slave mode restriction Thank you for your quick response. Have a nice day. Re: i.MX8MM ECSPI slave mode restriction double checked again, this limitation is HW limitation, the AN is released and based on the old bsp, the new bsp add 512 bytes limitation because of HW limitation, so you couldn't remove this,  it seems imx8mm ecspi couldn't support this(no 512 bytes limitation) if you want to use slave mode Re: i.MX8MM ECSPI slave mode restriction Thank you for your reply. But, I didn't understand exactly what you said. Does annotating the 512 byte limit in kernel code mean I can transfer more than 512 bytes in SPI Slave mode? if ((is_imx51_ecspi(spi_imx) || is_imx53_ecspi(spi_imx)) && transfer->len > MX53_MAX_TRANSFER_BYTES && spi_imx->target_mode) {     dev_err(spi_imx->dev, "Transaction too big, max size is %d bytes\n",     MX53_MAX_TRANSFER_BYTES);     return -EMSGSIZE; } Re: i.MX8MM ECSPI slave mode restriction I checked the driver again, the limitation is https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/spi/spi-imx.c#L1492 if you want to test this, you can comment the 512 limitation to test based on your detailed user case Re: i.MX8MM ECSPI slave mode restriction confirmed that DMA/PIO mode has 512 limitation, and DMA has 4 bytes align limitation, you can refer to the patch I sent to you before Re: i.MX8MM ECSPI slave mode restriction I apologize for contacting you. I have a question I'd like to ask for clarification. Could you please help me understand the meaning of the note on page 5 of the linked document? (Link) https://www.nxp.com/docs/en/application-note/AN13633.pdf " Note: From testing, it seems no such transfer length restriction must be added in DMA mode. So only PIO mode has this restriction." Re: i.MX8MM ECSPI slave mode restriction Thank you for your quick reply. Re: i.MX8MM ECSPI slave mode restriction yes, DMA has this limtitaion too Re: i.MX8MM ECSPI slave mode restriction Thank you for your response. I was trying to enable DMA mode thinking there were no transfer size restrictions in DMA mode. Based on the linked document, does it mean that both PIO and DMA modes have a 512-byte limit for transfer data size? Re: i.MX8MM ECSPI slave mode restriction AN13633 is very detailed application note for your request, for dma support, you also can refer to the patch as below, and you also can focus on the ERR003775 from errata LF-6680 spi: imx: add dma support for target mode · nxp-imx/linux-imx@1aef8ed · GitHub

change bluetooth address via vendor specific commands I am working with a module based on the 88W8997 chipset. We have a need to change the device's public BD address. Is there a vendor-specific command for doing so? What specific internal documents do I need to request access to? Product: WiFi 88W8997 Protocol: Bluetooth Re: change bluetooth address via vendor specific commands Dear @mike16 , See below, please! Thanks! Regards, weidong

i.MX93: ESDHC erratum ERR052357 U-Boot code from current BSP (lf-6.6.52_2.2.0) contains a fix for an undocumented erratum. Please give more in detail information about the issue. Is there a fix available for Linux? Re: i.MX93: ESDHC erratum ERR052357 Hi @Niebel-TQ  Is this always guaranteed even for a kernel compiled with PREEMPT_RT and / or at higher tick rates? -->The Linux OS here is NONE-RT kernel, for NONE-RT kernel, we have tested and didn't observe issue. For PREEMPT_RT Linux, there is no test data on this, but according to previous information, for Real Time OS, this delay needs to be added.  Is this issues limited to i.MX93 or is it present in other CPU / MCU -->The affected chips are i.MX91, i.MX93 and i.MX95 A1. Best Regards, Zhiming Re: i.MX93: ESDHC erratum ERR052357 Add  @florian_arndt and @danny_john Re: i.MX93: ESDHC erratum ERR052357 Thank you for explaining. Two additiponal questions:  1) `In Linux OS, since software latency is enough`: Is this always guaranteed even for a kernel compiled with PREEMPT_RT and / or at higher tick rates? 2) Is this issues limited to i.MX93 or is it present in other CPU / MCU (we us a lot of different NXP products in our company) Re: i.MX93: ESDHC erratum ERR052357 Hello, In Linux OS, since software latency is enough, this issue will not be observed, no need extra workaround. In real time OS like QNX, extra delay time should be added to avoid this issue. So in u-boot, 10μs delay is added for uSDHC read transfer since Linux 6.6.36_2.1.0. This errata will not affect application layer. Best Regards, Zhiming Re: i.MX93: ESDHC erratum ERR052357 Yes, this is the commit. 10us is a lot of time. Re: i.MX93: ESDHC erratum ERR052357 Hello, Is this commit? Best Regards, Zhiming

i.MX8MM ECSPIスレーブモードの制限 現在、i.MX8MM ECSPI SlaveをPIOモードで使用しています。 問題は、スレーブ モードでは、バースト長が 512 バイトに制限されているように見えることです。 PIOモードの代わりにDMAモードを使用すると送信データサイズの制限がなくなるかどうかは明らかではありませんが、カーネルパッチを適用してDMAモードを使用してみました。 スレーブモード(DMA使用)でSPIデータの送受信に関するサンプルコードや資料は入手できますか? 私はAN13633のドキュメントを参照していますが、他の役立つリソースがあればコメントをいただければ幸いです。 i.MX8MMでのECSPIのDMAモードの実装に関する特定のリソースやドキュメントを見つけるのを手伝ってほしい場合は、お知らせください。 Re:i.MX8MM ECSPIスレーブモードの制限 迅速な対応ありがとうございました。 よい一日を。 Re:i.MX8MM ECSPIスレーブモードの制限 もう一度確認し直して、この制限はHWの制限であり、ANがリリースされ、古いbspに基づいて、新しいbspはHWの制限のために512バイトの制限を追加するため、これを削除することはできませんでした、スレーブモードを使用したい場合は、imx8mm ecspiがこれをサポートできなかったようです（512バイトの制限はありません Re:i.MX8MM ECSPIスレーブモードの制限 ご返信ありがとうございます。 でも、君が何を言っているのかよくわからなかった。 カーネル コードで 512 バイトの制限に注釈を付けると、SPI スレーブ モードで 512 バイト以上を転送できるということですか。 if ((is_imx51_ecspi(spi_imx) || is_imx53_ecspi(spi_imx)) && transfer->len > MX53_MAX_TRANSFER_BYTES & spi_imx->target_mode) { dev_err(spi_imx->dev, "トランザクションが大きすぎます。最大サイズは %d バイトです\n", MX53_MAX_TRANSFER_BYTES); -EMSGSIZEを返します。 } Re:i.MX8MM ECSPIスレーブモードの制限 ドライバーを再度確認しましたが、制限は https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/spi/spi-imx.c#L1492 これをテストしたい場合は、詳細なユーザーケースに基づいてテストする512制限をコメントできます Re:i.MX8MM ECSPIスレーブモードの制限 DMA / PIOモードには512の制限があり、DMAには4バイトのアライメント制限があることを確認しましたので、以前に送信したパッチを参照できます Re:i.MX8MM ECSPIスレーブモードの制限 ご連絡を頂きまして申し訳ございません。 明確にしたい質問があります。 リンクされたドキュメントの5ページにある注の意味を理解するのを手伝っていただけますか? (リンク) https://www.nxp.com/docs/en/application-note/AN13633.pdf 注:テストの結果、DMAモードではそのような転送長の制限を追加する必要はないようです。したがって、PIOモードにのみこの制限があります。」 Re:i.MX8MM ECSPIスレーブモードの制限 迅速な返信ありがとうございます。 Re:i.MX8MM ECSPIスレーブモードの制限 ええ、DMAにもこの制限があります Re:i.MX8MM ECSPIスレーブモードの制限 返信ありがとうございます。 DMAモードには転送サイズの制限がないと思って、DMAモードを有効にしようとしていました。 リンクされたドキュメントに基づいて、PIO モードと DMA モードの両方に転送データ サイズに 512 バイトの制限があるということですか? Re:i.MX8MM ECSPIスレーブモードの制限 AN13633、DMAサポートについては、ご要望に応じた非常に詳細なアプリケーションノートであり、以下のようにパッチを参照することもでき、また、 エラッタからのERR003775 LF-6680 spi: imx: ターゲットモードのdmaサポートを追加 ·nxp-imx/linux-imx@1aef8ed ·GitHubの

i.MX8MM ECSPI 从属模式限制 我目前正在 PIO 模式下使用 i.MX8MM ECSPI 从属设备。 问题是，在从属模式下，突发长度似乎被限制为 512 字节。 虽然不清楚使用 DMA 模式而不是 PIO 模式是否会消除传输数据大小限制，但我已经应用了内核补丁来尝试使用 DMA 模式。 我可以获得与从属模式（使用 DMA）下的 SPI 数据传输和接收相关的示例代码或资料吗？ 我指的是 AN13633 文档，但如果有其他有用的资源，我将非常感激您的评论。 如果您希望我帮助您找到有关在 i.MX8MM 上为 ECSPI 实现 DMA 模式的特定资源或文档，请告诉我。 回复：i.MX8MM ECSPI 从属模式限制 感谢您的快速回复。 祝你今天过得愉快。 回复：i.MX8MM ECSPI 从属模式限制 再次检查，这个限制是硬件限制，AN 是基于旧 bsp 发布的，由于硬件限制，新 bsp 增加了 512 字节限制，所以你不能删除这个，如果你想使用从属模式，似乎 imx8mm ecspi 无法支持这个（没有 512 字节限制） 回复：i.MX8MM ECSPI 从属模式限制 感谢你的回复。 但是，我不太明白你的意思。 在内核代码中注释 512 字节限制是否意味着我可以在 SPI 从属模式下传输超过 512 字节？ 如果（（is_imx51_ecspi（spi_imx）|| is_imx53_ecspi（spi_imx））&& 传输->长度 > MX53_MAX_TRANSFER_BYTES && spi_imx->目标模式) { dev_err（spi_imx->dev，“事务太大，最大大小为%d字节\n”， MX53_最大传输字节数）； 返回-EMSGSIZE； } 回复：i.MX8MM ECSPI 从属模式限制 我再次检查了驱动程序，限制是 https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/drivers/spi/spi-imx.c#L1492 如果你想测试这一点，你可以根据你详细的用户案例，评论 512 限制进行测试 回复：i.MX8MM ECSPI 从属模式限制 确认DMA/PIO模式有512个限制，DMA有4个字节对齐限制，你可以参考我之前发给你的补丁 回复：i.MX8MM ECSPI 从属模式限制 很抱歉联系您。 我有一个问题想请求澄清。 您能帮我理解链接文档第 5 页注释的含义吗？ （关联） https://www.nxp.com/docs/en/application-note/AN13633.pdf “注意：从测试来看，在 DMA 模式下似乎不需要添加这样的传输长度限制。所以只有PIO模式才有这个限制。” 回复：i.MX8MM ECSPI 从属模式限制 感谢您的快速回复。 回复：i.MX8MM ECSPI 从属模式限制 是的，DMA 也有这个限制 回复：i.MX8MM ECSPI 从属模式限制 谢谢您的回复。 我试图启用 DMA 模式，认为 DMA 模式下没有传输大小限制。 根据链接的文档，这是否意味着 PIO 和 DMA 模式对传输数据大小都有 512 字节的限制？ 回复：i.MX8MM ECSPI 从属模式限制 AN13633 是一份非常详细的应用说明，适用于您的请求，对于 DMA 支持，您还可以参考下面的补丁，还可以关注勘误表中的 ERR003775 LF-6680 spi: imx: 添加目标模式的 dma 支持 · nxp-imx/linux-imx@1aef8ed · GitHub

IMX8ulp flexCAN Hi all，     I am debugging the CAN communication function, but I cannot find the flexCAN device node in the dtb file. If I want to get it working, what's the solution? Best regards! i.MX8ULP Re: IMX8ulp flexCAN Yes, I see.Thanks a lot! Re: IMX8ulp flexCAN I just got the confirmation from the SE team. FlexCAN is in realtime domain so it is not supported in Linux. It can only be accessed by M core. You can find driver and related examples in SDK. Re: IMX8ulp flexCAN yeah, I know I can refer to other dts, but how do I reference the clock and interrupts? These are strongly related to hardware. Re: IMX8ulp flexCAN Please refer to the following definition in arch/arm64/boot/dts/freescale/imx8mp.dtsi in Linux Kernel. flexcan1: can@308c0000 { compatible = "fsl,imx8mp-flexcan"; reg = <0x308c0000 0x10000>; interrupts = ; clocks = <&clk IMX8MP_CLK_IPG_ROOT>, <&clk IMX8MP_CLK_CAN1_ROOT>; clock-names = "ipg", "per"; assigned-clocks = <&clk IMX8MP_CLK_CAN1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_40M>; assigned-clock-rates = <40000000>; fsl,clk-source = /bits/ 8 <0>; fsl,stop-mode = <&gpr 0x10 4>; status = "disabled"; }; flexcan2: can@308d0000 { compatible = "fsl,imx8mp-flexcan"; reg = <0x308d0000 0x10000>; interrupts = ; clocks = <&clk IMX8MP_CLK_IPG_ROOT>, <&clk IMX8MP_CLK_CAN2_ROOT>; clock-names = "ipg", "per"; assigned-clocks = <&clk IMX8MP_CLK_CAN2>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_40M>; assigned-clock-rates = <40000000>; fsl,clk-source = /bits/ 8 <0>; fsl,stop-mode = <&gpr 0x10 5>; status = "disabled"; }; }; And the following definition in arch/arm64/boot/dts/freescale/imx8mp-evk.dts. &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; status = "okay"; }; &flexcan2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan2>; xceiver-supply = <&reg_can2_stby>; pinctrl-assert-gpios = <&pca6416 3 GPIO_ACTIVE_HIGH>; status = "disabled";/* can2 pin conflict with pdm */ };

IW612 PCM/I2S 支持 我正在开发一个嵌入式音频应用程序，使用IW612进行蓝牙通信。IW612 有一个 PCM/I2S 接口 - 该接口仅适用于 SCO 音频，还是可以用于其他情况，例如用于 A2DP 音频流？

通过供应商特定命令更改蓝牙地址 我正在使用基于 88W8997 芯片组的模块。我们需要更改设备的公共 BD 地址。是否有针对供应商的特定命令可以执行此操作？我需要请求访问哪些具体的内部文件？ 产品：WiFi 88W8997 协议：蓝牙

RT1024 second bootloader double bank Hi, Our final goal: - Be able to write an image from the RAM into a bank of the flash (with a dual bank system) - After restarting the uP, check the integrity of the image and then boot on this new bank After reading different documentation we found the document MCUOTASBLSFWUG and reconfigured the RT1020 example to be compatible with the RT1024. When we load the bootloader generated, in flash, using the software 'LINKFLASH', we can connect via ISP using the software 'MCU-BOOT-Utility'. First problem if we restart the uP we can no longer connect. The configuration of the boot pins is '10' internal boot, for the others BOOT_CFGX they are all zero. Second problem, we try to load our image at the configured address (0x60200000) and the image does not boot. We set this Defined symbols : XIP_BOOT_HEADER_ENABLE to 0 Our questions are: - Is the SBL project the most relevant to use to develop our second bootloader? - After programming our bootloader, is the pin configuration correct? - Is there a special configuration at the project level on MCUExpresso to make the image bootable with the second bootloader? Re: RT1024 second bootloader double bank Finally I tested with a hello world image and it works, so we have a problem, but it does not come from the bootloader, nor from the image configuration, but from the code itself. Thank you very much for your help! Re: RT1024 second bootloader double bank Thank you for your answer. Following your advice we switched to MCUBoot. As we also have an RT1064 uP in our application, we took the example from the SDK for this uP. The bootloader compiles well, we can load it in flash, but our application does not work, we have a hardfault. We have tried different configurations, which all lead to the same result. We do not want, for the moment, to go through the imgtool tool to create a header, this is not very practical, because we are in the development phase, so first, we added a partition MCUBoot_header to the address 0x70040000 of our flash and added the necessary structure. We put our application at the address 0x70040400. We removed the key verification. And we have enabled the SINGLE_IMAGE parameter After loading our program in flash, we restart the bootloader in debug mode. The bootloader does the header check and it is valid. When arriving at the jump there is the following code : vt = (struct arm_vector_table *)(flash_base + rsp->br_image_off + rsp->br_hdr->ih_hdr_size); cleanup(); __set_CONTROL(0); __set_MSP(vt->msp); __ISB(); ((void (*)(void))vt->reset)(); at this time vt = 0x0x7004000, which seems correct. And vt.msp = 0x20020000 and vt.reset = 0x7004071D. The address of the ResetISR does not match that of the .map which is = 0x7004071C. We tried to hardcode the address, but the result is the same. Do you have any advice? Re: RT1024 second bootloader double bank Hi @Gaetan  Thank you for contacting us and for your interest!  I just want to understand this phrase better: When we load the bootloader generated, in flash, using the software 'LINKFLASH', we can connect via ISP using the software 'MCU-BOOT-Utility'. First problem if we restart the uP we can no longer connect. After programming the ported SBL, do you see this bootloader executing ? After testing by loading a blinky with the LINKFLASH on RT1024, I had to make a reset to see the blinky running. The SBL prints to UART, when it is running. Have you ever seen any bootloader messages?  Regarding - Is the SBL project the most relevant to use to develop our second bootloader? The SBL is not under active development since 2021, still is is a good reference thanks to the security features and OTA capabilities that it provides. If we check the readme, on the github, you will find that development team recommends the MCU boot opensource project. However, the this project is also not ported for the  RT1024, but it is for the RT1020, as I mentioned on this thread I am not recommending you to jump directly to the MCU boot open source, feel free to pick the option that works better for you. Instead I mention this, in case you want  to consider other option, simply because the MCU boot open source is on active development. Regarding - After programming our bootloader, is the pin configuration correct? The SBL needs to boot on internal bootloader mode, so I think  the boot mode settings are correct. Regarding - Is there a special configuration at the project level on MCUExpresso to make the image bootable with the second bootloader? I can not tell, because I do not know all the steps you followed from the SBL user guide. If you follow all the steps, I do not see a missing step to boot the target SFW image.  Please correct me, if I am wrong, but I have not seen the SBL for the MCUXpresso IDE tool chain. Which IDE are you using? is ARM GCC instead? I hope I could help you Diego

IW612 PCM/I2S 対応 Bluetooth通信に IW612 を使用する組み込みオーディオアプリケーションを開発しています。IW612 には PCM/I2S インターフェースがありますが、このインターフェースは SCO オーディオでの使用のみを目的としていますか、それとも A2DP によるオーディオストリーミングなど、他の場合にも使用できますか?

LPCXpresso54628 Development Board SDRAM addressing I am using the documentation for the LPCXpress54628 development board as a guide to replicate the interface with the SDRAM IC IS42S16800F-6BLI in my own design.  I noticed on the diagram that there is a P1_24-EMC_A12 identified connected to pin G1.  However, the datasheet for that device shows pin G1 as NC.  I will assume it really isn't a functioning connection.  The 12 address lines A0-A11 do provide the 4K of addressing for the memory.  Was there a part change?  The other part number (W9812G6JB) also shows NC on G1. Thanks Sam LPC546xx Re: LPCXpresso54628 Development Board SDRAM addressing Hi @samv  Yes, The W9812G6JB and IS42S16800F-6BLI both have only 12 bit address lines. They are 128Mb SDRAM. You can also check the LPC54628 RM. BR Harry