[WRT32X-B] USB3 driver alternating logical bus

Hi,
I'm new to the forum and OpenWRT.

I have a new WRT32X-B. I installed OpenWrt 19.07.3, r11063-85e04e9f46 and am trying to get a stable extroot functionality in a partition on a Samsung Fit 128GB USB3 Key. Followed the instructions found here and was able to overlay the boot drive with the partition on the USB key.

The problem is, it only works every other reboot.

This router has two physical USB type A ports, a USB2 and a USB3. There are three logical USB busses in this device, one USB2 bus and two USB3 busses. Rebooting the router alternates attaching the USB3 device plugged into the physical USB3 port between logical Bus 02 and logical Bus 03. To be clear, each odd numbered reboot attaches the physical device to logical Bus 02, each even numbered reboot attaches the physical device to logical Bus 03.

On odd numbered reboots:
The physical USB device is linked to logical Bus 02.
The USB key name is mis-identified in the log.
/dev/sda is attached to the file system.
But the partition on the USB key is not attached to the file system at /dev/sda1.
Which means /overlay can't overlay the partition on /dev/sda1.
Thus extroot functionality does not work. :frowning:

root@OpenWrt:~# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
root@OpenWrt:~# logread | sed -n -e "/_an apprpriate regex to find the lines below_/p"
 scsi 2:0:0:0: Direct-Access     SMI      USB MEMORY BAR   1000 PQ: 0 ANSI: 5
 sd 2:0:0:0: [sda] Attached SCSI removable disk
root@OpenWrt:~# ls -als /dev/sda
     0 brw-------    1 root     root        8,   0 Jan  1  1970 /dev/sda
root@OpenWrt:~# ls -als /dev/sda1
ls: /dev/sda1: No such file or directory
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.3M      3.3M         0 100% /rom
tmpfs                   250.0M     96.0K    249.9M   0% /tmp
/dev/ubi0_1              97.8M      4.0M     89.1M   4% /overlay
overlayfs:/overlay       97.8M      4.0M     89.1M   4% /
tmpfs                   512.0K         0    512.0K   0% /dev

On even numbered reboots:
The physical USB device is linked to logical Bus 03.
The USB key name is properly identified in the log.
The partition on the USB key is attached to the file system at /dev/sda1.
/overlay is overlaid with /dev/sda1.
So, extroot functions as expected. :slightly_smiling_face:

root@OpenWrt:~# lsusb -t
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
root@OpenWrt:~# logread | sed -n -e "/_an apprpriate regex to find the lines below_/p"
 scsi 2:0:0:0: Direct-Access     Samsung  Flash Drive FIT  1100 PQ: 0 ANSI: 6
 sd 2:0:0:0: [sda] 250626566 512-byte logical blocks: (128 GB/120 GiB)
 sd 2:0:0:0: [sda] Write Protect is off
 sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
 sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2
 sd 2:0:0:0: [sda] Attached SCSI removable disk
root@OpenWrt:~# ls -als /dev/sda1
     0 brw-------    1 root     root        8,   1 Jan  1  1970 /dev/sda1
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.3M      3.3M         0 100% /rom
tmpfs                   250.0M     96.0K    249.9M   0% /tmp
/dev/sda1                31.2G     54.8M     29.6G   0% /overlay
overlayfs:/overlay       31.2G     54.8M     29.6G   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/ubi0_1              97.8M      4.0M     89.1M   4% /rwm

I have some questions.

Is this a known problem? Either with the OpenWrt xhci driver, or with the USB3 hardware on the WRT32X-B or some combination of these?
Are there any suggested workarounds to get the driver to always attach the physical key to logical Bus 03?
If not, are there any suggested workarounds to get the driver to properly identify the device and/or at least attach the partition to /dev/sda1 when it chooses to attach the device on Bus 02?

As this is my first post on this forum, I'll apologize in advance if this is the wrong category to post this kind of question, if so, please be so kind as to point me in the right direction.

