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

[Kyle Kienapfel]

On Thu, May 27, 2010 at 2:13 AM, Joshua Oreman <oremanj at mit.edu> wrote:
> 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
>

Intel disabled
03:02.0 CD00 PCI3.00!DE00 PnP BBS PMM0042 at 08 CD00
03:03.0 CE00 PCI3.00!DE00 PnP BBS PMM004A at 08 CE00

Intel Enabled
03:02.0 CE00 PCI3.00!DE00 PnP BBS PMM0043 at 08 CE00
03:03.0 CF00 PCI3.00!DE00 PnP BBS PMM004B at 08 CF00

Also of note, dhcp doesn't work from the roms in this problem
computer, also not from a chainloaded gpxe.pxe (dhcp net1)
card works inside linux