On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones Marc.Jones@amd.com wrote:
setting up resource map ex offset.... (0+0,18+0,1+0,44) & 0000f8f8 | 00000000+00000000 (0+0,18+0,1+0,4c) & 0000f8f8 | 00000001+00000000
...
done.
I don't think that resource setup needs to be done this early. There are no resources before HT init. It should go just before:
we can move it. I had not gotten around to doing that. V2 did it this early. This type of resource setup is first on most (all?) opteron mainboards in v2.
Ram1.0, setting up CPU 0x00 northbridge registers
Choosing fallback boot.
It does this because of cmos IIRC or something.
...
LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'.
I think that this came up way back when, but why is fallback tried first? Is this a configuration mistake? It is a waste of time which is making SimNow take even longer.
because we don't have the fallback/normal infrastructure set up yet.
prepare to InitDram:00000000 00000001 00000002 00000003 00000004 00000005 00000006 00000007 00000008 00000009
That is some strange output....
find_device_operations: cons 0x00015260, cons id PCI: 1022:1100 find_device_operations: check all_device_operations[i] 0x00015800 dev_id_string: Unknown device ID type: 0 find_device_operations: cons 0x00015800, cons id Unknown …À‰ÁÆ À¤ constructor: constructor is 0x00000000 No ops found and no constructor called for PNP: 0000. new_device: devcnt 4 find_device_operations: check all_device_operations[i] 0x00015200
This is the CPU HT device. This section loops several times. What is coreboot trying to do?
And then some stuff gets setup and it loop some more... Yeah, keep seeing this output come up again and again.
yes, it is SPEW. It's really verbose and it is not good or bad -- it's just there.
For each device in the static tree, it walks the set of constructors, trying to match the static tree device to a constructor. So you see a lot of same output over and over. This thing also happens in v2 but it's invislble.
PCI: scan devfn 0xc0 to 0xff PCI: devfn 0xc0
What is this for? When scanning PCI stuff
will try to find out.
PCI: devfn 0xc4 pci_scan_get_dev: list is 0x000cf084, *list is 0x00016680 pci_scan_get_dev: check dev domain_0_pci_1_0 pci_scan_get_dev: check dev domain_0_pci_1_0 it has devfn 0x08 pci_scan_get_dev: check dev domain_0_pci1_18_0 pci_scan_get_dev: check dev domain_0_pci1_18_0 it has devfn 0xc0 pci_scan_get_dev: check dev domain_0_pci2_18_0 pci_scan_get_dev: check dev domain_0_pci2_18_0 it has devfn 0xc0 pci_scan_get_dev: check dev domain_0_ioport_2e pci_scan_get_dev: child domain_0_ioport_2e(IOPORT: 2e) not a pci device: it's type 11 pci_scan_get_dev: check dev dynamic PNP: 002e.0
When scanning for PCI devices PNP IO areas should probably be skipped or I may just misunderstand what it is doing here...
it is being skipped. "domain_0_ioport_2e(IOPORT: 2e) not a pci device: it's type 11" The message is unclear.
Where is phase4_enable_disable? Shouldn't it happen before Phase 4: Reading resources ?
It does, for each device, if it is set up for that device.
phase4_enable_disable was in v2 in a different name. The problem is that sometimes you have to enable a device to read the resources. phase4_enable_disable looks at dev->enabled and enables "whatever has to be enabled" -- it's device dependent -- so that resources can be read. It's called enable_disable because it can do both, depending on device_enabled, and I was not clever enough to think of a better name :-)
For most devices, it's empty.
There is some 8111/8132 setup that might be causing the VGA issue?
not sure. I'd like to see where it's hanging. I think you're probably right -- I bet it's reading a register, waiting for a bit to go low, and never seeing anything but f's. That's the common issue with vga failure.
ron