Phoenix BIOS Developer Blog

MASM Bug #1

Quick! Can you see the bug in this code?

getTsc PROC NEAR USES EAX EDX
  DB 0Fh, 31h
  mov WORD PTR es:[ebx][ecx], ax
  add ecx, 2
  ret
getTsc ENDP

Ok, here's a hint. The following is the actual code generated:

0000006E getTsc PROC NEAR USES EAX EDX
0000006E 0F 31              DB 0Fh, 31h
00000070 50               * push eax
00000071 52               * push edx
00000072 66| 26: 89 04 19   mov WORD PTR es:[ebx][ecx], ax
00000077 83 C1 02           add ecx, 2
                            ret
0000007A 5A               * pop edx
0000007B 58               * pop eax
0000007C C3               * ret 00000h
0000007D getTsc ENDP

If you look closely, you'll see an extra push eax/push edx and an extra pop edx/pop eax inserted by the assembler. Why? Because of the USES EAX EDX on the PROC line. This tells the assembler that EAX and EDX should be preserved, so the assembler adds the PUSH instructions before the first instruction and the POPs before each RET in the function.

So what happened? Well, it turns out that MASM doesn't consider the DB 00Fh/DB 031h as "real" instructions and thus doesn't trigger the generation of the PUSHes. You can validate this by changing the code to:

getTsc PROC NEAR USES EAX EDX
  rdtsc
  mov WORD PTR es:[ebx][ecx], ax
  add ecx, 2
  ret
getTsc ENDP

This will get you the following code:

0000006E getTsc PROC NEAR USES EAX EDX
0000006E 50               * push eax
0000006F 52               * push edx
00000070 0F 31              rdtsc
00000072 66| 26: 89 04 19   mov WORD PTR es:[ebx][ecx], ax
00000077 83 C1 02           add ecx, 2
                            ret
0000007A 5A               * pop edx
0000007B 58               * pop eax
0000007C C3               * ret 00000h
0000007D getTsc ENDP

Now it generates correctly. Why? Because RDTSC is an opcode. This kicks MASM's prologue generation code into gear. The worst problem I've seen with this forced me to add a NOP and ORG $-1 in the code, but this was with tool-generated code. Haven't found any Microsoft reports on this behavior, but it's pretty consistent.

This is the first in a series of MASM quirks and bugs. Thanks to Savitha for bringing up this topic.

UPDATE #1: Well, this certainly generated a flurry of e-mails inside of Phoenix. Here's an example of the strange behavior when you put DB's inside of MACROS, sent in by Naonobu:

TEST_MACRO MACRO siidSig
DB 68h ;PUSH imm16
DW siidSig
TEST_MACRO ENDM

testProc PROC USES EAX EDX
TEST_MACRO 1234h
TEST EAX, EAX
RET
testProc ENDP

This code fails for the same reason, which makes it difficult to use macros for new CPU opcodes

Meanwhile, Kelly points out that MASM's default behavior makes it difficult to use PUSHF/POPF because it inserts SUB [R|E]SP, xxxx in the prologue code.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

Inside Phoenix Version Control, Part 2

As I mentioned here, Phoenix has a relatively unique version control system to take care of the roughly 240,000 assembly-language source files in our TrustedCore code base. Not only does this lead to problems when synchronizing 14 different development sites around the world, it also leads to problems when creating version labels.

Every file archive in TrustedCore has a revision. A revision is just a number which uniquely identifies a set of changes made to one source file.  A version label is used to record the revision of every file archive in TrustedCore at a particular moment.

Usually we generate several labels as we move towards a major new release of TrustedCore, 'A', 'B', 'C' etc.  Our BIOS Production team creates the labels, and then the Quality Assurance folks use that version label to retrieve retrieve the exact revision of every file in the release. They put it through its paces, find bugs, report bugs and then engineering fixes bugs. At some point, the BIOS Production team creates a new label and we start the cycle again. After the bugs are all cleared, that label is declared "Gold" and we release the product.

So most old-school version control systems (like CVS or PVCS) add the labels directly into the file archives. That is, the piece of data which says: version label X = revision level Y is inserted directly into the archive. That means that every single archive must be read, modified and written. That's 240K files on the network. Generating a label can take days (literally) this way.

In order to speed up this vital process, Phoenix created DFLs (Directory File List). In each directory of TrustedCore, there is one file which just lists the current revision levels of every source file. Every time we want a new revision of a file archive to be included in a label, we update its entry in the DFL.

This seems like kind of a hassle (and it is). But they payoff is that, instead of having to add the label to all 240,000 files, we only have to apply the label to 23,000 DFLs.

