| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,170 @@ | ||
| # ASUS A88XM-E | ||
|
|
||
| This page describes how to run coreboot on the [ASUS A88XM-E]. | ||
|
|
||
| ## Technology | ||
|
|
||
| Both "Trinity" and "Richland" FM2 desktop processing units are working, | ||
| the CPU architecture in these CPUs/APUs are [Piledriver], | ||
| and their GPU is [TeraScale 3] (VLIW4-based). | ||
|
|
||
| Kaveri is non-working at the moment (FM2+), | ||
| the CPU architecture in these CPUs/APUs are [Steamroller], | ||
| and their GPU is [Sea Islands] (GCN2-based). | ||
|
|
||
| A10 Richland is recommended for the best performance and working IOMMU. | ||
|
|
||
| ```eval_rst | ||
| +------------------+--------------------------------------------------+ | ||
| | A88XM-E | | | ||
| +------------------+--------------------------------------------------+ | ||
| | DDR voltage IC | Nuvoton 3101S | | ||
| +------------------+--------------------------------------------------+ | ||
| | Network | Realtek RTL8111G | | ||
| +------------------+--------------------------------------------------+ | ||
| | Northbridge | Integrated into CPU with IMC and GPU (APUs only) | | ||
| +------------------+--------------------------------------------------+ | ||
| | Southbridge | Bolton-D4 | | ||
| +------------------+--------------------------------------------------+ | ||
| | Sound IC | Realtek ALC887 | | ||
| +------------------+--------------------------------------------------+ | ||
| | Super I/O | ITE IT8603E | | ||
| +------------------+--------------------------------------------------+ | ||
| | VRM controller | DIGI VRM ASP1206 | | ||
| +------------------+--------------------------------------------------+ | ||
| ``` | ||
|
|
||
| ## Flashing coreboot | ||
|
|
||
| ```eval_rst | ||
| +---------------------+------------+ | ||
| | Type | Value | | ||
| +=====================+============+ | ||
| | Socketed flash | yes | | ||
| +---------------------+------------+ | ||
| | Model | [GD25Q64] | | ||
| +---------------------+------------+ | ||
| | Size | 8 MiB | | ||
| +---------------------+------------+ | ||
| | Package | DIP-8 | | ||
| +---------------------+------------+ | ||
| | Write protection | yes | | ||
| +---------------------+------------+ | ||
| | Dual BIOS feature | no | | ||
| +---------------------+------------+ | ||
| | Internal flashing | yes | | ||
| +---------------------+------------+ | ||
| ``` | ||
|
|
||
| ### Internal programming | ||
|
|
||
| The main SPI flash can be accessed using [flashrom], if the | ||
| AmdSpiRomProtect modules have been deleted in the factory image previously. | ||
|
|
||
| ### External flashing | ||
|
|
||
| Using a PLCC Extractor or any other appropriate tool, carefully remove the | ||
| DIP-8 BIOS chip from its' socket while avoiding the bent pins, if possible. | ||
| To flash it, use a [flashrom]-supported USB CH341A programmer - preferably with a | ||
| green PCB - and double check that it's giving a 3.3V voltage on the socket pins. | ||
|
|
||
| ## Integrated graphics | ||
|
|
||
| ### Retrieve the VGA optionrom ("Retrieval via Linux kernel" method) | ||
|
|
||
| Make sure a proprietary UEFI is flashed and boot Linux with iomem=relaxed flag. | ||
| Some Linux drivers (e.g. radeon for AMD) make option ROMs like the video blob | ||
| available to user space via sysfs. To use that to get the blob you need to | ||
| enable it first. To that end you need to determine the path within /sys | ||
| corresponding to your graphics chip. It looks like this: | ||
|
|
||
| # /sys/devices/pci<domain>:<bus>/<domain>:<bus>:<slot>.<function>/rom. | ||
|
|
||
| You can get the respective information with lspci, for example: | ||
|
|
||
| # lspci -tv | ||
| # -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex | ||
| # +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8210] | ||
| # ... | ||
|
|
||
| Here the the needed bits (for the ROM of the Kabini device) are: | ||
|
|
||
| # PCI domain: (almost always) 0000 | ||
| # PCI bus: (also very commonly) 00 | ||
| # PCI slot: 01 (logical slot; different from any physical slots) | ||
| # PCI function: 0 (a PCI device might have multiple functions... shouldn't matter here) | ||
|
|
||
| To enable reading of the ROM you need to write 1 to the respective file, e.g.: | ||
|
|
||
| # echo 1 > /sys/devices/pci0000:00/0000:00:01.0/rom | ||
|
|
||
| The same file should then contain the video blob and it should be possible to simply copy it, e.g.: | ||
|
|
||
| # cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin | ||
|
|
||
| romheaders should print reasonable output for this file. | ||
|
|
||
| This version is usable for all the GPUs. | ||
| 1002,9901 Trinity (Radeon HD 7660D) | ||
| 1002,9904 Trinity (Radeon HD 7560D) | ||
| 1002,990c Richland (Radeon HD 8670D) | ||
| 1002,990e Richland (Radeon HD 8570D) | ||
| 1002,9991 Trinity (Radeon HD 7540D) | ||
| 1002,9993 Trinity (Radeon HD 7480D) | ||
| 1002,9996 Richland (Radeon HD 8470D) | ||
| 1002,9998 Richland (Radeon HD 8370D) | ||
| 1002,999d Richland (Radeon HD 8550D) | ||
| 1002,130f Kaveri (Radeon R7) | ||
|
|
||
| ## Known issues | ||
|
|
||
| - AHCI hot-plug | ||
| - S3 resume (sometimes) | ||
| - Windows 7 can't boot because of the incomplete ACPI implementation | ||
| - XHCI | ||
|
|
||
| ### XHCI ports can break after using any of the blobs, restarting the | ||
| board with factory image makes it work again as fallback. | ||
| Tested even with/without the Bolton and Hudson blobs. | ||
|
|
||
| ## Untested | ||
|
|
||
| - audio over HDMI | ||
|
|
||
| ## TODOs | ||
|
|
||
| - one ATOMBIOS module for all the integrated GPUs | ||
| - manage to work with Kaveri/Godavary (they are using a binaryPI) | ||
| - IRQ routing is done incorrect way - common problem of fam15h boards | ||
|
|
||
| ## Working | ||
|
|
||
| - ACPI | ||
| - CPU frequency scaling | ||
| - flashrom under coreboot | ||
| - Gigabit Ethernet | ||
| - Hardware monitoring | ||
| - Integrated graphics | ||
| - KVM virtualization | ||
| - Onboard audio | ||
| - PCI | ||
| - PCIe | ||
| - PS/2 keyboard mouse (during payload, bootloader) | ||
| - SATA | ||
| - Serial port | ||
| - SuperIO based fan control | ||
| - USB (disabling XHCI controller makes to work as fallback USB2.0 ports) | ||
| - IOMMU | ||
|
|
||
| ## Extra resources | ||
|
|
||
| - [Board manual] | ||
|
|
||
| [ASUS A88XM-E]: https://www.asus.com/Motherboards/A88XME/ | ||
| [Board manual]: https://dlcdnets.asus.com/pub/ASUS/mb/SocketFM2/A88XM-E/E9125_A88XM-E.pdf | ||
| [flashrom]: https://flashrom.org/Flashrom | ||
| [GD25Q64]: http://www.elm-tech.com/ja/products/spi-flash-memory/gd25q64/gd25q64.pdf | ||
| [Piledriver]: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29#APU_lines | ||
| [Sea Islands]: https://en.wikipedia.org/wiki/Graphics_Core_Next#GCN_2nd_generation | ||
| [Steamroller]: https://en.wikipedia.org/wiki/Steamroller_(microarchitecture) | ||
| [TeraScale 3]: https://en.wikipedia.org/wiki/TeraScale_%28microarchitecture%29#TeraScale_3 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| # qemu i440fx mainboard | ||
|
|
||
| ## Running coreboot in qemu | ||
| Emulators like qemu don't need a firmware to do hardware init. | ||
| The hardware starts in the configured state already. | ||
|
|
||
| The coreboot port allows to test non mainboard specific code. | ||
| As you can easily attach a debugger, it's a good target for | ||
| experimental code. | ||
|
|
||
| ## coreboot x86_64 support | ||
| coreboot historically runs in 32-bit protected mode, even though the | ||
| processor supports x86_64 instructions (long mode). | ||
|
|
||
| The qemu-i440fx mainboard has been ported to x86_64 and will serve as | ||
| reference platform to enable additional platforms. | ||
|
|
||
| To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``. | ||
|
|
||
| ## Installing qemu | ||
|
|
||
| On debian you can install qemu by running: | ||
| ```bash | ||
| $ sudo apt-get install qemu | ||
| ``` | ||
|
|
||
| On redhat you can install qemu by running: | ||
| ```bash | ||
| $ sudo dnf install qemu | ||
| ``` | ||
|
|
||
| ## Running coreboot | ||
|
|
||
| ### To run the i386 version of coreboot (default) | ||
| Running on qemu-system-i386 will require a 32 bit operating system. | ||
|
|
||
| ```bash | ||
| qemu-system-i386 -bios build/coreboot.rom -serial stdio -M pc | ||
| ``` | ||
|
|
||
| ### To run the experimental x86_64 version of coreboot | ||
| Running on qemu-system-x86_64 allows to run a 32 bit or 64 bit operating system, | ||
| as well as firmware. | ||
|
|
||
| ```bash | ||
| qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc | ||
| ``` | ||
|
|
||
| ## Finding bugs | ||
| To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM. | ||
| It will not only run faster, but is closer to real hardware. If you see the | ||
| following message: | ||
|
|
||
| KVM internal error. Suberror: 1 | ||
| emulation failure | ||
|
|
||
| something went wrong. The same bug will likely cause a FAULT on real hardware, | ||
| too. | ||
|
|
||
| To enable KVM run: | ||
|
|
||
| ```bash | ||
| qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc -accel kvm -cpu host | ||
| ``` |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,64 @@ | ||
| # qemu q35 mainboard | ||
|
|
||
| ## Running coreboot in qemu | ||
| Emulators like qemu don't need a firmware to do hardware init. | ||
| The hardware starts in the configured state already. | ||
|
|
||
| The coreboot port allows to test non mainboard specific code. | ||
| As you can easily attach a debugger, it's a good target for | ||
| experimental code. | ||
|
|
||
| ## coreboot x86_64 support | ||
| coreboot historically runs in 32-bit protected mode, even though the | ||
| processor supports x86_64 instructions (long mode). | ||
|
|
||
| The qemu-q35 mainboard has been ported to x86_64 and will serve as | ||
| reference platform to enable additional platforms. | ||
|
|
||
| To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``. | ||
|
|
||
| ## Installing qemu | ||
|
|
||
| On debian you can install qemu by running: | ||
| ```bash | ||
| $ sudo apt-get install qemu | ||
| ``` | ||
|
|
||
| On redhat you can install qemu by running: | ||
| ```bash | ||
| $ sudo dnf install qemu | ||
| ``` | ||
|
|
||
| ## Running coreboot | ||
| ### To run the i386 version of coreboot (default) | ||
| Running on qemu-system-i386 will require a 32 bit operating system. | ||
|
|
||
| ```bash | ||
| qemu-system-i386 -bios build/coreboot.rom -serial stdio -M q35 | ||
| ``` | ||
|
|
||
| ### To run the experimental x86_64 version of coreboot | ||
| Running on `qemu-system-x86_64` allows to run a 32 bit or 64 bit operating system | ||
| and firmware. | ||
|
|
||
| ```bash | ||
| qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35 | ||
| ``` | ||
|
|
||
| ## Finding bugs | ||
| To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM. | ||
| It will not only run faster, but is closer to real hardware. If you see the | ||
| following message: | ||
|
|
||
| KVM internal error. Suberror: 1 | ||
| emulation failure | ||
|
|
||
| something went wrong. The same bug will likely cause a FAULT on real hardware, | ||
| too. | ||
|
|
||
| To enable KVM run: | ||
|
|
||
| ```bash | ||
| qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35 -accel kvm -cpu host | ||
| ``` | ||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| # HP EliteBook 2560p | ||
|
|
||
| This page is about the notebook [HP EliteBook 2560p]. | ||
|
|
||
| ## Release status | ||
|
|
||
| HP EliteBook 2560p was released in 2011 and is now end of life. | ||
| It can be bought from a secondhand market like Taobao or eBay. | ||
|
|
||
| ## Required proprietary blobs | ||
|
|
||
| The following blobs are required to operate the hardware: | ||
| 1. EC firmware | ||
| 2. Intel ME firmware | ||
|
|
||
| EC firmware can be retrieved from the HP firmware update image, or the firmware | ||
| backup of the laptop. EC Firmware is part of the coreboot build process. | ||
| The guide on extracting EC firmware and using it to build coreboot is in | ||
| document [HP Laptops with KBC1126 Embedded Controller](hp_kbc1126_laptops). | ||
|
|
||
| Intel ME firmware is in the flash chip. It is not needed when building coreboot. | ||
|
|
||
| ## Programming | ||
|
|
||
| The flash chip is located between the memory slots and the PCH, | ||
| covered by the base enclosure, which needs to be removed according to | ||
| the [Maintenance and Service Guide] to access the flash chip. An SPI | ||
| flash programmer using 3.3V voltage such as a ch341a programmer, and | ||
| an SOIC-8 clip can be used to read and flash the chip in-circuit. | ||
|
|
||
| Pin 1 of the flash chip is at the side near the PCH. | ||
|
|
||
|  | ||
|
|
||
| For more details have a look at the general [flashing tutorial]. | ||
|
|
||
| ## Debugging | ||
|
|
||
| The board can be debugged with EHCI debug. The EHCI debug port is the back | ||
| bottom USB port. | ||
|
|
||
| Schematic of this laptop can be found on [Lab One]. | ||
|
|
||
| ## Test status | ||
|
|
||
| ### Known issues | ||
|
|
||
| - GRUB payload freezes if at_keyboard module is in the GRUB image | ||
| ([bug #141]) | ||
|
|
||
| ### Untested | ||
|
|
||
| - Optical Drive | ||
| - VGA | ||
| - Fingerprint Reader | ||
| - Modem | ||
|
|
||
| ### Working | ||
|
|
||
| - Integrated graphics init with libgfxinit | ||
| - SATA | ||
| - Audio: speaker and microphone | ||
| - Ethernet | ||
| - WLAN | ||
| - WWAN | ||
| - Bluetooth | ||
| - ExpressCard | ||
| - SD Card Reader | ||
| - SmartCard Reader | ||
| - eSATA | ||
| - USB | ||
| - DisplayPort | ||
| - Keyboard, touchpad and trackpoint | ||
| - EC ACPI support and thermal control | ||
| - Dock: all USB ports, DisplayPort, eSATA | ||
| - TPM | ||
| - Internal flashing when IFD is unlocked | ||
| - Using `me_cleaner` | ||
|
|
||
|
|
||
| ## Technology | ||
|
|
||
| ```eval_rst | ||
| +------------------+--------------------------------------------------+ | ||
| | CPU | Intel Sandy/Ivy Bridge (FCPGA988) | | ||
| +------------------+--------------------------------------------------+ | ||
| | PCH | Intel Cougar Point QM67 | | ||
| +------------------+--------------------------------------------------+ | ||
| | EC | SMSC KBC1126 | | ||
| +------------------+--------------------------------------------------+ | ||
| | Coprocessor | Intel Management Engine | | ||
| +------------------+--------------------------------------------------+ | ||
| ``` | ||
|
|
||
| [HP EliteBook 2560p]: https://support.hp.com/us-en/product/hp-elitebook-2560p-notebook-pc/5071201 | ||
| [Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c03011618 | ||
| [flashing tutorial]: ../../flash_tutorial/ext_power.md | ||
| [Lab One]: https://www.laboneinside.com/hp-elitebook-2560p-schematic-diagram/ | ||
| [bug #141]: https://ticket.coreboot.org/issues/141 |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,122 @@ | ||
| # Purism Librem Mini | ||
|
|
||
| This page describes how to run coreboot on the [Purism Librem Mini]. | ||
|
|
||
| ```eval_rst | ||
| +------------------+--------------------------------------------------+ | ||
| | CPU | Intel Core i7-8565U | | ||
| +------------------+--------------------------------------------------+ | ||
| | PCH | Whiskey Lake / Cannon Point LP | | ||
| +------------------+--------------------------------------------------+ | ||
| | Super I/O, EC | ITE IT8528E | | ||
| +------------------+--------------------------------------------------+ | ||
| | Coprocessor | Intel Management Engine (CSME 12.x) | | ||
| +------------------+--------------------------------------------------+ | ||
| ``` | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ## Required proprietary blobs | ||
|
|
||
| To build a minimal working coreboot image some blobs are required (assuming | ||
| only the BIOS region is being modified). | ||
|
|
||
| ```eval_rst | ||
| +-----------------+---------------------------------+---------------------+ | ||
| | Binary file | Apply | Required / Optional | | ||
| +=================+=================================+=====================+ | ||
| | FSP-M, FSP-S | Intel Firmware Support Package | Required | | ||
| +-----------------+---------------------------------+---------------------+ | ||
| | microcode | CPU microcode | Required | | ||
| +-----------------+---------------------------------+---------------------+ | ||
| | vgabios | VGA Option ROM | Optional | | ||
| +-----------------+---------------------------------+---------------------+ | ||
| ``` | ||
|
|
||
| FSP-M and FSP-S are obtained after splitting the Coffee Lake FSP binary (done | ||
| automatically by the coreboot build system and included into the image) from | ||
| the `3rdparty/fsp` submodule. | ||
|
|
||
| Microcode updates are automatically included into the coreboot image by the build | ||
| system from the `3rdparty/intel-microcode` submodule. Official Purism release | ||
| images may include newer microcode, which is instead pulled from Purism's | ||
| [purism-blobs] repository. | ||
|
|
||
| VGA Option ROM is not required to boot, but if one needs graphics in pre-OS | ||
| stage, it should be included (if not using FSP/GOP display init). It can | ||
| be extracted via cbfstool from the existing board firmware or pulled from | ||
| the [purism-blobs] repository. | ||
|
|
||
| ## Intel Management Engine | ||
|
|
||
| The Librem Mini uses version 12.x of the Intel Management Engine (ME) / | ||
| Converged Security Engine (CSE). The ME/CSE is disabled using the High | ||
| Assurance Platform (HAP) bit, which puts the ME into a disabled state | ||
| after platform bring-up (BUP) and disables all PCI/HECI interfaces. | ||
| This can be verified via the coreboot cbmem utility: | ||
| `sudo ./cbmem -1 | grep 'ME:'` | ||
| provided coreboot has been modified to output the ME status even when | ||
| the PCI device is not visible/active (as it is in Purism's release builds). | ||
|
|
||
| ## Flashing coreboot | ||
|
|
||
| ### Internal programming | ||
|
|
||
| The main SPI flash can be accessed using [flashrom]. The first version | ||
| supporting the chipset is flashrom v1.2. Firmware an be easily flashed | ||
| with internal programmer (either BIOS region or full image). | ||
|
|
||
| ### External programming | ||
|
|
||
| The system has an internal flash chip which is a 8 MiB soldered SOIC-8 chip, | ||
| and has a diode attached to the VCC line for in-system programming. | ||
| This chip is located on the bottom side of the board under the CPU heatsink, | ||
| in line with the front USB 2.0 ports. | ||
|
|
||
| One has to remove all screws (in order): | ||
|
|
||
| * 2 top cover screws | ||
| * 4 screws securing the mainboard to the chassis | ||
| * 4 screws securing the heatsink/fan assembly to the mainboard (under the SODIMMs) | ||
|
|
||
| The m.2 SSD will need to be removed if the Wi-Fi antenna are connected to | ||
| an internal Wi-Fi/BT module. Use a SOIC-8 chip clip to program the chip. | ||
| Specifically, it's a Winbond W25Q128JV (3.3V) - [datasheet][W25Q128JV]. | ||
|
|
||
| The EC firmware is stored on a separate SOIC-8 chip (a Winbond W25Q80DV), | ||
| but is not protected by a diode and therefore cannot be read/written to without | ||
| desoldering it from the mainboard. | ||
|
|
||
| ## Known issues | ||
|
|
||
| * SeaBIOS can be finicky with detecting USB devices | ||
| * Booting can sometimes hang when a bootsplash image is used with SeaBIOS | ||
| and VGA option ROM display init, related to display mode changing | ||
| * Issues with some SATA devices have been mitigated by limiting the SATA speed to 3Gbps | ||
| until the correct HSIO PHY settings can be determined. | ||
|
|
||
| ## Working | ||
|
|
||
| * External displays via HDMI/DislpayPort with VGA option ROM or FSP/GOP init | ||
| (no libgfxinit support yet) | ||
| * SeaBIOS (1.13.x), Tianocore (CorebootPayloadpkg), Heads (Purism downstream) payloads | ||
| * Ethernet, m.2 2230 Wi-Fi | ||
| * System firmware updates via flashrom | ||
| * PCIe NVMe | ||
| * m.2 and SATA III | ||
| * Audio via front 3.5mm jack, HDMI, and DisplayPort | ||
| * SMBus (reading SPD from DIMMs) | ||
| * Initialization with CFL FSP 2.0 | ||
| * S3 Suspend/Resume | ||
| * Booting PureOS 9.x, Debian 10.x, Qubes 4.0.3, Linux Mint 19.3, Windows 10 2004 | ||
|
|
||
| ## Not working / untested | ||
|
|
||
| * ITE IT8528E Super IO functions | ||
|
|
||
|
|
||
| [Purism Librem Mini]: https://puri.sm/products/librem-mini/ | ||
| [purism-blobs]: https://source.puri.sm/coreboot/purism-blobs | ||
| [W25Q128JV]: https://www.winbond.com/resource-files/w25q128jv%20revf%2003272018%20plus.pdf | ||
| [flashrom]: https://flashrom.org/Flashrom |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,127 @@ | ||
| CSE FW update mechanism for devices in field | ||
|
|
||
| ## Introduction | ||
|
|
||
| CSE Firmware and PMC Firmware are critical components of Intel SoCs. | ||
| CSE and PMC cooperate by providing platform services during boot and other | ||
| power transition flows. | ||
|
|
||
| ## Problem Statement | ||
|
|
||
| Currently, on Chromium OS Systems, CSE region is not updatable. So, new CSE FW | ||
| versions that are released by Intel to address important functional and security | ||
| bugs post-product launch will not be available to the end-user. Hence, the proposed | ||
| solution allows in-field CSE FW update to propagate those bug fixes | ||
| to end user platforms. | ||
|
|
||
| ## Design Proposal | ||
|
|
||
| ### CSE FW design Proposal: | ||
|
|
||
| Key Elements: | ||
|
|
||
| - CSE FW layout is composed of two bootable partitions (RO Recovery Partition | ||
| and RW Normal Partition). | ||
|
|
||
| - Boot partition selection: An API-based mechanism is used to decide from which partition | ||
| CSE will boot. | ||
|
|
||
| - The HECI APIs below will be supported in this CSE FW: | ||
|
|
||
| - HMRFPO_ENABLE: This command requests the CSE enter a mode in which writes to | ||
| the CSE region from the CSE are disabled. It also grants temporary write access | ||
| to the RW partition from the host (RO is still protected by GPR0). | ||
|
|
||
| - GET_PARTITION_INFO: The command retrieves information for each boot partition from CSE | ||
| like version, start/end offsets of a partition within CSE region, and boot | ||
| partition status. Also, it provides below information: | ||
| - The current boot partition which was used during this boot, | ||
| - The boot partition that will be used on the next CSE reset | ||
| - The number of boot partitions available in the CSE region | ||
|
|
||
| - SET_BOOT_PARTITION_INFO: This command allows the firmware to request the | ||
| CSE to boot from either its RO or RW partition at its next reset. | ||
|
|
||
| - DATA_CLEAR: This command requests the CSE to reset its data partition back | ||
| to manufacturing defaults | ||
|
|
||
| FW Layout, RW/RO Partitions: | ||
|
|
||
| The CSE RO partition is the first in the CSE boot order, hence it will be used | ||
| out of G3. RO partition contains minimum CSE code capable to boot platform and | ||
| execute FW update of RW partition. In addition to CSE code, the RO partition also | ||
| contains PMC FW patch and other CSE-loadable platform FW components. | ||
|
|
||
| RW partition contains fully operational CSE FW, PMC FW, other CSE loadable | ||
| platform FW components. | ||
|
|
||
| Boot partition selection: | ||
|
|
||
| CSE FW shall support 2 APIs to get boot partition info, and set boot partition | ||
| info to notify CSE to select the partition on the next boot. | ||
|
|
||
| ### HOST FW Design proposal: | ||
|
|
||
| Key Elements: | ||
|
|
||
| - Build time artifacts: | ||
|
|
||
| CSE RW Version update binary - The FW shall pack CSE RW update blob and | ||
| corresponding version binary which contains version of the CSE RW blob. | ||
|
|
||
| - FW Update: | ||
|
|
||
| coreboot will implement the logic to compare the CSE's FW version with CBFS | ||
| CSE RW binary's version in the firmware slot (FW_MAIN_A/FW_MAIN_B) and update | ||
| the CSE RW region if there is a version mismatch. If there is no version | ||
| mismatch, firmware skips CSE FW update. | ||
|
|
||
| - Handling of CSE FW Downgrade: | ||
|
|
||
| coreboot will send DATA_CLEAR HECI command when there is a CSE FW downgrade. | ||
| This must be done to avoid data mismatch due to CSE FW downgrade. Further, | ||
| CSE will restore the data back to manufacturing defaults after data reset. | ||
|
|
||
|
|
||
| ## Implementation Details | ||
|
|
||
|
|
||
| To enable CSE FW update flow the following changes are required in coreboot: | ||
|
|
||
| * Descriptor change may be required to accommodate CSE binary. The CSE binary is tied with | ||
| a platform. So CSE size may vary from one platform to another. | ||
| * FMAP changes may be required to accommodate CSE binary and CSE RW blob in the RW CBFS region. | ||
| Please check platform specific CSE kit for CSE binary information. | ||
| * CSE Lite SKU binary and CSE RW blob | ||
| * Makefile change to pack CSE RW binaries in the CBFS | ||
| * Implementation of update flow: | ||
| - Get CSE boot partition info using GET_BOOT_PARTITION_INFO HECI command. | ||
| - Get the cbfs_me_rw.version from the currently selected RW slot. | ||
| - If the version from the above 2 locations don't match, then start CSE FW update. | ||
| - If CSE is not booting from RO, then | ||
| - Set the CSE's next boot partition to RO using SET_BOOT_PARTITION_INFO | ||
| HECI command. | ||
| - Send GLOBAL_RESET HECI command to reset the system. | ||
| - If RW update is a CSE FW downgrade, then coreboot has to send | ||
| DATA_CLEAR command to clear run time data of CSE. | ||
| - Enable HMRFPO Mode (Host ME Region Flash Protection Override) by | ||
| sending HMRFPO_ENABLE HECI command to CSE. | ||
| - Erase and Copy the CBFS CSE RW to CSE RW partition | ||
| - Set CSE's next boot partition to RW. | ||
| - Trigger Global Reset which resets both CSE and Host. | ||
| Then system should boot with the updated CSE. | ||
|
|
||
| * The resulting flash layout is shown below: | ||
|
|
||
|   | ||
|
|
||
|
|
||
| - Typical boot flow | ||
|
|
||
| - Vboot selects the RW FW (FW_MAIN_A or FW_MAIN_B) to boot. | ||
| - coreboot skips CSE FW update flow if boot mode is recovery. | ||
| - If CSE RW blob is not locatable in the CBFS, then RW Firmware skips update flow | ||
| and sends SET_BOOT_PARTITION_INFO command to switch CSE to boot from RW | ||
| and issues Global Reset if CSE is already not booting from RW partition. | ||
| - The RW firmware will compare the CSE RW version with CSE RW blob in the slot. | ||
| - If there is a mismatch, then firmware will carry out update flow as explained before. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,136 @@ | ||
| # Microcode updates | ||
|
|
||
| When booting a modern x86 platform, one task of the firmware is to update | ||
| [microcode] to correct hardware bugs and mitigate security issues found | ||
| after silicon has been shipped. The [Pentium FDIV bug] could have been | ||
| fixed with a microcode update, had the Pentium used updateable microcode. | ||
| Starting with the Pentium Pro, CPU microcode can be updated by software. | ||
|
|
||
| As per BIOS Writer's Guides, Intel defines a processor as the silicon and | ||
| the accompanying microcode update, and considers any processor that does | ||
| not have its microcode updated to be running out of specification. This | ||
| suggests that microcode is a crucial ingredient for correct operation. | ||
|
|
||
| On multi-processor or Hyper-Threading-enabled systems, each thread has | ||
| its own microcode. Therefore, microcode must be updated on every thread. | ||
|
|
||
| ## When to update microcode | ||
|
|
||
| When a CPU core comes out of reset, it uses microcode from an internal | ||
| ROM. This “default” microcode often contains bugs, so it needs to be | ||
| updated as soon as possible. For example, Core 2 CPUs can boot without | ||
| microcode updates, but have stability problems. On newer platforms, | ||
| it is nearly impossible to boot without having updated the microcode. | ||
| On some platforms, an updated microcode is required in order to enable | ||
| Cache-As-RAM or to be able to successfully initialize the DRAM. | ||
|
|
||
| Plus, microcode needs to be loaded multiple times. Intel Document 504790 | ||
| explains that this is because of so-called *enhanced microcode updates*, | ||
| which are large updates with errata workarounds for both core and uncore. | ||
| In order to correctly apply enhanced microcode updates, the [MP-Init] | ||
| algorithm must be decomposed into multiple initialization phases. | ||
|
|
||
| ### Firmware Interface Table | ||
|
|
||
| Beginning with 4th generation Intel Core processors, it is possible for | ||
| microcode to be updated before the CPU is taken out of reset. This is | ||
| accomplished by means of [FIT], a data structure which contains pointers | ||
| to various firmware ingredients in the BIOS flash. | ||
|
|
||
| In rare cases, FIT microcode updates may not be successful. Therefore, | ||
| it is important to check that the microcode is up-to-date and, if not, | ||
| update it. This needs to be done as early as possible, like on older | ||
| processor generations without FIT support. | ||
|
|
||
| Whether all threads on a processor get their microcode updated through | ||
| FIT is not clear. According to Intel Documents 493770 and 535094, FIT | ||
| microcode updates are applied to all cores within the package. However, | ||
| Intel Document 550049 states that FIT microcode updates are applied to | ||
| all threads within the package. | ||
|
|
||
| ## SMM bring-up | ||
|
|
||
| Prior to SMM relocation, microcode must have been updated at least once. | ||
|
|
||
| ## Multi-Processor bring-up | ||
|
|
||
| The BWG briefly describes microcode updates as part of the *MP-Init*. | ||
|
|
||
| ### MP-Init | ||
|
|
||
| As part of the [MP-Init] sequence, two microcode updates are required. | ||
|
|
||
| * The first update must happen as soon as one AP comes out of reset. | ||
| * The second update must happen after the MP-Init sequence has written MTRRs, | ||
| PRMRR, DCU mode and prefetcher configuration, SMM has been relocated, but | ||
| before clearing the MCE banks. | ||
|
|
||
| ## Recommendations | ||
|
|
||
| The Linux kernel developer's recommendations are: | ||
| * Serialize microcode updates if possible. | ||
| * Idle as many APs as possible while updating. | ||
| * Idle the sibling thread on a Hyper-Threading enabled CPU while updating. | ||
|
|
||
| ## Platform BWGs | ||
|
|
||
| The requirements specified in BWGs differ between platforms: | ||
|
|
||
| ### Sandy Bridge | ||
|
|
||
| * Before setting up Cache-As-RAM, load microcode update into the SBSP. | ||
| * Losing (non-SBSP) NBSPs must load their microcode update before being placed | ||
| back in the wait-for-SIPI state. | ||
| * Sibling threads on HT must use a semaphore. | ||
| * Microcode update loading has been done prior to SMM relocation. | ||
| * In MP-Init the microcode update on an AP must be done before initializing the | ||
| cache, MTRRs, SMRRs and PRMRRs. | ||
| * In MP-Init a second update must happen on all threads after initializing the | ||
| cache, MTRRs, SMRRs and PRMRRs. | ||
|
|
||
| Refer to Intel Document 504790 for details. | ||
|
|
||
| ### Haswell/Broadwell Client | ||
|
|
||
| * A microcode update must exist in FIT. | ||
| * During the race to the BSP semaphore, each NBSP must load its microcode update. | ||
| * All HT enabled threads can load microcode in parallel. However, the | ||
| IA32_BIOS_UPDT_TRIG MSR is core-scoped, just like on other platforms. | ||
| * Microcode update loading has been done prior to SMM relocation. | ||
| * In MP-Init the microcode update on an AP must be done before initializing the | ||
| cache, MTRRs, SMRRs and EMRR. | ||
| * In MP-Init a second update must happen on all threads after initializing the | ||
| cache, MTRRs, SMRRs and EMRR and after SMM initialization. | ||
|
|
||
| Refer to Intel Document 493770 and 535094 for details. | ||
|
|
||
| ### Broadwell Server | ||
|
|
||
| * A microcode update must exist in FIT. | ||
| * Before setting up Cache-As-RAM, load microcode update into each BSP. | ||
| * In MP-Init the microcode update on an AP must be done before initializing the | ||
| cache, MTRRs, SMRRs and EMRR. | ||
| * In MP-Init a second update must happen on all threads after initializing the | ||
| cache, MTRRs, SMRRs and EMRR and after SMM initialization. | ||
|
|
||
| Refer to Intel Document 546625 for details. | ||
|
|
||
| ### Skylake/Kaby Lake/Coffee Lake/Whiskey Lake/Comet Lake | ||
|
|
||
| * A microcode update must exist in FIT. | ||
| * Before setting up Cache-As-RAM, load microcode update into the BSP. | ||
| * Microcode update loading has been done prior to SMM relocation. | ||
| * In MP-Init the first update must happen as soon as one AP comes out of reset. | ||
| * In MP-Init the second update must happen after the MP-Init sequence has | ||
| written MTRRs, PRMRR, DCU mode and prefetcher configuration, but before | ||
| clearing the MCE banks. | ||
| * Microcode updates must happen on all threads. | ||
| * Sibling threads on HT should use a semaphore. | ||
|
|
||
| Refer to Intel Document 550049 for details. | ||
|
|
||
| [microcode]: https://en.wikipedia.org/wiki/Microcode | ||
| [Pentium FDIV bug]: https://en.wikipedia.org/wiki/Pentium_FDIV_bug | ||
| [FIT]: fit.md | ||
| [SDM]: https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf | ||
| [MP-Init]: mp_init/mp_init.md |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| # Not meant for actual use. Exercises, among other things: | ||
| # + Code coverage | ||
| # + UBSAN | ||
| # + Debug options | ||
| # + SMMSTORE | ||
| # + Silicon Image SIL3114 driver | ||
| # + Genesys Logic GL9763E driver | ||
| # + EM100 support | ||
| CONFIG_COVERAGE=y | ||
| CONFIG_UBSAN=y | ||
| CONFIG_VENDOR_ASROCK=y | ||
| CONFIG_ONBOARD_VGA_IS_PRIMARY=y | ||
| CONFIG_CBFS_SIZE=0x200000 | ||
| CONFIG_BOARD_ASROCK_B85M_PRO4=y | ||
| CONFIG_PCIEXP_L1_SUB_STATE=y | ||
| CONFIG_PCIEXP_CLK_PM=y | ||
| CONFIG_CONSOLE_POST=y | ||
| # CONFIG_INTEL_CHIPSET_LOCKDOWN is not set | ||
| # CONFIG_FINALIZE_USB_ROUTE_XHCI is not set | ||
| CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y | ||
| CONFIG_PCIEXP_HOTPLUG=y | ||
| CONFIG_SMMSTORE=y | ||
| CONFIG_SMMSTORE_SIZE=0x30000 | ||
| CONFIG_SPI_FLASH_NO_FAST_READ=y | ||
| CONFIG_USBDEBUG=y | ||
| CONFIG_USBDEBUG_DONGLE_FTDI_FT232H=y | ||
| CONFIG_DRIVERS_SIL_3114=y | ||
| CONFIG_DRIVERS_GENESYSLOGIC_GL9763E=y | ||
| # CONFIG_SQUELCH_EARLY_SMP is not set | ||
| CONFIG_CONSOLE_SPI_FLASH=y | ||
| CONFIG_POST_DEVICE_PCI_PCIE=y | ||
| CONFIG_FATAL_ASSERTS=y | ||
| CONFIG_DEBUG_CBFS=y | ||
| CONFIG_DEBUG_SMBUS=y | ||
| CONFIG_DEBUG_SMI=y | ||
| CONFIG_DEBUG_PERIODIC_SMI=y | ||
| CONFIG_DEBUG_MALLOC=y | ||
| CONFIG_DEBUG_CONSOLE_INIT=y | ||
| CONFIG_DEBUG_SPI_FLASH=y | ||
| CONFIG_DEBUG_COVERAGE=y | ||
| CONFIG_DEBUG_BOOT_STATE=y | ||
| CONFIG_DEBUG_ADA_CODE=y | ||
| CONFIG_HAVE_EM100_SUPPORT=y | ||
| CONFIG_EM100=y |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1 @@ | ||
| CONFIG_CPU_QEMU_X86_64=y |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| # Not meant for actual use. Exercises Intel TXT code. Since BIOS | ||
| # and SINIT ACM blobs are missing, use something else as placeholder. | ||
| CONFIG_VENDOR_PURISM=y | ||
| CONFIG_BOARD_PURISM_LIBREM15_V4=y | ||
| CONFIG_INTEL_TXT=y | ||
| CONFIG_INTEL_TXT_BIOSACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin" | ||
| CONFIG_INTEL_TXT_SINITACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin" | ||
| CONFIG_INTEL_TXT_LOGGING=y |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,4 +5,4 @@ CONFIG_LP_USB_UHCI=y | |
| CONFIG_LP_USB_OHCI=y | ||
| CONFIG_LP_USB_EHCI=y | ||
| CONFIG_LP_USB_XHCI=y | ||
| CONFIG_LP_HEAP_SIZE=1048576 | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,89 @@ | ||
| /* SPDX-License-Identifier: GPL-2.0-or-later */ | ||
|
|
||
| #include <console/console.h> | ||
| #include <bootmem.h> | ||
| #include <program_loading.h> | ||
| #include <fit.h> | ||
| #include <symbols.h> | ||
|
|
||
| /** | ||
| * Place the region in free memory range. | ||
| */ | ||
| static bool fit_place_mem(const struct range_entry *r, void *arg) | ||
| { | ||
| struct region *region = arg; | ||
| resource_t start; | ||
|
|
||
| if (range_entry_tag(r) != BM_MEM_RAM) | ||
| return true; | ||
|
|
||
| /* Linux 4.15 doesn't like 4KiB alignment. Align to 1 MiB for now. */ | ||
| start = ALIGN_UP(MAX(region->offset, range_entry_base(r)), 1 * MiB); | ||
|
|
||
| if (start + region->size < range_entry_end(r)) { | ||
| region->offset = (size_t)start; | ||
| return false; | ||
| } | ||
|
|
||
| return true; | ||
| } | ||
|
|
||
| bool fit_payload_arch(struct prog *payload, struct fit_config_node *config, | ||
| struct region *kernel, | ||
| struct region *fdt, | ||
| struct region *initrd) | ||
| { | ||
| void *arg = NULL; | ||
|
|
||
| /** | ||
| * The kernel ARM documentation recommends loading the kernel above 32MiB | ||
| * in order to avoid the need to need to relocate prior to decompression. | ||
| */ | ||
| kernel->offset = (uintptr_t)_dram + 32 * MiB; | ||
|
|
||
| /** | ||
| * The code assumes that bootmem_walk provides a sorted list of memory | ||
| * regions, starting from the lowest address. | ||
| * The order of the calls here doesn't matter, as the placement is | ||
| * enforced in the called functions. | ||
| * For details check code on top. | ||
| */ | ||
| if (!bootmem_walk(fit_place_mem, kernel)) | ||
| return false; | ||
|
|
||
| /* Mark as reserved for future allocations. */ | ||
| bootmem_add_range(kernel->offset, kernel->size, BM_MEM_PAYLOAD); | ||
|
|
||
| /** | ||
| * To ensure the fdt is not overwritten by the kernel decompressor, place | ||
| * the fdt above the 128 MB from the start of RAM, as recommended by the | ||
| * kernel documentation. | ||
| */ | ||
| fdt->offset = (uintptr_t)_dram + 128 * MiB; | ||
|
|
||
| if (!bootmem_walk(fit_place_mem, fdt)) | ||
| return false; | ||
|
|
||
| /* Mark as reserved for future allocations. */ | ||
| bootmem_add_range(fdt->offset, fdt->size, BM_MEM_PAYLOAD); | ||
|
|
||
| /* Place INITRD */ | ||
| if (config->ramdisk) { | ||
| initrd->offset = fdt->offset + fdt->size; | ||
|
|
||
| if (!bootmem_walk(fit_place_mem, initrd)) | ||
| return false; | ||
|
|
||
| /* Mark as reserved for future allocations. */ | ||
| bootmem_add_range(initrd->offset, initrd->size, BM_MEM_PAYLOAD); | ||
| } | ||
|
|
||
| /* Kernel expects FDT as argument */ | ||
| arg = (void *)fdt->offset; | ||
|
|
||
| prog_set_entry(payload, (void *)kernel->offset, arg); | ||
|
|
||
| bootmem_dump_ranges(); | ||
|
|
||
| return true; | ||
| } |