[coreboot] More v3 questions/issues

Myles Watson mylesgw at gmail.com
Tue Dec 16 00:22:53 CET 2008


On Mon, Dec 15, 2008 at 4:15 PM, Corey Osgood <corey.osgood at gmail.com>wrote:

> On Mon, Dec 15, 2008 at 6:12 PM, Corey Osgood <corey.osgood at gmail.com>wrote:
>
>> On Mon, Dec 15, 2008 at 5:25 PM, ron minnich <rminnich at gmail.com> wrote:
>>
>>> On Mon, Dec 15, 2008 at 9:24 AM, Myles Watson <mylesgw at gmail.com> wrote:
>>>
>>> > I saw that you moved something from phase6_init to phase2.  I don't
>>> think
>>> > that's necessary.  My understanding is that only things that are
>>> necessary
>>> > to enable basic things like bus reading and writing should go there.
>>>
>>> Yes, Myles is right: in general phase 2 is not needed, it is really
>>> there for pathological hardware ...
>>>
>>
Sorry.  I did misread it.

Ignore that part of the patch, I'm plugging at a couple other things at the
>> moment. I think you're reading the patch wrong, nothing should be moved to
>> phase2, some things are moved from phase2 to phase3_chip_setup (which is not
>> called atm), others might be moved to phase6_init. My problem at the moment
>> is the hang after pci_scan_bus with the error about being called for a PCI
>> domain, which is the same way it's called in qemu.
>>
>
> I thought pci_scan_bus() was causing the hang, but the PCI domain error
> doesn't actually do anything, pci_scan_bus just continues along happily.
>

That's right.  It's not really an error.  It's a leftover from v2, when
there was a bus device for every bus.  It's correct to call pci_scan_bus
from a domain.


> I need to look at a qemu boot log to see where the next step should be,
>> does anyone have one handy? I don't currently have QEMU set up.
>>
>
Here's a snippet from the log.  I think you're probably hanging in
pci_probe_dev.  That's why I asked if anything needed to be set up before a
PCI config read.

pci_get_dev gets the device structure from the tree
pci_probe_dev actually talks to it on the bus.

Thanks,
Myles

Phase 3: Enumerating buses...
dev_phase3_scan: scanning root(Root Device)
scan_static_bus for root (Root Device)
cpus(CPU: 00) enabled
domain_0(PCI_DOMAIN: 0000) enabled
domain_0(PCI_DOMAIN: 0000) scanning...
dev_phase3_scan: scanning domain_0(PCI_DOMAIN: 0000)
pci_domain_scan_bus: calling pci_scan_bus
pci_scan_bus start bus->dev domain_0 bus 0
ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is
PCI_DOMAIN: 0000
PCI: pci_scan_bus for bus 00
pci_scan_bus: old_devices domain_0_pci_0_0, dev for this bus domain_0
PCI: scan devfn 0x0 to 0xff
PCI: devfn 0x0
pci_get_dev: list is NOT NULL, *list is NOT NULL
pci_get_dev: check dev domain_0_pci_0_0
pci_get_dev: check dev domain_0_pci_0_0 it has devfn 0x00
PCI: pci_scan_bus pci_get_dev returns dev domain_0_pci_0_0
set_pci_ops: dev domain_0_pci_0_0 already has ops of type 20504349
PCI: 00:00.0 [PCI: 8086:1237] enabled
PCI: pci_scan_bus pci_probe_dev returns dev domain_0_pci_0_0
Not a multi function device, or the device is not present. Skip to next
device.
PCI: devfn 0x8
pci_get_dev: list is NOT NULL, *list is NOT NULL
pci_get_dev: check dev domain_0_pci_1_0
pci_get_dev: check dev domain_0_pci_1_0 it has devfn 0x08
PCI: pci_scan_bus pci_get_dev returns dev domain_0_pci_1_0
set_pci_ops: dev domain_0_pci_1_0 already has ops of type 20504349
PCI: 00:01.0 [PCI: 8086:7000] enabled
PCI: pci_scan_bus pci_probe_dev returns dev domain_0_pci_1_0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081215/cd11c2ea/attachment.html>


More information about the coreboot mailing list