Add USB tablet link report; disable the L4T-README drive
Tablet as USB host, Orin's stock L4T gadget as the network side: the tablet chose NCM and got 192.168.55.100. Android only routes app traffic over it once it is the default network, so the app has to bind to the Ethernet network explicitly. Mass storage is off (enable_ums=0); the config isn't a conffile, so an nvidia-l4t-init upgrade restores it and the report says how to check. The Orin's USB-C port (FUSB301, no PD) can't charge the tablet; the PD hub on hand is the practical fix. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,79 @@
|
||||
---
|
||||
type: report
|
||||
date: 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. Test whether the tablet reconnects cleanly when the hub's PD input is cut.
|
||||
Reference in New Issue
Block a user