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 <flyingfishfinger@gmail.com> 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 <flyingfishfinger@gmail.com> 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 -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org