MSI to offer free EFI BIOS update in July

FoNmNmXExZ8

DO THE EVOLUTION

On darn time.

Vista x64 seems to be quite prevalent among enthusiasts now (more than you might expect from the number of us who used XP x64), about time for a bit-tech OS poll?

phuzz your right, vista 64 bit has a rather big market share among bit -tech readers, but that isnt the case for the general public, I mean look at the number of newspapers / tv shows / websites spreading the hate vista message and it got to the point where its not socialy acceptable to use vista if you dont have the excuse of being a geek.

What if I LIKE the old methond instead an extremely stupid looking visual... thing?! I don't care too much how my programs look like, AS LONG AS they aren't unnecessarily flashy. I've always hated the programs made by motherboard manufacturers as they all try to look like some sort of cross-breed of space shuttles, bat mobile and huggy bear rainbow world. Damnit.

Maybe I'm just an old-fashioned and dull engineer, but I don't like this new thing.

Old style is the only way! Refuse Resist! How the hell am I supposed to feel like an elitist git when I have a user friendly interface!

it is more than just an interface. it is a better way for your system to interact with it's hardware.
my question is this, with this (nativeish) EFI will I be able to install a retail version OSX and dual boot to vista?

Originally Posted by shegs
with this (nativeish) EFI will I be able to install a retail version OSX and dual boot to vista?

yes and no.
osx checks if you have apple hw, if not it wont work, of course there are workarounds for it, but apple's eula does not really promote them to say it nice.

Originally Posted by Jipa
What if I LIKE the old methond instead an extremely stupid looking visual... thing?! I don't care too much how my programs look like, AS LONG AS they aren't unnecessarily flashy. I've always hated the programs made by motherboard manufacturers as they all try to look like some sort of cross-breed of space shuttles, bat mobile and huggy bear rainbow world. Damnit.

Maybe I'm just an old-fashioned and dull engineer, but I don't like this new thing.

i completly agree

there is nothing at all wrong with the current design. i dont want to see crappy graphics of robot animals telling me ive changed cpu voltage. i think this efi is a waste of time and a huge sack of shite.

as the old saying goes

if it ain't broke, dont try to fix it

if a poll was taken i truly believe only an incredibly small amount of people want efi.

Originally Posted by qwertyqweqwe
i completly agree

there is nothing at all wrong with the current design. i dont want to see crappy graphics of robot animals telling me ive changed cpu voltage. i think this efi is a waste of time and a huge sack of shite.

as the old saying goes

if it ain't broke, dont try to fix it

if a poll was taken i truly believe only an incredibly small amount of people want efi.

There's a LOT more to EFI than just some funky little graphic changes. BIOS is a system that has not been updated in over 25 years - most of the hardware that is in our computers wasn't even dreamed of at that point.

EFI is a totally different interconnection method that allows a lot greater future extensibility. BIOS is how the computer's parts "talk" to each other - you don't think that maybe with a change in BIOS standards to something a little more flexibility, we couldn't adapt some better methodologies? Maybe more efficient communications?

I wrote about it a while back in a column, and I still stand by it...EFI is a move forward, and much like Vista is not XP with a new startbar, it's not BIOS with a pretty graphic.

EFI is the future no question, I doubt it will be too much unlike current BIOS in it's looks. Though, I am sure any in-Windows apps to control EFI settings will look like iPhone interface on meth, as all motherboard/graphics manufacturers are incapable of making a GUI that isnt nearly unusable.

well then if thats the case then why not totally redesign the pc from the ground up, instead of just adding all the extra stuff and techs onto 70's/80's technology. giving a unified memory architecture for example.

Originally Posted by shegs
it is more than just an interface. it is a better way for your system to interact with it's hardware.
my question is this, with this (nativeish) EFI will I be able to install a retail version OSX and dual boot to vista?

Is my same doubt, with EFI i supposed will be open way to the Hackintosh PCs. Or at least, an improvement in easy OSX hacking.