I'll also apologize for not knowing how to mark up code or stdout lines above to get them into a scroll box for better readability. I will edit that into this post when I learn the correct markup. I guess I will have to spend some more quality time talking to myself through a proxy in the form of discobot. :wink: Of course, some kind soul could help me out and point me to the forum editor's markup manual. :slightly_smiling_face:

this is why UUID was invented

fstab.overlay.device="/dev/sdX" > fstab.overlay.uuid="abcde"
2 Likes

Thanks for the reply. (With an embedded code block!) :slightly_smiling_face:
I already removed option device '/dev/sda1' and set uuid to match the partition's uuid in both /etc/config/fstab and /rwm/upper/etc/config/fstab

config mount 'overlay'
        option uuid '8a201632-462e-4eb9-89fc-8a44fa20f9a4'
        option target '/overlay'
        option enabled '1'
        option auto_mount '1'

This doesn't seem to make any difference as the uuid is not found on odd numbered boots when physical key is attached to Bus 02 and /dev/sda1 is not attached to the file system:

root@OpenWrt:~# logread | grep -i uuid
Fri May 29 05:33:18 2020 user.err kernel: [   16.603027] block: extroot: cannot find device with UUID 8a201632-462e-4eb9-89fc-8a44fa20f9a4

please post;

block info

on an 'odd boot' :alien: :space_invader: :japanese_goblin:

also change this for testing;

delay_root '5' > '12'
root@OpenWrt:~# block info
/dev/mtdblock6: UUID="810223659" VERSION="1" TYPE="ubi"
/dev/mtdblock8: UUID="810223659" VERSION="1" TYPE="ubi"
/dev/ubiblock0_0: UUID="b28d4e9e-5451dc49-133c1a49-dd884e53" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/ubi0_1: UUID="fda70b69-f3aa-4289-8a20-52b0ad0cb8a8" VERSION="w4r0" MOUNT="/overlay" TYPE="ubifs"

Sorry it took a minute, I decided to try to set option delay_root '60' in fstab. A minute seems a lot longer when waiting for a reboot to end, oh, it made no difference so I'm going to set it back to 10.

10 did I say 10, make that 12 instead :wink:

1 Like

interesting... well that's pinning it down a bit...

now... also on an odd boot... post;

logread | grep usb
root@OpenWrt:~# logread | grep usb
Fri May 29 06:20:09 2020 kern.info kernel: [    0.010285] reg-fixed-voltage usb3_1-vbus: could not find pctldev for node /soc/internal-regs/pinctrl@18000/usb3_1-vbus-pins, deferring probe
Fri May 29 06:20:09 2020 kern.info kernel: [    0.010620] usbcore: registered new interface driver usbfs
Fri May 29 06:20:09 2020 kern.info kernel: [    0.010647] usbcore: registered new interface driver hub
Fri May 29 06:20:09 2020 kern.info kernel: [    0.010668] usbcore: registered new device driver usb
Fri May 29 06:20:09 2020 kern.info kernel: [    1.090477] orion-ehci f1058000.usb: EHCI Host Controller
Fri May 29 06:20:09 2020 kern.info kernel: [    1.095912] orion-ehci f1058000.usb: new USB bus registered, assigned bus number 1
Fri May 29 06:20:09 2020 kern.info kernel: [    1.103559] orion-ehci f1058000.usb: irq 38, io mem 0xf1058000
Fri May 29 06:20:09 2020 kern.info kernel: [    1.141158] orion-ehci f1058000.usb: USB 2.0 started, EHCI 1.00
Fri May 29 06:20:09 2020 kern.info kernel: [    1.155393] usbcore: registered new interface driver usb-storage
Fri May 29 06:20:09 2020 kern.info kernel: [    1.334827] xhci-hcd f10f8000.usb3: xHCI Host Controller
Fri May 29 06:20:09 2020 kern.info kernel: [    1.340174] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
Fri May 29 06:20:09 2020 kern.info kernel: [    1.347775] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x0000000000010010
Fri May 29 06:20:09 2020 kern.info kernel: [    1.357061] xhci-hcd f10f8000.usb3: irq 44, io mem 0xf10f8000
Fri May 29 06:20:09 2020 kern.info kernel: [    1.370927] xhci-hcd f10f8000.usb3: xHCI Host Controller
Fri May 29 06:20:09 2020 kern.info kernel: [    1.376280] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
Fri May 29 06:20:09 2020 kern.info kernel: [    1.383820] xhci-hcd f10f8000.usb3: Host supports USB 3.0  SuperSpeed
Fri May 29 06:20:09 2020 kern.info kernel: [    1.390341] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
Fri May 29 06:20:09 2020 kern.info kernel: [    1.731156] usb 2-1: new high-speed USB device number 2 using xhci-hcd
Fri May 29 06:20:09 2020 kern.info kernel: [    2.152327] usb-storage 2-1:1.0: USB Mass Storage device detected
Fri May 29 06:20:09 2020 kern.info kernel: [    2.158539] scsi host2: usb-storage 2-1:1.0
Fri May 29 06:20:09 2020 kern.info kernel: [    6.422992] usbcore: registered new interface driver uas
Fri May 29 06:20:09 2020 kern.info kernel: [   26.361927] usbcore: registered new interface driver btusb

