RPi 4 USB-C socket as host

[trejan]

This is probably useless for the vast majority of people.

The USB-C socket on the RPi 4 is officially meant to be device only but you can still use it as a host port if you have a USB-A to USB-C adapter. You can either use the internal XHCI controller (USB 2.0 only) by adding "otg_mode=1" or use the old DWC2 USB 2.0 OTG controller by adding "dtoverlay=dwc2,dr_mode=host" to /boot/config.txt. The XHCI controller should have better performance. You'll need to use an alternate method of powering the RPi 4 such as PoE or via the expansion header.

Plugging in an actual USB-C device may not work as the RPi 4 doesn't implement the CC1/CC2 signalling needed. A USB-A to USB-C adapter does work but you need to force it into host mode.

[andrum99]

The USB-C socket on the RPi 4 is officially meant to be device only

No its not. It officially supports both device mode and host mode, as it is the same USB controller on the BCM283x SoC used on all previous models of Raspberry Pi. The type A USB ports on the Pi use the new VLI controller, which was added in addition to the USB controller built into the SoC.

[trejan]

No its not. It officially supports both device mode and host mode, as it is the same USB controller on the BCM283x SoC used on all previous models of Raspberry Pi. The type A USB ports on the Pi use the new VLI controller, which was added in addition to the USB controller built into the SoC.

Yes. It is. I know it has the same DWC controller as before and it does do both hence the dtoverlay line to force it into host mode. However, the documentation specifically says it is meant to be used in the USB device mode only.

https://www.raspberrypi.org/documentati ... erview_pi4

The OTG hardware present on previous models of Pi is still available and it has moved to a single connection on the USB-C port. The OTG hardware is intended to be used in device-only mode on Pi 4.

It doesn't automatically switch between host and device mode so you have to add the dtoverlay line if you want host mode.

[drgeoff]

It that is what the documentation is really meant to say it is badly written.

"The OTG hardware is intended to be used in device-only mode on Pi 4." would be "The OTG hardware is intended to be used only in device mode on Pi 4."

But if that was what the documentation should say then the means to operate in host mode (via the dtoverlay) would not be provided.

[plugwash]

As I understand it the issue is that the USB C detection wiring is not set up for dual role, this means two things.

1. You have to force the mode to use the port in host mode because the Pi can't detect that what is plugged in is a device and not a host.
2. You may have problems if you use a C to C cable because the device may think it's connected to another device. Using a C plug to A socket adapter along with an A plug to C plug lead should avoid this.

[trejan]

What plugwash said.

It can't automatically switch between host and device mode on a RPi 4 because of the USB-C connector. USB OTG determines which end is what role by the ID pin in a micro USB connector but that doesn't exist in a USB-C connector. USB-C Dual Role does the detection with the CC1/CC2 pins and toggles those between pull up and pull down. The RPi 4 doesn't implement any of that.

If you wanted to make the USB-C socket into a dual role port then you'll need to add something like a TI TUSB320 which implements all of the CC signalling internally and generates an ID output for the USB OTG controller. It'll use up valuable PCB space and be an additional cost for a feature that most people will never use.

I'll update my initial post to say this is with a USB-A to USB-C adapter. YMMV for everything else.

But if that was what the documentation should say then the means to operate in host mode (via the dtoverlay) would not be provided.

That overlay was added back in 2016 so it isn't something specific to the RPi 4.

[jdb]

Can someone try the config.txt parameter "otg_mode=1"?

This swaps the DWC controller out for an xhci host-only controller on the USBC USB2.0 pins. No guarantees about which configurations this will work with, though.

It that is what the documentation is really meant to say it is badly written.

"The OTG hardware is intended to be used in device-only mode on Pi 4." would be "The OTG hardware is intended to be used only in device mode on Pi 4."

But if that was what the documentation should say then the means to operate in host mode (via the dtoverlay) would not be provided.

As plugwash said, the OTG ID pin is not connected to anything inside the USBC port so device operation is assumed. There is no hardware mechanism available to say that the port *should* operate in host mode. Cable hacks or forcing via devicetree will work, but is not a generally supported use case.

[trejan]

Can someone try the config.txt parameter "otg_mode=1"?

This swaps the DWC controller out for an xhci host-only controller on the USBC USB2.0 pins. No guarantees about which configurations this will work with, though.

