Intel ACPI IGD OpRegion Spec, and IntelSiliconPkg added to Tianocore

Jiewen Yao of Intel added a new module to the public Tianocore source project.

[PATCH 1/2] IntelSiliconPkg: Add initial version.
This package will include open source common Intel silicon related modules.
This series patch adds the initial version of IntelSiliconPkg and an include file.
We will use IntelSiliconPkg for open source common Intel silicon related modules.

I hope Intel transitions some of it’s binary-only releases from it’s Intel Firmware Support Package (FSP) into this source-only-based package!

It appears the first candidate for this new IntelSiliconPkg is the Intel IGD (Integrated Graphics Device).

[PATCH 2/2] IntelSiliconPkg/IgdOpRegion: Add definition for Intel IGD OpRegion.
Add IGD OpRegion definition from Intel Integrated Graphics Device OpRegion Specification.

OpRegion structures: Sub-structures define the different parts of the OpRegion followed by the main structure representing the entire OpRegion. Sub-structures:
INTEL_IGD_OPREGION_MBOX1  MBox1; // Mailbox 1: Public ACPI Methods
INTEL_IGD_OPREGION_MBOX2  MBox2; // Mailbox 2: Software SCI Inteface
INTEL_IGD_OPREGION_MBOX3  MBox3; // Mailbox 3: BIOS/Driver Communication
INTEL_IGD_OPREGION_VBT    VBT;   // Video BIOS Table (OEM customizable data)

Click to access acpi_igd_opregion_spec_0.pdf

Hmm, I don’t see IGD mentioned in the list of ACPI specs:

I am pretty sure that one of Intel’s Beyond BIOS whitepapers mentions IGD/ACPI/UEFI interactions, sorry I forget which one it is, it may have been the one on BIOS memory maps:

It appears Intel first released this spec in 2008. Besides UEFI, Intel IGD OpRegion support is in coreboot as well. And in the Linux kernel.

For more information, see the patch on the EDK2-devel list:

UEFI ported to RISC-V!

There’ve been a few presentations on porting UEFI to the RISC-V, but now there is public code! Abner Chang of HPE has submitted multiple patches with RISC-V support for various components of EDK-II.

[PATCH 0/3] *** EDK2 base tools support RISC-V processor***

EDK2 base tools support RISC-V arch. EDK2 build tool changes to generate RISC-V PE/Coff image from RISC-V ELF file, handle RISC-V relocations and generate EDK2 FW with RISC-V image machine type.

BaseTools: Support build RISC-V PE/Coff image.
The changes on BaseTools is for building RISC-V ELF image and PE/Coff Image. Also to generate FW and FV for RISC-V arch.     

[PATCH 0/2] *** EDK2 MDE for RISC-V processor ***

MdePkg: MDE implementations for RISC-V arch. The implementations of RISC-V MDE base libraries.

    Add RISC-V architecture image file machine code.
    Add RISC-V architecture relocation type.    
    Add RISC-V architecture context buffer.
    Add RISC-V architecture exception types.
    Add RISC-V architecture PXE tag definition.    
    Add RISC-V architecture EFI image machine type.
    Add RISC-V architecture removable media boot path.
    Add RISC-V architecture processor binding.
[PATCH] OvmfPkg/PciHostBridgeDxe: [RISC-V] Add back OVMF PciHostBridge module.

Use OVMF PCI host bridge driver as the RISC-V platform BUS.
This driver is used by RISC-V Virtualization package (RiscVVirtPkg).
Currently the platfrom spec for RISC-V is not yet ready, thus we use PCI host bridge in temporarily.

[PATCH] RiscVVirtPkg: RISC-V QEMU package.

This is RISC-V QEMU package. The image which built from this package can be launched on QEMU RISC-V port (not official QEMU). RiscVVirtPkg utilizes below modules from EDK2 OVMF package,
 – PciHostBridge DXE driver.
   Use PCI host bridge driver as RISC-V platform bus spec for adopting PC/AT components.
 – QemuFwCfgLib
   QEMU firmware configuration.
 – OVMF ACPI timer lib.
 – QemuFlashFvbServicesRuntimeDxe
 – QemuVideoDxe
 – XenIoPciDxe