And the same from an even numbered (extroot working) boot for comparison.

root@OpenWrt:~# logread | grep usb
Fri May 29 06:22:47 2020 kern.info kernel: [    0.008818] reg-fixed-voltage usb3_1-vbus: could not find pctldev for node /soc/internal-regs/pinctrl@18000/usb3_1-vbus-pins, deferring probe
Fri May 29 06:22:47 2020 kern.info kernel: [    0.009137] usbcore: registered new interface driver usbfs
Fri May 29 06:22:47 2020 kern.info kernel: [    0.009164] usbcore: registered new interface driver hub
Fri May 29 06:22:47 2020 kern.info kernel: [    0.009186] usbcore: registered new device driver usb
Fri May 29 06:22:47 2020 kern.info kernel: [    1.108816] orion-ehci f1058000.usb: EHCI Host Controller
Fri May 29 06:22:47 2020 kern.info kernel: [    1.114254] orion-ehci f1058000.usb: new USB bus registered, assigned bus number 1
Fri May 29 06:22:47 2020 kern.info kernel: [    1.121900] orion-ehci f1058000.usb: irq 38, io mem 0xf1058000
Fri May 29 06:22:47 2020 kern.info kernel: [    1.149677] orion-ehci f1058000.usb: USB 2.0 started, EHCI 1.00
Fri May 29 06:22:47 2020 kern.info kernel: [    1.163912] usbcore: registered new interface driver usb-storage
Fri May 29 06:22:47 2020 kern.info kernel: [    1.338658] xhci-hcd f10f8000.usb3: xHCI Host Controller
Fri May 29 06:22:47 2020 kern.info kernel: [    1.344026] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
Fri May 29 06:22:47 2020 kern.info kernel: [    1.351606] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x0000000000010010
Fri May 29 06:22:47 2020 kern.info kernel: [    1.360890] xhci-hcd f10f8000.usb3: irq 44, io mem 0xf10f8000
Fri May 29 06:22:47 2020 kern.info kernel: [    1.383425] xhci-hcd f10f8000.usb3: xHCI Host Controller
Fri May 29 06:22:47 2020 kern.info kernel: [    1.388765] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
Fri May 29 06:22:47 2020 kern.info kernel: [    1.396312] xhci-hcd f10f8000.usb3: Host supports USB 3.0  SuperSpeed
Fri May 29 06:22:47 2020 kern.info kernel: [    1.402814] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
Fri May 29 06:22:47 2020 kern.info kernel: [    2.599776] usb 3-1: new SuperSpeed USB device number 2 using xhci-hcd
Fri May 29 06:22:47 2020 kern.info kernel: [    2.630863] usb-storage 3-1:1.0: USB Mass Storage device detected
Fri May 29 06:22:47 2020 kern.info kernel: [    2.637068] usb-storage 3-1:1.0: Quirks match for vid 090c pid 1000: 400
Fri May 29 06:22:47 2020 kern.info kernel: [    2.643828] scsi host2: usb-storage 3-1:1.0
Fri May 29 06:22:47 2020 kern.info kernel: [    6.457820] usbcore: registered new interface driver uas
Fri May 29 06:22:47 2020 kern.info kernel: [   14.680438] usbcore: registered new interface driver btusb
1 Like

