On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones <[EMAIL PROTECTED]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
