Rensas USB 3.0 cards VFIO Passthrough possible fix through firmware upgrade

Software & Operating Systems VFIO
, ,
1

EDIT: if you have uPD720202 and firmware update does not work for you, check the tool mentioned in this post later in the thread

So I recently set up my OpenSUSE KVM passthrough host, and as many other people I wanted to pass through a USB PCIe card to the system.

I installed a cheap Rensas uPD720201 PCIe card from Ebay to the M.2 slot from the CPU, added its PCIe ID to the vfio script list so it’s locked out and not used by Linux. Passedthrough and started the VM…

and the VM showed all the known issues as said in this forum: the VM crashes or is unstable, it boots slowly, and more importantly the USB card does not actually work in the VM at all.

How unexpected. But I’m a strong man with manly hair on the chest, I’m not giving up.

I personally believe that Rensas is a reputable manufacturer and their driver support is pretty decent on all platforms (so much better than Fresco and VIA, for the very least), and knowing a thing or two about cheap chinese stuff, it’s almost guaranteed that firmware flashed at factory is ancient and buggy. Time to update the firmware. It’s actually easy to do, there are Windows installers for that.

WARNING DISCLAIMER: I take no responsibility, if you do this yourself you take full responsibility for what you are doing.

Some background info: these cheap and cheerful 2-4 port cards don’t have brand-specific firmware, any difference is in the electrical and physical parts (you either have USB ports or USB headers, for the chip it does not matter much).
Yes you heard it here first, you don’t need to get the Startech card Jack's Hardware: The Ultimate VFIO USB 3.0 Controller
any other using the same chipset will do if you just update the firmware.

So I looked at the good old station-drivers.com for a firmware update for that chipset. I used that site before and I kind of trust it.

Found some. Renesas/Nec uPD720201/720202

There is also the Startech firmware upgrade package that must be run from DOS 2 Port PCIe USB 3.0 Card Adapter w/ UASP - USB 3.0 Cards and since Startech is an actually decent company the package actually provides full release notes for what was fixed in what version of this firmware.
I’m not a fan of running it from DOS if I can avoid it, so I tried the Windows applications first.

Tried upgrading with the oldest firmware from the list, 2.0.2.0, which is a release from 2012. Kind of ancient, but I had a hunch. Placed it in a Win10 PC with a free PCIe slot.

Hah! It upgraded, so the firmware onboard was older than that. Or maybe it does not check firmware version before flashing?

Tried updating again with same firmware to check if the updater actually checks firmware version.

Aaand yes it does, it stops updating and tells me “firmware is already updated”. Good to know, it’s a thing to keep in mind, you can’t rollback to a previous version with these tools, so the sane way is to update to the next version and test it with the VM passthrough.

I have updated to 2.0.2.6 (same version as Startech firmware update package, which says this version was released in November 12, 2013 ) and now it’s allright. Now the VM starts at normal speed and USB work. If there is any test I can do, please tell me.

It seems the updater application will error out if there is more than one Rensas chipset to upgrade in the same system, so the people that have the fancy x4 cards with multiple controllers might be out of luck (unless you manage to disable the controllers selectively, I guess it’s doable if you fancy some microsoldering to keep the reset pin shorted to ground or something).

I had a look at the DOS executable that flashes the firmware in the Startech firmware upgrade package and it seems to have a pretty big help printout talking about all various commands you can use with it. I think that you can get it to flash newer firmware into the special x4 cards too.

I really think I’m going to buy one of those to try this out.

4 Likes
2

I’m glad my thread gave you a hint of what to do. I can attest VIA chipset firmware updates are practically impossible, so firmware updates on NEC/Renesas chipsets pretty much fix most VFIO issues.

I only suggest the Startech one because if you get one manufactured recently, it’s almost guaranteed to have the right firmware. If you want to flash something like a Sonnet Firmware for Hackintosh, that’s also okay.

What I am curious though is which Hackintosh compatible firmware still works with VFIO. Since you have firmware flashing tools, this is worth investigation.

2 Likes
3

