Sun 13 January 2019
By Leif Lindholm
In UEFI .
tags: UEFI Windows
Background
EDK2/TianoCore has a very complex build system. Part of that is to let developers use vastly different
toolcains to build (GCC, CLANG, Visual Studio, ICC, XCODE). But it also provides different profiles for
different versions of these toolchains.
(As a side note, this is what leads to the frequently repeated misconception that EDK2 cannot be built with
GCC later than version 5. The reality is that GCC behaviour and command line options have remained stable
enough since version 5 that we haven't needed to add new profiles, and the GCC5 profile works fine for 6-8.)
From the start, the ARM/AARCH64 ports were developed using ARM's commercial toolchain and GCC. Whereas on
the Ia32/X64 side, most of the development has tended to happen with Visual Studio (GCC mainly being used
for Ovmf). This means that for a developer moving from x86 to ARM, they have not only had to get used to
a new architecture, but they've also had to deal with a new toolchain.
Installing the tools
Visual Studio
Visual Studio 2017 has included ARM/AARCH64 support since release 15.4. Not publicly announced,
and not complete - but sufficient to build firmware, and UEFI applications and drivers. And with release
15.9, the support is now public and complete . Which makes for a good time to ensure we can provide a familiar development
environment for those already using Visual Studio.
So I set out to make myself a development environment in which I could build all current architectures in
the same environment - and in Visual Studio. And since I have my new ARM64 laptop, I'll make sure to get
it working there.
There is no native Visual Studio for arm64, but the (32-bit) x86 version runs just fine.
Search for it in the Microsoft Store, or go straight to
the download page . The Community Edition is sufficient,
and is free (as in beer) for individuals or open source development.
I'm not going to go through downloading and starting the installer and how to press the Next button,
but a few things are worth mentioning.
First, you don't need to install everything in order to get the basic toolchain functionality. I opted
for the "Linux development with C++" toolset and ended up with what I needed.
Second, make sure the components "Visual C++ compilers and libraries for ARM", "Visual C++ compilers and
libraries for ARM64" and "Python 2 32-bit" are selected.
NASM
For building EDK2 for Ia32/X64, you may also need nasm . Currently, there is no
arm64 build of nasm for Windows, but again the 32-bit x86 variant does the job. (It also won't currently
build with Visual Studio, so that's not a way to get a native one.)
Acpica-tools
Acpica-tools (including iasl
for building ACPI tables)
comes in a .zip file (32-bit x86). Rather ungracefully, the Visual Studio build profile simply assumes
the binaries from this archive have been extracted and placed in C:\ASL
, so do that.
GIT
If you don't want to rely completely on the Visual Studio git integration, the 32-bit x86 variant
available from here works fine.
Building
Open the Visual Studio Developer Command Prompt directly (don't worry about the GUI).
Then, from your edk2 directory, run:
C:\git\edk2>set PYTHON_HOME=C:\Python27
C:\git\edk2>set NASM_PREFIX=C:\Program Files (x86)\NASM\
C:\git\edk2>edksetup.bat rebuild
to build the native BaseTools and set up the build environment.
This will complete with a warning that !!! WARNING !!! No CYGWIN_HOME set, gcc build may not be used !!!
,
which is fine, because we're not using GCC.
After this, the build
command works as usual - V2017 is the toolchain profile we want.
So, to build OvmfPkg for X64:
C:\git\edk2>build -a X64 -t VS2017 -p OvmfPkg\OvmfPkgX64.dsc
Or to build HelloWorld for AARCH64:
C:\git\edk2>build -a AARCH64 -t VS2017 -p MdeModulePkg\MdeModulePkg.dsc -m MdeModulePkg\Application\HelloWorld\HelloWorld.inf
What's missing?
Thanks to Pete Batard , support for building UEFI applications and drivers for
AARCH64 was already available upstream. So for Option ROM drivers or UEFI command line utilities, you
should be good to go.
However, since we've really only used GCC/CLANG for the port up till now, we're lacking assembler files
using a compatible syntax. In addition to this, when trying to build whole platform support, there are
several issues with (ARM-specific) C source files that have never before been compiled with Visual Studio.
I started ploughing through this end of last year - a hacked up version leaving many asm implementations
empty (just so I could get through and identify all of the C issues) is available in one of my
working branches .
Of course, this appears to have suffered some bitrot (and change in behaviour with VS 15.9), so I will
get back to that over the next few weeks. And as always, if you're impatient - patches welcome!