Well, right now i just have an EFI script (startup.nsh) which does this, and it works fine (walks through all the root ports until it finds a TB controller, then unhides it).
However, this only works if the extended registers are visible. I've never written a driver or anything, but I'm unsure how this would help given the registers aren't visible in the first place... R Tim Wawrzynczak <[email protected]> schrieb am Mo., 23. Nov. 2020, 09:19: > Hi Rafael, > > The 'hidden' keyword in devicetree hadn't been used in a while, so we > repurposed its meaning. > The usage here was for PCI devices that Intel hides (during calls to FSP); > we know they exist > and there are device operations we still want to associate with the device > (fixed memory and I/O > ranges the resource allocator needs to know about, ACPI tables, etc.), so > the semantics of the > 'hidden' keyword are basically that the device will not be probed for its > presence during PCI > enumeration (i.e., there is no check for a valid DID/VID); rather, it is > assumed that the device > exists, and its children may be scanned as well. > > I left a comment in pci_device.c for posterity here: > https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/device/pci_device.c#1171 > > Regarding your system, it sounds like you may need to add a custom driver > for the TBT controller, if it requires a special programming sequence > before its config space becomes "visible." > > Cheers, > - Tim > > On Sun, Nov 22, 2020 at 8:02 PM Rafael Send <[email protected]> > wrote: > >> Ok, I have a more formulated question now. TLDR, I got the same result as >> with 4.12, so there's probably something else going on I'd love some >> insight on. >> Hardware-wise, I'm on a 51nb X210, and have attached a Thunderbolt >> controller in the NVME slot (i.e root port 9, which is enabled in the >> device tree. Other PCI cards show up correctly here). Under normal >> circumstances, the Thunderbolt card shows up as a hidden device, until it >> is woken by writing certain values to an extended register. Obviously, in >> order to do this, the device has to be correctly detected (even as a hidden >> device). >> >> With the stock BIOS, issuing "pci 030000 -i" in an EFI shell results in >> the first attachment ("working.txt"). Note that here, I can see the entire >> configuration space including extended registers, which is important & I >> can then unhide the card. >> >> If I do the same thing with coreboot from either Tianocore's EFI shell or >> the same one I invoked above on disk, I get the other result >> ("notworking.txt"). Notice that it has much less output, and the >> human-readable section actually appears cut off. I'm guessing this means >> that somehow the rest of the configuration space isn't being mapped >> properly in the coreboot version, but that might be the wrong word. I'm >> unfamiliar with the inner workings of this part. >> >> Can anyone shed some light on why I can't seem to access the full config >> space for my device with coreboot, but can via stock BIOS? This is really >> the only thing keeping me from straight up switching to coreboot so it'd be >> dope to get it working... >> >> Cheers, >> Rafael >> >> On Fri, Nov 20, 2020 at 10:36 AM Rafael Send <[email protected]> >> wrote: >> >>> Hi, >>> Unsure if appending to the 4.13 announcement email was cool, so here's a >>> separate thread. >>> >>> I was using coreboot for a while, but then discovered that something >>> about it was not accessing hidden PCI devices correctly (not enough >>> expertise to figure out what). >>> >>> In my particular case, I'm adding a Thunderbolt controller to an >>> unsupported system. >>> The process for waking it up / unhiding it involves poking an extended >>> capability register of the device while it is still hidden, via the EFI >>> shell. >>> >>> This works fine on stock BIOS + shell, but never worked in coreboot / >>> Tianocore so unfortunately I had to give up using coreboot. >>> >>> Given the "hidden PCI device" change from the 4.13 release notes, should >>> I expect that my use-case may work now? >>> The notes talk about a specific device, but I'm unsure if all hidden >>> devices are treated the same way. >>> >>> Cheers, >>> R >>> >> _______________________________________________ >> coreboot mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
