[SeaBIOS] [PATCH V2] pci: fixes to allow booting from extra root pci buses.

[Kevin O'Connor]

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