you can enter the following commands to enter the USB2.0 into compliance with the test packet。 devmem2 0x31000420 w 0xA0 devmem2 0x31000020 w 0x4 devmem2 0x31000424 w 0x40000000

How to enable USB test mode for  USB 3.0 eye diagram ，use same to

USB 2.0  or other?

Thanks 

USB2p0 Expected to be tested on January 10th.

Can you provide the  software package for testing  USB3.0 eye diagrams and how to use it?

Thanks.

Guojuan,

Pls refer to the Lecroy QPHY USB test manual.

https://cdn.teledynelecroy.com/files/manuals/qualiphyusb3manual.pdf

This PDF is use for X86

we need u-boot or Linux kernel to cest USB3.0 eye diagrams

Shreyas, 

The test manual is for Oscilloscope and I think the problem now is from DUT side (AM67x), does it require to run any software or instructions to enter test mode for USB3.0. (there is commend for USB2.0 for test mode, is there similar commend for USB3)

BR, Rich   

Hi Rich,

Guojuan's question on Jan 3 was about the software package and how to use it, so I pasted the Lecroy manual that we used.

Regarding the software instructions to test USB3.0, I replied on Jan 2 on the instructions. I used CCS for the USB 3.0 validation. I have not used Linux for USB 3.0 nor do I know if there are set of instructions to put the device into the test compliance mode.

Since USB 3.0 uses the SERDES TX/RX pins, we need to put out LFPS, CP0, and CP1 patterns that we generate using the SERDES wrapper.

Upon reading the xHCI document,

"Only if the port is in the Disconnected state, then a write to the PORTSC register with the PLS field set to Compliance Mode and LWS set to ‘1’ would enter into compliance mode after LFPS ping timeout.

From the AM67 TRM Excel sheet,

Port Link State [PLS], RWS. Default = RxDetect ['5']. This field is used to power manage the port and reflects its current link state. When the port is in the Enabled state, system software may set the link U state by writing this field. System software may also write this field to force a Disabled to Disconnected state transition of the port.
            Write Values:  
            0: The link shall transition to a U0 state from any of the U states.
            3: The link shall transition to a U3 state from the U0 state. This action selectively suspends the device connected to this port. While the Port Link State = U3, the hub does not propagate downstream-directed traffic to this port, but the hub shall respond to resume signaling from the port.
            5: If the port is in the Disabled state [PLS = Disabled, PP = '1'], then the link shall transition to a RxDetect state and the port shall transition to the Disconnected state, else ignored.
            1-2,4,6-15: Ignored.   
            State Encoding:
            0: Link is in the U0 State,
            1: Link is in the U1 State,
            2: Link is in the U2 State,
            3: Link is in the U3 State [Device Suspended],
            4: Link is in the Disabled State,
            5: Link is in the RxDetect State,
            6: Link is in the Inactive State,
            7: Link is in the Polling State,
            8: Link is in the Recovery State,
            9: Link is in the Hot Reset State,
            10 Link is in the Compliance Mode State,
            11: Link is in the Test Mode State,
            12-14: Reserved,
            15: Link is in the Resume State.
            Note: The Port Link State Write Strobe [LWS] shall also be set to '1' to write this field. This field is undefined if PP = '0'.
            Note: Transitions between different states are not reflected until the transition is complete.
            Refer to section 4.19 of xHCI specification for PLS transition conditions. Refer to sections 4.15.2 and 4.23.5 for more information on the use of this field.

Refer to the xHCI spec:

https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf

Shreyas, 

Thanks for your feedback. 

You mentioned "I used CCS for the USB 3.0 validation. I have not used Linux for USB 3.0 nor do I know if there are set of instructions to put the device into the test compliance mode." 

Later, you pointed out the registers to set for entering  compliance mode. 

"Only if the port is in the Disconnected state, then a write to the PORTSC register with the PLS field set to Compliance Mode and LWS set to ‘1’ would enter into compliance mode after LFPS ping timeout.

