SimNOW goes off into the weeds when int 1a is called. Here's the trace of execution:
C000:0003 E9E200 jmp loc_00e8 C000:00E8 60 pusha C000:00E9 E84331 call loc_322f C000:322F B800C0 mov ax,c000 C000:3232 8ED8 mov ds,ax C000:3234 BE0000 mov si,0000 C000:3237 BB2C00 mov bx,002c C000:323A 8B17 mov dx,[bx] C000:323C BB2E00 mov bx,002e C000:323F 8B0F mov cx,[bx] C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a FFFF:FFFF FF
I'm looking for the place where the interrupt vector was supposed to have been set.
Thanks, Myles
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson mylesgw@gmail.com wrote:
C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a FFFF:FFFF FF
Yep, "b102" is not a common signature.
I'm looking for the place where the interrupt vector was supposed to have been set.
I am confused, your coreboot log shows several int1a before the failure:
int1a vector at 10ffef dev_find_device: find PCI: 1022:2067 ... int1a vector at 37da2 int1a vector at 37da2 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682
-----Original Message----- From: Tom Sylla [mailto:tsylla@gmail.com] Sent: Wednesday, October 15, 2008 2:04 PM To: Myles Watson Cc: Coreboot; ron minnich Subject: Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson mylesgw@gmail.com wrote:
C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a FFFF:FFFF FF
Yep, "b102" is not a common signature.
I'm looking for the place where the interrupt vector was supposed to
have
been set.
I am confused, your coreboot log shows several int1a before the failure:
int1a vector at 10ffef dev_find_device: find PCI: 1022:2067 ... int1a vector at 37da2 int1a vector at 37da2 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682
Sorry. I should have sent a new log. It's the same as the old one except at the end. Once I switched to vm86 instead of x86emu, there is no longer any output after "Copying VGA ROM Image ..."
Thanks, Myles
Myles Watson wrote:
-----Original Message----- From: Tom Sylla [mailto:tsylla@gmail.com] Sent: Wednesday, October 15, 2008 2:04 PM To: Myles Watson Cc: Coreboot; ron minnich Subject: Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson mylesgw@gmail.com wrote:
C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a FFFF:FFFF FF
Yep, "b102" is not a common signature.
I'm looking for the place where the interrupt vector was supposed to
have
been set.
I am confused, your coreboot log shows several int1a before the failure:
int1a vector at 10ffef dev_find_device: find PCI: 1022:2067 ... int1a vector at 37da2 int1a vector at 37da2 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682 int1a vector at 76682
Sorry. I should have sent a new log. It's the same as the old one except at the end. Once I switched to vm86 instead of x86emu, there is no longer any output after "Copying VGA ROM Image ..."
Is int1a pci bios calls supported in the emulators?
Marc
Is int1a pci bios calls supported in the emulators?
It seems to work in v2. I've never looked at them before today.
Thanks, Myles
On Wed, Oct 15, 2008 at 1:26 PM, Marc Jones Marc.Jones@amd.com wrote:
Is int1a pci bios calls supported in the emulators?
yes they are.
I'm not sure what is going wrong here.
ron
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
Thanks, Myles
Myles Watson wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
That isn't the same emulator that most of v2 uses. setup_realmode_idt is certainly required. 0x18 is a strange INT to see. http://www.ctyme.com/intr/int.htm
Can you get back to the calling code and see what it was doing?
Marc
-----Original Message----- From: Marc Jones [mailto:Marc.Jones@amd.com] Sent: Wednesday, October 15, 2008 2:45 PM To: Myles Watson Cc: Tom Sylla; ron minnich; Coreboot Subject: Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
That isn't the same emulator that most of v2 uses. setup_realmode_idt is certainly required. 0x18 is a strange INT to see. http://www.ctyme.com/intr/int.htm
Can you get back to the calling code and see what it was doing?
The VGA BIOS calls 1a, but it looks like too many things get pushed onto the stack, and it thinks it's 18 instead. I'm not an assembly programmer, but it looks like the problem is in callbiosint or handler. It looks like the registers are being pushed onto the stack too many times?
Thanks, Myles
Myles Watson wrote:
-----Original Message----- From: Marc Jones [mailto:Marc.Jones@amd.com] Sent: Wednesday, October 15, 2008 2:45 PM To: Myles Watson Cc: Tom Sylla; ron minnich; Coreboot Subject: Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
That isn't the same emulator that most of v2 uses. setup_realmode_idt is certainly required. 0x18 is a strange INT to see. http://www.ctyme.com/intr/int.htm
Can you get back to the calling code and see what it was doing?
The VGA BIOS calls 1a, but it looks like too many things get pushed onto the stack, and it thinks it's 18 instead. I'm not an assembly programmer, but it looks like the problem is in callbiosint or handler. It looks like the registers are being pushed onto the stack too many times?
Ewwww! This looks like a compiler function calling problem.
I think that the 0x18 comes from here : "biosprotect: \n" " .code32 \n" " movw $0x18, %ax\n" " mov %ax, %ds\n" " mov %ax, %es\n" " mov %ax, %fs\n" " mov %ax, %gs\n" " mov %ax, %ss\n" " lidt idtarg \n" " call biosint \n"
Which means that biosint isn't using variables from the stack but from the register.
Marc
On Wed, Oct 15, 2008 at 1:27 PM, Myles Watson mylesgw@gmail.com wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
when you're looking for a misaligned stack frame the registers are always interesting.
Note that edi looks like a 1a.
This code is unchanged for the most part since I wrote it. What you can do is look via gdb at the biosint function and see where it gets the int #. It is unlikely that this is a gcc problem. A misguided directive, on the other hand ...
let's look around:
gdb build/util/x86emu/vm86.o
Dump of assembler code for function biosint: 0x000004f3 <biosint+0>: push %esi 0x000004f4 <biosint+1>: mov %eax,%esi 0x000004f6 <biosint+3>: push %ebx 0x000004f7 <biosint+4>: sub $0x4,%esp 0x000004fa <biosint+7>: movzwl 0x34(%esp),%eax 0x000004ff <biosint+12>: mov 0x30(%esp),%ebx 0x00000503 <biosint+16>: mov %eax,(%esp) 0x00000506 <biosint+19>: push %esi 0x00000507 <biosint+20>: push $0x86 0x0000050c <biosint+25>: push $0x7 0x0000050e <biosint+27>: call 0x50f <biosint+28>
We are passing arg 1 in eax. How could this be?
Simple. We got Clever in v3:
-mregparm=3
A nice optimization that utterly destroys the bios interrupt support.
Myles, try setting -mregparm=0 and see if life is better.
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
ron
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
If it isn't more relevant because of CAR then away it goes.
//Peter
On 16.10.2008 01:13, Peter Stuge wrote:
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
__attribute__((stdcall)) will do this for you. Changing compilation mode makes code to -mregparm=0 makes the code bigger and slower and it will also possibly consume more stack which we don't have in MP setups.
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
If it isn't more relevant because of CAR then away it goes.
See above.
Regards, Carl-Daniel
On Wed, Oct 15, 2008 at 4:44 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.10.2008 01:13, Peter Stuge wrote:
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
__attribute__((stdcall)) will do this for you. Changing compilation mode makes code to -mregparm=0 makes the code bigger and slower and it will also possibly consume more stack which we don't have in MP setups.
ok let's do that. I was wondering about that too.
ron
On Wed, Oct 15, 2008 at 5:44 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 16.10.2008 01:13, Peter Stuge wrote:
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
__attribute__((stdcall)) will do this for you.
It doesn't work for me. I tried it in various places, but it doesn't change the way the parameters are handled.
void __attribute__ ((stdcall)) callbiosint(void) __attribute__ ((stdcall)) void callbiosint(void) void callbiosint(void) __attribute__ ((stdcall))
biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
Thanks, Myles
Changing compilation mode makes code to -mregparm=0 makes the code bigger and slower and it will also possibly consume more stack which we don't have in MP setups.
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
If it isn't more relevant because of CAR then away it goes.
See above.
Regards, Carl-Daniel
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[taking in Segher as gcc expert]
On 16.10.2008 14:53, Myles Watson wrote:
On Wed, Oct 15, 2008 at 5:44 PM, Carl-Daniel Hailfinger wrote:
On 16.10.2008 01:13, Peter Stuge wrote:
ron minnich wrote:
Myles, try setting -mregparm=0 and see if life is better.
Good find.
__attribute__((stdcall)) will do this for you.
It doesn't work for me. I tried it in various places, but it doesn't change the way the parameters are handled.
void __attribute__ ((stdcall)) callbiosint(void) __attribute__ ((stdcall)) void callbiosint(void) void callbiosint(void) __attribute__ ((stdcall))
biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
What about __attribute__((regparm(0))) ?
The gcc documentation is not clear on this, but a call made this way should take all of its arguments from the stack.
Segher: How do regparm(0) and stdcall differ for i386?
Regards, Carl-Daniel
What about __attribute__((regparm(0))) ?
The gcc documentation is not clear on this, but a call made this way should take all of its arguments from the stack.
Segher: How do regparm(0) and stdcall differ for i386?
"stdcall" means the callee pops the args from the stack when it returns; "cdecl" (the default) means the caller has to pop them. "stdcall" gives smaller code, but cannot work for functions without prototype (you shouldn't have such anyway, with ISO C -- but in olden days it was the norm). If you would like stdcall by default, use -mrtd.
"regparm" says how many integer arguments are passed in registers instead of on the stack. 0 is the default, and 3 is the maximum. The registers used are A, D, C. Use -mregparm=N to get some other default.
So, "stdcall" and "regparm" are orthogonal. stdcall would be good for coreboot (smaller code size), but regparm > 0 probably increases code size (try it though). Whatever you use, "special" code (context switching, etc. -- but also all assembler routines in general) need to be aware of the calling sequence in use, of course -- but they can always override it to something of their liking.
What is the actual problem you are trying to solve here?
Segher
Segher: How do regparm(0) and stdcall differ for i386?
"stdcall" means the callee pops the args from the stack when it returns; "cdecl" (the default) means the caller has to pop them. "stdcall" gives smaller code, but cannot work for functions without prototype (you shouldn't have such anyway, with ISO C -- but in olden days it was the norm). If you would like stdcall by default, use -mrtd.
"regparm" says how many integer arguments are passed in registers instead of on the stack. 0 is the default, and 3 is the maximum. The registers used are A, D, C. Use -mregparm=N to get some other default.
So, "stdcall" and "regparm" are orthogonal. stdcall would be good for coreboot (smaller code size), but regparm > 0 probably increases code size (try it though). Whatever you use, "special" code (context switching, etc. -- but also all assembler routines in general) need to be aware of the calling sequence in use, of course -- but they can always override it to something of their liking.
What is the actual problem you are trying to solve here?
We are compiling with -mregparm=3 and that breaks the assembly files that support interrupts in vm86.c because they expect the other calling convention.
The question is what attribute can be used to make those functions have the normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons.
Thanks, Myles
On Thu, Oct 16, 2008 at 7:58 AM, Myles Watson mylesgw@gmail.com wrote:
The question is what attribute can be used to make those functions have the normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons.
The simplest thing: put all the functions that need regparm=0 in one file, compile that file with regparm=0
ron
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Thursday, October 16, 2008 9:41 AM To: Myles Watson Cc: Segher Boessenkool; Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
On Thu, Oct 16, 2008 at 7:58 AM, Myles Watson mylesgw@gmail.com wrote:
The question is what attribute can be used to make those functions have
the
normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons.
The simplest thing: put all the functions that need regparm=0 in one file, compile that file with regparm=0
There's a warning in the man pages for gcc that says that you have to compile all the functions (including libraries) with the same setting.
Myles
On Thu, Oct 16, 2008 at 8:45 AM, Myles Watson mylesgw@gmail.com wrote:
-----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Thursday, October 16, 2008 9:41 AM To: Myles Watson Cc: Segher Boessenkool; Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
On Thu, Oct 16, 2008 at 7:58 AM, Myles Watson mylesgw@gmail.com wrote:
The question is what attribute can be used to make those functions have
the
normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons.
The simplest thing: put all the functions that need regparm=0 in one file, compile that file with regparm=0
There's a warning in the man pages for gcc that says that you have to compile all the functions (including libraries) with the same setting.
that's because they can not call each other otherwise if compiled with different regparm settings.
biosint is only called from assembly, so it really doesn't matter. The issue is that the assembly that calls biosint is written with as "regparm=0", from long ago, and the rules got changed when we set regparm=3.
Again, only functions called from assembly for vm86 mode need to be compiled with regparm=0.
ron
There's a warning in the man pages for gcc that says that you have to compile all the functions (including libraries) with the same setting.
It says that in the description of -mregparm, not of the function attribute "regparm", and it is slightly misleading: -mregparm specifies the default for any function without an explicit attribute, so you better use the same -mregparm option for any file that contains functions (or calls functions) without explicit attribute; but you _can_ have multiple regparm settings in total.
biosint is only called from assembly, so it really doesn't matter. The issue is that the assembly that calls biosint is written with as "regparm=0", from long ago, and the rules got changed when we set regparm=3.
Again, only functions called from assembly for vm86 mode need to be compiled with regparm=0.
Whatever calling sequence you choose, please put the required attribute for any function that needs something specific in the declaration for that function (in a header file). This includes any function implemented in assembler (except those without arguments at all).
This will save you a lot of headaches ;-)
Segher
-----Original Message----- From: Segher Boessenkool [mailto:segher@kernel.crashing.org] Sent: Thursday, October 16, 2008 10:30 AM To: ron minnich Cc: Myles Watson; Carl-Daniel Hailfinger; Coreboot Subject: Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
There's a warning in the man pages for gcc that says that you have to compile all the functions (including libraries) with the same setting.
It says that in the description of -mregparm, not of the function attribute "regparm", and it is slightly misleading: -mregparm specifies the default for any function without an explicit attribute, so you better use the same -mregparm option for any file that contains functions (or calls functions) without explicit attribute; but you _can_ have multiple regparm settings in total.
biosint is only called from assembly, so it really doesn't matter. The issue is that the assembly that calls biosint is written with as "regparm=0", from long ago, and the rules got changed when we set regparm=3.
Again, only functions called from assembly for vm86 mode need to be compiled with regparm=0.
Whatever calling sequence you choose, please put the required attribute for any function that needs something specific in the declaration for that function (in a header file). This includes any function implemented in assembler (except those without arguments at all).
This will save you a lot of headaches ;-)
I appreciate the clarification.
Thanks, Myles
Whatever calling sequence you choose, please put the required attribute for any function that needs something specific in the declaration for that function (in a header file). This includes any function implemented in assembler (except those without arguments at all).
This will save you a lot of headaches ;-)
I appreciate the clarification.
Thanks, Myles
This patch makes the vm86 call succeed. It
1. moves the run_bios function down so it can call setup_realmode_idt 2. adds the __attribute__((regnum(0))) to biosint because it is called from assembly
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
On 16.10.2008 17:41, ron minnich wrote:
On Thu, Oct 16, 2008 at 7:58 AM, Myles Watson mylesgw@gmail.com wrote:
The question is what attribute can be used to make those functions have the normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons.
The simplest thing: put all the functions that need regparm=0 in one file, compile that file with regparm=0
Indeed simple, but it won't work because every function outside this file, but called from this file will have a calling convention conflict. The caller will assume regparm(0), the callee will assume regparm(3). Boom.
Myles, please go with __attribute__((regparm(0))) for the functions that need it.
Regards, Carl-Daniel
let's look around:
gdb build/util/x86emu/vm86.o
Dump of assembler code for function biosint: 0x000004f3 <biosint+0>: push %esi 0x000004f4 <biosint+1>: mov %eax,%esi 0x000004f6 <biosint+3>: push %ebx 0x000004f7 <biosint+4>: sub $0x4,%esp 0x000004fa <biosint+7>: movzwl 0x34(%esp),%eax 0x000004ff <biosint+12>: mov 0x30(%esp),%ebx 0x00000503 <biosint+16>: mov %eax,(%esp) 0x00000506 <biosint+19>: push %esi 0x00000507 <biosint+20>: push $0x86 0x0000050c <biosint+25>: push $0x7 0x0000050e <biosint+27>: call 0x50f <biosint+28>
We are passing arg 1 in eax. How could this be?
Simple. We got Clever in v3:
-mregparm=3
A nice optimization that utterly destroys the bios interrupt support.
Myles, try setting -mregparm=0 and see if life is better.
I'll try it when I get back to that machine. My laptop isn't AMD64, so I can't run SimNOW on it.
Thanks for finding that.
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
I'll be interested to see how much faster v3 is when it's not set to SPEW. Right now it seems a lot slower than v2dsr on SimNOW.
Myles
Myles Watson wrote:
I'll be interested to see how much faster v3 is when it's not set to SPEW.
Quite a lot on geodelx.
//Peter
On Wed, Oct 15, 2008 at 4:27 PM, Myles Watson mylesgw@gmail.com wrote:
I'll be interested to see how much faster v3 is when it's not set to SPEW. Right now it seems a lot slower than v2dsr on SimNOW.
v3 is far faster than romcc v2 of course. Is it faster than CAR v2? that's not clear yet. My guess is it may not be due to the multiple invocations of rom-based code. I think that is fixable but we'll see.
ron
On Wed, Oct 15, 2008 at 5:00 PM, ron minnich rminnich@gmail.com wrote:
On Wed, Oct 15, 2008 at 1:27 PM, Myles Watson mylesgw@gmail.com wrote:
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga.
Copying VGA ROM image from 0xfe040000 to 0xc0000, 0x8000 bytes BREAK HERE run_bios = 0x0000944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x10000 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc0000000 esp 0xd0000 edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18
when you're looking for a misaligned stack frame the registers are always interesting.
Note that edi looks like a 1a.
This code is unchanged for the most part since I wrote it. What you can do is look via gdb at the biosint function and see where it gets the int #. It is unlikely that this is a gcc problem. A misguided directive, on the other hand ...
let's look around:
gdb build/util/x86emu/vm86.o
Dump of assembler code for function biosint: 0x000004f3 <biosint+0>: push %esi 0x000004f4 <biosint+1>: mov %eax,%esi 0x000004f6 <biosint+3>: push %ebx 0x000004f7 <biosint+4>: sub $0x4,%esp 0x000004fa <biosint+7>: movzwl 0x34(%esp),%eax 0x000004ff <biosint+12>: mov 0x30(%esp),%ebx 0x00000503 <biosint+16>: mov %eax,(%esp) 0x00000506 <biosint+19>: push %esi 0x00000507 <biosint+20>: push $0x86 0x0000050c <biosint+25>: push $0x7 0x0000050e <biosint+27>: call 0x50f <biosint+28>
We are passing arg 1 in eax. How could this be?
Simple. We got Clever in v3:
-mregparm=3
A nice optimization that utterly destroys the bios interrupt support.
Myles, try setting -mregparm=0 and see if life is better.
I get a Execution halted due to Stopping SimNow due to unhandled case(s)
EAX=00000001 EBX=000163A8 ECX=80012010 EDX=00000FDC ESI=0000B10D EDI=00000001 ESP=00000F34 EBP=00000020 CS=0010 DS=0018 ES=0018 FS=0018 GS=0018 SS=0018 EFLAGS=oditSzapc GIF=1 ASID=00000000 HCR3=0000000000000000 VMHSAVEPA=0000000000000000 GuestVMCBPA=0000000000000000
0010:FFFFF07D 0000 add [eax],al 0010:FFFFF07F 007000 add [eax+00],dh 0010:FFFFF082 0000 add [eax],al 0010:FFFFF084 0018 add [eax],bl 0010:FFFFF086 01B44800000000 add [eax+ecx*2+00000000],esi 0010:FFFFF08D 0000 add [eax],al 0010:FFFFF08F 007000 add [eax+00],dh 0010:FFFFF092 0000 add [eax],al 0010:FFFFF094 0018 add [eax],bl 0010:FFFFF096 01BC4800000000 add [eax+ecx*2+00000000],edi 0010:FFFFF09D FF
The last output on the serial port is: biosint: INT# 0x1a biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0000 esi 0x10000 biosint: ip 0x3246 cs 0xc000 flags 0x46 dev_find_device: find PCI: 1022:2067 Check Root Device Check CPU: 00 Check APIC: 00 Check PCI: 00:01.0 Check PCI: 1022:7462 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7458 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:1100 Check PCI: 1022:1100 Check PCI: 00:02.0 Check PCI: 1022:1100 Check PCI: 1022:1101 Check PCI: 1022:1102 Check PCI: 1022:1103 Check IOPORT: 2e Check APIC_CLUSTER: 1022:1100 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PCI: 1022:7460 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746b Check PCI: 1022:746d Check PCI: 1022:746e Check PCI: 1022:746f Check PCI: 1022:7459 Check PCI: 1022:7458 Check PCI: 1022:7459 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7463 Check PCI: 1022:7462 Check PCI: 1022:2067 found 0xb102: return 0x120 biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x10000 biosint: ip 0x325a cs 0xc000 flags 0x46 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 biosint: INT# 0x1a biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x10000 biosint: ip 0x3269 cs 0xc000 flags 0x46 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x10000 biosint: ip 0x3283 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 biosint: ip 0x3294 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100ad biosint: ip 0x32a2 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x10 val 0xfd000000 biosint: INT# 0x1a biosint: eax 0xb10d ebx 0x120 ecx 0xffffffff edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100a9 biosint: ip 0x32b3 cs 0xc000 flags 0x46
I vote we get rid of this type of Cleverness. It's just not performance critical in a bios. We're not an OS and we should keep it simple. I don't think we'll live or die on 3 on-stack variables.
ron
On Thu, Oct 16, 2008 at 5:39 AM, Myles Watson mylesgw@gmail.com wrote: tter.
I get a Execution halted due to Stopping SimNow due to unhandled case(s)
EAX=00000001 EBX=000163A8 ECX=80012010 EDX=00000FDC ESI=0000B10D EDI=00000001 ESP=00000F34 EBP=00000020 CS=0010 DS=0018 ES=0018 FS=0018 GS=0018 SS=0018 EFLAGS=oditSzapc GIF=1 ASID=00000000 HCR3=0000000000000000 VMHSAVEPA=0000000000000000 GuestVMCBPA=0000000000000000
0010:FFFFF07D 0000 add [eax],al 0010:FFFFF07F 007000 add [eax+00],dh 0010:FFFFF082 0000 add [eax],al 0010:FFFFF084 0018 add [eax],bl 0010:FFFFF086 01B44800000000 add [eax+ecx*2+00000000],esi 0010:FFFFF08D 0000 add [eax],al 0010:FFFFF08F 007000 add [eax+00],dh 0010:FFFFF092 0000 add [eax],al 0010:FFFFF094 0018 add [eax],bl 0010:FFFFF096 01BC4800000000 add [eax+ecx*2+00000000],edi 0010:FFFFF09D FF
see where this is is build/coreboot.map. It looks like garbage to me.
The last output on the serial port is: biosint: INT# 0x1a biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0000 esi 0x10000 biosint: ip 0x3246 cs 0xc000 flags 0x46 dev_find_device: find PCI: 1022:2067 Check Root Device Check CPU: 00 Check APIC: 00 Check PCI: 00:01.0 Check PCI: 1022:7462 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7458 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:1100 Check PCI: 1022:1100 Check PCI: 00:02.0 Check PCI: 1022:1100 Check PCI: 1022:1101 Check PCI: 1022:1102 Check PCI: 1022:1103 Check IOPORT: 2e Check APIC_CLUSTER: 1022:1100 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PCI: 1022:7460 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746b Check PCI: 1022:746d Check PCI: 1022:746e Check PCI: 1022:746f Check PCI: 1022:7459 Check PCI: 1022:7458 Check PCI: 1022:7459 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7463 Check PCI: 1022:7462 Check PCI: 1022:2067 found 0xb102: return 0x120
so that worked.
biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x10000 biosint: ip 0x325a cs 0xc000 flags 0x46 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 biosint: INT# 0x1a biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x10000 biosint: ip 0x3269 cs 0xc000 flags 0x46 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x10000 biosint: ip 0x3283 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 biosint: ip 0x3294 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100ad biosint: ip 0x32a2 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x10 val 0xfd000000 biosint: INT# 0x1a biosint: eax 0xb10d ebx 0x120 ecx 0xffffffff edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100a9 biosint: ip 0x32b3 cs 0xc000 flags 0x46
going through looking for several things I guess? The esp looks ok.
I suggest you set a break at c32b3 and see what you see.
ron
2008/10/16 ron minnich rminnich@gmail.com
On Thu, Oct 16, 2008 at 5:39 AM, Myles Watson mylesgw@gmail.com wrote: tter.
I get a Execution halted due to Stopping SimNow due to unhandled case(s)
EAX=00000001 EBX=000163A8 ECX=80012010 EDX=00000FDC ESI=0000B10D EDI=00000001 ESP=00000F34 EBP=00000020 CS=0010 DS=0018 ES=0018 FS=0018 GS=0018 SS=0018 EFLAGS=oditSzapc GIF=1 ASID=00000000 HCR3=0000000000000000 VMHSAVEPA=0000000000000000 GuestVMCBPA=0000000000000000
0010:FFFFF07D 0000 add [eax],al 0010:FFFFF07F 007000 add [eax+00],dh 0010:FFFFF082 0000 add [eax],al 0010:FFFFF084 0018 add [eax],bl 0010:FFFFF086 01B44800000000 add [eax+ecx*2+00000000],esi 0010:FFFFF08D 0000 add [eax],al 0010:FFFFF08F 007000 add [eax+00],dh 0010:FFFFF092 0000 add [eax],al 0010:FFFFF094 0018 add [eax],bl 0010:FFFFF096 01BC4800000000 add [eax+ecx*2+00000000],edi 0010:FFFFF09D FF
see where this is is build/coreboot.map. It looks like garbage to me.
The last output on the serial port is: biosint: INT# 0x1a biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0000 esi 0x10000 biosint: ip 0x3246 cs 0xc000 flags 0x46 dev_find_device: find PCI: 1022:2067 Check Root Device Check CPU: 00 Check APIC: 00 Check PCI: 00:01.0 Check PCI: 1022:7462 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7458 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:1100 Check PCI: 1022:1100 Check PCI: 00:02.0 Check PCI: 1022:1100 Check PCI: 1022:1101 Check PCI: 1022:1102 Check PCI: 1022:1103 Check IOPORT: 2e Check APIC_CLUSTER: 1022:1100 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PCI: 1022:7460 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746b Check PCI: 1022:746d Check PCI: 1022:746e Check PCI: 1022:746f Check PCI: 1022:7459 Check PCI: 1022:7458 Check PCI: 1022:7459 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7463 Check PCI: 1022:7462 Check PCI: 1022:2067 found 0xb102: return 0x120
so that worked.
biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x10000 biosint: ip 0x325a cs 0xc000 flags 0x46 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 biosint: INT# 0x1a biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x10000 biosint: ip 0x3269 cs 0xc000 flags 0x46 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x10000 biosint: ip 0x3283 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 biosint: ip 0x3294 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100ad biosint: ip 0x32a2 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x10 val 0xfd000000 biosint: INT# 0x1a biosint: eax 0xb10d ebx 0x120 ecx 0xffffffff edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100a9 biosint: ip 0x32b3 cs 0xc000 flags 0x46
going through looking for several things I guess? The esp looks ok.
I suggest you set a break at c32b3 and see what you see.
It looks like the problem is that coreboot is giving the VGA BIOS the wrong device number. I don't know why the reads succeed, but the device number should be 4 for the VGA controller, not 2. When it writes to the non-existant device, it triple faults.
Thanks, Myles
2008/10/16 Myles Watson mylesgw@gmail.com:
The last output on the serial port is: biosint: INT# 0x1a biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0000 esi 0x10000 biosint: ip 0x3246 cs 0xc000 flags 0x46 dev_find_device: find PCI: 1022:2067 Check Root Device Check CPU: 00 Check APIC: 00 Check PCI: 00:01.0 Check PCI: 1022:7462 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7458 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:1100 Check PCI: 1022:1100 Check PCI: 00:02.0 Check PCI: 1022:1100 Check PCI: 1022:1101 Check PCI: 1022:1102 Check PCI: 1022:1103 Check IOPORT: 2e Check APIC_CLUSTER: 1022:1100 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PNP: 0000 Check PCI: 1022:7460 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746b Check PCI: 1022:746d Check PCI: 1022:746e Check PCI: 1022:746f Check PCI: 1022:7459 Check PCI: 1022:7458 Check PCI: 1022:7459 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7463 Check PCI: 1022:7462 Check PCI: 1022:2067 found 0xb102: return 0x120
the wrong # here?
so that worked.
biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x10000 biosint: ip 0x325a cs 0xc000 flags 0x46 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 biosint: INT# 0x1a biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x10000 biosint: ip 0x3269 cs 0xc000 flags 0x46 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x10000 biosint: ip 0x3283 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 biosint: ip 0x3294 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100ad biosint: ip 0x32a2 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x10 val 0xfd000000 biosint: INT# 0x1a biosint: eax 0xb10d ebx 0x120 ecx 0xffffffff edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100a9 biosint: ip 0x32b3 cs 0xc000 flags 0x46
or here?
It looks like the problem is that coreboot is giving the VGA BIOS the wrong device number. I don't know why the reads succeed, but the device number should be 4 for the VGA controller, not 2. When it writes to the non-existant device, it triple faults.
at what point is it giving the wrong #?
nice detective work
ron
Check PCI: 1022:2067 found 0xb102: return 0x120
the wrong # here?
Yes. It should be device # 4 as far as I can tell. In the debugger when I do a config read to bus 1 dev 4 function 0 I get the right data back. When I do a read to bus 1 dev 2 function 0 I get an error that no device responded.
Like I said, I don't know why the reads succeed.
Thanks, Myles
On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson mylesgw@gmail.com wrote:
Check PCI: 1022:2067 found 0xb102: return 0x120
the wrong # here?
Yes. It should be device # 4 as far as I can tell. In the debugger when I do a config read to bus 1 dev 4 function 0 I get the right data back. When I do a read to bus 1 dev 2 function 0 I get an error that no device responded.
Like I said, I don't know why the reads succeed.
so you need some debug prints in the PCIBIOS support code.
ron
On Thu, Oct 16, 2008 at 9:49 AM, ron minnich rminnich@gmail.com wrote:
On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson mylesgw@gmail.com wrote:
Check PCI: 1022:2067 found 0xb102: return 0x120
the wrong # here?
Yes. It should be device # 4 as far as I can tell. In the debugger when
I
do a config read to bus 1 dev 4 function 0 I get the right data back.
When
I do a read to bus 1 dev 2 function 0 I get an error that no device responded.
Like I said, I don't know why the reads succeed.
so you need some debug prints in the PCIBIOS support code.
Check PCI: 1022:2067 PCI: 01:04.0 found bus->secondary = 0x1 dev->path.pci.devfn = 0x20 0xb102: return 0x120
Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 bits of the byte), so I'm still looking. Now it makes sense why the reads succeed, but the config write failure is puzzling. It's trying to write 0xffffffff to the BAR, but that changes the memory map, so after that write there's garbage everywhere. I still haven't found the config register that gets changed, but it's not in the VGA card's space.
Thanks, Myles
Myles Watson wrote:
On Thu, Oct 16, 2008 at 9:49 AM, ron minnich <rminnich@gmail.com mailto:rminnich@gmail.com> wrote:
On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson <mylesgw@gmail.com <mailto:mylesgw@gmail.com>> wrote: >> >> > Check PCI: 1022:2067 >> >> > found >> >> > 0xb102: return 0x120 >> >> the wrong # here? > > Yes. It should be device # 4 as far as I can tell. In the debugger when I > do a config read to bus 1 dev 4 function 0 I get the right data back. When > I do a read to bus 1 dev 2 function 0 I get an error that no device > responded. > > Like I said, I don't know why the reads succeed. > so you need some debug prints in the PCIBIOS support code.Check PCI: 1022:2067 PCI: 01:04.0 found bus->secondary = 0x1 dev->path.pci.devfn = 0x20 0xb102: return 0x120
Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 bits of the byte), so I'm still looking. Now it makes sense why the reads succeed, but the config write failure is puzzling. It's trying to write 0xffffffff to the BAR, but that changes the memory map, so after that write there's garbage everywhere. I still haven't found the config register that gets changed, but it's not in the VGA card's space.
Which BAR? What is the contents of 0xcf8? Not sure why, but writing 0xFFFFFFFF to a BAR is to get the size. It shoudl disable the device before it does that but sometimes they are sloppy and don't.
Marc
-----Original Message----- From: Marc Jones [mailto:marc.jones@amd.com] Sent: Thursday, October 16, 2008 10:32 AM To: Myles Watson Cc: ron minnich; Tom Sylla; Coreboot Subject: Re: [coreboot] SimNOW VGA int 1a
Myles Watson wrote:
On Thu, Oct 16, 2008 at 9:49 AM, ron minnich <rminnich@gmail.com mailto:rminnich@gmail.com> wrote:
On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson <mylesgw@gmail.com <mailto:mylesgw@gmail.com>> wrote: >> >> > Check PCI: 1022:2067 >> >> > found >> >> > 0xb102: return 0x120 >> >> the wrong # here? > > Yes. It should be device # 4 as far as I can tell. In the debugger when I > do a config read to bus 1 dev 4 function 0 I get the right data back. When > I do a read to bus 1 dev 2 function 0 I get an error that nodevice
> responded. > > Like I said, I don't know why the reads succeed. > so you need some debug prints in the PCIBIOS support code.Check PCI: 1022:2067 PCI: 01:04.0 found bus->secondary = 0x1 dev->path.pci.devfn = 0x20 0xb102: return 0x120
Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 bits of the byte), so I'm still looking. Now it makes sense why the reads succeed, but the config write failure is puzzling. It's trying to write 0xffffffff to the BAR, but that changes the memory map, so after that write there's garbage everywhere. I still haven't found the config register that gets changed, but it's not in the VGA card's space.
Which BAR? What is the contents of 0xcf8? Not sure why, but writing 0xFFFFFFFF to a BAR is to get the size. It shoudl disable the device before it does that but sometimes they are sloppy and don't.
cf8 = 0x80012010
Thanks, Myles
On Thu, Oct 16, 2008 at 9:35 AM, Myles Watson mylesgw@gmail.com wrote:
Which BAR? What is the contents of 0xcf8? Not sure why, but writing 0xFFFFFFFF to a BAR is to get the size. It shoudl disable the device before it does that but sometimes they are sloppy and don't.
cf8 = 0x80012010
bus 1 dev 4 BAR 1.
Writing ffffffff is fine. It's sizing.
This is puzzling.
ron
-
Carl-Daniel Hailfinger -
Marc Jones -
Marc Jones
-
Myles Watson -
Peter Stuge -
ron minnich -
Segher Boessenkool -
Tom Sylla