Some people have had issues with the USB3 port on this router, and some devices attached to the USB3 port will only show when attached after booting.

2 Likes

Are you aware of anyone who has found a workaround for the USB3 issues on this router?

Yes, in an odd numbered boot, I can unplug the usb key, plug it back in and the driver will attach it to logical Bus 3. I guess that counts as the even numbered boot, since on next reboot the key is attached to Bus 02 again.

If I needed to get a usb key working for storage quickly, I suppose unplugging and plugging would be a (n annoying) workaround, just pretty useless for running extroot. I could also reboot twice each time I needed a single reboot in order to use extroot on a fast USB3 key, but I think I'd rather do without extroot :frowning:

Another option would be to just plug a superspeed USB3.1 key into a USB2.0 port. Extroot will work every reboot, but it is USB2.0! That just seems so WRONG to waste a superspeed usb3.1 key in a 2.0 physical port when there is a USB3 port right beside it, which should be useable.

/etc/init.d/fstab

boot() {
    if ! block info | grep -q '/dev/sd'; then
      rmmod ...
      insmod ...
      sleep 3
    fi
	/sbin/block mount
}

My two cents:

  • I was affected by the issue that I explained above on older versions of OpenWrt, then it was fixed with an update.
  • However, my experience was "plugged after booting" vs "plugged in before booting".
  • Some people seems to be still affected, I think this depends on the device.

Added this to /etc/init.d/fstab and the copy in /rwm/upper. No joy, key still alternately attaches to Bus 02 or Bus 03 on subsequent reboots.

Since my last forays into kernel hacking are a couple decades behind me, I am not familiar with the remove module and insert module commands. Seems like they could be really handy :wink:
Is ... an actual parameter to the module commands, or was I supposed to replace the textual ellipsis with module names? If it's a parameter, can you point me to doc that tells me what ... represents? The man pages I found don't mention ... And, if it's an ellipsis, not a parameter, what was I supposed to replace it with? Thanks.

just do it manually first... on an odd boot...

do something like;

lsmod | grep usb

then

rmmod <MODULENAME>
insmod <MODULENAME>
dmesg | grep usb | tail -n10

repeat a few times until you nail down the module names related to usb on your system. I don't have your router so I've no idea what they are called.

the idea is to load them in a specific order if possible... or if just re-manually loading them will resolve.

Methinks the update might not have been a complete fix? :slightly_smiling_face:
At least not for all devices.

In my experience plugged after booting always works. The physical device is attached to the correct logical bus and attaches the device to the file system in /dev/sd[abc...]X If leaving the device plugged in, next reboot (first reboot after plugging in, odd numbered) the key is attached to Bus 02 and it doesn' t work. Not until the following reboot (second reboot after plugging in, even numbered) correctly attaches the key to Bus 03, again.

:slightly_smiling_face: :laughing: :slightly_smiling_face: Yes. This particular router has another built in alternating behavior which may or may not make a difference to the problem with alternating USB bus attachment. The router has a dual firmware flash layout which alternates between flashing a primary and secondary partition each time firmware is flashed. And, luci-app-advanced-reboot is installed to manage which partition to boot next. May not be related at all, but is a somewhat unique feature of this device.

