Development and Debugging of UEFI Drivers on Intel Galileo, Part One, Introductory

Hello, dear habrachitateli.

Many of you may be interested in the topic of developing and debugging UEFI driver code and applications, which is not yet widely covered on the network, but to which I was fortunate enough to have a direct relationship.

In this regard, I plan to write a series of articles on the development and debugging of UEFI drivers on the Intel Galileo Gen 1 hardware platform, because this platform has, in my opinion, the best price / quality ratio for the above task.

The first part of the article is an introductory one, in it I will talk about the UEFI standard, the TianoCore project and its shortcomings, about Intel's sudden decision and their Galileo board, about the reasons for choosing this particular hardware platform as the base one and plans for the next parts.

Unified Extensible Firmware Interface

As you already know, UEFI is a standard developed by Intel in collaboration with Microsoft and other members of the UEFI Forum for components and firmware interfaces for various computer equipment. The standard describes the structure of firmware files, the interface between the firmware and the OS (which is actually called UEFI) and between the components of the firmware (whose name is more modest - PI ). A good introduction to the structure and mechanisms of UEFI work is available in the Beyond BIOS book written by direct participants in the development and implementation of the standard, but I won’t tell you better than them anyway, so I won’t repeat it, especially since the UEFI boot process has already been described in one of the of my past articles . If for you terms like " PEI phase" or "DXE driver "still sounds unfamiliar - read it and come back.

TianoCore and its shortcomings

If there is an open standard, then there must be its open implementation, otherwise such an “open” standard is worthless (citizens, let’s pass, we don’t linger, there’s nothing to look at Office OpenXML, nothing). To avoid such a price overtaking UEFI, Intel, together with other members of the UEFI Forum and the community, began to develop an open implementation of the "upper" part of the UEFI standard , i.e. DXE and BDS phase code common to all supported systems and processor architectures. It is based on the UEFI Development Kit, which has recently been updated to version 2014 SR1. Fans of nightly builds and trunk code are offered the EDK2 repository, the “stable” slice of which is all versions of UDK. The "lower" part of the standard (i.e. SEC phasesand PEI, hardware-dependent and initializing this hardware part) was until recently closed to all x86-based systems and was provided either as BLOBs to everyone (as is now done on Minnowboard V1 and Intel UEFI server boards Development Kit), or as source code bundled with CRB , NDA , and contract with IBV thousand for about $ 30-40 for an annual license for code, IDE and debugging tools, so enthusiasts had little to do but use virtual machines to debug UEFI drivers of their own design (debugging through QEMU is one of the standard ways for EDK2) or do dirty hacking, search for leaked source codes and development tools, and the like.

Intel rushes to the rescue

Salvation from this difficult situation came from an unexpected side - suddenly Intel released an Arduino-compatible Galileo board , on which, in addition to running Yocto Linux with an Arduino emulator for running sketches from the SPI chip, the open implementation turned out to be almost completely (except for microcode) an open implementation UEFI BIOS, suitable for assembly in the debug-mode, adding to it the components of its own design and debug both through UART (that had already occurred in the above Minnowboard V1 and other evaluation boards), and using the JTAG interface, low cost debug Ica based FT232H and utilities OpenOCD and GDB (but this feature users x86 processors got on my mind for the first time). Now, for hardware debugging, the firmware code is not needed eitherIntel BlueBox (~ $ 3000 apiece), nor Intel System Studio (~ $ 2000 per year license), and almost all firmware code is available under the BSD license.

Now the second generation of Minnowboard motherboards is being prepared for release - MAX (pre-order is already available), for which in September this year they also promise to introduce an open UEFI implementation, but at the moment it is not yet, and Galileo remains the only open-source UEFI x86 motherboard available mere mortals. Here we take it as a base platform for our experiments.

Galileo

When Intel released this controversial product , many quite sincerely wondered why we needed a SoC debugging board with the “new” (actually creatively recalled old) i586 + architecture, no GPU, no Audio, but with miniPCIe, USB host, JTAG- port, UEFI and Linux, which at the same time is limitedly compatible with Arduino (because it uses its own version of Arduino IDE), is limitedly compatible with x86 (since "adult" Linux distributions are installed on it with a considerable tambourine, and after detection of a bug in the operation of the lock instructionthey also need additional fine-tuning with a file to bypass it, and most programs have already been built for the i686 a long time ago and therefore will not work on Galileo without rebuilding), while the CPU Raspberry Pi that loses in performance is at least twice as expensive as it. I must say, at that moment I was perplexed with them.

The guys from Intel, of course, told us about the bright future of the Internet of Things, and predicted a tenfold increase in sales of Quarks, while tactfully avoiding answering the simple question "why is this Quark better than ARMs or MIPSs for the same money."

And now, finally, the application of this strange board has been found, and $ 70 for it no longer seems like a completely unreasonable waste.

Plans and Survey

In the second part, I plan to dedicate the preparation for the board to work: downloading and assembling the BSP , connecting the programmer to the ISP connector on the board, assembling and flashing the Debug version of UEFI.
In the third part, it is planned to cover debugging of DXE driver code using Debug messages via UART, as well as debugging through JTAG using OpenOCD, GDB and, possibly, trial version of Intel System Studio.

But before writing a sequel, I’m interested in your opinion, dear habratchiteli. Thanks in advance for your vote.