Didn't work for me. The XHCI controller does appear but doesn't see my device. dmesg doesn't say anything.

I was wondering how to enable the internal XHCI controller in the devicetree. Changing the status from disabled to okay didn't do anything when I tried it the other day.

[hippy]

The USB-C socket on the RPi 4 is officially meant to be device only

No its not. It officially supports both device mode and host mode, as it is the same USB controller on the BCM283x SoC used on all previous models of Raspberry Pi.

The best way to describe the situation is probably "the Pi 4B USB-C socket allows it to be a USB-C device or limited capability USB-C host but the Pi 4B is only officially a USB-C device due to its hardware configuration".

This was a timely topic as I was this morning buying bits to build a USB-C to USB-A socket 'OTG cable' - It answers the questions I had.

[andrum99]

No its not. It officially supports both device mode and host mode, as it is the same USB controller on the BCM283x SoC used on all previous models of Raspberry Pi. The type A USB ports on the Pi use the new VLI controller, which was added in addition to the USB controller built into the SoC.

Yes. It is. I know it has the same DWC controller as before and it does do both hence the dtoverlay line to force it into host mode. However, the documentation specifically says it is meant to be used in the USB device mode only.

https://www.raspberrypi.org/documentati ... erview_pi4

The OTG hardware present on previous models of Pi is still available and it has moved to a single connection on the USB-C port. The OTG hardware is intended to be used in device-only mode on Pi 4.

It doesn't automatically switch between host and device mode so you have to add the dtoverlay line if you want host mode.

I didn't know the documentation said that. I was going on what James Hughes posted on one of the forums.

[fury]

Is it possible to boot up with it set to host by default but have a way to switch into peripheral / gadget mode at runtime? e.g. temporarily enable g_serial or g_ether or something like that for a makeshift debug port without needing SSH or digging into the IO header UART

I'm planning on using it in an automated test system and it would be nice to be able to hit a button on my UI to make the normally host port a gadget port for plugging into my laptop without changing config.txt and rebooting

[sjevtic]

Is it possible to boot up with it set to host by default but have a way to switch into peripheral / gadget mode at runtime? e.g. temporarily enable g_serial or g_ether or something like that for a makeshift debug port without needing SSH or digging into the IO header UART

I'm planning on using it in an automated test system and it would be nice to be able to hit a button on my UI to make the normally host port a gadget port for plugging into my laptop without changing config.txt and rebooting

As long as you are not using it for power input, the USB-C port works wonderfully as both a device and host port. If you want the USB port to boot up in host mode, put this in config.txt:

Code: Select all

dtoverlay=dwc2,dr_mode=host

Regardless of whether or not you have done this, you can switch into device mode in the shell as root:

Code: Select all

modprobe -r dwc2 && dtoverlay dwc2 dr_mode=peripheral && modprobe dwc2

At this point, you can load the gadget of your choice. When you are done, remove, the gadget driver, and you can switch back to host mode:

Code: Select all

modprobe -r dwc2 && dtoverlay dwc2 dr_mode=host && modprobe dwc2

In short, all of this is possible because of the excellent dtoverlay utility provided by Raspberry Pi. It doesn't do anything magical; you could instead yourself manage the installation of the overlay via configfs (i.e., in /sys/kernel/config/device-tree/overlays), but it sure is convenient! Note also the following:

1. dr_mode is checked only once when dwc2 is loaded so the remove/dtoverlay change/insert pattern is necessary for correct behavior.
2. modprobe returns success both when asked to remove an unloaded module as well as when asked to load an already loaded module.
3. When the dwc2 overlay first appears, or appears after having been previously removed, it seems that dwc2 is automatically loaded.
4. The default value of dr_mode is otg. On rpi4, where the OTG pin isn't connected to anything useful, so this has the effect of being device mode.

The scheme proposed above has the implication of loading the dwc2 overlay once for every role switch. If that is undesirable, for example because you will be doing many role switches, you can always remove the overlay before reinserting it again:

Code: Select all

dtoverlay -r dwc2

Interestingly, every time the overlay is inserted, dmesg shows the following:

Code: Select all

OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/compatible
OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/dr_mode
OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/g-np-tx-fifo-size
OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/g-rx-fifo-size
OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/g-tx-fifo-size
OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/usb@7e980000/status

