VL805 firmware release 0137ad - fixes for Isochronous streams

[jdb]

Edit: This firmware is now installed by default on all Raspbian systems that have recently updated their rpi-eeprom-images package.

We've received an updated firmware from VLI that should fix isochronous bandwidth issues as seen here with 0137ac: viewtopic.php?f=28&t=250990&p=1580242#p1580242

To update to the new firmware image, edit /etc/default/rpi-eeprom-update as root and replace the parameter FIRMWARE_RELEASE_STATUS="critical" with FIRMWARE_RELEASE_STATUS="beta" and reboot.


To verify that the EEPROM has been updated, run sudo rpi-eeprom-update with no arguments, which should print out the currently installed revision.

[LTolledo]

will this be integrated to the regular update/upgrade cycle later on?

[jdb]

will this be integrated to the regular update/upgrade cycle later on?

After a successful round of testing, yes it will be pushed to the apt rpi-eeprom-images package.

[trejan]

Flashed with no errors on all the Pi 4 boards I've got. Works okay here with some SDR receivers and the usual USB devices like keyboard, mouse and storage. usbtop shows no difference in throughput between 0137ab and 0137ad. 0137ab was fine for me anyway as the SDR receivers I have all use bulk mode but no regression with 0137ad.

[noee]

FYI, after this update, I can now play videos with the test VLC from my network using WIFI without dropouts (audio and video) at 1080p with h/w accel working with 8bit (1080p and 4K) AVC and HEVC sources.

[trejan]

FYI, after this update, I can now play videos with the test VLC from my network using WIFI without dropouts (audio and video) at 1080p with h/w accel working with 8bit (1080p and 4K) AVC and HEVC sources.

Eh? How is USB involved here? Are you using a USB WiFi dongle? I don't know of any that use isochronous transfers.

[noee]

I know, it's weird, I have 3 USB devices connected (none are wifi dongle):

Code: Select all

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 20b1:000a XMOS Ltd 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I've been struggling with wifi on the pi4 and the VLC testing with videos from my server. Constant audio drops and sporadic playback, generally VLC is unusable when playing sources from the network (wifi). No issues at all with eth wired. FWIW, MPV has no such issues with the wifi, however, it doesn't do the h/w accel.

I just updated this to "ad", rebooted and now VLC testing works with the built-in wifi, meaning no audio drops or video stuttering. Not sure what to make of this exactly.

FWIW, my /boot/cmdline.txt points to the connected USB SSD (ASMedia bridge).

[trejan]

I know, it's weird, I have 3 USB devices connected (none are wifi dongle):

Are you connecting to 2.4GHz WiFi? USB 3.0 can cause interference in the 2.4GHz band.

Your XMOS audio device will use isochronous transfers as it needs guaranteed bandwidth. I guess it might be possible that the new firmware has altered the timing enough that it no longer interferes with your WiFi. Not sure how likely that is in practice though.

Your SATA adapter will use bulk transfers still. If you do something throughput intensive on the attached drive to cause a lot of USB traffic then do you still get uninterrupted video playback? If your problems were due to interference then I'd expect it to start dropping out again.

[jamesh]

I know, it's weird, I have 3 USB devices connected (none are wifi dongle):

Code: Select all

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 20b1:000a XMOS Ltd 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I've been struggling with wifi on the pi4 and the VLC testing with videos from my server. Constant audio drops and sporadic playback, generally VLC is unusable when playing sources from the network (wifi). No issues at all with eth wired. FWIW, MPV has no such issues with the wifi, however, it doesn't do the h/w accel.

I just updated this to "ad", rebooted and now VLC testing works with the built-in wifi, meaning no audio drops or video stuttering. Not sure what to make of this exactly.

FWIW, my /boot/cmdline.txt points to the connected USB SSD (ASMedia bridge).

Have you also done an rpi-update?

[noee]

Are you connecting to 2.4GHz WiFi? USB 3.0 can cause interference in the 2.4GHz band.

Yes, only option I have with my current DSL/Router

Have you also done an rpi-update?

Not since the test version of VLC came out, IIRC. Should I give it a go?

[jamesh]

Have you also done an rpi-update?

Not since the test version of VLC came out, IIRC. Should I give it a go?

Not if you don't want to! Just asking in case that what was caused the improvement.

[noee]

Well, fwiw, I must've done so as I tried it and the got the "firmware up to date" msg, but I don't recall when, had to be well before xmas.

Also, I just plugged in yet another USB3 device (VIA flash reader) and while it disconnected my wifi (this is to be expected, I guess), I just clicked the wifi again and it reconnected and remains working even while accessing the reader (and btw, the xDuoo is being used too).

[jamesh]

Well, fwiw, I must've done so as I tried it and the got the "firmware up to date" msg, but I don't recall when, had to be well before xmas.

Also, I just plugged in yet another USB3 device (VIA flash reader) and while it disconnected my wifi (this is to be expected, I guess), I just clicked the wifi again and it reconnected and remains working even while accessing the reader (and btw, the xDuoo is being used too).

