So the class in UCSC is confirmed for Winter 2011.  You can find more information about it here.

Today I ordered Beagle Board with touch screen.  I am going to play with it and see whether I can use it for developing some UEFI drivers/applications.

Stay tuned.

Regarding curriculum, legacy BIOS is slowly phased out for UEFI.  Except for some standard things most part of legacy BIOS is proprietary.  It makes more sense to start basics of firmware and move to UEFI.  The following are the topics I was considering as part of legacy BIOS:

• History of BIOS and its evolution
• BIOS architecture: memory footprint and architecture
• BIOS Hardware and Software Interrupts
• BIOS Device Enumeration and Configuration
• Option ROM and its interfaces
• BIOS and option ROM limitation
• Boot options and methods
• BIOS Runtime Services
• ACPI & SMBIOS

For UEFI,

• UEFI and its history
• UEFI Architecture
• Boot & Runtime Services
• Understanding UEFI driver architecture
• Writing UEFI drivers and UEFI applications
• UEFI debugging methodologies

Finally end the course with a brief section on U-Boot and ARM architecture.

It will be boring not to have any practical lab sessions.  Unfortunately it requires a board and source to test it out.  For ARM, I found Beagle Board a good choice, it has UEFI port and has U-Boot support.  It will be great if I can find a PC based architecture for less than 100$ with relevant UEFI source.  For UEFI, Tiano will be my choice but open source version does not have all the drivers required to boot a board.  Another choice will be use some emulator.

I have close to 6 months to finalize on all this things.  Any suggestion on curriculum or board/source choice?

In the BIOS/EFI world the “old hats” cut their teeth on x86 assembly where (-1) is an insightful shortcut to (11…111b).  However, today’s BIOS (now called EFI) is written in “C”.  Unlike assembly, in “C” the watch word is portability.  Whenever possible, good “C” MUST be written without consideration of the compiler or the target hardware.  In “C”, if (-1) gives the proper binary number it is simply a matter of luck.  To get around a “bug” in the .Net compiler, you will often see these “fixes”:

(unsigned long long)(-1);

(UINT64)(-1);

However, if you consider that there is no universal negative binary notation, you will realize that it is beyond the scope of “C” to specify how any compiler maps any negative number into binary.  Considering these facts, you must agree that this is not a “bug” in the .Net compiler after all, it is simply luck that has run out.  I am all about holding MS accountable for their bugs, when they are real bugs.  Fortunately, “C” has a compiler agnostic, hardware portable, short cut that exactly fills the same desired purpose:

(~0);

(~0) is the shortest VALID way to express (11…111b) in “C”.  After all, how “short” is a short cut that has to be cast 3 ways ’till Sunday and why count on being lucky?

I had seen lot of BIOS rewrites in my professional life. I am specifically talking about PC BIOS. We all started with uncompressed BIOS image, then moved to compressed image to fit in existing flash (EEPROM at that time) chip. Then we need to move the BIOS out of x86 segment limitations. There was a rewrite for new technologies such as ACPI, USB etc.

Every time we rewrite the BIOS code base everything seems to be fine and clean. After couple of years, the code look ugly with lot of patches here and there, new features are poured over without proper code rearrangement etc. By this time the original developers/designers of that code will not be in the project. They (rather we) always look at the code and say.. Oh.. it is not our fault we did provide a clean proper solution it is the new Engineers who ruined the code; they don’t know what they are doing!

Even though it is true in some sense but from Robert C Martin’s foreword in the book ‘Working Effectively with Legacy Code‘ by Michael C Feathers:
“Designs that cannot tolerate changing requirements are poor designs to begin with. It is the goal of every competent software developer to create designs that tolerate change”

Apparently the original developers (that includes me too) are not ‘competent’ enough. I started seeing similar pattern in the EFI/UEFI code base already. Backward compatibility, newer chipset support, new protocols, new specifications etc are rapidly ruining the original code base. In many cases, the original design goal are not met anymore as original Engineers moved away and the design spirit didn’t distilled down to new Engineers! I see a serious problem here!

How to fix it? One common suggestion will be better documentation! Well, frankly how many people really read documentations, really? I think better way to handle this will be to incorporate proven software Engineering technologies. Coding standards should include Software Engineering technologies like Test Driven Development, Defensive programming etc, in addition to what to capitalize and how long should be the variables.

One basic thing that can help is unit testing. I used to say.. unit testing in the BIOS - that’s impossible! We need actual hardware to test the code nothing can replace the actual hardware! This is true.. but we can simulate most of the condition even before hardware arrive using mocks. Already we see an advantage here - Time-to-market is reduced since we don’t need to wait till hardware, we can already test our code!

What are unit tests? Unit tests are tests in isolation. They are not big tests. They run complete in fraction of a second and test just a procedure. They localize the issues. If your test is for more than a procedure than it basically not an unit test.

How are they useful? Think about a procedure written with an unit test. The test that verifies various inputs and outputs in a contained fashion. Later another Engineer wants to change this procedure, he/she can do the change and run the unit test (normally unit tests are run as part of build process) to make sure the original functionality is kept intact. Also from the unit tests she/he can understand what the original intent of the procedure. This ‘original intent’ helps a lot in future code updates!

