On Thu, Jun 11, 2015 at 08:34:56PM +0200, Laszlo Ersek wrote: > On 06/11/15 19:46, Marcel Apfelbaum wrote: > > On 06/11/2015 07:54 PM, Kevin O'Connor wrote: > >> On real machines, the firmware assigns the 4 - it's not a physical > >> address; it's a logical address (like all bus numbers in PCI). The > >> firmware might assign a totally different number on the next boot. > > Now I am confused. Don't get me wrong, I am not an expert on fw, I hardly > > try to understand it. > > > > I looked up a real hardware machine and it seemed to me that the extra > > pci root numbers > > are provided in the ACPI tables, meaning by the vendor, not the fw. > > In this case QEMU is the vendor, i440fx is the machine, right? > > > > I am not aware that Seabios/OVMF are deciding the bus numbers for the > > *PCI roots*. > > They are doing it for the pci-2-pci bridges of course. > > I saw that Seabios is trying to "guess" the root-buses by going over all > > the 0-0xff range > > and probing all the slots, looking for devices. So it expects the hw to > > be hardwired regarding > > PCI root buses. > > This is exactly how I understood it. > > We're not interested in placing such bus numbers in device paths that > are assigned during PCI enumeration. (Like subordinate bus numbers.) > We're talking about the root bus numbers. > > OVMF implements the same kind of probing that SeaBIOS does (based on > natural language description from Michael and Marcel, not on the actual > code). Devices on the root buses respond without any prior bus number > assignments.
Alas, that is not correct. Coreboot supports several AMD boards that have multiple southbridge chips which provide independent PCI root buses. These chips have to be configured and assigned a bus number prior to use (which coreboot does). -Kevin
