AM5748: USB Etherent issue, when USB host side (Windows) suspends/sleeps

Hi Paritosh,

Can you please comment if this issue is seen with the AM57xx IDK/EVM and is there a way to reproduce this on TI side to help look into this further?

Regards

Karthik

Karthik & TI Team,

I have sent offline the file “Procedure to configure USB Ethernet on AM5728 IDK.docx” to you and the team.

Please forward it as needed as you review this issue for Paritosh.

TY,

Chris

Chris, Please upload the file to this ticket.

Thanks,

Kyle

Done! (I just blotted out some sensitive company name info that's all)

-Chris

Procedure to configure USB Ethernet on AM5728 IDK blotted.docx

TEAM - ALTHOUGH THIS THREAD HAS BEEN LOCKED IT IS STILL AN OPEN ISSUE.

SINCE THE LAST POST, WE ALSO FOUND THE FOLLOWING RELATED THREAD ON THIS TOPIC:

(+) Linux/AM5748: USB-C device mode with g_ether not working - Processors forum - Processors - TI E2E support forums

ALSO WANTED TO VERIFY THAT THE VBUS SIGNAL IS BEING PROPERLY HANDLED.

PLEASE COMMENT, TI TEAM.

THANK YOU,

CHRIS

TI TEAM - ALTHOUGH THIS THREAD HAS BEEN LOCKED IT IS STILL AN OPEN ISSUE.

Since the last post, we also found reference to the following related thread on this topic:

(+) Linux/AM5748: USB-C device mode with g_ether not working - Processors forum - Processors - TI E2E support forums

We also wanted to verify that the VBUS signal is being properly handled.  We assume so from the customer side.

Regardless, please comment, TI Team as this needs to be resolved for the customer to their satisfaction.

Thank you,

Chris

Hi Chris,

Apologies for delay in response.

We followed the procedure you shared and we were able to reproduce the issue on our end. For more analysis we enumerated USB as mass storage on a windows PC but there we did not face this issue. We were able to communicate with USB after Windows woke up from sleep when USB is used as mass storage.

We are further analyzing the difference in the communication happening between the board and the PC after Windows wakes up from sleep in both the cases, will back with updates soon.

Regards,
Parth

Hi Parth,

Thank you!  Appreciate the update very much.  I've asked separately if the GE Team can also duplicate this and report their findings?  Assuming they will be able to - however it begs the question on whether they need to support other USB Class devices for their implementation or would forcing Mass Storage be a simple fix.  We assume it is not quite that simple.  Regardless, thank you for reporting that you have been able to duplicate their findings (encouraging) and will report back with further test results shortly.  Thanks again for that.

Since the thread appears UNLOCKED now, we have asked GE to review this latest post and share any additional comments they feel are appropriate.

Regards,

Chris

Hi Chris,

Chris Yorkey said:

however it begs the question on whether they need to support other USB Class devices for their implementation or would forcing Mass Storage be a simple fix

They don't need to support other USB class devices, also they don't need to force the mass storage. We are just using mass storage as a working case reference to help us understand what is the communication happening once windows wakes up from sleep. We have recorded the logs using a USB packet analyzer in the three scenarios in both the cases:

1) During enumeration
2) When windows sends suspend signal
3) When windows wakes up from sleep.

We can see that for some reason enumeration is not completed when windows wakes up in case when USB is used as ethernet. We are discussing the logs within the team. I am also sharing them here USB_logs.zip for GE team to look and analyze parallelly.

Regards,
Parth

Thanks Parth, agreed and understood.  Indeed, USB as Mass Storage Device is not a use-case for their devices.  Their devices use USB as Ethernet gadgets only.  GE understands your comments about USB as Mass Storage Device related to your steps in debugging the issue and while you do not see issue when USB is used as Mass Storage Device, you see issue when USB is used as Ethernet gadget.

I will ask the GE folks to review your latest post and link.

TY,
Chris

HI Parth, Have you had a chance to discuss the logs within the team?  I also shared them with the GE team to look and analyze in parallel.

Any further comments or guidance appreciated.

TY,

Chris

Hi Chris,

Yes, I discussed the issue with the team and just got their response some time back. They suggested that this is more of g_ether driver issue than USB driver (given that g_mass_storage works). If reproducible on mainline, we need to report this on linux-usb list for help. Also, we checked the mainline driver for g_ether with the one we are trying on(4.19). It’s a legacy driver and there were couple of cosmetic fixes & it should be reproducible on mainline most likely. We suggest linux-usb list would be a better platform to resolve this issue.

Regards,
Parth

Hi Parth,

Thanks. In an attempt to be 100% convinced this is indeed a mainline Linux issue and not TI, we'd like to confirm. How would you suggest this accomplished? Specifically list the HW platform and exact build steps you'd suggest be tried, if possible.

Thank you,

Chris

Hi Chris,

g_ether module is not a TI Owned module. So is DWC core is also Linux community owned & TI has a wrapper.

Also from If I understand correctly the mass storage enumerates fine after windows suspend/resume. So the suspicion
is towards g_ether.

I checked internally & we want to know if this works well with Linux hosts?

As far as mainline kernel testing goes:

Tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Branch: master

So following commands on your Linux host:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git checkout master

make ARCH=arm CROSS_COMPILE="GIve_the_Path" omap2plus_defconfig
make ARCH=arm CROSS_COMPILE="GIve_the_Path" zImage dtbs modules

make ARCH=arm CROSS_COMPILE="GIve_the_Path" modules_install INSTALL_MOD_PATH="PATH_TO_SD_CARD_ROOTFS"

Copy the zImage & appropriate dtb for the IDK or the AM57xx board you are testing with to the SD card.

Check if the issue is reproducible.

We strongly recommend to check on the linux-usb mailing list.

Best Regards,
Keerthy

Hi Keerthy,

We believe an engineer such as Parth, who has all the information related to different TI and open source layers of USB drivers, should ask this question in the kernel mailing list.  Moreover, GE themselves has not asked a question directly in the kernel mailing list so far.

Please advise and thank you very much.

Sincerely,
Chris

An update on this thread:

Parth has validated this usecase on the RT Linux version of the latest nightly build (based on Kernel 5.10), the issue is fixed on this version.

This will eventually be available as part of an upcoming SDK release which will be available on ti.com in 3-4 weeks.