On Thu, May 27, 2010 at 1:59 AM, Michael Brown <[email protected]> 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 pmm0...@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 pmm0...@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 _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