I have not done any investigation to evaluate the impact of either repeated installation of the overlay or the remove/insert paradigm. Perhaps a device tree expert can weigh in on the relative merits of these two approaches.

[elee]

Hello,

I would also like to switch the direction of the pi 4 OTG port (as part of a test setup).
Ideally in host mode it could read/write a USB drive, and in device mode it would appear as 3 peripherals (usb-uart, usb-drive, usb-ethernet)

The command to switch the OTG port to host mode worked when I connected a keyboard.

Code: Select all

modprobe -r dwc2 && dtoverlay dwc2 dr_mode=host && modprobe dwc2

And when I connected a USB drive I could mount it and see the directories/files.
But reading the files produced mangled contents (non-ascii characters).
I could write a file, but when I tried reading that file on a macbook it was also mangled.

The same USB drive worked fine when plugged into the "regular" usb ports on the rpi4, so I guessing some driver is not getting loaded, or some configuration is missing?

Any hints/suggestions would be welcome.

Regards,
Eric

[kevinthefixer]

Hi guys, I confess I'm over my head here in this thread. But I think it would be worth your while to look here:
viewtopic.php?f=28&t=267331
While you're getting mangled files, we are getting "spurious spikes" on our oscilloscopes. I can't help but think the two are related. I have another puzzling point to add: my Hantek 6022BL 'scope does not show this behavior, it has a perfectly clean trace with only the expected RFI noise, and very little of that. It's also connected through the usb-c port as described in the other thread. If anyone can shed a bit of light on this I'd appreciate it! PM me if you need me to experiment or???

Thanks, Kevin

[jj_0]

Hello,

I would also like to switch the direction of the pi 4 OTG port (as part of a test setup).
Ideally in host mode it could read/write a USB drive, and in device mode it would appear as 3 peripherals (usb-uart, usb-drive, usb-ethernet)

The command to switch the OTG port to host mode worked when I connected a keyboard.

Code: Select all

modprobe -r dwc2 && dtoverlay dwc2 dr_mode=host && modprobe dwc2

And when I connected a USB drive I could mount it and see the directories/files.
But reading the files produced mangled contents (non-ascii characters).
I could write a file, but when I tried reading that file on a macbook it was also mangled.

The same USB drive worked fine when plugged into the "regular" usb ports on the rpi4, so I guessing some driver is not getting loaded, or some configuration is missing?

Any hints/suggestions would be welcome.

Regards,
Eric

I tested this with a USB-drive as well and have the same experience, even with a powered USB hub (or actually a powered USB power meter). So it does not seem to be power-related.

I put some test files on the USB-drive and tested from the normal USB2 port:

Code: Select all

root@rpi4b-4:/home/pi# ls -lisa /mnt
total 4664
 2    4 drwx------  2 pi   pi      4096 Jun 13 15:10 .
 2    4 drwxr-xr-x 22 root root    4096 Jun 13 14:36 ..
12  188 -rw-r--r--  1 root root  191442 Jun 13 14:23 test-file-from-laptop.txt
16   28 -rw-r--r--  1 root root   27576 Jun 13 14:54 test-file-from-rpi4.txt
15 4440 -rw-r--r--  1 root root 4543636 Jun 13 15:04 THEC64-Full-size-User-Manual-Dec-2019-EN.pdf

Then checksummed them:

Code: Select all

root@rpi4b-4:/home/pi# md5sum /mnt/*
dd504035434432c1094ae84385f008c1  /mnt/test-file-from-laptop.txt
aa95bbcdafaa668968519520b29f5a0e  /mnt/test-file-from-rpi4.txt
08c2766c98e6006c47b7937f0569755c  /mnt/THEC64-Full-size-User-Manual-Dec-2019-EN.pdf

And checked which blocks one of them occupied:

Code: Select all

root@rpi4b-4:/home/pi# debugfs -R "stat <15>" /dev/sda1 >which-blocks.txt
debugfs 1.44.5 (15-Dec-2018)
root@rpi4b-4:/home/pi# cat which-blocks.txt 
Inode: 15   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 552302989    Version: 0x00000000:00000001
User:     0   Group:     0   Project:     0   Size: 4543636
File ACL: 0
Links: 1   Blockcount: 8880
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
 atime: 0x5ee4cfa0:a7ef5e44 -- Sat Jun 13 15:07:44 2020
 mtime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