[PATCH] RiscVPkg: RISC-V processor package.

 New processor package added to EDK2 open source for RISC-V.
[PATCH] MdeModulePkg/DxeIplPeim: RISC-V arch DxeIpl.

The implementation of RISC-V DxeIpl.

This is only the first round of these multiple patches, given initial discussion it is likely there will be another round. In the discussion for this patch, it appears there is more support upcoming, not yet public. In the thread, Abner mentioned:

“The UEFI/PI ECR for RISC-V is ready but not yet send to UEFI for review. I have been told to upstream RISC-V code first and then submit the spec. I will confirm this again.”

I am looking forward to seeing what happens with the RISC-V UEFI port, and seeing some consumer devices based on RISC-V!

For more info, see the various threads on the EDK2-devel list:

Intel FSP 2.0

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:

Microsoft relicensed EDK2 FatPkg to BSD!!

Laszlo Ersek of RedHat has updated the EDK2’s FatPkg to use the BSD license!

“This is huge. It will enable Fedora to ship OvmfPkg and ArmVirtPkg builds. It will enable RHEL to ship OVMF in Main. Of course other GNU/Linux distros will benefit similarly.”

I rarely say this as much as I’d like to, but: “Great job Microsoft!”

EDK2 issue tracking

The Tianocore project, the open source subset of the UEFI Forum’s private UEFI implementation, is talking about getting an issue tracking system:

Excerpting from the initial thread on the topic:

The built-in issue tracking system that comes with GitHub isn’t sufficient to satisfy a key requirement.  There needs to be support for multiple Tianocore-related programs.  As you know Intel has a system today that’s internal to Intel where we track issues.  That does not meet the needs of the community.  And to help improve transparency, and better engage with the community I’m driving the discussion and bring up of a bug tracking system. The goal is to have one operational by March 21, 2016 (WW13).  We’re 6 weeks and counting from that deadline.  I’m interested in community feedback, gathering requirements, and feedback on proposals for which system to use. We’re going to transform issue tracking on Tianocore a transparent, community driven behavior. Key requirements for the system include (but not limited to):
* OSS (does not have to be free)
* Ability to bulk import/export databases, data (CSV)
* Secure, ability to shield sensitive issues
* Group credential management
* Supports mobile views (phone/tablet)
* Ability to generate reports
* Can be used to generate quick tasks for community members (e.g. Find a Task)
* Integrate with GitHub

Speak up if you have input. More info:

(I’m hoping they also going to spend some time spend some time updating the Tianocore Security Advisories. They have only done 2 of them, and it has been over a year since those have been published. I expect there are a few Tianocore issues that are merit security advisories, but nobody is spending time to publish new advisories.)

Tianocore moving to Github

“This message is to notify you that near the end of January 2016 the active repository for EDK2 development will switch from using SourceForge to GitHub. The repository found at SourceForge will continue to be a read-only mirror of the master branch on GitHub. […] As part of this change a number of process changes will be adopted to support better use of git. This includes the method for sending out patches for review and other minor changes. […] “

Full article:

UEFI updated to IPMI v2.0

Daocheng Bu of Intel has added IPMI 2.0 definitions to the EDK2 project.

MdePkg/Include/IndustryStandard/Ipmi.h             |  26 +
…/IndustryStandard/IpmiNetFnAppDefinitions.h     | 614 +++++++++++++++++++++
…/IndustryStandard/IpmiNetFnBridgeDefinitions.h  | 238 ++++++++
…/IndustryStandard/IpmiNetFnChassisDefinitions.h | 294 ++++++++++
…/IpmiNetFnFirmwareDefinitions.h                 |  26 +
…/IpmiNetFnGroupExtDefinitions.h                 |  26 +
…/IpmiNetFnSensorEventDefinitions.h              |  44 ++
…/IndustryStandard/IpmiNetFnStorageDefinitions.h | 514 +++++++++++++++++
…/IpmiNetFnTransportDefinitions.h                | 531 ++++++++++++++++++
9 files changed, 2313 insertions(+)

For more information see the edk2-devel posts (or look at the current EDK2 trunk in the above files):

EDK2 supports, multiple workspaces

The RSS feed reports that the EDK2 now supports multiple workspaces:

