Phoenix will be at Intel's Developer Forum in Taipei next week (20-21 October). Come visit us in booth S03.
On the 21st, Richard Heitmann, the Vice-President of Product Management, will be discussing "Laptop Theft Deterrence and Protection with Intel® Anti-Theft Technology - PC Protection and Phoenix FailSafe" at 10:20am in room VIP-A on the 4th floor.
Also on the 21st, Tim Lewis, BIOS architect will be co-presenting with Vincent Zimmer of Intel, discussing "Emerging Unified Extensible Firmware Interface (UEFI) Capabilities", which includes UEFI 2.2, PI 1.1 and the UEFI Shell 2.0 specifications. This will be held at 2:40pm in room VIP-A on the 4th floor.
For more information, see www.apacidf.com
A thread here poses the question: why do new CPUs still support 16-bit real mode when all of the operating systems are moving to 64-bit long mode. I had to stop and think about that, since I've been working in BIOS since 286s were news and 386s were revolutionary. I remember I went to the seminar in Santa Clara, CA where Intel detailed the 386 architecture in front of a packed house.
So, here are my top 5 reasons why we still have 16-bit support in x86 CPUs:
#5. Can't Get Started Without It. When an x86 CPU is reset, it returns to 16-bit real mode and starts execution at 0xFFFFFFF0. Since this address is outside of the normal 16-bit address space (which, with segment registers, is limited to 1MB), the CPU folks play tricks with the CS selector cache. In x86 CPUs, the current instruction location is CS:IP, where CS is the code segment (real mode) or selector (protected mode) and IP is the instruction pointer. To calculate the linear address in real mode, you multiply CS by 16 and add IP. In protected mode, you use CS as an index into the descriptor table and look up the linear address before adding it to IP. Paging adds yet another level. So, rather than calculating or looking up the CS linear address each instruction, the CPU caches it and then only changes the cached value when you change the CS register or modify the descriptor table. So, in order to execute the code at 0xFFFFFFF0, the CPU designers set CS to FFFF, but set the cached version of CS to 0xFFFFFFF0. Normally the first instruction is a JMP FAR instruction, which forces a reload of CS (and thus, the cached CS), which causes execution to continue at an address under 1MB.
#4. Long Mode Requires Paging and Paging Requires RAM and RAM Requires Initialization. In order to enter 64-bit long mode, you need to enable paging. 64-bit long mode is actually an attribute of the page descriptors. When the system resets, there are no page tables set up (since no one has created them) and no place to create them (since RAM has not been initialized yet). It is possible that future CPUs could cache a page table (similar to the CS descriptors above) or require that they be present at a pre-defined location. Until that time, the best you could do for CPU reset would be 32-bit protected mode.
#3. Operating Systems Still Use BIOS Real-Mode Services. Today's operating systems (or their commonly used drivers), including Linux 2.6.x and Vista SP1 still use 16-bit BIOS services. Linux video drivers still rely on INT 10h to handle mode switches, for the most part. Vista SP1 still needs INT 10h for the BSOD to reset the screen mode.
#2. Dos Lives! Some folks still run DOS, especially on manufacturing lines, and are loath to change.
And...the #1 reason why 16-bit real mode still exists today:
#1. Silicon Is Cheap. The 16-bit support is such a small portion of the overall transitor budget for modern CPUs. Removing the feature doesn't gain anything. So, if it ain't broken, don't fix it.
Trivia #1: The segment limits (64KB for real mode) are cached but are not reset when switching segment values, which can be used to allow real-mode data access >1MB. You switch to protected mode, load a selector with 4GB limits and then switch back to real mode. Voila! ds:[esi] can now get all the way to 4GB. This is the form of real-mode used in System Management Mode, many BIOS' and various DOS utilties.
Trivia #2: The 286 processor's reset address was 0x00FFFFF0 (just below 16MB).
Tim
it get's mentioned in Dilbert (here). If you follow the blogs, you find it doesn't take a Ratbert to wipe out your BIOS. Since the BIOS sits at the heart of all PCs and is tuned for every motherboard, following the step-by-step instructions provided by the manufacturer is usually the difference between a happy PC and a brick. Here are some common mistakes:
1. Trying to force a BIOS on the wrong platform. Just because the model numbers are similar doesn't mean that a BIOS for one model will work on another.
2. Trying to watch YouTube (or any other serious app) while flashing the BIOS. Not only is flashing very sensitive to timing issues, but if there is a system crash while flashing, most systems have trouble recovering.
3. Updating your BIOS when nothing is really wrong. If it ain't broken, don't fix it.
Phoenix flash utilties take some pains to make sure that the new BIOS image is actualy newer than the old version and that the model numbers matches.
Tim
The latest geek myth is that Phoenix's BIOS is somehow locking you (the system owner) into Vista. Feeding the conspiracy theory is the blog entry here. Digging a little deeper, you find the report here, which cites, as evidence, a note on a laptop vendor's web page which says:
"This BIOS is ONLY for use with Windows Vista. Please do not install this BIOS for use with Windows XP, or other Windows versions."
Then the author follows it up with a problem with the system password and a citation of a really old press release by Phoenix concerning our co-development relationship with Microsoft on some security stuff.
What's going on here? Pretty simple: the laptop vendor only validated their BIOS with Vista. What happens if you use another OS with the BIOS? Answer: the vendor didn't know or didn't guarantee the behavior. Validation for each OS requires $$$. It also means keeping up with the right drivers for that OS. How to make a cheaper laptop? One way is to only test with one OS. The way the warning is worded, maybe they knew that there were bad drivers out there or that the experience was sub-optimal.
What about the password stuff the blog mentions? If you reflash your BIOS without clearing battery-backed SRAM (CMOS) (pop the battery or use the clear-CMOS option in the flash utilithy), the locations used for certain settings (including whether password is set) get shifted around. Technically, the checksum is still valid in these cases, but the meaning of the bits has changed. All sorts of weird behavior can result.
Phoenix doesn't lock system owners into a particular OS with our BIOS. We regularly validate our BIOS (including the UEFI versions) with different Linux variants.
Conspiracy? No. Just someone jumping to conclusions.
Tim
I'm spending this week up in sunny (cough, cough) Seattle. Played in the snow on Hurricane Ridge and came down from the mountain to the Microsoft campus where the Longhorn Server plugfest is underway. We've got a couple of platforms here, testing UEFI (web site) and the Windows Hardware Error Architecture (WHEA, web site). WHEA is interesting, esp. the part about how you can "inject" artificial errors to make sure that the architecture is working. First, virtual hardware running virtual BIOS and now virtual errors. Next, the virtual BSOD...
UEFI is stable and there is quite a bit of discussion about what it means for platform vendors, both now and in the future (post server release). Hoping to hear more from Microsoft at WinHEC.
Tim
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
Ahh, the fond memories. MASM 6.11d (yes, 'd') was the first really stable and usable version of the MASM 6 family. A major upgrade, it added strong/weak externals (the foundation of Phoenix's TrustedCore build system), support for C-style calling convetions, stack variables and several high level constructs, such as .while, .if, .repeat and invoke. It was also a quirky beast whose macro language could drive the most stable engineer to tears trying to figure out when to use %.
Subsequent versions of MASM went on to add support for later processors (6.12 - 6.15), but they also added a strange incompatibility with the way strong/weaks and PUBLICs interacted which made it unusable. Sadly, as of February 2000, it was no longer available as a commercial product. Desperate BIOS engineers pled with Microsoft customer service people to send them just one more copy. Wiser birds found that you could buy "Assembly Language For Intel-Based Computers" by Kip R. Irvine, but only the 3rd edition. The 5th edition comes with MASM 8.
Fortunately, TrustedCore moved on to MASM 8 last year. But that led to a different problem: finding a linker that worked under 64-bit Windows. Despite using the new MASM 8, we still needed a linker that spoke 16-bit OMF. The old MASM 6.11 linker worked fine but (a) can't buy it either and (b) it was a 16-bit EXE that didn't run under 64-bit Windows. Fortunately, it turned out that the last linker shipped with 16-bit Visual C++ (1.52) was a 32-bit EXE (pheww!) and it almost worked. Turns out that, just before ship, Microsoft added a few bits which threw off the compatibility with older 16-bit linkers. With the help of a few Microsoft engineers, we located a version that fit the bill.
So, MASM is dead. Long live MASM...
Tim
The articles about Skype reading your BIOS have been making the rounds, such as this article here. Essentially, it looks like Skype goes out and reads the 64KB just below 1MB and saves it away into a file. This works because the Windows DOS box gives read-only access to the BIOS area. Apparently symptoms started showing up when folks starting running the Skype on 64-bit Vista, which doesn't allow DOS executables to run.
So what, exactly, is in that 64Kb which is so valuable? Good question. That portion of the BIOS is actually constructed out of a few pieces of the original flash device. Possibilities include:
1. The SMBIOS tables. These tables contain a series of records which describe various pieces of information about your system, much of which is not exposed in any other way. For example, it includes information about the type of DIMMs you have on your platform, the computer manufacturer, the model numbers, number of PCIe slots, etc. The format of the tables is described in the SMBIOS specification, produced and regularly updated by the Desktop Management Task Force (DMTF). See here for information on the release of the SMBIOS 2.5 specification last December, which added, among other things, new CPU types, new types of system enclosures for CompactPCI & AdvancedTCA, SATA/SAS port connector information, and an enum for fully-buffer DIMMs (FB-DIMMs).
2. The copyright notice. With a little bit of work, you can figure out the BIOS manufacturer and other tidbits from the various copyright strings.
3. Pointers to the ACPI tables.
Frankly, these are pretty poor pickings. All of this information is available through standard Windows interfaces, such as WMI. No magic here, considering someone went through a lot of trouble to save it away.
Update: Since the original post, Skype has commented publicly about it here, saying that it was used as a means of uniquely identifying the platform via their EasyBits framework. They state that the information was never sent back to Skype. According to this analysis here, the offending EasyBits were removed in version 3.0.0.216.
Tim
An interesting article here gives a basic overview on how standby and resume work under Linux. Other than getting a few basic acronyms wrong (D in DSDT = Differentiated, not Discrete, A in FADT = ACPI, not Address) it is a good overview of what happens when you press the sleep button on your machine. Most of the Linux support for ACPI came from Intel's ACPI CA project, described here. The most recent version of the ACPI specification is 3.0a and is available on the official ACPI site www.acpi.info (which was down as of tonight).
This article points out something I always have trouble explaining to folks, "In a lot of cases, it's just down to bugs in the drivers" Back in the APM days, you really could blame the BIOS, since almost all of the save-and-restore of system state was built into the firmware. But that didn't work very well for plug in devices. So ACPI moved most of the responsibility up to the OS, leaving the BIOS with just the non-standard or non-enumerable bits of the process (saving and restoring the DRAM configuration, setting up GPIOs, and fixing chipset bugs etc.)
It turns out that putting a system to sleep is almost as much work as putting my kids to sleep: an established routine, cooperation from all parties and, at the end of the day, a little magic.
Tim