From the AM67 TRM Excel sheet,

Did you use CCS to do all the register setting for compliance test? Do we have a instruction guide for customer how to do this via CCS if customer have JTAG reserved? 

Customers very often not reserve JTAG, is it possible to have commends line instruction in u-boot or kernel to do same thing?

BR, Rich  

Hi Rich,

Yes, I apologize for the confusion I created. I initially replied to you not knowing if there is a way to enter compliance mode outside of using CCS. Later I went back and read the xHCI document that mentioned the compliance mode entrance, and then back to the TRM to find out the PLS and LWS register that need to be set for compliance mode entrance.

I used CCS for my USB3.0 compliance testing. In the CCS, we have APIs which set up the SERDES TX to output the LFPS signals, put the device in loopback and output the CP0 pattern through AWG or BERT, and also to output the CP1 pattern.

Would it be possible to try those registers in Linux and see if the device can enter compliance mode? Do you also have the USB squid test fixture that would be required for compliance testing?

Shreyas, 

No, we don't have USB test fixture for compliance test. 

For the register setting in Linux,  we should be able to manage it if it is just set two bits in registers but not a sequence of setting. 

Please share us the code in CCS and we can refer to modify the instructions. 

BR, Rich

I could share the binary with you, but without the test fixtures not sure if you can run the compliance.

Shreyas, 

I don't want binary and customer would like to use Linux comment. 

My intention is to check the register you set and procedure. I am not sure if I can translate to Linux but I will take a try. 

Customer has the test features and I will provide the Linux comments to them if possible. 

This USB 3.0 compliance test will be required for all customers. 

Recommend creating complete document for test procedure based on Linux.  

BR, Rich

Rich,

In the address 0x31000420h, write 0x0A010340. This command should put the SoC into USB3.0 compliance mode and then you can connect the USB test fixture.

Shreyas, 

Ok, so there is only one register need to be set to enter USB 3.0 compliance mode. 

devmem2 0x31000420 w 0xA0010340 

BR, Rich

Rich,

One register, but it touches different fields to put the device into compliance.

USE  devmem2 0x31000420 w 0xA0010340 test USB3.0：

There is a signal output, but the signal waveform cannot be fixed, and an error is displayed when switching the pattern using the SI test fixture

Now there are more LFPS signals, and it should not have fully entered the USB compliance mode

Serial port printing：

usb usb3-port1:cannot enabe.Maybe the usb cable is bad

Do you see the LFPS signal output on the TX pins? and can switch to different patterns?

Are the USB cables certified?

Standard USB test cable, other projects are tested with this test。
Use the package , there is no other waveform out, only the LFPS waveform that will appear as shown when the fixture is just connected
You can see the LFPS waveform, but you can't cut out the other patterns。

Shreyas, 

"Would it be possible to try those registers in Linux and see if the device can enter compliance mode? Do you also have the USB squid test fixture that would be required for compliance testing?"

Customer try to set registers in Linux as suggested, AM67x looks does enter test mode. They have test fixture but the result is as reported.

"we have APIs which set up the SERDES TX to output the LFPS signals, put the device in loopback and output the CP0 pattern through AWG or BERT, and also to output the CP1 pattern."

You mentioned about APIs, for setting register 0x31000420 to 0xA0010340, is it only one condition and there will be other setting for different test mode?  

Could you try to setup test for Linux and provide instructions as guideline? 

BR, Rich

Is the LFPS waveform passing the compliance test?

Do you have the S/w test suite on the scope? The test suite will provide the ping for the device to change the waveforms from Cp0 to CP1.

Shreyas, 

Yes, LFPS waveform passing the compliance test. 

Yes, customer has S/W test suite on the scope and customer also complete test with Rockchip SOC.

According to customer, the problem is now after LFPS, test suite enable the test items but there may not have ping to AM67x to inform AM67x USB to change waveform. Is there any specific operation is missed? 

