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

[Joshua Oreman]

On Thu, May 27, 2010 at 1:59 AM, Michael Brown <mbrown at fensystems.co.uk> wrote:
> 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's possible that the code from E000 to E800 or so has to do with
system bootstrapping that's not called after we return; this is what I
meant by "suspect this was only randomly". The absence of a crash
doesn't confirm that we did the right thing, but the presence of a
crash is a pretty strong indicator that we did the wrong thing.

Note that my patch doesn't actually care whether the runtime segment
is above E000; it only checks whether the init-time segment is below
A000. The logic is that if the init-time segment is already in the
BIOS area it's probably meant to also be the runtime segment. I'm not
sure what the relative numbers of systems are that validly put the
runtime segment above E000 versus validly put the init-time segment
above A000 versus have broken PCI3 support that happens to leave
something reasonable-looking in %gs (where this case seems to be one
of the latter). Fixing the problem on this BIOS would necessarily
break one of the first two groups.

> 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.

I agree. Adding Kyle on CC - Kyle, any chance you could try stock gPXE
and gPXE-with-this-patch with two identically-flashed cards in your
problem system?

-- Josh