Why is a disconnected Wifi expected? Anything in dmesg about the disconnection? Might be power related if the plugged in device required some significant startup current, browning out the WIfi.

[noee]

lsusb:

Code: Select all

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 004: ID 05e3:0748 Genesys Logic, Inc. All-in-One Cardreader
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 20b1:000a XMOS Ltd 
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Near the end of dmesg:

Code: Select all

092.175802] usb 1-1.4: New USB device found, idVendor=20b1, idProduct=000a, bcdDevice= 6.f2
[ 4092.175819] usb 1-1.4: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[ 4092.175832] usb 1-1.4: Product: xDuoo USB Audio 2.0
[ 4092.175844] usb 1-1.4: Manufacturer: XMOS
[ 4092.208588] usb 1-1.4: 1:3 : unsupported format bits 0x100000000
[ 4129.289583] Unhandled prefetch abort: breakpoint debug exception (0x222) at 0x00000000
[ 4246.619414] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 4246.664150] usb 2-1: New USB device found, idVendor=05e3, idProduct=0748, bcdDevice=12.09
[ 4246.664165] usb 2-1: New USB device strings: Mfr=3, Product=4, SerialNumber=5
[ 4246.664178] usb 2-1: Product: USB Storage
[ 4246.664189] usb 2-1: Manufacturer: Generic
[ 4246.664200] usb 2-1: SerialNumber: 000000001209
[ 4246.670241] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 4246.673176] scsi host1: usb-storage 2-1:1.0
[ 4247.730381] scsi 1:0:0:0: Direct-Access     Generic  MassStorageClass 1209 PQ: 0 ANSI: 6
[ 4247.731513] sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 4247.738050] scsi 1:0:0:1: Direct-Access     Generic  MassStorageClass 1209 PQ: 0 ANSI: 6
[ 4247.739483] sd 1:0:0:1: Attached scsi generic sg2 type 0
[ 4247.746174] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[ 4248.054255] sd 1:0:0:1: [sdc] 124735488 512-byte logical blocks: (63.9 GB/59.5 GiB)
[ 4248.057093] scsi 1:0:0:2: Direct-Access     Generic  MassStorageClass 1209 PQ: 0 ANSI: 6
[ 4248.058594] sd 1:0:0:1: [sdc] Write Protect is off
[ 4248.058601] sd 1:0:0:1: [sdc] Mode Sense: 21 00 00 00
[ 4248.059793] sd 1:0:0:2: Attached scsi generic sg3 type 0
[ 4248.064332] scsi 1:0:0:3: Direct-Access     Generic  MassStorageClass 1209 PQ: 0 ANSI: 6
[ 4248.064666] sd 1:0:0:3: Attached scsi generic sg4 type 0
[ 4248.066391] sd 1:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 4248.070021] sd 1:0:0:2: [sdd] Attached SCSI removable disk
[ 4248.075625] sd 1:0:0:3: [sde] Attached SCSI removable disk
[ 4248.090409]  sdc: sdc1 sdc2
[ 4248.099689] sd 1:0:0:1: [sdc] Attached SCSI removable disk
[ 4248.659964] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 4248.714183] EXT4-fs (sdc2): mounted filesystem with ordered data mode. Opts: (null)
[ 4679.907430] usb 1-1.4: timeout: still 1 active urbs on EP #1
[ 4680.907468] usb 1-1.4: timeout: still 1 active urbs on EP #1
[ 4691.088080] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 4 ep 1
[ 4691.088088] xhci_hcd 0000:01:00.0: @000000000ed0b8f0 00000000 00000000 0e000000 04028001
[ 4720.079023] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 4 ep 1
[ 4720.079031] xhci_hcd 0000:01:00.0: @000000000ed0b320 00000000 00000000 0e000000 04028001
[ 4732.959637] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 4 ep 1
[ 4732.959656] xhci_hcd 0000:01:00.0: @000000000ed061a0 00000000 00000000 0e000000 04028000
[ 4788.651092] xhci_hcd 0000:01:00.0: ERROR Transfer event for disabled endpoint slot 4 ep 1
[ 4788.651100] xhci_hcd 0000:01:00.0: @000000000ed0b5e0 00000000 00000000 0e000000 04028000

Well, maybe some interesting log info....

I say "expected" because it seems like the interference with 2.4Ghz wifi and USB3 is a known issue, though obviously this is would not be intended behavior.

The Genesis reader device is like a 3-in-1 type reader, though the only thing in it is a micro SD.

The xDuoo is powered externally.

[jdb]

@noee

Please do the test that trejan suggested -

Your SATA adapter will use bulk transfers still. If you do something throughput intensive on the attached drive to cause a lot of USB traffic then do you still get uninterrupted video playback? If your problems were due to interference then I'd expect it to start dropping out again.

Generate traffic on your USB3.0 disk. Does the wifi stay connected/reliable?

[LTolledo]

will this be integrated to the regular update/upgrade cycle later on?

After a successful round of testing, yes it will be pushed to the apt rpi-eeprom-images package.