Do we have a instruction or operation guide with test suite? 

BR, Rich

Rich,

I will look into this further and update you.

Rich,

Please try this register from the J722S TRM excel sheet.

USB_VBP2AHB_WRAP_CONTROLLER_VBP_USB3_CORE_GBL_GPIPE_GUSB3PIPECTL.HstPrtCmpl[30] = 1b'1.

This feature tests the PIPE PHY compliance patterns without requiring a test fixture on the USB 3.0 cable.

This bit enables the compliance state for the SS port link. By default, it must be set to 1'b0.

In compliance lab testing, the SS port link enters compliance after failing the first polling sequence after power on. Set this bit to 0, when you run compliance tests.

The sequence for using this functionality is as follows:
 - 1. Disconnect any plugged in devices.
 - 2. Perform USBCMD.HCRST or power-on-chip reset.
 - 3. Set PORTSC.PLS=0xA.
 - 4. Set PORTSC.PP=0.
 - 5. Set GUSB3PIPECTL. HstPrtCmpl=1. This places the link into compliance state.
To advance the compliance pattern, follow this sequence [toggle the set GUSB3PIPECTL. HstPrtCmpl]:
 - 1. Set GUSB3PIPECTL.HstPrtCmpl=0.
 - 2. Set GUSB3PIPECTL.HstPrtCmpl=1. This advances the link to the next compliance pattern.
To exit from the compliance state perform USBCMD.HCRST or power-on-chip reset.

Please let me know.

Do we need to reference this E2E on TDA4?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/941445/tda4vm-usb-2-0-host-test-mode-usb-3-0-host-compliance-pattern

Hi ShreyasRao:

When we do this kind of cmd:

//Read first, it will give us 0x5.

root@ecu1270-f14ffe:~# devmem2 0x31000020
/dev/mem opened.
Memory mapped at address 0xffff80817000.
Value at address 0x31000020 (0xffff80817020): 0x5

//Write with value 0x4, it will read back as 0x5.
root@ecu1270-f14ffe:~# devmem2 0x31000020 w 0x4
/dev/mem opened.
Memory mapped at address 0xffff9d69b000.
Value at address 0x31000020 (0xffff9d69b020): 0x5
Written 0x4; readback 0x4
root@ecu1270-f14ffe:~#

So, in short, the writing Reg is not working to cause the USB3.0 fail testing.

Any other way to fix this?

BR Rio

According this E2E:

e2e.ti.com/.../5450292

-->Only USB1 along with serdes0 can be used to support USB3.0 , USB0 is used to support USB2.0.

Shreyas, 

We tried to do the register setting via devmem2 in Linux kernel on EVM with Linux SDK 10.1 wic image and we found the registers can not be modified successfully even on EVM with TI prebuild image. 

I am wondering whether these area registers need to be unlock before modifying? 

root@am67-sk:~# uname -a

Linux am67-sk 6.6.44-ti-01478-g541c20281af7-dirty #1 SMP PREEMPT Thu Nov 14 19:20:24 UTC 2024 aarch64 GNU/Linux

root@am67-sk:~# devmem 0x31000420

-sh: devmem: command not found

root@am67-sk:~# devmem2 0x31000420

/dev/mem opened.

Memory mapped at address 0xffff85c7b000.

Read at address  0x31000420 (0xffff85c7b420): 0x00000280

root@am67-sk:~# devmem2 0x31000420 w 0xFFFF

/dev/mem opened.

Memory mapped at address 0xffff8e09f000.

Read at address  0x31000420 (0xffff8e09f420): 0x00000280

Write at address 0x31000420 (0xffff8e09f420): 0x0000FFFF, readback 0x0000FFFF

root@am67-sk:~# devmem2 0x31000420 w 0xFFFFFFFF

/dev/mem opened.

Memory mapped at address 0xffff9cc4d000.

Read at address  0x31000420 (0xffff9cc4d420): 0x0000C290

