Archive for the ‘Technical’ Category

BIOS/Firmware Class

Thursday, October 7th, 2010

First of all thanks to all of you for the comments!  I will look into the suggestions and give my feedback on each of them.

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.

Posted in Technical | 2 Comments »

(-1) Your number is up!

Tuesday, April 13th, 2010

(This is a guest posting from my good friend Robert Rauch!)

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?

Posted in Technical | 1 Comment »

USB 101 - Specifications

Thursday, March 12th, 2009

One of the major project I did in AMI is implementing USB 2.0 for AMIBIOS8. It was a wonderful adventure to learn USB and to be able to implement the host controller support from scratch. Programming for USB controller seems like a daunting task but if we get the basic operations of USB controller then it is very simple.

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.

Posted in USB, Host Controllers, Technical, System Software | 2 Comments »

Needle in the haystack!

Wednesday, January 21st, 2009

Last week my co-worker and me searched the internet for the document that lists all the PnP ID (used in ACPI mostly). It took for both of us a while to get that document, supposed to be maintained by Microsoft. It is maintained as a text document hidden in MSDN documentation online. That made me think about other specifications and documents - we, the BIOS Engineers search time to time.

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.

Posted in Specifications, BIOS, Technical | 1 Comment »

Size does matter!

Thursday, January 15th, 2009

Around 1992 the BIOS vendors started to compress part of their BIOS. Before that the BIOS was uncompressed and kept in 64KB EPROM. I remembered spending lot of time in EPROM UV erasers and blank checking the EPROMs.

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!

Posted in BIOS, Technical | No Comments »


gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.