Phoenix BIOS Developer Blog

Entering Setup On A Virtual BIOS

In a somewhat surreal article, this user on VMWare's support site (here) asks, "How to enter the BIOS of a VM?" Yes, you read it right, there is a virtual BIOS in the virtual machines. Why? So that an OS running in a virtual machine can call the BIOS in order to initialize correctly.

There's just something strange about wanting to pop into the BIOS Setup on a virtual machine. What are you going to do? Overclock the CPU and the DRAM? Switch from the on-board to plug-in graphics adapter? Better yet, reset the BIOS' administrator password!

Turns out you need some of your video game button-pressing skills to press F2 at just the right moment. The best method: Repeatedly pressing Ctrl-R to reset the virtual machine and then pressing F2 to get into setup.  Needs all the hand-eye-coordination you can muster.

Tim

Into The Shadowlands...

Ever wonder what happens when the OS is loading, after the BIOS hands off control? From the article and video here, Microsoft gurus and fellow UEFI contributors Jamie Schwartz and Andrew Ritz describe the shadowlands...

(this is the single threaded world of pre-operating system start-up context where there is no memory manager, no object manager, no kernel period - it takes highly skilled developers to write code in this memory confined space, the land of real mode code and the BIOS).

Worth a look to see life inside the guts of the Windows loader.

Tim

Phoenix Tools Depot

Just a plug for the Phoenix Tools Subscription Program.

Want to look at the ACPI tables? Use the ACPI Disassembler. Search the SMBIOS data? Flash a Phoenix BIOS? Develop UEFI applications with an SDK? All are there. Many of them also have source.

What are these? Well, Phoenix engineers write a lot of tools. And we're a pretty talented lot so, while we don't support them as products, they are really useful. Testing, validation, information dumpers and editors for BIOS and various industry standards.

So, take a look. And bug your local Phoenix sales guy to subscribe.

Tim

And I Thought You Liked The Phoenix Logo...

With the introduction of hybrid drives (like the ones mentioned here, from Samsung), notebooks can get ultra-low power drives because they don't have to keep the hard disk running as much. Hard drives use rotating meda. The slower notebook drives rotate at 4200RPM. Typical desktop drives use 5400RPM and faster drives go for 7200RPM or 10,000RPM. Like high performance sports cars, the more RPMs, the more energy required.

Up until now, power-conscious ment smaller capacity (thus less energy to spin up) or variable speed drives which could spin faster when plugged into the wall but slower when running on battery power.

With hybrid drives, the approach is a little different. Commonly used data is cached in flash memory rather than on the rotating media. Flash isn't as fast and typically has slower write times. But it consumes a lot less power. Also, flash wears out after a while, although the typical number of writes is pretty high (~1 million sector writes typical). Performance is still an issue as well, since flash read is slower and, when you get out of the cache, you still have to wait while the drive spins up.

Other initiatives, like Intel's Robson technology (see this Wiki article) have used this combination as a one-two punch to speed up boot time. It works like this: you start the drive spinning up, but in the mean time, the first n megabytes worth of boot data is already cached in the flash. This means the boot process is well on its way before the drive spins up to full speed and then it can take over. If your OS were small enough, you could launch the entire OS without ever touching the rotating media.

Sad to say, this means that you don't get to look at the Phoenix logo quite as long during boot.  But you can always stop by with a keypress...

Tim

Apple Presents At UEFI EBC Summit 2007

Back in high school, I studiously avoided taking the Pascal class. At the time, I was a true AppleSoft BASIC and 6502 assembly-language hacker. But one of the items that always fascinated me was that the Apple Pascal compiler.  The compiler didn't generate "real" code. It generated p-code. That p-code was, in fact, a stack-based assembly language, but not for any real CPU. Instead, an interpreter processed the p-code. Which made it hard to do anything useful except write high school computer homework assignments.

Fast forward to 2007, Apple is back presenting (along with me and several Intel folks) about another type of p-code: EBC. EBC (EFI Byte Code) is a pseudo-assembly language which is designed to execute correctly on either 32-bit or 64-bit machines without modification. It is designed to operate seamlessly with other UEFI drivers written, even if they're not in EBC. The goal was that you could take your native UEFI driver and recompile it to work in EBC without modifications.

This sounds great. But have you considered what happens when the size of a struct can change based on the size of VOID *? Your sizeof() operator no longer generates a constant value. Instead, it is more like a function. How do you initialize that structure? You can't do it at build time because the offsets of the members may vary depend on the size of your INT.

So this event got everyone together: motherboard folks, BIOS vendors, plug-in card vendors and compiler writers, in one big room, threw in some pizza, and tried to get everyone to play nice with each other. The two server systems in the room provided sufficient white noise to mask the hubbub of folks talking about compiler issues, driver issues and BIOS issues. It was certainly nice to see a number of high quality 3rd party UEFI drivers in the room.

Dong Wei, the chair of the UEFI Test Working Group, pointed out that our next p-code problem will probably be the user-interface forms language (IFR) in UEFI 2.1. Yet-Another-P-Code. Sounds like the topic for another summit.

Tim