Development and debugging of UEFI-drivers on Intel Galileo, part one, introductory

Hello, dear habrachiteli.

Many of you may be interested in the topic of developing and debugging UEFI driver code and applications, which is not yet widely covered in the network, but to which I was fortunate to have a direct connection.
')
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, since This platform has, in my opinion, the best price / quality ratio for the above task.

The first part of the article is introductory, in it I will talk about the UEFI standard, the TianoCore project and its flaws, the sudden Intel decision and their Galileo board, the reasons for choosing this hardware platform as the baseline and plans for the following parts.

Unified Extensible Firmware Interface

As you already know, UEFI is a standard on components and firmware interfaces for various computer hardware developed by Intel in collaboration with Microsoft and other members of the UEFI Forum. The standard describes the structure of the 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 is available in the Beyond BIOS book, written by direct participants in the development and implementation of the standard, but I still will not tell better than them, so I will not repeat myself, especially since the UEFI boot process has already been described in one of the my past articles . If terms like " PEI- phase" or " DXE- driver" still sound unfamiliar to you, read it and come back.

TianoCore and its shortcomings

If there is an open standard, then there should be its open implementation, otherwise this “open” standard is worth a penny (citizens, we pass, we don’t linger, there’s nothing to look at at Office OpenXML, nothing). So that such a price does not overtake UEFI, Intel, together with other members of the UEFI Forum and the community, has taken up the development of an open implementation of the “upper” part of the UEFI standard , i.e. DXE and BDS phase codes, common to all supported systems and processor architectures. It is also based on the UEFI Development Kit, which has recently been updated to version 2014 SR1. Fans of nightly builds and code from trunk are offered an EDK2 repository, the “stable” slice of which is all versions of the UDK. The “lower” part of the standard (i.e., the SEC and PEI phases, dependent on the hardware and occupied by the hardware itself by initialization) was until recently closed to all x86 systems and was provided either as a BLOB to everyone (as is now done on Minnowboard V1 and server boards from the Intel UEFI Development Kit), either as source code bundled with CRB , NDA , and a contract with IBV thousands of about $ 30-40 for a one-year license for code, IDE and debugging tools, therefore, there was practically nothing left for enthusiasts to do except lzovat debug UEFI-drivers proprietary virtual machines (debugging through QEMU - one of the regular ways to EDK2) or to engage in dirty hacking, finding leaked source code and development tools, and the like.

Intel to the rescue

The escape from this difficult situation came from an unexpected side - suddenly Intel released the Arduino-compatible Galileo board , which, apart from the Yocto Linux build from the SPI chip, built with the Arduino emulator to run sketches, was also almost completely (except for microcode) 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 OpenOCD GDB and utilities (but this feature users x86 processors got on my mind for the first time). Now, for hardware debugging of the firmware code, neither Intel BlueBox (~ $ 3000 per piece) or Intel System Studio (~ $ 2000 per license for a year) is needed, and almost all the firmware code is available under the BSD license.

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

Galileo

When Intel released this ambiguous product , many quite sincerely wondered why we needed a debug board on the SoC with the “new” (actually creatively recalled old) architecture i586 +, without a GPU, without Audio, but with miniPCIe, USB host, JTAG- port, UEFI and Linux, which is limited to Arduino (because it uses its own version of Arduino IDE), is limited to x86 (because “adult” Linux distributions are installed on it with a tambourine, and after finding a bug in the lock instructions also require additional fine-tuning of its traversal of a file for and, as most programs have long been collected for i686 and because work on Galileo without rebuilding will not be), at the same CPU Raspberry Pi losing performance, being at least twice as much as her. 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 Quark, while tactfully evading the answer to a simple question "than this Quark is better than ARMs or MIPSs for the same money."

And now, finally, the use of this strange motherboard was found, and $ 70 for it no longer seems like an absolutely unreasonable waste.

Plans and survey

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

But before you write a sequel, I am interested in your opinion, dear habrachchiteli. Thanks in advance for your vote.