Custom kernel, slow USB device enumeration on boot

[bchristo]

Hello, I’m having an issue when generating a custom kernel. The generated kernel boots and everything works, however
if I have a USB device connected, it takes 60 seconds after boot to detect it, and then this message in bold shows up:

[ 14.399437] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 17.206049] random: crng init done
[ 17.211904] random: 3 urandom warning(s) missed due to ratelimiting
[ 64.489011] tegra-xusb 70090000.xusb: cannot find firmware…retry after 1 second
[ 65.519995] tegra-xusb 70090000.xusb: Firmware timestamp: 2019-10-17 15:58:59 UTC, Version: 50.25 release
[ 65.532070] tegra-xusb 70090000.xusb: xHCI Host Controller
[ 65.540084] tegra-xusb 70090000.xusb: new USB bus registered, assigned bus number 1
[ 65.550984] tegra-xusb 70090000.xusb: hcc params 0x0184f525 hci version 0x100 quirks 0x00050010
[ 65.562255] tegra-xusb 70090000.xusb: irq 61, io mem 0x70090000
[ 65.570799] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

This doesn’t happen in the official Nano image, am I missing some steps when generating this custom kernel?

Thanks

[WayneWWW]

Please follow the guide in this page and share the information. Especially what you’ve changed to the kernel.

Tips for debug jetson platforms

Hi, I would like to share some tips for someone who has problem and wants to file a topic for their issues. This thread will guide you what are necessary files/information you should prepare when you file a topic. Also, such rule is not limited to jetson nano. You could follow this for every jetson forum. 1. Please share the detailed info of your board You should tell what kind of carrier board you are using. If that carrier board is not a NVIDIA Development kits (devkit), we usually say …

[bchristo]

Wayne, here is the requested data:

1 - P3448 (Jetson Nano Developer Kit)

2 - Jetson-210_Linux_R32.4.4_aarch64

5 - Just boot the device with any USB device plugged in
[syslog.txt|attachment]

Full Syslog:
(upload://kVTgOsdsHWAN5smkbjrCUrmsP3J.txt) (53.4 KB)

[WayneWWW]

What did you add to this “custom kernel”?

[bchristo]

OpenWRT.

[WayneWWW]

Could you share steps? We don’t know how you turn on it.

[bchristo]

I just write the nano image to the SDcard, put the SDcard on the Nano, and with any USB device connected to the Nano, I connect the power cable to the Nano.

[WayneWWW]

I mean how you turn on openWRT in kernel. Also, your log is not able to read.

[bchristo]

I’ve compiled the OpenWRT project using your kernel as an external tree.

Please try again:

syslog.txt (53.4 KB)

[WayneWWW]

Please learn to share more about your issue.

I want to know what is your step to reproduce this issue.

We need a clear step from the beginning to the end.

What did you modify in kernel?
What command do you use to build kernel?
Where do you put your new kernel?
What command do you use to flash your new driver package to the device?

Please do not just say you compiled OpenWRT using our kernel and nothing else. We really don’t know how you achieve that and couldn’t find where the problem is by just such little info.

[bchristo]

I can’t share the code since it contains lots of modifications and my client probably wouldn’t approve it, I was hoping you could help me debug the cause of the 60 second delay when detecting the USB devices at boot. Do you know of any similar issues that you could point me to?

[WayneWWW]

No, we don’t know.

The kernel should be public source, there is no reason to say it is not able to release.

[WayneWWW]

Also, I don’t think purely modifying the kernel would hit this problem. Based on the info you shared so far, I can only say we cannot debug this issue. No enough information.

Please share the log from uart too.

[linuxdev]

This is rather vague, and perhaps not too useful, but if the device eventually works, then there is a possibility that it is the enumeration which is slow. However, the log shows fast enumeration. What I do see is just after USB, and might be the real delay:

[  316.387134] EXT4-fs (mmcblk0p1): error count since last fsck: 3
[  316.395451] EXT4-fs (mmcblk0p1): initial error at time 1619975475: ext4_journal_check_start:61
[  316.406557] EXT4-fs (mmcblk0p1): last error at time 1619975489: ext4_remount:5226

Your filesystem seems to be unmounted uncleanly, and may take significant time to correct for filesystem errors. Is the system with OpenWRT truly being shut down cleanly?

[bchristo]

Yes, the device works after a minute. The filesystem was dirty, but after a fsck the problem persists as you can see.
Do you know what could cause a delay in the device enumeration?

syslog.txt (53.1 KB)

[WayneWWW]

Please share the log from uart serial console. It has no help to share similar syslog again.

If you really want other to check this issue, share what I said from previous comment…

[WayneWWW]

If you really cannot share the code, then just remove those codes and see if the issue is still there.

There are lots of method to approach your scenario without revealing the code. Just try to share those info as possible.

Though it still makes no sense to not reveal your modified kernel. I can understand if you don’t want to reveal your usespace side code. But it makes no sense for kernel parts.

[bchristo]

Here’s the UART log.

minicom.cap (75.1 KB)

[WayneWWW]

Hi,

Please just share “what did you add” to the kernel config instead of just giving out a whole file and ask others to check them line by line.

[bchristo]

Ok, I started with the basic nano image, then replaced the rootfs with the one generated by OpenWRT, and then copied the firmware from the original Nano image partition to /lib/firmware.
But the problem appears to be that the firmware direct load is failing for some reason, and after 60 seconds it works.
Is there anything else that I have to change in the other partitions?