thanks for the reply

so just to clarify...
this is not part of / different from / will not be deployed with
sudo apt update && sudo apt full-upgrade ?

because up to now this is the only procedure I follow to update/upgrade my RPi4B series boards.

thanks again...

[jamesh]

will this be integrated to the regular update/upgrade cycle later on?

After a successful round of testing, yes it will be pushed to the apt rpi-eeprom-images package.

thanks for the reply

so just to clarify...
this is not part of / different from / will not be deployed with
sudo apt update && sudo apt full-upgrade ?

because up to now this is the only procedure I follow to update/upgrade my RPi4B series boards.

thanks again...

The opposite - it WILL end up as part of the apt update. That's what the pi-eeprom-images package is for.

[LTolledo]

After a successful round of testing, yes it will be pushed to the apt rpi-eeprom-images package.

thanks for the reply

so just to clarify...
this is not part of / different from / will not be deployed with
sudo apt update && sudo apt full-upgrade ?

because up to now this is the only procedure I follow to update/upgrade my RPi4B series boards.

thanks again...

The opposite - it WILL end up as part of the apt update. That's what the pi-eeprom-images package is for.

thanks jamesh.... that's very re-assuring..... because all the while I thought EEPROM updates on my RPi4B were being left out...
I can rest easy now....
will wait then until "officially deployed" in next update/upgrade cycle.

thanks again to all RPF engineers to making this easy for us!

[noee]

@noee

Please do the test that trejan suggested -

Your SATA adapter will use bulk transfers still. If you do something throughput intensive on the attached drive to cause a lot of USB traffic then do you still get uninterrupted video playback? If your problems were due to interference then I'd expect it to start dropping out again.

Generate traffic on your USB3.0 disk. Does the wifi stay connected/reliable?

SOrry, meant to post, but got busy...I did this test.

I started two movies playing in VLC, one from the local USB reader, the other from my server (via wifi). I then started a file copy (~1GB) from another machine on the network down to the pi, using the USB sata (/home/pi) as the target. No issues.

BTW, JRiver Media Center playing music all the while with a hefty DSD up-convert to the xDuoo.

It wasn't until I went from 4K30p to 4K60p when it all went tits up (I must have a cheesy HDMI cable).

[frasey]

This release fixed an issue for me introduced in the 0137ab which essentially broke USB communication with my Kinect sensor. The issue was that the OS became unresponsive and the mouse/keyboard lagged whenever attempting to read video from the Kinect, and the simultaneous streaming of the two Kinect sensors which previously worked prior to 0137ab no longer worked at all.

Since flashing this firmware it all works flawlessly.

[Aardappeltaart]

Code: Select all

$ sudo vl805 -w vl805_fw_0137ad.bin 
VL805 FW version: 000137ab
VL805 EEPROM successfully reprogrammed - please reboot to activate.
~ $ sudo vl805 
VL805 FW version: 000137ab

Still hanging with reboot (SSD USB3 root)

But after power-cycle:

Code: Select all

sudo vl805
VL805 FW version: 000137ad

[trejan]

Code: Select all

$ sudo vl805 -w vl805_fw_0137ad.bin 
VL805 FW version: 000137ab
VL805 EEPROM successfully reprogrammed - please reboot to activate.
~ $ sudo vl805 
VL805 FW version: 000137ab

Still hanging with reboot (SSD USB3 root)

Doing the update via rpi-eeprom-update which uses recovery.bin to flash it at startup is the preferred method now. Updating directly using the vl805 tool can cause problems if you're using USB at the time.

[f0rd0prefect]

I have a USB3-to-mSATA-converter-board with an uPD720231A from Renesas Electronics (NEC). I use it with an SAMSUNG 860EVO mSATA SSD.
With the firmware release 0137ad the performance is nearly back to normal as it was with the first version (013701).
I always test the SSD performance with https://www.jamesachambers.com/raspberr ... nchmarks/ . After the update the score went up from 69xx to 93xx.
So for me, this is a very useful and great update.

[Aardappeltaart]

Doing the update via rpi-eeprom-update which uses recovery.bin to flash it at startup is the preferred method now. Updating directly using the vl805 tool can cause problems if you're using USB at the time.

Aha, I just followed instructions from OP

Code: Select all

sudo rpi-eeprom-update -f vl805_fw_0137ad.bin

You mean this would have done the same without hanging?

[trejan]

Aha, I just followed instructions from OP

Sorry. I wasn't very clear. The vl805 utility does the update directly and is probably better for testing the firmware which is why it was in the instructions. When the firmware is released for general usage however, it'll use rpi-eeprom-update which does the update using recovery.bin at startup and shouldn't hang. The Pi can guarantee that nothing else is running at the time because it does the update before starting Linux.

Code: Select all

sudo rpi-eeprom-update -f vl805_fw_0137ad.bin

You mean this would have done the same without hanging?

It should be the -u option for a VL805 firmware update.

Code: Select all

-u Install the specified VL805 (USB EEPROM) image file.