An update to the EDKII build tools now allows the setting of multiple paths that will be searched when attempting to resolve the location of packages. This new feature allows for more flexibility when designing a tree layout or combining sources from different sources. The new functionality is enabled through the addition of a new environment variable (PACKAGES_PATH). The PACKAGES_PATH variable is an ordered list of additional search paths using the default path separator of the host OS between each entry. The first path in the list has the highest priority and the last path has the lowest priority. The path specified by the WORKSPACE variable always has the highest search priority over any PACKAGE_PATH entries. To use this feature, the PACKAGES_PATH environment variable must be set prior to running the edksetup script. The reason for this is that the edksetup script determines the location of the Conf and BaseTools directory location based on the values of the WORKSPACE and PACKAGES_PATH environment variables. The use of the PACKAGES_PATH environment variable is optional and if it is not defined the build will function like it has in the past.

So, check PACKAGES_PATH for any strange entries from attackers trying to insert evil modules in to your builds, from now on. 🙂

UDK2015 expected mid-October

The UDK github wiki has been updated to give information about upcoming UDK 2015 release next month. It appears to include most UEFI 2.5 features, plus a few new ones. Excerpt of changes:


Support UEFI 2.5 Updates:
 + Smart Card Reader & Smart card edge protocol (H file only)
 + Inline Cryptographic Interface Protocol (H file only)
 + UEFI USB Function I/O Protocol (H file only)
 + Add NVM Express Pass Thru Protocol
 + Add UFS stack
 + Add SD Device Path (H file only)
 + Add reconnect Browser Action
 + Ability to refresh the entire form
 + The default/options for the Ordered List question
 + Keyword Strings support
 + New CPER Memory Section (H file only)
 + Adding support for No executable data areas
 + Persistent Memory Type support
 + Add the Support for new PKCS7 Verification Services
 + System Prep Applications
 + Add SMBIOS3_TABLE_GUID in configuration table.
 + Exposing Memory Redundancy to OSPM
 + ESRT: EFI System Resource Table and component firmware updates
 + IPV6 support from UNDI
 + UEFI “Next” Feature –
    * IP_CONFIG2 Protocol
    * Boot from HTTP (Excluding IPV6)
    * DNSv4 and DNSv6

Support PI 1.4 Updates:
 + New MP Service PPI
 + Multiple CPU health info
 + PEI SetBootMode Service() clarification
 + GetMemoryMap Update for ReservedMemory
 + New Graphics PPI
 + New Capsule PPI
 + SIO PEI and UEFI-Driver Model Architecture
 + Extended File Size Errata
 + Add Reset2 PPI

Excluded from UEFI 2.5 Updates:
 + Bluetooth Support (H file only)
 + Errata Boot Manager Policy & SATA Device Path Node
 + RamDisk Device Path
 + UEFI “Next” Feature –
    * Boot from HTTP (Excluding IPV6)
    * WIFI support (H file only)
    * EAP2 Protocol (H file only)
    * REST Protocol
    * Platform recovery
    * Customized Deployment of Secure Boot
    * BMC/Service Processor Device Path

Other features:
 + Add ACPI 6.0 definitions.
 + Add SMBIOS 3.0 definitions.
 + Support OpenSSL version 1.0.2d.

Looking forward to the upcoming checkins to Tianocore’s EDK2 trunk!

Full roadmap article:

Gentoo support for EDK2

On the EDK2-devel mailing list, Stéphane Veyret just announced Gentoo Linux for EDK2, including rEFInd application support. Excerpt:

I made a Gentoo ebuild for EDK2. This ebuild transforms a little bit the installation in order to be able to use the product as is generally used a library in Linux. Samples are also modified. I also made an ebuild for rEFInd as a proof of concept.

More Information:

AMD clarifies firmware strategy

A while ago, I asked on the UEFI development list for someone to clarify AMD’s UEFI strategy. I’m unfortunately, not that strong on AMD64 technology, and was a bit confused by the available documentation as to a few things. Gary Simpson, Firmware Architect at AMD, was kind enough to reply to my questions, with verbose reponses. I’ve slightly edited the message, cleaning up the email intro and simplifying my questions, but did not alter any text responses from AMD. Below, lines beginning with “Q:” are questions from me to AMD, and the bold lines with “A:” are Gary’s replies.