crtime: 0x5ee4ceda:6bcfb16c -- Sat Jun 13 15:04:26 2020
Size of extra inode fields: 32
Inode checksum: 0x3c5f49a5
EXTENTS:
(0-1109):33288-34397
root@rpi4b-4:/home/pi# 

Then unmounted, put the USB-drive in the USB-C port mounted and did the above again:

Code: Select all

root@rpi4b-4:/home/pi# ls -lisa /mnt
total 4664
 2    4 drwx------  2 pi   pi      4096 Jun 13 15:10 .
 2    4 drwxr-xr-x 22 root root    4096 Jun 13 14:36 ..
12  188 -rw-r--r--  1 root root  191442 Jun 13 14:23 test-file-from-laptop.txt
16   28 -rw-r--r--  1 root root   27576 Jun 13 14:54 test-file-from-rpi4.txt
15 4440 -rw-r--r--  1 root root 4543636 Jun 13 15:04 THEC64-Full-size-User-Manual-Dec-2019-EN.pdf
root@rpi4b-4:/home/pi# md5sum /mnt/*
7d38b23ddb73d1e28dff2cc95ce1a561  /mnt/test-file-from-laptop.txt
7a4e01a582596539e1919856b64d2ea5  /mnt/test-file-from-rpi4.txt
1838f326c5608aab214dff845a851d63  /mnt/THEC64-Full-size-User-Manual-Dec-2019-EN.pdf
root@rpi4b-4:/home/pi# debugfs -R "stat <15>" /dev/sda1 >which-blocks.txt
debugfs 1.44.5 (15-Dec-2018)
root@rpi4b-4:/home/pi# cat which-blocks.txt
Inode: 15   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 552302989    Version: 0x00000000:00000001
User:     0   Group:     0   Project:     0   Size: 4543636
File ACL: 0
Links: 1   Blockcount: 8880
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
 atime: 0x5ee4cfa0:a7ef5e44 -- Sat Jun 13 15:07:44 2020
 mtime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
crtime: 0x5ee4ceda:6bcfb16c -- Sat Jun 13 15:04:26 2020
Size of extra inode fields: 32
Inode checksum: 0x3c5f49a5
EXTENTS:
(0-1109):33288-34397

So interestingly enough the directory entries are still intact, the md5sum is different but the test file still occupies the correct blocks. So something is going wrong in reading (some) blocks.

Also, if you do a loop mount of the physical device everything seems fine:

Code: Select all

root@rpi4b-4:/home/pi# losetup -fP --show /dev/sda
/dev/loop0
root@rpi4b-4:/home/pi# mount /dev/loop0p1 /mnt
root@rpi4b-4:/home/pi# ls -lisa /mnt
total 4664
 2    4 drwx------  2 pi   pi      4096 Jun 13 15:10 .
 2    4 drwxr-xr-x 22 root root    4096 Jun 13 14:36 ..
12  188 -rw-r--r--  1 root root  191442 Jun 13 14:23 test-file-from-laptop.txt
16   28 -rw-r--r--  1 root root   27576 Jun 13 14:54 test-file-from-rpi4.txt
15 4440 -rw-r--r--  1 root root 4543636 Jun 13 15:04 THEC64-Full-size-User-Manual-Dec-2019-EN.pdf
root@rpi4b-4:/home/pi# md5sum /mnt/*
dd504035434432c1094ae84385f008c1  /mnt/test-file-from-laptop.txt
aa95bbcdafaa668968519520b29f5a0e  /mnt/test-file-from-rpi4.txt
08c2766c98e6006c47b7937f0569755c  /mnt/THEC64-Full-size-User-Manual-Dec-2019-EN.pdf
root@rpi4b-4:/home/pi# debugfs -R "stat <15>" /dev/sda1 >which-blocks.txt
debugfs 1.44.5 (15-Dec-2018)
root@rpi4b-4:/home/pi# cat which-blocks.txt 
Inode: 15   Type: regular    Mode:  0644   Flags: 0x80000
Generation: 552302989    Version: 0x00000000:00000001
User:     0   Group:     0   Project:     0   Size: 4543636
File ACL: 0
Links: 1   Blockcount: 8880
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
 atime: 0x5ee4cfa0:a7ef5e44 -- Sat Jun 13 15:07:44 2020
 mtime: 0x5ee4ceda:6fa04480 -- Sat Jun 13 15:04:26 2020
