Files

T

mikkeli 98fb9f306a Record PD power-cycling test through the hub

Three PD unplug/replug cycles each caused one full USB-C detach; the
link flapped ~3 times and settled within 5-12 s with no intervention.
Treated as a service-level requirement (yukart decision 24), not a
host fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-09 00:18:50 +09:00

5.9 KiB

Raw Blame History

type, date

type	date
report	2026-10-09

USB Link to the Tablet (Orin as USB Network Gadget)

Result

Item	State
Physical	USB-C ↔ USB-C, tablet (Redmi Pad SE 8.7 4G, Android 16) = USB host, Orin's USB-C port = USB device
Network	Orin `192.168.55.1` on `l4tbr0`, tablet gets `192.168.55.100` from the Orin's DHCP. Ping ~2.5 ms
Function used	NCM (`usb1`, ECM/NCM MAC). RNDIS (`usb0`) is offered but the tablet ignores it
Mass storage (`L4T-README`)	Disabled (`enable_ums=0`)
Tablet charging over this cable	Not possible (see below)

How it works (stock L4T, no install needed)

nv-l4t-usb-device-mode.service (package nvidia-l4t-init) builds a composite USB gadget on the USB-C port at boot. It has RNDIS + NCM network functions bridged into l4tbr0, an ACM serial console, and (stock) a mass-storage drive. When a host connects, a dedicated dhcpd hands out exactly one address. Settings live in /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-config.sh:

net_ip=192.168.55.1          net_dhcp_start=192.168.55.100  net_dhcp_end=192.168.55.100
net_ipv4_defroute_router=192.168.55.100   net_ipv4_defroute_metric=32766

The Orin also adds default via 192.168.55.100 metric 32766. This ranks below everything else, so it never takes traffic from Ethernet, WiFi or LTE.

Android routes apps over it only when it is the default network

The tablet joins the USB network, but Android only sends ordinary app traffic over its default network, and an Ethernet network without validated internet doesn't become default while WiFi or cellular is up. Tested: http://192.168.55.1:5000 (camera-webui) didn't load until the tablet's WiFi and cellular were off; then it did.

Consequence for the tablet app: request the Ethernet network explicitly (ConnectivityManager.requestNetwork with TRANSPORT_ETHERNET) and bind its sockets to it. Then the link works no matter what the tablet's internet is doing. The other option is NAT on the Orin so Android's check passes, but that would route the tablet's internet through the Orin (and in the car, through the metered povo SIM). Not chosen.

Mass storage disabled

L4T-README is NVIDIA's flashing-help drive and just causes prompts on the tablet.

D=/opt/nvidia/l4t-usb-device-mode
sudo cp -n $D/nv-l4t-usb-device-mode-config.sh $D/nv-l4t-usb-device-mode-config.sh.orig
sudo sed -i 's/^enable_ums=1$/enable_ums=0/' $D/nv-l4t-usb-device-mode-config.sh
sudo systemctl restart nv-l4t-usb-device-mode     # link drops for a few seconds
ls /sys/kernel/config/usb_gadget/l4t/configs/*/   # acm.GS0, ncm.usb0, rndis.usb0. No mass_storage

⚠ The file is not a dpkg conffile, so an nvidia-l4t-init upgrade silently restores enable_ums=1. The only effect is that the drive comes back. After a JetPack/L4T upgrade, check grep ^enable_ums $D/nv-l4t-usb-device-mode-config.sh and re-apply. (dpkg-divert was rejected: it would also hide upstream changes to the file's format, which fails worse than a returning drive.)

RNDIS is left enabled. It's unused but harmless; enable_rndis=0 would remove it the same way.

Charging the tablet

With one port on the tablet, the data cable to the Orin is also its only charging path, and the Orin doesn't charge it.

The Orin can't be the charger on this port, whatever the network protocol. RNDIS vs NCM is irrelevant; power is separate from data:

In USB-C, data role (host/device) and power role (source/sink) are negotiated separately. "Tablet is host but gets charged" is normal, but it needs a power source that negotiates USB Power Delivery.
The Orin's USB-C port controller is a FUSB301. It only detects attachment and orientation, has no PD, and is wired as the flashing/device port. The kernel registers no USB-C port or PD device (/sys/class/typec is empty, there is no usb_power_delivery class). So the port can't offer charging power to the tablet.

Options:

Option	Charging	Notes
PD hub with one data port (on hand)	Full PD from the car charger, through to the tablet	Tablet → hub's USB-C host/PD port, charger → hub's PD-in, Orin USB-C → hub's data port. Same gadget/NCM setup, nothing changes on the Orin. Some hubs briefly re-enumerate when PD power appears or disappears (ignition), so the app should reconnect
Reverse roles: Orin USB-A host + tablet USB tethering	~4.5 W at most (5 V, USB-A)	Tablet becomes the router, tethering has to be enabled by hand on Android, and it needs `never-default` on the Orin so the Orin's traffic doesn't leave via the tablet

The PD hub is the practical choice, and it's now in use.

PD power cycling through the hub (tested 2026-10-09)

Setup: tablet → hub (USB-C host/PD), car-style charger → hub PD-in, Orin USB-C → hub data port. Three PD unplug/replug cycles while pinging the tablet every 0.5 s:

Cycle	USB-C detach (Orin)	Link stable again	Ping lost
1	00:14:29.3	00:14:36.1	3.1 s + 1.5 s
2	00:14:38.5	00:14:43.6	3.1 s + 1.5 s
3	00:14:51.4	00:15:02.0	11.8 s

Each cycle caused exactly one full detach (fusb301_detach), not one per transition. The hub resets its data port on one of the two PD edges; which one can't be seen from the Orin side.
Each detach follows the same pattern: re-attach after about 0.5 s, then the l4tbr0 bridge ports flap about three times over 5–10 s (the tablet re-creating its USB network) before settling.
Recovery is automatic every time: the same DHCP lease, normal ping (~3 ms) afterwards. Nothing needs fixing on the Orin.

Consequence: in the car, expect a link outage of up to about 12 s at every ignition change. That is a requirement for the services (failure detection and redelivery; project-yukart ARCHITECTURE decision 24), not something to fix in the host setup.

5.9 KiB Raw Blame History Unescape Escape