Re: Option ROM - Real Mode - PCI BAR
- From: Brendan <spamtrap@xxxxxxxxxx>
- Date: Tue, 13 Jan 2009 02:16:20 -0800 (PST)
Hi,
On Jan 11, 6:48 am, "H. Peter Anvin" <spamt...@xxxxxxxxxx> wrote:
Or somewhat more complex, but safer, is to go into protected mode and
set up a so-called BIOS extender, a stub to intercept interrupts and
return to real mode.
I have a disk emulator called MEMDISK, which stashes the virtual disk in
high memory. As a result it has to do bounces to protected mode to
fetch the data. It doesn't use INT 15h unless it has to (i.e. it is
running in a PM already, e.g. under EMM386.) It is still quite fast,
enough that it doesn't require interrupt service during the switchover.
If you *do* take extended time for copying, you will need to service
interrupts.
The problem here is that some software may expect the BIOS and option
ROMs to contain "real mode only" code, and might use the GDT and/or
unreal mode. In this case there's no guaranteed safe way for BIOS code
or option ROM code to use protected mode or unreal mode without
trashing the caller's segments; because in some cases it's impossible
to save/restore the hidden parts of the caller's segment registers
(e.g. non-standard segment limits) - especially when the current GDTR
doesn't still point to the caller's original GDT, or when the caller's
original GDT has been modified after segments were loaded.
In addition, it's common for an OS to expect certain BIOS/device
services to be usable from virtual8086 mode - mainly disk functions
and video functions, where virtual8086 may be used by boot code
(before native device drivers are started) or after boot for fallback
code (when no suitable native device driver can be found). In this
case, if your option ROM attempts to use protected mode then the OS is
screwed, as virtual8086 only works for real mode code - as soon as
your code attempts to set the "protected mode enable" bit in CR0 it'd
trap to the OS, and unless the OS includes a full CPU emulator (which
would be extremely unlikely) there's no way for the OS to continue.
Of course none of this matters for option ROM initialization code -
it's only option ROM code that hooks BIOS services (like "Int 0x13").
On Jan 10, 5:44 am, google000 <spamt...@xxxxxxxxxx> wrote:
- Should I have the hardware guys add a I/O BAR to the device, that
the BIOS will map to a low address, and which I can access directly
with in/out instructions?
How much would an I/O BAR add to the "unit cost" of the final device?
How much would not having an I/O BAR add to the helpdesk/support costs
(customers complaining that it doesn't work in certain/rare
situations); and if the device can't work in certain/rare situations
will that harm your company's reputation and/or cause some lost sales?
I can't answer these questions...
Cheers,
Brendan
.
- References:
- Option ROM - Real Mode - PCI BAR
- From: google000
- Re: Option ROM - Real Mode - PCI BAR
- From: Alexei A. Frounze
- Re: Option ROM - Real Mode - PCI BAR
- From: H. Peter Anvin
- Option ROM - Real Mode - PCI BAR
- Prev by Date: Re: Programmers Ref. for win32
- Next by Date: Re: Programmers Ref. for win32
- Previous by thread: Re: Option ROM - Real Mode - PCI BAR
- Next by thread: Re: unusual MOV statement?
- Index(es):
Relevant Pages
|
Loading
