ls1046a XFI Signal Stability

[__OTL__]

I am developing a board using LS1046A, and I am using MAC.9 as XFI and directly connecting it to L2SW. I have created serval development boards, but I have noticed that the XFI signal does not seem to be very stable.

80% of the boards can use ping and tftp in U-boot, but cannot ping in Linux.
10% of the boards can use the network in both U-boot and Linux, but the iperf speed is only around 1Mb/s in Linux.
10% of the boards cannot use the network in either U-boot or Linux.

I suspect that it is an issue with the XFI signal. Please advise me on how to modify the register to adjust the signal strength.

Thank you!

[yipingwang]

[Q1] Is there a retimer in the XFI path? It is recommend to use a retimer with XFI on our SoCs.

That being said, the retimer is usually with the connection being a SFP cage.
Only the LX2160A has been deemed to not use a retimer because it can meet SFI electrical specifications.

We don't use a retimer in the XFI when we don't need XFI-toSFI electrical conversion.
Hence, you will see a direct connection to the AQR PHYs because they support XFI.

[Q2] Does the L2SW support XFI?
If so, did the IBIS modeling for the interconnect highlight any issues?

AN12750 is related to 10GBASE-KR but it highlights the registers for TX equalization settings.

Aside from the possible HW issues. How is the SW configured for the link. For Linux, it should be defined as "fixed".

I'll research the details for the SW changes.

[__OTL__]

Thank you for your reply.

To answer your question:

1. No, there is no retimer. That was my mistake.
2. Yes, the L2SW supports XFI.

I confirmed the signal waveform using a high-speed oscilloscope and found no issues. Additionally, the L2SW did not receive any badOctects, so it doesn't seem to be a signal quality problem as I initially thought. I apologize for the confusion.

After updating the settings of the L2SW to force XFI connection, all boards (100%) were able to establish a stable XFI connection and successful pings were observed. However, the network performance remains unstable.

Currently, I am encountering the following issues:

1. In U-Boot and Linux, I can use commands like ping and tftp. However, after continuously transmitting tftp for a while, the network on some boards stops working. In such cases, I can bring the XFI MAC down using ifconfig and then bring it up again to restore functionality.

2. During iperf testing in Linux, I observed the following problems:

   • TCP operates at near maximum speed.
   • UDP speed is extremely slow, approximately 1 Mb/s.
     I referred to the following forum post: LS1021A-TWR UDP packet loss - NXP Community
     I tried disabling CONFIG_NETFILTER and CONFIG_CPU_FREQ as suggested, but it did not improve the situation.

3. For the fman firmware, I only used fsl_fman_ucode_ls1046_r1.0_108_4_9.bin. Is this firmware not sufficient, or am I using it incorrectly?

[yipingwang]

Please refer to the update from the AE team.

https://www.nxp.com/docs/en/application-note/AN4760.pdf

Tell the customer to :

— CONFIG_NETFILER
— CONFIG_CPU_FREQ
— CONFIG_USB_SUPPORT
— CONFIG_MMC

The boot argument used were:
Kernel command line: root=/dev/nfs rw nfsroot=10.171.81.48:/work/rootfs-ls1043-siemens,vers=3 ip=192.168.2.160:192.168.1.1:192.168.1.4:255.255.248.0:ls10406:eth7:off console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 pci=pcie_bus_perf iommu.passthrough=1 default_hugepagesz=2m hugepagesz=2m hugepages=512

apply the fmc
fmc -c config_file -p pcd_file -a

then try iperf

maxflows=$ncpu

ncpu=$(nproc)

the above instructions, revert them


for i in $(seq 1 $ncpu); do
        taskset --cpu-list $(($i-1)) iperf -c 1.1.1.$(($i+1)) -u -b 10000M -t 3 -P 1 -l 1400B&
done

OR

iperf -c 1.1.1.2 -u -b 10000M -t 3 -P 16 -l 1000B

If TCP works then UDP overhead must be related to some config problems

TCP is controlled while UDP isn't. UDP should work at line rate

they can do in loopback with iperf without depending on a server

if loopback works at linerate then the problem is the xfi connection with the other end

but if tcp worked then it should work with udp as well. contradictory info means that they have some config issues in udp case