Tag Archives: uefi

Tianocore (UEFI) now has a free FAT driver

Tianocore, the basis for many UEFI firmware implementations, has long been nearly free software. Low level hardware initialization is provided by CPU and motherboard manufacturers as binary blobs, but this part doesn’t matter for virtualization where we don’t need these blobs.

The main hindrance to shipping Tianocore in Linux distros was the FAT driver. UEFI standardized on FAT as a format for the boot partition. Microsoft supplied the corresponding FAT driver in Tianocore, but with a terms of use restriction that meant it was not free software. Anyway, today that changed. Microsoft has relicensed the code without the use restriction. The code is available here. So yes, thanks Microsoft. Also Intel who were involved in this.


Filed under Uncategorized

Gigabyte MP30-AR0: Flashing UEFI

I finally got UEFI flashed onto the Gigabyte board so now it is SBSA/SBBR compliant [edit: see note at end] and will just work with RHEL. Instructions here: https://lists.centos.org/pipermail/arm-dev/2016-March/001743.html

Here are the boot messages from TianoCore:

TianoCore 1.20.03 UEFI 2.4.0 Jan 26 2016 18:09:04
CPU: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
     SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Board: X-Gene Mp30ar0 Board
Slimpro FW:
        Ver: 2.4 (build 2015/05/22)
        TPC: disable
        AVS: support
        PMD: 970 mV
        SOC: 950 mV
The default boot selection will start in   1 second

Note: A few people have pointed out that the Gigabyte isn’t SBSA compliant because it lacks the right serial port, RTC and WDT. However it still boots RHELSA fine if you add console=ttyS0,115200.


Filed under Uncategorized

Edit UEFI varstores

See end of post for an important update

UEFI firmware has a concept of persistent variables. They are used to control the boot order amongst other things. They are stored in non-volatile RAM on the system board, or for virtual machines in a host file.

When a UEFI machine is running you can edit these variables using various tools, such as Peter Jones’s efivar library, or the efibootmgr program.

These programs don’t actually edit the varstore directly. They access the kernel /sys/firmware/efi interface, but even the kernel doesn’t edit the varstore. It just redirects to the UEFI runtime “Variable Services”, so what is really running is UEFI code (possibly proprietary, but more usually from the open source TianoCore project).

So how can you edit varstores offline? The NVRAM file format is peculiar to say the least, and the only real specification is the code that writes it from Tianocore. So somehow you must reuse that code. To make it more complicated, the varstore NVRAM format is tied to the specific firmware that uses it, so varstores used on aarch64 aren’t compatible with those on x86-64, nor are SecureBoot varstores compatible with normal ones.

virt-efivars is an attempt to do that. It’s rather “meta”. You write a small editor program (an example is included), and virt-efivars compiles it into a tiny appliance. You then boot the appliance using qemu + UEFI firmware + varstore combination, the editor program runs and edits the varstore, using the UEFI code.

It works .. at least on aarch64 which is the only convenient machine I have that has virtualized UEFI.

Git repo: http://git.annexia.org/?p=virt-efivars.git;a=summary


After studying this problem some more, Laszlo Ersek came up with a different and better plan:

  1. Boot qemu with only the OVMF code & varstore attached. No OS or appliance.
  2. This should drop you into a UEFI shell which is accessible over qemu’s serial port.
  3. Send appropriate setvar commands to update the variables. Using expect this should be automatable.

Leave a comment

Filed under Uncategorized