Desktop Management Interface (DMI) Access Interface

Well, I should make an article about this later because it doesn't make it to my first edition book. First, let me emphasize that we're looking at the DMI Access Interface from the BIOS execution context, not from within an OS context. The DMI v2.0 specification (www-pc.uni-regensburg.de/hardware/TECHDOK/BIOS_DMI_20.PDF) "vaguely" states that the interface to the DMI from the BIOS execution context as follows:

To prevent the proliferation of interfaces for accessing information embedded in the System BIOS, the Desktop Management BIOS Specification will follow the System Device Node model used by Plug and Play, and use Plug and Play BIOS functions to access DMI information. Plug and Play functions 50h-5Fh have been assigned to the DMI BIOS Interface.

Well, it's not immediately clear what does it mean by "Plug and Play functions 50h-5Fh". A closer look into the PnP BIOS spec v1.0A (www.osdever.net/documents/PNPBIOSSpecification-v1.0a.pdf) reveals the crux of the matter. When you read through the PnP BIOS spec v1.0A, what you will find in section 4.4 is a description to the PnP BIOS entry point. Furthermore, try to find function "number" higher than PnP function 43h and you're out of luck. Now, from the description in the DMI v2.0 spec snippet above it's now clear that the higher function "number" (above 43h) is relegated to another spec (presumably after the PnP BIOS spec was ratified). One of them is the DMI spec. PnP BIOS spec was published in 1994, while the DMI spec v2.0 was published in 1996. Therefore, accessing the DMI "services" in BIOS code (or ring-0 code in an OS) is carried-out via PnP BIOS interface at function 50h to 5Fh. It seems all of this past effort was part of the DMTF standardization (I'm not 100% sure).

License for the source code in the Low Cost Embedded x86 Teaching Tool article

I haven't had the time to update the copyright notice in the Low Cost Embedded x86 Teaching Tool. However, if you want to use it (and modify it) for your own purposes, you could do so under the Gnu Public License (GPL) version 2 which mandates you to relase your changes. Coreboot project have been using some part of it for their use under the GPL. I'm going to update the license notice in the article ASAP. Cheers.

IOMMU Specification from Intel and AMD

This is just a dump of the links to download AMD and Intel IOMMU specification. For those of you new to IOMMU, a good introductory is at http://en.wikipedia.org/wiki/IOMMU.

Now, the specs:

AMD specs: http://support.amd.com/us/Processor_TechDocs/34434-IOMMU-Rev_1.26_2-11-09.pdf and http://support.amd.com/us/Processor_TechDocs/48882.pdf

Intel spec: http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf

Just a note that Intel calls the IOMMU as Virtualization Technology for Directed IO (VT for Directed I/O).

"Frying" Another USB-to-IDE Converter

Last wednesday was the second time I fried another USB-to-IDE converter device due to buggy ATA command that was sent to the IDE device (a DVD-ROM Drive). I'm not really sure which command that causes it to happen. But, now is the time to look into ATA command set much deeper. Well, this is just a precaution for guys/girls out there working with *-to-IDE converter device. Be very careful with ATA command that you send to the IDE device. Apparently, the problem was the "offending" ATA command corrupt the firmware inside the converter. I haven't look very detailed into what type of chip used in the converter. Probably MIPS-based or ARM-based microcontroller. Too bad I don't have JTAG debugger to see what exactly happens.