Write at address 0x31000420 (0xffff9cc4d420): 0xFFFFFFFF, readback 0xFFFFFFFF

root@am67-sk:~# devmem2 0x31000420

/dev/mem opened.

Memory mapped at address 0xffffb4ec7000.

Read at address  0x31000420 (0xffffb4ec7420): 0x0000C290

root@am67-sk:~# devmem2 0x31000420 w 0x5A5A5A5A

/dev/mem opened.

Memory mapped at address 0xffffb8cd4000.

Read at address  0x31000420 (0xffffb8cd4420): 0x0000C290

Write at address 0x31000420 (0xffffb8cd4420): 0x5A5A5A5A, readback 0x5A5A5A5A

root@am67-sk:~# devmem2 0x31000420

/dev/mem opened.

Memory mapped at address 0xffff96e07000.

Read at address  0x31000420 (0xffff96e07420): 0x0000C290

root@am67-sk:~# devmem2 0x31000400

/dev/mem opened.

Memory mapped at address 0xffff8104e000.

Read at address  0x31000400 (0xffff8104e400): 0x00000000

root@am67-sk:~# devmem2 0x31000400 w 0x5A5A5A5A

/dev/mem opened.

Memory mapped at address 0xffff9cff6000.

Read at address  0x31000400 (0xffff9cff6400): 0x00000000

Write at address 0x31000400 (0xffff9cff6400): 0x5A5A5A5A, readback 0x5A5A5A5A

root@am67-sk:~# devmem2 0x31000400

/dev/mem opened.

Memory mapped at address 0xffffad73d000.

Read at address  0x31000400 (0xffffad73d400): 0x00000000

root@am67-sk:~# devmem2 0x31000020

/dev/mem opened.

Memory mapped at address 0xffff86ad5000.

Read at address  0x31000020 (0xffff86ad5020): 0x00000000

root@am67-sk:~# devmem2 0x31000020 w 0xFFFF

/dev/mem opened.

Memory mapped at address 0xffffb1328000.

Read at address  0x31000020 (0xffffb1328020): 0x00000000

Write at address 0x31000020 (0xffffb1328020): 0x0000FFFF, readback 0x0000FFFF

root@am67-sk:~# devmem2 0x31000020

/dev/mem opened.

Memory mapped at address 0xffffa6fa2000.

Read at address  0x31000020 (0xffffa6fa2020): 0x00000000

root@am67-sk:~# sudo devmem2 0x31000020

/dev/mem opened.

Memory mapped at address 0xffffa56c5000.

Read at address  0x31000020 (0xffffa56c5020): 0x00000000

root@am67-sk:~# sudo devmem2 0x31000020 w 0xFFFFFFF

/dev/mem opened.

Memory mapped at address 0xffffac4c4000.

Read at address  0x31000020 (0xffffac4c4020): 0x00000000

Write at address 0x31000020 (0xffffac4c4020): 0x0FFFFFFF, readback 0x0FFFFFFF

root@am67-sk:~# sudo devmem2 0x31000020

/dev/mem opened.

Memory mapped at address 0xffffa3ff6000.

Read at address  0x31000020 (0xffffa3ff6020): 0x00000000

root@am67-sk:~#

Boot and try another test