Where are these ? I’m not a Hackingtosh guy and a quick Google search didn’t find anything useful.
I’m not terribly interested in MacOS-only tools though as I don’t have or need a MacOS VM.
As long as I can get the firmware file alone though, I can probably convince the Startech updater to flash it.

My gut feeling is that these “hackingtosh compatible” firmware are just up-to-date normal firmware.

I’m not sure I was clear enough above, I didn’t use physical SPI chip flasher tools, anyone can do the same I did.

The firmware upgrade tool I got from station-drivers is a Windows executable, just place the card you want to upgrade in a PCIe slot, boot windows and click on the installer.

The one from Startech requires you to make a FreeDOS USB drive with Rufus (or other tools) and extract the Startech update package in it, and then place the card in a PCIe slot, reboot, enable CSM if you disabled it, and boot into the USB drive.
More involved, but anyone setting up a KVM with passthrough should be able to do this easily.

Yeah, that’s correct, they also provide firmware update on their site and are in general a good serious company with support and all.
In my OP I was just a bit sarcastic, no offence intended.

Although they don’t seem to make a card with no ports and only USB 3.0 headers (2 headers, for 4 ports), and that’s what I’m using.
They also don’t seem to make M.2 USB 3.0 cards either, which would also be useful in my situation

EDIT: on a second note, I just looked up their x4 PCIe card and they have a working Windows updater for it that explains how to deal with multiple controllers. Since what I said still applies, it should work fine for any other x4 card using the same general idea with multiple controllers

4

No, the Hackintosh firmware changes the PCI vendor ID and then you can install the Sonnet Drivers in MacOS plug and play:

https://www.tonymacx86.com/threads/making-nec-usb-3-0-card-fully-comportable-with-original-mac-drivers-caldigit-lacie-oyen.77864/

5

Hm, the guy in that thread is using the same DOS tool as found in the Startech firmware upgrade package, just telling it to write different vendor IDs so it can fool MacOS into loading and using the best vendor drivers available, he is also using settings defined in the CFG.INI text file.

He seems to be focused on the
uPD720200 & uPD720200a, and not on our chipset, which is the uPD720201/uPD720202.

Although it does not matter much, commands and settings are the same. In his OP in the instructions he is just detecting the chip revision and flashing different firmware depending on that.
He also says in the OP that his firmwares are “latest ORIGINAL” so there is no firmware mod.

The readme in his package (for our Rensas chipset it is linked in post 34 of that thread) and in the Startech firmware upgrade package explain all possible options in the CFG.INI text file.

That’s neat, I didn’t look at that readme yet.
The DOS zip is the “full vendor SDK” as it allows to define all settings, what ports should be disabled, forcing connected devices as “not removable”, power options and “battery charge mode” for ports, and a switch to block the generic FW update tool that runs in Windows from updating the chipset (to allow the illusion of vendor-specific firmware).

His link for the tools for our chipset is old, so they are flashing firmware version 2.0.0.6, not anywhere near the latest, even for 2013, as guys in the thread complain they had newer firmware on cards they bought. But he does not explain why nor answer him, I guess he isn’t much interested in that chipset.

Anyway, these are the options in his file for the uPD720200 & uPD720200a

[SubSystemVendorID]
FFFF
[SubSystemID]
FFFF
[UsePPON]
1
; Set to '1', if you control the VBUS by PPON pin function of uPD720200/200A. 
; Set to '0', if you don't use PPON pin function of uPD720200/200A.
; This configuraiton is reflected in HCCPARAMS(Bit3) of Host Controller Capability
; Register. See the User's Manual(Table 3-78). Default Value is '1'.
[EnableDeviceNonRemovalPort1]
0
; Set to '1', if the Non-Removable Device is connected to Port1&Port3(U2DP1,U2DM1,
; U3TXDP1,U3TXDN1,U3RXDP1,U3RXDN1) or Port1&Port3 is unused.
; This configuraion is reflected in Device Removable(Bit30) of PORTSC Register 
; on xHCI. See the User's Manual(Table 3-90). Default value is '0'
[EnableDeviceNonRemovalPort2]
0
; Set to '1', if the Non-Removable Device is connected to Port2&Port4(U2DP2,U2DM2,
; U3TXDP2,U3TXDN2,U3RXDP2,U3RXDN2) or Port2&Port4 is unused.
; This configuraion is reflected in Device Removable(Bit30) of PORTSC Register 
; on xHCI. See the User's Manual(Table 3-90). Default value is '0'
[EnableClockRequest]
0
; Set to '0', if you want to disable the CLKREQ#(ClockRequest). 
; There exist PCs which has problem in its CLKREQ# function for ExpressCard slot.
; It is recommended to disable CLKREQ# function, if the product is ExpressCard.
; Default value is "1".

