[coreboot] v3 comments - was Serengeti vga hang

ron minnich rminnich at gmail.com
Wed Oct 15 19:52:26 CEST 2008


On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones <Marc.Jones at 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




More information about the coreboot mailing list