Is it unique or common to have 2 USB3 logical busses on a device? I'm guessing Bus 02 may be for USB 3.0 devices and Bus 03 may be for USB 3.1 devices? I'm basing that guess on bus descriptions from lsusb being identical except for Bus 03 ending with 5000M and Bus 02 ending with 480M (and on Bus 03, not Bus 02 working with my USB3.1 key). If my guess is correct, then 2 USB3 busses would be present on all devices with a USB 3.1 capable physical port, and not something unique to the WRT32X-B.
Thanks.

Update... Found a partial answer to the 2 USB3 logical devices question. Bus 03 is for USB3.x devices. USB3.x devices operate at a maximum signalling rate of 5Gbps (5000M). Looks like Bus 02 exists so that a USB2.0 device with its maximum signalling rate of 480Mbps won't fail if it is plugged into the USB 3 physical port.

That means there are 2 problems, my USB3.1 key is alternately mis-identified as a USB2. 0 device, and driver support for a USB2.0 key plugged into a USB3 physical port is not working correctly (at least not when the driver has mis-recognized a USB3 key as a USB2.0 key).

Thank you. Looks like I need the module btusb. So I replaced ... with btusb in /etc/init.d/fstab and it had no effect.

root@OpenWrt:~# lsmod | grep usb
bluetooth             253952 11 btusb,rfcomm,hidp,hci_uart,btmrvl_sdio,btmrvl,btintel,bnep
btintel                12288  1 btusb
btusb                  28672  0
root@OpenWrt:~# rmmod btusb
root@OpenWrt:~# insmod btusb
root@OpenWrt:~# dmesg | grep usb | tail -n10
[    1.402778] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.759651] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[    2.090643] usb-storage 2-1:1.0: USB Mass Storage device detected
[    2.096886] scsi host2: usb-storage 2-1:1.0
[    6.395063] usbcore: registered new interface driver uas
[   26.340414] usbcore: registered new interface driver btusb
[   27.777638] usbcore: deregistering interface driver btusb
[   27.812476] usbcore: registered new interface driver btusb
[  637.776676] usbcore: deregistering interface driver btusb
[  644.899902] usbcore: registered new interface driver btusb
root@OpenWrt:~# ls -als /dev/sda1
ls: /dev/sda1: No such file or directory
root@OpenWrt:~# block info
/dev/mtdblock6: UUID="810223659" VERSION="1" TYPE="ubi"
/dev/mtdblock8: UUID="810223659" VERSION="1" TYPE="ubi"
/dev/ubiblock0_0: UUID="b28d4e9e-5451dc49-133c1a49-dd884e53" VERSION="4.0" MOUNT="/rom" TYPE="squashfs"
/dev/ubi0_1: UUID="fda70b69-f3aa-4289-8a20-52b0ad0cb8a8" VERSION="w4r0" MOUNT="/overlay" TYPE="ubifs"

Interface driver registration from odd #d boot at 26.3s. Registered again from /etc/init.d/fstab at 27.8s (doesn't appear to count as an even #d boot or fix the problem since /dev/sda1 was not attached to the file system). Registered again from insmod on the command line at 644.8s.

1 Like

Might be worth a try to see if a 5.4 image changes this behaviour.

I sent the following response in a private message and thought it would show up here, but it didn't so...

Hi,
I’m new to OpenWRT. First install was a DD-WRT replacement on a decommissioned TL-WR1043ND I had lying around. That was just two weeks ago and, that install was just to get a feel for what needed to happen when the new WRT32X-B arrived, six days ago.

So, I’m really NOT trying to be a smartazz when I ask the following, and I hope it doesn’t come across that way. What’s a 5.4 image? And, where might I find one?

Also, does a 5.4 image contain USB3 interface driver updates that may allow a USB3.1 key plugged into a USB3.0 port to be properly identified at each boot? If so, I’m game to do some alpha testing.
Thanks.

"5.4" refers to the kernel version in use of your firmware. Right now kernel v5.4.x is only used in master snapshots, not in the stable v19.07.x releases (it will form the basis for a future 20.x.0 release though), but not necessarily already available or the default for all targets yet.