But wait! It an effort to create infinite levels of regression and save even more time, we have lists of lists, called CDLs (Component Directory Lists).  These files just list  the current revision levels of every DFL.  Every time we want a new revision of a directory to be included in a label, we update its entry in the CDL.

So now, instead of having to add the label to all 23,000 DFLs, we only have to apply the label to 350 CDLs.

This approach needs Phoenix special tools to keep the grunt work down, but it helps a lot a crunch time when we're about to do a major release.

Next time we'll talk a little bit about how the BIOS comes together for one platform.

Tim

Inside Phoenix Version Control, Part 1

Phoenix has the rather unenviable position of maintaining probably the largest body of assembly language source code in the world. At my last count, there were over 4K assembly-language source code files in an average deliverable and ~240K files in our TrustedCore code base.

On top of that, while TrustedCore is one product with hundreds of variants.  The variants represent the different combination of features and silicon support that go into supporting a single platform. Phoenix itself maintains over 500 different variants on the basic TrustedCore (BIOS) product and our customers maintain thousands more. The average life-span of a single variant is about 24 months, from start of a silicon-support product, through the delivery of a typical mobile platform.  Embedded and server platforms have a longer lifespan and desktop platforms have a shorter platform. In a way, TrustedCore is never shipped the same way twice.

Compound this problem by having a few hundred developers simultaneously working on the same product at the same time, from 14 different sites around the world, some of which have less total Internet bandwidth than the broadband connection that I use from my house.

In this series, I'll talk a little bit about Phoenix maintains this massive source code database in a fairly efficient manner, using a combination of standard and home-grown source code control tools.

Phoenix's source code is organized into directories and sub-directories. Some of these directories are for silicon (i.e. CHIPSET\INTEL\SOLANO). Some directories are for features (ACPI\STD32.600). Some directories are for individual platforms (BIGREF\TC\865\GBF.TC). In order to build TrustedCore, you go to the platform directory and type 'nmake' and that starts the build process for the entire BIOS.  While each variant doesn't require every directory, many directories are used by most, if not all, products.

Each of the 14 different sites (India, Europe, Taiwan, Oregon, etc.) has a server with a complete copy of all of the source code and all of the source code archives. But each of the directories which are part of TrustedCore is "owned" by only one site.

For example:  CHIPSET\INTEL\SOLANO is owned by our Beaverton office, ACPI\STD32.600 is owned by our Taiwan offce and BIGREF\TC\865\GBF.TC is owned by our west coast U.S. office.  We use an internal utility WHOOWNS to return the owner of a directory.

K:\nb\source\NUBIOS\BIGREF\TC\865\GBF.TC>whoowns

Santa Clara

The site (or server) which owns a directory is the "master" or "owning" site. So, if you want to check in a change to files in that directory, you must change the archive on the owning site.

Normally, when I log into Phoenix's internal network, the default is to use the Milpitas (or Santa Clara) server. That means I will have fastest access to archives which are owned by Milpitas. If I want to check in files to a directory owned by another server, I have to change servers. We do this using an internal utility MAPDRIVE

C:\pv\dos>mapdrive twn
Site TWN assigned to Drive K:

Now, checking in to a remote server, like Taiwan, is slow for me, since I'm based in the U.S. I might do it for a file or two, but if I need to check in a lot of files or need to do a lot of work over a period of time, I might request that the ownership of the directory be changed from Taiwan to Milpitas. Once the ownership is changed, my access is much faster because I'm talking to a U.S. based server.

This is important, because it allows Phoenix to give very fast access to our massive source code base to any engineer around the world on a directory-by-directory basis.

So what about other engineers? What do they do? Well, lurking in the background is PSYNC, a Phoenix utility which monitors each directory on the owning server for changes in the archives. When it detects a change, it copies the source code archive and the most recent revision of the source file to every other server.

Most engineers just retrieve source code using the copy of the archive on the local server. Doesn't this lead to problems of potentially being out of date? Yes.  But it usually doesn't lead to problems for three reasons:

1. The synchronization process is fast, since the process is continuous and the number of archives changed per day is fairly low.
2. Most engineers don't need access to the bleeding edge of development in every directory. They usually retrieve from a version label rather than from the tip revisions.
3. Many of our sites are in radically different time zones. Many times, the Taiwan, China and India sites are starting just as the U.S. sites are finishing.

This distributed ownership of archives also gives one other benefit: we have a built in backup process. When a server dies, there are usually 13 other copies of every archive! And when we need to bring a new server on line, the synchronization process can automatically bring it up to speed by copying all the files from the other server.

It works remarkably well, has managed the transfer between different networks and runs using a fairly standard version control system. 

Next time, in part 2, we'll talk about versioning and labels.

Tim