[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