Yeah sure true improvements and steps forward are always nice, but so far I just am not impressed. And the UI simply looks like very colorful pile of crap.

I'm an EFI engineer with a major BIOS vendor. I don't want to say too much about this because the company is fairly small and I work with something of a niche product within the company. So it would be really easy for someone in my company or familiar with it to track me down based on my stating who my employer is, and what I work on. Because I am not speaking for the company, and I like my job, I'm reluctant to pass out that information in a public forum that could ID me. Sorry if this bothers anyone.

I've been working for about the past two and a half years with projects based off the Tiano core. I am by no means the most experienced engineer in the industry, but I know enough at this point that I think I can field EFI questions.

The pretty graphics are just a coat of paint on EFI. From the point of view of developers working on it, it is a neat trick because text mode has been the greatest common factor for getting information out of the box to users. That is because it is what was available in the first PCs 25 years ago on IBM PCs. The graphics are basically developers starting to flex their new EFI muscle and see what can be done with the spec, but not required or even common (Intel has been shipping boards with EFI on them for a little while).

I doubt what MSI ships will have much in the way of graphics. If they are upgrading from a legacy BIOS, they are probably using a 512k flash part (though maybe they shipped the board with 1 meg parts in anticipation of this). If the part is 512k it is squeeze for an EFI project so I don't see them putting much in the way of graphics in the image. Setup will probally be a text based affair. Note that this is just the setup browser, there is a lot more to both EFI and BIOS than just the user interface everyone is familiar with (and it often mistaken to be what BIOS is).

EFI really is needed desperately, and it is a lot more than just the age of BIOS that matters. The demands of users frequently run into the limitations of BIOS, but since BIOS is a shadowy world, not many people realize it. The one issue that comes up a lot on message boards that I can point to is USB support and how widely it varies between boards and BIOS versions. There are a lot of games that need to be played behind the scenes, the details of which could easily fill one post.

It won't make a real difference for software that is not aware of EFI, but it will reduce a lot of hassle for future software and really help demonstrate what cross platform support means.

Standards are problematic in BIOS, there really isn't a formal group. It's more of a tug-of-war with big players like Intel and Microsoft driving things. And there are a lot of specs to support like the PnP spec, ACPI, BBS, El Torito, Post memory manager, option ROMs, and so on. EFI will help centralize all of this and hopefully help make unified, cross platform systems easier.

The main job of BIOS is to get the hardware programmed, then leave a footprint of 16 bit ISRs, description tables defined by various specifications, ASL code, SMM, and anything else I may have forgotten. BIOS is based entirely around providing these things and not too much else which can be a real problem if you need to do anything with a full OS.

EFI applies lesions learned from operating system design to system firmware. Consider the number of platforms Linux can run on. Now consider trying to install Linux on an arbitrary platform that doen not have BIOS. On a PC, to interface with the hardware befor the OS can load drivers, it will use the BIOS or a custom loader from the firmware. If it is a custom loader, the author needs to know about it ahead of time. But with EFI, things are unified. The platform can be anything and Linux can still load on it in the same way using the same source.

The services BIOS provides are hardware dependent and based on what the greatest common factor would be meaning 8286 compatibility.

For software that is EFI aware, it will not have to make any assumptions about the underlying hardware (like, I can only use what was available on an IBM 286). Instead, it knows that a core set of services are available to it, and all it needs is the API defined in the EFI spec. These services will help make OS boot loaders and installers lighter weight, faster, and easier to work with as they can let the system firmware share the load again.

These services can help with more than the OS though. A mainboard may look like one monolithic construct, but it's not, there are a lot of tiny pieces in there. However, BIOS is written in a monolithic fashion. Some vendors have worked hard to make the source code and build process modular, but it is still monolithic in the flash part. It's not a good match for the modular nature of modern hardware. EFI can be writen in a fashion that it has a set of binary features that can be swapped around in a very modular fashion. The services based approach will also allow add in hardware to more closely integrate with the platform. For example, it is theoretically possible for an add in card to add a menu to the BIOS setup instead of launching a separate utility.