I've done some further device checks and testing. And, I may have found a workaround that will allow me to use extroot on the WRT32XB, just not on the Samsung Fit USB key I wanted to use.

  • Verified that the WRT32XB has a 3.0, not 3.1 USB port.
  • Verified that the Samsung Fit USB3 key is 3.1, not 3.0.
  • Verified that the Samsung Fit USB3.1 key is mounted at each reboot when plugged into a USB3.0 port on a computer running linux.
  • Formatted a Sandisk Cruzer USB3.0 key and verified that it is mounted at each reboot on the WRT32XB
  • Installed extroot on the Sandisk Cruzer key and verified that the key was still mounted and overlayed at each reboot! (Yay!!! a workaround :slightly_smiling_face:)
  • Verified that the root of the problem attaching the Samsung Fit USB3.1 key to /dev/sda1 is mis-identification of the usb key (by the interface driver ?) on every other reboot.

Here is the head of 'lsusb -s 02:02 -v' output, on an odd #'d, non-working reboot. Note the second half of the ID, and the values of idProduct, iManufacturer, iProduct, iSerial, and bcdUSB

Bus 002 Device 002: ID 090c:3267 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x090c Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
  idProduct          0x3267
  bcdDevice            1.00
  iManufacturer           1 Silicon Motion,Inc.
  iProduct                2 SM3280AA MEMORY BAR
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA

Here is the head of 'lsusb -s 03:02 -v' output, on an even #'d, working reboot. Note the second half of the ID, and the values of idProduct, iManufacturer, iProduct, iSerial, and bcdUSB

Bus 003 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         9
  idVendor           0x090c Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)
  idProduct          0x1000 Flash Drive
  bcdDevice           11.00
  iManufacturer           1 Samsung
  iProduct                2 Flash Drive FIT
  iSerial                 3 0373819120034258
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           44
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               76mA

Even though I have a workaround (Thanks to everyone who responded!) I'd still like to be able to use extroot on the Samsung Fit. It is a very low profile USB key, and it is already on hand. The Sandisk Cruzer is just too large a package, and I don't want to have to buy a new low profile USB3.0 key in order to use extroot on this router.

Ahhh, 5.4 is the kernel version on the dev branch, that makes it a little clearer. Let me make sure I understand,

  • v19.07.x and its 4.14.180 kernel are considered mature enough that only mid to major level bug fixes for relatively serious problems will be made to it going forward.
  • As usual, new development, new features, and minor bug fixes go into the dev (uhh, master) branch (which is using a new kernel, v5.4).
  • A fix to the xchi USB3 interface driver to correctly identify USB 3.1 devices plugged into USB 3.0 ports every reboot instead of every other, is going to be considered a minor bug fix.
  • The bug may already be fixed at the master branch, in which case OpenWRT.org could use an alpha tester with appropriate hardware to see if that's the case.
  • If the bug is not already fixed at master, OpenWRT.org could use a developer to make the fix, or at the very least to open a bug report with an accurate description of problem and possibly a suggested fix.
  • Any fix would eventually be pushed to master, so I'd need to be using a master "5.4 image" anyway if I wanted the fix before v20.x is released.
  • It is not necessary for me to understand any of this unless I'm just too cheap to spring for a new low profile USB3.0 key and completely avoid the bug in the driver. :wink:

I have a couple questions...

  • Are the statements in the list above correct, or close to?
  • You said...
  • Is the 5.4 image available for the mvebu target, the cortexa9 subtarget, the arm_cortex-a9_vfpv3 architecture, and the WRT32XB (WRT32X) model?
  • How often are master snapshots broken? No need to be exact, a ballpark percentage of the time would be fine. Maybe a better way to phrase that would be, how robust is your build system in detecting and preventing breaking changes from making it into a master snapshot?
  • How large is the OpenWRT development community? How many people are working on the 5.4 image?
  • Has a proposed release date for v20.x been announced?
  • Is there a development roadmap?
  • Where is the doc for downloading/pulling/fetching master snapshot builds and source from github, uhhm, in case I like the answers to the other questions?

Thank you.