root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff89277000.
Read at address 0x31000420 (0xffff89277420): 0x00000280
root@am67-sk:~# devmem2 0x31000420 w 0x0000FFFF
/dev/mem opened.
Memory mapped at address 0xffffbbe16000.
Read at address 0x31000420 (0xffffbbe16420): 0x00000280
Write at address 0x31000420 (0xffffbbe16420): 0x0000FFFF, readback 0x0000FFFF
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff92d7a000.
Read at address 0x31000420 (0xffff92d7a420): 0x0000C290
root@am67-sk:~# devmem2 0x31000420 w 0x00000000
/dev/mem opened.
Memory mapped at address 0xffffb1fd2000.
Read at address 0x31000420 (0xffffb1fd2420): 0x0000C290
Write at address 0x31000420 (0xffffb1fd2420): 0x00000000, readback 0x00000000
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff8edbc000.
Read at address 0x31000420 (0xffff8edbc420): 0x0000C290
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff80e59000.
Read at address 0x31000420 (0xffff80e59420): 0x0000C290
root@am67-sk:~# devmem2 0x31000420 w 0x0000
/dev/mem opened.
Memory mapped at address 0xffff8a61c000.
Read at address 0x31000420 (0xffff8a61c420): 0x0000C290
Write at address 0x31000420 (0xffff8a61c420): 0x00000000, readback 0x00000000
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff9737d000.
Read at address 0x31000420 (0xffff9737d420): 0x0000C290
root@am67-sk:~# devmem2 0x31000400
/dev/mem opened.
Memory mapped at address 0xffff86380000.
Read at address 0x31000400 (0xffff86380400): 0x00000000

BR, Rich

Shreyas, 

Have you back to office now? 

Here I would like to add a supplement which I originally use wrong value due to typo, then I correct it as you posted in this post. I found other vendor also use same commends and same setting value. 

devmem2 0x31000420 w 0xA0010340   ==>  devmem2 0x31000420 w 0x0A010340

However, it still not working.

Then we see the post for TDA4 which Rio posted.

We test the register setting in lab and found the registers cannot be modified as the setting value so we test on AM67x SK EVM and found the registers setting problem. 

Is there a unlock process which we need to do before modify 0x31000420? 

Shreyas, 

Besides, may you direct me to the excel sheet? Where to find it? 

I have a excel probably from you but I don't find the register you show here. 

What's the register address? Which worksheet number? 

Please try this register from the J722S TRM excel sheet.

USB_VBP2AHB_WRAP_CONTROLLER_VBP_USB3_CORE_GBL_GPIPE_GUSB3PIPECTL.HstPrtCmpl[30] = 1b'1.

BR, Rich

Kyle, 

Thanks, I found the register for USB2SS_GBL_GPIPE_GUSB3PIPECTL. It is 0x3100C2C0. 

The read out value is 0x010E0002. 

I can set bit 30 to 1 by using devmem2 0x3100C2C0 w 0x410E0002. 

However, I have problem to set LWS and PLS. 

I tried to use "Perform USBCMD.HCRST or power-on-chip reset." 

run devmem2 0x31000020 w 0x2 to reset USB but found registers values in USB are not changed back to default. 

Is there any limitation or precondition to set LWS and PLS? 

BR, Rich

root@am67-sk:~# root
-sh: root: command not found
root@am67-sk:~#
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff8b279000.
Read at address 0x31000420 (0xffff8b279420): 0x00000280
root@am67-sk:~# devmem2 0x3100C2C0
/dev/mem opened.
Memory mapped at address 0xffffb33dc000.
Read at address 0x3100C2C0 (0xffffb33dc2c0): 0x010E0002
root@am67-sk:~# devmem2 0x3100C2C0 w 0x410E0002
/dev/mem opened.
Memory mapped at address 0xffffb5d89000.
Read at address 0x3100C2C0 (0xffffb5d892c0): 0x010E0002
Write at address 0x3100C2C0 (0xffffb5d892c0): 0x410E0002, readback 0x410E0002
root@am67-sk:~# devmem2 0x3100C2C0
/dev/mem opened.
Memory mapped at address 0xffff9d2f5000.
Read at address 0x3100C2C0 (0xffff9d2f52c0): 0x410E0002
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff89288000.
Read at address 0x31000420 (0xffff89288420): 0x00000280
root@am67-sk:~# devmem2 0x31000420 w 0x00000340
/dev/mem opened.
Memory mapped at address 0xffffb544f000.
Read at address 0x31000420 (0xffffb544f420): 0x00000280
Write at address 0x31000420 (0xffffb544f420): 0x00000340, readback 0x00000340
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffffa79e4000.
Read at address 0x31000420 (0xffffa79e4420): 0x00000280