The first two are just IDs (you are supposed to write an ID from the list in his OP instead of the FFFF), and IDs matter only for drivers, but for a KVM setup we are force binding the Rensas device to VFIO when in Linux anyway, and VFIO does not care.

The other options are all set as default apart from the last one, [EnableClockRequest]
that is some workaround for an ExpressCard bug on some PCs that report the CLKREQ# in a bad way.
In his OP he talks about ExpressCard so he might have done that because back then in 2012 when he wrote that post it was still a thing?

The config he uses for our Rensas chipset (from the package he posts in post 34 of that thread) is just plain default options, [EnableClockRequest] included.

All in all, I don’t think it’s necessary to test any of this, so I’ll leave it at this “preliminary stage conclusions”.

Anything he does is changing device IDs and this does nothing on the host if the card is just bound to VFIO.
I have no idea if Linux drivers for Rensas chipsets will work if you change the vendor ID (they probably won’t), but if it’s bound to VFIO it won’t work in the host anyway. In any case you can always change the IDs later if you want to move the card somewhere else.
There is also no indication in his thread about using specific or modded firmware for MacOS so whatever is latest firmware should be OK, the main point of his thread is changing the vendor ID so MacOS will load good drivers for this device.

6

I am curious however if it will work inside a macOS VM with the same proper reset functionality. If you have a spare card, I would appreciate this being investigated. So far, I have had zero success getting USB 3.0 UVC devices to work when using any USB 3.0 chip on macOS. I would like to see success with USB 3.0 UVC devices in macOS in any form via Clover or via VFIO KVM Clover.

7

I’m not sure what you want me to do.

If on Windows UVC with that card and USB capture device works fine and on Linux it works fine, then it does not work in MacOS I would say is a driver issue. Macs use Intel USB controllers only in their devices so the driver they use for that may or may not like Rensas controllers, the only source of decent drivers is third party vendors.

So you either load a patched driver in MacOS or you disguise your device by changing the ID so you use a device vendor driver that does not suck. This is “Hackingtosh lite” land.

As I already said, MacOS is useless to me so I don’t plan to invest time to make a VM for it, so I won’t test that.

I can prepare and test a tool to let you (or others) change PCI IDs and then you can test different vendor drivers for Rensas controllers in the VMs you have.

I will test it on my (more expendable) cards first, so I can actually confirm that it does not kill the card and the PCI IDs actually change.
(I would be using the Startech zip updater to do so, it’s just a config file change, piece of cake).

But testing different PCI IDs and drivers on MacOS would be left to you or someone else that has such VM and uses the tool to change his card’s IDs, because I don’t and won’t have one any time soon.

Let me know.

8

So the pure problem is XHCI full compatibility is Intel chipset only. Like a full HDCP path is exclusive to the Vega 64 for Clover boot… (Would love if Radeon VII was also Netflix HDCP path compatible)

Those are the 2 major issues I personally have running Hackintosh.

9

Hm, still seems a MacOS driver problem to me. Other chipsets are fine with modern drivers/firmware.

For example, seems USB 3.0 chipsets were an issue for Oculus VR too, some time ago https://www.reddit.com/r/oculus/comments/3zrtgs/psa_your_usb_30_ports_may_not_be_compatible_with/

And they blacklisted more or less everything that isn’t Intel, AMD and Texas Instruments (what?, never heard of them, Macs don’t use them anyway, they seem to use XHCI generic drivers) for a while.