Q: Can anyone explain AMD’s strategy w/r/t UEFI and BIOS, UEFI and coreboot?
A: Here’s some quick background: AMD is a founding Board member (i.e. Promoter) of the UEFI Forum and an active member in most of the work groups.  We are proponents of the UEFI and ACPI interfaces (because they provide standardized firmware API’s, allowing shrink-wrapped OS distributions, without customized drivers, enabling end-user OS flexibility and choice).  Also, despite some birthing pains with individual implementations, UEFI is enormously more secure than legacy BIOS was.  AMD’s evolution from legacy BIOS to UEFI has happened over the last ten years in sync with the schedules of our industry partners (IBV’s, OEM’s) and their code bases.  We’re not seeing any demand for legacy BIOS enablement anymore, so we no longer focus any effort there.  Coreboot is the only remaining legacy code base we enable.  Coreboot enablement is provided by AMD’s embedded group for a market-appropriate subset of our chips.
    By the way, you may be assuming that the traditional competitiveness between companies persists in the UEFI Forum and the spec work groups that it oversees.  But there is actually very little of that (especially compared with a lot of other industry-standards bodies).  The general attitude within UEFI is that the firmware layer should be unified, interoperable, well-specified and secure.  There is no room for competition or company-specific advantage in the firmware layer.  (Then, of course, we all go home to our individual companies and work to create competitive advantage at other layers, such as hardware or higher-level software.)  I just want to make sure you understand the atmosphere of cooperation and common-cause that exists between the various OEM’s, Silicon Vendors, OS Vendors, IBV’s, and others that make up the UEFI Forum.  That cooperative atmosphere pervades the UEFI work groups, as well as the UEFI Board of Directors.

Q: What AMD X64 models use UEFI, what models use BIOS, what models use coreboot?
A: We don’t specify or control this.  Our customers can implement whatever platform firmware solution they choose.  However, the firmware components AMD provides focus primarily on UEFI solutions.  As mentioned, our embedded group also enables coreboot for a selected subset of our chips.  Coreboot is the only legacy code base we still target.  For coreboot, we maintain wrappers and a centralized function dispatcher, but our core code is natively targeted at the various UEFI-style code bases used by our IBV partners, our OEM customers, and Tianocore (e.g. EDKII).

Q: I’m unclear if current/upcoming AMD X64 models are still using BIOS on most or only some of their systems, as well as coreboot -vs- UEFI usage and future plans.
A: Internally, we create Customer Reference Boards (CRB’s) and build platform firmware in-house to support them.  These in-house BIOS’s, which we use to bring-up and validate our new silicon designs, are all UEFI-based.  These are almost always based on our AGESA firmware (see below) combined with a platform code base from one of the IBV’s.  Additionally, AMD’s embedded team ports coreboot to their versions of the CRB’s.

Q: Are there different goals for UEFI/BIOS/coreboot for consumer desktop/laptop models -vs- server models? I’ve heard one person speculate that servers are focusing on BIOS, laptops are focusing on GPUs/DirectX [and perhaps UEFI].
A: AMD’s goal is simply to provide what our customers want and need.  Server manufacturers were, in general, slower to transition from legacy to UEFI,  but we are no longer seeing any demand from them for legacy BIOS.

Q: I’m really unclear how they can get Win8 logos if they’re using BIOS. If they’re getting logos for those systems. Do AMD systems have less Win8 technical restrictions than Intel systems in this regard?
A: In combination with the BIOS Vendors and/or the OEM’s, AMD makes UEFI solutions (supporting Secure Boot, etc.) available for all our chips.  We qualify for our Win8 and Win10 logo certifications the old fashioned way – by passing the tests.  We make sure that all of our CRB’s pass the certifications tests, and we assist our OEM customers as needed to make sure that their production systems pass as well.

Q: What is AMD equivalent of Intel FSP, for closed-source blobs need alongside Tianocore open source?
A: Our deliverable is called AGESA (AMD Generic Encapsulated SW Architecture).  It plugs into the IBV and OEM code bases and does initialization and configuration of the AMD silicon (CPU, GPU, FCH (southbridge), GNB (Graphics North Bridge), etc.).  We private-license AGESA source (for free) to our IBV and OEM partners.  For coreboot, AGESA is currently provided as a binary module.  We did previously publish AGESA open-source in the coreboot repository for a few of our chips over the last several years.  You can have a look at those if you’re interested.