crtime: 0x5ee4ceda:6bcfb16c -- Sat Jun 13 15:04:26 2020
Size of extra inode fields: 32
Inode checksum: 0x3c5f49a5
EXTENTS:
(0-1109):33288-34397
root@rpi4b-4:/home/pi# 

'debugfs -R "cat <12>" /dev/sda1' and 'dd-ing' /dev/sda1 also seems to to work fine:

Code: Select all

# On the USB C port:
root@rpi4b-4:/home/pi# debugfs -R "cat <12>" /dev/sda1 | md5sum
debugfs 1.44.5 (15-Dec-2018)
dd504035434432c1094ae84385f008c1  -
root@rpi4b-4:/home/pi# dd if=/dev/sde1 of=sde1-dd.img bs=512M
3+1 records in
3+1 records out
2048917504 bytes (2.0 GB, 1.9 GiB) copied, 251.721 s, 8.1 MB/s
root@rpi4b-4:/home/pi# mount sde1-dd.img /mnt
root@rpi4b-4:/home/pi# ls -lisa /mnt
total 4664
 2    4 drwx------  2 pi   pi      4096 Jun 13 15:10 .
 2    4 drwxr-xr-x 22 root root    4096 Jun 13 14:36 ..
12  188 -rw-r--r--  1 root root  191442 Jun 13 14:23 test-file-from-laptop.txt
16   28 -rw-r--r--  1 root root   27576 Jun 13 14:54 test-file-from-rpi4.txt
15 4440 -rw-r--r--  1 root root 4543636 Jun 13 15:04 THEC64-Full-size-User-Manual-Dec-2019-EN.pdf
root@rpi4b-4:/home/pi# md5sum /mnt/*
dd504035434432c1094ae84385f008c1  /mnt/test-file-from-laptop.txt
aa95bbcdafaa668968519520b29f5a0e  /mnt/test-file-from-rpi4.txt
08c2766c98e6006c47b7937f0569755c  /mnt/THEC64-Full-size-User-Manual-Dec-2019-EN.pdf

So the problem doesn't appear when using 'direct access' but does appear when going via the USB Mass Storage os SCSI driver?

UPDATE: All of the above was on Linux rpi4b-4 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux

After an 'rpi-update' to 'Linux rpi4b-4 5.4.45-v7l+ #1321 SMP Wed Jun 10 17:39:20 BST 2020 armv7l GNU/Linux' however it seems to work fine:

Code: Select all

