No ADB available on newer OS releases?

brentr

Working with RVC4-Dev kit (SL3456 R4)

Shipped with OS 1.18.3. Used ADB to flash to OS 1.30.1, after which no ADB interface was available.

No a permission error. dmesg on the host shows nothing when the USB-C to the RVC4 is removed and inserted.

After reverting RVC4 back to 1.18.3, ADB became available again.

Why?

Must one configure something in the newer OS versions to enable the USB gadget interface?

OskarSonc

Hey brentr - did you folow this guide on how to use ADB?

You need oakctlinstalled. What do you get if you run this:

$ oakctl adb devices

If the device is listed, you can proceed with the following commands to open a shell on the device:

$ oakctl adb shell

Thanks,
Oskar

brentr

Sorry. I should have given more information…

When running OS 1.8.3, dmesg on my AMD64 Linux host outputs:

new SuperSpeed USB device number 9 using xhci_hcd

LPM exit latency is zeroed, disabling LPM.

New USB device found, idVendor=05c6, idProduct=901d, bcdDevice= 1.02

New USB device strings: Mfr=1, Product=2, SerialNumber=3

Product: DEV-KIT R4

Manufacturer: Luxonis

SerialNumber: 5b27bfd1

It also shows device disconnect when the USB link is pulled.

However, when running OS 2.9.2 or OS 3.0.1, no such dmesg entries are produced.

In fact, there are NO dmesg entries emitted when the USB link to the RVC4-DEV-KIT is made or broken.

It appears that the newer OS does not register the required USB gadget drivers as OS 1.8.x did.

Is there something one must do on the device to enable this?

OskarSonc

brentr - could you try out the latest Luxonis OS RVC4 1.31.2?

Thanks,
Oskar

brentr

No change with OS RVC4 1.31.2

I can get a shell on the DevKit via ssh.

Can you suggest some commands I might run there to diagnose this failure?

What is the name of the kernel module that supports USB gadget access?

Can you duplicate the problem there? (ADB via USB works on v1.18.3, does not on latest)

OskarSonc

Hey @brentr - sorry for the wait.
The dev team said this:

We were not able to reproduce this internally on recent OS versions, so the next thing I would try is a full flash of the latest OS using oakctl device flash, just as a sanity check. You may need to power-cycle the device and hold the usb_boot button to force it into QDL mode first.

Before flashing, could you try these debug steps over SSH and check what your host sees in lsusb:

reboot bootloader

This should reboot the device into fastboot mode. Please check whether the host sees it there.

reboot edl

This should reboot the device into EDL/QDL mode. Please check whether the host sees it there.

One more thing worth trying is to blacklist the tps6598x driver, then power-cycle the device and check whether USB starts working in at least one USB-C orientation.

Thanks,
Oskar

brentr

I skipped right to blacklisting tps6598x because that was what seemed most plausible to me.

It worked. After rebooting without the tps6598x module, the board enumerates on host's USB bus. oakctl adb shell works as well, as does adb shell.

So, what is going on here?

Why does the TI power delivery controller driver interfere with registration as a USB gadget?

OskarSonc

brentr - That is very helpful, thanks.
This suggests the default TPS firmware works correctly on your board, but our override TPS firmware does not. That is not expected.

We will try to reproduce this on one of our dev kits to understand exactly what is happening.

Could you share your exact flow so we can investigate this faster/easier?

Thanks,
Oskar