[SeaBIOS] [PATCH V2] pci: fixes to allow booting from extra root pci buses.
kevin at koconnor.net
Thu Jun 11 21:24:27 CEST 2015
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
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).
More information about the SeaBIOS