How to detect EFI and get the EFI memory map?
whodunit
method to detect an EFI enabled BIOS, and to get the EFI memory map as
opposed to the BIOS E820 memory map? The problem I am running into is that
the E820 map lists some portions of memory as user accessible, but as soon
as I write to them I get protection errors. My suspicion is that EFI has
data storage in these particular areas and that EFI would have told me these
areas are reserved. How would I go about accessing the EFI routines to get
an EFI map, before any OS loader?
A caveat to this request is that my code is not going to identify itself to
EFI as an EFI specific function. I need to know how to access the EFI
tables and/or functions from a pure BIOS level, somewhere between EFI/BIOS
and any OS loader.
If it makes it any easier to understand, then pretend that a piece of
assembly code wants to request EFI's memory map instead of the BIOS E820, or
as a means to cross check the BIOS E820 map, and that the assembly code will
be 32-bit under MS DOS.
Thanks,
Rod Pemberton
news:y%aFj.62502$cQ1....@bgtnsc04-news.ops.worldnet.att.net...
All but one line of your post made sense to me. If I remove that line
(below), my answer is: "I don't know. But, there is an EFI spec. somewhere,
but I don't have a link at the moment."
> The problem I am running into is that
> the E820 map lists some portions of memory as user accessible, but as soon
> as I write to them I get protection errors.
If I take into account the removed line, I become confused at to your
problem. My question is: "How are you getting protection errors? Is this in
your own OS?" "... will be 32-bit under MS-DOS" could mean you've setup
32-bit protected mode for your own OS *or* you're using a memory manger:
EMS, XMS, VCPI, DPMI, etc. If not your own OS, then the protection errors
should be expected, yes? (I.e., the memory manager is controlling memory,
not you...) If your own OS, why are you blocking yourself from accessing
memory?
Rod Pemberton
whodunit
> (below), my answer is: "I don't know. But, there is an EFI spec.
> somewhere,
> but I don't have a link at the moment."
>
>> The problem I am running into is that
>> the E820 map lists some portions of memory as user accessible, but as
>> soon
>> as I write to them I get protection errors.
>
> If I take into account the removed line, I become confused at to your
> problem. My question is: "How are you getting protection errors? Is this
> in
> your own OS?" "... will be 32-bit under MS-DOS" could mean you've setup
> 32-bit protected mode for your own OS *or* you're using a memory manger:
> EMS, XMS, VCPI, DPMI, etc. If not your own OS, then the protection errors
> should be expected, yes? (I.e., the memory manager is controlling memory,
> not you...) If your own OS, why are you blocking yourself from accessing
> memory?
There is an EFI spec, and I've read it, but from what I understand, there
does not seem to be a non-EFI initiated method of obtaining EFI structures.
I may have overlooked some key point in the spec, and hope that someone
would point to the verbiage I need to re-read whereby any program with ring
0 privilege can access those structures.
In a typical BIOS E820 map, there would be two type 1 entries for memory
below 4 GB, then one entry for any memory above 4 GB. In an EFI based
system, notably from Intel in my cases, there are many type 1 entries below
4 GB. It appears that at least one of these type 1 regions is actually not
supposed to be accessible by user programs, that some of these could be
otherwise reserved by and for EFI.
Do not let the side effects distract you, I am looking for some method
whereby I can identify EFI specific regions of memory and exclude those from
the pool of available memory, in spite of what the BIOS E820 map tells me.
Rod Pemberton
news:y%aFj.62502$cQ1....@bgtnsc04-news.ops.worldnet.att.net...
the
> method to detect an EFI enabled BIOS,
Don't know. Linux seems to do this in the bootloader now. Let me find an
EFI spec copy...
> and to get the EFI memory map as
> opposed to the BIOS E820 memory map?
This EFI function seems to be called (of all things...) GetMemoryMap()
(from EFI spec. v102).
Linux' removed EFI memory map code:
http://groups.google.com/group/linux.kernel/msg/ff6294ba77a779b
Rod Pemberton
Rod Pemberton
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:fs42lk$sm8$1...@aioe.org...
> "whodunit" <n...@localhost.org> wrote in message
> news:y%aFj.62502$cQ1....@bgtnsc04-news.ops.worldnet.att.net...
> > From a pre-OS environment, meaning immediately after BIOS POST, what is
> the
> > method to detect an EFI enabled BIOS,
>
> Don't know. Linux seems to do this in the bootloader now. Let me find an
> EFI spec copy...
>
My hopefully correct quickly skimmed summary:
An EFI OS Loader is loaded to a fixed address (unspecified) and executed.
The EFI OS Loader loads the OS.
The OS takes control from the OS Loader by calling ExitBootServices().
To call ExitBootServices(), the OS Loader must call GetMemMap().
EFI boot services can't be called after a call to ExitBootServices().
EFI run time services can be called after a call to ExitBootServices().
GetMemMap() is the only way to obtain the memory map.
GetMemMap() is an EFI boot service and can't be called after
ExitBootServices(), i.e., by the OS...
The OS is passed information on how to call run time EFI services.
This is called a "Handoff State" which passes EFI_HANDLE and
EFI_SYSTEM_TABLE in a cpu dependent manner.
The OS can make runtime EFI service calls:
1) in flat physical mode (32-bit, base 0, 4Gb limit, CLI, CLD, 4k stack, no
IDT)
2) in v86 mode
EFI for IA-32 uses C calling convention
EFI for IA-32 EFI may destroy eax,ecx,edx
whodunit
>
> An EFI OS Loader is loaded to a fixed address (unspecified) and executed.
> The EFI OS Loader loads the OS.
> The OS takes control from the OS Loader by calling ExitBootServices().
> To call ExitBootServices(), the OS Loader must call GetMemMap().
> EFI boot services can't be called after a call to ExitBootServices().
> EFI run time services can be called after a call to ExitBootServices().
> GetMemMap() is the only way to obtain the memory map.
> GetMemMap() is an EFI boot service and can't be called after
> ExitBootServices(), i.e., by the OS...
> The OS is passed information on how to call run time EFI services.
> This is called a "Handoff State" which passes EFI_HANDLE and
> EFI_SYSTEM_TABLE in a cpu dependent manner.
>
> The OS can make runtime EFI service calls:
> 1) in flat physical mode (32-bit, base 0, 4Gb limit, CLI, CLD, 4k stack,
> no
> IDT)
> 2) in v86 mode
>
> EFI for IA-32 uses C calling convention
> EFI for IA-32 EFI may destroy eax,ecx,edx
My read of the spec is similar, that if the boot record of the hard drive
does not indicate EFI compliance (typical of preinstalled software from
non-EFI systems), then EFI will call ExitBootServices() itself and remove
any access methods that I might be able to use. From the link you posted,
Ying Huang claims the EFI memory map is itself compatible with E280 memory
map, such that E820 type 1 _should_ be user accessible even when I know the
region is an EFI controlled area. This does not seem to be entirely true,
but I will have to connect my Arium to one of my Intel EFI servers to find
out.
Thanks,
Chip
Maxim S. Shatskih
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"whodunit" <n...@localhost.org> wrote in message
news:y%aFj.62502$cQ1....@bgtnsc04-news.ops.worldnet.att.net...
Alexei A. Frounze
wrote:
> Is EFI ever supported on non-Itanium machines?
>
Yes, it is, though hasn't become mainstream.
Alex
Brendan
On Mar 22, 5:05 pm, "whodunit" <n...@localhost.org> wrote:
> From a pre-OS environment, meaning immediately after BIOS POST, what is the
> method to detect an EFI enabled BIOS, and to get the EFI memory map as
> opposed to the BIOS E820 memory map?
You can't use EFI and PC BIOS at the same time.
If your code is designed for PC BIOS then you can only use PC BIOS and
can't use EFI. If your code is designed for EFI then it can only use
EFI and can't use PC BIOS.
What you're asking is like trying to use the Linux kernel API from a
Windows executable.
> The problem I am running into is that
> the E820 map lists some portions of memory as user accessible, but as soon
> as I write to them I get protection errors.
Your code has bugs and these bugs have nothing to do with EFI at all.
Cheers,
Brendan
whodunit
>> the
>> method to detect an EFI enabled BIOS, and to get the EFI memory map as
>> opposed to the BIOS E820 memory map?
>
> You can't use EFI and PC BIOS at the same time.
>
> If your code is designed for PC BIOS then you can only use PC BIOS and
> can't use EFI. If your code is designed for EFI then it can only use
> EFI and can't use PC BIOS.
>
> What you're asking is like trying to use the Linux kernel API from a
> Windows executable.
No at all. Both the PC BIOS and EFI are resident in RAM for Intel's Tiano
BIOS.
>> The problem I am running into is that
>> the E820 map lists some portions of memory as user accessible, but as
>> soon
>> as I write to them I get protection errors.
>
> Your code has bugs and these bugs have nothing to do with EFI at all.
Bugs might be there, in code outside of my program (in code I did not
write), I grant you that, and I will debug through it/them next week.
However, I do know that Intel's EFI code has bugs with their SMI USB driver,
and has or did have a bug with their microcode update in SMI. I've proven
both of these to Intel.
What I am seeking is some way to identify potential problems with the EFI v
E280 memory maps so I do not interfere with EFI's memory allocations. This
should be possible, since some part of EFI is still resident in memory in
some form.
Brendan
On Mar 23, 8:32 am, "whodunit" <n...@localhost.org> wrote:
> >> The problem I am running into is that
> >> the E820 map lists some portions of memory as user accessible, but as
> >> soon
> >> as I write to them I get protection errors.
>
> > Your code has bugs and these bugs have nothing to do with EFI at all.
>
> Bugs might be there, in code outside of my program (in code I did not
> write), I grant you that, and I will debug through it/them next week.
Ok, let's be a little analytical then.
1) Have you tried your code on other computers (either real or
virtual) that don't support EFI at all?
2) Is it possible that your code makes assumptions about the memory
map that aren't necessarily correct (like "there's only one RAM area
above 4 GB" or "space for N entries are enough to store the E820
memory map" or "E820 is sorted from lowest to highest addresses by the
BIOS")?
3) Is it possible that the E820 memory map contains overlapping areas
(I noticed that Linux has special handling for this case)?
4) Are you relying on GRUB (it's memory detection code is, um,
"minimal")?
5) Does any other OS have problems with the E820 memory map on the
same computer?
The last question would be the most interesting question, because I'd
be extremely surprised if any motherboard manufacturer would be stupid
enough to produce a motherboard that crashed when someone installed (a
"PC BIOS only" version of) Windows on it (*especially* Intel). The
same E820 memory map can't be broken for your OS and correct for
someone else's OS.
> What I am seeking is some way to identify potential problems with the EFI v
> E280 memory maps so I do not interfere with EFI's memory allocations. This
> should be possible, since some part of EFI is still resident in memory in
> some form.
If the E820 memory map does report an area as usable RAM that isn't
actually usable RAM (for any reason), then as an OS developer you can
safely ignore the issue - tell the end-users to call whoever supplied
the dodgy PC BIOS - "Not My Problem(tm)".
Cheers,
Brendan
whodunit
>> >> the E820 map lists some portions of memory as user accessible, but as
>> >> soon
>> >> as I write to them I get protection errors.
>>
>> > Your code has bugs and these bugs have nothing to do with EFI at all.
>>
>> Bugs might be there, in code outside of my program (in code I did not
>> write), I grant you that, and I will debug through it/them next week.
>
> Ok, let's be a little analytical then.
>
> 1) Have you tried your code on other computers (either real or
> virtual) that don't support EFI at all?
Yes, everyday on boards available from other manufacturers. EFI(32) is only
on Intel boards we have in the lab, not on any other manufacturer's boards.
There are no issues with our non-Intel manufactured boards today, that I am
aware of. Supermicro had an issue two years ago (might still?) with an
FB-DIMM system where the SMI handler would periodically clear MTRRs for APs,
so I put a workaround in my code.
> 2) Is it possible that your code makes assumptions about the memory
> map that aren't necessarily correct (like "there's only one RAM area
> above 4 GB" or "space for N entries are enough to store the E820
> memory map" or "E820 is sorted from lowest to highest addresses by the
> BIOS")?
>
> 3) Is it possible that the E820 memory map contains overlapping areas
> (I noticed that Linux has special handling for this case)?
I've checked the E820 map, there are no overlapping areas.
>
> 4) Are you relying on GRUB (it's memory detection code is, um,
> "minimal")?
GRUB is not in the picture, I primarily run a multithreaded DOS application.
For the Linux version, the boot loader is LILO; someone else did the Linux
install that I copied to a spare drive for continued development.
>
> 5) Does any other OS have problems with the E820 memory map on the
> same computer?
Not sure the E820 map is buggy, I am just interested in finding out for
myself how the two maps compare. FYI, I don't run Winders for our testing.
> The last question would be the most interesting question, because I'd
> be extremely surprised if any motherboard manufacturer would be stupid
> enough to produce a motherboard that crashed when someone installed (a
> "PC BIOS only" version of) Windows on it (*especially* Intel). The
> same E820 memory map can't be broken for your OS and correct for
> someone else's OS.
>
>> What I am seeking is some way to identify potential problems with the EFI
>> v
>> E280 memory maps so I do not interfere with EFI's memory allocations.
>> This
>> should be possible, since some part of EFI is still resident in memory in
>> some form.
>
> If the E820 memory map does report an area as usable RAM that isn't
> actually usable RAM (for any reason), then as an OS developer you can
> safely ignore the issue - tell the end-users to call whoever supplied
> the dodgy PC BIOS - "Not My Problem(tm)".
Intel won't respond. They're too big for their britches to supply a
properly working BIOS. Their answers in the past were to take out the buggy
piece of SMI code, and to acknowledge they have an SMI USB bug but without
providing a fix. A year and a half after they acknowledged a bug in their
SMI USB code, I still receive Intel systems with the bug in place. I've
used "Not My Problem" many times regarding Intel's buggy Tiano BIOS, but
that does not make Intel fix their problem, probably because I don't have
the clout of M$.
Brendan
On Mar 23, 5:57 pm, "whodunit" <n...@localhost.org> wrote:
> GRUB is not in the picture, I primarily run a multithreaded DOS application.
> For the Linux version, the boot loader is LILO; someone else did the Linux
> install that I copied to a spare drive for continued development.
So the problem involves an EFI motherboard, LILO and Linux (ie. it's
not a problem involving an EFI motherboard and code you wrote)?
> > 5) Does any other OS have problems with the E820 memory map on the
> > same computer?
>
> Not sure the E820 map is buggy, I am just interested in finding out for
> myself how the two maps compare. FYI, I don't run Winders for our testing.
To get a memory map from EFI, AFAIK you need something that boots from
EFI - either write your own "EFI application" (e.g. something that
just displays the memory map) or perhaps install an OS that boots from
EFI and see what that OS shows for the memory map.
For example, you could install Linux and ELILO and see what "cat /var/
log/dmesg" tells you (and compare it to "cat /var/log/dmesg" for Linux
and LILO), although I'm not sure how much processing is done on the
memory map before it's displayed - Linux might not report raw data in
either case.
However, if your problem involves an EFI motherboard, LILO and Linux
then switching to ELILO might fix the problem anyway (it bypasses the
"PC BIOS compatability layer" that's probably running on top of native
EFI firmware).
Alternatively, I guess you could try to find out which area/s cause
problems using "trial and error" by ignoring some of the RAM areas
reported by E820. For example, for Linux, the kernel parameter
"memmap=0x100000$0x20000000" will tell Linux that there's 1 MB of RAM
at 0x20000000 that should be considered "reserved".
Of course it's also possible that I've misunderstood your (lack of)
details, and that the Linux version of your application works
correctly, and your problem is with the "multithreaded DOS" version
only. In this case I'd wonder why Linux can use the E820 memory map
without crashing but "whatever you did to DOS" can't. I guess I should
also mention that the idea of running a modern multithreaded
application (using more than 640 KB of RAM) on DOS makes me vomit
(it's like trying to ride a "modified poodle" in a horse race), but
that's not really relevant... :-)
Cheers,
Brendan