[coreboot] option roms in SeaBIOS and Coreboot

[Kevin O'Connor]

On Tue, Nov 25, 2008 at 12:15:48AM +0100, Rudolf Marek wrote:
> Hello,
> 
> I obtained some SAS PCIe card. I have some good and bad news ;)
> 
> 1) it does not work at all, PCI ROM signature wrong.
> 2) it does work with some help glitch
> 3) it does not work as expected
> 
> I solved 1) with a simple hack patch (attached) The PCI ROM BARs should not be
> relocated. The K8 processor has some PCI hole resource and imho there is a
> problem that even the PCI hole starts at TOPMEM, it still hits RAM because of
> video framebuffer for integrated VGA.

Thanks.  Does coreboot setup the option rom bar with a valid value?
If so, this makes things easy - I can just enable the existing value.
I didn't see any code in coreboot that did this though.

> I fixed this isssue by not touching PCI ROM base, check the patch.
> 
> 2) It does work! PCI option rom get executed. This particular ROM has "press
> space to skip" option, and if I do that I get to grub/linux whatever.
> 
> 3) If I do not press space, the PCI option rom is supposed to init the HW.
> 
> it just freezes somewhere inside, but keyboard IRQ still delivered.
> 

Note that your patch doesn't seem to disable the mapping after the
copy.  This is definitely necessary.  Maybe add something like:

    pci_config_writel(bdf, PCI_ROM_ADDRESS, orig & ~PCI_ROM_ADDRESS_ENABLE);

Also, since the initial SeaBIOS support, I found the pci spec (google
for "PCI Firmware Specification v3.0 (2005-06-20).pdf"), and it
indicates that multiple firmware images can be in the rom - the BIOS
needs to walk the list and find the right one depending on the PCI
headers.  Sigh - this stuff's never simple.

> With original BIOS, some other screen is printed with another screen mode, but
> it freezes too ;)))
> 
> Some remark to the end. I'm not sure if next_rom pointer should be adjusted
> before the rom is copied.
> 
> In my case VGA has someting like 36KB and with 2K align it gets to 0xCA000 for
> next ROM. I tried with ALIGN of 64KB but it does not help that particular silly
> option rom :) Maybe the align should be handled also depending on actual rom
> size. I mean "allow spaces for aligns between roms".

As near as I can tell, the code that updates next_rom is correct.  We
don't want to increase next_rom until after the pnp init function is
called, because that function can resize the rom.

The option roms should only require 2K alignment.  The docs are pretty
clear on that.

Thanks again,
-Kevin