Re: Etherboot 5.5

On Thu, 19 May 2005, H. Peter Anvin wrote:
> > Operating in real mode is not the really tricky part; that would be
> > operating in 16-bit protected mode (which we're supposed to do with
> > the same binary code).  There are a few interesting theoretical
> > impossibilities that the spec throws at us, such as requiring us to
> > write to specified arbitrary physical addresses when we're in 16-bit
> > pmode and have enforced 64kB segment limits.
>
> ... without access to the GDT.  Of course, if you're in CPL0 you can 
> always hijack the GDT, at least as long as you turn interrupts off.
>
> Real-life hardware seems to have "solved" this by hiding an back door
> somewhere on the card, either in I/O space or in PCI Config space.

Access to hardware isn't the only issue.  The major problem is API calls
such as PXENV_TFTP_READ_FILE, where the receive buffer address is 
specified as a 32-bit physical address.  Previous versions of the PXE spec 
provided a separate API call PXENV_TFTP_READ_FILE_PMODE, which provided a 
valid pmode selector in an additional field, but this API call is absent 
from version 2.1.

I'm going to assume that we are meant to implicitly use the caller's data 
segment for PXENV_TFTP_READ_FILE in pmode, since I don't see any other 
possibility.

Michael



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click