Then Asmedia controllers were added back to the “good boy” list after their drivers were updated to fix the issue (also important because AMD is basically using Asmedia technology in their chipset for Sata and USB 3.0).

If I look at Oculus’s compatibility list, https://support.oculus.com/204823846627499/

They say the above about Asmedia, and it also seems Rensas controllers went in the “good boy” list too if you were using Microsoft’s driver for their chipsets, as the PCIe x4 Startech cards with these chipsets are recommended for use with Oculus, “with the latest Microsoft drivers on the latest Microsoft OS”

The Asmedia chipsets are listed in Hackingtosh threads like this https://forums.macrumors.com/threads/usb-3-x-pcie-cards-for-classic-mac-pro.1501482/
but I have no idea if they actually work in MacOS.

But as all things (and most likely the reason people on reddit got random results with them and VFIO) is that firmware version matters just as it does with Rensas cards, or anything really. I had to update some USB 3.0 hub firmware some times too to solve instability issues.

(again, on the station-drivers site they have plenty of firmware updates for Asmedia chipsets https://www.station-drivers.com/index.php?option=com_remository&Itemid=352&func=select&id=20&lang=en and it works the same as with Rensas, these cards aren’t using a vendor-specific firmware, they are way too simple and cheap to run anywhere near custom software).

That’s a problem I don’t have, I avoid content that wants HDCP or any form of stupid DRM.

I’m also more of an audiobook kind of guy.

10

Getting FairPlay to work is the only way to get 1080p Netflix working in macOS Safari.

Oculus tracks using cameras rather than sensors in the headset. They are basically UVC cameras with high frame rate. UVC is just a nightmare for third party chipsets.

11

Good, so what the Oculus devs said for their issue with USBs https://forums.oculusvr.com/community/discussion/comment/330689/#Comment_330689
should apply to UVC in general as well.

In terms of why certain cards don’t work, it’s mostly about the USB 3.0 spec (at first) being not completely clear in places, causing different chipsets to act differently. In the beginning, there were aspects of the USB 3.0 spec that were ambiguous, in which case some vendors interpreted the spec in slightly different, conflicting, ways. With simple devices, like a USB hard drive, this isn’t a big issue, but with the consumer Rift it’s really pushing the limits of USB and can run into some problems.

So, did you test any card providing USB 3.2 (or 3.1 gen2, aka 10Gbps)?

Also, on those cards the controller is usually supporting Intel eXtensible Host Controller Interface specification revision 1.1, while on older ones like Rensas/Via/Fresco/whatever that we all know and love, the controller supports the spec revision 1.0.

This is the interface used by the driver to communicate with the card.
Theoretically a device that is fully compliant with that should work correctly with the generic USB 3.0 driver.

For example, this sonnet card https://www.sonnettech.com/product/allegro-usbc-pcie.html
or this Startech card https://www.startech.com/Cards-Adapters/USB-3.0/Cards/2-port-pcie-usb3-1-card~PEXUSB312C3
that is using the Asmedia 3142 https://www.asmedia.com.tw/eng/e_show_products.php?cate_index=175&item=179
And Sonnet says the card works in MacOS, and they don’t give any drivers so maybe it’s using the generic driver?

Or this Startech card https://www.startech.com/Cards-Adapters/USB-3.0/Cards/2-port-usb-3-1-card~PEXUSB312A2
that is using Asmedia 2142 https://www.asmedia.com.tw/eng/e_show_products.php?item=178&cate_index=175

There is also a newer Intel eXtensible Host Controller Interface specification, the 1.2 in 2019, but afaik there is no hardware (maybe besides Intel) that supports that.

1 Like
12

I have not tested 3.2 Gen 2, but with XHCI on Linux, it has problems with UVC devices with ASMedia chipsets part of most current AMD motherboards.

13

Are those chipsets you tested on Linux USB 3.2 (or USB 3.1 gen2) or not? It’s unclear from what you posted.

Because Asmedia 3.0 chipsets were also in the same boat as others, with USB 3.0 spec and eXtensible Host Controller Interface specification 1.0.

Or are you talking of AMD controllers in the chipset, which are in practice slightly customized Asmedia controllers, licensed as part of their partnership.

14

AMD controllers in the chipset capable of 3.2 Gen 2. Had problems with UVC devices in Linux on that controller.

15

Hm, today I stumbled on a thing that might be interesting for you.

You can get Intel USB 3.0 controllers on a pcie card, the Thunderbolt 3 PCIe cards with TitanRidge Thunderbolt chipset (the chipset that can work also on AMD boards too, among other things).

They have USB 3.2 too (as part of the Thunderbolt 3 spec), and it seems they work fine without connecting the TBT header (that was what limited Thunderbolt 2 cards from working outside of officially supported boards, usually same brand of the card, and obviously Intel), or can be convinced into working fine with a simple bridge between two pins. Might be necessary to flash a modded firmware for the cards to use them in MacOS.
See this https://github.com/ameyrupji/thunderbolt-macpro-5-1/blob/master/ThunderboltEX3.md
and this https://github.com/ameyrupji/thunderbolt-macpro-5-1/blob/master/GC-TitanRidge.md

and more about people using that on hackingtosh and Windows https://egpu.io/forums/postid/44262/

I have no idea about passthrough that controller with KVM, most people reporting successful “passthrough” with Titan Ridge Thunderbolt chipsets on laptops are actually just passing through the GPU on the PCIe lanes of the thunderbolt to the VM.

16

Huh. It’s worth investigating with the Titan Ridge controller in passthrough. I know for certain things in passthrough cannot interface with the firmware interface of FPGA PCI-E cards (which is most PCI-E capture cards) so it cannot initialize such cards because the firmware can’t reach the card in passthrough.

17

Thank you for posting this thread. I ordered the recommended Startech card and had the same issues. It didn’t immediately occur to me to do a BIOS update. Instead, I thought that not having the SATA power connector present might be the culprit, but a BIOS update fixed everything.

18

I purchased an M.2 form factor uPD720202 with the internal USB 3.0 header off of ebay and ran into problems flashing it using the methods above. (I could have been doing it wrong).

The host operating system (proxmox) recognized the usb controller just fine, but when I passed it to a VM, the VM would see the pcie device, but wouldn’t load a driver. (xhci_hcd driver would fail with error 110 and skip this devices)

Long story short, I stumbled upon this github repo: GitHub - markusj/upd72020x-load: Firmware loader for Renesas uPD72020x USB 3.0 chipsets for Linux which can load a specified driver into some kind of RAM on the renesas card.

Download 2.0.2.6 driver above and extract the package looking for the UPDATE.mem file. Then, clone the repo, build the program, and run.

git clone https://github.com/markusj/upd72020x-load
cd upd72020x-load
make
mv ../UPDATE.mem ./K2026.mem
./upd72020x-check-and-init

The program will load up the firmware which persists through virtual machine reboots. The firmware does not persist through host power off. In the github repo, there’s a systemd service that can be configured in order to make this run once at startup.

Now I don’t have to have a full 16X pcie slot dedicated for my USB passthrough, instead I only have to give up a single M.2 slot.

– Hope this helped someone having issues with this controller/firmware.

4 Likes
19

On a sidenote, some (Intel) boards like the MSI z390-a pro allow passthrough of the onboard Intel USB. That’s quite useful for a Hackintosh VM.

20

If you could not flash an updated firmware (note that what I linked above is the firmware for uPD720201 which is an older chipset so you would need to look for firmware for uPD720202 instead), maybe they are cards have no eeprom/flash chip at all and expect the OS/drivers to load the firmware in the controller RAM.
This is how modern devices usually work, GPUs, wifi chipsets and so on. It’s cheaper for the manufacturers that don’t need to deal with flash chips and firmware versions since it’s all handled by the OS drivers.

I think this method should work with onboard controllers as well, where the Rensas controller is soldered to the motherboard.

Thanks for updating this thread with your experience, I’ll add a link to your post in the OP