root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff97912000.
Read at address 0x31000420 (0xffff97912420): 0x00000280
root@am67-sk:~# devmem2 0x31000020
/dev/mem opened.
Memory mapped at address 0xffff98b82000.
Read at address 0x31000020 (0xffff98b82020): 0x00000000
root@am67-sk:~# devmem2 0x3100C2C0
/dev/mem opened.
Memory mapped at address 0xffffb2e6f000.
Read at address 0x3100C2C0 (0xffffb2e6f2c0): 0x010E0002
root@am67-sk:~#
root@am67-sk:~# devmem2 0x31000020 w 0x2
/dev/mem opened.
Memory mapped at address 0xffffbe170000.
Read at address 0x31000020 (0xffffbe170020): 0x00000000
Write at address 0x31000020 (0xffffbe170020): 0x00000002, readback 0x00000002
root@am67-sk:~# devmem2 0x31000020
/dev/mem opened.
Memory mapped at address 0xffff970a6000.
Read at address 0x31000020 (0xffff970a6020): 0x00000000
root@am67-sk:~# devmem2 0x3100C2C0
/dev/mem opened.
Memory mapped at address 0xffffb1115000.
Read at address 0x3100C2C0 (0xffffb11152c0): 0x010E0002
root@am67-sk:~# devmem2 0x31000420
/dev/mem opened.
Memory mapped at address 0xffff965ee000.
Read at address 0x31000420 (0xffff965ee420): 0x00000280
root@am67-sk:~#

Hi Rich,

One quick question why we are modifying register usb0 register's? USB3 is supported using USB1.

Regards
Diwakar

Diwakar, 

This is what I were curious on the register excel table. 

That's the instructions from this e2e thread. 

BR, Rich

Diwakar, 

There is a old e2e thread indicates the test commend

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/941445/tda4vm-usb-2-0-host-test-mode-usb-3-0-host-compliance-pattern

I check the Linux kernel on AM67x EVM and found there are two ports, I am wondering whether the port mapping to USB0 and USB1 or SERDES0 or SERDES1?

Which port is USB3.0?  

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port01/portsc   

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port02/portsc    

Secondary, I am wondering whether USB3 test will use USB2 signals? Can USB3 be tested directly without USB2 connection? 

The reason why for this is there is other thread claim USB3.0 can only work with USB1 but not USB0 and customer board use USB0 with USB3.0 SS. 

Is USB2.0 signal mandatory for USB3.0 compliance test? 

BR, Rich 

Hi Rich

is it possible for you to get the schematic in particular of the USB section.

Regards
Diwakar

USB3.0 would be backward compatible with USB2.0; however, USB2.0 and USB3.0 would have separate controllers within the USB subsystem.

Shreyas, 

Yes, this is why I am asking why USB3.0 can only work with USB2.0 (USB1) but not work with USB2.0 (USB0). Is this a limitation on AM67x? 

Secondary, when doing USB3.0 compliance test, will only the USB3.0 Singles waveform will be measured? Will USB 2.0 DP/DM is required for the USB3.0 compliance test? 

Customer now is using USB2.0 (USB0) combine with USB 3.0 signals to a USB3.0 host connector and it works fine in Linux to support mass storage device and the speed is 5Ghz. 

Diwakar, 

I will send the schematic to you in mail. 

BR, Rich 

Rich,

Rich Chen said:

will only the USB3.0 Singles waveform will be measured

I am not sure what you mean here by saying singles waveform measured.

USB2.0 DP/DM is not required for USB3.0. USB3.0 uses the SERDES TX/RX pins for data.

USB0 supports USB2.0 and the SERDES pins are connected to USB1 instance.

Shreyas, 

Your latest statement is what I am asking. 

USB0 supports USB2.0 and the SERDES pins are connected to USB1 instance.

