Well I was assuming (hoping) there would be at least significantly *better*
end-user (if that user IS a sysadmin / developer / IT pro type) customizability /
tweakability of EFI systems vs. the standard BIOS ones.
I don't expect (though it would be nice!!!) to get the motherboard schematics,
BIOS source code and development manual on a CD when I buy the
machine (though the old CP/M, S-100 and PC-XT / PC-AT stuff often did just that and it
was GREAT!).
I would like to be able to say write / edit some customized NSH shell (see below)
scripts to customize my boot sequence, hardware register settings, whatever.
Even at a minimum that'd be a billion times better than the current junk ==
"if you have the reflexes of a cat, hit F2 to enter setup,
hit PAUSE to see the hardware I/O & memory map that scrolls 80% unpreventably
off your screen before even superman could read the first page of it..., hit F11
if you actually want to *choose* boot devices, hit [YOU MUST BE KIDDING] if you
actually want to choose OS boot flags..,
hit [F1] to enter setup to turn off the useless full screen logo that displays INSTEAD
of telling you how to enter setup to get rid of it....".
As for modularity?
Well if I have a 4MB AMI BIOS, and say that includes subsidiary
BIOSES for Marvell (LAN), JMICRON (SATA RAID), INTEL (LAN), I'd HOPE we'd
start to see flash utilities to let you say download the latest BIOS from say Marvell
probably itself some 512kB image, then reflash *that* part of the BIOS if there's
an update to its BIOS but not the whole AMI BIOS overall. Traditionally if these
other devices weren't integrated on the MB they'd have physically distinct BIOS ROMs
of their own that could be reflashed, so I'd be shocked if there couldn't be some physical
segregation of a big single MB ROM to admit sectional flashing of the sub-ROMs it
contails. Not uniquely an EFI 'feature' but hopefully the better architecture / toolset /
evolutionary mentality would be conducive to giving such finer grained control options.
Also, of course, if there are NSH scripts for things like device self-test,
default configuration parameters, etc., I'd hope it'd be trivial to have those all
stored as individually updatable files / modules / scripts in an environment string block /
whatever.
ACPI table modularity / end user tweaks, etc?
Well fortunately I haven't had to get too deeply into this for my own present
devices (they're either hopelessly broken or sorta-work-enough-for-the-moment).
But it does seem like it's increasingly common for people to actually be patching
their ACPI tables to fix known problems their BIOS OEM's won't. I'd only assume
that EFI's better scriptability / modularity / power would facilitate test / debug /
patch / override of these sorts.
q.v.:
http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems
http://ubuntuforums.org/archive/index.php/t-609925.html
http://acpi.sourceforge.net/dsdt/index.php
So from your comments I take it you're possibly a BIOS engineer by trade;
if you have some inside scoop as to how some MB / BIOS OEMs are planning
to deploy EFI, perhaps you can share a few more details? Just basic
things like how / if the scripting may be supported / made accessable to
end user environment variables / scripts, what kinds of spare memory
capacity for BIOS expansion a typical MB might have, whether the
user settable BIOS configuration parameters would typically be exported / imported
as "environment / shell" variables to scripts, if the BIOS GUI basically would be
scripted, etc.
Thanks for the info you've posted previously, it's interesting.
http://en.wikipedia.org/wiki/E...ble_Firmware_Interface
...
The EFI shell
The EFI community has created an open source shell environment[6].; rather than booting directly into a full OS, on some implementations, the user can boot to the EFI shell. The shell is an EFI application; it can reside directly within the platform ROM, or on a device for which the drivers are in ROM.
The shell can be used to execute other EFI applications, such as setup, OS install, diagnostic or configuration utilities, and system flash updates; it can also be used to play CDs or DVDs without having to boot to a complete operating system, provided that an EFI application with the appropriate features is written. Shell commands also make it possible to copy or move files and directories between supported file systems. Drivers can be loaded and unloaded, and a complete TCP/IP stack can also be used from within the shell.
The EFI shell supports scripting through .nsh files, which are analogous to DOS batch files.
Originally posted by: Peter
Yeah, QuixoticOne, your software quality rant is heard, but really, it's nothing to do with the choice of firmware platform. It's a symptom of the general end user's buying behaviour. There's an impressing willingness to put up with sh*t software rather than put the money where the quality is. Always the latest and greatest, if it still has rough edges, "it's just software issues, let's wait for updates" rather than return it and buy something slightly older that's actually been developped and tested all the way through. Etc. etc.
Getting the software right upon release is possible - and where customers demand it, it is actually being done. Server gear, embedded x86 computing in mission critical aero, space, medical applications, they all can do it. It costs money, it takes time, and you're not getting a "new and improved" piece of hardware every three months either.
The normal computer buyer is different. When Intel or AMD present a new chipset or CPU, everyone here expects product on shop shelves five seconds later. Of course it's not going to be good product, but it's being bought anyway, even at the premium prices charged for "early adopter" kit. As a manufacturer in this area, you need to be first to market, not first to market with something that works right - and by the time you'd know enough to actually achieve the latter, you're already two or three generations of halfbakery further down the line. Project engineers don't grow on trees, so the "old" product quickly has to be abandoned.
So much for the general direction of the problem. Now, details.
Even with EFI, you, the end user, is not going to create any patches nor are you going to merge any 3rd party updates into some uncaring OEM's base frame - at least no more than you can now use a BIOS ROM module manager tool to replace a PXE boot image or an integrated VGA BIOS.
Likewise, ACPI is far from being "just tables", vast misconception there too. ACPI is mostly code, existing to abstract the board specific implementation of certain hardware features so the OS can remain generic. With few exceptions of bleeding obvious coding errors, modifying the ACPI in a way that makes sense requires in-depth knowledge of the particular hardware design and what the boot firmware does with it.
Facebook
Twitter