BIOS/Protected Mode
GenerationXrr
I am starting to investigate why protected mode is not routinely used
for BIOS peripherals for POST.
Unfortunately, real mode is becoming a huge limitation with the
increase in option ROM BIOS sizes, to the point where I am starting to
look at other alternatives.
Even if an option ROM can initialize to a full 64k size, the chances
that other peripheral cards ( SCSI cards especially ) will get
squeezed out and will not post at all. This of course depends on how
intelligent system BIOS is to determine whether the init size has
decreased to just runtime INT services rather than full POST size,
however, I cannot take this chance since system BIOS' can vary from
Phoenix to Wistron.
The next alternative would be to use EBDA as a method of "dynamically
loading" executable binary to minimize the initialization size,
however, I have found problems with Post Memory Manager (PMM)
allocating space below 1MB in direct conflict of the EBDA spec.
Therefore, I cannot *reliably* allocate even what I would consider a
reasonable amount.
This whole problem description has motivated me to look into protected
mode for BIOS initialization to reduce overall POST size (to system
BIOS ) and add more BIOS functionality. Here are the questions:
1. Are there any BIOS folks out there that have done this? If so, what
were the complexities involved? How big was the effort? If not, why
not?
2. After Reading several posts, I am still unclear whether I can still
use segmentation for real mode calls when in protected mode.
3. Timers, interrupts, enabled in real mode but used in protected mode
seem to be the biggest issue to prevent migration to protected mode.
Why?
Lastly, let me say that yes, Extensible Firmware Interface (EFI) is
coming to 32 bit systems from IA64 making all of this somewhat
obsolete. However, it is important to note that at this is Intel's
roadmap and a few years down the road. AMD will still plan to use real
mode BIOS for their 64 bit systems, which are pretty frequent in Tyan
motherboards. So BIOS won't go away anytime soon, prompting me to look
into the above.
Thanks, and all answers appreciated
Jordan
motcat
You have hit the nail on the head with your assessment of option ROMs failing to initialize when UMB space is limited. Many modern BIOSes will include 1 or more option ROMs for 'value added' features, which, if you add a SCSI card for example, will not get initialized. However, the ability to shrink the option ROM to a small runtime footprint is not the responsibility of the BIOS, it is the option ROM itself that must do the task. Most well written option ROMs will shrink to a very small runtime footprint. I've seen many that shrink to 2K or less. Some SCSI ROMs I've seen will shrink to 0 if the ROM doesn't detect a device attached to the channel.
However, it is the responsibility of the BIOS to pack the option ROMs together to avoid gaps in shadow space. For example the video BIOS might occupy C0000h-CBFFFh, then another option ROM should start at CC000h. The issue is complicated further because there needs to be enough UMB space available in order to shadow the entire option ROM image prior to initialization. If there is only 32K of space available, and the option ROM is 48K in size, it can't be shadowed and it won't initialize, regardless if its runtime footprint is 2K.
Several BIOSes implement the PMM, and you can request either conventional or extended memory when you call into the PMM.
Using protected mode is something a BIOS will do for specific tasks, however using big real mode is more common and you can accomplish almost the same things (during POST).
EFI?? Intel has been trying to shove that down our throats for years. IMO it hasn't been adopted by the industry because it would require a large investment in infrastructure to get the ball rolling. You have to understand that a lot of BIOS development has gone to the Pacific Rim area where labor is cheap but excellent. Margins are so thin on motherboards the OEMs don't want to retrain their BIOS programmers to start with EFI when everything is working just fine with a traditional BIOS because each new project is leveraged from the prior. I guess after a while we'll all be assimilated into EFI by Intel, but yikes, that means I'd have to learn 'C'.
:MC
Michael Tippach
GenerationXrr wrote:
> Even if an option ROM can initialize to a full 64k size, the chances
> that other peripheral cards ( SCSI cards especially ) will get
> squeezed out and will not post at all.
This is why OpROM vendors need to be pushed towards smaller BIOS sizes
by whomever qualifies the components for system integration. I know
of at least one case where this has worked to get a video BIOS back to
<32k, as used to be the industry standard.
Well, this could mean that OpROM vendors would need to revert back
to good old assembly language. Good thing. Creates jobs for
Generation X assembly language programmers ;-)
> This of course depends on how
> intelligent system BIOS is to determine whether the init size has
> decreased to just runtime INT services rather than full POST size,
> however, I cannot take this chance since system BIOS' can vary from
> Phoenix to Wistron.
I guess most system BIOSes are smart enough to do that. OpROMs
sometimes aren't smart enough to seperate initialisation stuff from
run-time stuff, so part of the init stuff becomes run-time stuff.
> The next alternative would be to use EBDA as a method of "dynamically
> loading" executable binary to minimize the initialization size,
> however, I have found problems with Post Memory Manager (PMM)
> allocating space below 1MB in direct conflict of the EBDA spec.
> Therefore, I cannot *reliably* allocate even what I would consider a
> reasonable amount.
>
> This whole problem description has motivated me to look into protected
> mode for BIOS initialization to reduce overall POST size (to system
> BIOS ) and add more BIOS functionality. Here are the questions:
If you are into OpROM programming, look up PXE. Most PXE ROMs copy
their code up into extended memory. Only a small stub is left in the
OpROM region, which later (at boot time) copies the run-time code
into the EBDA and executes it there. Since PMM is shut down before
boot, it becomes a non-issue.
> 1. Are there any BIOS folks out there that have done this? If so, what
> were the complexities involved? How big was the effort? If not, why
> not?
Any system BIOS that uses the TSEG already does execute part of its
code in PM, even at run-time. For OpROMs, this is a no-no, since
run-time execution must also be guaranteed in a V86 environment.
and they do not have access to SMRAM anywhere.
I guess the reasons why system BIOSes do not execute all of their
initialisation code in protected mode are either of the following:
- Early initialisation needs to be done in a stackless environment,
where every register counts i.e. one uses segment registers for
data storage etc.
- Code base would need to be rewritten, completely seperated into
init and run-time portion. All shared routines must be PM-
callable - cost factor.
- ROM footprint would increase. Cost of flash memory is part of
the mainboard cost in an extremely competitive market.
- run-time code is limited to real mode anyway, because of the
V86- requirement (except when executed in SMM, which means a
substancial performance decrease)
> 2. After Reading several posts, I am still unclear whether I can still
> use segmentation for real mode calls when in protected mode.
You can always thunk to the real mode routine.
> 3. Timers, interrupts, enabled in real mode but used in protected mode
> seem to be the biggest issue to prevent migration to protected mode.
> Why?
This is just a matter of proper redirection. Not unsolvable. The
real problem is that any run-time BIOS code must be able to run in
V86.
> Lastly, let me say that yes, Extensible Firmware Interface (EFI) is
> coming to 32 bit systems from IA64 making all of this somewhat
> obsolete.
Well, EFI's been around for quite a while and I'm not sure about
which is making which obsolete as far as IA32 environments, YMMV
Would have been different if IA64 had succeeded in becoming the next
big thing in the main stream market.
Best regards,
Michael Tippach
Ed Beroset
> Hello,
>
> I am starting to investigate why protected mode is not routinely used
> for BIOS peripherals for POST.
>
> Unfortunately, real mode is becoming a huge limitation with the
> increase in option ROM BIOS sizes, to the point where I am starting to
> look at other alternatives.
I'm not quite sure what you're asking. If you're asking "why doesn't
the POST code in a modern system BIOS use protected mode?" the answer is
"it often does." Another question is "why not use big real mode?" and
they answer is that "they usually do."
> Even if an option ROM can initialize to a full 64k size, the chances
> that other peripheral cards ( SCSI cards especially ) will get
> squeezed out and will not post at all.
I'm not sure what you're talking about here. What's the "full 64k
size?" Are you talking about ISA cards here?
> The next alternative would be to use EBDA as a method of "dynamically
> loading" executable binary to minimize the initialization size,
> however, I have found problems with Post Memory Manager (PMM)
> allocating space below 1MB in direct conflict of the EBDA spec.
> Therefore, I cannot *reliably* allocate even what I would consider a
> reasonable amount.
Did you know that a PMM allocation request for 0 bytes will tell your
code how much memory of the requested type is available?
> This whole problem description has motivated me to look into protected
> mode for BIOS initialization to reduce overall POST size (to system
> BIOS ) and add more BIOS functionality. Here are the questions:
>
> 1. Are there any BIOS folks out there that have done this? If so, what
> were the complexities involved? How big was the effort? If not, why
> not?
Are you talking about system BIOS or option card BIOS? I've done system
BIOS work but the option BIOS work I've done is way too ancient to be of
use with this question.
> 2. After Reading several posts, I am still unclear whether I can still
> use segmentation for real mode calls when in protected mode.
If you're using PMM, did you miss the fact that it's using big real
mode? If you're asking "can I call real mode system BIOS services from
within protected mode" the answer is "generally not." If you're asking
if there's a way use large memory addresses and real mode services, the
answer is yes -- you can use big real mode.
> 3. Timers, interrupts, enabled in real mode but used in protected mode
> seem to be the biggest issue to prevent migration to protected mode.
> Why?
Because real mode interrupt handlers are not guarenteed to work under
protected mode. If ANY of the handler code loads a segment register,
for instance, it won't work unless you get lucky. And you want to write
more reliable code that that, I'm sure.
> Lastly, let me say that yes, Extensible Firmware Interface (EFI) is
> coming to 32 bit systems from IA64 making all of this somewhat
> obsolete. However, it is important to note that at this is Intel's
> roadmap and a few years down the road.
But they wisely included a migration path to make it relatively painless
to start implementing now.
Ed
GenerationXrr
You have described my problem exactly. I'll summarize the problem as
well. Basically, I am concerned with the initialization and runtime
size of the option ROM that I work with. Unfortunately, the business
I'm in is software RAID which predisposes init/runtime size to a
greater average size than say, a NIC card with PXE enabled.
The option ROM I work with will unload if there are no drives
attached, which make that particular case a non-issue.
The current solution I have developed to tackle the init (however, the
runtime size remains a problem) size is to load part of the POST
executable code directly from ROM into the EBDA area and making a far
jump at a known segment and offset address. This has managed to shave
about 14k from the init size.
However, in my attempts to claim EBDA space, I've discovered that PMM
is not globally aware of anything that EBDA currently has ( or may
reasonably claim in the future) claimed, thereby causing EBDA to
potentially overwrite memory managed by PMM. This particular case is
for conventional memory allocations only. Intel has in fact
acknowledged this as a problem and I have submitted a solution to this
problem to Phoenix for review and they are considering it through the
folks at AMD.
My focus now is to shift to memory above 1MB and load executable code
to a set limit of 4GB. However, this prompted my question about
executing code above 1MB. I was under the impression that unreal mode
set limits to 4GB in flat addressing, but remained in real mode for
code execution. This is why I am thinking about using protected mode
for code execution. Any thoughts?
:-) As far as EFI, I can tell you that Intel is starting to abandon
legacy BIOS co-authored specs in favor of EFI, hence my mention of
AMD. I think you may find that you might be a C programmer in a few
years. I know of at least one 32 bit server system from Intel that has
EFI support now - more to come.
Thanks,
Jordan
motcat <mot...@ragingbull.com> wrote in message news:<3F393BFF...@ragingbull.com>...
> --
GenerationXrr
Can you give me examples which system BIOS will use protected mode and
for what functions? This would be great to know so I can investigate
these further and talk to the system vendors. I wasn't aware that they
used protected mode. As far as big real mode, I use this for flat
memory addressing/PMM and DMA transfers, however, I cannot use it for
code execution.
Option ROMs initialize to a pre-defined size. In this particular case
I was talking about my option ROM which initializes to 64k. Also, this
card is not ISA but PCI. Option ROMs can have a variable size, some
64k, some 48k - it just depends.
I'm talking about option ROMs exclusively. Also, I did not miss the
fact that PMM uses big real mode, since the specification is publicly
available:
http://www.phoenix.com/resources/specs-pmm101.pdf
I guess the question I would have is why can't I make a call to real
mode system BIOS services from within protected mode, in general?
Thanks,
Jordan
Ed Beroset <ber...@mindspring.com> wrote in message news:<bhc3l9$lt5$1...@slb9.atl.mindspring.net>...
GenerationXrr
:-) I am one guilty (used to be) of initializing a full 64k of memory
space for the option ROM I work with, however, this is driving me to
find alternatives to this problem.
There are some system BIOS such as the one for the Intel server board,
Clearwater which will reclaim memory space given up by an option ROM
after shrinking from initialization to run-time size, and I have seen
some really bad system BIOS that do not. This is part of the
motivation to look for alternatives and solutions.
I can definitely understand what you mean about separating
initialization and run-time services into clear and distinct modules.
You mention cost as a problem calling shareable functions.. Do you
mean cost in terms of size or speed, or both?
> This is just a matter of proper redirection. Not unsolvable. The
> real problem is that any run-time BIOS code must be able to run in
> V86.
Can you explain this a little further? I'm very interested in this.
This would definitely help my understanding of what's involved.
Assuming that the size of flash ROM is not an issue, and that all of
the above have been taken care of, would it be realistic to load the
option ROM initialization code only in memory above 1MB and execute
from protected mode?
As far as EFI, I wish that AMD and Intel would agree on a common
structure, rather than AMD taking the legacy BIOS approach and Intel
taking the EFI route. In a few years, this will mean that flash ROMs
will have to contain both a legacy BIOS option ROM and also an EFI
driver for EFI, if this is going to be seamless to the end user. Torn,
torn like an old sweater. Aaargggh! :-)
Thanks,
Jordan
Michael Tippach <mtip...@gmx.net> wrote in message news:<3F397765...@gmx.net>...
Michael Tippach
> I can definitely understand what you mean about separating
> initialization and run-time services into clear and distinct modules.
> You mention cost as a problem calling shareable functions.. Do you
> mean cost in terms of size or speed, or both?
I meant in terms of $$$
> > This is just a matter of proper redirection. Not unsolvable. The
> > real problem is that any run-time BIOS code must be able to run in
> > V86.
>
> Can you explain this a little further? I'm very interested in this.
> This would definitely help my understanding of what's involved.
Run-time code cannot perform mode switches and cannot rely on
FRM. It has to use int 15/87 for the ext mem copy business. As
far as init code, this restriction does not apply. But then again,
I don't see any advantage in running the init code in PM - see
below!
>
> Assuming that the size of flash ROM is not an issue, and that all of
> the above have been taken care of, would it be realistic to load the
> option ROM initialization code only in memory above 1MB and execute
> from protected mode?
You could, but what's the gain from this? The only solution I can
think of, where the OpROM pretends to be like just 1KByte in size
and bootstrap loads its initialisation code from some obscure place
from within the OpROM aperture - this solution does not work, because
the OpROM aperture of the PCI device is closed at the time of
the ROM scan and there is no safe way to re-open it, especially
not if the device is behind a bridge, and very especially not in
a system with multiple host busses.
A feasible solution would involve a change in hardware in as far
as to make the PCI config space of the device contain a BAR that
maps to the on board OpROM image. This way, the image would always
be accessible and your code could copy portions of it into RAM or
execute them in place, depending on speed requirements. This would
actually solve your problem.
Without any mechanism like this, the System BIOS will always have
to fit your complete ROM image, including the init code into the
OpROM space, which, as you correctly stated, is an extremely scarce
resource these days. That the image is shrunk after init does not
help with the fact that it might not fit into what space is left
to begin with.
Best regards,
Michael Tippach
motcat
You've peaked my interest, I'm investigating why the PMM doesn't manage EBDA. I was under the
impression the PMM handled management of all conventional memory. I'll get back to you on
that issue.
I'm not sure I agree on using protected mode to initialize your option ROM. I think using big
real is easier if you wanted to access memory >1MB. I think part of the problem is the size
of your option ROM. If you're going to offer an option ROM that has a runtime size of 64K, I
can see that in many cases it will never be initialized by the system BIOS. Traditionally
Award BIOS usually had a smaller footprint than Phoenix, however even with Award, shadow space
is shrinking. Phoenix on the other hand has always been encroaching into the E000 segment.
That makes it difficult to get the option ROMs initialized with space so limited.
MC