On Thu, Oct 13, 2011 at 12:18:08AM +0700, Darmawan Salihun wrote:
On 10/11/11, Kevin O'Connor kevin@koconnor.net wrote:
I suggest getting serial debugging working, and post the full log.
The full log is in the attachment. Anyway, I observed that the PCI ROM that I'm working with always got it's 3rd byte set to zero prior to being executed. I've just found where it's being modified but have yet to find the corresponding code in the entire "debugging system"
SeaBIOS wont modify the rom. However, the rom might self-modify itself when it is run.
[...]
Real mode stub @00000600: 606 bytes Calling Option ROM... oprom: INT# 0x10
If you are using SeaBIOS, you should instruct coreboot to not execute option roms. Disable both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN. (If both coreboot and seabios run the roms, it can confuse the hardware.)
Copying option rom (size 72192) from 0xfe020000 to c9000 Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm00: length=8000 handle=ffffffff flags=6 pmm call arg1=2 pmm02: buffer=7f00000 pmm call arg1=0 pmm00: length=10000 handle=ffffffff flags=6
I guess the boot hangs at this point?
BTW, is this a gPXE rom? It seems to follow a similar pattern of allocating, deallocating, and then allocating a larger chunk.
-Kevin
On 10/13/11, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Oct 13, 2011 at 12:18:08AM +0700, Darmawan Salihun wrote:
On 10/11/11, Kevin O'Connor kevin@koconnor.net wrote:
I suggest getting serial debugging working, and post the full log.
The full log is in the attachment. Anyway, I observed that the PCI ROM that I'm working with always got it's 3rd byte set to zero prior to being executed. I've just found where it's being modified but have yet to find the corresponding code in the entire "debugging system"
SeaBIOS wont modify the rom. However, the rom might self-modify itself when it is run.
[...]
Real mode stub @00000600: 606 bytes Calling Option ROM... oprom: INT# 0x10
If you are using SeaBIOS, you should instruct coreboot to not execute option roms. Disable both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN. (If both coreboot and seabios run the roms, it can confuse the hardware.)
This is the culprit which causes the ROM bytes to be modified. Disabling both CONFIG_VGA_ROM_RUN and CONFIG_PCI_ROM_RUN fixes it, no more modified PCI ROM bytes when SeaBIOS executes the ROM.
Copying option rom (size 72192) from 0xfe020000 to c9000 Running option rom at c900:0003 pnp call arg1=60 pmm call arg1=0 pmm00: length=8000 handle=ffffffff flags=6 pmm call arg1=2 pmm02: buffer=7f00000 pmm call arg1=0 pmm00: length=10000 handle=ffffffff flags=6
I guess the boot hangs at this point?
Well, not exactly. It was a break point in IDA Pro that stops the execution there. Anyway, the log above was for a gPXE ROM which I don't know exactly. It seems "bundled" with SeaBIOS or Coreboot. The log for my target option ROM was inadvertently not included. Here it is: ------------ Searching CBFS for prefix genroms/ Copying data 24063@0xfffd5278 to 157696@0x000c9800 Searching CBFS for prefix genroms/ Searching bootorder for: /pci@i0cf8/*@3 Registering bootable: gPXE (PCI 00:03.0) (type:128 prio:104 data:c9000336) Searching bootorder for: /rom@genroms/modd000.rom Registering bootable: Legacy option rom (type:129 prio:9999 data:c9800003) Press F12 for boot menu.
Checking for bootsplash Searching CBFS for prefix bootsplash.jpg Mapping cd drive 0x000fdb10 Mapping hd drive 0x000fdb40 to 0 drive 0x000fdb40: PCHS=20/16/63 translation=none LCHS=20/16/63 s=20480 Running option rom at c980:0003 pmm call arg1=0 pmm00: length=1000 handle=ffffffff flags=1 pnp call arg1=50 --------------
The target option ROM always loaded at C980:0000h As you can see, it calls PMM once above.
BTW, is this a gPXE rom? It seems to follow a similar pattern of allocating, deallocating, and then allocating a larger chunk.
Nope. The gPXE was not the target PCI option ROM. See my comment above.
Thanks,
Darmawan
-
Darmawan Salihun -
Kevin O'Connor