[gPXE-devel] [PATCH] [romprefix] Consider PCI3 init-time segment in BIOS area insane

[Michael Brown]

On Thursday 27 May 2010 09:30:42 Joshua Oreman wrote:
> This was reported by Kyle Kienapfel on #etherboot today, on a system
> with a Phoenix Award BIOS ("the motherboard from an Acer Aspire E700
> crammed into an old case"). He was getting a banner of
> 
>     03:03.0 CE00 PCI3.00 PnP BBS PMM0043 at 08 EC00
> 
> and a freeze with two gibberish characters printed immediately after
> the POST-time prompt. This failure mode suggests to me that we did
> write something to EC00; if we hadn't, it seems there shouldn't have
> been a problem until the actual BEV execution. the A test with iPXE's
> PMM enhancements worked:
> 
>     03:02.0 CE00 PCI3.00 PnP BBS PMM+0042D600+0043B4E0 E000
> 
> though I suspect that was only randomly by virtue of the different
> runtime address. With gPXE + this patch we got
> 
>     03:02.0 CE00 PCI3.00!DE00 PnP BBS PMM0043 at 08 CE00
> 
> which also worked.
> 
> I'm not sure why the runtime address was different each time, but I
> don't know of any system where 0xe0000 and up are not mapped to [a
> shadowed copy of] the system BIOS.

I don't know of any such system, but they *are* allowed to exist according to 
the spec.

The iPXE banner line suggests that we successfully relocated to 0xe000, which 
would indicate that the BIOS in question does allow (and expect) option ROMs 
to live outside the [0xc000,0xe000) region.  Also, although the runtime 
address is changing each time, it is always (so far) a potentially valid 
address (in the range [0xa000,0xffff) and 2kB-aligned).

It would be interesting to see what happens to a second such iPXE/gPXE ROM in 
this system; the relative positioning of the init-time and runtime segments 
for the two (preferably identical) ROMs might give some insight into what the 
BIOS is doing.

Michael