Q: How do I debug UEFI on AMD systems, like I can use Intel WinDbg/GDB-based solution for debugging Tianocore with Tunnel Mountain box?
A: AMD does not have an equivalent to Tunnel Mountain. There aren’t any motherboard manufacturers willing to produce and sell such a board, since our volumes would be smaller than Tunnel Mountain.  We do design and build Customer Reference Boards for each new chip.  The CRB volumes are small and the cost is high, so they mostly go to larger customers.  Even inside AMD, these are usually in short supply.

Q: Are you going to port LUVos (and LUV-live) — including it’s new and bundled various tests, especially CHIPSEC — to your systems? CHIPSEC won’t work on AMD64 systems, only Intel systems, implementations are different.
A: We don’t have any current plans to do this, but your question may cause us to do more investigation in this area.

Q: For AMD’s new ARM Ltd.-based systems, are they going to use UEFI on all of them, or just some? What will be used on others, U-Boot or something else?
A: This is an area where we are feeling our way forward. Different customers will want different things.  We will try to accommodate them all as well as we can.  We plan to offer AGESA for UEFI code bases only, so we won’t support U-Boot directly, but we will enable a UEFI solution that creates a Flattened Device Tree, which should boot any OS’s that normally sit on top of U-Boot.

Q: Are you using Linaro for UEFI bits and making your own ARM firmware, our outsourcing to IBV, if so which?
A: We are working with IBV’s, replicating the traditional firmware-development process from the x86 PC world, but we recognize that traditional ARM-embedded customers may be looking for a free-source stack from us, so we are working to prepare for that possibility as well.

Q: Are you going to help Linaro with their AArch64 port of LUV-live and CHIPSEC, especially including AMD-specific AArch64 implementation issues?
A: No plans yet, but we will investigate.

—- [End of ‘interview’.]

Thanks, Gary, for the detailed answers to my many ignorant questions!  For more information, see the email thread on the edk2-devel mailing list, mainly see Gary’s response on July 31st:

It is especially good to hear about AGESA being open source! I hope Intel can match that bar, with FSP…

Since the responses from Gary, I’ve done two AMD64-centric blog posts, one on the most recent (?) vulnerability, and one on ASESA.

Some additional questions I should’ve asked but didn’t think of until now:

Q: Has AMD or any AGESA licensee (IBV, OEM) ever hired an security audit of the AGESA sources, and published the results?

Q: Does the AMD’s SimNow, either Public or Partner release, support OVMF (the public release appears to not), or is there any other emulator/simulator accurate enough to facilitate porting of CHIPSEC to AMD64 systems?

Q: Can you clarify use of TrustZone on AMD64 — not ARM Ltd.-based AArch32/AArch64 systems? Does TrustZone even work on non-ARM systems as-is, or was this a new port? Are there any more technical details you can point us to for this?

Again, thanks Gary! For the sake of enterprise security, I hope AMD helps with and AMD64 port of CHIPSEC, or at least helps document the issues that need to be removed and added to and AMD64 port, so the open source community can help with the port.

tool mini-review: UEFI Reverse

UEFI Reverse (uefireverse) is a collection of tools to help with analysis of UEFI-based firwmare, written by Jethro Beekman (jethrogb). It consists of four tools.

1) EFI PE Run (efiperun): Load and run EFI PE image files on Linux.

DISCLAIMER: This program loads and runs PE image files. It does this without any protection mechanisms. Certain memory sections will be mapped writable and executable simultaneously. Do not run this on untrusted software. Think carefully before running this on trusted software. Load and run EFI PE image files on your favorite operation system (Linux). PE images are just x86 code that will run fine as long as the environment is correct. efiperun is to EFI as Wine is to Windows, but much less advanced. This tool is not meant for long-term use and only for debugging. There’s instrumentation everywhere, which is great for debugging but makes things slow.Memory generally doesn’t get freed. Most EFI functionality is not implemented. Functions that are implemented only provide the bare minimum. This tool aims to aid in debugging/reverse engineering by providing a framework that you can extend as necessary. By default, this program will load a PE image specified on the command-line, call the entry point, and exit once that returns. If the entry point does not return in 10 seconds, the program will abort with SIGALRM. Beyond running images, you can also extend this execution, with a “debug module”, an extension to efiperun that can run code before and after loading a PE image. This is useful to install protocols beforehand that the PE image will use or to access the protocols that the PE image installed afterwards.