There are lot of benefits I can say about unit tests.. let us keep that for our next post. Also I will write more about what tools are available for unit tests and how to write better unit tests in my future posts. If you’re impatient read the book and check out cMockery.

USB specification is not a good point to start. I find it is better to start with OHCI (Open Host Controller Interface) specification, then move to EHCI (Enhanced..) and finally to USB specification. Let us see what these specifications talk about and how it will help us to understand the USB itself.

USB Specification:
The USB specification defines the things starting from the USB connector on the board to the device. It details mechanical, electrical and communication protocol of the USB bus. Meaning it explains the various USB connectors (A, B, mini-A etc), bus characteristics, data transmission details etc. The latest specification version is 3.0. This 3.0 specification covers 4 different USB speeds such as:

• Low speed (1.5 Mb/s) - keyboard, mouse etc
• Full speed (12 Mb/s) - USB 1.1 flash drive
• High speed (480 Mb/s) - USB 2.0 flash drive
• Super Speed (5 Gb/s) - Newer devices

Host controller specifications:
The host controller specification talks about how actually software talks to the USB bus. It defines the hardware interface through which the system software (OS, BIOS etc) can communicate through the USB bus. There are 4 types of host controllers as below:

• Universal Host Controller Interface (UHCI) - During USB 1.1 specification time frame there was split between hardware vendors on Host Controller Interface agreements, thus two different specifications were created and supported by different companies. UHCI is one of those two specifications and it is supported in Intel Chipsets. As this is the very first Host Controller interface this is one of the badly designed host controller interface (in my opinion). It supports only low & full speed otherwise called USB 1.1 speeds.
• Open Host Controller Interface (OHCI) - Competitor to the UHCI specification, this is supported by AMD, Compaq and others. This is elegantly designed and easy to program when compared to UHCI. It supports USB 1.1 speeds only
• Enhanced Host Controller Interface (EHCI) - This supports USB 2.0 speed aka high speed. Luckily for the software developers there is only one 2.0 Host Controller. This utilizes most of the OHCI approach and thus easy to program.
• eXtensible Host Controller Interface (XHCI) - This host controller supports new USB 3.0 speed aka super speed. I didn’t look at the specification yet as it is not publicly available. This specification was almost split up just like USB 1.1 controllers but saved at the last moment - that is what I heard!

Mostly System Software Engineers need to worry about how to communicate through the host controller interface. It is more like when you start programming serial port first thing we want to learn is the programming interface, how to set the transmission speed, how to receive a byte or transmit a byte etc. It is same in USB too.

As the main goal of USB is to support wide range of devices connected to a same connector, the complexity of identifying and configuring devices falls under software stack. The USB specification tells you how to generate a meaningful generic (in the sense of device types) communication in the USB bus. There are various other specifications which details communication details for various type of devices like Human Interface Devices (HID) such as keyboard, mouse etc, Mass Storage Devices such as CDROM, flash drives etc.

In the next post I will discuss more into communication details.

All those documents are scattered in 100’s of websites. I decided to create a link to those documents in one of my blog post here and maintain it! Let us see how it goes.. if you have any suggestions/corrections let me know.

During the early stage of the BIOS there are not many chips to initialize. Memory detection is simple and straight forward, super I/O initialization is simple and nothing to enumerate - most of the configuration is through hardware jumpers. So 64KB was enough and it is kept as a ‘tiny’ memory model - single 64KB segment! Since the ROM is an EPROM no worry of corruption and thus no hardware protected boot block!

When more companies started making x86 clone CPUs, introduction of various storage formats (5 1/4, 3 1/2 Floppy drives, various HDD drives) and PnP buses (ISA PnP anyone?) made BIOS size grew dramatically. Every extra byte was squeezed out of BIOS. BIOS vendors started providing OEM with tools to select what CPU support they need in their BIOS. There was a time when people can choose 8 different CPU vendors each with different flavors of 386 or 486 compatible chips.

Compressing a certain portion of the BIOS was the only solution at that time. Initially only a very small portion of the BIOS was compressed. BIOS code was also separated into boot (or POST) and runtime code at this time. Mostly runtime code was compressed. Boot and runtime code were kept in two different segments. Boot code normally invokes runtime code using a single entry point with function numbers. The boot code should wait till runtime code gets uncompressed before using this interface. This was an ugly implementation that lived for quite sometime.

The main design choice for this ugly idea was Time-To-Market (famous TTM). There were not much Engineers to do parallel development of a better BIOS core (at least in the company I worked for). It worked perfectly for 1/2 decade, then the interface got uglier and EEPROM size increased to 128KB in newer systems. At this point, BIOS moved out of Shadow RAM and into RAM.

For a while it looked like we had lot of space both in ROM & in RAM, but not for long!

After graduation my first job was mainly with Unix System V & SCO Unix. Next job was in Networking drivers.. where I worked with fun MS-DOS/Windows 3.1 technologies like Extended Memory, Expanded Memory & Cloaking - art of using 32bit code/data in MS-DOS. I lasted a year each in my first two jobs.

Then I got my contact with BIOS again in my third job in 1995. It was a long affair with BIOS from that time. I was with that company till 2007 worked in various locations. I might soon move away from BIOS as full time job. This blog - biosism - is my journey to past into this world of ‘neglected elitism’.