Renesas uPD720202 uPD720201 usb controllers

[Steve Coleman]

A number of months ago I was happily backing up my system at home using
my sys-usb with a dedicated USB controller that worked right out of the
box. I didn't need any drivers or anything special. It just worked.

Then something happened, likely during an update, which could be like 6
months ago, so I switched back to using dom0 for my updates until I
could find the time to look into it. It appeared to me that the USB
controller was simply malfunctioning, so I searched for a new card from
a different manufacturer which claimed it had native Linux support.

But after installing this new card and booting up qubes, nothing. The
new card didn't work either. Booting other OS's both cards work just
fine. But with qubes neither one works, and as luck would have it both
cards have chip-sets from Renesas (uPD720201 uPD720202).

I know that I have received a couple of qubes-vm kernel updates over
that time, and I can't say for certain which one broke it, but it
appears that other people on some other OS's are also having some
similar issues:

e.g. circa 2018-05-05
https://bugzilla.kernel.org/show_bug.cgi?id=199627

and in 2016 there was a patch to xhci-pci
https://lore.kernel.org/patchwork/patch/686290/

and some more recent indecision and push back:
https://lore.kernel.org/linux-usb/CANcMJZDqX6-+naGEbBiyM+1c...@mail.gmail.com/
https://lore.kernel.org/linux-usb/20191106083843....@kernel.org/


So my question to this forum is; Short of buying yet another "new" USB
card and taking a chance of getting the exact same flunky Renesas
chipset, what other options are there for resolving this? It seems
Kernel.org/linux-usb isn't exactly making haste in fixing this issue,
and reverting back to an older and less secure qubes-vm kernel would be
a definite mistake given some recent vulnerabilities.

Thoughts? Do I need to trash them and just move on? I do have one that
is working in my machine here at work, but I'll have to disassemble it
to find out what brand/model number it is. I hate breaking tamper seals
if I can avoid it.

Thanks,

Steve


My hardware info:

$ sudo dmesg | grep xhci
[ 16.516802] xhci_hcd 0000:00:07.0: xHCI Host Controller
[ 16.516893] xhci_hcd 0000:00:07.0: new USB bus registered, assigned
bus number 2
[ 26.517096] xhci_hcd 0000:00:07.0: can't setup: -110
[ 26.517199] xhci_hcd 0000:00:07.0: USB bus 2 deregistered
[ 26.520823] xhci_hcd 0000:00:07.0: init 0000:00:07.0 fail, -110
[ 26.520857] xhci_hcd: probe of 0000:00:07.0 failed with error -110
[ 26.522239] xhci_hcd 0000:00:08.0: xHCI Host Controller
[ 26.522332] xhci_hcd 0000:00:08.0: new USB bus registered, assigned
bus number 2
[ 36.522522] xhci_hcd 0000:00:08.0: can't setup: -110
[ 36.522567] xhci_hcd 0000:00:08.0: USB bus 2 deregistered
[ 36.524235] xhci_hcd 0000:00:08.0: init 0000:00:08.0 fail, -110
[ 36.524268] xhci_hcd: probe of 0000:00:08.0 failed with error -110

$ lspci
...
00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02)
00:08.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev 03)

Both controllers are using similar chipsets...


> setpci -v -s 00:07.0 f0.l
0000:00:07.0 @f0 = ffffffff
> setpci -v -s 00:07.0 ec.l
0000:00:07.0 @ec = ffffffff

> setpci -v -s 00:08.0 ec.l
0000:00:08.0 @ec = ffffffff
> setpci -v -s 00:08.0 f0.l
0000:00:08.0 @f0 = ffffffff

Hmmm, no bios I can flash...


> sudo lspci -vvv
00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02) (prog-if 30 [XHCI])
Physical Slot: 7
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f2024000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq-
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1,
Exit Latency
L0s <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported,
TimeoutDis+, LTR+, OBFF
Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-,
LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Kernel modules: xhci_pcisudo

00:08.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev 03) (prog-if 30 [XHCI])
Physical Slot: 8
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f2026000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq-
AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1,
Exit Latency
L0s <4us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported,
TimeoutDis+, LTR+, OBFF
Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-,
LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-,
LinkEqualizationRequest-
Kernel modules: xhci_pci

[David Hobach]

I can confirm the issue for that chipset.

Maybe the firmware loading fails, because it's not shipped with the
kernel? I don't know...

Ah...

https://www.startpage.com/do/dsearch?query=uPD720202+firmware

-->

https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/

So possibly it claims to have the firmware in the EEPROM, but it in fact
doesn't and requires it from the kernel.

Not sure why yours ever worked then. I just got mine, so I can't claim
that. Maybe I'll try the stuff mentioned in the blog post.

[David Hobach]

On 1/9/20 3:27 PM, David Hobach wrote:
> https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/

I tested that after passing the device to a VM via IOMMU.

It did work and even survived a reboot (without power off though).

I found the firmware inside an extractable executable (7z) of the CD
that came with it. It was ~13K and called UPDATE.rom.

Good luck with your devices!

[David Hobach]

On 1/10/20 10:27 AM, David Hobach wrote:
> On 1/9/20 3:27 PM, David Hobach wrote:
>> https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/
>
> I tested that after passing the device to a VM via IOMMU.
>
> It did work and even survived a reboot (without power off though).

Disadvantage here:
An attacker may modify the ROM and then use DMA during the boot process
to do whatever he wants. But that unfortunately applies to many PCIE
devices. It's also an attack quite sensitive to timing.

[Steve Coleman]

On 2020-01-09 09:27, David Hobach wrote:

>
> I can confirm the issue for that chipset.
>
> Maybe the firmware loading fails, because it's not shipped with the
> kernel? I don't know...
>
> Ah...
>
> https://www.startpage.com/do/dsearch?query=uPD720202+firmware
>
> -->
>
> https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/

Thanks for the references! I'll have to check this out this weekend.

> So possibly it claims to have the firmware in the EEPROM, but it in fact
> doesn't and requires it from the kernel.

It was my understanding that the setpci statements in my original email
say there is no EEPROM/BIOS on the card, but then your references say
that I should have been using the "f6.w" argument for that.

I'll have to try and see this "f6.w" parameter returns (e.g. setpci -s
00:0[x].0 f6.w ) I'm just learning about this setpci command that I had
never heard of before this problem forced me to investigate. Your
referenced blog eventually landed me here:

http://billauer.co.il/blog/2015/11/renesas-rom-setpci/

Some good information on using this setpci command can be found there. I
guess I'll need to spend some time reading up on this, since I have been
very interested in how to go about reading and validating EPROMS and
BIOS lately, but didn't know quite where to start.

> Not sure why yours ever worked then. I just got mine, so I can't claim
> that. Maybe I'll try the stuff mentioned in the blog post.

It definitely did work, as I had my system so that whenever I was ready
to shutdown, I just clicked on a desktop icon and my scripts found all
non-running AppVM that had not yet been backed up, and it would
automatically kick off a job to back up those VMs to the sys-usb
attached device, and then shut itself down. It made it very easy for my
wife that way. But then after some kernel update it just stopped
working. I don't know which update killed it, and if I did, I would
certainly go look to see if there were drivers in that package prior to
that specific update. In hind sight I should have been much more
proactive when it first stopped working, but somehow life got in the way.

Now that I have some loader software, that you kindly pointed me to,
I'll have to look at some of the Live-CD's that previously worked with
the card in the past, to see if I can steal a copy of the drivers from
one of them. I don't remember specifically which ones worked other than
I do remember that one of the prior versions of the Tor Live-cd's did work.

Many thanks! I now have something to try out and experiment with.

Steve