See the tool’s readme, there are more ways to hook into the execution process.

2) GUID DataBase (guiddb): Create C source listing of TianoCore GUIDs.

A few programs that Scan EDK-II .DEC build files for GUIDs, and output them in C-source file format.

(There are about 4 GUID tools by different authors. One of these days, I’ll need to compare the various UEFI GUID tools’s output to see which’re more accurate…)

3) Memory Dump (memdmp): Tools to dump UEFI memory.

First, there’s a patch against UEFI Shell’s “memmap” dump memory command to pipe that to a file called “mdmp”. Then, run “dmp2seg” to convert that output file into many files with the actual memory contents. Then, run “make_elf.rb” to make a single ELF file with all the memory contents. The ELF file is not executable or anything, it’s just a convenient format to store memory segments.

4) Tree (tree): Ruby firmware tree on your filesystem.

A class file that will provides a Ruby tree abstraction for a firmware tree on your filesystem previously extracted by UEFITool’s UEFIExtract tool.

UEFI Reverse is a collection of some specialized UEFI research tools that may help augment your toolbox.

UEFI Reverse-aside, Jethro also has some TPMv2 project as well, that is worth checking out, if you use Linux and are into TPMs…

More Information:

Tianocore web site updated

As reported by the Intel UEFI Twitter feed, the UEFI Forum’s web team have done a complete overhaul to the web site:

There are a few other web pages, not many more; most others are github-hosted web pages now.

This news was found on the Twitter feed of Brian Richardson of Intel, which was not on my previous 0.3 release of Twitter feeds, but will be in next 0.4 release:

On a related note, the edk2-devel mailing list finally moved from SourceForge to

Tutorial on using EDK-II’s Linux emulator

Today Jey Jay (LinuxKernelSeeker) has a blog post on how to use TianoCore with Linux, using the EDK2 emulator.

“This post will explains the steps involved in compiling EmulatorPkg of Tianocore EDK2. Who wish to learn UEFI can use this emulator for writing UEFI samples.” …

It is a good article, some of the Tianocore readmes for Linux are fairly vague (and/or referencing outdated distro releases that’re no longer available), so it is nice to have a tutorial talking about a fresh release, including some screenshots to be even more user-friendly.

More Information:

ARM’s EDK-II maintainer leaves ARM Ltd for

Today, Oliver Martin, the TianoCore EDK2 maintainer for the ARM packages for the last 4 years, is leaving ARM, this is his last week. Oliver didn’t give many details on his new project:

Unfortunately, it is still too early to share more details about my future product, so I created a quick website (and found a neutral name) last week-end to allow people to follow the adventure: (can either be pronounced as “Lab apart” or “Lab à Part”).

Given his background with ARM and UEFI, I’ll be curious to see if this new product is at all related…

As I understand it, Leif Lindholm of ARM will take over as new EDK2 ARM role; he has been co-maintainer for the last few months, is experienced with open source, Linux, and has been working on UEFI for Linaro for the last few years.

More Information:
edk2-devel mailing list archives (Subject: Farewell – last days at ARM Ltd)

Vim syntax highlighting for EDK2 sources

If you use Vim, there are a few projects with syntax highlighting support for TianoCore sources and config files. A recent one, from this year:
Two others from 2013, with different features from above one:

If you use Visual Slick Edit, one firmware engineer at Dell has created some files for EDK-II support:

I found no support found for Emacs, perhaps the FSF anti-UEFI campaign has impacted this? I don’t know of any EDK-II support in any other open source programmer’s editors or IDEs.

Besides highlighting C/assembly sources, EDK2 has 7 different build/config files, much more complex than a single Makefile to deal with. The specs for these files are listed below; it would be nice if you spend time in EDK2 sources, if your editor helps you understand these formats.