pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
u16 class, vendor;
unsigned bus;
int devfn;
struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST 0x0600
#define
ron minnich wrote:
I thought that even without VSA, a pci config read of 0:1.0 would give
me something reasonable back. But the devices that are found without
VSA are 0:c.0, 0:d.0, and then 0:f.0 etc.
Without VSA, the only thing you are going to see south of LX are the
real hardware PCI
On Sat, Jan 19, 2008 at 09:09:03AM -0500, Tom Sylla wrote:
Of course, you can access MSRs on those devices before VSA is
loaded.
It would be really awesome to support the bus natively.
//Peter
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 19.01.2008 09:15, ron minnich wrote:
I am wondering for VSA if we should not have a post-ram step where we
find all LAR entries with names like
prestage2/*
and run them. Still not sure of the right approach for VSA. Is VSA so
special that we shouldn't worry about handling it in the
On Jan 19, 2008 7:58 AM, Peter Stuge [EMAIL PROTECTED] wrote:
It would be really awesome to support the bus natively.
I get this request a lot -- just heard the same comment a few days ago.
We could create a method to do this natively, but would need to create
pci bios tables for linux, or
ron minnich wrote:
pci_sanity_check is confusing. It looks like this:
static int pci_sanity_check(const struct pci_bus_operations *o)
{
u16 class, vendor;
unsigned bus;
int devfn;
struct bus pbus; /* Dummy device */
#define PCI_CLASS_BRIDGE_HOST 0x0600
6 matches
Mail list logo