EFI looks more like a tiny operating system than firmware. There is a core that provides a number of services. These are defined in the EFI spec under the boot services table and runtime services table. Outside of this are modules called drivers that are independent of the core, all they need are the services. Modules create interfaces called protocols to operate with each other. Besides the system services I mentioned above, the EFI spec also defines some protocols for drivers to implement and use to ensure a base level of functionality on the platform. As an example, to get input, I would look for the SIMPLE_INPUT_INTERFACE (called EFI_SIMPLE_TEXT_IN_PROTOCOL in Tiano) using the GUID 387477c1-69c7-11d2-8e39-00a0c969723b.

This protocol interfaces to a driver that can be implemented how ever the author wants. The driver this protocol interfaces to could gets its keystroke data from a USB keyboard, bluetooth keyboard, PS/2 keyboard, from a serial port, from a network interface, from a joystick, or even from a purely logical construct.
Drivers are totally modular and dynamically linked. They can be provided as binaries and inserted into a firmware image peace meal. This means they could be flashed into your mainboard without having the flash an entire image, or can come from something like an add in RAID card.
But they are intended to be small and minimal. EFI not well suited to real time tasks, does not have any naitive multi-threading, very basic memory management (flat memory model) and has no user management. Additional services can be built on it and you can get something a bit like DOS as the EFI shell will demonstrate, but it is not a substitute for a full OS.


To try and illustrate some of the modularity and platform independence of EFI, here is an example of using the core to locate a protocol and get data from a driver implementing the protocol. This is based on Tiano. Please ignore the typos, spelling errors, etc :)

#include "EfiDriverLib.h"
EFI_PROTOCOL_CONSUMER(SimpleTextIn)
EFI_DRIVER_ENTRY_POINT (ExampleEntryPoint)
EFI_STATUS
EFIAPI
ExampleEntryPoint (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  )
{
  EFI_SIMPLE_TEXT_IN_PROTOCOL *TextIn=NULL;
  EFI_STATUS Status;
  EFI_INPUT_KEY Key;

  EfiInitializeDriverLib (ImageHandle, SystemTable);

  Status=gBS->LocateProtocol( &gEfiSimpleTextInProtocolGuid, NULL, &TextIn);
  if(Status || TextIn==NULL || TextIn->ReadKeyStroke==NULL) {
    // there was an error locatng the protocol or something is not filled out properly.
    //It may not have been published on the platform, or is not ready yet, or something else is wrong. Do error handling.
    ErrorHandling();
  }
  Status = TextIn->ReadKeyStroke(TextIn, &Key);
  if(!Status){
    //we have a key, do stuff
    MyKeyHandler();
  }
  return EFI_SUCCESS;
}

Nowhere does that code depend on a fixed memory location, IO port, or hardware in any way. As long as there is a text in protocol available and a driver behind it, then the code will work.

I figure I've created a big enough text wall for now. I hope that wasn't too disjointed, I was was trying to keep the length down (looks like I failed :( )

Originally Posted by Splynncryth
I figure I've created a big enough text wall for now. I hope that wasn't too disjointed, I was was trying to keep the length down (looks like I failed :( )

omg.....


great post, thats the sort of post I love.

Splynncryth, that was bloody amazing!

I just saw an MSI p45 review so I thought I'd comment on the one kernel of information relevant to this thread. The reviewer commented that the flash image was 4 meg meaning that's how big the chip is. I have no idea what their flash layout looks like and if all o that space really is set aside for BIOS or is used for other stuff on the board that needs firmware. Even if it is only using half of that, there is still the potential for MSI's graphical setup utility. I'll agree it's odd looking, but I don't know if it will affect usability any.

Hopefully, they will allow users to choose between a traditional looking setup bowser and their graphical one. And while I'm hoping, maybe they will provide a utility to change the graphics too.