On AM67x TRM, it shows USB3.0 port is binding with USB0 in the figure. 

Is there document indicates USB3.0 are connected to USB1 port only and USB0 port can only work as USB2.0?  

For the commend 

BR, Rich

Shreyas, 

For the commend to enter compliance test, why there are two ports? 

Does Port01 and Port02 mean USB0 and USB1? 

For USB3 test, is Port02 the right port to use?   

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port01/portsc   

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port02/portsc    

We can not verify this on EVM due to USB1 is connected to USB3 HUB so we cannot get the USB3 output on EVM directly. 

BR, Rich

I had talked to the IP team to confirm that there are 2 instances of USB on TDA4VEN; with USB0 supporting a single USB2p0SS only and another USB instance that supports both USB2p0 and USB3p0 and instantiated as USB1 which would be connected to the SERDES pins.

On the TI EVM, you are right, the USB1 goes through the USB_Hub, and hence cannot validate the USB3.0 of the SoC.

USB1 should be Port02.

Shreyas, 

Customer had tried both commends when USB0 + SERDES0 and USB1 (blue wire) + SERSES0. 

Not get USB test pattern on U3 interface.  

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port01/portsc   

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port02/portsc    

Could team review the commend and confirm how USB 3.0 test mode be enabled on AM67x?

Customer needs a simple way to enter test mode via UART console. 

BR, Rich

Shreyas, 

We still cannot complete USB 3.0 compliance test for AM67x. 

Is there a verified way to conduct compliance test? 

BR, Rich

Let me raise a request with the vendor to guide you on this.

If I understand correctly, so far you have the LFPS working but are unable to move to CP0 / CP1 pattern to output on the SERDES pins correct?

Shreyas, 

According to customer, LFPS will be observed no matter the DUT is connected or not. 

And Yes, after connect, the test equipment (run Test Suite) can not have AM67x USB to move to CP0/CP1 pattern on "U3 SS" pins.

BR, Rich  

Rich,

Rich Chen said:

According to customer, LFPS will be observed no matter the DUT is connected or not. 

I did not follow this statement. DUT is connected (or not) to test fixture you mean? 

Rich Chen said:

And Yes, after connect, the test equipment (run Test Suite) can not have AM67x USB to move to CP0/CP1 pattern on "U3 SS" pins.

I understood this one. No CP0/CP1 pattern outputs. 

I will reply once I hear back from the vendor.

Rich,

Here below is the response I received.

"For the USB Controller and PHY Device mode: compliance tests are enabled and supported by default. 

For the USB Controller and PHY Host mode: - Power-On SoC with no Device/Compliance Tool (e.g. scope/exerciser) connected

-Enable Compliance Mode in Host Controller 

- write USB3 PORTSC register setting the following bits:                                - PP [9]                                - LWS [16]                                - PLS [8:5] = 0xA

-Connect Compliance Tool  (e.g. scope)- from now on, Compliance Tool (e.g. scope) shall control Compliance Mode entry and switching Compliance Patterns

- It can be checked if Controller has entered Compliance mode by reading USB3 PORTSC register. If PLS is 0xA, then Controller is in Compliance Mode."

I believe that you have tried this and only see the LFPS signal but not the CP0/CP1 patterns?

Shreyas, 

Writing USB3 PORTSC is the original approach and the problem encountered was the register cannot be modified accordingly. 

The register seems not totally modifiable.

So the statement for PORTSC approach is only correct half. We tried to modify register but the register setting may not be modified successfully so the Compliance mode may not be entered. 

For this approach, please check and verify the commends on TI EVM your side and help figure out what the limitation is or it is a problem about register mapping. We had stuck here. 

For second approach, we cannot get it work either. We need one of them to be working. 

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port01/portsc   

root@am67-sk:~# echo compliance > /sys/kernel/debug/usb/xhci/xhci-hcd.7.auto/ports/port02/portsc    

BR, Rich