Hello Thomas,
I am working around another dev kit by Intel, the EP80579 which is shipped with the G550 card as well.
Same kind of crash :
copying VGA ROM Image from f4800000 to 0xc0000, 0x9000 bytes Real mode stub @00000500: 422 bytes Calling Option ROM... oprom: INT# 0x1a oprom: eax: 0000b102 ebx: 00000200 ecx: 1f001541 edx: 000210b9 oprom: ebp: 00023f40 esp: 00000fe8 edi: 000000f8 esi: 00000000 oprom: ip: 8125 cs: c000 flags: 00000046
What I do not have is the second INT#0x6 error and my edx value being different, well still dx being same anyway
What I would like to do is reproduce your resolution steps to confirm.
Would you be kind enough to describe your dummy handlers in x86.c as well as the method used to "inject" your patched ROM so I can reproduce your steps?
Thank you,
Arnaud
Thomas JOURDAN wrote:
Hi all
Yesterday I posted patches to support the Intel Eagle Eights evaluation board. The board comes with a Matrox G550 PCIe 1x graphics card (http://www.matrox.com/graphics/en/products/graphics_cards/g_series/g550pcie/). I had to disable the VGA console in order to boot, because Coreboot failed to execute it. All the 3 methods failed (x86emu, yabel and real mode). The problem is not related to the Eagle Heights board at all, that why I create a new thread.
So today I did investigate a little with a probe to figure out why it fails. Here you are my results :
- With x86emu :
... CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = 00000000 On card, rom address for PCI: 03:00.0 = fe800000 copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes entering emulator int1a vector at 0
And nothing more, the board is stuck.
- With realmode :
CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = 00000000 On card, rom address for PCI: 03:00.0 = fe800000 copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes Calling Option Rom... oprom: INT# 0x1a oprom: eax: 0000b102 ebx: 00130300 ecx: 1f001541 edx: 000010b9 oprom: ebp: 00139f70 esp: 00000fe8 edi: 001200f8 esi: 00130000 oprom: ip: 8125 cs: c000 flags: 00000046 error! oprom: INT# 0x6 oprom: eax: 0000e000 ebx: 00130300 ecx: 1f000004 edx: 00030001 oprom: ebp: 00139f70 esp: 00000fe4 edi: 001259fc esi: 00134c0b oprom: ip: 7a00 cs: c000 flags: 00000282 Unsupported software interrupt #0x6 error!
The first interrupt (int 1a, ax=b102) is PCI_FIND_DEVICE. It seems that the vga bios looks for an Ali chipset (vendor id dx=10b9, device id cx=1541), maybe for a workaround on this kind of mainboard. There is no such device so it fails. Then I have an interrupt 6 (invalid opcode). On another mainboard, this would be an interrupt 4 (overflow). Both interrupts occurs at the same instruction located at C000:7A00 (opcode 665Ah -> POP EDX).
- With Yabel :
CBFS: Could not find file pci102b,2527.rom In cbfs, rom address for PCI: 03:00.0 = 00000000 On card, rom address for PCI: 03:00.0 = fe800000 copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes Unexpected Exception: 0 @ 10:0011bfa1 - Halting Code: 0 eflags: 00010046 eax: 00000001 ebx: 00000061 ecx: 00000000 edx: 00000000 edi: 00000003 esi: 00000000 ebp: 00155abc esp: 00155a98
This time this is an interrupt 0 (divide error). Someone on the IRC suggested that it might be a missing timer setup leading to a division by zero.
I also tried with seabios but I don't have the log available here. Basically, because the int 1a fails, it seems that it exited the execution of the rom.
I focused my debugging on the real mode. First of all I added dummy handlers for int 4 and 6 in utils/x86emu/x86.c. This way, coreboot continues the execution of the rom but with the probe, we get stucked in an endless loop of a function. By the way, the vga rom is available for download on the matrox website (http://www.matrox.com/graphics/en/support/drivers/download/?id=151). In the archive, this is the file 964-15.bin (36 KB). The guilty function starts at offset 2C46, ends at 2C85. The test condition which is never meet is at offset 2C75. This function is called 5 or 6 times during the rom execution. With the probe, if I skip calls to it, coreboot manages to finish the execution, and the graphics card is initialized. Then the framebuffer can be used in linux.
A nice feature of coreboot is to 'override' a pci option rom. So I decided to patch the VGA bios. I replaced calls to the annoying function with nop instructions, put the patched vga bios in the CBFS file, and execute it in real mode -> it works ! I attached a binary patch to apply on the matrox bios. Use bsdiff / bspatch to apply it (http://www.daemonology.net/bsdiff).
Now that it was working with real mode, I tried again with x86emu and yabel. Yabel produced the same result (int 0 / divide error). x86emu went a little bit farther but generates int 6 : C000:8458: 1F ILLEGAL EXTENDED X86 OPCODE!
My solution (dummy handlers and patched vga rom) looks more like an ugly hack than a nice bug fix. It's a workaround to get the matrox graphics card up and running but I would be better if we could find the origin of the problem. It happens with this exotic graphics card but maybe someone with an ati or nvidia cards will run into the same troubles. Maybe some of the 16bit code guru from yabel or seabios have some clues, or even a solution to share ? I'm not skilled enough in assembly to fix it alone.
Regards, Thomas
PS : I also attached the boot log when I execute the board in real mode, with my fixes
* *