Here's the latest log. It hangs in the emulator. I've tried both emulators, but to no avail.
Thanks, Myles
On Wed, Oct 15, 2008 at 9:14 AM, Myles Watson mylesgw@gmail.com wrote:
Here's the latest log. It hangs in the emulator. I've tried both emulators, but to no avail.
Stick with the "non emulator". This is incredible progress!
can you stop it and get us a register dump and tell us where eip is.
If we can get your commits to svn I can try this tonight.
ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 15, 2008 11:05 AM To: Myles Watson Cc: Coreboot Subject: Re: Serengeti vga hang
On Wed, Oct 15, 2008 at 9:14 AM, Myles Watson mylesgw@gmail.com wrote:
Here's the latest log. It hangs in the emulator. I've tried both emulators, but to no avail.
Stick with the "non emulator".
I'm sorry I didn't get what you meant here. vm86 and x86emu are the two choices to run the ROM and I'm using x86emu.
can you stop it and get us a register dump and tell us where eip is.
I'm looking for how to get a register dump, but I don't see it.
If we can get your commits to svn I can try this tonight.
Great.
Thanks, Myles
On Wed, Oct 15, 2008 at 10:22 AM, Myles Watson mylesgw@gmail.com wrote:
Stick with the "non emulator".
I'm sorry I didn't get what you meant here. vm86 and x86emu are the two choices to run the ROM and I'm using x86emu.
stick with vm86
can you stop it and get us a register dump and tell us where eip is.
I'm looking for how to get a register dump, but I don't see it.
It is a command of some sort in the debug window. You have to view debug and then type help and it should be there.
ron
Myles Watson wrote:
Here's the latest log. It hangs in the emulator. I've tried both emulators, but to no avail.
Nothing jumped out at me why you might be having a problem with VGA.
These are some general v3 comments. I have a good feel for the new dts/device scanning so some questions may just be dumb.
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: Ram1.0, setting up CPU 0x00 northbridge registers
Choosing fallback boot.
...
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.
prepare to InitDram:00000000000000010000000200000003000000040000000500000006000000070000000800000009
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.
PCI: scan devfn 0xc0 to 0xff PCI: devfn 0xc0
What is this for? When scanning PCI stuff
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...
Where is phase4_enable_disable? Shouldn't it happen before Phase 4: Reading resources ?
There is some 8111/8132 setup that might be causing the VGA issue?
Marc
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
ron minnich wrote:
On Wed, Oct 15, 2008 at 10:36 AM, Marc Jones Marc.Jones@amd.com wrote:
...
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.
Sorry but I don't see any phase4_enable_disable in the output. It is not being called in device.c dev_phase4(). I think that is a problem.
Marc
On Wed, Oct 15, 2008 at 11:02 AM, Marc Jones Marc.Jones@amd.com wrote:
ron minnich wrote:
Sorry but I don't see any phase4_enable_disable in the output. It is not being called in device.c dev_phase4(). I think that is a problem.
see pci_probe_dev.
And, hey, if I could get you all to use kscope, you would just ask kscope to show you where it's called :-)
I'm not saying it's right but ... it's there.
ron
I was wrong about the bridge bit. Here's the output from the SimNOW windows when it dies: EAX=0000B102 EBX=0000002E ECX=000C2067 EDX=000C1022 ESI=00010000 EDI=000D0000 ESP=000063D0 EBP=000CF11C CS=FFFF DS=C000 ES=0000 FS=0000 GS=0000 SS=0000 EFLAGS=oditsZaPc GIF=1 ASID=00000000 HCR3=0000000000000000 VMHSAVEPA=0000000000000000 GuestVMCBPA=0000000000000000
FFFF:0051 0000 add [bx+si],al FFFF:0053 0000 add [bx+si],al FFFF:0055 0000 add [bx+si],al FFFF:0057 0000 add [bx+si],al FFFF:0059 0000 add [bx+si],al FFFF:005B 0000 add [bx+si],al FFFF:005D 0000 add [bx+si],al FFFF:005F 00FF add bh,bh /*Hightlighted line */ FFFF:0061 FF FFFF:0062 FF
00000000,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000010,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 00000020,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 00000030,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000040,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 00000050,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 00000060,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000070,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a.
Execution halted due to Halt
Thanks, Myles
On Wed, Oct 15, 2008 at 1:03 PM, Myles Watson mylesgw@gmail.com wrote:
I was wrong about the bridge bit. Here's the output from the SimNOW windows when it dies: EAX=0000B102 EBX=0000002E ECX=000C2067 EDX=000C1022 ESI=00010000 EDI=000D0000 ESP=000063D0 EBP=000CF11C CS=FFFF DS=C000 ES=0000 FS=0000 GS=0000 SS=0000 EFLAGS=oditsZaPc
I would have thought CS =C000 here. I'm looking there first.
Myles
GIF=1 ASID=00000000 HCR3=0000000000000000 VMHSAVEPA=0000000000000000 GuestVMCBPA=0000000000000000
FFFF:0051 0000 add [bx+si],al FFFF:0053 0000 add [bx+si],al FFFF:0055 0000 add [bx+si],al FFFF:0057 0000 add [bx+si],al FFFF:0059 0000 add [bx+si],al FFFF:005B 0000 add [bx+si],al FFFF:005D 0000 add [bx+si],al FFFF:005F 00FF add bh,bh /*Hightlighted line */ FFFF:0061 FF FFFF:0062 FF
00000000,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000010,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 00000020,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 00000030,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000040,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 00000050,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 00000060,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 00000070,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a.
Execution halted due to Halt
Thanks, Myles
ron minnich wrote:
On Wed, Oct 15, 2008 at 11:02 AM, Marc Jones Marc.Jones@amd.com wrote:
ron minnich wrote:
Sorry but I don't see any phase4_enable_disable in the output. It is not being called in device.c dev_phase4(). I think that is a problem.
see pci_probe_dev.
And, hey, if I could get you all to use kscope, you would just ask kscope to show you where it's called :-)
I'm not saying it's right but ... it's there.
Should it really be a phase3 function? Should it be run after any phase3_enable_scan?
Marc
there is a phase 3 enable that enables a device (if needed) to appear or disappear in config space. There is a phase 4 enable disable to enable a device's resources to be read. Both of these usages appeared in v2.
Sorry, I'm worn out (long day) if this makes no sense let me know.
ron
ron minnich wrote:
there is a phase 3 enable that enables a device (if needed) to appear or disappear in config space. There is a phase 4 enable disable to enable a device's resources to be read. Both of these usages appeared in v2.
Sorry, I'm worn out (long day) if this makes no sense let me know.
Your explanation of what it is makes sense. What doesn't make sense is that it is never called during phase4. It is no better than v2 if name doesn't tell you when it is used. The only time it is used is in pci device scan which is really phase1.
Marc
On Wed, Oct 15, 2008 at 4:10 PM, Marc Jones Marc.Jones@amd.com wrote:
Your explanation of what it is makes sense. What doesn't make sense is that it is never called during phase4. It is no better than v2 if name doesn't tell you when it is used. The only time it is used is in pci device scan which is really phase1.
Then it's broken and we'll have to fix it. I must have gotten confused.
ron
On Wed, Oct 15, 2008 at 4:10 PM, Marc Jones Marc.Jones@amd.com wrote:
Your explanation of what it is makes sense. What doesn't make sense is that it is never called during phase4. It is no better than v2 if name doesn't tell you when it is used. The only time it is used is in pci device scan which is really phase1.
I think you've just pointed out a bug that's been in there since I brought this code over from v2.
In truth, the v2 use of enable is very inconsistent. I compiled all the ways that it was used in v2 and it turns out to be pretty ad-hoc. The reason for this is the very messy nature of pc hardware; as more and more strange cases showed up, people used device functions in dfifferent ways.
I think I did not get it right in v3. I think that we're going to have to go through and fix this ... look at each phase4 enable usage and see what it really means. Sorry for this mistake.
I think that phase4_enable_disable needs a new name, which will make it easy to hunt down usage and try to figure out where it ought to go.
phase4_resource_control? Meaning that it enables or disables resource read/write depending on enabled? I believe most uses of it belong in phase3_enable_scan actually.
ron
ron
There is some 8111/8132 setup that might be causing the VGA issue?
Most of your questions I don't have answers for, but right now I'm trying to figure out why the VGA_ENABLE bit in the 8111 gets cleared after it's set.
Thanks, Myles
-
Marc Jones -
Myles Watson -
ron minnich