LS1046A - How to configure the Linux kernel for a USB 3.0 compliance test?

[AbelianMeme]

Hi everyone,

I have very little knowledge of how USB 3.0 compliance testing works, but apparently it isn't as simple as I had hoped.  We recently sent our product configured around an LS1046A running Linux to a testing house to get USB3.2 Gen 1 Tx compliance test done.

They plugged in their test equipment and reported:

"We turned on the DUT and connected the test fixture to the "USB-A" Port and didn't see any test packets (LFPS packet or Compliance TestPatterns) on the oscilloscope"

I have no idea how to proceed now. I thought the Linux kernel was just supposed to recognize this and automatically load the appropriate module for test.

I can find some limited discussion online about USB2.0 testing, but nothing about superspeed tests. How can I start to make sense of what might be happening?

Are there specific kernel options that I could have misconfigured?

Is there any easy way I can test this locally to see if it is doing what it is supposed to without access to a USB compliance testing apparatus?

Thank you for any assistance.

[LFGP]

dear @AbelianMeme ,

in order to check the USB compliance is necessary to use a specific apparatus to develop the specific test.

But if you only want to have an idea if your device is using USB3 or not, you can develop an empirical test, I mean, transfer any big file size from the board to some memory stick USB3 and then repeat the test with other memory USB2, if the elapsed time is bigger on USB2 then you can conclude that you have USB3 on your board.

But first of all, is your USB port working?

In addition you can develop a test at Kernel level debug, review the next link

https://www.kernel.org/doc/html/v6.3/driver-api/usb/usb3-debug-port.html

[AbelianMeme]

Thank you for taking the time to response. I'm not sure this really helps though. The problem is as follows:

We are having significant trouble getting the LS1046A to communicate with USB3.2 Gen 1 devices at superspeed.  The kernel seems to enumerate them OK, but just reports communication errors after it is connected. We are able to plug in 2.0 devices, and most work.  We have a standard, 60cm USB cable (the same blue cables that are used in PC's for this purpose) that leads from the mainboard where our LS1046A is located to the USB connector on the chassis.

We asked NXP if they could please provide us different parameters that we could program into the LS1046A registers to configure the PHY for better signal quality.  We were told by NXP that we needed to send them the output from a USB Tx compliance test first.

We found a lab that could do that for us, and paid them a significant amount of money for the privilege, but the USB port doesn't respond at all when the lab attaches an appropriate test fixture.

I have no idea how to proceed from here.

What could be causing the USB port to not respond to the compliance events?

Is it a software problem? Do I not have the correct settings in the Linux .config file?

Note that I am not there at the compliance test facility. It is in a completely different country, which is why I asked if there is anything I can do to simulate what may be happening at the test center locally without access to the compliance test fixtures or the appropriate hardware.

Any assistance at what I can do is appreciated.  Really, all of this is just to get NXP's assistance to provide us parameters that we can use to adjust the signal integrity on the PHY.

[yipingwang]

Please refer to the following update from the AE team.

Users can apply the patches to linux souce codes and rebuild the kernel for running the compliance test. These patches are for reference now as they were made for LSDK-2004. If the users don't adopt LSDK-2004, they may need to do similar changes to their kernel source codes manually. The USB 3.0 compliance test mode should enter automatically as no command is needed.

After running with the patched kernel, users should connect test fixture and other equipment to the LS1046A board and follow the test procedure as described in test equipment manual.

[yipingwang]

Discussing with the AE team.