root@rpi4b-4:md5sum /mnt/*
dd504035434432c1094ae84385f008c1  test-file-from-laptop.txt
aa95bbcdafaa668968519520b29f5a0e  test-file-from-rpi4.txt
08c2766c98e6006c47b7937f0569755c  THEC64-Full-size-User-Manual-Dec-2019-EN.pdf

[trejan]

This commit semi fixes the built-in XHCI host only controller and it does detect devices now but doesn't work properly yet. USB 2.0 High Speed i.e. 480Mbps devices are only detected as USB 1.1 Full Speed i.e. 12Mbps and trying to use the device will give errors. The same device on the old DWC controller works fine.

Code: Select all

[  160.097864] usb usb3-port1: disabled by hub (EMI?), re-enabling...
[  160.097948] usb 3-1: USB disconnect, device number 2
[  161.144654] usb usb3-port1: Cannot enable. Maybe the USB cable is bad?

[cleverca22]

This commit semi fixes the built-in XHCI host only controller

my rough understanding, is that the xhci and dwc2 controllers share a synopsys usb2.0 PHY
the PHY being in the old usb power domain would explain the changes in that commit, and why the controller was basically dead in the water

i'm guessing there may be some other changes needed, to switch the PHY between 1.0 and 2.0 speeds, but isnt that normally on a per-packet basis? so the controller would have to know how to signal it to the PHY...

[ganzgustav22]

I have added

Code: Select all

dtoverlay=dwc2,dr_mode=host

to config.txt

The hub appears in dmesg kernel log:

Code: Select all

[    0.575000] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    0.575116] dwc_otg: FIQ enabled
[    0.575121] dwc_otg: NAK holdoff enabled
[    0.575126] dwc_otg: FIQ split-transaction FSM enabled
[    0.575132] Module dwc_common_port init
[    2.303401] dwc2 fe980000.usb: fe980000.usb supply vusb_d not found, using dummy regulator
[    2.303459] dwc2 fe980000.usb: fe980000.usb supply vusb_a not found, using dummy regulator
[    2.363149] dwc2 fe980000.usb: DWC OTG Controller
[    2.363168] dwc2 fe980000.usb: new USB bus registered, assigned bus number 3
[    2.363193] dwc2 fe980000.usb: irq 30, io mem 0xfe980000
[    2.363389] usb usb3: Manufacturer: Linux 5.4.51-v7l+ dwc2_hsotg

Also appears with lsusb:

Code: Select all

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M

But when plugging in something (have tried QR-Code reader, mouse, memory stick), it doesn't appear anywhere, not in dmesg kernel log nor with lsusb.

The USB-C to USB-A socket Adapter used is this one:
https://www.amazon.de/Adapter-Compatibl ... uage=en_GB

Am I doing something wrong or is it the cable?

Edit: Forgot to add, Raspberry Pi OS 2020-08-20 Lite, kernel and firmware stock.

[andrum99]

This commit semi fixes the built-in XHCI host only controller

my rough understanding, is that the xhci and dwc2 controllers share a synopsys usb2.0 PHY

I don't think that's correct - there would have been no point in Broadcom putting an XHCI controller in their chip, only to disable the capability to do USB 3.0 ("super speed").

What I do know is that, although the XHCI controller in the BCM2711 will do USB 3.0, you cannot use USB 3.0 on the Raspberry Pi 4B, since the USB 3.0 ("super speed") pins are not connected. You are therefore limited to USB 2.0 ("high speed") as a maximum.

[ejolson]

This commit semi fixes the built-in XHCI host only controller

my rough understanding, is that the xhci and dwc2 controllers share a synopsys usb2.0 PHY

I don't think that's correct - there would have been no point in Broadcom putting an XHCI controller in their chip, only to disable the capability to do USB 3.0 ("super speed").

What I do know is that, although the XHCI controller in the BCM2711 will do USB 3.0, you cannot use USB 3.0 on the Raspberry Pi 4B, since the USB 3.0 ("super speed") pins are not connected. You are therefore limited to USB 2.0 ("high speed") as a maximum.

My understanding is routing difficulties with the traces on the circuit board are the main reason only the wires for USB2 were brought to the USBC connector.

[jdb]

My understanding is routing difficulties with the traces on the circuit board are the main reason only the wires for USB2 were brought to the USBC connector.

True of the USB2 type-A plugs but not the Type-C plug. The OTG/onboard xHCI controllers are connected to a USB2.0 OTG PHY.

[cleverca22]

My understanding is routing difficulties with the traces on the circuit board are the main reason only the wires for USB2 were brought to the USBC connector.

True of the USB2 type-A plugs but not the Type-C plug. The OTG/onboard xHCI controllers are connected to a USB2.0 OTG PHY.

that would mean that the unconnected 3.0 high speed lanes, are unconnected within the silicon, and no board with the same chip could get it working?

or is there another undocumented usb PHY that could be muxed in, and nobody has mentioned it, because the usb-c isnt wired up to take adantage of it?

[jdb]

XHCI controllers are not required to have a non-zero number of USB3 ports. It's perfectly valid to have an XHCI controller that has only USB2 ports (but operating systems tend to object to this configuration). If you switch to the onboard XHCI controller on the USB-C port, Linux complains about finding a USB3 root hub that has zero ports.

[cleverca22]

XHCI controllers are not required to have a non-zero number of USB3 ports. It's perfectly valid to have an XHCI controller that has only USB2 ports (but operating systems tend to object to this configuration). If you switch to the onboard XHCI controller on the USB-C port, Linux complains about finding a USB3 root hub that has zero ports.

makes sense, ive heard about xhci being the replacement for the whole ahci/ehci/ohci mess, making it one uniform api

[Irrational_Pi]

Would someone please help me understand which direction I should set the USB-C port (device or host) so I don't end up with "mangled" files being written to my external drive?

And does it matter where in the config.txt file that I add

Code: Select all

dtoverlay=dwc2,dr_mode=host