[GSoC] Ghidra firmware utilities, week 4

During the previous week, I worked on additional filesystem loaders to support parsing Flash Map (FMAP) images and the coreboot file system (CBFS). As of this week, these FS loaders are mostly complete, and can be used to import raw binaries within compiled coreboot ROMs. Support for CBFS file compression (with either LZMA or LZ4) is also implemented; compressed files will be automatically extracted. Here are some screenshots of the new FS loaders:

While these might not be the most useful FS loaders (as FMAP and CBFS are mainly used by coreboot itself), I gained additional familiarity with Ghidra’s plugin APIs for FS loaders. This will be useful, as I will be writing additional FS loaders for this project.

Plans for next week

I’ll continue to make minor changes to the existing FS loaders (various cleanups/etc). I’ll also start to write a FS loader for parsing ROMs with an Intel firmware descriptor (IFD), which shouldn’t be too complicated. After this is completed, I plan on writing a FS loader for UEFI firmware volumes (ideally similar to UEFITool or uefi-firmware-parser). I anticipate that this loader will be more complex, so I’ve reserved additional time to ensure its completion.

[GSoC] Common Mistakes for Beginners

Hello everyone. I am Asami and a student for this year’s GSoC project. My project is adding a new mainboard QEMU/AArch64 to make it easier for coreboot developers to support new boards for ARMv8. I’ve already written a small patch to enable building a sample program with libpayload for ARM architecture. Also, I’ve read the implementation of coreboot (main code path) for ARMv7 and QEMU (qemu/hw/arm/vexpress.c). Now, I just created a new CL for my main project and I started to read the implementation of the target machine of AArch64 (qemu/hw/arm/virt.c).

In this article, I’m going to talk about my mistakes when I developed coreboot. I hope it helps for beginners of coreboot development. The target board is QEMU/ARM and the CPU is ARMv7.

“ERROR: Ramstage region _postram_cbfs_cache overlapped by: fallback/payload”

I faced this error when I built coreboot.rom for QEMU/ARM with the coreinfo which is a small informational payload for coreboot. The cause is that the coreinfo doesn’t support ARM architecture and then the payload is compiled as a 32-bit x86.

Make sure that your payload is your target architecture. You need to use other executable files instead of the coreinfo when you want to use architectures other than x86. We provide the libpayload which is a small BSD-licensed static library.

The details of the error is:

$ make
...(omitted)....
W: Written area will abut bottom of target region: any unused space will keep its current contents
CBFS fallback/romstage
CBFS fallback/ramstage
CBFS config 
CBFS revision
CBFS fallback/payload
INFO: Performing operation on 'COREBOOT' region...
ERROR: Ramstage region _postram_cbfs_cache overlapped by: fallback/payload
Makefile.inc:1171: recipe for target 'check-ramstage-overlaps' failed
make: *** [check-ramstage-overlaps] Error 1 

“ERROR: undefined reference to ‘_ttb'” and “ERROR: undefined reference to ‘_ettb'”

This errors might happen when you build coreboot.rom by `make` at root directory. In this case, You need to add TTB() at your memleyout.ld.  

TTB is a translation table base address for MMU. TTBR0 and TTBR1 (TTB registers) hold the start point of TTB. We can put TTB anywhere in memory as long as we store the address to TTBR.

According to the “ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition”, the difference between TTBR0 and TTBR1 is:

(B3-1345) When a PL1&0 stage 1 MMU is enabled, TTBR0 is always used. If TTBR1 is also used then:

– TTBR1 is used for the top part of the input address range

– TTBR0 is used for the bottom part of the input address range

https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf

(B4-1724) TTBCR determines which of the Translation Table Base Registers, TTBR0 or TTBR1, defines the base address for a translation table walk required for the stage 1 translation of a memory access from any mode other than Hyp mode.

https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf

TTBR0 is basically used for user processes and TTBR1 is used for kernel. However, Linux kernel only uses TTBR0 to reduce the time of context switch. (I just heard that Linux kernel starts to use TTBR1 because of security reasons such as Meltdown and Spectre.)

