Writing for the UEFI BIOS in Visual Studio. Part 1 - development environment deployment, compilation and debugging

Introduction

This article will describe how to quickly start programming for UEFI in the edk2 framework in Visual Studio , without spending a lot of time setting up the environment in the usual way, according to the original manuals. It is enough to give the git clone ... command in the root directory of the disk, and that’s all, the environment will be fully installed and ready to go. Requires 64-bit Windows 7 and above with Visual Studio 2008-2015 . These two conditions are not necessary, but then you will have to work a little on assembling the edk2 - Visual Studio system into a single whole, a brief memo will be given.

The purpose of the article is to guide the beginner by the hand on the first UEFI project, while remaining in his familiar environment. For more experienced people, I hope it will be interesting to work in VS instead of the usual command line, or to parse the approach and transfer it to your favorite Eclipse .

Let's start with simple things, outputting a string to the console and Russification (a pretty popular thing, and easy to implement), then there will be work with forms in HII (what was called BIOS Setup pages in everyday life ), then graphics, then Boot Manager , and then it will be seen (s).

Interested persons - please welcome under cat.

Now you need to decide whether you need it or not. We’ll spend half a page on this at the start, so as not to spend half a day and at the end understand that you need something completely different. Or, I hope, on the contrary - to catch fire with enthusiasm and make time to read the article.

Good at first

1) The equipment is not needed from the word at all. No Evaluation Boards , no Intel BlueBox JTAG for $ 3,000. Everything will be debugged in the 32-bit OVMF virtual machine - the qemu virtual port ported by Intel for debugging UEFI Firmware . To recompile under a real platform, it is enough then - after debugging - to rearrange the key pair in the compilation settings, and that’s all.

2) We will work with all the features of Visual Studio , i.e. breakpoints, watch, step execution and the rest are available. Recompiling and starting a simple module takes 8-10 seconds.

3) The file system of the virtual machine is available on the Windows machine for writing and reading. It will come in handy if you need to edit UEFI Shel l scripts , after starting, see screenshots and analyze logs using Windows tools.

4) No assembler , only C / C ++ .

Now about what we will not do

1) We will work in DXE (where UEFI Shell already exists ) and in later phases. In the earlier phases, we will not be useful, since no one will let us in, at least for Intel processors. Later there will be an explanation of why. If you want to make a full cycle, from turning on to loading the OS, and quickly and without bothering you with a bunch of information that is unnecessary and uninteresting to you at the moment, you do not need to manually configure the system - do not read further, but type “coreboot” in Google .

2) "Graphic" UEFI with a mouse and buttons, like Dell, MSI and others, will not be here. These are paid environments for use in large companies. There are, of course, enthusiasts who themselves create them with their own hands, without first answering the question “Why?”, But usually their enthusiasm ends on the second form with buttons.

3) We will work with the Visual Studio compiler . Those who wish can configure gcc in cygwin , or icc , but at the moment the task is not to get the optimal fast code, but the task is to quickly go the way to the beginning of full work.

Everything, the preliminary dances are over, who is needed is inspired, who is needed is scared.

Let's get down to business

First of all, download the repository to the root of the disk. It will unfold in with: / FW . If the FW directory at the root of the disk already exists, then it would be better to rename it, because all the configs are configured exactly there in absolute paths. Not in Feng Shui, but perfectionists can always correct absolute paths with relative ones by writing the appropriate script that does this.

So, whoever has git on the machine on the command line, execute the command in the cmd window (or in Far Commander , it doesn’t matter) from the root directory:

git clone https://github.com/ProgrammingInUEFI/FW

and those who don’t have it follow the link to github , download the zip file and open it to the directory with: / fw .

As previously promised, here is a tip from Intel training on using a different configuration than the one indicated at the beginning of the article. Look for your combination in the nameplate if the proposed one for some reason does not fit:

Configuring an environment for a version other than VS2010

Open the file c: \ FW \ edk2 \ Conf \ target.txt and in the line
TOOL_CHAIN_TAG = VS2010x86

Replace VS2010x86 with the tag of your version of Visual Studio . For Visual Studio 2010, the tag will remain as it is, for other versions of VS - see the picture above, or the list at the beginning of the file c: \ FW \ edk2 \ Conf \ tools_def.txt

Actually, the edk2 development environment is fully deployed and you can work in it from the command line . Some people have been working this way all their lives (“to die in hardcore, to maintain the spirit of the old school and all that” - (c) CodeRush in his classic article ). But we will go further, transferring a person from MSVS back to the command line is inhumane, especially in 2017.

Set up a project in Visual Studio

We open Visual Studio , in it we open Solution NT32.sln from the directory C: \ FW \ VS \ NT32 . In order to reduce the time needed to enter the topic, the solution has already created the NT32 project of the same name , in which the settings described below have already been made. If you can’t create it yourself - in order to have guaranteed working project settings. This approach will greatly reduce the time to search for the source of problems, if any. Nevertheless, it is better to go through the path described below yourself, and understand the meaning of the settings - this will facilitate the configuration of the following projects.


So, in steps:

Project creation

We create a new project in Solution NT32 for Visual C ++ (right- click on Solution NT32, Add-> New Project , select the Makefile Project option ), and call it MyFirstUEFIProject (or whatever else). Click Finish .



We select the NT32 project in Solution , select Project-> Properties from the context menu and make project settings.

Configure NMake Options

Select the line Configurarion Properties → NMake in the window on the left, the Build Command Line line in the window on the right.



Click Edit ... and in the text box that opens, enter:

set NASM_PREFIX=C:\FW\NASM\
call c:\FW\edk2\edksetup.bat --nt32
build

