Bill I am not permitted to tell you more than I've told you unfortunately.But
thanks for your detailed writeup. It helped me understand issues better.And
turning on the PCI Bus Debug messages as Laszlo recommended definitely
helpednarrow down the problem.
I know that Bus 1 exists because I'm able to read PCI Registers freely using a
homegrown tool. It's just that the UEFI PCI Bus Driver is not seeing Bus 1.
Shubha D. ramanishubharam...@gmail.com
shubharam...@yahoo.com
On Thursday, September 24, 2015 5:09 PM, Bill Paul <wp...@windriver.com>
wrote:
Of all the gin joints in all the towns in all the world, Shubha Ramani had to
walk into mine at 15:59:09 on Thursday 24 September 2015 and say:
> Hello Laszlo.
> All I see from the driver debug messages are the following type(just a
> snippet printed). I assume the format is [B|F|D] and I'm not seeing any
> with 01 for the B. So the PCI Bus Driver is not seeing Bus 1 it seems. Is
> my interpretation correct ?
It would help if we knew a little about the hardware platform. So far you have
only said the device you're looking for is a "proprietary Intel chip." The
issue may not be with the chip, but with the way the platform is set up.
I have one possible theory as to why your code can't find the device, but
since I'm not too clear on the details this is just a guess.
Intel treats PCI a little differently that other platforms, and this can
sometimes lead to a little bit of confusion. If you look at non-Intel
platforms that have multiple PCI "hoses" (or segments), you'll see that each
such hose has its own bus/dev/func space. That is, if you have two PCI host
bridges or two PCIe root complexes, then each one has its own tree of PCI
devices starting at a root of bus0, device0, function0.
In the Intel architecture, it is still possible to have multiple PCI roots,
but everything is faked up to make it look as if there is only one tree of
devices and only one instance of bus0/dev0/func0. You may for example have
multiple PCIe root complexes, but the BDF space is unified so that everything
looks like it's part of one big happy family.
There is one thing you have to watch out for though: even though the BDF space
is unified, each hose might not be easily discoverable by simply starting from
bus0/dev0/func0 and working down.
I have an old Pentium3 Dell server that was used as a test machine a long time
ago which has 64-bit PCI slots. It also has a couple of 32-bit PCI slots. The
64-bit PCI bus runs at 66MHz while the 32-bit bus runs at 33MHz. The spec
allows you to plug a 32-bit device into a 64-bit slot, but if you do that, the
64-bit bus will slow down to 33MHz too. This will affect all devices on that
64-bit bus too. Consequently, to maintain the best performance on the 64-bit
bus, you don't want to connect any 32-bit devices.
There's another caveat of this: you can't bridge the 32-bit bus onto the 64-
bit bus because that will reduce the clock speed too. This means you can't
easily have a single BDF space that covers both sets of slots.
What happens instead is that the 32-bit devices are discoverable starting at
bus 0, and the 64-bit devices are discoverable starting at bus 1. There is no
bridge from bus 0 to bus 1, so you can't just start at bus 0 and keep
traversing: you have to explicitly know that bus 1 exists and is distinct from
bus 0, and once you finish traversing all devices on bus 0, you then repeat
the process for bus 1.
The question is: how do you find out that bus 1 is there? The answer is you
look at the ACPI device table. If there are multiple distinct PCI segments,
they will be defined there.
There is a more recent board from Intel which uses a special network packet
processing engine, which shows up as a PCIe device on bus 128. It has the same
issue: you have to know that bus 128 exists, because you won't discover it
just by probing for all devices starting at bus 0.
Now, I'm under the impression that the UEFI code is smart enough to discover
all the devices based on the ACPI tables on the board, but I can't be sure
that's working right here since I don't know what hardware you're using. At
any rate, that is one reason why bus 1 might not show up.
That said, you should check to see if any of the devices you did discover are
PCI bridges, and if one of them is a bridge to bus 1.
-Bill
> PciBus: Discovered PCI @ [00|00|00]
> PciBus: Discovered PCI @ [00|00|01]
> PciBus: Discovered PCI @ [00|00|04]
> PciBus: Discovered PCI @ [00|00|05]
> PciBus: Discovered PCI @ [00|00|06]
> PciBus: Discovered PCI @ [00|00|07]
> PciBus: Discovered PCI @ [00|01|04]
> PciBus: Discovered PCI @ [00|01|05]
> PciBus: Discovered PCI @ [00|01|06]
> PciBus: Discovered PCI @ [00|01|07]
> PciBus: Discovered PCI @ [00|02|04]
> PciBus: Discovered PCI @ [00|02|05]
> PciBus: Discovered PCI @ [00|02|06]
> PciBus: Discovered PCI @ [00|02|07]
> PciBus: Discovered PCI @ [00|05|00]
> PciBus: Discovered PCI @ [00|05|02]
> PciBus: Discovered PCI @ [00|05|03]
> PciBus: Discovered PCI @ [00|05|04] blahblahblah
> Shubha D. ramanishubharam...@gmail.com
> shubharam...@yahoo.com
>
>
> On Thursday, September 24, 2015 2:44 PM, Shubha Ramani
> <shubharam...@yahoo.com> wrote:
>
>
> Indeed Laszlo ! Thanks kindly for your detailed help. Will follow through
> with your tips !
>
> Sent from Shubha Ramani's iPhone 6 Plus
>
> > On Sep 24, 2015, at 2:29 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> >
> > Laszlo
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
--
=============================================================================
-Bill Paul (510) 749-2329 | Senior Member of Technical Staff,
wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
"I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
