Hi, Iru,
On Thu, Feb 28, 2019 at 10:03 PM Iru Cai <[email protected]> wrote:
>
> Hi Jason,
>
> On Fri, Mar 1, 2019 at 10:33 AM Jason Andryuk <[email protected]> wrote:
>>
>> Hi,
>>
>> I have a Lenovo Thinkpad t420s on which I've installed coreboot.
>> However, the USB 3.0 port is not active and the controller is not
>> listed under lspci.
>>
>> Under the original Lenovo bios, the xhci device was at pci address
>> 0d:00.0 behind bridge 00:1c.4.
>>
>> It looks like the t420s devicetree.cb is set up for the xhci
>> controller to be behind 00:1c.6. I changed that to 00:1c.4 and that
>> got the xhci pci device to show up as 03:00.0. Strangely, booting
>> into linux, it shows 001c.3 as the bridge to 03:00.0. Additionally,
>> plugged in USB devices were not detected.
>
>
> Note that the mainboard has pcie_port_coalesce set in the devicetree, so it
> can be wrong to just see the BDF address to know which port the XHCI device
> is connected to.
>
> However, lspci also shows the port, it'll show `PCI Express Root Port X`
> where X is actually the port number (PCI function number + 1). The function
> number in the device tree is based on this port number.
lspci says PCI Express Root Port 5 which matched my devicetree modification.
>>
>> Here's where it gets weird. I had a mouse plugged in, and I was
>> looking in sysfs.
>> cat /sys/devices/pci0000\:00/0000\:00\:1c.3/0000\:03\:00.0/enable
>> 0
>> So the xhci pci device is disabled. I ran `lspci -vvnn` a few times
>> in quick sucession - I was looking to see if it showed disabled - and
>> the mouse lit up!
>>
>> Plugging in a USB Flash drive, it was again not detected. The lspci
>> trigger worked. Later, promptly switching USB devices resulted in the
>> new USB device still being detected.
>>
>> Is "PCH: PCIe map 1c.4 -> 1c.3" the remapping from the device tree
>> 1c.4 to the 1c.3 that I see?
>>
>> Below I've included the cbmem -c output and a snippet from an old
>> lenovo BIOS dmesg w/ the pci address.
>>
>> Does anyone have an idea of what is going on, or what I should
>> investigate next? A total guess, but could poking the PCI device with
>> lspci turn it on so that it may detect an attached device and then
>> stay active? Maybe something with power management? Again, I'm just
>> guessing. Any suggestions are appreciated.
Playing around a little more, I discovered the USB 3.0 port works
normally when the laptop is plugged in. When on battery, the USB port
doesn't detect device insertion in Linux. Booting with an inserted
flash drive, Seabios detects and offers the device as a boot option.
Comparing lspci for battery vs. plugged in,
--- lspci-vvvnnn-03:00.0-battery 2019-03-03 21:53:06.490961592 -0500
+++ lspci-vvvnnn-03:00.0-plugged 2019-03-03 21:52:56.006905368 -0500
@@ -1,12 +1,13 @@
03:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host
Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo uPD720200 USB 3.0 Host Controller [17aa:21d2]
- Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
+ 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-
+ Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at e1900000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
- Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
+ Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [90] MSI-X: Enable+ Count=8 Masked-
So the NEC controller goes into D3 and doesn't seem to leave.
Disabling d3cold_allow on the xhci controller also seems to help
device insertion when on battery.
echo 0 > /sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/d3cold_allowed
It doesn't change the lspci output, but device insertion is again detected.
My understanding is d3cold requires some out of band signalling to
awaken a device.
Looking at page 100 of these schematics:
https://drive.google.com/file/d/0B6IqcVTk0jpYZ0ZvWVd3T1lFVHc/view
"If Wakeup function from D3 cold is required, VCC3_AUX should be
applied from system."
(Label next to it is VCC3_AUX_USB)
Also from page 100, it looks like VCC3_AUX_USB_ON controls VCC3_AUX_USB.
page 68
VCC3_AUX_USB_ON is pin 13, PGPIO3, of Thinker-1? The chip is labeled
BU77700KVT-GP, which google doesn't really have an answer for.
Anyone have any ideas what this chip may be? Any other ideas or
suggestions on what to investigate?
Regards,
Jason
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
