ARM64 – Pi 4 USB Problems – And a Messy Fix..
After some delay, I finally had a ‘good’ cooling solution for my 8GB Pi4, and resumed testing..
The last Kernel version I had running on it was 5.9-rc4, and everything seemed to be working OK (including 8GB of memory recognised).
I then updated to 5.11.18, and found that none of the USB ports worked:
# dmesg |grep usb
[ 0.061522] usbcore: registered new interface driver usbfs
[ 0.061571] usbcore: registered new interface driver hub
[ 0.061619] usbcore: registered new device driver usb
[ 0.061770] usb_phy_generic phy: supply vcc not found, using dummy regulator
[ 2.405204] usbcore: registered new interface driver usb-storage
[ 2.444718] usbcore: registered new interface driver usbhid
[ 2.449078] usbhid: USB HID core driver
[ 2.967797] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 3.103999] usb 1-1: device descriptor read/64, error -71
[ 3.343985] usb 1-1: device descriptor read/64, error -71
[ 3.587805] usb 1-1: new high-speed USB device number 3 using xhci_hcd
[ 3.719992] usb 1-1: device descriptor read/64, error -71
[ 3.959983] usb 1-1: device descriptor read/64, error -71
[ 4.071910] usb usb1-port1: attempt power cycle
[ 4.727810] usb 1-1: new high-speed USB device number 4 using xhci_hcd
[ 5.763798] usb 1-1: device not accepting address 4, error -22
[ 5.899777] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[ 6.335782] usb 1-1: device not accepting address 5, error -22
[ 6.340571] usb usb1-port1: unable to enumerate USB device
More research showed that the USB/PCI issues had – supposedly – been fixed in 2020, and I then carried out a test booting from the official Fedora 34 kernel – 5.11.17-300.fc34.aarch64 – and this detected the USB ports correctly, but (as usual) failed to find the rootfs.. I then extracted the Fedora/RedHat kernel patchset (patch-5.11-redhat.patch) from the source rpm kernel-5.11.17-300.fc34.src.rpm and applied this to the kernel.org 5.11.18, and this detected USB correctly again..
Further tests produced the following good/bad results:
5.9.0 – USB good
5.9.16 – USB good
5.10.34 – USB bad
5.11.18 – USB bad
5.11.17 Fedora34 – USB good (but fails to find rootfs..)
5.11.18 + Fedora/RedHat patchset – USB good.
5.12.1 – USB bad
5.12.1 + RedHat (koji dev) patch – USB bad..
5.13-rc1 – USB bad.
The VIA USB connection on the Pi4 is via PCIe, and this may (again?) be the source of the problem:
Good system:
# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01)
Bad system:
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 10)
01:00.0 USB controller: VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller (rev 01)
In summary, it would appear that USB on an 8GB Pi4 was OK with kernel 5.9.x, but broken after 5.10.x, and there is a ‘messy’ fix for 5.11.18 by applying the Fedora 5.11.17 patchset. More testing needed, including – possibly – repeating them with a 4GB Pi4?
Robert Gadsdon. May 11th 2021.
I found the block in the patch patch-5.11-redhat.patch which makes this work:
— drivers/pci/controller/pcie-brcmstb.c.org 2021-08-31 15:07:02.055978191 +0200
+++ drivers/pci/controller/pcie-brcmstb.c 2021-08-31 15:07:31.500193106 +0200
@@ -871,20 +871,21 @@
struct resource_entry *entry;
bool ssc_good = false;
struct resource *res;
int num_out_wins = 0;
u16 nlw, cls, lnksta;
int i, ret, memc;
u32 tmp, burst, aspm_support;
/* Reset the bridge */
pcie->bridge_sw_init_set(pcie, 1);
+ pcie->perst_set(pcie, 1);
usleep_range(100, 200);
/* Take the bridge out of reset */
pcie->bridge_sw_init_set(pcie, 0);
tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
tmp &= ~PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK;
writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
/* Wait for SerDes to be stable */
usleep_range(100, 200);
… if you want in 5.13.13 also 4 CPUs instead of one:
— arch/arm/boot/dts/bcm2837.dtsi.org 2021-08-30 03:48:45.998742555 +0200
+++ arch/arm/boot/dts/bcm2837.dtsi 2021-08-30 03:52:43.390480156 +0200
@@ -31,54 +31,54 @@
interrupts = , // PHYS_SECURE_PPI
, // PHYS_NONSECURE_PPI
, // VIRT_PPI
; // HYP_PPI
always-on;
};
cpus: cpus {
#address-cells = ;
#size-cells = ;
– enable-method = “brcm,bcm2836-smp”; // for ARM 32-bit
cpu0: cpu@0 {
device_type = “cpu”;
compatible = “arm,cortex-a53”;
reg = ;
– enable-method = “spin-table”;
– cpu-release-addr = ;
+ enable-method = “psci”;
};
cpu1: cpu@1 {
device_type = “cpu”;
compatible = “arm,cortex-a53”;
reg = ;
– enable-method = “spin-table”;
– cpu-release-addr = ;
+ enable-method = “psci”;
};
cpu2: cpu@2 {
device_type = “cpu”;
compatible = “arm,cortex-a53”;
reg = ;
– enable-method = “spin-table”;
– cpu-release-addr = ;
+ enable-method = “psci”;
};
cpu3: cpu@3 {
device_type = “cpu”;
compatible = “arm,cortex-a53”;
reg = ;
– enable-method = “spin-table”;
– cpu-release-addr = ;
+ enable-method = “psci”;
};
};
+
+ psci {
+ compatible = “arm,psci-1.0”, “arm,psci-0.2”;
+ method = “smc”;
+ };
};
/* Make the BCM2835-style global interrupt controller be a child of the
* CPU-local interrupt controller.
*/
&intc {
compatible = “brcm,bcm2836-armctrl-ic”;
reg = ;
interrupt-parent = ;
interrupts = ;
@@ -86,10 +86,11 @@
&cpu_thermal {
coefficients = ;
};
/* enable thermal sensor with the correct compatible property set */
&thermal {
compatible = “brcm,bcm2837-thermal”;
status = “okay”;
};
+
I found that with 5.14-rc the USB3 connection worked OK, but the USB2 did not.. I did find that the ‘latest’ version of U-Boot fixed this.. (article to come..)
RG.