In coreboot, mmu_init() sets TTBR registers in arch/arm/armv7/mmu.c.

Fails to build a sample program with libpayload

We provide the libpayload which is a small BSD-licensed static library for coreboot and we also have a sample program to know how to use it. However, you might fail to build a sample program when you select the ARM architecture as a target with the following errors:

/usr/bin/ld: cannot represent machine `arm'

The reason why this problem happens is Makefile in the sample directory is old dated. So I created a CL to update current architectures that coreboot supports.

Please see the Makefile in https://review.coreboot.org/c/coreboot/+/33287

“Payload not loaded”

“Payload not loaded” happens when the load address of a payload is wrong. The load address should be placed in the RAM place where anyone can use. You can define the load address via CONFIG_LP_BASE_ADDRESS if you use a libpayload.

I created a CL for a sample configuration. Please see the config.emulation-qemu-arm in https://review.coreboot.org/c/coreboot/+/33287

Whole operations for building coreboot.rom with a sample payload for QEMU/ARM are:

1. Build a libc and cross compiler environment.

// In coreboot/payloads/libpayload/
$ make distclean // Always needs when switching a mainboard.
$ cp configs/config.emulation-qemu-arm configs/defconfig // Or you can set up it via 'make menuconfig'
$ make defconfig
$ make
$ make install

2. Build a sample payload hello.elf.

// In coreboot/payloads/libpayload/sample
$ make // Make sure that Makefile is updated by https://review.coreboot.org/c/coreboot/+/33287

3. Build coreboot.rom with a sample payload.

// In coreboot/
$ make distclean // Always needs when switching a mainboard.
$ make menuconfig // or make defconfig
  Select payload “payloads/libpayload/sample/hello.elf”
$ make

Make sure to do ‘make distclean’ before switching your board target

‘make distclean’ removes build artifacts and config files. The default archtecture in coreboot is x86, so you need to do ‘make distclean’ when you want to use other architectures.

Fails to update an existing CL on Gerrit 

Gerrit is a code review tool used in coreboot project. I’m familiar with GitHub and I thought the operations of Gerrit are almost the same with the operations of GitHub, but it weren’t.

On GitHub, developers can create a commit for each update. On the other hand, developers using Gerrit need to amend their commit until it will be merged.

Commands to create a new CL are almost the same with the operations of GitHub:

$ git add <target files>
$ git commit -s
$ git push

Commands to update an existing CL are slightly different:

$ git add <target files>
$ git commit --amend --no-edit

Make sure to leave the “Change-Id” line of the commit message as is.

[GSoC] Coreboot Coverity, Week 3

Hello again! This is a continuation of my posts about fixing the Coverity issues in coreboot. This week’s plan was to tackle the 28 issues in northbridge/intel, which turned out to be much easier than I expected, since I’m already done! With that out of the way, I’m going to begin working on northbridge/via and southbridge. For the curious, here is the project timeline for entire summer. (I had wanted to include this in last week’s post, but hadn’t figured out how to do tables in WordPress yet.)

Week Components Issues
May 6 to 10 util 22
May 13 to 17 util, payloads 22
May 20 to 24 arch, drivers 20
May 27 to 31 commonlib, cpu, lib, mainboard 22
June 3 to 7 northbridge/amd 21
June 10 to 14 northbridge/intel 28
June 17 to 21 northbridge/via, southbridge 22
June 24 to 28 soc/intel 21
July 1 to 5 soc/rockchip, soc/nvidia 20
July 15 to 19 soc/misc, vendorcode/cavium 26
July 22 to 26 vendorcode/amd 21
July 29 to Aug 2 vendorcode/amd 21
Aug 5 to 9 vendorcode/amd 20
Aug 12 to 16 vendorcode/amd 20
Aug 19 to 23 vendorcode/amd 20

As you can see, there are a lot of issues in the AMD vendorcode. This consists primarily of AGESA, AMD’s framework for initialization of their 64 bit platforms (somewhat similar to Intel’s FSP). This code is somewhat … dense (someone on IRC described it as a “sea of abstraction”), so I made sure to leave plenty of time for it. As always, you can keep up to date on my current progress on Gerrit.

PS: As an extra bonus, here is a picture of my new BeagleBone Black!

I recently got a ThinkPad T500 to practice installing coreboot on, and I needed some sort of external programmer to flash the SOIC. There are many options available (flashrom has a whole list here), but a single-board computer like this is one of the closest you can get to “plug-and-play.” There are many other popular boards (notably the Raspberry Pi), but the BBB doesn’t require any binary blobs to boot, and is open source hardware too. The only thing I’m waiting for now is an Atheros ath9k wireless card, which runs without any binary firmware. (Hey, if you’re gonna go freedom, you gotta go all the way.)

[GSoC] Ghidra firmware utilities, week 3

Last week, I finalized my work on the PCI option ROM loader, which was the first part described in my initial proposal for this project. This consists of a filesystem loader for hybrid/UEFI option ROMs and a binary loader for x86 option ROMs.

Background information on PCI option ROMs

Option ROMs may contain more than one executable image; for example, a graphics card may have a legacy x86 option ROM for VGA BIOS support as well as a UEFI option ROM to support the UEFI Graphics Output Protocol. x86 option ROMs are raw 16-bit binaries. The entry point is stored as a short JMP instruction in the option ROM header; the BIOS will execute this instruction to jump to the entry point. In contrast, UEFI images contain an UEFI driver, which is a PE32+ binary. This binary can be (and frequently is) compressed with the EFI compression algorithm, which is a combination of Huffman encoding and the LZ77 algorithm.

Filesystem loader

The filesystem loader allows hybrid/UEFI option ROMs to be imported. It also transparently handles the extraction of compressed UEFI executables.

Initially, I attempted to write a Java implementation of the EFI Compression Algorithm for use in the FS loader, but ran into several issues when handling the decompression of certain blocks. I eventually decided to reuse the existing C decompression implementation in EDK2, and wrote a Java Native Interface (JNI) wrapper to call the functions in the C library.

With the FS loader, UEFI drivers in option ROMs can be imported for analysis with Ghidra’s native PE32+ loader.

x86 option ROM binary loader

This loader allows x86 option ROMs to be imported for analysis. Various PCI structures are automatically defined, and the entry function is resolved by decoding the JMP instruction in the option ROM header.

PCI option ROM header data type
PCI data structure data type
Disassembled entry point

Plans for this week

I’ve started to work on filesystem loader for FMAP/CBFS (used by coreboot firmware images). After that, I plan on working on additional FS loaders for Intel flash images (IFD parsing) and UEFI firmware volumes.

As usual, the source code is available in my GitHub repository. Installation and usage instructions are included in the README; feel free to open an issue report if anything goes awry.

[GSoC] Coreboot Coverity, Introduction

Hello everyone! My name is Jacob Garber, and I am a student in this year’s GSoC 2019! My project is on making coreboot Coverity clean. Coverity is a free static-analysis tool for open source projects that searches for common coding mistakes and errors, such as buffer overruns, null pointer dereferences, and integer overflow. Coverity automatically analyzes the coreboot codebase and flags issues it finds, and my job is to classify them into bugs and false-positives and patch them if I can. You can check the Coverity overview for coreboot here, though seeing the issue tracker itself requires registration. At the beginning of the summer, coreboot had over 380 flagged issues, but it’s now down to 303, so we’re making progress! I plan to address 20-30 issues per week depending on the source component, which so far has gone surprisingly well (surprising, in the sense that coming into the summer I knew very little about coreboot or firmware development in general). For the curious, you can see the history and progress of all my changes on Gerrit. My mentors for this project are Patrick Georgi, Martin Roth, and David Hendricks, who have all been extremely helpful in guiding me through the development process, reviewing my patches, and answering my many questions. Thank you all.

Now, fixing Coverity bugs isn’t the only thing I’d like to do this summer. As I said before, I’d like to learn more about coreboot, and what better way to do that than installing it on a laptop! My current laptop is an old 2011 Macbook Air, which is surprisingly close to getting coreboot support (many thanks to Evgeny Zinoviev). However, I am (slightly) hesitant about installing yet-experimental firmware on my one and only development machine, so until then I picked up an old Thinkpad T500 to practice on. This laptop has the advantage of being able to run blob-free, and if in the very unlikely event I end up bricking it, who cares! (I mean, I’ll care, but it was a worthy sacrifice.) I also bought a BeagleBone Black to try out external flashing and was hoping to include a picture today, but the shipping was delayed. You’ll have to wait until next week!

[GSoC] Ghidra firmware utilities, weeks 1-2

Hi everyone. I’m Alex James (theracermaster on IRC) and I’m working on developing modules for Ghidra to assist with firmware reverse engineering as a part of GSoC 2019. Martin Roth and Raul Rangel are my mentors for this project; I would like to thank them for their support thus far.

Ghidra is an open-source software reverse engineering suite developed by the NSA, offering similar functionality to existing tools such as IDA Pro. My GSoC project aims to augment its functionality for firmware RE. This project will consist of three parts: a loader for PCI option ROMs, a loader for firmware images, and various scripts to assist with UEFI binary reverse engineering (importing common types, GUIDs, etc).

The source code for this project is available here.

Week 1

During my first week, I started implementing the filesystem loader for PCI option ROMs. This allows option ROMs (and their enclosed images) to be loaded into Ghidra for analysis. So far, option ROMs containing uncompressed UEFI binaries can be successfully loaded as PE32+ executables in Ghidra. The loader also calculates the entry point address for legacy x86 option ROMs.

Plans for this week

So far this week, I’ve worked on writing a simple JNI wrapper for the reference C implementation of the EFI decompressor from EDK2, and have used this to add support for compressed EFI images to the option ROM FS loader. Additionally, I plan on making further improvements to the option ROM loader for legacy option ROMs; while the entry point address is properly calculated, they still have to be manually imported as a raw binary.

Announcing coreboot 4.9

coreboot 4.9 release notes

The 4.9 release covers commit 532b8d5f25 to commit 7f520c8fe6
There is a pgp signed 4.9 tag in the git repository, and a branch will
be created as needed.

In the little more than 7 months since 4.8.1 we had 175 authors commit 2610 changes to master. The changes were, for the most part, all over the place, touching every part of the repository: chipsets, mainboards, tools, build system, documentation.

In that time we also had 70 authors made their first commit to coreboot: Welcome and to many more!

Finally, a big Thank You to all contributors who helped shape the coreboot project, community and code with their effort, no matter if through development, review, testing, documentation or by helping people asking questions on our venues like IRC or our mailing list.

Clean up

If there’s any topic to give to this release, “clean up” might be the most appropriate: There was lots of effort to bring the codebase into compliance with our coding style, to remove old idioms that we’d like to retire like the overloaded device_t data type, and to let features percolate through the entire tree to bring more uniformity to its parts.

For example, during the coreboot 4.4 cycle, coreboot gained the notion of mainboard variants to avoid duplication of code in rather similar mainboards.

Back then, this feature was developed and used mostly for the benefit of Chrome OS devices, but more recently the code for various Lenovo Thinkpads was deduplicated in the same way.

Another part of cleaning up our tree is improving our tools that help developers follow coding style and avoid mistakes, as well as the infrastructure we have for automated build tests and we’ve seen quite some activity in that space as well.

Documentation

Since the last release we also moved the documentation into the repository. No need for a special wiki account to edit the documentation, and by colocating sources and documentation, it’s easier to keep the latter in sync with the code, too.

This effort is still under way, which is why we still host the old wiki (now read-only) in parallel to the new documentation site that is rendered from coreboot.git’s Documentation/ directory.

Blobs handling

Another big change is in our blobs handling: Given that Intel now provides a reasonably licensed repository with FSP binaries, we were able to mirror it to coreboot.org and integrate it in the build system. This makes it easier to have working images out of the box for devices that depend on Intel’s proprietary init code.

As usual the blobs aren’t part of the coreboot tree and only downloaded with the USE_BLOBS options.

Deprecations

One of the first changes to coreboot after the 4.8 release was to remove boards that didn’t support certain new features and were apparently unmaintained, as discussed in the release notes of coreboot 4.6.

We didn’t follow up on all plans made back then to deprecate boards more aggressively: The board status reporting mechanism is still rather raw and therefore places quite a burden on otherwise sympathetic contributors of build results.

Also, there will be no deprecations after 4.10: Due to its slipping schedule, coreboot 4.9 is released rather late, and as a result 4.10 will only see about 4 months of development. We considered that a rather short timeframe in which to bring old boards up to new standards, and so the next deprecation cycle may be announced with 4.10 to occur after 4.11 is released, in late 2019.

General changes

  • Various code cleanups
  • Removed device_t in favor of struct device* in ramstage code
  • Removed unnecessary include directives
  • Improved adherence to coding style
  • Deduplicated boards by using the variants mechanism
  • Expand use of the postcar stage
  • Add bootblock compression capability: on systems that copy the bootblock from very slow flash to SRAM, allow adding a stub that decompresses the bootblock into SRAM to minimize the amount of flash reads
  • Rename the POWER8 architecture port to PPC64 to reflect that it isn’t limited to POWER8
  • Added support for booting FIT (uImage) payloads on arm64
  • Added SPI flash write protection API
  • Implemented on Winbond
  • Implemented TCPA log for measured boot
  • Implemented GDB support for arm64 architecture in libpayload
  • Dropped support for unmaintained code paths
  • Measured boot support

Added 56 mainboards

  • ASROCK G41C-GS
  • ASROCK G41M-GS
  • ASROCK G41M-S3
  • ASROCK G41M-VS3 R2.0
  • ASROCK H81M-HDS
  • ASUS P5QC
  • ASUS P5QL-PRO
  • ASUS P5Q-PRO
  • ASUS P8H61-M-LX
  • ASUS P8H61-M-PRO
  • CAVIUM CN8100-SFF-EVB
  • FACEBOOK WATSON
  • FOXCONN D41S
  • GIGABYTE GA-H61M-S2PV
  • GOOGLE ALEENA
  • GOOGLE AMPTON
  • GOOGLE ARCADA
  • GOOGLE ASUKA
  • GOOGLE BOBBA
  • GOOGLE BUDDY
  • GOOGLE CAREENA
  • GOOGLE CAROLINE
  • GOOGLE CASTA
  • GOOGLE CAVE
  • GOOGLE DELAN
  • GOOGLE DRAGONEGG
  • GOOGLE FLEEX
  • GOOGLE HATCH
  • GOOGLE KARMA
  • GOOGLE KUKUI
  • GOOGLE LIARA
  • GOOGLE MEEP
  • GOOGLE RAMMUS
  • GOOGLE SARIEN
  • GOOGLE SENTRY
  • HEWLETT PACKARD HP COMPAQ 8200 ELITE SFF PC
  • INTEL COFFEELAKE RVP11
  • INTEL COFFEELAKE RVP8
  • INTEL COFFEELAKE RVPU
  • INTEL DG41WV
  • INTEL ICELAKE RVPU
  • INTEL ICELAKE RVPY
  • INTEL WHISKEYLAKE RVP
  • LENOVO T431S
  • LENOVO THINKCENTRE A58
  • LENOVO W500
  • LENOVO W530
  • OPENCELLULAR ELGON
  • OPENCELLULAR ROTUNDU
  • OPENCELLULAR SUPABRCKV1
  • SIEMENS MC-APL2
  • SIEMENS MC-APL3
  • SIEMENS MC-APL4
  • SIEMENS MC-APL5

Dropped 71 mainboards

  • AAEON PFM-540I REVB
  • AMD DB800
  • AMD DBM690T
  • AMD F2950
  • AMD MAHOGANY
  • AMD NORWICH
  • AMD PISTACHIO
  • AMD SERENGETI-CHEETAH
  • ARTECGROUP DBE61
  • ASROCK 939A785GMH
  • ASUS A8N-E
  • ASUS A8N-SLI
  • ASUS A8V-E DELUXE
  • ASUS A8V-E SE
  • ASUS K8V-X
  • ASUS KFSN4-DRE K8
  • ASUS M2N-E
  • ASUS M2V
  • ASUS M2V MX-SE
  • BACHMANN OT200
  • BCOM WINNETP680
  • BROADCOM BLAST
  • DIGITALLOGIC MSM800SEV
  • GIGABYTE GA-2761GXDK
  • GIGABYTE M57SLI
  • GOOGLE KAHLEE
  • GOOGLE MEOWTH
  • GOOGLE PURIN
  • GOOGLE ROTOR
  • GOOGLE ZOOMBINI
  • HP DL145-G1
  • HP DL145-G3
  • IEI PCISA LX-800 R10
  • IEI PM LX2-800 R10
  • IEI PM LX-800 R11
  • INTEL COUGAR-CANYON2
  • INTEL STARGO2
  • IWILL DK8 HTX
  • JETWAY J7F2
  • JETWAY J7F4K1G2E
  • JETWAY J7F4K1G5D
  • KONTRON KT690
  • LINUTOP LINUTOP1
  • LIPPERT HURRICANE LX
  • LIPPERT LITERUNNER LX
  • LIPPERT ROADRUNNER LX
  • LIPPERT SPACERUNNER LX
  • LOWRISC NEXYS4DDR
  • MSI MS7135
  • MSI MS7260
  • MSI MS9185
  • MSI MS9282
  • NVIDIA L1-2PVV
  • SIEMENS SITEMP-G1P1
  • SUNW ULTRA40
  • SUNW ULTRA40M2
  • SUPERMICRO H8DME
  • SUPERMICRO H8DMR
  • TECHNEXION TIM5690
  • TECHNEXION TIM8690
  • TRAVERSE GEOS
  • TYAN S2912
  • VIA EPIA-CN
  • VIA EPIA-M700
  • VIA PC2500E
  • VIA VT8454C
  • WINENT MB6047
  • WINENT PL6064
  • WINNET G170

CPU changes

  • cpu/intel/model_2065x,206ax,haswell: Switch to POSTCAR_STAGE
  • cpu/intel/slot_1: Switch to different CAR setup
  • Dropped support for the FSP1.0 sandy-/ivy-bridge bootpath

SoC changes

  • Added Cavium CN81xx, Intel Ice Lake and Mediatek MT8183
  • Dropped Broadcom Cygnus, Lowrisc and Marvell mvmap2315

Northbridge changes

  • Dropped AMD K8, VIA CN700, VIA CX700, VIA VX800 because they lack EARLY_CBMEM support
  • intel/e7505: Moved to EARLY_CBMEM
  • nb/intel/i945,e7505,pineview,x4x,gm45,i440bx: Moved to POSTCAR_STAGE
  • nb/intel/i440bx, e7505: Moved to RELOCATABLE_RAMSTAGE
  • intel/x4x: Add DDR3 support
  • nb/intel/pineview: Speed up fetching SPD
  • nb/intel/i945,gm45,x4x,pineview: Use TSEG in SMI

Southbridge changes

  • sb/intel/i82801{g,i,j}x, lynxpoint: Use the common ACPI pirq generator
  • sb/intel/i82801{g,i,j}x: Use common code to set up SMM and for the smihandler
  • Use common functions for PMBASE configuration

Payload changes

  • Support initrd in uImage/FIT to be placed above 4GiB
  • Added documentation for uImage/FIT payloads

Toolchain

  • Update to gcc 8.1.0, binutils 2.30, IASL 20180810, clang 6

Announcing coreboot 4.8 & 4.8.1

coreboot 4.8 was released on May 15, 2018.  An issue with payloads was found immediately after the release was complete, requiring the release of an updated version, 4.8.1.  The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads.html

coreboot 4.8 & 4.8.1 release notes

The 4.8.1 release contains 2 commits: 5f0b80b880 and 6794ce02d4. This minor release fixes an issue with adding payloads. The 4.8 release covers commit 6dd2f69878 to commit ebdeb4d07d Since the last release, the coreboot project had 1198 commits by 124 authors.

There are PGP signed 4.8 and 4.8.1 tags in the git repository. A branch for 4.8 releases (4.8_branch) has been created.

A big thank you to everyone involved in making this release happen. We couldn’t have done this without the 35 new commit authors, the experienced developers, the many reviewers, documentation writers and the fantastic community supporting users on both the mailing list and the IRC channel.

In general, this has been a calm release cycle. Several old devices were removed from the master branch early in the release, as they hinder development and nobody stepped up doing the porting effort or was willing to test coreboot on them. If there is the desire to get a board back, it isn’t lost as it’s still in the git history.

Intel i945 platform

  • On Intel 945 devices, native graphics initialization is now skipped saving around 100 ms during resume from S3. The OS drivers need to be able to handle that. Linux’ i915 driver is able to handle it, but not the frame buffer driver.

AMD Stoney Ridge

  • Significant cleanup from older AGESA based platforms
  • Fixes to get S3 working
  • Updates to GPIO code to match other modern coreboot chips
  • AGESA interface cleanup – Use native coreboot functions when possible

Lenovo mainboards

  • Started integration of VBT (Video Bios Table) binary files to support native graphics initialisation

Internal changes

  • Rename of payload type ‘payload’ to ‘simple_elf’
  • Progress in removing typedef device_t
  • Migrated all Intel platforms to a common VBT codebase
  • Ongoing cleanup of whitespace, spelling and formatting
  • Support for PCI in ramstage on non-x86
  • Ongoing Intel platform code deduplication

Console changes

  • Reduce default loglevel to DEBUG
  • Introduce a way for mainboard to override the loglevel
  • Restrict console messages to after console initialization

Fixed Bugs

  • qemu-i440fx: Fix ACPI checksum corruption
  • intelmetool: Fix crash, support ME11+ platforms, fix bootguard detection
  • tpm: Fix TPM software stack vulnerability in tlcl_read() for TPM 1.2 (https://github.com/nccgroup/TPMGenie)
  • asrock/b75pro3-m: Fixed HDMI
  • Intel/ibexpeak: Fix missing ACPI PIRQ entries
  • Intel/nehalem: Fix freeze during chipset lockdown

Payloads

  • Bumped SeaBIOS to 1.11.1
  • Improved TianoCore integration

Security

  • Start of refactoring the TPM software stack
  • Introduced coreboot security section in kconfig
  • VBoot & TPM code moved into src/security

Intelmetool

  • Add Intel Boot Guard status support

Documentation

Added 17 mainboards

  • Asus MAXIMUS_IV_GENE_Z Intel Sandybridge
  • Google ATLAS Intel Kabylake
  • Google BIP Intel Geminilake
  • Google CHEZA Qualcomm SDM845
  • Google NOCTURNE Intel Kabylake
  • Google OCTOPUS Intel Geminilake
  • Google PHASER Intel Geminilake
  • Google YORP Intel Geminilake
  • HP 8770W Intel Ivybridge
  • HP FOLIO_9470M Intel Ivybridge
  • Intel KBLRVP8 Intel Skylake
  • Lenovo W520 Intel Sandybridge
  • OCP MONOLAKE Intel Broadwell DE
  • OCP WEDGE100S Intel Broadwell DE
  • Purism Librem 15 v2 Intel Broadwell
  • Scaleway TAGADA Intel Denverton
  • SiFive HIFIVE_UNLEASHED SiFive FU540

Removed 39 mainboards

  • Abit BE6_II_V2_0
  • AMD DINAR
  • AMD RUMBA
  • Asus DSBF
  • Asus MEW_AM
  • Asus MEW_VM
  • A-trend ATC_6220
  • A-trend ATC_6240
  • AZZA PT_6IBD
  • Biostar M6TBA
  • Compaq DESKPRO_EN_SFF_P600
  • DMP EX
  • ECS P6IWP_FE
  • Gigabyte GA_6BXC
  • Gigabyte GA_6BXE
  • HP E_VECTRA_P2706T
  • Intel D810E2CB
  • Intel EAGLEHEIGHTS
  • Intel MTARVON
  • Intel TRUXTON
  • Iwave RAINBOW_G6
  • Lanner EM8510
  • Lippert FRONTRUNNER
  • Mitac 6513WU
  • MSI MS_6119
  • MSI MS_6147
  • MSI MS_6156
  • MSI MS_6178
  • NEC POWERMATE_2000
  • Nokia IP530
  • RCA RM4100
  • Soyo SY_6BA_PLUS_III
  • Supermicro H8QGI
  • Supermicro H8SCM
  • Supermicro X7DB8
  • Thomson IP1000
  • Tyan S1846
  • Tyan S8226
  • Wyse S50

Added 2 socs

  • Qualcomm sdm845
  • SiFive fu540

Removed 2 socs

  • DMP vortex86ex
  • Intel sch

Removed 5 processors

  • AMD agesa-family15
  • AMD geode-gx2
  • Intel ep80579
  • Intel model-f0x
  • Intel model-f1x

Statistics

  • Total commits: 1198
  • Average Commits per day: 9.85
  • Total authors: 124
  • New authors: 35
  • Total lines added: 386113
  • Total lines removed: 291201
  • Total lines difference: 94912

UEFI memory mapping

Recently I got into UEFI (TianoCore) development. One of UEFI's properties is that a part of it survives the OS load and remains resident to provide a limited set of firmware services to the OS. Its predecessor, PCBIOS, provided software interrupt services that ran in real-mode - with the effect that every operating system since about 1994 had to switch back to that mode if it wanted to make use of these services. Most didn't, so they simply ignored them and implemented those features by themselves, which was usually faster and more robust, too. Instead of learning the lesson that nobody wants or needs firmware runtime services, UEFI Runtime Services were adapted to that new world: they're regular entry points into protected/long mode code. But these modes allow, or even require, page tables that can change the address under which code or data is found. How could the surviving UEFI code deal with that, not even knowing at which address itself is residing once the OS messed a bit with the memory map? UEFI doesn't walk the current page table. It also doesn't provide a way to convert from logical to physical addresses and back. Instead, the OS can send a partial memory map to UEFI once (and only once!) that must cover all memory regions UEFI claimed as its own (and only those regions!). This must happen before the new memory map is enabled, and UEFI triggers handlers that registered themselves for that event. In these handlers (and only then!) can code request address translations so it can fix up its data structures. Afterwards UEFI patches up all relocations to match the new memory map and returns. From then on, UEFI code can do no further address translation. The expectation is that the OS switches to a page table matching that memory map before next calling into UEFI (or the addresses would be all wrong), and that the UEFI addresses never change again since all later requests to update the memory map will be refused with an error code.

coreboot support in lenovo x1 carbon gen1

A friend gave me the his x1 carbon gen1 some time ago. The x1 carbon is little bit different from other Thinkpad because it's a combination of a Thinkpad and a Ultrabook.
  • It has a Trackpoint (and even Trackpoint buttons).
  • It has soldered memory (only Elpida memory is support atm).
  • It has Full-HD. (missed that on x2xx).
Looking under the hood. The x1 carbon gen1 look very likely as x230. x1 carbon left side x1 carbon right side