Now it’s worth explaining a little what we are doing. In fact, we write in this window the usual batch bat file instead of the makefile.

The first line sets the NASM_PREFIX assembler environment variable as edk2 understands it , that is, the path where the nasm.exe file lies . We will not write in assembler ourselves, but our assembly system requires assembler.

The second line calls the edk2 environment configuration script and sets up environment variables for this compilation and launch session (these variables are not reflected outside VS). The –nt32 switch tells the build system to compile the source for the Nt32Pkg package located inC: \ FW \ edk2 \ Nt32Pkg . There are many of these packages, we will consider them, but not now.

In the third line, we give the command to compile in the just configured environment ( build.exe is in C: \ FW \ edk2 \ BaseTools \ Bin \ Win32 , this path is written in the previous line, in edksetup.bat )

So, here’s what we have should appear in the end in the Build Command Line text box :



Then, in the next line, enter the Rebuild Command Line in the opened by Edit ... window the following text

set NASM_PREFIX=C:\FW\NASM\
call c:\FW\edk2\edksetup.bat --nt32 
build clean
build

The build clean command means what you expect. She does a complete rebuild of the project with a recompilation of all modules.

What we enter in the window from the Clean Command Line , probably all have already guessed:

set NASM_PREFIX=C:\FW\NASM\
call  c:\FW\edk2\edksetup.bat --nt32 
build clean

Honestly, this option is not really needed, in 99% of cases Rebuild is enough , but let it be - for example, clean the environment to transfer it to another place or fill it on github.
As a result, we should get this window:



Everything with the NMake configuration .

Setting Debugging Option

So, open the Debugging line and enter:
In the Command line :

C:\FW\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\SecMain.exe

In the line “Working Directory” :

C:\FW\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\

A couple of comments:

SecMain.exe - explain now what it is - for a long time, if very briefly and simplified - then this is an analogue of bootloader-a, which launches everything else.

Working directory - all successfully created modules will be placed here, and they will be available all at once from the command line.

So, here is what we should get after the settings in this window:



That's all with the project settings.

Project building

We call Build Solution , look at the screen for about a minute, during which there is the greatest risk of being scolded by the compiler, and go to drink coffee - it will all be created 10-15 minutes, depending on the resources of your computer. Nothing tedious is forever, and in the end we get a message:

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

If, instead, something else is received, see if you completed all the steps correctly. The most difficult case is to get it:

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

this is a bug of the VS2010 environment and means that VS2010 is installed without SP1. Put SP1, or look for ways to plug this error on the Internet.

If you get an error and it is not clear from the compiler messages what it is - rearrange the default project to NT32 and run it to compile with debugging. If there is an error - check the correspondence againTOOL_CHAIN_TAG to the predefined values ​​described in tools_def.txt . Nothing else can rest there, unless Visual Studio itself is installed, hmm, it's not quite standard, or it uses a third-party compiler.

Jobs at UEFI Shell

So everything compiled well and you read these lines. Now click on your favorite F5 and after about a minute of working with the disk (we will reduce this time a bit later) we get the following picture:



Actually, this is the UEFI Shell . How to work in it - a lot of manuals have been written, look at Google, but for now we will do a few things in it.

1. We look that we compiled there for these 10 minutes. We enter fs0: ( UEFI-of Shell is not case sensitive), and then the ls -b , where option -b means waiting press Enter to scroll the page, because there's a big list, not on one screen.

Now it’s clear what the “Working Directory” parameter meantin the configuration options of the Visual Studio project - C: \ FW \ edk2 \ Build \ NT32IA32 \ DEBUG_VS2010x86 \ IA32 \ . There is the same list of files, and it is better to watch it (and edit scripts) through the developed Far Commander (or Total Commander ) shell than from the command line in the UEFI Shell .

2. In UEFI Shell and type “hel”, press Tab and see Helloworld.efi on the screen . It’s not that we didn’t know at all what would happen if we press Enter after that, but we need to check! Click and get three UEFI Hello World! . The number of repetitions is an external parameter that is configured in the environment settings (and not in the source) and we will then analyze this configuration.

3. We type exit and get into our favorite and familiar window:



Well, you can admire the fruits of your labors. After that, we use the arrows to focus on Reset and the virtual machine closes, returning us to the familiar MSVC window.

Print your line

Creating your own application will require a lot of settings, which will be better considered in the next article - otherwise it will turn out to be a large amount, and nobody reads long sheets. However, the heading of this article says "Programming", and so far we have only been engaged in tuning. To keep the promise, let's make a very simple modification of the HelloWorld application in this article using its existing set of files, and in the next article we will create our own using the Intel UEFI Driver Wizard, since it is inhumane, wildly routine and carries the risk of losing 90% of the audience, since starting a complete set of files for a UEFI driver (or application) to run away from is complete. If you hook a person, he will come to this with time, and if you just want to play around, it makes no sense to spend a lot of time on it, since a lot has already been done automatically for a long time through the UEFI Driver Wizard , and in Feng Shui, which is naive to expect from a beginner.

So, open the file in Visual Studio
C:\FW\edk2\MdeModulePkg\Application\HelloWorld\HelloWorld.c

and add our simple line, immediately after declaring the variables in a single function:

Print (L"I did it in UEFI!\r\n");

Of course, the text can be replaced with anything, only in English letters - the Russian font edk2 does not yet understand, we will add it in the following articles. You can put a regular breakpoint on this line and see how Visual Studio behaves.

We press F5 , after compilation and elimination of errors we enter "fs0:" , HelloWorld.efi and we get the following output:



That's all. In the next article, we will work a bit at UEFI Shell to get comfortable, and we will analyze a little theory.