What is all of this OF, FDT, UEFI and ACPI about?

April 05, 2014

achimnohl-April 05, 2014

After my work on the ARMv8 LAMP server bring up, I've been trying to understand more about the firmware on ARM SoCs. Lately, there have been many mentions of acronyms such as OF, FDT, UEFI and ACPI. In this post, I would like to share what I found out. Please do not hesitate to comment where I am wrong. I am less confused than before, but still haven’t achieved enlightenment.

Many standards or types of firmware exist. As an example, the so called Open Firmware (OFW, OF) is an open, platform independent firmware standard (IEEE 1275). OF has been successful with SPARC and PowerPC architectures. As an example, Apple’s PowerPC Macs have been using OF-compliant firmware. The standard defines the interface that the operating system uses to query the specifics of the underlying hardware system. As an example, OF allows the operating system to easily query the address, interrupt, clocks, voltage regulators, etc., of a hardware component in an embedded system. Thus, those hardware details do not have to be hard-coded in the OS, which makes a lot of sense.

However, for a long time this has been done specifically for Linux and ARM architectures. In the old ARM support of the Linux kernel, each SoC or board had its own hardware-specific code. Often, even drivers which could be shared with other SoC families have been put underneath the board-specific code with hardcoded properties of the underlying SoC. With the increasing number of ARM SoCs, the resulting code duplication, and Linus Torvalds's comment in the Linux kernel mailing list ("Gaah. Guys, this whole ARM thing is a f*cking pain in the ass." 2011, http://lkml.org/lkml/2011/3/17/492), something had to be done. A goal has been set to build a single Linux kernel which would boot on different ARM SoCs. This is similar to the Intel world, where a single kernel image works on multiple PCs.

Driven by many forces, Linux for ARM has been changed in a way where the underlying hardware is described in a specification separate from the kernel. The ARM kernel image, which is only specific to the instruction set (e.g., v7 kernel, v8/aarch64 kernel), is reading in this hardware specification at boot time and dynamically configures the device drivers for the enumerated hardware components. The specification used here is the so called “device tree”. The device tree data-structure is a subset of the previously mentioned open firmware standard. In order to overcome the requirement to also move to an OF compliant firmware (boot loader), the so called Flattened Device Tree (FDT) format has been adopted. The FDT format is a simplified way (see example below) of passing device tree information to the kernel without requiring an OF compliant firmware. FDT is rooted at the Linux implementation of OF.

ethernet@40044000 
{
	compatible = "snps,dwmac";
	reg = <0 0x40044000 0 0x10000>;
	interrupts = <0 23 0 0 23 0 >;
	interrupt-names = "macirq", "eth_wake_irq";
	clocks = <&smbclk>;
	clock-names = "stmmaceth";
	mac-address = [4255FD60FA1D];
	phy-mode = "gmii";		
};

Listing 1: Example for a DesignWare GMAC description in a Flattened Device Tree

The ARM Linux move to use device tree has been done in incremental steps and is still ongoing. Not only does the SoC specific code need to change, but also the drivers e.g., read the configuration from the device tree, instead of a hardcoded C data structure. It has not been that long (December 2012) since the first Linux kernel (v3.7) supporting device trees was released.

At Synopsys, we have also adopted device trees for our virtual prototypes. The virtual prototype, which can be constructed and configured out of a model of arbitrary hardware components (e.g ARM core, Synopsys DesignWare IP, custom hardware, etc.) automatically generates a flattened device tree file. Thus, out of the box Linux can be booted on almost any arbitrary hardware configuration. The use model here is specifically targeting device driver development for IP where no HW exists yet (such as USB 3.1, eMMC 5.0, UFS 2.0). The user can quickly put a virtual SoC prototype in place, which is sufficient to start the driver development without worrying about porting the Linux kernel to the virtual SoC.

However, the device tree is not the end of the road. While researching in the areas of Linux, ARMv8 and what needs to be done on the software side for the emerging data center market; I stumbled over UEFI and ACPI. Initially, the more I read about it, the more questions than answers popped up.

< Previous
Page 1 of 2
Next >

Loading comments...

Most Commented

Parts Search Datasheets.com

KNOWLEDGE CENTER