     [file constants.texi not included]

Copyright © 2014, 2015, 2016 Leah Rowe <info@minifree.org>

Copyright © 2015 Paul Kocialkowski <contact@paulk.fr>

Copyright © 2015 Alex David <opdecirkel@gmail.com>

Copyright © 2015 Patrick "P. J." McDermott <pj@pehjota.net>

Copyright © 2015 Albin Söderqvist

Copyright © 2015 Jeroen Quint <jezza@diplomail.ch>

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at gfdl-1.3.txt (../licenses/gfdl-1.3.txt)

Updated versions of the license (when available) can be found at https://www.gnu.org/licenses/licenses.html

     UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.

     TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.

     The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.

GNU Libreboot documentation
***************************

Information about this release can be found by consulting the release notes (see release). Always check libreboot.org (http://libreboot.org) for updates.

Libreboot release information
*****************************

Release date: Day Month Year.

Installation instructions can be found here. Building instructions (for source code) can be found here.

Machines supported in this release:
===================================

  * ASUS Chromebook C201

       * Check notes: see ASUS Chromebook C201.

       * NOTE: not in libreboot 20150518. Only in git. for now.

  * Gigabyte GA-G41M-ES2L desktop board

       * Check notes: see Gigabyte GA-G41M-ES2L motherboard.

       * NOTE: not in libreboot 20150518. Only in git, for now.

  * Intel D510MO desktop board

       * Check notes: see Intel D510MO motherboard.

       * NOTE: not in libreboot 20150518. Only in git, for now.

  * ASUS KFSN4-DRE server board

       * PCB revision 1.05G is the best version (can use 6-core CPUs)

       * Check notes: see ASUS KFSN4-DRE motherboard.

       * NOTE: not in libreboot 20150518. Only in git, for now.

  * ASUS KGPE-D16 server board

       * Check notes: see ASUS KGPE-D16 motherboard.

       * NOTE: not in libreboot 20150518. Only in git, for now.

  * ASUS KCMA-D8 desktop/workstation board

       * Check notes: see ASUS KCMA-D8 motherboard.

       * NOTE: not in libreboot 20150518. Only in git, for now.

  * ThinkPad X60/X60s

       * You can also remove the motherboard from an X61/X61s and replace it with an X60/X60s motherboard. An X60 Tablet motherboard will also fit inside an X60/X60s.

  * ThinkPad X60 Tablet (1024x768 and 1400x1050) with digitizer support

       * See Lenovo ThinkPad X60/X60s for list of supported LCD panels

       * It is unknown whether an X61 Tablet can have it's mainboard replaced with an X60 Tablet motherboard.

  * ThinkPad T60 (Intel GPU) (there are issues; see below):

       * See notes below for exceptions, and see Supported T60 list for known working LCD panels.

       * It is unknown whether a T61 can have it's mainboard replaced with a T60 motherboard.

       * See https://libreboot.org/docs/future/index.html#t60_cpu_microcode

       * T60P (and T60 laptops with ATI GPU) will likely never be supported: see Lenovo ThinkPad T60.

  * ThinkPad X200

       * X200S and X200 Tablet are also supported, conditionally; see X200S and X200 Tablet.

       * ME/AMT: libreboot removes this, permanently. See GM45 chipsets - remove the ME.

  * ThinkPad R400

       * See hcl/r400.html

       * ME/AMT: libreboot removes this, permanently. See GM45 chipsets - remove the ME.

  * ThinkPad T400

       * See hcl/t400.html

       * ME/AMT: libreboot removes this, permanently. See GM45 chipsets - remove the ME.

  * ThinkPad T500

       * See hcl/t500.html

       * ME/AMT: libreboot removes this, permanently. See GM45 chipsets - remove the ME.

  * Apple MacBook1,1 (MA255LL/A, MA254LL/A, MA472LL/A)

       * See Macbook1,1.

  * Apple MacBook2,1 (MA699LL/A, MA701LL/A, MB061LL/A, MA700LL/A, MB063LL/A, MB062LL/A)

       * See Macbook2,1.

Changes for this release, relative to r20150518 (earliest changes last, recent changes first)
=============================================================================================

  * Changelog not yet generated. Clone the git repository and check the git logs.

Table of contents
*****************

Hardware compatibility
======================

This section relates to known hardware compatibility in libreboot.

List of supported hardware
--------------------------

Libreboot supports the following systems in this release:

  * Desktops (AMD, Intel x86)

       - Gigabyte GA-G41M-ES2L motherboard

       - Intel D510MO motherboard

       - ASUS KCMA-D8 motherboard

  * Servers/workstations (AMD, x86)

       - ASUS KFSN4-DRE motherboard

       - ASUS KGPE-D16 motherboard

  * Laptops (ARM)

       - ASUS Chromebook C201

  * Laptops (Intel x86)

       - Lenovo ThinkPad X60/X60s

       - Lenovo ThinkPad X60 Tablet

       - Lenovo ThinkPad T60

       - Lenovo ThinkPad X200

       - Lenovo ThinkPad R400

       - Lenovo ThinkPad T400

       - Lenovo ThinkPad T500

       - Apple MacBook1,1

       - Apple MacBook2,1

`Supported' means that the build scripts know how to build ROM images for these systems, and that the systems have been tested (confirmed working). There may be exceptions; in other words, this is a list of `officially' supported systems.

It is also possible to build ROM images (from source) for other systems (and virtual systems, e.g. QEMU).

Gigabyte GA-G41M-ES2L motherboard
.................................

This is a desktop board using intel hardware (circa ~2009, ICH7 southbridge, similar performance-wise to the Libreboot X200. It can make for quite a nifty desktop. Powered by libreboot.

IDE on the board is untested, but it might be possible to use a SATA HDD using an IDE SATA adapter. The SATA ports do work.

Read this post on the libreboot mailing list for more information: https://lists.nongnu.org/archive/html/libreboot-dev/2015-12/msg00011.html

NOTE: by default, a working MAC address is not always set automatically. You need to set a MAC address manually in your GNU/Linux distribution. On debian-based systems (e.g. Trisquel), you can add this to your /etc/network/interfaces file for your NIC: hwaddress ether macaddressgoeshere

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository.

Flashing instructions can be found at flashrom.

Intel D510MO motherboard
........................

This is a desktop board using intel hardware. It can make for quite a nifty desktop. Powered by libreboot.

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository.

NOTE: video framebuffer currently unsupported, only text-mode works, even when booting GNU/Linux. This can still be used for building a headlesss server. Boot with fb=false

Flashing instructions can be found at Flashing Intel D510MO.

ASUS KCMA-D8 motherboard
........................

This is a desktop board using AMD hardware (Fam10h and Fam15h CPUs available). It can also be used for building a high-powered workstation. Powered by libreboot. The coreboot port was done by Timothy Pearson of Raptor Engineering Inc. (https://raptorengineeringinc.com/) and, working with Timothy (and sponsoring the work) merged into libreboot.

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository.

Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..

Flashing instructions can be found at flashrom - note that external flashing is required (e.g. BBB), if the proprietary (ASUS) firmware is currently installed. If you already have libreboot, by default it is possible to re-flash using software running in GNU/Linux on the kcma-d8, without using external hardware.

  * CPU compatibility

       * Use Opteron 4200 series (works without microcode updates, including hw virt). 4300 series needs microcode updates, so avoid those CPUs. 4100 series is too old, and mostly untested.

  * Board status compatibility

       * See https://raptorengineeringinc.com/coreboot/kcma-d8-status.php.

  * Form factor

       * These boards use the SSI EEB 3.61 form factor; make sure that your case supports this. This form factor is similar to E-ATX in that the size is identical, but the position of the screws are different.

  * IPMI iKVM module add-on

       * Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the Intel Management Engine (http://libreboot.org/faq/#intelme). Fortunately, the firmware is unsigned (possibly to replace) and physically separate from the mainboard since it's on the add-on module, which you don't have to install.

  * Flash chips

       * 2MiB flash chips are included by default, on these boards. It's on a P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes: 4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a compressed linux+initramfs image (BusyBox+Linux system) into CBFS and boot that, loading it into memory.

       * Libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default flash chip is 2MiB).

       * DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

  * Native graphics initialization

       * Only text-mode is known to work, but linux(kernel) can initialize the framebuffer display (if it has KMS - kernel mode setting).

  * Current issues

       * LRDIMM memory modules are currently incompatible

       * SAS (via PIKE 2008 module) requires non-free option ROM (and SeaBIOS) to boot from it (theoretically possible to replace, but you can put a kernel in CBFS or on SATA and use that to boot GNU, which can be on a SAS drive. The linux kernel can use those SAS drives (via PIKE module) without an option ROM).

       * IPMI iKVM module (optional add-on card) uses proprietary firmware. Since it's for remote out-of-band management, it's theoretically a backdoor similar to the Intel Management Engine. Fortunately, unlike the ME, this firmware is unsigned which means that a free replacement is theoretically possible. For now, the libreboot project recommends not installing the module. This project (https://github.com/facebook/openbmc) might be interesting to derive from, for those who want to work on a free replacement. In practise, out-of-band management isn't very useful anyway (or at the very least, it's not a major inconvenience to not have it).

       * Graphics: only text-mode works. See graphics.

  * Hardware specifications

       * Check ASUS website for specs

ASUS KFSN4-DRE motherboard
..........................

This is a server board using AMD hardware (Fam10h). It can also be used for building a high-powered workstation. Powered by libreboot.

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository.

Flashing instructions can be found at flashrom.

  * Form factor

       * These boards use the SSI EEB 3.61 form factor; make sure that your case supports this. This form factor is similar to E-ATX in that the size is identical, but the position of the screws are different.

  * Flash chips

       * These boards use LPC flash (not SPI), in a PLCC socket. The default flash size 1MiB (8Mbits), and can be upgraded to 2MiB (16Mbits). SST49LF080A is the default that the board uses. SST49LF016C is an example of a 2MiB (16Mbits) chip, which might work. It is believed that 2MiB (16Mbits) is the maximum size available for the flash chip.

       * DO NOT hot-swap the chip with your bare hands. Use a PLCC chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

  * Native graphics initialization

       * Native graphics initialization exists (XGI Z9s) for this board. Framebuffer- and text-mode both work. A serial port is also available.

  * Memory

       * DDR2 533/667 Registered ECC. 16 slots. Total capacity up to 64GiB.

  * Hex-core CPUs

       * PCB revision 1.05G is the best version of this board (the revision number will be printed on the board), because it can use dual hex-core CPUs (Opteron 2400/8400 series). Other revisions are believed to only support dual quad-core CPUs.

  * Current issues

       * There seems to be a 30 second bootblock delay (observed by tpearson); the system otherwise boots and works as expected. See kfsn4-dre/bootlog.txt (../text/kfsn4-dre/bootlog.txt) - this uses the 'simple' bootblock, while tpearson uses the 'normal' bootblock, which tpearson suspects may be a possible cause. This person says that they will look into it. This config (http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asus/kfsn4-dre/4.0-10101-g039edeb/2015-06-27T03:59:16Z/config.txt;h=4742905c185a93fbda8eb14322dd82c70641aef0;hb=055f5df4e000a97453dfad6c91c2d06ea22b8545) doesn't have the issue.

       * Text-mode is a bit jittery (but still usable). (the jitter disappears if using KMS, once the kernel starts. The jitter will remain, if booting the kernel in text-mode).

  * Other information

       * specifications (ftp://ftp.sgi.com/public/Technical%20Support/Pdf%20files/Asus/kfsn4-dre.pdf)

ASUS KGPE-D16 server/workstation board
......................................

This is a server board using AMD hardware (Fam10h and Fam15h CPUs available). It can also be used for building a high-powered workstation. Powered by libreboot. The coreboot port was done by Timothy Pearson of Raptor Engineering Inc. (https://raptorengineeringinc.com/) and, working with Timothy (and sponsoring the work) merged into libreboot.

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository.

Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..

Flashing instructions can be found at flashrom - note that external flashing is required (e.g. BBB), if the proprietary (ASUS) firmware is currently installed. If you already have libreboot, by default it is possible to re-flash using software running in GNU/Linux on the KGPE-D16, without using external hardware.

  * CPU compatibility

       - Use Opteron 6200 series (works without microcode updates, including hw virt). 6300 series needs microcode updates, so avoid those CPUs. 6100 series is too old, and mostly untested.

  * Board status compatibility

       - See https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php.

  * Form factor

       - These boards use the SSI EEB 3.61 form factor; make sure that your case supports this. This form factor is similar to E-ATX in that the size is identical, but the position of the screws are different.

  * IPMI iKVM module add-on

       - Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the Intel Management Engine (http://libreboot.org/faq/#intelme). Fortunately, the firmware is unsigned (possibly to replace) and physically separate from the mainboard since it's on the add-on module, which you don't have to install.

  * Flash chips

       - 2MiB flash chips are included by default, on these boards. It's on a P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes: 4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a compressed linux+initramfs image (BusyBox+Linux system) into CBFS and boot that, loading it into memory.

       - Libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default flash chip is 2MiB).

       - DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

  * Native graphics initialization

       - Only text-mode is known to work, but linux(kernel) can initialize the framebuffer display (if it has KMS - kernel mode setting).

  * Current issues

       - LRDIMM memory modules are currently incompatible

       - SAS (via PIKE 2008 module) requires non-free option ROM (and SeaBIOS) to boot from it (theoretically possible to replace, but you can put a kernel in CBFS or on SATA and use that to boot GNU, which can be on a SAS drive. The linux kernel can use those SAS drives (via PIKE module) without an option ROM).

       - IPMI iKVM module (optional add-on card) uses proprietary firmware. Since it's for remote out-of-band management, it's theoretically a backdoor similar to the Intel Management Engine. Fortunately, unlike the ME, this firmware is unsigned which means that a free replacement is theoretically possible. For now, the libreboot project recommends not installing the module. This project (https://github.com/facebook/openbmc) might be interesting to derive from, for those who want to work on a free replacement. In practise, out-of-band management isn't very useful anyway (or at the very least, it's not a major inconvenience to not have it).

       - Graphics: only text-mode works. See graphics.

  * Processor / system bus

       * 2 CPU sockets (G34 compatible)

       * HyperTransport(TM) Technology 3.0

       * CPUs supported:

            * AMD Opteron 6100 series (Fam10h. No IOMMU support. Not recommended - old. View errata datasheet here: http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf)

            * AMD Opteron 6200 series (bulldozer cores) (Fam15h, with full IOMMU support in libreboot. highly recommended - fast, and works well without microcode updates, including virtualization)

            * AMD Opteron 6300 series (piledriver cores) (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates

            * NOTE: 6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates. The 6200 series CPUs have more reliable microcode. Look at this errata datasheet: http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf (see Errata 734 - this is what kills the 6300 series)

       * 6.4 GT/s per link (triple link)

  * Core logic

       * AMD SR5690

       * AMD SP5100

  * Memory compatibility with libreboot

       * Total Slots: 16 (4-channel per CPU, 8 DIMM per CPU), ECC

       * Capacity: Maximum up to 256GB RDIMM

       * Memory Type that is compatible:

            * DDR3 1600/1333/1066/800 UDIMM*

            * DDR3 1600/1333/1066/800 RDIMM*

       * Compatible sizes per memory module:

            * 16GB, 8GB, 4GB, 3GB, 2GB, 1GB RDIMM

            * 8GB, 4GB, 2GB, 1GB UDIMM

  * Expansion slots

       * Total slot: 6

       * Slot Location 1: PCI 32bit/33MHz

       * Slot Location 2: PCI-E x16 (Gen2 X8 Link)

       * Slot Location 3: PCI-E x16 (Gen2 X16 Link), Auto switch to x8 link if slot 2 is occupied

       * Slot Location 4: PCI-E x8 (Gen2 X4 Link)

       * Slot Location 5: PCI-E x16 (Gen2 X16 Link)

       * Slot Location 6: PCI-E x16 (Gen2 X16 Link), Auto turn off if slot 5 is occupied, For 1U FH/FL Card, MIO supported

       * Additional Slot 1: PIKE slot (for SAS drives. See notes above)

       * Follow SSI Location#

  * Form factor

       * SSI EEB 3.61 (12"x13")

  * ASUS features

       * Fan Speed Control

       * Rack Ready (Rack and Pedestal dual use)

  * Storage

       * SATA controller:

            * AMD SP5100

            * 6 x SATA2 300MB/s

       * SAS/SATA Controller:

            * ASUS PIKE2008 3Gbps 8-port SAS card included

  * Networking

       * 2 x Intel® 82574L + 1 x Mgmt LAN

  * Graphics

       * Aspeed AST2050 with 8MB VRAM

  * On board I/O

       * 1 x PSU Power Connector (24-pin SSI power connector + 8-pin SSI 12V + 8-pin SSI 12V power connector)

       * 1 x Management Connector , Onboard socket for management card

       * 3 x USB pin header , Up to 6 Devices

       * 1 x Internal A Type USB Port

       * 8 x Fan Header , 4pin (3pin/4pin fan dual support)

       * 2 x SMBus

       * 1 x Serial Port Header

       * 1 x TPM header

       * 1 x PS/2 KB/MS port

  * Back I/O ports

       * 1 x External Serial Port

       * 2 x External USB Port

       * 1 x VGA Port

       * 2 x RJ-45

       * 1 x PS/2 KB/Mouse

  * Environment

       * Operation temperature: 10C ~ 35C

       * Non operation temperature: -40C ~ 70C

       * Non operation humidity: 20% ~ 90% ( Non condensing)

  * Monitoring

       * CPU temperatures

       * Fan speed (RPM)

  * Note

       * DDR3 1600 can only be supported with AMD Opteron 6300/6200 series processor

ASUS Chromebook C201
....................

This is a Chromebook, using the Rockchip RK3288 SoC. It uses an ARM CPU, and has free EC firmware (unlike some other laptops). More RK3288-based laptops will be added to libreboot at a later date.

Paul Kocialkowski, a Replicant (http://www.replicant.us/) developer, ported this laptop to libreboot. Thank you, Paul!

NOTE: This board is unsupported in libreboot 20150518. To use it in libreboot, for now, you must build for it from source using the libreboot git repository. Note that we recommend building for it from an x86 host, until libreboot's build system is modified accordingly.

More info will be added later, including build/installation instructions. The board is supported in libreboot, however, and has been confirmed to work.

Flashing instructions can be found at flashrom.

Google's intent with CrOS devices
.................................

CrOS (Chromium OS/Chrome OS) devices, such as Chromebooks, were not designed with the intent of bringing more freedom to users. However, they run with a lot of free software at the boot software and embedded controller levels, since free software gives Google enough flexibility to optimize various aspects such as boot time and most importantly, to implement the CrOS security system, that involves various aspects of the software. Google does hire a lot of Coreboot developers, who are generally friendly to the free software movement and try to be good members of the free software community, by contributing code back.

CrOS devices are designed (from the factory) to actually coax the user into using proprietary web services (https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html) (SaaSS) that invade the user's privacy (ChromeOS is literally just the Google Chrome browser when you boot up, itself proprietary and comes with proprietary add-ons like flash. It's only intended for SaaSS, not actual, real computing). Google is even a member of the PRISM program, as outlined by Edward Snowden. See notes about ChromeOS below. The libreboot project recommends that the user replace the default ChromeOS with a distribution that can be used in freedom, without invading the user's privacy.

We also use a similar argument for the MacBook and the ThinkPads that are supported in libreboot. Those laptops are supported, in spite of Apple and Lenovo, companies which are actually hostile to the free software movement.

Considerations about ChromeOS and free operating systems
........................................................

This laptop comes preinstalled (from the factory) with Google ChromeOS. This is a GNU/Linux distribution, but it's not general purpose and it comes with proprietary software. It's designed for SaaSS (https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html). Libreboot recommends that users of this laptop replace it with another distribution.

The FSF has a list of distributions (https://www.gnu.org/distros/free-distros.html) that are 100% free software. Only one of them is confirmed to work on ARM CrOS devices. Parabola looks hopeful: https://www.parabola.nu/news/parabola-supports-armv7/

The libreboot project would like to see all FSF-endorsed distro projects port to these laptops. This includes Trisquel, GuixSD and others. And ProteanOS. Maybe even LibreCMC. The more the merrier. We need them, badly.

We need these distributions to be ported as soon as possible.

Caution: Video acceleration requires a non-free blob, software rendering can be used instead.
.............................................................................................

The Tamil driver source code for the onboard Mali T GPU is not released. The developer has so-far withheld it. Until that is released, the only way to use video (in freedom) on this laptop is to not have video acceleration, by making sure not to install the relevant blob. Most tasks can still be performed without video acceleration, without any noticeable performance penalty.

In practise, this means that certain things like games, blender and GNOME shell (or other fancy desktops) won't work well. The libreboot project recommends a lightweight desktop which does not need video acceleration, such as XFCE or LXDE.

The Tamil developer wrote this blog post, which sheds light on the story: http://libv.livejournal.com/27461.html

Caution: WiFi requires a non-free blob, a USB dongle can be used instead.
.........................................................................

These laptops have non-removeable (soldered on) WiFi chips, which require non-free firmware in the Linux kernel in order to work.

The libreboot project recommends using an external USB wifi dongle that works with free software. See Recommended wifi chipsets.

There are 2 companies (endorsed by the Free Software Foundation, under their Respects your Freedom guidelines), that sell USB WiFi dongles guaranteed to work with free software (i.e. linux-libre kernel):

  * ThinkPenguin sells them (https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb) (company based in USA)

  * Tehnoetic sells them (https://tehnoetic.com/tehnoetic-wireless-adapter-gnu-linux-libre-tet-n150) (company based in Europe)

These wifi dongles use the AR9271 (atheros) chipset, supported by the free ath9k_htc driver in the Linux kernel. They work in linux-libre too.

EC firmware is free software!
.............................

It's free software. Google provides the source. Build scripts will be added later, with EC sources provided in libreboot, and builds of the EC firmware.

This is unlike the other current libreboot laptops (Intel based). In practise, you can (if you do without the video/wifi blobs, and replace ChromeOS with a distribution that respects your freedom) be more free when using one of these laptops.

The libreboot FAQ briefly describes what an EC is: http://libreboot.org/faq/#firmware-ec

No microcode!
.............

Unlike x86 (e.g. Intel/AMD) CPUs, ARM CPUs do not use microcode, not even built in. On the Intel/AMD based libreboot systems, there is still microcode in the CPU (not considered problematic by the FSF, provided that it is reasonably trusted to not be malicious, since it's part of the hardware and read-only), but we exclude microcode updates (volatile updates which are uploaded at boot time by the boot firmware, if present), which are proprietary software.

On ARM CPUs, the instruction set is implemented in circuitry, without microcode.

Depthcharge payload
...................

These systems do not use the GRUB payload. Instead, they use a payload called depthcharge, which is common on CrOS devices. This is free software, maintained by Google.

Flash chip write protection: the screw
......................................

It's next to the flash chip. Unscrew it, and the flash chip is read-write. Screw it back in, and the flash chip is read-only. It's called the screw.

The screw is accessible by removing other screws and gently prying off the upper shell, where the flash chip and the screw are then directly accessible. User flashing from software is possible, without having to externally re-flash, but the flash chip is SPI (SOIC-8 form factor) so you can also externally re-flash if you want to. In practise, you only need to externally re-flash if you brick the laptop; read BBB setup for an example of how to set up an SPI programmer.

Write protection is useful, because it prevents the firmware from being re-flashed by any malicious software that might become executed on your GNU/Linux system, as root. In other words, it can prevent a firmware-level evil maid attack. It's possible to write protect on all current libreboot systems, but CrOS devices make it easy. The screw is such a stupidly simple idea, which all designs should implement.

Lenovo ThinkPad X60/X60s
........................

Native gpu initialization (`native graphics') which replaces the proprietary VGA Option ROM (`Video BIOS (https://en.wikipedia.org/wiki/Video_BIOS)' or `VBIOS'), all known LCD panels are currently compatible:

To find what LCD panel you have, see: Get EDID.

  * TMD-Toshiba LTD121ECHB: #

  * CMO N121X5-L06: #

  * Samsung LTN121XJ-L07: #

  * BOE-Hydis HT121X01-101: #

You can remove an X61/X61s motherboard from the chassis and install an X60/X60s motherboard in it's place (for flashing libreboot). The chassis is mostly identical and the motherboards are the same shape/size.

The X60 typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one after libreboot is installed. See Recommended wifi chipsets for replacements.

Lenovo ThinkPad X60 Tablets
...........................

Native gpu initialization (`native graphics') which replaces the proprietary VGA Option ROM (`Video BIOS (https://en.wikipedia.org/wiki/Video_BIOS)' or `VBIOS').

To find what LCD panel you have, see: Get EDID.

There are 5 known LCD panels for the X60 Tablet:

  * X60T XGA (1024x768):

       * BOE-Hydis HV121X03-100 (works)

       * Samsung LTN121XP01 (does not work. blank screen)

       * BOE-Hydis HT12X21-351 (does not work. blank screen)

  * X60T SXGA+ (1400x1050):

       * BOE-Hydis HV121P01-100 (works)

       * BOE-Hydis HV121P01-101 (works)

Most X60Ts only have digitizer (pen), but some have finger (touch) aswell as pen; finger/multitouch doesn't work, only digitizer (pen) does.

You can remove an X61/X61s motherboard from the chassis and install an X60/X60s motherboard in its place (for flashing libreboot). The chassis is mostly identical and the motherboards are the same shape/size. It is unknown if the same applies between the X60 Tablet and the X61 Tablet.

The X60 Tablet typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one after libreboot is installed. See Recommended wifi chipsets for replacements.

A user with a X60T that has digitizer+finger support, reported that they could get finger input working. They used linuxwacom at git tag 0.25.99.2 and had the following in their xorg.conf:

# Now, for some reason (probably a bug in linuxwacom),
# the 'Touch=on' directive gets reset to 'off'.
# So you'll need to do
# $ xsetwacom --set WTouch Touch on
#
# tested with linuxwacom git 42a42b2a8636abc9e105559e5dea467163499de7

Section "Monitor"
     Identifier             "<default monitor>"
     DisplaySize     245 184
EndSection

Section "Screen"
     Identifier "Default Screen Section"
     Monitor    "<default monitor<"
EndSection

Section "InputDevice"
     Identifier  "WTouch"
     Driver      "wacom"
     Option      "Device" "/dev/ttyS0"
#    Option      "DebugLevel" "12"
     Option      "BaudRate" "38400"
     Option      "Type" "touch"
     Option      "Touch" "on"
     Option      "Gesture" "on"
     Option      "ForceDevice" "ISDV4"
#    Option      "KeepShape" "on"
     Option      "Mode" "Absolute"
     Option      "RawSample" "2"
#    Option      "TPCButton" "off"
     Option      "TopX" "17"
     Option      "TopY" "53"
     Option      "BottomX" "961"
     Option      "BottomY" "985"
EndSection

Section "ServerLayout"
  Identifier    "Default Layout"
  Screen        "Default Screen Section"
  InputDevice   "WTouch" "SendCoreEvents"
EndSection

Lenovo ThinkPad T60
...................

If your T60 is a 14.1" or 15.1" model with an ATI GPU, it won't work with libreboot by default but you can replace the motherboard with another T60 motherboard that has an Intel GPU, and then libreboot should work.

As far as I know, 14.1" (Intel GPU) and 15.1" (Intel GPU) T60 motherboards are the same, where 'spacers' are used on the 15.1" T60. In any case, it makes sense to find one that is guaranteed to fit in your chassis.

There is also a 15.4" T60 with Intel GPU.

Note: the T60p laptops all have ATI graphics. The T60p laptops cannot be used with libreboot under any circumstances.

The following T60 motherboard (see area highlighted in white) shows an empty space where the ATI GPU would be (this particular motherboard has an Intel GPU):

The reason that the ATI GPU on T60 is unsupported is due to the VBIOS (Video BIOS) which is non-free. The VBIOS for the Intel GPU on X60/T60 has been reverse engineered, and replaced with Free Software and so will work in libreboot.

The 'Video BIOS' is what initializes graphics.

See: https://en.wikipedia.org/wiki/Video_BIOS.
 In fact, lack of free VBIOS in general is a big problem in coreboot, and is one reason (among others) why many ports for coreboot are unsuitable for libreboot's purpose.

Theoretically, the ThinkPad T60 with ATI GPU can work with libreboot and have ROM images compiled for it, however in practise it would not be usable as a laptop because there would be no visual display at all. That being said, such a configuration is acceptable for use in a 'headless' server setup (with serial and/or ssh console as the display).

Native gpu initialization ('native graphics') which replaces the proprietary VGA Option ROM ('Video BIOS (https://en.wikipedia.org/wiki/Video_BIOS)' or 'VBIOS').

To find what LCD panel you have, see: Get EDID.

Some T60s have ATI GPUs, and all T60P laptops have ATI GPUs These are incompatible! See t60_ati_intel for how to remedy this.

How to dump the EDID:

Tested LCD panels: working(compatible)

  * TMD-Toshiba LTD141EN9B (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)

  * Samsung LTN141P4-L02 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)

  * LG-Philips LP150E05-A2K1 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

  * Samsung LTN150P4-L01 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board) (not a T60 screen afaik, but it works)

  * BOE-Hydis HV150UX1-100 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

Tested LCD panels: not working yet (incompatible; see https://libreboot.org/docs/future/index.html#lcd_i945_incompatibility)

  * Samsung LTN141XA-L01 (14.1" 1024x768)

  * LG-Philips LP150X09 (15.1" 1024x768)

  * Samsung LTN150XG (15.1" 1024x768)

  * LG-Philips LP150E06-A5K4 (15.1" 1400x1050) (also, not an official T60 screen)

  * Samsung LTN154X3-L0A (15.4" 1280x800)

  * IDtech IAQX10N (15.1" 2048x1536) (no display in GRUB, display in GNU/Linux is temperamental) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

  * IDtech N150U3-L01 (15.1" 1600x1200) (no display in GRUB, display in GNU/Linux works) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

The following LCD panels are UNTESTED. If you have one of these panels then please submit a report!:

  * CMO(IDtech?) N141XC (14.1" 1024x768)

  * BOE-Hydis HT14X14 (14.1" 1024x768)

  * TMD-Toshiba LTD141ECMB (14.1" 1024x768)

  * Boe-Hydis HT14P12 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)

  * CMO (IDtech?) 13N7068 (15.1" 1024x768)

  * CMO (IDtech?) 13N7069 (15.1" 1024x768)

  * BOE-Hydis HV150P01-100 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

  * BOE-Hydis HV150UX1-102 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

  * IDtech IAQX10S (15.1" 2048x1536) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)

  * Samsung LTN154P2-L05 (42X4641 42T0329) (15.4" 1680x1050)

  * LG-Philips LP154W02-TL10 (13N7020 42T0423) (15.4" 1680x1050)

  * LG-Philips LP154WU1-TLB1 (42T0361) (15.4" 1920x1200) (for T61p but it might work in T60. Unknown!)

  * Samsung LTN154U2-L05 (42T0408 42T0574) (15.4" 1920x1200) (for T61p but it might work in T60. Unknown!)

It is unknown whether the 1680x1050 (15.4") and 1920x1200 (15.4") panels use a different inverter board than the 1280x800 panels.

The T60 typically comes with an Intel wifi chipset which does not work at all without proprietary firmware, and while Lenovo BIOS is running the system will refuse to boot if you replace the card. Fortunately it is very easily replaced; just remove the card and install another one after libreboot is installed. See Recommended wifi chipsets for replacements.

ThinkPad X200
.............

It is believed that all X200 laptops are compatible. X200S and X200 Tablet will also work,depending on the configuration.

It *might* be possible to put an X200 motherboard in an X201 chassis, though this is currently untested by the libreboot project. The same may also apply between X200S and X201S; again, this is untested. It's most likely true.

There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or 8MiB (64Mbit). This can be identified by the type of flash chip below the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.

The X200 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see gm45_remove_me (contains notes, plus instructions).

Flashing instructions can be found at flashrom

Compatibility without blobs - X200
..................................

The X200, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower).

On GM45 hardware (with libreboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU.

The following errata datasheet from Intel might help with investigation: http://download.intel.com/design/mobile/specupdt/320121.pdf

Anecdotal reports from at least 1 user suggests that some models with CPU microcode 1067a (on the CPU itself) might work with vt-x in libreboot.

X200S and X200 Tablet.
......................

X200S and X200 Tablet have raminit issues at the time of writing (GS45 chipset. X200 uses GM45).

X200S and X200 Tablet are known to work, but only with certain CPU+RAM configurations. The current stumbling block is RCOMP and SFF, mentioned in https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf.

The issues mostly relate to raminit (memory initialization). With an unpatched coreboot, you get the following: cblog00.txt (../text/x200s/cblog00.txt). No SODIMM combination that was tested would work. At first glance, it looks like GS45 (chipset that X200S uses. X200 uses GM45) is unsupported, but there is a workaround that can be used to make certain models of the X200S work, depending on the RAM.

The datasheet for GS45 describes two modes: low-performance and high-performance. Low performance uses the SU range of ultra-low voltage procesors (SU9400, for example), and high-performance uses the SL range of processors (SL9400, for example). According to datasheets, GS45 behaves very similarly to GM45 when operating in high-performance mode.

The theory then was that you could simply remove the checks in coreboot and make it pass GS45 off as GM45; the idea is that, with a high-performance mode CPU (SL9400, for example) it would just boot up and work.

This suspicion was confirmed with the following log: cblog01.txt (../text/x200s/cblog01.txt). The memory modules in this case are 2x4GB. However, not all configurations work: cblog02.txt (../text/x200s/cblog02.txt) (2x2GB) and cblog03.txt (../text/x200s/cblog03.txt) (1x2GB) show a failed bootup. False alarm. The modules were mixed (non-matching). X200S with high-performance mode CPU will work so long as you use matching memory modules (doesn't matter what size). S

This was then pushed as a patch for coreboot, which can be found at http://review.coreboot.org/#/c/7786/ (libreboot merges this patch in coreboot-libre now. Check the 'getcb' script in src or git).

A new northbridge gs45 should be added to coreboot, based on gm45, and a new port x200st (X200S and X200T) should be added based on the x200 port.

This port would have proper raminit. Alternatively, gs45 (if raminit is taken to be the only issue with it) can be part of gm45 northbridge support (and X200S/Tablet being part of the X200 port) with conditional checks in the raminit that make raminit work differently (as required) for GS45. nico_h and pgeorgi/patrickg in the coreboot IRC channel should know more about raminit on gm45 and likely gs45.

pgeorgi recommends to run SerialICE on the factory BIOS (for X200S), comparing it with X200 (factory BIOS) and X200 (gm45 raminit code in coreboot), to see what the differences are. Then tweak raminit code based on that.

Trouble undocking (button doesn't work)
.......................................

This person seems to have a workaround: https://github.com/the-unconventional/libreboot-undock

LCD compatibility list
......................

LCD panel list (X200 panels listed there): http://www.thinkwiki.org/wiki/TFT_display

All LCD panels for the X200, X200S and X200 Tablet are known to work.

X200 Adapted from https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X200

Look at wikipedia for difference between TN and IPS panels. IPS have much better colour/contrast than a regular TN, and will typically have good viewing angles.

These seem to be from the X200 tablet. You need to find one without the glass touchscreen protection on it (might be able to remove it, though). It also must not have a digitizer on it (again, might be possible to just simply remove the digitizer).

  * BOE-Hydis HV121WX4-120, HV121WX4-110 or HV121WX4-100 - cheap-ish, might be hard to find

  * Samsung LTN121AP02-001 - common to find, cheap

If your X200 has an LED backlit panel in it, then you also need to get an inverter and harness cable that is compatible with the CCFL panels. To see which panel type you have, see led_howtotell. If you need the inverter/cable, here are part numbers: 44C9909 for CCFL LVDS cable with bluetooth and camera connections, and 42W8009 or 42W8010 for the inverter.

There are glossy and matte versions of these. Matte means anti-glare, which is what you want (in this authors opinion).

Refer to the HMM (hardware maintenance manual) for how to replace the screen.

Sources:

  * ThinkPad Forums - Matte AFFS Panel on X200 (http://forum.thinkpads.com/viewtopic.php?f=2&t=84941)

  * ThinkPad Forums - Parts for X200 AFFS Mod (http://forum.thinkpads.com/viewtopic.php?p=660662#p660662)

  * ThinkWiki.de - X200 Displayumbau (http://thinkwiki.de/X200_Displayumbau) (achtung: du musst lesen und/oder spreche deutsch; oder ein freund fur hilfe)

http://forum.thinkpads.com/viewtopic.php?p=618928#p618928 explains that the X200S screens/assemblies are thinner. You need to replace the whole lid with one from a normal X200/X201.

Some X200s have a CCFL backlight and some have an LED backlight, in their LCD panel. This also means that the inverters will vary, so you must be careful if ever replacing either the panel and/or inverter. (a CCFL inverter is high-voltage and will destroy an LED backlit panel).

CCFLs contain mercury. An X200 with a CCFL backlight will (unless it has been changed to an LED, with the correct inverter. Check with your supplier!) the following: "This product contains Lithium Ion Battery, Lithium Battery and a lamp which contains mercury; dispose according to local, state or federal laws" (one with an LED backlit panel will say something different).

The coreboot wiki shows (http://www.coreboot.org/Motherboard_Porting_Guide) how to collect various logs useful in porting to new boards. Following are outputs from the X200:

  * BIOS 3.15, EC 1.06

       * x200_dumps/ (../misc/dumps/x200/)

Not all memory modules work. Most of the default ones do, but you have to be careful when upgrading to 8GiB; some modules work, some don't.

This page (http://www.forum.thinkpads.com/viewtopic.php?p=760721) might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)

pehjota started collecting some steppings for different CPUs on several X200 laptops. You can get the CPUID by running:
 $ dmesg | sed -n 's/^.* microcode: CPU0 sig=0x\([^,]*\),.*$/\1/p'

What pehjota wrote: The laptops that have issues resuming from suspend, as well as a laptop that (as I mentioned earlier in #libreboot) won't boot with any Samsung DIMMs, all have CPUID 0x10676 (stepping M0).

What pehjota wrote: Laptops with CPUID 0x167A (stepping R0) resume properly every time and work with Samsung DIMMs. I'll need to do more testing on more units to better confirm these trends, but it looks like the M0 microcode is very buggy. That would also explain why I didn't have issues with Samsung DIMMs with the Lenovo BIOS (which would have microcode updates). I wonder if VT-x works on R0.

What pehjota wrote: As I said, 10676 is M0 and 1067A is R0; those are the two CPUIDs and steppings for Intel Core 2 Duo P8xxx CPUs with factory microcode. (1067 is the family and model, and 6 or A is the stepping ID.)

TODO: check the CPUIDs and test S3 resume and/or KVM on any C2D systems (including non-P8xxx ones, which I don't have here) you have available. I'd be curious if you could confirm these results. It might not be coreboot that's buggy with raminit/S3; it might just be down to the microcode updates.

<sgsit> do you know if it's possible to flash thinkpads over the LPC debug connector at the front edge?
<sgsit> that would make life much easier for systems like this
<sgsit> all the Wistron manufactured systems have this thing called a "golden finger", normally at the front edge of the board
<sgsit> you can plug a board in which gives diagnostic codes but i'm wondering whether it is capable of more
<sgsit> http://www.endeer.cz/bios.tools/bios.html

Lenovo ThinkPad R400
....................

It is believed that all or most R400 laptops are compatible. See notes about CPU compatibility for potential incompatibilities.

There are two possible flash chip sizes for the R400: 4MiB (32Mbit) or 8MiB (64Mbit). This can be identified by the type of flash chip below the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.

The R400 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see gm45_remove_me (contains notes, plus instructions).

Flashing instructions can be found at flashrom.

  * Hardware virtualization vt-x The R400, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower).

     On GM45 hardware (with libreboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU.

     The following errata datasheet from Intel might help with investigation: http://download.intel.com/design/mobile/specupdt/320121.pdf

The R400 is almost identical to the X200, code-wise. See x200.

TODO: put hardware register logs here like on the X200 (x200.html) and T400 (t400.html) page.

Not all LCD panels are compatible yet. See gm45_lcd.

Lenovo ThinkPad T400
....................

It is believed that all or most T400 laptops are compatible. See notes about CPU compatibility for potential incompatibilities.

There are two possible flash chip sizes for the T400: 4MiB (32Mbit) or 8MiB (64Mbit). This can be identified by the type of flash chip below the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.

The T400 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see gm45_remove_me (contains notes, plus instructions)

Flashing instructions can be found at flashrom.

  * Hardware virtualization vt-x

     The T400, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower).

     On GM45 hardware (with libreboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU.

     The following errata datasheet from Intel might help with investigation: http://download.intel.com/design/mobile/specupdt/320121.pdf

     The T400 is almost identical to the X200, code-wise. See x200.

Not all LCD panels are compatible yet. See gm45_lcd.

The coreboot wiki shows (http://www.coreboot.org/Motherboard_Porting_Guide) how to collect various logs useful in porting to new boards. Following are outputs from the T400:

  * T400 with Winbond W25X64 flash chip (8MiB, SOIC-16) and Lenovo BIOS 2.02 (EC firmware 1.01):

       * logs-t400-bios2.02-ex1.01 (../misc/dumps/logs-t400-bios2.02-ec1.01/)

  * Version of flashrom used for the external flashing/reading logs is the one that libreboot git revision c164960 uses.

Lenovo ThinkPad T500
....................

It is believed that all or most T500 laptops are compatible. See notes about CPU compatibility for potential incompatibilities.

There are two possible flash chip sizes for the T500: 4MiB (32Mbit) or 8MiB (64Mbit). This can be identified by the type of flash chip below the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.

The T500 laptops come with the ME (and sometimes AMT in addition) before flashing libreboot. Libreboot disables and removes it by using a modified descriptor: see gm45_remove_me (contains notes, plus instructions)

Flashing instructions can be found at flashrom.

  * Hardware virtualization vt-x

     The T500, when run without CPU microcode updates in coreboot, currently kernel panics if running QEMU with vt-x enabled on 2 cores for the guest. With a single core enabled for the guest, the guest panics (but the host is fine). Working around this in QEMU might be possible; if not, software virtualization should work fine (it's just slower).

     On GM45 hardware (with libreboot), make sure that the kvm and kvm_intel kernel modules are not loaded, when using QEMU.

     The following errata datasheet from Intel might help with investigation: http://download.intel.com/design/mobile/specupdt/320121.pdf

     The T500 is almost identical to the X200, code-wise. See x200.

Not all LCD panels are compatible yet. See gm45_lcd.

See descriptor_diff_t500_x200.txt (../misc/dumps/t500_x200_descriptor/descriptor_diff_t500_x200.txt) and gbe_diff_t500_x200.txt (../misc/dumps/t500_x200_descriptor/gbe_diff_t500_x200.txt).

The patches above are based on the output from ich9deblob on a factory.rom image dumped from the T500 with a SOIC-8 4MiB flash chip. The patch re-creates the X200 descriptor/gbe source, so the commands were something like:
 $ diff -u t500gbe x200gbe
 $ diff -u t500descriptor x200descriptor

ME VSCC table is in a different place and a different size on the T500. Libreboot disables and removes the ME anyway, so it doesn't matter.

The very same descriptor/gbe used on the X200 (generated by ich9gen) was re-used on the T500, and it still worked.

The coreboot wiki shows (http://www.coreboot.org/Motherboard_Porting_Guide) how to collect various logs useful in porting to new boards. Following are outputs from the T500:

  * T500 with Macronix MX25L3205D flash chip (4MiB, SOIC-8) and Lenovo BIOS 3.13 7VET83WW (EC firmware 1.06):

       * t500log/ (../misc/dumps/t500log/)

Information about the macbook1,1
................................

There is an Apple laptop called the macbook1,1 from 2006 which uses the same i945 chipset as the ThinkPad X60/T60. A developer ported the MacBook21 to coreboot, the ROM images also work on the macbook1,1.

You can refer to MacBook21 for most of this. Macbook2,1 laptops come with Core 2 Duo processors which support 64-bit operating systems (and 32-bit). The MacBook1,1 uses Core Duo processors (supports 32-bit OS but not 64-bit), and it is believed that this is the only difference.

It is believed that all models are compatible, listed here:

  * http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook1

Specifically (Order No. / Model No. / CPU):

  * MA255LL/A / A1181 (EMC 2092) / Core Duo T2500 (tested - working)

  * MA254LL/A / A1181 (EMC 2092) / Core Duo T2400 (tested - working)

  * MA472LL/A / A1181 (EMC 2092) / Core Duo T2500 (untested)

Also of interest: config_macbook21.

Unbricking: this page shows disassembly guides (https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono's page (see MacBook21) shows the location of the SPI flash chip on the motherboard. How to remove the motherboard (https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529).

No method is yet known for flashing in GNU/Linux while the Apple firmware is running. You will need to disassemble the system and flash externally. Reading from flash seems to work. For external flashing, refer to bbb_setup.

Information about the macbook2,1
................................

There is an Apple laptop called the macbook2,1 from late 2006 or early 2007 that uses the same i945 chipset as the ThinkPad X60 and ThinkPad T60. A developer ported coreboot to their macbook2,1, and now libreboot can run on it.

Mono Moosbart is the person who wrote the port for macbook2,1. Referenced below are copies (up to date at the time of writing, 20140630) of the pages that this person wrote when porting coreboot to the macbook2,1. They are included here in case the main site goes down for whatever reason, since they include a lot of useful information.

Backups created using wget:
 $ wget -m -p -E -k -K -np http://macbook.donderklumpen.de/
 $ wget -m -p -E -k -K -np http://macbook.donderklumpen.de/coreboot/
 Use -e robots=off if using this trick for other sites and the site restricts using robots.txt

Links to wget backups (and the backups themselves) of Mono's pages (see above) removed temporarily. Mono has given me permission to distribute them, but I need to ask this person to tell me what license these works fall under first. Otherwise, the above URLs should be fine. NOTE TO SELF: REMOVE THIS WHEN DONE

  * Parabola GNU/Linux installation on a macbook2,1 with Apple EFI firmware (this is a copy of Mono's page, see above)

How to boot an ISO: burn it to a CD (like you would normally) and hold down the Alt/Control key while booting. The bootloader will detect the GNU/Linux CD as 'Windows' (because Apple doesn't think GNU/Linux exists). Install it like you normally would. When you boot up again, hold Alt/Control once more. The installation (on the HDD) will once again be seen as 'Windows'. (it's not actually Windows, but Apple likes to think that Apple and Microsoft are all that exist.) Now to install libreboot, follow flashrom_macbook21.

  * Coreboot on the macbook2,1 (this is a copy of Mono's page, see above)

  * http://www.coreboot.org/Board:apple/macbook21

It is believed that all models are compatible, listed here:

  * http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook2

Specifically (Order No. / Model No. / CPU):

  * MA699LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T5600 (tested - working)

  * MA701LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 (tested - working)

  * MB061LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7200 (untested)

  * MA700LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 (tested - working)

  * MB063LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 (works)

  * MB062LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 (tested - working)

Also of interest: config_macbook21.

Unbricking: this page shows disassembly guides (https://www.ifixit.com/Device/MacBook_Core_2_Duo) and mono's page (see above) shows the location of the SPI flash chip on the motherboard. How to remove the motherboard (https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529).

For external flashing, refer to bbb_setup.

You need to replace OS X with GNU/Linux before flashing libreboot. (OSX won't run at all in libreboot).

There are some issues with this system (compared to other computers that libreboot supports):

This is an apple laptop, so it comes with OS X: it has an Apple keyboard, which means that certain keys are missing: insert, del, home, end, pgup, pgdown. There is also one mouse button only. Battery life is poor compared to X60/T60 (for now). It also has other issues: for example, the Apple logo on the back is a hole, exposing the backlight, which means that it glows. You should cover it up.

The system does get a bit hotter compared to when running the original firmware. It is certainly hotter than an X60/T60. The heat issues have been partially fixed by the following patch (now merged in libreboot): http://review.coreboot.org/#/c/7923/.

The MacBook2,1 comes with a webcam, which does not work without proprietary software. Also, webcams are a security risk; cover it up! Or remove it.

A user reported that they could get better response from the touchpad with the following in their xorg.conf:

Section "InputClass"
 Identifier "Synaptics Touchpad"
 Driver "synaptics"
 MatchIsTouchpad "on"
 MatchDevicePath "/dev/input/event*"
 Driver "synaptics"
# The next two values determine how much pressure one needs
# for tapping, moving the cursor and other events.
 Option "FingerLow" "10"
 Option "FingerHigh" "15"
# Do not emulate mouse buttons in the touchpad corners.
 Option "RTCornerButton" "0"
 Option "RBCornerButton" "0"
 Option "LTCornerButton" "0"
 Option "LBCornerButton" "0"
# One finger tap = left-click
 Option "TapButton1" "1"
# Two fingers tap = right-click
 Option "TapButton2" "3"
# Three fingers tap = middle-mouse
 Option "TapButton3" "2"
# Try to not count the palm of the hand landing on the touchpad
# as a tap. Not sure if helps.
 Option "PalmDetect" "1"
# The following modifies how long and how fast scrolling continues
# after lifting the finger when scrolling
 Option "CoastingSpeed" "20"
 Option "CoastingFriction" "200"
# Smaller number means that the finger has to travel less distance
# for it to count as cursor movement. Larger number prevents cursor
# shaking.
 Option "HorizHysteresis" "10"
 Option "VertHysteresis" "10"
# Prevent two-finger scrolling. Very jerky movement
 Option "HorizTwoFingerScroll" "0"
 Option "VertTwoFingerScroll" "0"
# Use edge scrolling
 Option "HorizEdgeScroll" "1"
 Option "VertEdgeScroll" "1"
EndSection

A user reported that the above is only for linux kernel 3.15 or lower. For newer kernels, the touchpad works fine out of the box, except middle tapping.

A user submitted a utility to enable 3-finger tap on this laptop. It's available at resources/utilities/macbook21-three-finger-tap in the libreboot git repository. The script is for GNOME, confirmed to work in Trisquel 7.

Recommended wifi chipsets
-------------------------

The following are known to work well:

  * Atheros AR5B95 (http://h-node.org/search/results/en/1/search/wifi/ar9285) (chipset: Atheros AR9285); mini PCI-E. Most of these are half-height, so you will need a half>full height mini PCI express adapter/bracket.

  * Atheros AR928X (http://h-node.org/wifi/view/en/116/Atheros-Communications-Inc--AR928X-Wireless-Network-Adapter--PCI-Express---rev-01-) chipset; mini PCI-E. Most of these are half-height, so you will need a half>full height mini PCI express adapter/bracket

  * Unex DNUA-93F (chipset: Atheros AR9271 (http://h-node.org/search/results/en/1/search/wifi/ar9271)); USB.

  * Any of the chipsets listed at https://www.fsf.org/resources/hw/endorsement/respects-your-freedom

  * Any of the chipsets listed at http://h-node.org/wifi/catalogue/en/1/1/undef/undef/yes?

The following was mentioned (on IRC), but it's unknown to the libreboot project if these work with linux-libre kernel (TODO: test):

  * ar5bhb116 ar9382 ABGN

  * [0200]: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:001c]

GM45 chipsets: remove the ME (manageability engine)
---------------------------------------------------

This sections relates to disabling and removing the ME (Intel Management Engine) on GM45. This was originally done on the ThinkPad X200, and later adapted for the ThinkPad R400/T400/T500. It can in principle be done on any GM45 or GS45 system.

The ME is a blob that typically must be left inside the flash chip (in the ME region, as outlined by the default descriptor). On GM45, it is possible to remove it without any ill effects. All other parts of coreboot on GM45 systems (provided GMA MHD4500 / Intel graphics) can be blob-free, so removing the ME was the last obstacle to make GM45 a feasible target in libreboot (the systems can also work without the microcode blobs).

The ME is removed and disabled in libreboot by modifying the descriptor. More info about this can be found in the ich9deblob/ich9gen source code in resources/utilities/ich9deblob/ in libreboot, or more generally on this page.

More information about the ME can be found at http://www.coreboot.org/Intel_Management_Engine and http://me.bios.io/Main_Page.

Another project recently found: http://io.smashthestack.org/me/

ICH9 gen utility
................

It is no longer necessary to use ich9deblob to generate a deblobbed descriptor+gbe image for GM45 targets. ich9gen is a small utility within ich9deblob that can generate them from scratch, without a factory.bin dump.

If you are using src or git, build ich9gen from source with:
 $ ./build module ich9deblob
 The executable will appear under resources/utilities/ich9deblob/

Building from the _util directory is done in much the same way.

Run:
 $ ./ich9gen

Running ich9gen this way (without any arguments) generates a default descriptor+gbe image with a generic MAC address. You probably don't want to use the generic one; the ROM images in libreboot contain a descriptor+gbe image by default (already inserted) just to prevent or mitigate the risk of bricking your laptop, but with the generic MAC address (the libreboot project does not know what your real MAC address is).

You can find out your MAC address from ip addr or ifconfig in GNU/Linux. Alternatively, if you are running libreboot already (with the correct MAC address in your ROM), dump it (flashrom -r) and read the first 6 bytes from position 0x1000 (or 0x2000) in a hex editor (or, rename it to factory.rom and run it in ich9deblob: in the newly created mkgbe.c will be the individual bytes of your MAC address). If you are currently running the stock firmware and haven't installed libreboot yet, you can also run that through ich9deblob to get the mac address.

An even simpler way to get the MAC address would be to read what's on the little sticker on the bottom/base of the laptop.

On GM45 laptops that use flash descriptors, the MAC address or the onboard ethernet chipset is flashed (inside the ROM image). You should generate a descriptor+gbe image with your own MAC address inside (with the Gbe checksum updated to match). Run:
 $ ./ich9gen --macaddress XX:XX:XX:XX:XX:XX
 (replace the XX chars with the hexadecimal chars in the MAC address that you want)

Two new files will be created:

  * ich9fdgbe_4m.bin: this is for GM45 laptops with the 4MB flash chip.

  * ich9fdgbe_8m.bin: this is for GM45 laptops with the 8MB flash chip.

  * ich9fdgbe_16m.bin:  this is for GM45 laptops with the 16MB flash chip.

Assuming that your libreboot image is named libreboot.rom, copy the file to where libreboot.rom is located and then insert the descriptor+gbe file into the ROM image.  For 16MiB flash chips:
 $ dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=1 count=12k conv=notrunc
 For 8MiB flash chips:
 $ dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=1 count=12k conv=notrunc
 For 4MiB flash chips:
 $ dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=1 count=12k conv=notrunc

Your libreboot.rom image is now ready to be flashed on the system. Refer back to flashrom. for how to flash it.

Write-protecting the flash chip
...............................

Look in resources/utilities/ich9deblob/src/descriptor/descriptor.c for the following lines in the descriptorHostRegionsUnlocked function:

   descriptorStruct.masterAccessSection.flMstr1.fdRegionWriteAccess = 0x1;
   descriptorStruct.masterAccessSection.flMstr1.biosRegionWriteAccess = 0x1;
   descriptorStruct.masterAccessSection.flMstr1.meRegionWriteAccess = 0x1;
   descriptorStruct.masterAccessSection.flMstr1.gbeRegionWriteAccess = 0x1;
   descriptorStruct.masterAccessSection.flMstr1.pdRegionWriteAccess = 0x1;

Also look in resources/utilities/ich9deblob/src/ich9gen/mkdescriptor.c for the following lines:

    descriptorStruct.masterAccessSection.flMstr1.fdRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */
    descriptorStruct.masterAccessSection.flMstr1.biosRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */
    descriptorStruct.masterAccessSection.flMstr1.meRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */
    descriptorStruct.masterAccessSection.flMstr1.gbeRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */
    descriptorStruct.masterAccessSection.flMstr1.pdRegionWriteAccess = 0x1; /* see ../descriptor/descriptor.c */

NOTE: When you write-protect the flash chip, re-flashing is no longer possible unless you use dedicated external equipment, which also means disassembling the laptop. The same equipment can also be used to remove the write-protection later on, if you choose to do so. *Only* write-protect the chip if you have the right equipment for external flashing later on; for example, see bbb_setup.

Change them all to 0x0, then re-compile ich9gen. After you have done that, follow the notes in ich9gen to generate a new descriptor+gbe image and insert that into your ROM image, then flash it. The next time you boot, the flash chip will be read-only in software (hardware re-flashing will still work, which you will need for re-flashing the chip after write-protecting it, to clear the write protection or to flash yet another ROM image with write protection set in the descriptor).

Flashrom will tell you that you can still forcefully re-flash, using -p internal:ich_spi_force=yes but this won't actually work; it'll just brick your laptop.

For external flashing guides, refer to Installation.

ICH9 deblob utility
...................

This is no longer strictly necessary. Libreboot ROM images for GM45 systems now contain the 12KiB descriptor+gbe generated from ich9gen, by default.

This was the tool originally used to disable the ME on X200 (later adapted for other systems that use the GM45 chipset). ich9gen now supersedes it; ich9gen is better because it does not rely on dumping the factory.rom image (whereas, ich9deblob does).

This is what you will use to generate the deblobbed descriptor+gbe regions for your libreboot ROM image.

If you are working with libreboot_src (or git), you can find the source under resources/utilities/ich9deblob/ and will already be compiled if you ran ./build module all or ./build module ich9deblob from the main directory (./), otherwise you can build it like so:
 $ ./build module ich9deblob
 An executable file named ich9deblob will now appear under resources/utilities/ich9deblob/

Place the factory.rom from your system (can be obtained using the external flashing guides for GM45 targets linked, see Installation) in the directory where you have your ich9deblob executable, then run the tool:
 $ ./ich9deblob

A 12kiB file named deblobbed_descriptor.bin will now appear. Keep this and the factory.rom stored in a safe location! The first 4KiB contains the descriptor data region for your system, and the next 8KiB contains the gbe region (config data for your gigabit NIC). These 2 regions could actually be separate files, but they are joined into 1 file in this case.

A 4KiB file named deblobbed_4kdescriptor.bin will alternatively appear, if no GbE region was detected inside the ROM image. This is usually the case, when a discrete NIC is used (eg Broadcom) instead of Intel. Only the Intel NICs need a GbE region in the flash chip.

Assuming that your libreboot image is named libreboot.rom, copy the deblobbed_descriptor.bin file to where libreboot.rom is located and then run:
 $ dd if=deblobbed_descriptor.bin of=libreboot.rom bs=1 count=12k conv=notrunc

Alternatively, if you got a the deblobbed_4kdescriptor.bin file (no GbE defined), do this: $ dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=1 count=4k conv=notrunc

The utility will also generate 4 additional files:

  * mkdescriptor.c

  * mkdescriptor.h

  * mkgbe.c

  * mkgbe.h

These are C source files that can re-generate the very same Gbe and Descriptor structs (from ich9deblob/ich9gen). To use these, place them in src/ich9gen/ in ich9deblob, then re-build. The newly built ich9gen executable will be able to re-create the very same 12KiB file from scratch, based on the C structs, this time without the need for a factory.rom dump!

You should now have a libreboot.rom image containing the correct 4K descriptor and 8K gbe regions, which will then be safe to flash. Refer back to flashrom. for how to flash it.

demefactory utility
...................

This takes a factory.rom dump and disables the ME/TPM, but leaves the region intact. It also sets all regions read-write.

The ME interferes with flash read/write in flashrom, and the default descriptor locks some regions. The idea is that doing this will remove all of those restrictions.

Simply run (with factory.rom in the same directory):
 $ ./demefactory

It will generate a 4KiB descriptor file (only the descriptor, no GbE). Insert that into a factory.rom image (NOTE: do this on a copy of it. Keep the original factory.rom stored safely somewhere):
 $ dd if=demefactory_4kdescriptor.bin of=factory_nome.rom bs=1 count=4k conv=notrunc

TODO: test this.
 TODO: lenovobios (GM45 thinkpads) still write-protects parts of the flash. Modify the assembly code inside. Note: the factory.rom (BIOS region) from lenovobios is in a compressed format, which you have to extract. bios_extract upstream won't work, but the following was said in #coreboot on freenode IRC:

<roxfan> vimuser: try bios_extract with ffv patch http://patchwork.coreboot.org/patch/3444/
<roxfan> or https://github.com/coreboot/bios_extract/blob/master/phoenix_extract.py
<roxfan> what are you looking for specifically, btw?

0x74: 0x9fff03e0 PR0: Warning: 0x003e0000-0x01ffffff is read-only.
0x84: 0x81ff81f8 PR4: Warning: 0x001f8000-0x001fffff is locked.

Use-case: a factory.rom image modified in this way would theoretically have no flash protections whatsoever, making it easy to quickly switch between factory/libreboot in software, without ever having to disassemble and re-flash externally unless you brick the device.

demefactory is part of the ich9deblob src, found at resources/utilities/ich9deblob/

Notes
.....

The sections below are adapted from (mostly) IRC logs related to early development getting the ME removed on GM45. They are useful for background information. This could not have been done without sgsit's help.

Early notes
...........

  * http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf page 230 mentions about descriptor and non-descriptor mode (which wipes out gbe and ME/AMT).

  * textstrikeout{See reference to HDA_SDO (disable descriptor security)} strap connected GPIO33 pin is it on ICH9-M (X200). HDA_SDO applies to later chipsets (series 6 or higher). Disabling descriptor security also disables the ethernet according to sgsit. sgsit's method involves use of 'soft straps' (see IRC logs below) instead of disabling the descriptor.

  * and the location of GPIO33 on the x200s: (was an external link. Putting it here instead) ../useinstallimages/x200/gpio33_location.jpg - it's above the number 7 on TP37 (which is above the big intel chip at the bottom)

  * The ME datasheet may not be for the mobile chipsets but it doesn't vary that much. This one gives some detail and covers QM67 which is what the X201 uses: http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf

Flash chips
...........

  * Schematics for X200 laptop: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf textstrikeout{- Page 20 and page 9 refer to SDA_HDO or SDA_HDOUT} only on series 6 or higher chipsets. ICH9-M (X200) does it with a strap connected to GPIO33 pin (see IRC notes below)
      - According to page 29, the X200 can have any of the following flash chips:

       * ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip

       * MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb (4MiB) chip

       * MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb (8MiB) chip

       * Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip

     sgsit says that the X200s with the 64Mb flash chips are (probably) the ones with AMT (alongside the ME), whereas the 32Mb chips contain only the ME.

  * Schematics for X200s laptop: http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf.

Early development notes
.......................

Start (hex) End (hex)   Length (hex)    Area Name
----------- ---------   ------------    ---------
00000000    003FFFFF    00400000    Flash Image

00000000    00000FFF    00001000    Descriptor Region
00000004    0000000F    0000000C        Descriptor Map
00000010    0000001B    0000000C        Component Section
00000040    0000004F    00000010        Region Section
00000060    0000006B    0000000C        Master Access Section
00000060    00000063    00000004            CPU/BIOS
00000064    00000067    00000004            Manageability Engine (ME)
00000068    0000006B    00000004            GbE LAN
00000100    00000103    00000004        ICH Strap 0
00000104    00000107    00000004        ICH Strap 1
00000200    00000203    00000004        MCH Strap 0
00000EFC    00000EFF    00000004        Descriptor Map 2
00000ED0    00000EF7    00000028        ME VSCC Table
00000ED0    00000ED7    00000008            Flash device 1
00000ED8    00000EDF    00000008            Flash device 2
00000EE0    00000EE7    00000008            Flash device 3
00000EE8    00000EEF    00000008            Flash device 4
00000EF0    00000EF7    00000008            Flash device 5
00000F00    00000FFF    00000100        OEM Section
00001000    001F5FFF    001F5000    ME Region
001F6000    001F7FFF    00002000    GbE Region
001F8000    001FFFFF    00008000    PDR Region
00200000    003FFFFF    00200000    BIOS Region

Start (hex) End (hex)   Length (hex)    Area Name
----------- ---------   ------------    ---------
00000000    003FFFFF    00400000    Flash Image

00000000    00000FFF    00001000    Descriptor Region
00000004    0000000F    0000000C        Descriptor Map
00000010    0000001B    0000000C        Component Section
00000040    0000004F    00000010        Region Section
00000060    0000006B    0000000C        Master Access Section
00000060    00000063    00000004            CPU/BIOS
00000064    00000067    00000004            Manageability Engine (ME)
00000068    0000006B    00000004            GbE LAN
00000100    00000103    00000004        ICH Strap 0
00000104    00000107    00000004        ICH Strap 1
00000200    00000203    00000004        MCH Strap 0
00000ED0    00000EF7    00000028        ME VSCC Table
00000ED0    00000ED7    00000008            Flash device 1
00000ED8    00000EDF    00000008            Flash device 2
00000EE0    00000EE7    00000008            Flash device 3
00000EE8    00000EEF    00000008            Flash device 4
00000EF0    00000EF7    00000008            Flash device 5
00000EFC    00000EFF    00000004        Descriptor Map 2
00000F00    00000FFF    00000100        OEM Section
00001000    00002FFF    00002000    GbE Region
00003000    00202FFF    00200000    BIOS Region

Build Settings
--------------
Flash Erase Size = 0x1000

It's a utility called 'Flash Image Tool' for ME 4.x that was used for this. You drag a complete image into in and the utility decomposes the various components, allowing you to set soft straps.

This tool is proprietary, for Windows only, but was used to deblob the X200. End justified means, and the utility is no longer needed since the ich9deblob utility (documented on this page) can now be used to create deblobbed descriptors.

GBE (gigabit ethernet) region in SPI flash
..........................................

Of the 8K, about 95% is 0xFF. The data is the gbe region is fully documented in this public datasheet: http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf

The only actual content found was:

00  1F  1F  1F  1F  1F  00  08  FF  FF  83  10  FF  FF  FF  FF
08  10  FF  FF  C3  10  EE  20  AA  17  F5  10  86  80  00  00
01  0D  00  00  00  00  05  06  20  30  00  0A  00  00  8B  8D
02  06  40  2B  43  00  00  00  F5  10  AD  BA  F5  10  BF  10
AD  BA  CB  10  AD  BA  AD  BA  00  00  00  00  00  00  00  00
00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
00  01  00  40  28  12  07  40  FF  FF  FF  FF  FF  FF  FF  FF
FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  FF  D9  F0
20  60  1F  00  02  00  13  00  00  80  1D  00  FF  00  16  00
DD  CC  18  00  11  20  17  00  DD  DD  18  00  12  20  17  00
00  80  1D  00  00  00  1F

The first part is the MAC address set to all 0x1F. It's repeated haly way through the 8K area, and the rest is all 0xFF. This is all documented in the datasheet.

The GBe region starts at 0x20A000 bytes from the *end* of a factory image and is 0x2000 bytes long. In libreboot (deblobbed) the descriptor is set to put gbe directly after the initial 4K flash descriptor. So the first 4K of the ROM is the descriptor, and then the next 8K is the gbe region.

GBE region: change MAC address
..............................

According to the datasheet, it's supposed to add up to 0xBABA but can actually be others on the X200. https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums

"One of those engineers loves classic rock music, so they selected 0xBABA"

In honour of the song Baba O'Reilly by The Who apparently. We're not making this stuff up...

0x3ABA, 0x34BA, 0x40BA and more have been observed in the main Gbe regions on the X200 factory.rom dumps. The checksums of the backup regions match BABA, however.

By default, the X200 (as shipped by Lenovo) actually has an invalid main gbe checksum. The backup gbe region is correct, and is what these systems default to. Basically, you should do what you need on the *backup* gbe region, and then correct the main one by copying from the backup.

Look at resources/utilities/ich9deblob/ich9deblob.c.

  * Add the first 0x3F 16bit numbers (unsigned) of the GBe descriptor together (this includes the checksum value) and that has to add up to 0xBABA. In other words, the checksum is 0xBABA minus the total of the first 0x3E 16bit numbers (unsigned), ignoring any overflow.

Flash descriptor region
.......................

http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf from page 850 onwards. This explains everything that is in the flash descriptor, which can be used to understand what libreboot is doing about modifying it.

How to deblob:

  * patch the number of regions present in the descriptor from 5 - 3

  * originally descriptor + bios + me + gbe + platform

  * modified = descriptor + bios + gbe

  * the next stage is to patch the part of the descriptor which defines the start and end point of each section

  * then cut out the gbe region and insert it just after the region

  * all this can be substantiated with public docs (ICH9 datasheet)

  * the final part is flipping 2 bits. Halting the ME via 1 MCH soft strap and 1 ICH soft strap

  * the part of the descriptor described there gives the base address and length of each region (bits 12:24 of each address)

  * to disable a region, you set the base address to 0xFFF and the length to 0

  * and you change the number of regions from 4 (zero based) to 2

There's an interesting parameter called 'ME Alternate disable', which allows the ME to only handle hardware errata in the southbridge, but disables any other functionality. This is similar to the 'ignition' in the 5 series and higher but using the standard firmware instead of a small 128K version. Useless for libreboot, though.

To deblob GM45, you chop out the platform and ME regions and correct the addresses in flReg1-4. Then you set meDisable to 1 in ICHSTRAP0 and MCHSTRAP0.

How to patch the descriptor from the factory.rom dump

  * map the first 4k into the struct (minus the gbe region)

  * set NR in FLMAP0 to 2 (from 4)

  * adjust BASE and LIMIT in flReg1,2,3,4 to reflect the new location of each region (or remove them in the case of Platform and ME)

  * set meDisable to 1/true in ICHSTRAP0 and MCHSTRAP0

  * extract the 8k GBe region and append that to the end of the 4k descriptor

  * output the 12k concatenated chunk

  * Then it can be dd'd into the first 12K part of a coreboot image.

  * the GBe region always starts 0x20A000 bytes from the end of the ROM

This means that libreboot's descriptor region will simply define the following regions:

  * descriptor (4K)

  * gbe (8K)

  * bios (rest of flash chip. CBFS also set to occupy this whole size)

The data in the descriptor region is little endian, and it represents bits 24:12 of the address (bits 12-24, written this way since bit 24 is nearer to left than bit 12 in the binary representation).

So, x << 12 = address

If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F.

platform data partition in boot flash (factory.rom / lenovo bios)
.................................................................

Basically useless for libreboot, since it appears to be a blob. Removing it didn't cause any issues in libreboot.

This is a 32K region from the factory image. It could be data (non-functional) that the original Lenovo BIOS used, but we don't know.

It has only a 448 byte fragment different from 0x00 or 0xFF.

LCD compatibility on GM45 laptops
---------------------------------

On the T400 and T500 (maybe others), some of the higher resolution panels (e.g. 1440x900, 1680x1050, 1920x1200) fail in libreboot.

All X200/X200S/X200T LCD panels are believed to be compatible.

The problem
...........

In some cases, backlight turns on during boot, sometimes not. In all cases, no display is shown in GRUB, nor in GNU/Linux.

Current workaround
..................

Libreboot (git, and releases after 20150518) now automatically detect whether to use single or dual link LVDS configuration. If you're using an older version, use the instructions below. In practise, this means that you'll get a visual display when booting GNU/Linux, but not in GRUB (payload).

The i915 module in the Linux kernel also provides an option to set the LVDS link configuration. i915.lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int) - from /sbin/modinfo i915 - use i915.lvds_channel_mode=2 as a kernel option in grub.cfg.

Differences in dmesg (kernel parameter added)
.............................................

https://01.org/linuxgraphics/documentation/how-report-bugs

These panels all work in the original firmware, so the idea is to see what differences there are in how coreboot handles them.

dmesg with coreboot-libre (http://www.coreboot.org/pipermail/coreboot/attachments/20150712/d2e214bb/attachment-0002.txt) (coreboot) - See: [drm:intel_lvds_init] detected single-link lvds configuration

dmesg with lenovobios (http://www.coreboot.org/pipermail/coreboot/attachments/20150712/d2e214bb/attachment-0003.txt) (lenovobios) - For the same line, it says dual-channel lvds configuration.

EDID
....

One T500 had a screen (1920x1200) that is currently incompatible. Working to fix it. EDID:

user@user-ThinkPad-T500:~/Desktop$ sudo i2cdump -y 2 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX ff ff ff ff ff ff 00 30 ae 55 40 00 00 00 00    X.......0?U@....
10: 00 11 01 03 80 21 15 78 ea ba 70 98 59 52 8c 28    .????!?x??p?YR?(
20: 25 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    %PT...??????????
30: 01 01 01 01 01 01 e7 3a 80 8c 70 b0 14 40 1e 50    ???????:??p??@?P
40: 24 00 4b cf 10 00 00 19 16 31 80 8c 70 b0 14 40    $.K??..??1??p??@
50: 1e 50 24 00 4b cf 10 00 00 19 00 00 00 0f 00 d1    ?P$.K??..?...?.?
60: 0a 32 d1 0a 28 11 01 00 32 0c 00 00 00 00 00 fe    ?2??(??.2?.....?
70: 00 4c 50 31 35 34 57 55 31 2d 54 4c 42 31 00 9a    .LP154WU1-TLB1.?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

What happens: backlight turns on at boot, then turns off. At no point is there a working visual display.

Another incompatible screen (EDID) 1680 x 1050 with the same issue:

EDID:
00 ff ff ff ff ff ff 00 30 ae 53 40 00 00 00 00
00 11 01 03 80 21 15 78 ea cd 75 91 55 4f 8b 26
21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 a8 2f 90 e0 60 1a 10 40 20 40
13 00 4b cf 10 00 00 19 b7 27 90 e0 60 1a 10 40
20 40 13 00 4b cf 10 00 00 19 00 00 00 0f 00 b3
0a 32 b3 0a 28 14 01 00 4c a3 50 33 00 00 00 fe
00 4c 54 4e 31 35 34 50 33 2d 4c 30 32 0a 00 7e
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   30 ae 53 40 00 00 00 00 00 11
version:         01 03
basic params:    80 21 15 78 ea
chroma info:     cd 75 91 55 4f 8b 26 21 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    a8 2f 90 e0 60 1a 10 40 20 40 13 00 4b cf 10 00 00 19
descriptor 2:    b7 27 90 e0 60 1a 10 40 20 40 13 00 4b cf 10 00 00 19
descriptor 3:    00 00 00 0f 00 b3 0a 32 b3 0a 28 14 01 00 4c a3 50 33
descriptor 4:    00 00 00 fe 00 4c 54 4e 31 35 34 50 33 2d 4c 30 32 0a
extensions:      00
checksum:        7e

Manufacturer: LEN Model 4053 Serial Number 0
Made week 0 of 2007
EDID version: 1.3
Digital display
Maximum image size: 33 cm x 21 cm
Gamma: 220%
Check DPMS levels
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: a82f90e0601a1040204013004bcf10000019
Did detailed timing
Detailed mode (IN HEX): Clock 122000 KHz, 14b mm x cf mm
               0690 06b0 06f0 0770 hborder 0
               041a 041b 041e 042a vborder 0
               -hsync -vsync
Hex of detail: b72790e0601a1040204013004bcf10000019
Detailed mode (IN HEX): Clock 122000 KHz, 14b mm x cf mm
               0690 06b0 06f0 0770 hborder 0
               041a 041b 041e 042a vborder 0
               -hsync -vsync
Hex of detail: 0000000f00b30a32b30a281401004ca35033
Manufacturer-specified data, tag 15
Hex of detail: 000000fe004c544e31353450332d4c30320a
ASCII string: LTN154P3-L02
Checksum
Checksum: 0x7e (valid)
WARNING: EDID block does NOT fully conform to EDID 1.3.
        Missing name descriptor
        Missing monitor ranges
bringing up panel at resolution 1680 x 1050
Borders 0 x 0
Blank 224 x 16
Sync 64 x 3
Front porch 32 x 1
Spread spectrum clock
Single channel
Polarities 1, 1
Data M1=2132104, N1=8388608
Link frequency 270000 kHz
Link M1=236900, N1=524288
Pixel N=9, M1=24, M2=8, P1=1
Pixel clock 243809 kHz
waiting for panel powerup
panel powered up

Another incompatible (T400) screen:

No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX ff ff ff ff ff ff 00 30 ae 33 40 00 00 00 00    X.......0?3@....
10: 00 0f 01 03 80 1e 13 78 ea cd 75 91 55 4f 8b 26    .??????x??u?UO?&
20: 21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    !PT...??????????
30: 01 01 01 01 01 01 b0 27 a0 60 51 84 2d 30 30 20    ???????'?`Q?-00
40: 36 00 2f be 10 00 00 19 d5 1f a0 40 51 84 1a 30    6./??..????@Q??0
50: 30 20 36 00 2f be 10 00 00 19 00 00 00 0f 00 90    0 6./??..?...?.?
60: 0a 32 90 0a 28 14 01 00 4c a3 42 44 00 00 00 fe    ?2??(??.L?BD...?
70: 00 4c 54 4e 31 34 31 57 44 2d 4c 30 35 0a 00 32    .LTN141WD-L05?.2
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

For comparison, here is a working display (T400 screen, but was connected to a T500. Some T500 displays also work, but no EDID available on this page yet):

EDID:
00 ff ff ff ff ff ff 00 30 ae 31 40 00 00 00 00
00 12 01 03 80 1e 13 78 ea b3 85 95 58 53 8a 28
25 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 26 1b 00 7d 50 20 16 30 30 20
36 00 30 be 10 00 00 18 8b 16 00 7d 50 20 16 30
30 20 36 00 30 be 10 00 00 18 00 00 00 0f 00 81
0a 32 81 0a 28 14 01 00 30 e4 28 01 00 00 00 fe
00 4c 50 31 34 31 57 58 33 2d 54 4c 52 31 00 d8
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   30 ae 31 40 00 00 00 00 00 12
version:         01 03
basic params:    80 1e 13 78 ea
chroma info:     b3 85 95 58 53 8a 28 25 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    26 1b 00 7d 50 20 16 30 30 20 36 00 30 be 10 00 00 18
descriptor 2:    8b 16 00 7d 50 20 16 30 30 20 36 00 30 be 10 00 00 18
descriptor 3:    00 00 00 0f 00 81 0a 32 81 0a 28 14 01 00 30 e4 28 01
descriptor 4:    00 00 00 fe 00 4c 50 31 34 31 57 58 33 2d 54 4c 52 31
extensions:      00
checksum:        d8

Manufacturer: LEN Model 4031 Serial Number 0
Made week 0 of 2008
EDID version: 1.3
Digital display
Maximum image size: 30 cm x 19 cm
Gamma: 220%
Check DPMS levels
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 261b007d502016303020360030be10000018
Did detailed timing
Detailed mode (IN HEX): Clock 69500 KHz, 130 mm x be mm
               0500 0530 0550 057d hborder 0
               0320 0323 0329 0336 vborder 0
               -hsync -vsync
Hex of detail: 8b16007d502016303020360030be10000018
Detailed mode (IN HEX): Clock 69500 KHz, 130 mm x be mm
               0500 0530 0550 057d hborder 0
               0320 0323 0329 0336 vborder 0
               -hsync -vsync
Hex of detail: 0000000f00810a32810a2814010030e42801
Manufacturer-specified data, tag 15
Hex of detail: 000000fe004c503134315758332d544c5231
ASCII string: LP141WX3-TLR1
Checksum
Checksum: 0xd8 (valid)
WARNING: EDID block does NOT fully conform to EDID 1.3.
        Missing name descriptor
        Missing monitor ranges
bringing up panel at resolution 1280 x 800
Borders 0 x 0
Blank 125 x 22
Sync 32 x 6
Front porch 48 x 3
Spread spectrum clock
Single channel
Polarities 1, 1
Data M1=1214600, N1=8388608
Link frequency 270000 kHz
Link M1=134955, N1=524288
Pixel N=10, M1=14, M2=11, P1=1
Pixel clock 138857 kHz
waiting for panel powerup
panel powered up

Another compatible T400 screen:

trisquel@trisquel:~$ sudo i2cdump -y 2 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 30 ae 31 40 00 00 00 00    ........0?1@....
10: 00 12 01 03 80 1e 13 78 ea b3 85 95 58 53 8a 28    .??????x????XS?(
20: 25 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    %PT...??????????
30: 01 01 01 01 01 01 26 1b 00 7d 50 20 16 30 30 20    ??????&?.}P ?00
40: 36 00 30 be 10 00 00 18 8b 16 00 7d 50 20 16 30    6.0??..???.}P ?0
50: 30 20 36 00 30 be 10 00 00 18 00 00 00 0f 00 81    0 6.0??..?...?.?
60: 0a 32 81 0a 28 14 01 00 30 e4 28 01 00 00 00 fe    ?2??(??.0?(?...?
70: 00 4c 50 31 34 31 57 58 33 2d 54 4c 52 31 00 d8    .LP141WX3-TLR1.?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

Installing libreboot
====================

This section relates to installing libreboot on supported targets.

NOTE: if running flashrom -p internal for software based flashing, and you get an error related to /dev/mem access, you should reboot with iomem=relaxed kernel parameter before running flashrom, or use a kernel that has CONFIG_STRICT_DEVMEM not enabled.

Software methods
----------------

List of ROM images in libreboot
...............................

Libreboot distributes pre-compiled ROM images, built from the libreboot source code. These images are provided for user convenience, so that they don't have to build anything from source on their own.

The ROM images in each archive use the following at the end of the file name, if they are built with the GRUB payload: _keymap_mode.rom

Available modes: vesafb or txtmode. The vesafb ROM images are recommended, in most cases; txtmode ROM images come with MemTest86+, which requires text-mode instead of the usual framebuffer used by coreboot native graphics initialization.

keymap can be one of several keymaps that keyboard supports (there are quite a few), which affects the keyboard layout configuration that is used in GRUB. It doesn't matter which ROM image you choose here, as far as the keymap in GNU/Linux is concerned.

Keymaps are named appropriately according to each keyboard layout support in GRUB. To learn how these keymaps are created, see grub_keyboard.

ROM images for QEMU
...................

Libreboot comes with ROM images built for QEMU, by default:

Examples of how to use libreboot ROM images in QEMU:

  * $ qemu-system-i386 -M q35 -m 512 -bios qemu_q35_ich9_keymap_mode.rom

  * $ qemu-system-i386 -M pc -m 512 -bios qemu_i440fx_piix4_keymap_mode.rom

You can optionally specify the -serial stdio argument, so that QEMU will emulate a serial terminal on the standard input/output (most likely your terminal emulator or TTY).

Other arguments are available for QEMU. The manual will contain more information.

How to update or install libreboot (if you are already running libreboot or coreboot)
.....................................................................................

On all current targets, updating libreboot can be accomplished without disassembly and, therefore, without having to externally re-flash using any dedicated hardware. In other words, you can do everything entirely in software, directly from the OS that is running on your libreboot system.

If you are using libreboot_src or git, then make sure that you built the sources first (see build).

Look at the list of ROM images to see which image is compatible with your device.

If you are currently running the proprietary firmware (not libreboot or coreboot), then the flashing instructions for your system are going to be different.

X60/T60 users running the proprietary firmware should refer to flashrom_lenovobios. MacBook2,1 users running Apple EFI should refer to flashrom_macbook21.

X200 users, refer to x200_external, R400 users refer to r400_external, T400 users refer to t400_external, T500 users refer to t500_external.

Internal flashing should work just fine, even if you are currently booting the proprietary firmware.

Libreboot currently lacks documentation for externally re-flashing an LPC flash chip. However, these boards have the flash chip inside of a PLCC socket, and it is possible to hot-swap the chips. If you want to back up your known-working image, simply hot-swap the chip for one that is the same capacity, after having dumped a copy of the current firmware (flashrom -p internal -r yourchosenname.rom), and then flash that chip with the known-working image. Check whether the system still boots, and if it does, then it should be safe to flash the new image (because you now have a backup of the old image).

Keeping at least one spare LPC PLCC chip with working firmware on it is highly recommended, in case of bricks.

DO NOT hot-swap the chip with your bare hands. Use a PLCC chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

Do check the HCL entry: kfsn4-dre-hcl.

If you have the proprietary BIOS, you need to flash libreboot externally. See kgpe-d16.

If you already have coreboot or libreboot installed, without write protection on the flash chip, then you can do it in software (otherwise, see link above).

DO NOT hot-swap the chip with your bare hands. Use a PDIP-8 chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

Do check the HCL entry: kgpe-d16-hcl.

If you have the proprietary BIOS, you need to flash libreboot externally. See kcma-d8.

If you already have coreboot or libreboot installed, without write protection on the flash chip, then you can do it in software (otherwise, see link above).

DO NOT hot-swap the chip with your bare hands. Use a PDIP-8 chip extractor. These can be found online. See http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools

Do check the HCL entry: kcma-d8-hcl

X60/T60 users should be fine with this guide. If you write-protected the flash chip, please refer to x60_unbrick, x60tablet_unbrick or t60_unbrick. This probably does not apply to you. Most people do not write-protect the flash chip, so you probably didn't either.

Similarly, it is possible to write-protect the flash chip in coreboot or libreboot on GM45 laptops (X200/R400/T400/T500). If you did this, then you will need to use the links above for flashing, treating your laptop as though it currently has the proprietary firmware (because write-protected SPI flash requires external re-flashing, as is also the case when running the proprietary firmware).

If you did not write-protect the flash chip, or it came to you without any write-protection (libreboot does not write-protect the flash chip by default, so this probably applies to you), read on!

Users of the X200/R400/T400/T500 take note: The MAC address for the onboard ethernet chipset is located inside the flash chip. Libreboot ROM images for these laptops contain a generic MAC address by default (00:F5:F0:40:71:FE), but this is not what you want. Make sure to change the MAC address inside the ROM image, before flashing it. The instructions on ich9gen show how to do this.

It is important that you change the default MAC address, before flashing. It will be printed on a sticker at the bottom of the laptop, or it will be printed on a sticker next to or underneath the RAM. Alternatively, and assuming that your current firmware has the correct MAC address in it, you can get it from your OS.

Use this to find out:
 # dmidecode | grep ROM\ Size

Excellent! Moving on...

How to update the flash chip contents:
 $ sudo ./flash update yourrom.rom

Ocassionally, coreboot changes the name of a given board. If flashrom complains about a board mismatch, but you are sure that you chose the correct ROM image, then run this alternative command:
 $ sudo ./flash forceupdate yourrom.rom

You should see "Verifying flash... VERIFIED." written at the end of the flashrom output. Shut down after you see this, and then boot up again after a few seconds.

ThinkPad X60/T60: Initial installation guide (if running the proprietary firmware)
..................................................................................

This is for the ThinkPad X60 and T60 while running Lenovo BIOS. If you already have coreboot or libreboot running, then go to flashrom instead!

If you are flashing a Lenovo ThinkPad T60, be sure to read supported_t60_list

If you are using libreboot_src or git, then make sure that you built the sources first (see build).

Warning: this guide will not instruct the user how to backup the original Lenovo BIOS firmware. These backups are tied to each system, and will not work on any other. For that, please refer to http://www.coreboot.org/Board:lenovo/x60/Installation.

If you're using libreboot 20150518, note that there is a mistake in the flashing script. do this: rm -f patch && wget -O flash http://git.savannah.gnu.org/cgit/libreboot.git/plain/flash?id=910b212e90c6f9c57025e1c7b0c08897af787496 && chmod +x flash

The first half of the procedure is as follows:
 $ sudo ./flash i945lenovo_firstflash yourrom.rom.

You should see within the output the following:
 "Updated BUC.TS=1 - 64kb address ranges at 0xFFFE0000 and 0xFFFF0000 are swapped".

You should also see within the output the following:
 "Your flash chip is in an unknown state", "FAILED" and "DO NOT REBOOT OR POWEROFF"
 Seeing this means that the operation was a resounding success! DON'T PANIC.

See this link for more details: http://thread.gmane.org/gmane.linux.bios.flashrom/575.

If the above is what you see, then SHUT DOWN. Wait a few seconds, and then boot; libreboot is running, but there is a 2nd procedure *needed* (see below).

When you have booted up again, you must also do this:
 $ sudo ./flash i945lenovo_secondflash yourrom.rom

If flashing fails at this stage, try the following:
 $ sudo ./flashrom/i686/flashrom -p internal:laptop=force_I_want_a_brick -w yourrom.rom

You should see within the output the following:
 "Updated BUC.TS=0 - 128kb address range 0xFFFE0000-0xFFFFFFFF is untranslated"

You should also see within the output the following:
 "Verifying flash... VERIFIED."

MacBook2,1: Initial installation guide (if running the proprietary firmware)
............................................................................

If you have a MacBook1,1, refer to macbook1-1 for flashing instructions.

This is for the MacBook2,1 while running Apple EFI firmware. If you already have coreboot or libreboot running, then go to flashrom instead!

Be sure to read the information in macbook2-1.

Warning: this guide will not instruct the user how to backup the original Apple EFI firmware. For that, please refer to http://www.coreboot.org/Board:apple/macbook21.

If you are using libreboot_src or git, then make sure that you built the sources first (see build).

Look at the list of ROM images to see which image is compatible with your device.

Use this flashing script, to install libreboot:
 $ sudo ./flash i945apple_firstflash yourrom.rom

You should also see within the output the following:
 "Verifying flash... VERIFIED."

Shut down.

ASUS Chromebook C201 installation guide
.......................................

These instructions are for installing Libreboot to the ASUS Chromebook C201. Since the device ships with Coreboot, the installation instructions are the same before and after flashing Libreboot for the first time.

If you are using libreboot_src or git, then make sure that you built the sources first (see build).

Look at the list of ROM images to see which image is compatible with your device.

Libreboot can be installed internally from the device, with sufficient privileges. The installation process requires using Google's modified version of flashrom, that has support for reflashing the Chromebook's SPI flash. Otherwise, flashing externally will work with the upstream flashrom version.

Google's modified version of flashrom is free software and its source code is made available by Google: flashrom (https://chromium.googlesource.com/chromiumos/third_party/flashrom/).
 It is not distributed along with Libreboot yet. However, it is preinstalled on the device, with ChromeOS.

Installing Libreboot internally requires sufficient privileges on the system installed on the device.
 When the device has ChromeOS installed (as it does initially), it is necessary to gain root privileges in ChromeOS, to be able to access a root shell.

In order to gain root privileges on ChromeOS, developer mode has to be enabled from the recovery mode screen and debugging features have to be enabled in ChromeOS.

Instructions to access the recovery mode screen and enabling developer mode are available on the page dedicated to depthcharge.

Once developer mode is enabled, the device will boot to the developer mode screen. ChromeOS can be booted by waiting for 30 seconds (the delay is shortened in Libreboot) or by pressing Ctrl + D

After the system has booted, root access can be enabled by clicking on the Enable debugging features link. A confirmation dialog will ask whether to proceed.
 After confirming by clicking Proceed, the device will reboot and ask for the root password to set. Finally, the operation has to be confirmed by clicking Enable.

After setting the root password, it becomes possible to log-in as root. A tty prompt can be obtained by pressing Ctrl + Alt + Next. The Next key is the one on the top left of the keyboard.

Before installing Libreboot on the device, both its software and hardware has to be prepared to allow the installation procedure and to ensure that security features don't get in the way.

It is recommended to have access to the developer mode screen and to configure the following verified boot parameters:

  * Kernels signature verification: disabled

  * External media boot: enabled

Those changes can be reverted later, when the device is known to be in a working state.

Since part of the SPI flash is write-protected by a screw, it is necessary to remove the screw to remove the write protection and allow writing Libreboot to the read-only part of the flash.

To access the screw, the device has to be opened. There are 8 screws to remove from the bottom of the device, as shown on the picture below. Two are hidden under the top pads. After removing the screws, the keyboard plastic part can be carefully detached from the rest. Beware: there are cables attached to it! It is advised to flip the keyboard plastic part over, as shown on the picture below. The write protect screw is located next to the SPI flash chip, circled in red in the picture below. It has to be removed.

Screws (../useinstallimages/c201/screws.jpg) WP screw (../useinstallimages/c201/wp-screw.jpg)

The write protect screw can be put back in place later, when the device is known to be in a working state.

The SPI flash (that holds Libreboot) is divided into various partitions that are used to implement parts of the CrOS security system. Libreboot is installed in the read-only coreboot partition, that becomes writable after removing the write-protect screw.

Before installing Libreboot to the SPI flash internally, the device has to be reassembled.

All the files from the veyron_speedy release (or build) have to be transferred to the device.

The following operations have to be executed with root privileges on the device (e.g. using the root account). In addition, the cros-flash-replace script has to be made executable:
 # chmod a+x cros-flash-replace

The SPI flash has to be read first:
 # flashrom -p host -r flash.img
 Note: it might be a good idea to copy the produced flash.img file at this point and store it outside of the device for backup purposes.

Then, the cros-flash-replace script has to be executed as such:
 # ./cros-flash-replace flash.img coreboot ro-frid
 If any error is shown, it is definitely a bad idea to go further than this point.

If you are getting "./cros-flash-replace: Permission denied" error, it might be that ChromeOS automatically mounts your drive with noexec flag for security reasons. You can check if your device is mounted noexec:
 # mount -l
 Manually re-mounting the device solves the problem (replace /dev/sda1 with correct partition path and /mnt with desired mount point:
 # umount /dev/sda1 && mount /dev/sda1 /mnt

The resulting flash image can then be flashed back:
 # flashrom -p host -w flash.img

You should also see within the output the following:
 "Verifying flash... VERIFIED."

Shut down. The device will now boot to Libreboot.

Before installing Libreboot to the SPI flash internally, the device has to be opened.

The SPI flash is located next to the write protect screw. Its layout is indicated in the picture below. Note that it is not necessary to connect WP# since removing the screw already connects it to ground. Before writing to the chip externally, the battery connector has to be detached. It is located under the heat spreader, that has to be unscrewed from the rest of the case. The battery connector is located on the right and has colorful cables, as shown on the picture below.

SPI flash layout (../useinstallimages/c201/spi-flash-layout.jpg) Battery connector (../useinstallimages/c201/battery-connector.jpg)

All the files from the veyron_speedy release (or build) have to be transferred to the host.

The following operations have to be executed with root privileges on the host (e.g. using the root account). In addition, the cros-flash-replace script has to be made executable:
 # chmod a+x cros-flash-replace

The SPI flash has to be read first (using the right spi programmer):
 # flashrom -p programmer -r flash.img
 Note: it might be a good idea to copy the produced flash.img file at this point and store it outside of the device for backup purposes.

Then, the cros-flash-replace script has to be executed as such:
 # ./cros-flash-replace flash.img coreboot ro-frid
 If any error is shown, it is definitely a bad idea to go further than this point.

The resulting flash image can then be flashed back (using the right spi programmer):
 # flashrom -p programmer -w flash.img

You should also see within the output the following:
 "Verifying flash... VERIFIED."

The device will now boot to Libreboot.

Disabling the developer mode resets the verified boot parameters to:

  * Kernels signature verification: disabled

  * External media boot: disabled

If you have installed a custom kernel to external device, and wiped the internal device, it may cause your device to be bricked if you disable the developer mode (by pressing space at boot screen). Make sure your custom kernel resides on internal device before disabling the developer mode, or do not disable it at all until you know everyhing works fine.

However if you have mistakenly disabled developer mode and locked yourself out, Google's recovery image can still be of use. See this (https://lists.nongnu.org/archive/html/libreboot/2016-06/msg00021.html) post on mailing list. If that did not help, the final solution would be using SPI flash programmer.

Hardware methods
----------------

How to program an SPI flash chip with the BeagleBone Black or Teensy 3.1
........................................................................

This document exists as a guide for reading from or writing to an SPI flash chip with the BeagleBone Black, using the flashrom (http://flashrom.org/Flashrom) software.  A BeagleBone Black, rev. C was used when creating this guide, but earlier revisions may also work.

There was no justification for a further section for the Teensy. Simply refer to this page on flashrom.org (https://www.flashrom.org/Teensy_3.1_SPI_%2B_LPC/FWH_Flasher#ISP_Usage) for information about how to set it up, and correlate that with the pins on the SPI flash chip as per other guides in the libreboot documentation for each board. At the time of writing, the teensy is tested for flashing on the ThinkPad X200, but it should work for other targets. here is a photo of the setup for Teensy: http://h5ai.swiftgeek.net/IMG_20160601_120855.jpg.

Onto the BeagleBone black...

Shopping list (pictures of this hardware is shown later):

  * A Flashrom (http://flashrom.org)-compatible external SPI programmer: BeagleBone Black, sometimes referred to as 'BBB', (rev. C) is highly recommended.  You can buy one from Adafruit (https://www.adafruit.com) (USA), Electrokit (http://electrokit.com) (Sweden) or any of the distributors listed here (http://beagleboard.org/black) (look below 'Purchase').  We recommend this product because we know that it works well for our purposes and doesn't require any non-free software.

  * Electrical/insulative tape: cover the entire bottom surface of the BBB (the part that rests on a surface).  This is important, when placing the BBB on top of a board so that nothing shorts.  Most hardware/electronics stores have this.  Optionally, you can use the bottom half of a hammond plastic enclosure (http://www.hammondmfg.com/1593HAM.htm#BeagleBoneBlack).

  * Clip for connecting to the flash chip: if you have a SOIC-16 flash chip (16 pins), you will need the Pomona 5252 or equivalent.  For SOIC-8 flash chips (8 pins), you will need the Pomona 5250 or equivalent.  Do check which chip you have, before ordering a clip.  Also, you might as well buy two clips or more since they break easily.  Farnell element 14 (http://farnell.com/) sells these and ships to many countries.  Some people find these clips difficult to get hold of, especially in South America.  If you know of any good suppliers, please contact the libreboot project with the relevant information.  If you can't get hold of a pomona clip, some other clips might work, e.g. 3M, but they are not always reliable.  You can also directly solder the wires to the chip, if that suits you; the clip is just for convenience, really.

  * External 3.3V DC power supply, for powering the flash chip: an ATX power supply / PSU (common on Intel/AMD desktop computers) will work for this.  A lab PSU (DC) will also work (adjusted to 3.3V).

       * Getting a multimeter might be worthwhile, to verify that it's supplying 3.3V.

  * External 5V DC power supply (barrel connector), for powering the BBB: the latter can have power supplied via USB, but a dedicated power supply is recommended.  These should be easy to find in most places that sell electronics.  OPTIONAL. Only needed if not powering with the USB cable, or if you want to use EHCI debug.

  * Pin header / jumper cables (2.54mm / 0.1" headers): you should get male--male, male--female and female--female cables in 10cm size.  Just get a load of them.  Other possible names for these cables/wires/leads are

       * flying leads

       * dupont (or other brand names)

       * breadboard cables (since they are often used on breadboards).

     Adafruit (https://www.adafruit.com) sell them, as do many others.  Some people find them difficult to buy.  Please contact the libreboot project if you know of any good sellers.  You might also be able to make these cables yourself.  For PSU connections, using long cables, e.g. 20cm, is fine, and you can extend them longer than that if needed.

  * Mini USB A-B cable: the BBB probably already comes with one.  OPTIONAL---only needed for EHCI debug or for serial/SSH access without ethernet cable (g_multi kernel module).

  * FTDI TTL cable or debug board: used for accessing the serial console on the BBB.  This page (http://elinux.org/Beagleboard:BeagleBone_Black_Serial) contains a list.  OPTIONAL---only needed for serial console on the BBB, if not using SSH via ethernet cable.

ATX PSU pinouts can be read on this Wikipedia page (https://en.wikipedia.org/wiki/Power_supply_unit_%28computer%29#Wiring_diagrams).

You can use pin 1 or 2 (orange wire) on a 20-pin or 24-pin ATX PSU for 3.3V, and any of the ground/earth sources (black cables) for ground.  Short PS_ON# / Power on (green wire; pin 16 on 24-pin ATX PSU, or pin 14 on a 20-pin ATX PSU) to a ground (black; there is one right next to it) using a wire/paperclip/jumper, then power on the PSU by grounding PS_ON# (this is also how an ATX motherboard turns on a PSU).

DO **NOT** use pin 4, 6, do **NOT** use pin 19 or 20 (on a 20-pin ATX PSU), and DO **NOT** use pin 21, 22 or 23 (on a 24-pin ATX PSU).  Those wires (the red ones) are 5V, and they **WILL** kill your flash chip.  ***NEVER*** supply more than 3.3V to your flash chip (that is, if it's a 3.3V flash chip; 5V and 1.8V SPI flash chips do exist, but they are rare.  Always check what voltage your chip takes.  Most of them take 3.3V).

You only need one 3.3V supply and one ground for the flash chip, after grounding PS_ON#.

The male end of a 0.1" or 2.54mm header cable is not thick enough to remain permanently connected to the ATX PSU on its own. When connecting header cables to the connector on the ATX PSU, use a female end attached to a thicker piece of wire (you could use a paper clip), or wedge the male end of the jumper cable into the sides of the hole in the connector, instead of going through the centre.

Here is an example set up:

The operating system on your BBB will probably have an SSH daemon running where the root account has no password. Use SSH to access the operating system and set a root password. By default, the OS on your BBB will most likely use DHCP, so it should already have an IP address.

You will also be using the OS on your BBB for programming an SPI flash chip.

  * Alternatives to SSH in case SSH fails::

     You can also use a serial FTDI debug board with GNU Screen, to access the serial console.
      # screen /dev/ttyUSB0 115200
      Here are some example photos:

     You can also connect the USB cable from the BBB to another computer and a new network interface will appear, with its own IP address. This is directly accessible from SSH, or screen:
      # screen /dev/ttyACM0 115200

     You can also access the uboot console, using the serial method instead of SSH.

Log on as root on the BBB, using either SSH or a serial console as defined in bbb_access. Make sure that you have internet access on your BBB.

Follow the instructions at http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0 up to (and excluding) the point where it tells you to modify uEnv.txt

You need to update the software on the BBB first. If you have an element14 brand BBB (sold by Premier Farnell plc. stores like Farnell element14, Newark element14, and Embest), you may need to work around a bug (https://groups.google.com/forum/?_escaped_fragment_=msg/beagleboard/LPjCn4LEY2I/alozBGsbTJMJ#!msg/beagleboard/LPjCn4LEY2I/alozBGsbTJMJ) in the LED aging init script before you can update your software. If you don't have a file named /etc/init.d/led_aging.sh, you can skip this step and update your software as described below. Otherwise, replace the contents of this file with:

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          led_aging.sh
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start LED aging
# Description:       Starts LED aging (whatever that is)
### END INIT INFO

x=$(/bin/ps -ef | /bin/grep "[l]ed_acc")
if [ ! -n "$x" -a -x /usr/bin/led_acc ]; then
    /usr/bin/led_acc &
fi

Run apt-get update and apt-get upgrade then reboot the BBB, before continuing.

Check that the firmware exists:
 # ls /lib/firmware/BB-SPI0-01-00A0.*
 Output:

/lib/firmware/BB-SPI0-01-00A0.dtbo

Then:
 # echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots
 # cat /sys/devices/bone_capemgr.*/slots
 Output:

 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0-01

Verify that the spidev device now exists:
 # ls -al /dev/spid*
 Output:

crw-rw---T 1 root spi 153, 0 Nov 19 21:07 /dev/spidev1.0

Now the BBB is ready to be used for flashing. Make this persist across reboots:
 In /etc/default/capemgr add CAPE=BB-SPI0-01 at the end (or change the existing CAPE= entry to say that, if an entry already exists.

Finally, get the ROM image that you would like to flash and put that on your BBB.

Now test flashrom:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
 Output:

Calibrating delay loop... OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

This means that it's working (the clip isn't connected to any flash chip, so the error is fine).

Use this image for reference when connecting the pomona to the BBB: http://beagleboard.org/Support/bone101#headers (D0 = MISO or connects to MISO).

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):

 NC              -       - 21
 1               -       - 17
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 18              -       - 3.3V (PSU)
 22              -       - NC - this is pin 1 on the flash chip
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

You may also need to connect pins 1 and 9 (tie to 3.3V supply). These are HOLD# and WP#.
On some systems they are held high, if the flash chip is attached to the board.
If you're flashing a chip that isn't connected to a board, you'll almost certainly
have to connect them.

SOIC16 pinout (more info available online, or in the datasheet for your flash chip):
HOLD    1-16    SCK
VDD 2-15    MOSI
N/C 3-14    N/C
N/C 4-13    N/C
N/C 5-12    N/C
N/C 6-11    N/C
SS  7-10    GND
MISO    8-9 WP

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):

 18              -       - 1
 22              -       - NC
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

You may also need to connect pins 3 and 7 (tie to 3.3V supply). These are HOLD# and WP#.
On some systems they are held high, if the flash chip is attached to the board.
If you're flashing a chip that isn't connected to a board, you'll almost certainly
have to connect them.

SOIC8 pinout (more info available online, or in the datasheet for your flash chip):
SS  1-8 VDD
MISO    2-7 HOLD
WP  3-6 SCK
GND 4-5 MOSI

NC = no connection

DO NOT connect 3.3V (PSU) yet. ONLY connect this once the pomona is connected to the flash chip.

You also need to connect the BLACK wire (ground/earth) from the 3.3V PSU to pin 2 on the BBB (P9 header). It is safe to install this now (that is, before you connect the pomona to the flash chip); in fact, you should.

if you need to extend the 3.3v psu leads, just use the same colour M-F leads, but keep all other leads short (10cm or less)

You should now have something that looks like this:

http://flashrom.org/ISP is what we typically do in libreboot, though not always. That page has some notes about using resistors to affect stability. Currently, we use spispeed=512 (512kHz) but it is possible to use higher speeds while maintaining stability.

tty0_ in #libreboot was able to get better flashing speeds with the following configuration:

  * "coax" with 0.1 mm core and aluminum foley (from my kitchen), add 100 Ohm resistors (serial)

  * put heatshrink above the foley, for: CS, CLK, D0, D1

  * Twisted pair used as core (in case more capacitors are needed)

  * See this image: http://i.imgur.com/qHGxKpj.jpg

  * He was able to flash at 50MHz (lower speeds are also fine).

GA-G41M-ES2L flashing tutorial
..............................

This guide is for those who want libreboot on their Intel GA-G41M-ES2L motherboard while they still have the original BIOS present.

Flash chip size
...............

Use this to find out:
 # dmidecode | grep ROM\ Size

Flashing instructions - GA-G41M-ES2L
....................................

Refer to bbb_setup for how to set up the BBB for flashing it externally, if you want to do that.

Here is an image of the flash chip:

Internal flashing is possible. Boot with proprietary BIOS and GNU/Linux, and run the latest version of flashrom. This board has 2 flash chips, one is a backup.

Flash the first chip: ./flashrom -p internal:dualbiosindex=0 -w libreboot.rom

Flash the second chip: ./flashrom -p internal:dualbiosindex=1 -w libreboot.rom

NOTE: You need the latest version of flashrom. Just grab it on flashrom.org from their SVN or Git repos.

That's all!

NOTE: There is a hardcoded MAC address for this board, due to a bug in the hardware. The factory BIOS worked around this per board, but in libreboot we don't. You will need to set the MAC address yourself, in your operating system.

Do refer to the compatibility page for more information about this board.

Flashing Intel D510MO
.....................

D510MO flashing tutorial

This guide is for those who want libreboot on their Intel D510MO motherboard while they still have the original BIOS present.

Use this to find out:
 # dmidecode | grep ROM\ Size

Use this image for reference, then refer to bbb_setup for how to set up the BBB for flashing it.

Do refer to the compatibility page for more information about this board.

EHCI debugging on the BeagleBone Black
......................................

If your computer does not boot after installing libreboot, it is very useful to get debug logs from it, from the payload (grub) and/or the kernel (if gets to there). All of them stream debug logs on the available serial (RS-232) by default. However, most of todays laptops lack RS-232 port. The other option is to stream the logs to USB EHCI debug port.

This section explains step-by-step how to setup BBB as a ``USB EHCI debug dongle'' and configure libreboot and the linux kernel to stream logs to it (TODO: grub).

I will refer to three computers:

  * host - this is the computer you use, have tools, compiler, Internet, etc

  * BBB - Beaglebone Black (rev. B or higher, i use rev. C)

  * target - the computer you are trying to install liberboot

Not all USB controllers support EHCI debug (see: EHCI Debug Port (http://www.coreboot.org/EHCI_Debug_Port#Hardware_capability) ). Even more, if a USB controller supports EHCI debug, it is available only on a single port that might or might not be exposed externally.

  * You need running OS (GNU/Linux) on your target for this step (If you've flashed libreboot and it does not boot, you have to flush back the stock bios)

  * You need USB memory stick (the data on it will not be touched).

  * The EHCI debugging can not be done through external hub, BBB must be connected directly to the debug port of the controller (so, no hubs)

  * Download see 1, this (http://www.coreboot.org/pipermail/coreboot/attachments/20080909/ae11c291/attachment.sh) shell script.

 1. Plug the usb stick in the first available usb port

 2. Run the script, you will get output similar to following:

 3. The buses the support debug are Bus 3 (0000:00:1a.0) on Port 1 and Bus 4 (0000:00:1d.0) on port 2. Your usb stick is plugged on Bus 1, Port 3

 4. Repeat the steps, plugging the USB stick in the next available port

 5. Go through all available ports and remember(write down) those for which bus/port of the usb stick matches one of the bus/port that support debug (bold).

Remember (write down) for each port (external plug) you found that supports debug: PCI device id, the bus id, the port number, and the physical location of the usb plug.

If you do not find a match, you can not get debug over EHCI. Sorry.

The guys from coreboot were talking about including the script in coreboot distribution (check the status).

BBB must be powered with a barrel power connector since the mini-B USB plug will be used for the EHCI debug stream. So you will need:

  * power supply (5V, 2A(10W) is sufficient).

  * an extra usb cable: A to mini-B

(On BBB) The linux kernel includes module (g_dbgp that enables one of the usb ports on a computer to behave as EHCI debug dongle. Make sure you have this module available on your BBB (Debian 7.8 that comes with BBB should have it), if not, you should compile it yourself (see next section):

ls /lib/modules/3.8.13-bone70/kernel/drivers/usb/gadget/g_dbgp.ko

Unload all other g_* modules:

# lsmod
# rmmod g_multi
...

Then load g_dbgp :

# modprobe g_dbgp
# lsmod # should show that g_dbgp is loaded, and no other g_*

Plug the mini-B side of the USB cable in your BBB and the A side in your target. Then one of the usb devices on your target (with lsusb ) should be:

Bus 001 Device 024: ID 0525:c0de Netchip Technology, Inc.

If you see the device on the target, you are good to continue to the next step.

For the reasons why you need this, see: EHCI Gadget Debug (http://www.coreboot.org/EHCI_Gadget_Debug).
Make sure that you have cross compiling environment for arm-linux-gnueabihf setup on your host.

  * On BBB: uname -r - this will give you version number like 3.8.13-bone70 (I will refer to this as: $mav.$miv-$lv: where mav=3.8, miv=13, lv=bone70

  * Get the BBB kernel ready on your host for cross-compiling:

$ cd $work_dir
$ git clone https://github.com/beagleboard/kernel.git
$ cd kernel
$ git checkout $mav (see above)
$ ./patch.sh
$ wget http://arago-project.org/git/projects/?p=am33x-cm3.git\;a=blob_plain\;f=bin/am335x-pm-firmware.bin\;hb=HEAD -O kernel/firmware/am335x-pm-firmware.bin
$ cp configs/beaglebone kernel/arch/arm/configs/beaglebone_defconfig

  * Download the patch from here (http://www.coreboot.org/images/8/88/Ehci-debug-gadget-patches.tar.gz)

  * tar -xf Ehci-debug-gadget-patches.tar.gz (will create dir: usbdebug-gadget)

  * Note that there are two patches (patch_1 and patch_2) for each of the two different version of the kernel (3.8 and 3.10). I will use 3.8. (If using kernel 3.12 patch_1 is not needed)

  * cd kernel (note that this is one more level: you should be in $work_dir/kernel/kernel)

  * Apply the patches:

git apply ../usbdebug-gadget/v3.8-debug-gadget/0001-usb-dbgp-gadget-Fix-re-connecting-after-USB-disconne.patch
git apply ../usbdebug-gadget/v3.8-debug-gadget/0002-usb-serial-gadget-no-TTY-hangup-on-USB-disconnect-WI.patch
;
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- beaglebone_defconfig -j4@

  * You should also apply the linux-libre deblob script to turn it into linux-libre (deletes all the blobs from the linux kernel). fsfla website (http://www.fsfla.org/ikiwiki/selibre/linux-libre/) - see scripts (http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/).

  * Get your current BBB kernel config (from: /boot/config-<ver>) and copy it to your host as $work_dir/kernel/kernel/.config

  * Set proper version number:

       * On your host, edit $work_dir/kernel/kernel/.config (the one you've just copied from BBB), find the line CONFIG_LOCALVERSION="<something or empty>" and change it to CONFIG_LOCALVERSION="-$lv", so it will look something like: CONFIG_LOCALVERSION="-bone70"

  * Also, make sure that: CONFIG_USB_G_DBGP=m (If not, make menuconfig, and set @Device Drivers-> USB Support -> USB Gadget Support -> EHCI Debug Device Gadget=m

  * Build the module:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 (is it possoble to build only the gadget modules)
$ mkdir ../tmp && make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=../tmp modules_install

  * on BBB, backup /lib/modules/3.8.13-bone70/kernel/drivers/usb/gadget (i.e. mv /lib/modules/3.8.13-bone70/kernel/drivers/usb/gadget $HOME)

  * copy the freshly compiled usb/gadget dir to /lib/modules/3.8.13-bone70/kernel/drivers/usb

  * restart BBB

  * Remove all g_* modules (rmmod g_<>)

  * modprobpe g_dbgp

Libreboot(coreboot) should be configured with debug turned on and to push debug messages to the EHCI debug port.
If you've downloaded the binary distribution, you can check if it is properly configured in the following way:

  * Go to the libreboot dist root directory cd $libreboot_bin

  * Locate the rom image for your target (I will call it: $img_path)

  * Running the following command will extract the config in a file ./my_config:

cbfstool is in coreboot source code under util/

./cbfstool/i686/cbfstool $img_path extract -n config -f ./my_config

  * Make sure that the following params in the config are set as following:

CONFIG_USBDEBUG=y (Generic Drivers -> USB 2.0 EHCI debug dongle support)
CONFIG_USBDEBUG_IN_ROMSTAGE=y (Generic Drivers -> Enable early (pre-RAM) usbdebug)
CONFIG_USBDEBUG_HCD_INDEX=<HCD Index of usb controller - see below> (Generic Drivers -> Index for EHCI controller to use with usbdebug)
CONFIG_USBDEBUG_DEFAULT_PORT=<USB Debug port - see below> (Generic Drivers -> Default USB port to use as Debug Port)

The following three are behind radio button in the menu. Only the first one see 2, should be = y

USBDEBUG_DONGLE_STD=y                       (Generic Drivers -> Type of dongle (Net20DC or compatible) -> Net20DC or compatible)
CONFIG_USBDEBUG_DONGLE_BEAGLEBONE=n         (Generic Drivers -> Type of dongle (Net20DC or compatible) -> BeagleBone)
CONFIG_USBDEBUG_DONGLE_BEAGLEBONE_BLACK=n   (Generic Drivers -> Type of dongle (Net20DC or compatible) -> BeagleBone Black)

The g_dbgp module on BeagleBone Black (Rev. C) reports it self as Net20DC, the other options are for older BB(B) - ver1. This is documented here (https://johnlewis.ie/coreboot-ehci-debug-gadget-demonstration/) (also tested/verified).

Then:

CONFIG_CONSOLE_USB=y (Console -> USB dongle console output)

Also Debugging ---> Output verbose XYZ ) (FIXME somebody verify these):

CONFIG_DEBUG_CBFS=y (Output verbose CBFS debug messages )
CONFIG_HAVE_DEBUG_RAM_SETUP=y (??? What/where is this)
CONFIG_DEBUG_RAM_SETUP=y (Output verbose RAM init debug messages)
CONFIG_DEBUG_SMI=y      (Output verbose SMI debug messages)
CONFIG_DEBUG_ACPI=y     (Output verbose ACPI debug messages )
CONFIG_DEBUG_USBDEBUG=y (Output verbose USB 2.0 EHCI debug dongle messages)

If some of the above mentioned configuration options are not as specified, you have to configure and compile libreboot yourself. Please refer to the doc(FIXME: link about compiling libreboot.

This applies (and works) only if the USB controller that supports debug (found in the first section) is from Intel.
If the PCI ID of the port you found in the first section is 0000:00:1a.0 or 0000:00:1d.0 , you are ok. Otherwise you have to try without guarantee that will work.

If the externally exposed port is on a bus with PCI ID == 0000:00:1a.0 then for CONFIG_USBDEBUG_HCD_INDEX choose 2, otherwise choose 0 .

For CONFIG_USBDEBUG_DEFAULT_PORT choose the port from the first section that correspond to the PCI ID

Notes:
The above is based on the implementation of coreboot/src/southbridge/intel/common/usb_debug.c : pci_ehci_dbg_dev() .
This is enough as it applies for the supported GM45/G45 Thinkpads. coreboot support some other contollers too, but they are irellevent for libreboot (for now).

  * On T500 (with switchable GPU) the debug ports for both intel controllers is exposed.

  * On x200t the debug ports for both intel controllers is exposed.

  * Plug the USB cable in the target's debug port (the one you found in step 1) and BBB's mini-B USB

  * Make sure no other then g_dbgp of the g_* modules is loaded on your BBB

  * On the BBB:

stty -icrnl -inlcr -F /dev/ttyGS0
cat /dev/ttyGS0

  * Power on the target with libreboot

  * You should see debug logs comming on your BBB console

Note that this is not permanent on BBB, if you reboot it, you have to rmmod g_* and modprobe g_dbgp

You have to know how to compile kernel for your target.

 1. Check if early debugging is already enabled: grep CONFIG_EARLY_PRINTK_DBGP /boot/config-<ver>

 2. If enabled, you do not have to compile the kernel (skip this step). Otherwise, prepare kernel source for your distribution and select (Kernel hacking -> Early printk via EHCI debug port). Compile and install the new kernel.

 3. Edit your grub configuration and add following to the kernel parameters see 20, see 21,: earlyprintk=dbgp,keep. Also, try: earlyprintk=dbgp<N>,keep where N is the debug port id if the first does not work.

 1. EHCI Debug Port (http://www.coreboot.org/EHCI_Debug_Port)

 2. coreboot EHCI debug gadget demonstration (https://johnlewis.ie/coreboot-ehci-debug-gadget-demonstration/)

 3. EHCI Gadget Debug (http://www.coreboot.org/EHCI_Gadget_Debug)

 4. Ehci-debug-gadget-patches.tar.gz (http://www.coreboot.org/images/8/88/Ehci-debug-gadget-patches.tar.gz)

 5. Compiling the BeagleBone Black Kernel (http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel)

 6. http://dumb-looks-free.blogspot.ca/2014/06/beaglebone-black-bbb-compile-kernel.html

 7. http://dumb-looks-free.blogspot.fr/2014/06/beaglebone-black-bbb-kernal-headers.html

 8. Building BBB Kernel (http://elinux.org/Building_BBB_Kernel)

 9. http://komposter.com.ua/documents/USB-2.0-Debug-Port%28John-Keys%29.pdf

 10. Exploring USB at the Hardware/Software Interface (http://cs.usfca.edu/~cruse/cs698s10/)

 11. https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt

 12. https://wiki.ubuntu.com/Kernel/Debugging/USBearlyprintk

     TODO:

      1. grub does not send messages to EHCI debug. Investigate.

      2. The section ``Configure libreboot with EHCI debug'' can be skipped/simplified if a common configuration works for all relevant targets is selected as defualt

      3. Patch and compule g_dbgp on BBB instead cross-compile

      4. Find a simple way to send debug messages from targets userland

Initial flashing instructions for KGPE-D16
..........................................

Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..

This guide is for those who want libreboot on their ASUS KGPE-D16 motherboard, while they still have the proprietary ASUS BIOS present. This guide can also be followed (adapted) if you brick you board, to know how to recover.

For more general information about this board, refer to kgpe-d16.

TODO: show photos here, and other info.

If you don't want to install libreboot yourself, companies exist that sell these boards with libreboot pre-installed, along with a free GNU/Linux distribution.

Check the suppliers (../../suppliers) page for more information.

Refer to bbb_setup for a guide on how to set up an external SPI programmer.

The flash chip is in a PDIP 8 socket (SPI flash chip) on the motherboard, which you take out and then re-flash with libreboot, using the programmer. DO NOT remove the chip with your hands. Use a chip extractor tool.

Initial flashing instructions for KCMA-D8
.........................................

Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..

This guide is for those who want libreboot on their ASUS KGPE-D16 motherboard, while they still have the proprietary ASUS BIOS present. This guide can also be followed (adapted) if you brick you board, to know how to recover.

For more general information about this board, refer to kcma-d8.

TODO: show photos here, and other info.

If you don't want to install libreboot yourself, companies exist that sell these boards with libreboot pre-installed, along with a free GNU/Linux distribution.

Check the suppliers (../../suppliers) page for more information.

Refer to bbb_setup for a guide on how to set up an external SPI programmer.

The flash chip is in a PDIP 8 socket (SPI flash chip) on the motherboard, which you take out and then re-flash with libreboot, using the programmer. DO NOT remove the chip with your hands. Use a chip extractor tool.

ThinkPad X60: Recovery guide
............................

This section documents how to recover from a bad flash that prevents your ThinkPad X60 from booting.

Types of brick:

You still have Lenovo BIOS, or you had libreboot running and you flashed another ROM; and you had bucts 1 set and the ROM wasn't dd'd.* or if Lenovo BIOS was present and libreboot wasn't flashed.

 In this case, unbricking is easy: reset BUC.TS to 0 by removing that yellow cmos coin (it's a battery) and putting it back after a minute or two:

 *Those dd commands should be applied to all newly compiled X60 ROM images (the ROM images in libreboot binary archives already have this applied!):
 dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
 dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
 dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
 (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: http://www.coreboot.org/Board:lenovo/x60/Installation.

In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all.

"Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the system, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides).

Remove those screws:

Push the keyboard forward (carefully):

Lift the keyboard up and disconnect it from the board:

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:

You should now have this:

Disconnect the wifi antenna cables, the modem cable and the speaker:

Unroute the cables along their path, carefully lifting the tape that holds them in place. Then, disconnect the modem cable (other end) and power connection and unroute all the cables so that they dangle by the monitor hinge on the right-hand side:

Disconnect the monitor from the motherboard, and unroute the grey antenna cable, carefully lifting the tape that holds it into place:

Carefully lift the remaining tape and unroute the left antenna cable so that it is loose:

Remove the screw that is highlighted (do NOT remove the other one; it holds part of the heatsink (other side) into place):

Remove those screws:

Carefully remove the plate, like so:

Remove the SATA connector:

Now remove the motherboard (gently) and cast the lcd/chassis aside:

Lift back that tape and hold it with something. Highlighted is the SPI flash chip:

Now wire up the BBB and the Pomona with your PSU.
 Refer to bbb_setup for how to setup the BBB for flashing.
 Note, the guide mentions a 3.3v DC PSU but you don't need this on the X60: if you don't have or don't want to use an external PSU, then make sure not to connect the 3.3v leads mentioned in the guide; instead, connect the AC adapter (the one that normally charges your battery) so that the board has power (but don't boot it up)
 Correlate the following with the BBB guide linked above:

POMONA 5250:
===  golden finger and wifi switch ====
 18              -       - 1
 22              -       - NC                    ---------- audio jacks are on this end
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  CPU fan ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Connecting the BBB and pomona (in this image, an external 3.3v DC PSU was used):

SSH'd into the BBB:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w yourrom.rom

It should be Verifying flash... VERIFIED at the end. If flashrom complains about multiple flash chip definitions detected, then choose one of them following the instructions in the output.

Remove the programmer and put it away somewhere. Put back the tape and press firmly over it:

Your empty chassis:

Put the motherboard back in:

Reconnect SATA:

Put the plate back and re-insert those screws:

Re-route that antenna cable around the fan and apply the tape:

Route the cable here and then (not shown, due to error on my part) reconnect the monitor cable to the motherboard and re-insert the screws:

Re-insert that screw:

Route the black antenna cable like so:

Tuck it in neatly like so:

Route the modem cable like so:

Connect modem cable to board and tuck it in neatly like so:

Route the power connection and connect it to the board like so:

Route the antenna and modem cables neatly like so:

Connect the wifi antenna cables. At the start of the tutorial, this system had an Intel wifi chip. Here you see I've replaced it with an Atheros AR5B95 (supports 802.11n and can be used without blobs):

Connect the modem cable:

Connect the speaker:

You should now have this:

Re-connect the upper chassis:

Re-connect the keyboard:

Re-insert the screws that you removed earlier:

Power on!

Trisquel live USB menu (using the GRUB ISOLINUX parser):

Trisquel live desktop:

ThinkPad X60 Tablet Recovery Guide
..................................

This section documents how to recover from a bad flash that prevents your ThinkPad X60 Tablet from booting.

Types of brick:

You still have Lenovo BIOS, or you had libreboot running and you flashed another ROM; and you had bucts 1 set and the ROM wasn't dd'd.* or if Lenovo BIOS was present and libreboot wasn't flashed.

 In this case, unbricking is easy: reset BUC.TS to 0 by removing that yellow cmos coin (it's a battery) and putting it back after a minute or two:

 *Those dd commands should be applied to all newly compiled X60 ROM images (the ROM images in libreboot binary archives already have this applied!):
 dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
 dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
 dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
 (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: http://www.coreboot.org/Board:lenovo/x60/Installation.

In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all.

"Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the system, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides).

Remove those screws:

Remove the HDD:

Push keyboard forward to loosen it:

Lift:

Remove those:

Also remove that (marked) and unroute the antenna cables:

For some X60T laptops, you have to unroute those too:

Remove the LCD extend board screws. Also remove those screws (see blue marks) and remove/unroute the cables and remove the metal plate:

Remove that screw and then remove the board:

Now wire up the BBB and the Pomona with your PSU.
 Refer to bbb_setup for how to setup the BBB for flashing.
 Note, the guide mentions a 3.3v DC PSU but you don't need this on the X60 Tablet: if you don't have or don't want to use an external PSU, then make sure not to connect the 3.3v leads mentioned in the guide; instead, connect the AC adapter (the one that normally charges your battery) so that the board has power (but don't boot it up)
 Correlate the following with the BBB guide linked above:

POMONA 5250:
===  golden finger and wifi switch ====
 18              -       - 1
 22              -       - NC                    ---------- audio jacks are on this end
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  CPU fan ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Connecting the BBB and pomona (in this image, an external 3.3v DC PSU was used):

SSH'd into the BBB:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w yourrom.rom

It should be Verifying flash... VERIFIED at the end. If flashrom complains about multiple flash chip definitions detected, then choose one of them following the instructions in the output.

Reverse the steps to re-assemble your system.

ThinkPad T60 Recovery Guide
...........................

This section documents how to recover from a bad flash that prevents your ThinkPad T60 from booting.

Types of brick:

You still have Lenovo BIOS, or you had libreboot running and you flashed another ROM; and you had bucts 1 set and the ROM wasn't dd'd.* or if Lenovo BIOS was present and libreboot wasn't flashed.

 In this case, unbricking is easy: reset BUC.TS to 0 by removing that yellow cmos coin (it's a battery) and putting it back after a minute or two:

 *Those dd commands should be applied to all newly compiled T60 ROM images (the ROM images in libreboot binary archives already have this applied!):
 dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
 dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
 dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
 (doing this makes the ROM suitable for use when flashing a system that still has Lenovo BIOS running, using those instructions: http://www.coreboot.org/Board:lenovo/x60/Installation. (it says x60, but instructions for t60 are identical)

In this scenario, you compiled a ROM that had an incorrect configuration, or there is an actual bug preventing your system from booting. Or, maybe, you set BUC.TS to 0 and shut down after first flash while Lenovo BIOS was running. In any case, your system is bricked and will not boot at all.

"Unbricking" means flashing a known-good (working) ROM. The problem: you can't boot the system, making this difficult. In this situation, external hardware (see hardware requirements above) is needed which can flash the SPI chip (where libreboot resides).

Remove those screws and remove the HDD:

Lift off the palm rest:

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:

Gently wedge both sides loose:

Remove that cable from the position:

Now remove that bezel. Remove wifi, nvram battery and speaker connector (also remove 56k modem, on the left of wifi):

Remove those screws:

Disconnect the power jack:

Remove nvram battery:

Disconnect cable (for 56k modem) and disconnect the other cable:

Disconnect speaker cable:

Disconnect the other end of the 56k modem cable:

Make sure you removed it:

Unscrew those:

Make sure you removed those:

Disconnect LCD cable from board:

Remove those screws then remove the LCD assembly:

Once again, make sure you removed those:

Remove the shielding containing the motherboard, then flip it over. Remove these screws, placing them on a steady surface in the same layout as they were in before you removed them. Also, you should mark each screw hole after removing the screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the system:

Now wire up the BBB and the Pomona with your PSU.
 Refer to bbb_setup for how to setup the BBB for flashing.
 Note, the guide mentions a 3.3v DC PSU but you don't need this on the T60: if you don't have or don't want to use an external PSU, then make sure not to connect the 3.3v leads mentioned in the guide; instead, connect the AC adapter (the one that normally charges your battery) so that the board has power (but don't boot it up)

 Correlate the following with the BBB guide linked above:

POMONA 5250:
===  DVD drive ====
 18              -       - 1
 22              -       - NC               ---- RAM is on this end
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  audio jacks ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Connect the pomona from the BBB to the flash chip. No pics unfortunately. (use the text diagram above).

SSH'd into the BBB:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w yourrom.rom

It should be Verifying flash... VERIFIED at the end. If flashrom complains about multiple flash chip definitions detected, then choose one of them following the instructions in the output.

Put those screws back:

Put it back into lower chassis:

Attach LCD and insert screws (also, attach the lcd cable to the board):

Insert those screws:

On the CPU (and there is another chip south-east to it, sorry forgot to take pic) clean off the old thermal paste (with the alcohol) and apply new (Artic Silver 5 is good, others are good too) you should also clean the heatsink the same way

Attach the heatsink and install the screws (also, make sure to install the AC jack as highlighted):

Reinstall that upper bezel:

Do that:

Re-attach modem, wifi, (wwan?), and all necessary cables. Sorry, forgot to take pics. Look at previous removal steps to see where they go back to.

Attach keyboard and install nvram battery:

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:

It lives!

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:

Flashing the X200 with a BeagleBone Black
.........................................

Initial flashing instructions for X200.

This guide is for those who want libreboot on their ThinkPad X200 while they still have the original Lenovo BIOS present. This guide can also be followed (adapted) if you brick your X200, to know how to recover.

If you don't want to install libreboot yourself, companies exist that sell these laptops with libreboot pre-installed, along with a free GNU/Linux distribution.

Check the suppliers (../../suppliers) page for more information.

Use this to find out:
 # dmidecode | grep ROM\ Size

The X200S and X200 Tablet will use a WSON-8 flash chip, on the bottom of the motherboard (this requires removal of the motherboard). Not all X200S/X200T are supported; see x200s.

On the X200/X200S/X200T, the MAC address for the onboard gigabit ethernet chipset is stored inside the flash chip, along with other configuration data.

Keep a note of the MAC address before disassembly; this is very important, because you will need to insert this into the libreboot ROM image before flashing it. It will be written in one of these locations:

Refer to bbb_setup for how to set up the BBB for flashing.

The following shows how to connect the clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):

POMONA 5252 (correlate with the BBB guide)
===  front (display) on your X200 ====
 NC              -       - 21
 1               -       - 17
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 18              -       - 3.3V (PSU)
 22              -       - NC - this is pin 1 on the flash chip
===  back (palmrest) on your X200 ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
Here is a photo of the SOIC-16 flash chip. Pins are labelled:

The following shows how to connect the clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):

POMONA 5250 (correlate with the BBB guide)
===  left side of the X200 (where the VGA port is) ====
 18              -       - 1
 22              -       - NC
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip. in front of it is the screen.
===  right side of the X200 (where the audio jacks are) ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
Here is a photo of the SOIC-8 flash chip. The pins are labelled:

Look at the pads in that photo, on the left and right. Those are for SOIC-16. Would it be possible to remove the SOIC-8 and solder a SOIC-16
chip on those pins?

On the X200S and X200 Tablet the flash chip is underneath the board, in a WSON package. The pinout is very much the same as a SOIC-8, except you need to solder (there are no clips available).
 The following image shows how this is done:

 In this image, a pin header was soldered onto the WSON. Another solution might be to de-solder the WSON-8 chip and put a SOIC-8 there instead. Check the list of SOIC-8 flash chips at flashchips but do note that these are only 4MiB (32Mb) chips. The only X200 SPI chips with 8MiB capacity are SOIC-16. For 8MiB capacity in this case, the X201 SOIC-8 flash chip (Macronix 25L6445E) might work.

This section is for the X200. This does not apply to the X200S or X200 Tablet (for those systems, you have to remove the motherboard completely, since the flash chip is on the other side of the board).

Remove these screws:

Push the keyboard forward, gently, then lift it off and disconnect it from the board:

Pull the palm rest off, lifting from the left and right side at the back of the palm rest:

Lift back the tape that covers a part of the flash chip, and then connect the clip:

On pin 2 of the BBB, where you have the ground (GND), connect the ground to your PSU:

Connect the 3.3V supply from your PSU to the flash chip (via the clip):

Of course, make sure that your PSU is also plugged in and turn on:

This tutorial tells you to use an ATX PSU, for the 3.3V DC supply. The PSU used when taking these photos is actually not an ATX PSU, but a PSU that is designed specifically for providing 3.3V DC (an ATX PSU will also work):

Now, you should be ready to install libreboot.

Log in as root on your BBB, using the instructions in bbb_access.

Test that flashrom works:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
 In this case, the output was:

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.

How to backup factory.rom (change the -c option as neeed, for your flash chip):
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
 Note: the -c option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in flashchips.c have been removed.
 Now compare the 3 images:
 # sha512sum factory*.rom
 If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another system, not the BBB). This is useful for reverse engineering work, if there is a desirable behaviour in the original firmware that could be replicated in coreboot and libreboot.

Follow the instructions at ich9gen to change the MAC address inside the libreboot ROM image, before flashing it. Although there is a default MAC address inside the ROM image, this is not what you want. Make sure to always change the MAC address to one that is correct for your system.

Now flash it:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V

You might see errors, but if it says Verifying flash... VERIFIED at the end, then it's flashed and should boot. If you see errors, try again (and again, and again); the message Chip content is identical to the requested image is also an indication of a successful installation.

Example output from running the command (see above):

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.

The X200 typically comes with an Intel wifi chipset, which does not work without proprietary software. For a list of wifi chipsets that work without proprietary software, see recommended_wifi.

Some X200 laptops come with an Atheros chipset, but this is 802.11g only.

It is recommended that you install a new wifi chipset. This can only be done after installing libreboot, because the original firmware has a whitelist of approved chips, and it will refuse to boot if you use an 'unauthorized' wifi card.

The following photos show an Atheros AR5B95 being installed, to replace the Intel chip that this X200 came with:

If you have a WWAN/3G card and/or sim card reader, remove them permanently. The WWAN-3G card has proprietary firmware inside; the technology is identical to what is used in mobile phones, so it can also track your movements.

Not to be confused with wifi (wifi is fine).

You need DDR3 SODIMM PC3-8500 RAM installed, in matching pairs (speed/size). Non-matching pairs won't work. You can also install a single module (meaning, one of the slots will be empty) in slot 0.

NOTE: reports from some users indicate that non matching pairs might work (e.g. 1+2 GiB).

Make sure that the RAM you buy is the 2Rx8 density.

This page (http://www.forum.thinkpads.com/viewtopic.php?p=760721) might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)

In this photo, 8GiB of RAM (2x4GiB) is installed:

You should see something like this:

Now install GNU/Linux.

sgsit found out about a pin called GPIO33, which can be grounded to disable the flashing protections by the descriptor and stop the ME from starting (which itself interferes with flashing attempts). The theory was proven correct; however, it is still useless in practise.

Look just above the 7 in TP37 (that's GPIO33):

By default we would see this in lenovobios, when trying flashrom -p internal -w rom.rom:

FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00001000-0x005f5fff) is locked.

With GPIO33 grounded during boot, this disabled the flash protections as set by descriptor, and stopped the ME from starting. The output changed to:

The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.

The part in bold is what got us. This was still observed:

PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.

It is actually possible to disable these protections. Lenovobios does, when updating the BIOS (proprietary one). One possible way to go about this would be to debug the BIOS update utility from Lenovo, to find out how it's disabling these protections. Some more research is available here: http://www.coreboot.org/Board:lenovo/x200/internal_flashing_research

On a related note, libreboot has a utility that could help with investigating this: demefactory

Flashing the ThinkPad R400 with a BeagleBone Black
..................................................

Initial flashing instructions for R400.

This guide is for those who want libreboot on their ThinkPad R400 while they still have the original Lenovo BIOS present. This guide can also be followed (adapted) if you brick your R400, to know how to recover.

Before following this section, please make sure to setup your libreboot ROM properly first. Although ROM images are provided pre-built in libreboot, there are some modifications that you need to make to the one you chose before flashing. (instructions referenced later in this guide)

You may also be interested in the smaller, more portable Libreboot T400.

EHCI debug might not be needed. It has been reported that the docking station for this laptop has a serial port, so it might be possible to use that instead.

Not all LCD panels are compatible yet. See gm45_lcd.

ThinkWiki (http://www.thinkwiki.org/wiki/Category:R400) has a list of CPUs for this system. The Core 2 Duo P8400 and P8600 are believed to work in libreboot. The Core 2 Duo T9600 was confirmed to work, so the T9400 probably also works. The Core 2 Duo T5870/5670 and Celeron M 575/585 are untested!

  * Quad-core CPUs

       - Incompatible. Do not use.

Some models have an Intel GPU, while others have both an ATI and an Intel GPU; this is referred to as "switchable graphics". In the BIOS setup program for lenovobios, you can specify that the system will use one or the other (but not both).

Libreboot is known to work on systems with only the Intel GPU, using native graphics initialization. On systems with switchable graphics, the Intel GPU is used and the ATI GPU is disabled, so native graphics initialization works all the same.

See paste.

Use this to find out:
 # dmidecode | grep ROM\ Size

On the R400, the MAC address for the onboard gigabit ethernet chipset is stored inside the flash chip, along with other configuration data.

Keep a note of the MAC address before disassembly; this is very important, because you will need to insert this into the libreboot ROM image before flashing it. It will be written in one of these locations:

Refer to bbb_setup for how to setup the BBB for flashing.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):

POMONA 5252 (correlate with the BBB guide)
===  ethernet jack and VGA port ====
 NC              -       - 21
 1               -       - 17
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 18              -       - 3.3V (PSU)
 22              -       - NC - this is pin 1 on the flash chip
===  SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):

POMONA 5250 (correlate with the BBB guide)
===  RAM slots ====
 18              -       - 1
 22              -       - NC
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  slot where the AC jack is connected ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Remove all screws:

 Remove the HDD and optical drive:

 Remove the hinge screws:

Remove the palm rest and keyboard:

Remove these screws, and then remove the bezel:

Remove the speaker screws, but don't remove the speakers yet (just set them loose):

Remove these screws, and then remove the metal plate:

Remove the antennas from the wifi card, and then start unrouting them:

Disconnect the LCD cable from the motherboard:

Remove the hinge screws, and then remove the LCD panel:

Remove this:

Remove this long cable (there are 3 connections):

Disconnect the speaker cable, and remove the speakers:

Remove the heatsink screws, remove the fan and then remove the heatsink/fan:

Remove the NVRAM battery:

Remove this screw:

Disconnect the AC jack:

Remove this screw and then remove what is under it:

Remove this:

Lift the motherboard (which is still inside the cage) from the side on the right, removing it completely:

Remove all screws, marking each hole so that you know where to re-insert them. You should place the screws in a layout corresponding to the order that they were in before removal:

Remove the motherboard from the cage, and the SPI flash chip will be next to the memory slots:

Connect your programmer, then connect GND and 3.3V

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:

Of course, make sure to turn on your PSU:

Now, you should be ready to install libreboot.

Log in as root on your BBB, using the instructions in bbb_access.

Test that flashrom works:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
 In this case, the output was:

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.

How to backup factory.rom (change the -c option as neeed, for your flash chip):
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
 Note: the -c option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in flashchips.c have been removed.
 Now compare the 3 images:
 # sha512sum factory*.rom
 If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another system, not the BBB). This is useful for reverse engineering work, if there is a desirable behaviour in the original firmware that could be replicated in coreboot and libreboot.

Follow the instructions at ich9gen to change the MAC address inside the libreboot ROM image, before flashing it. Although there is a default MAC address inside the ROM image, this is not what you want. Make sure to always change the MAC address to one that is correct for your system.

Now flash it:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V

You might see errors, but if it says Verifying flash... VERIFIED at the end, then it's flashed and should boot. If you see errors, try again (and again, and again); the message Chip content is identical to the requested image is also an indication of a successful installation.

Example output from running the command (see above):

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.

Because part of this procedure involved removing the heatsink, you will need to apply new paste. Arctic MX-4 is ok. You will also need isopropyl alcohol and an anti-static cloth to clean with.

When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much better than the default paste used on these systems.

NOTE: the photo above is for illustration purposes only, and does not show how to properly apply the thermal paste. Other guides online detail the proper application procedure.

The R400 typically comes with an Intel wifi chipset, which does not work without proprietary software. For a list of wifi chipsets that work without proprietary software, see recommended_wifi.

Some R400 laptops might come with an Atheros chipset, but this is 802.11g only.

It is recommended that you install a new wifi chipset. This can only be done after installing libreboot, because the original firmware has a whitelist of approved chips, and it will refuse to boot if you use an 'unauthorized' wifi card.

The following photos show an Atheros AR5B95 being installed, to replace the Intel chip that this R400 came with:

If you have a WWAN/3G card and/or sim card reader, remove them permanently. The WWAN-3G card has proprietary firmware inside; the technology is identical to what is used in mobile phones, so it can also track your movements.

Not to be confused with wifi (wifi is fine).

You need DDR3 SODIMM PC3-8500 RAM installed, in matching pairs (speed/size). Non-matching pairs won't work. You can also install a single module (meaning, one of the slots will be empty) in slot 0.

Make sure that the RAM you buy is the 2Rx8 density.

This page (http://www.forum.thinkpads.com/viewtopic.php?p=760721) might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)

The following photo shows 8GiB (2x4GiB) of RAM installed:

You should see something like this:

Now install GNU/Linux.

Flashing the T400 with a BeagleBone Black
.........................................

Initial flashing instructions for the ThinkPad T400.

This guide is for those who want libreboot on their ThinkPad T400 while they still have the original Lenovo BIOS present. This guide can also be followed (adapted) if you brick your T400, to know how to recover.

Before following this section, please make sure to setup your libreboot ROM properly first. Although ROM images are provided pre-built in libreboot, there are some modifications that you need to make to the one you chose before flashing. (instructions referenced later in this guide)

If you don't want to install libreboot yourself, companies exist that sell these laptops with libreboot pre-installed, along with a free GNU/Linux distribution.

EHCI debug might not be needed. It has been reported that the docking station for this laptop has a serial port, so it might be possible to use that instead.

Not all LCD panels are compatible yet. See gm45_lcd.

ThinkWiki (http://www.thinkwiki.org/wiki/Category:T400) has a list of CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed to work in libreboot. The T9600 was confirmed to work, so the T9500/T9550 probably also work.

  * Quad-core CPUs

       - Incompatible. Do not use.

Some models have an Intel GPU, while others have both an ATI and an Intel GPU; this is referred to as ``switchable graphics''. In the BIOS setup program for lenovobios, you can specify that the system will use one or the other (but not both).

Libreboot is known to work on systems with only the Intel GPU, using native graphics initialization. On systems with switchable graphics, the Intel GPU is used and the ATI GPU is disabled, so native graphics initialization works all the same.

See paste.

Use this to find out:
 # dmidecode | grep ROM\ Size

On the T400, the MAC address for the onboard gigabit ethernet chipset is stored inside the flash chip, along with other configuration data.

Keep a note of the MAC address before disassembly; this is very important, because you will need to insert this into the libreboot ROM image before flashing it. It will be written in one of these locations:

Refer to bbb_setup for how to configure the BBB for flashing.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):

POMONA 5252 (correlate with the BBB guide)
===  ethernet jack and VGA port ====
 NC              -       - 21
 1               -       - 17
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 18              -       - 3.3V (PSU)
 22              -       - NC - this is pin 1 on the flash chip
===  SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):

POMONA 5250 (correlate with the BBB guide)
===  RAM slots ====
 18              -       - 1
 22              -       - NC
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  slot where the AC jack is connected ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Remove all screws, placing them in the order that you removed them:

Remove those three screws then remove the rear bezel:

Remove the speakers:

Remove the wifi:

Remove this cable:

Unroute those antenna wires:

Remove the LCD assembly:

Disconnect the NVRAM battery:

Disconnect the fan:

Unscrew these:

Unscrew the heatsink, then lift it off:

Disconnect the power jack:

Loosen this:

Remove this:

Unscrew these:

Remove this:

Unscrew this:

Remove the motherboard (the cage is still attached) from the right hand side, then lift it out:

Remove these screws, placing the screws in the same layout and marking each screw hole (so that you know what ones to put the screws back into later):

Separate the motherboard:

Connect your programmer, then connect GND and 3.3V

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:

Of course, make sure to turn on your PSU:

Now, you should be ready to install libreboot.

Log in as root on your BBB, using the instructions in bbb_access.

Test that flashrom works:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
 In this case, the output was:

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.

How to backup factory.rom (change the -c option as neeed, for your flash chip):
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
 Note: the -c option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in flashchips.c have been removed.
 Now compare the 3 images:
 # sha512sum factory*.rom
 If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another system, not the BBB). This is useful for reverse engineering work, if there is a desirable behaviour in the original firmware that could be replicated in coreboot and libreboot.

Follow the instructions at ich9gen to change the MAC address inside the libreboot ROM image, before flashing it. Although there is a default MAC address inside the ROM image, this is not what you want. Make sure to always change the MAC address to one that is correct for your system.

Now flash it:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V

You might see errors, but if it says Verifying flash... VERIFIED at the end, then it's flashed and should boot. If you see errors, try again (and again, and again); the message Chip content is identical to the requested image is also an indication of a successful installation.

Example output from running the command (see above):

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.

Because part of this procedure involved removing the heatsink, you will need to apply new paste. Arctic MX-4 is ok. You will also need isopropyl alcohol and an anti-static cloth to clean with.

When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much better than the default paste used on these systems.

NOTE: the photo above is for illustration purposes only, and does not show how to properly apply the thermal paste. Other guides online detail the proper application procedure.

The T400 typically comes with an Intel wifi chipset, which does not work without proprietary software. For a list of wifi chipsets that work without proprietary software, see recommended_wifi.

Some T400 laptops might come with an Atheros chipset, but this is 802.11g only.

It is recommended that you install a new wifi chipset. This can only be done after installing libreboot, because the original firmware has a whitelist of approved chips, and it will refuse to boot if you use an 'unauthorized' wifi card.

The following photos show an Atheros AR5B95 being installed, to replace the Intel chip that this T400 came with:

If you have a WWAN/3G card and/or sim card reader, remove them permanently. The WWAN-3G card has proprietary firmware inside; the technology is identical to what is used in mobile phones, so it can also track your movements.

Not to be confused with wifi (wifi is fine).

You need DDR3 SODIMM PC3-8500 RAM installed, in matching pairs (speed/size). Non-matching pairs won't work. You can also install a single module (meaning, one of the slots will be empty) in slot 0.

Make sure that the RAM you buy is the 2Rx8 density.

This page (http://www.forum.thinkpads.com/viewtopic.php?p=760721) might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)

The following photo shows 8GiB (2x4GiB) of RAM installed:

You should see something like this:

Now install GNU/Linux.

Flashing the T500 with a BeagleBone Black
.........................................

Initial flashing instructions for T500.

This guide is for those who want libreboot on their ThinkPad T500 while they still have the original Lenovo BIOS present. This guide can also be followed (adapted) if you brick your T500, to know how to recover.

You may also be interested in the smaller, more portable Libreboot T400.

EHCI debug might not be needed. It has been reported that the docking station for this laptop has a serial port, so it might be possible to use that instead.

Not all LCD panels are compatible yet. See gm45_lcd.

ThinkWiki (http://www.thinkwiki.org/wiki/Category:T500) has a list of CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed to work in libreboot. The T9600 was also tested on the T400 and confirmed working, so the T9400/T9500/T9550 probably also work, but they are untested.

  * Quad-core CPUs

       - Incompatible. Do not use.

Some models have an Intel GPU, while others have both an ATI and an Intel GPU; this is referred to as "switchable graphics". In the BIOS setup program for lenovobios, you can specify that the system will use one or the other (but not both).

Libreboot is known to work on systems with only the Intel GPU, using native graphics initialization. On systems with switchable graphics, the Intel GPU is used and the ATI GPU is disabled, so native graphics initialization works all the same.

See paste.

Use this to find out:
 # dmidecode | grep ROM\ Size

On the T500, the MAC address for the onboard gigabit ethernet chipset is stored inside the flash chip, along with other configuration data.

Keep a note of the MAC address before disassembly; this is very important, because you will need to insert this into the libreboot ROM image before flashing it. It will be written in one of these locations:

Refer to bbb_setup for how to configure the BBB for flashing.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-16 (clip: Pomona 5252):

POMONA 5252 (correlate with the BBB guide)
===  ethernet jack and VGA port ====
 NC              -       - 21
 1               -       - 17
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 NC              -       - NC
 18              -       - 3.3V (PSU)
 22              -       - NC - this is pin 1 on the flash chip
===  SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

The following shows how to connect clip to the BBB (on the P9 header), for SOIC-8 (clip: Pomona 5250):

POMONA 5250 (correlate with the BBB guide)
===  RAM slots ====
 18              -       - 1
 22              -       - NC
 NC              -       - 21
 3.3V (PSU)      -       - 17 - this is pin 1 on the flash chip
===  slot where the AC jack is connected ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.

Remove all screws:

 It is also advisable to, throughout the disassembly, place any screws and/or components that you removed in the same layout or arrangement. The follow photos demonstrate this:

Remove the HDD/SSD and optical drive:

Remove the palm rest:

Remove the keyboard and rear bezel:

If you have a WWAN/3G card and/or sim card reader, remove them permanently. The WWAN-3G card has proprietary firmware inside; the technology is identical to what is used in mobile phones, so it can also track your movements:

Remove this frame, and then remove the wifi chip:

Remove the speakers:

Remove the NVRAM battery (already removed in this photo):

When you re-assemble, you will be replacing the wifi chip with another. These two screws don't hold anything together, but they are included in your system because the screw holes for half-height cards are a different size, so use these if you will be installing a half-height card:

Unroute the antenna wires:

Disconnect the LCD cable from the motherboard:

Remove the LCD assembly hinge screws, and then remove the LCD assembly:

Remove the fan and heatsink:

Remove this screw:

Remove these cables, keeping note of how and in what arrangement they are connected:

Disconnect the power jack:

Remove the motherboard and cage from the base (the marked hole is where those cables were routed through):

Remove all screws, arranging them in the same layout when placing the screws on a surface and marking each screw hole (this is to reduce the possibility of putting them back in the wrong holes):

Also remove this:

Separate the motherboard from the cage:

The flash chip is next to the memory slots. On this system, it was a SOIC-8 (4MiB or 32Mb) flash chip:

Connect your programmer, then connect GND and 3.3V

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:

Of course, make sure to turn on your PSU:

Now, you should be ready to install libreboot.

Log in as root on your BBB, using the instructions in bbb_access.

Test that flashrom works:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
 In this case, the output was:

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.

How to backup factory.rom (change the -c option as neeed, for your flash chip):
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
 Note: the -c option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in flashchips.c have been removed.
 Now compare the 3 images:
 # sha512sum factory*.rom
 If the hashes match, then just copy one of them (the factory.rom) to a safe place (on a drive connected to another system, not the BBB). This is useful for reverse engineering work, if there is a desirable behaviour in the original firmware that could be replicated in coreboot and libreboot.

Follow the instructions at ich9gen to change the MAC address inside the libreboot ROM image, before flashing it. Although there is a default MAC address inside the ROM image, this is not what you want. Make sure to always change the MAC address to one that is correct for your system.

Now flash it:
 # ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V

You might see errors, but if it says Verifying flash... VERIFIED at the end, then it's flashed and should boot. If you see errors, try again (and again, and again); the message Chip content is identical to the requested image is also an indication of a successful installation.

Example output from running the command (see above):

flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.

Because part of this procedure involved removing the heatsink, you will need to apply new paste. Arctic MX-4 is ok. You will also need isopropyl alcohol and an anti-static cloth to clean with.

When re-installing the heatsink, you must first clean off all old paste with the alcohol/cloth. Then apply new paste. Arctic MX-4 is also much better than the default paste used on these systems.

NOTE: the photo above is for illustration purposes only, and does not show how to properly apply the thermal paste. Other guides online detail the proper application procedure.

The T500 typically comes with an Intel wifi chipset, which does not work without proprietary software. For a list of wifi chipsets that work without proprietary software, see recommended_wifi.

Some T500 laptops might come with an Atheros chipset, but this is 802.11g only.

It is recommended that you install a new wifi chipset. This can only be done after installing libreboot, because the original firmware has a whitelist of approved chips, and it will refuse to boot if you use an 'unauthorized' wifi card.

The following photos show an Atheros AR5B95 being installed, to replace the Intel chip that this T500 came with:

If you have a WWAN/3G card and/or sim card reader, remove them permanently. The WWAN-3G card has DMA, and proprietary firmware inside; the technology is identical to what is used in mobile phones, so it can also track your movements.

Not to be confused with wifi (wifi is fine).

You need DDR3 SODIMM PC3-8500 RAM installed, in matching pairs (speed/size). Non-matching pairs won't work. You can also install a single module (meaning, one of the slots will be empty) in slot 0.

Make sure that the RAM you buy is the 2Rx8 density.

This page (http://www.forum.thinkpads.com/viewtopic.php?p=760721) might be useful for RAM compatibility info (note: coreboot raminit is different, so this page might be BS)

The following photo shows 8GiB (2x4GiB) of RAM installed:

You should see something like this:

Now install GNU/Linux.

GNU/Linux distributions
=======================

This section relates to dealing with GNU/Linux distributions: preparing bootable USB drives, changing the default GRUB menu and so on.

This section is only for the *GRUB* payload. For depthcharge, instructions have yet to be written.

How to install GNU/Linux on a libreboot system
----------------------------------------------

This section relates to preparing, booting and installing a GNU/Linux distribution on your libreboot system, using nothing more than a USB flash drive (and dd).

This section is only for the GRUB payload. For depthcharge (used on CrOS devices in libreboot), instructions have yet to be written in the libreboot documentation.

Prepare the USB drive (in GNU/Linux)
....................................

Connect the USB drive. Check dmesg:
 $ dmesg
 Check lsblk to confirm which drive it is:
 $ lsblk

Check that it wasn't automatically mounted. If it was, unmount it. For example:
 $ sudo umount /dev/sdX*
 # umount /dev/sdX*

dmesg told you what device it is. Overwrite the drive, writing your distro ISO to it with dd. For example:
 $ sudo dd if=gnulinux.iso of=/dev/sdX bs=8M; sync
 # dd if=gnulinux.iso of=/dev/sdX bs=8M; sync

You should now be able to boot the installer from your USB drive. Continue reading, for information about how to do that.

Installing GNU/Linux with full disk encryption
..............................................

  * Installing Trisquel GNU/Linux with full disk encryption (including /boot)

  * Installing Parabola GNU/Linux with full disk encryption (including /boot)

GNU Guix System Distribution?
.............................

The Guix installers use the GRUB bootloader, unlike most GNU/Linux installers which will likely use ISOLINUX.

To boot the Guix live USB install, select Search for GRUB configuration (grub.cfg) outside of CBFS from the GRUB payload menu. After you have done that, a new menuentry will appear at the very bottom with text like Load Config from (usb0); select that, and it should boot.

Once you have installed Guix onto the main storage device, check option1_dont_reflash for hints on how to boot it.

GuixSD (Guix System Distribution) is highly recommended; it's part of GNU, and endorsed (https://www.gnu.org/distros/free-distros.html) by the Free Software Foundation.

Trisquel net install?
.....................

Tip: don't use the official net install image. Download the full GNOME ISO (the ~1.5GiB one). In this ISO, there is still the capability to boot the net install, while it also provides an easy to use live system (which you can boot from USB). This ISO also works using syslinux_configfile -i (the Parse ISOLINUX menu entries in the default GRUB configuration that libreboot uses).

Booting ISOLINUX images (automatic method)
..........................................

Boot it in GRUB using the Parse ISOLINUX config (USB) option. A new menu should appear in GRUB, showing the boot options for that distro; this is a GRUB menu, converted from the usual ISOLINUX menu provided by that distro.

Booting ISOLINUX images (manual method)
.......................................

These are generic instructions. They may or may not be correct for your distribution. You must adapt them appropriately, for whatever GNU/Linux distribution it is that you are trying to install.

If the ISOLINUX parser or Search for GRUB configuration options won't work, then press C in GRUB to access the command line.
 grub> ls
 Get the device from above output, eg (usb0). Example:
 grub> cat (usb0)/isolinux/isolinux.cfg
 Either this will show the ISOLINUX menuentries for that ISO, or link to other .cfg files, for example /isolinux/foo.cfg.
 If it did that, then you do:
 grub> cat (usb0)/isolinux/foo.cfg
 And so on, until you find the correct menuentries for ISOLINUX. The file /isolinux/foo.cfg is a fictional example. Do not actually use this example, unless you actually have that file, if it is appropriate.

For Trisquel (and other debian-based distros), there are typically menuentries listed in /isolinux/txt.cfg or /isolinux/gtk.cfg. For dual-architecture ISO images (i686 and x86_64), there may be separate files/directories for each architecture. Just keep searching through the image, until you find the correct ISOLINUX configuration file.

Now look at the ISOLINUX menuentry. It'll look like:
 kernel /path/to/kernel
 append PARAMETERS initrd=/path/to/initrd MAYBE_MORE_PARAMETERS
 GRUB works the same way, but in it's own way. Example GRUB commands:
 grub> set root='usb0'
 grub> linux /path/to/kernel PARAMETERS MAYBE_MORE_PARAMETERS
 grub> initrd /path/to/initrd
 grub> boot
 Note: usb0 may be incorrect. Check the output of the ls command in GRUB, to see a list of USB devices/partitions. Of course this will vary from distro to distro. If you did all of that correctly, then it should now be booting your USB drive in the way that you specified.

Troubleshooting GNU/Linux installation
......................................

Most of these issues occur when using libreboot with coreboot's 'text mode' instead of the coreboot framebuffer. This mode is useful for booting payloads like memtest86+ which expect text-mode, but for GNU/Linux distributions it can be problematic when they are trying to switch to a framebuffer because it doesn't exist.

In most cases, you should use the vesafb ROM images. Example filename: libreboot_ukdvorak_vesafb.rom.

Parabola won't boot in text-mode
................................

Use one of the ROM images with vesafb in the filename (uses coreboot framebuffer instead of text-mode).

Debian-installer (trisquel net install) graphical corruption in text-mode
.........................................................................

When using the ROM images that use coreboot's "text mode" instead of the coreboot framebuffer, booting the Trisquel net installer results in graphical corruption because it is trying to switch to a framebuffer which doesn't exist. Use that kernel parameter on the 'linux' line when booting it:
 vga=normal fb=false

Tested in Trisquel 6 (and 7). This forces debian-installer to start in text-mode, instead of trying to switch to a framebuffer.

If selecting text-mode from a GRUB menu created using the ISOLINUX parser, you can press E on the menu entry to add this. Or, if you are booting manually (from GRUB terminal) then just add the parameters.

This workaround was found on the page: https://www.debian.org/releases/stable/i386/ch05s04.html. It should also work for gNewSense, Debian and any other apt-get distro that provides debian-installer (text mode) net install method.

How to replace the default GRUB configuration file on a libreboot system
------------------------------------------------------------------------

Libreboot on x86 uses the GRUB payload (http://www.coreboot.org/Payloads#GRUB_2) by default, which means that the GRUB configuration file (where your GRUB menu comes from) is stored directly alongside libreboot and its GRUB payload executable, inside the flash chip. In context, this means that installing distributions and managing them is handled slightly differently compared to traditional BIOS systems.

A libreboot (or coreboot) ROM image is not simply "flat"; there is an actual filesystem inside called CBFS (coreboot filesystem). A utility called 'cbfstool' allows you to change the contents of the ROM image. In this case, libreboot is configured such that the 'grub.cfg' and 'grubtest.cfg' files exist directly inside CBFS instead of inside the GRUB payload 'memdisk' (which is itself stored in CBFS).

cbfstool is in coreboot source code under util/

You can either modify the GRUB configuration stored in the flash chip, or you can modify a GRUB configuration file on the main storage which the libreboot GRUB payload will automatically search for.

Here is an excellent writeup about CBFS (coreboot filesystem): http://lennartb.home.xs4all.nl/coreboot/col5.html.

This guide is *only* for the GRUB payload. If you use the depthcharge payload, ignore this section entirely.

Introduction
............

Download the latest release from http://libreboot.org/
If you downloaded from git, refer to build_meta before continuing.

There are several advantages to modifying the GRUB configuration stored in CBFS, but this also means that you have to flash a new libreboot ROM image on your system (some users feel intimidated by this, to say the least). Doing so can be risky if not handled correctly, because it can result in a bricked system (recovery is easy if you have the equipment for it, but most people don't). If you aren't up to that then don't worry; it is possible to use a custom GRUB menu without flashing a new image, by loading a GRUB configuration from a partition on the main storage instead.

1st option: don't re-flash
..........................

By default, GRUB in libreboot is configured to scan all partitions on the main storage for /boot/grub/libreboot_grub.cfg or /grub/libreboot_grub.cfg(for systems where /boot is on a dedicated partition), and then use it automatically.

Simply create your custom GRUB configuration and save it to /boot/grub/libreboot_grub.cfg on the running system. The next time you boot, GRUB (in libreboot) will automatically switch to this configuration file. This means that you do not have to re-flash, recompile or otherwise modify libreboot at all!

Ideally, your distribution should automatically generate a libreboot_grub.cfg file that is written specifically under the assumption that it will be read and used on a libreboot system that uses GRUB as a payload. If your distribution does not do this, then you can try to add that feature yourself or politely ask someone involved with or otherwise knowledgeable about the distribution to do it for you. The libreboot_grub.cfg could either contain the full configuration, or it could chainload another GRUB ELF executable (built to be used as a coreboot payload) that is located in a partition on the main storage.

If you want to adapt a copy of the existing libreboot GRUB configuration and use that for the libreboot_grub.cfg file, then follow tools, rom and extract_testconfig to get the grubtest.cfg. Rename grubtest.cfg to libreboot_grub.cfg and save it to /boot/grub/ on the running system where it is intended to be used. Modify the file at that location however you see fit, and then stop reading this guide (the rest of this page is irrelevant to you); in libreboot_grub.cfg on disk, if you are adapting it based on grub.cfg from CBFS then remove the check for libreboot_grub.cfg otherwise it will loop..

This is all well and good, but what should you actually put in your GRUB configuration file? Read grub_config for more information.

2nd option: re-flash
....................

You can modify what is stored inside the flash chip quite easily. Read on to find out how.

Acquire the necessary utilities
...............................

Acquiring the correct ROM image
...............................

You can either work directly with one of the ROM images already included in the libreboot ROM archives, or re-use the ROM that you have currently flashed. For the purpose of this tutorial it is assumed that your ROM image file is named libreboot.rom, so please make sure to adapt.

ROM images are included pre-compiled in libreboot. You can also dump your current firmware, using flashrom:
 $ sudo flashrom -p internal -r libreboot.rom
 # flashrom -p internal -r libreboot.rom
 If you are told to specify the chip, add the option -c {your chip} to the command, for example:
 # flashrom -c MX25L6405 -p internal -r libreboot.rom

Extract grubtest.cfg from the ROM image
.......................................

You can check the contents of the ROM image, inside CBFS:
 $ cd .../libreboot_util/cbfstool $ ./cbfstool libreboot.rom print

cbfstool is in the coreboot source archive, under util/

The files grub.cfg and grubtest.cfg should be present. grub.cfg is loaded by default, with a menuentry for switching to grubtest.cfg. In this tutorial, you will first modify and test grubtest.cfg. This is to reduce the possibility of bricking your device, so DO NOT SKIP THIS!

Extract grubtest.cfg from the ROM image:
 $ ./cbfstool libreboot.rom extract -n grubtest.cfg -f grubtest.cfg

Modify the grubtest.cfg accordingly.

This is all well and good, but what should you actually put in your GRUB configuration file? Read grub_config for more information.

Re-insert the modified grubtest.cfg into the ROM image
......................................................

Once your grubtest.cfg is modified and saved, delete the unmodified config from the ROM image:
 $ ./cbfstool libreboot.rom remove -n grubtest.cfg

Next, insert the modified version:
 $ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw

Testing
.......

Now you have a modified ROM. Refer back to flashrom for information on how to flash it.
 $ cd /libreboot_util # ./flash update libreboot.rom
 Ocassionally, coreboot changes the name of a given board. If flashrom complains about a board mismatch, but you are sure that you chose the correct ROM image, then run this alternative command:
 # ./flash forceupdate libreboot.rom
 You should see "Verifying flash... VERIFIED." written at the end of the flashrom output. Once you have done that, shut down and then boot up with your new test configuration.

Choose (in GRUB) the menu entry that switches to grubtest.cfg. If it works, then your config is safe and you can continue below.

If it does not work like you want it to, if you are unsure or sceptical in any way, then re-do the steps above until you get it right! Do *not* proceed past this point unless you are 100% sure that your new configuration is safe (or desirable) to use.

Final steps
...........

When you are satisfied booting from grubtest.cfg, you can create a copy of grubtest.cfg, called grub.cfg. This is the same except for one difference: the menuentry 'Switch to grub.cfg' will be changed to 'Switch to grubtest.cfg' and inside it, all instances of grub.cfg to grubtest.cfg. This is so that the main config still links (in the menu) to grubtest.cfg, so that you don't have to manually switch to it, in case you ever want to follow this guide again in the future (modifying the already modified config). From /libreboot_util/cbfstool, do:
 $ sed -e 's:(cbfsdisk)/grub.cfg:(cbfsdisk)/grubtest.cfg:g' -e 's:Switch to grub.cfg:Switch to grubtest.cfg:g' < grubtest.cfg > grub.cfg

Delete the grub.cfg that remained inside the ROM:
 $ ./cbfstool libreboot.rom remove -n grub.cfg

Add the modified version that you just made:
 $ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw

Now you have a modified ROM. Again, refer back to flashrom for information on how to flash it. It's the same method as you used before. Shut down and then boot up with your new configuration.

Writing a GRUB configuration file
---------------------------------

This section is for those systems which use the GRUB payload. If your system uses the depthcharge payload, ignore this section.

The following are some common examples of ways in which the grubtest.cfg file can be modified.

Obvious option: don't even modify the built-in grub.cfg
.......................................................

Use the menuentry that says something like Search for GRUB outside CBFS. Assuming that you have a grub.cfg file at /boot/grub/ in your installed distro, this will generate a new menuentry in the GRUB menu. Use that to boot.

Then do this as root:
 $ cd /boot/grub/
 $ ln -s grub.cfg libreboot_grub.cfg

After that, your system should then boot automatically.

Trisquel with full disk encryption, custom partition layout
...........................................................

GRUB can boot from a symlink (or symlinks) pointing to your kernel/initramfs, whether from an unencrypted or encrypted /boot/. You can create your own custom symlink(s) but you have to manually update them when updating your kernel. This guide (not maintained by the libreboot project) shows how to configure Trisquel to automatically update that symlink on every kernel update. http://www.rel4tion.org/people/fr33domlover/libreboot-fix/

TODO: adapt those notes and put them here. The author said that it was CC-0, so re-licensing under GFDL shouldn't be a problem.

As an example, on my test system in /boot/grub/grub.cfg (on the HDD/SSD) I see for the main menu entry:

  * linux /boot/vmlinuz-3.15.1-gnu.nonpae root=UUID=3a008e14-4871-497b-95e5-fb180f277951 ro crashkernel=384M-2G:64M,2G-:128M quiet splash $vt_handoff

  * initrd /boot/initrd.img-3.15.1-gnu.nonpae

ro, quiet, splash, crashkernel=384M-2G:64M,2G-:128M and $vt_handoff can be safely ignored.

I use this to get my partition layout:
 $ lsblk

In my case, I have no /boot partition, instead /boot is on the same partition as / on sda1. Yours might be different. In GRUB terms, sda means ahci0. 1 means msdos1, or gpt1, depending on whether I am using MBR or GPT partitioning. Thus, /dev/sda1 is GRUB is (ahci0,msdos1) or (ahci0,gpt1). In my case, I use MBR partitioning so it's (ahci0,msdos1). 'msdos' is a GRUB name simply because this partitioning type is traditionally used by MS-DOS. It doesn't mean that you have a proprietary OS.

Trisquel doesn't keep the filenames of kernels consistent, instead it keeps old kernels and new kernel updates are provided with the version in the filename. This can make GRUB payload a bit tricky. Fortunately, there are symlinks /vmlinuz and /initrd.img so if your /boot and / are on the same partition, you can set GRUB to boot from that. These are also updated automatically when installing kernel updates from your distributions apt-get repositories. Note: when using jxself kernel releases (http://jxself.org/linux-libre), these are not updated at all and you have to update them manually.

For the GRUB payload grubtest.cfg (in the 'Load Operating System' menu entry), we therefore have (in this example):
 set root='ahci0,msdos1'
 linux /vmlinuz root=UUID=3a008e14-4871-497b-95e5-fb180f277951
 initrd /initrd.img

Optionally, you can convert the UUID to its real device name, for example /dev/sda1 in this case. sdX naming isn't very reliable, though, which is why UUID is used for most distributions.

Alternatively, if your /boot is on a separate partition then you cannot rely on the /vmlinuz and /initrd.img symlinks. Instead, go into /boot and create your own symlinks (update them manually when you install a new kernel update).
 $ sudo -s (or su -)
 # cd /boot/
 # rm -f vmlinuz initrd.img
 # ln -s yourkernel ksym
 # ln -s yourinitrd isym
 # exit

Then your grubtest.cfg menu entry (for payload) becomes like that, for example if / was on sda2 and /boot was on sda1:
 set root='ahci0,msdos1'
 linux /ksym root=/dev/sda2
 initrd /isym

There are lots of possible variations so please try to adapt.

Parabola GNU/Linux-libre
........................

You can basically adapt the above. Note however that Parabola does not keep old kernels still installed, and the file names are always consistent, so you don't need to boot from symlinks, you can just use the real thing directly.

Installing Parabola GNU/Linux-libre with full disk encryption including /boot
-----------------------------------------------------------------------------

Libreboot on x86 uses the GRUB payload (http://www.coreboot.org/Payloads#GRUB_2) by default, which means that the GRUB configuration file (where your GRUB menu comes from) is stored directly alongside libreboot and it's GRUB payload executable, inside the flash chip. In context, this means that installing distributions and managing them is handled slightly differently compared to traditional BIOS systems.

On most systems, the /boot partition has to be left unencrypted while the others are encrypted. This is so that GRUB, and therefore the kernel, can be loaded and executed since the firmware can't open a LUKS volume. Not so with libreboot! Since GRUB is already included directly as a payload, even /boot can be encrypted. This protects /boot from tampering by someone with physical access to the system.

NOTE: When finishing implementing this setup, if the boot stalls when running cryptomount -a, try removing the DVD drive (on thinkpads).

This guide is *only* for the GRUB payload. If you use the depthcharge payload, ignore this section entirely.

Booting the install environment
...............................

Boot Parabola's install environment. How to boot a GNU/Linux installer.

For this guide I used the 2015 08 01 image to boot the live installer and install the system. This is available at this page (https://wiki.parabola.nu/Get_Parabola#Main_live_ISO).

This guide will go through the installation steps taken at the time of writing, which may or may not change due to the volatile nature of Parabola (it changes all the time). In general most of it should remain the same. If you spot mistakes, please say so! This guide will be ported to the Parabola wiki at a later date. For up to date Parabola install guide, go to the Parabola wiki. This guide essentially cherry picks the useful information (valid at the time of writing: 2015-08-25).

Setting up the storage device
.............................

This section deals with wiping the storage device on which you plan to install Parabola GNU/Linux. Follow these steps, but if you use an SSD, also:

- beware there are issues with TRIM (not enabled through luks) and security issues if you do enable it. See this page (https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29) for more info.

- make sure it's brand-new (or barely used). Or, otherwise, be sure that it never previously contained plaintext copies of your data.

- make sure to read this article (https://wiki.archlinux.org/index.php/Solid_State_Drives). Edit /etc/fstab later on when chrooted into your install. Also, read the whole article and keep all points in mind, adapting them for this guide.

Securely wipe the drive:
 # dd if=/dev/urandom of=/dev/sda; sync
 NOTE: If you have an SSD, only do this the first time. If it was already LUKS-encrypted before, use the info below to wipe the LUKS header. Also, check online for your SSD what the recommended erase block size is. For example if it was 2MiB:
 # dd if=/dev/urandom of=/dev/sda bs=2M; sync

If your drive was already LUKS encrypted (maybe you are re-installing your distro) then it is already 'wiped'. You should just wipe the LUKS header. https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/ showed me how to do this. It recommends doing the first 3MiB. Now, that guide is recommending putting zero there. I'm going to use urandom. Do this:
 # head -c 3145728 /dev/urandom > /dev/sda; sync
 (Wiping the LUKS header is important, since it has hashed passphrases and so on. It's 'secure', but 'potentially' a risk).

Change keyboard layout
......................

Parabola live shell assumes US Qwerty. If you have something different, list the available keymaps and use yours:
 # localectl list-keymaps
 # loadkeys LAYOUT
 For me, LAYOUT would have been dvorak-uk.

Establish an internet connection
................................

Refer to this guide (https://wiki.parabola.nu/Beginners%27_guide#Establish_an_internet_connection). Wired is recommended, but wireless is also explained there.

Getting started
...............

The beginning is based on https://wiki.parabolagnulinux.org/Installation_Guide. Then I referred to https://wiki.archlinux.org/index.php/Partitioning at first.

dm-mod
......

device-mapper will be used - a lot. Make sure that the kernel module is loaded:
 # modprobe dm-mod

Create LUKS partition
.....................

I am using MBR partitioning, so I use cfdisk:
 # cfdisk /dev/sda

I create a single large sda1 filling the whole drive, leaving it as the default type 'Linux' (83).

Now I refer to https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation#Partitioning:
 I am then directed to https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption.

Parabola forces you to RTFM. Do that.

It tells me to run:
 # cryptsetup benchmark (for making sure the list below is populated)
 Then:
 # cat /proc/crypto
 This gives me crypto options that I can use. It also provides a representation of the best way to set up LUKS (in this case, security is a priority; speed, a distant second). To gain a better understanding, I am also reading:
 # man cryptsetup

Following that page, based on my requirements, I do the following based on https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode. Reading through, it seems like Serpent (encryption) and Whirlpool (hash) is the best option.

I am initializing LUKS with the following:
 # cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --use-random --verify-passphrase luksFormat /dev/sda1 Choose a secure passphrase here. Ideally lots of lowercase/uppercase numbers, letters, symbols etc all in a random pattern. The password length should be as long as you are able to handle without writing it down or storing it anywhere.

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

Create LVM
..........

Now I refer to https://wiki.archlinux.org/index.php/LVM.

Open the LUKS partition:
 # cryptsetup luksOpen /dev/sda1 lvm
 (it will be available at /dev/mapper/lvm)

Create LVM partition:
 # pvcreate /dev/mapper/lvm
 Show that you just created it:
 # pvdisplay

Now I create the volume group, inside of which the logical volumes will be created:
 # vgcreate matrix /dev/mapper/lvm
 (volume group name is 'matrix' - choose your own name, if you like) Show that you created it:
 # vgdisplay

Now create the logical volumes:
 # lvcreate -L 2G matrix -n swapvol (2G swap partition, named swapvol)
 Again, choose your own name if you like. Also, make sure to choose a swap size of your own needs. It basically depends on how much RAM you have installed. I refer to http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space.
 # lvcreate -l +100%FREE matrix -n root (single large partition in the rest of the space, named root)
 You can also be flexible here, for example you can specify a /boot, a /, a /home, a /var, a /usr, etc. For example, if you will be running a web/mail server then you want /var in its own partition (so that if it fills up with logs, it won't crash your system). For a home/laptop system (typical use case), a root and a swap will do (really).

Verify that the logical volumes were created, using the following command:
 # lvdisplay

Create / and swap partitions, and mount
.......................................

For the swapvol LV I use:
 # mkswap /dev/mapper/matrix-swapvol
 Activate swap:
 # swapon /dev/matrix/swapvol

For the root LV I use:
 # mkfs.ext4 /dev/mapper/matrix-root

Mount the root (/) partition:
 # mount /dev/matrix/root /mnt

Continue with Parabola installation
...................................

This guide is really about GRUB, Parabola and cryptomount. I have to show how to install Parabola so that the guide can continue.

Now I am following the rest of https://wiki.parabolagnulinux.org/Installation_Guide. I also cross referenced https://wiki.archlinux.org/index.php/Installation_guide.

Create /home and /boot on root mountpoint:
 # mkdir -p /mnt/home
 # mkdir -p /mnt/boot

Once all the remaining partitions, if any, have been mounted, the devices are ready to install Parabola.

In /etc/pacman.d/mirrorlist, comment out all lines except the Server line closest to where you are (I chose the UK Parabola server (main server)) and then did:
 # pacman -Syy
 # pacman -Syu
 # pacman -Sy pacman (and then I did the other 2 steps above, again)
 In my case I did the steps in the next paragraph, and followed the steps in this paragraph again.

<troubleshooting>
    The following is based on 'Verification of package signatures' in the Parabola install guide.
    Check there first to see if steps differ by now.
    Now you have to update the default Parabola keyring. This is used for signing and verifying packages:
    # pacman -Sy parabola-keyring
    It says that if you get GPG errors, then it's probably an expired key and, therefore, you should do:
    # pacman-key --populate parabola
    # pacman-key --refresh-keys
    # pacman -Sy parabola-keyring
    To be honest, you should do the above anyway. Parabola has a lot of maintainers, and a lot of keys. Really!
    If you get an error mentioning dirmngr, do:
    # dirmngr </dev/null
    Also, it says that if the clock is set incorrectly then you have to manually set the correct time
    (if keys are listed as expired because of it):
    # date MMDDhhmm[[CC]YY][.ss]
    I also had to install:
    # pacman -S archlinux-keyring
    # pacman-key --populate archlinux
    In my case I saw some conflicting files reported in pacman, stopping me from using it.
    I deleted the files that it mentioned and then it worked. Specifically, I had this error:
    licenses: /usr/share/licenses/common/MPS exists in filesystem
    I rm -Rf'd the file and then pacman worked. I'm told that the following would have also made it work:
    # pacman -Sf licenses
 </troubleshooting>

I also like to install other packages (base-devel, compilers and so on) and wpa_supplicant/dialog/iw/wpa_actiond are needed for wireless after the install:
 # pacstrap /mnt base base-devel wpa_supplicant dialog iw wpa_actiond

Configure the system
....................

Generate an fstab - UUIDs are used because they have certain advantages (see https://wiki.parabola.nu/Fstab#Identifying_filesystems. If you prefer labels instead, replace the -U option with -L):
 # genfstab -U -p /mnt >> /mnt/etc/fstab
 Check the created file:
 # cat /mnt/etc/fstab
 (If there are any errors, edit the file. Do NOT run the genfstab command again!)

Chroot into new system:
 # arch-chroot /mnt /bin/bash

It's a good idea to have this installed:
 # pacman -S linux-libre-lts

It was also suggested that you should install this kernel (read up on what GRSEC is):
 # pacman -S linux-libre-grsec

This is another kernel that sits inside /boot, which you can use. LTS means 'long-term support'. These are so-called 'stable' kernels that can be used as a fallback during updates, if a bad kernel causes issues for you.

Parabola does not have wget. This is sinister. Install it:
 # pacman -S wget

Locale:
 # nano /etc/locale.gen
 Uncomment your needed localisations. For example en_GB.UTF-8 (UTF-8 is highly recommended over other options).
 # locale-gen
 # echo LANG=en_GB.UTF-8 > /etc/locale.conf
 # export LANG=en_GB.UTF-8

Console font and keymap:
 # nano /etc/vconsole.conf
 In my case:

KEYMAP=dvorak-uk
FONT=lat9w-16

Time zone:
 # ln -s /usr/share/zoneinfo/Europe/London /etc/localtime
 (Replace Zone and Subzone to your liking. See /usr/share/zoneinfo)

Hardware clock:
 # hwclock --systohc --utc

Hostname: Write your hostname to /etc/hostname. For example, if your hostname is parabola:
 # echo parabola > /etc/hostname
 Add the same hostname to /etc/hosts:
 # nano /etc/hosts

#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1   localhost.localdomain   localhost   parabola
::1     localhost.localdomain   localhost   parabola

Configure the network: Refer to https://wiki.parabola.nu/Beginners%27_guide#Configure_the_network.

Mkinitcpio: Configure /etc/mkinitcpio.conf as needed (see https://wiki.parabola.nu/Mkinitcpio). Runtime modules can be found in /usr/lib/initcpio/hooks, and build hooks can be found in /usr/lib/initcpio/install. (# mkinitcpio -H hookname gives information about each hook.) Specifically, for this use case:
 # nano /etc/mkinitcpio.conf
 Then modify the file like so:

  * MODULES="i915"

  * This forces the driver to load earlier, so that the console font isn't wiped out after getting to login). Macbook21 users will also need to add the "hid-generic", "hid" and "hid-apple" modules to have a working keyboard when asked to enter the LUKS password.

  * HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt lvm2 filesystems fsck shutdown"

  * Explanation:

  * keymap adds to initramfs the keymap that you specified in /etc/vconsole.conf

  * consolefont adds to initramfs the font that you specified in /etc/vconsole.conf

  * encrypt adds LUKS support to the initramfs - needed to unlock your disks at boot time

  * lvm2 adds LVM support to the initramfs - needed to mount the LVM partitions at boot time

  * shutdown is needed according to Parabola wiki for unmounting devices (such as LUKS/LVM) during shutdown)

Now using mkinitcpio, you can create the kernel and ramdisk for booting with (this is different from Arch, specifying linux-libre instead of linux):
 # mkinitcpio -p linux-libre
 Also do it for linux-libre-lts:
 # mkinitcpio -p linux-libre-lts
 Also do it for linux-libre-grsec:
 # mkinitcpio -p linux-libre-grsec

Set the root password: At the time of writing, Parabola used SHA512 by default for its password hashing. I referred to https://wiki.archlinux.org/index.php/SHA_password_hashes.
 # nano /etc/pam.d/passwd
 Add rounds=65536 at the end of the uncommented 'password' line.
 # passwd root
 Make sure to set a secure password! Also, it must never be the same as your LUKS password.

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

Extra security tweaks
.....................

Based on https://wiki.archlinux.org/index.php/Security.

Restrict access to important directories:
 # chmod 700 /boot /etc/{iptables,arptables}

Lockout user after three failed login attempts:
 Edit the file /etc/pam.d/system-login and comment out that line:
 # auth required pam_tally.so onerr=succeed file=/var/log/faillog
 Or just delete it. Above it, put:
 auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
 To unlock a user manually (if a password attempt is failed 3 times), do:
 # pam_tally --user theusername --reset What the above configuration does is lock the user out for 10 minutes, if they make 3 failed login attempts.

Configure sudo - not covered here. Will be covered post-installation in another tutorial, at a later date. If this is a single-user system, you don't really need sudo.

Unmount, reboot!
................

Exit from chroot:
 # exit

unmount:
 # umount -R /mnt
 # swapoff -a

deactivate the lvm lv's:
 # lvchange -an /dev/matrix/root
 # lvchange -an /dev/matrix/swapvol

Lock the encrypted partition (close it):
 # cryptsetup luksClose lvm

# shutdown -h now
 Remove the installation media, then boot up again.

Booting from GRUB
.................

Initially you will have to boot manually. Press C to get to the GRUB command line. The underlined parts are optional (using those 2 underlines will boot lts kernel instead of normal).

grub> cryptomount -a
 grub> set root='lvm/matrix-root'
 grub> linux /boot/vmlinuz-linux-libre-lts root=/dev/matrix/root cryptdevice=/dev/sda1:root
 grub> initrd /boot/initramfs-linux-libre-lts.img
 grub> boot

You could also make it load /boot/vmlinuz-linux-libre-grsec and /boot/initramfs-linux-libre-grsec.img

Follow-up tutorial: configuring Parabola
........................................

We will modify grub.config inside the ROM and do all kinds of fun stuff, but I recommend that you first transform the current bare-bones Parabola install into a more useable system. Doing so will make the upcoming ROM modifications MUCH easier to perform and less risky! configuring_parabola shows my own notes post-installation. Using these, you can get a basic system similar to the one that I chose for myself. You can also cherry pick useful notes and come up with your own system. Parabola is user-centric, which means that you are in control. For more information, read The Arch Way (https://wiki.archlinux.org/index.php/The_Arch_Way) (Parabola also follows it).

Modify grub.cfg inside the ROM
..............................

(Re-)log in to your system, pressing C, so booting manually from GRUB (see above). You need to modify the ROM, so that Parabola can boot automatically with this configuration. grub_cbfs shows you how. Follow that guide, using the configuration details below. If you go for option 2 (re-flash), promise to do this on grubtest.cfg first! We can't emphasise this enough. This is to reduce the possibility of bricking your device!

In grubtest.cfg, inside the 'Load Operating System' menu entry, change the contents to:

cryptomount -a
set root='lvm/matrix-root'
linux /boot/vmlinuz-linux-libre-lts root=/dev/matrix/root cryptdevice=/dev/sda1:root
initrd /boot/initramfs-linux-libre-lts.img

Note: the underlined parts above (-lts) can also be removed, to boot the latest kernel instead of LTS (long-term support) kernels. You could also copy the menu entry and in one have -lts, and without in the other menuentry. You could also create a menu entry to load /boot/vmlinuz-linux-libre-grsec and /boot/initramfs-linux-libre-grsec.img The first entry will load by default.

Without specifying a device, the -a parameter tries to unlock all detected LUKS volumes. You can also specify -u UUID or -a (device).

Now, to protect your system from an attacker simply booting a live usb distro and re-flashing the boot firmware, we are going to add a password for GRUB. In a new terminal window, if you are not yet online, start dhcp on ethernet:
 # systemctl start dhcpcd.service Or make sure to get connected to the internet in any other way you prefer, at least.

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

AGAIN: MAKE SURE TO DO THIS WHOLE SECTION ON grubtest.cfg *BEFORE* DOING IT ON grub.cfg. (When we get there, upon reboot, select the menu entry that says Switch to grubtest.cfg and test that it works. Only once you are satisfied, copy that to grub.cfg. Only a few steps to go, though.) WHY? BECAUSE AN INCORRECTLY SET PASSWORD CONFIG MEANS YOU CAN'T AUTHENTICATE, WHICH MEANS 'BRICK'.

(emphasis added, because it's needed: this is a common roadblock for users.)

We need a utility that comes with GRUB, so we will download it temporarily. (Remember that GRUB isn't needed for booting, since it's already included as a payload in libreboot.) Also, we will use flashrom, and I installed dmidecode. You only need base-devel (compilers and so on) to build and use cbfstool. It was already installed if you followed this tutorial, but here it is:
 # pacman -S grub flashrom dmidecode base-devel
 Next, do:
 # grub-mkpasswd-pbkdf2
 Enter your chosen password at the prompt and your hash will be shown. Copy this string - you will add it to your grubtest.cfg.

The password below (it's password, by the way) after 'password_pbkdf2 root' should be changed to your own. Make sure to specify a password that is different from both your LUKS *and* your root/user password. Obviously, do not simply copy and paste the examples shown here...

Next, back in grubtest.cfg, above the first 'Load Operating System' menu entry, you should now add your GRUB password, like so (replace with your own name (I used root on both lines, feel free to choose another one) and the password hash which you copied):

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711

Save your changes in grubtest.cfg, then delete the unmodified config from the ROM image:
 $ ./cbfstool libreboot.rom remove -n grubtest.cfg
 and insert the modified grubtest.cfg:
 $ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw

Now refer to http://libreboot.org/install/index.html#flashrom. Cd (up) to the libreboot_util directory and update the flash chip contents:
 # ./flash update libreboot.rom
 Ocassionally, coreboot changes the name of a given board. If flashrom complains about a board mismatch, but you are sure that you chose the correct ROM image, then run this alternative command:
 # ./flash forceupdate libreboot.rom
 You should see "Verifying flash... VERIFIED." written at the end of the flashrom output.

With this new configuration, Parabola can boot automatically and you will have to enter a password at boot time, in GRUB, before being able to use any of the menu entries or switch to the terminal. Let's test it out: reboot and choose grubtest.cfg from the GRUB menu, using the arrow keys on your keyboard. Enter the name you chose, the GRUB password, your LUKS passphrase and login as root/your user. All went well? Great!

If it does not work like you want it to, if you are unsure or sceptical in any way, don't despair: you have been wise and did not brick your device! Reboot and login the default way, and then modify your grubtest.cfg until you get it right! Do *not* proceed past this point unless you are 100% sure that your new configuration is safe (or desirable) to use.

Now, we can easily and safely create a copy of grubtest.cfg, called grub.cfg. This will be the same except for one difference: the menuentry 'Switch to grub.cfg' is changed to 'Switch to grubtest.cfg' and, inside it, all instances of grub.cfg to grubtest.cfg. This is so that the main config still links (in the menu) to grubtest.cfg, so that you don't have to manually switch to it, in case you ever want to follow this guide again in the future (modifying the already modified config). Inside libreboot_util/cbfstool/{armv7l i686 x86_64}, we can do this with the following command:
 $ sed -e 's:(cbfsdisk)/grub.cfg:(cbfsdisk)/grubtest.cfg:g' -e 's:Switch to grub.cfg:Switch to grubtest.cfg:g' < grubtest.cfg > grub.cfg
 Delete the grub.cfg that remained inside the ROM:
 $ ./cbfstool libreboot.rom remove -n grub.cfg
 Add the modified version that you just made:
 $ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw

Now you have a modified ROM. Once more, refer to http://libreboot.org/install/index.html#flashrom. Cd to the libreboot_util directory and update the flash chip contents:
 # ./flash update libreboot.rom
 And wait for the "Verifying flash... VERIFIED." Once you have done that, shut down and then boot up with your new configuration.

When done, delete GRUB (remember, we only needed it for the grub-mkpasswd-pbkdf2 utility; GRUB is already part of libreboot, flashed alongside it as a payload):
 # pacman -R grub

If you followed all that correctly, you should now have a fully encrypted Parabola installation. Refer to the wiki for how to do the rest.

Bonus: Using a key file to unlock /boot/
........................................

By default, you will have to enter your LUKS passphrase twice; once in GRUB, and once when booting the kernel. GRUB unlocks the encrypted partition and then loads the kernel, but the kernel is not aware of the fact that it is being loaded from an encrypted volume. Therefore, you will be asked to enter your passphrase a second time. A workaround is to put a keyfile inside initramfs, with instructions for the kernel to use it when booting. This is safe, because /boot/ is encrypted (otherwise, putting a keyfile inside initramfs would be a bad idea).
 Boot up and login as root or your user. Then generate the key file:
 # dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile iflag=fullblock
 Insert it into the luks volume:
 # cryptsetup luksAddKey /dev/sdX /etc/mykeyfile
 and enter your LUKS passphrase when prompted. Add the keyfile to the initramfs by adding it to FILES in /etc/mkinitcpio.conf. For example:
 # FILES="/etc/mykeyfile"
 Create the initramfs image from scratch:
 # mkinitcpio -p linux-libre
 # mkinitcpio -p linux-libre-lts
 # mkinitcpio -p linux-libre-grsec
 Add the following to your grub.cfg - you are now able to do that, see above! -, or add it in the kernel command line for GRUB:
 # cryptkey=rootfs:/etc/mykeyfile

 You can also place this inside the grub.cfg that exists in CBFS: grub_cbfs.

Further security tips
.....................

https://wiki.archlinux.org/index.php/Security.
 https://wiki.parabolagnulinux.org/User:GNUtoo/laptop

Troubleshooting Parabola
........................

A user reported issues when booting with a docking station attached on an X200, when decrypting the disk in GRUB. The error AHCI transfer timed out was observed. The workaround was to remove the docking station.

Further investigation revealed that it was the DVD drive causing problems. Removing that worked around the issue.

"sudo wodim -prcap" shows information about the drive:
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/sr0
Using /dev/cdrom of unknown capabilities
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   :
Vendor_info    : 'HL-DT-ST'
Identification : 'DVDRAM GU10N    '
Revision       : 'MX05'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.

Drive capabilities, per MMC-3 page 2A:

  Does read CD-R media
  Does write CD-R media
  Does read CD-RW media
  Does write CD-RW media
  Does read DVD-ROM media
  Does read DVD-R media
  Does write DVD-R media
  Does read DVD-RAM media
  Does write DVD-RAM media
  Does support test writing

  Does read Mode 2 Form 1 blocks
  Does read Mode 2 Form 2 blocks
  Does read digital audio blocks
  Does restart non-streamed digital audio reads accurately
  Does support Buffer-Underrun-Free recording
  Does read multi-session CDs
  Does read fixed-packet CD media using Method 2
  Does not read CD bar code
  Does not read R-W subcode information
  Does read raw P-W subcode data from lead in
  Does return CD media catalog number
  Does return CD ISRC information
  Does support C2 error pointers
  Does not deliver composite A/V data

  Does play audio CDs
  Number of volume control levels: 256
  Does support individual volume control setting for each channel
  Does support independent mute setting for each channel
  Does not support digital output on port 1
  Does not support digital output on port 2

  Loading mechanism type: tray
  Does support ejection of CD via START/STOP command
  Does not lock media on power up via prevent jumper
  Does allow media to be locked in the drive via PREVENT/ALLOW command
  Is not currently in a media-locked state
  Does not support changing side of disk
  Does not have load-empty-slot-in-changer feature
  Does not support Individual Disk Present feature

  Maximum read  speed:  4234 kB/s (CD  24x, DVD  3x)
  Current read  speed:  4234 kB/s (CD  24x, DVD  3x)
  Maximum write speed:  4234 kB/s (CD  24x, DVD  3x)
  Current write speed:  4234 kB/s (CD  24x, DVD  3x)
  Rotational control selected: CLV/PCAV
  Buffer size in KB: 1024
  Copy management revision supported: 1
  Number of supported write speeds: 4
  Write speed # 0:  4234 kB/s CLV/PCAV (CD  24x, DVD  3x)
  Write speed # 1:  2822 kB/s CLV/PCAV (CD  16x, DVD  2x)
  Write speed # 2:  1764 kB/s CLV/PCAV (CD  10x, DVD  1x)
  Write speed # 3:   706 kB/s CLV/PCAV (CD   4x, DVD  0x)

Supported CD-RW media types according to MMC-4 feature 0x37:
  Does write multi speed       CD-RW media
  Does write high  speed       CD-RW media
  Does write ultra high speed  CD-RW media
  Does not write ultra high speed+ CD-RW media

Configuring Parabola (post-install)
-----------------------------------

Post-installation configuration steps for Parabola GNU/Linux-libre. Parabola is extremely flexible; this is just an example.

While not strictly related to the libreboot project, this guide is intended to be useful for those interested in installing Parabola on their libreboot system.

It details configuration steps that I took after installing the base system, as a follow up to encrypted_parabola. This guide is likely to become obsolete at a later date (due to the volatile 'rolling-release' model that Arch/Parabola both use), but attempts will be made to maintain it.

This guide was valid on 2014-09-21. If you see any changes that should to be made at the present date, please get in touch with the libreboot project!

You do not necessarily have to follow this guide word-for-word; parabola is extremely flexible. The aim here is to provide a common setup that most users will be happy with. While Parabola can seem daunting at first glance (especially for new GNU/Linux users), with a simple guide it can provide all the same usability as Trisquel, without hiding any details from the user.

Paradoxically, as you get more advanced Parabola can actually become easier to use when you want to set up your system in a special way compared to what most distributions provide. You will find over time that other distributions tend to get in your way.

This guide assumes that you already have Parabola installed. If you have not yet installed Parabola, then this guide is highly recommended!

A lot of the steps in this guide will refer to the Arch wiki. Arch is the upstream distribution that Parabola uses. Most of this guide will also tell you to read wiki articles, other pages, manuals, and so on. In general it tries to cherry pick the most useful information but nonetheless you are encouraged to learn as much as possible. It might take you a few days to fully install your system how you like, depending on how much you need to read. Patience is key, especially for new users.

The Arch wiki will sometimes use bad language, such as calling the whole system Linux, using the term open-source (or closed-source), and it will sometimes recommend the use of proprietary software. You need to be careful about this when reading anything on the Arch wiki.

Some of these steps require internet access. I'll go into networking later but for now, I just connected my system to a switch and did:
 # systemctl start dhcpcd.service
 You can stop it later by running:
 # systemctl stop dhcpcd.service
 For most people this should be enough, but if you don't have DHCP on your network then you should setup your network connection first:
 Setup network connection in Parabola

Configure pacman
................

pacman (package manager) is the name of the package management system in Arch, which Parabola (as a deblobbed parallel effort) also uses. Like with 'apt-get' on debian-based systems like Trisquel, this can be used to add/remove and update the software on your computer.

Based on https://wiki.parabolagnulinux.org/Installation_Guide#Configure_pacman and from reading https://wiki.archlinux.org/index.php/Pacman (make sure to read and understand this, it's very important) and https://wiki.parabolagnulinux.org/Official_Repositories

Updating Parabola
.................

In the end, I didn't change my configuration for pacman. When you are updating, resync with the latest package names/versions:
 # pacman -Syy
 (according to the wiki, -Syy is better than Sy because it refreshes the package list even if it appears to be up to date, which can be useful when switching to another mirror).
 Then, update the system:
 # pacman -Syu

Before installing packages with 'pacman -S', always update first, using the notes above.

Keep an eye out on the output, or read it in /var/log/pacman.log. Sometimes, pacman will show messages about maintenance steps that you will need to perform with certain files (typically configurations) after the update. Also, you should check both the Parabola and Arch home pages to see if they mention any issues. If a new kernel is installed, you should also update to be able to use it (the currently running kernel will also be fine). It's generally good enough to update Parabola once every week, or maybe twice. As a rolling release distribution, it's a good idea never to leave your install too outdated; update regularly. This is simply because of the way the project works; old packages are deleted from the repositories quickly, once they are updated. A system that hasn't been updated for quite a while will mean potentially more reading of previous posts through the website, and more maintenance work.

The Arch forum can also be useful, if others have the same issue as you (if you encounter issues, that is). The Parabola IRC channel (#parabola on freenode) can also help you.

Due to this and the volatile nature of Parabola/Arch, you should only update when you have at least a couple hours of spare time in case of issues that need to be resolved. You should never update, for example, if you need your system for an important event, like a presentation or sending an email to an important person before an allocated deadline, and so on.

Relax - packages are well-tested regularly when new updates are made to the repositories. Separate 'testing' repositories exist for this exact reason. Despite what many people will tell you, Parabola is fairly stable and trouble-free, so long as you are aware of how to check for issues, and are willing to spend some time fixing issues in the rare event that they do occur.

Maintaining Parabola
....................

Parabola is a very simple distro, in the sense that you are in full control and everything is made transparent to you. One consequence is that you also need to know what you are doing, and what you have done before. In general, keeping notes (such as what I have done with this page) can be very useful as a reference in the future (if you wanted to re-install it or install the distro on another computer, for example).

Cleaning the package cache
..........................

The following is very important as you continue to use, update and maintain your Parabola system:
 https://wiki.archlinux.org/index.php/Pacman#Cleaning_the_package_cache. Essentially, this guide talks about a directory that has to be cleaned once in a while, to prevent it from growing too big (it's a cache of old package information, updated automatically when you do anything in pacman).

To clean out all old packages that are cached:
 # pacman -Sc

The wiki cautions that this should be used with care. For example, since older packages are deleted from the repo, if you encounter issues and want to revert back to an older package then it's useful to have the caches available. Only do this if you are sure that you won't need it.

The wiki also mentions this method for removing everything from the cache, including currently installed packages that are cached:
 # pacman -Scc
 This is inadvisable, since it means re-downloading the package again if you wanted to quickly re-install it. This should only be used when disk space is at a premium.

pacman command equivalents
..........................

The following table lists other distro package manager commands, and their equivalent in pacman:
 https://wiki.archlinux.org/index.php/Pacman_Rosetta

your-freedom
............

your-freedom is a package specific to Parabola, and it is installed by default. What it does is conflict with packages from Arch that are known to be non-free (proprietary) software. When migrating from Arch (there is a guide on the Parabola wiki for migrating - converting - an existing Arch system to a Parabola system), installing your-freedom will also fail if these packages are installed, citing them as conflicts; the recommended solution is then to delete the offending packages, and continue installing your-freedom.

Add a user
..........

Based on https://wiki.archlinux.org/index.php/Users_and_Groups.

It is important (for security reasons) to create and use a non-root (non-admin) user account for everyday use. The default 'root' account is intended only for critical administrative work, since it has complete access to the entire operating system.

Read the entire document linked to above, and then continue.

Add your user:
 # useradd -m -G wheel -s /bin/bash yourusername
 Set a password:
 # passwd yourusername

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

systemd
.......

This is the name of the system used for managing services in Parabola. It is a good idea to become familiar with it. Read https://wiki.archlinux.org/index.php/systemd and https://wiki.archlinux.org/index.php/systemd#Basic_systemctl_usage to gain a full understanding. This is very important! Make sure to read them.

An example of a 'service' could be a webserver (such as lighttpd), or sshd (openssh), dhcp, etc. There are countless others.

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 explains the background behind the decision by Arch (Parabola's upstream supplier) to use systemd.

The manpage should also help:
 # man systemd
 The section on 'unit types' is especially useful.

According to the wiki, systemd 'journal' keeps logs of a size up to 10% of the total size your / partition takes up. on a 60GB root this would mean 6GB. That's not exactly practical, and can have performance implications later when the log gets too big. Based on instructions from the wiki, I will reduce the total size of the journal to 50MiB (the wiki recommends 50MiB).

Open /etc/systemd/journald.conf and find the line that says:
 #SystemMaxUse=
 Change it to say:
 SystemMaxUse=50M

The wiki also recommended a method for forwarding journal output to TTY 12 (accessible by pressing ctrl+alt+f12, and you use ctrl+alt+[F1-F12] to switch between terminals). I decided not to enable it.

Restart journald:
 # systemctl restart systemd-journald

The wiki recommends that if the journal gets too large, you can also simply delete (rm -Rf) everything inside /var/log/journald/* but recommends backing it up. This shouldn't be necessary, since you already set the size limit above and systemd will automatically start to delete older records when the journal size reaches it's limit (according to systemd developers).

Finally, the wiki mentions 'temporary' files and the utility for managing them.
 # man systemd-tmpfiles
 The command for 'clean' is:
 # systemd-tmpfiles --clean
 According to the manpage, this "cleans all files and directories with an age parameter". According to the Arch wiki, this reads information in /etc/tmpfiles.d/ and /usr/lib/tmpfiles.d/ to know what actions to perform. Therefore, it is a good idea to read what's stored in these locations to get a better understanding.

I looked in /etc/tmpfiles.d/ and found that it was empty on my system. However, /usr/lib/tmpfiles.d/ contained some files. The first one was etc.conf, containing information and a reference to this manpage:
 # man tmpfiles.d
 Read that manpage, and then continue studying all the files.

The systemd developers tell me that it isn't usually necessary to touch the systemd-tmpfiles utility manually at all.

Interesting repositories
........................

Parabola wiki at https://wiki.parabolagnulinux.org/Repositories#kernels mentions about a repository called [kernels] for custom kernels that aren't in the default base. It might be worth looking into what is available there, depending on your use case.

I enabled it on my system, to see what was in it. Edit /etc/pacman.conf and below the 'extra' section add:
 [kernels]
 Include = /etc/pacman.d/mirrorlist

Now sync with the repository:
 # pacman -Syy

List all available packages in this repository:
 # pacman -Sl kernels

In the end, I decided not to install anything from it but I kept the repository enabled regardless.

Setup a network connection in Parabola
......................................

Read https://wiki.archlinux.org/index.php/Configuring_Network.

Set the hostname
................

This should be the same as the hostname that you set in /etc/hostname when installing Parabola. You can also do it with systemd (do so now, if you like):
 # hostnamectl set-hostname yourhostname
 This writes the specified hostname to /etc/hostname. More information can be found in these manpages:
 # man hostname
 # info hostname
 # man hostnamectl

Add the same hostname to /etc/hosts, on each line. Example:
 127.0.0.1 localhost.localdomain localhost myhostname
 ::1 localhost.localdomain localhost myhostname

You'll note that I set both lines; the 2nd line is for IPv6. More and more ISPs are providing this now (mine does) so it's good to be forward-thinking here.

The hostname utility is part of the inetutils package and is in core/, installed by default (as part of base).

Network Status
..............

According to the Arch wiki, udev (https://wiki.archlinux.org/index.php/Udev) should already detect the ethernet chipset and load the driver for it automatically at boot time. You can check this in the "Ethernet controller" section when running this command:
 # lspci -v

Look at the remaining sections 'Kernel driver in use' and 'Kernel modules'. In my case it was as follows:
 Kernel driver in use: e1000e
 Kernel modules: e1000e

Check that the driver was loaded by issuing dmesg | grep module_name. In my case, I did:
 # dmesg | grep e1000e

Network device names
....................

According to https://wiki.archlinux.org/index.php/Configuring_Network#Device_names, it is important to note that the old interface names like eth0, wlan0, wwan0 and so on no longer apply. Instead, systemd creates device names starting with en (for enternet), wl (for wifi) and ww (for wwan) with a fixed identifier that systemd automatically generates. An example device name for your ethernet chipset would be enp0s25, where it is never supposed to change.

If you want to enable the old names (eth0, wlan0, wwan0, etc), the Arch wiki recommends adding net.ifnames=0 to your kernel parameters (in libreboot context, this would be accomplished by following the instructions in grub_cbfs).

For background information, read Predictable Network Interface Names (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/)

Show device names:
 # ls /sys/class/net

Changing the device names is possible (I chose not to do it):
 https://wiki.archlinux.org/index.php/Configuring_Network#Change_device_name

Network setup
.............

I actually chose to ignore most of Networking section on the wiki. Instead, I plan to set up LXDE desktop with the graphical network-manager client. Here is a list of network managers:
 https://wiki.archlinux.org/index.php/List_of_applications/Internet#Network_managers. If you need to, set a static IP address (temporarily) using the networking guide and the Arch wiki, or start the dhcpcd service in systemd. NetworkManager will be setup later, after installing LXDE.

System Maintenance
..................

Read https://wiki.archlinux.org/index.php/System_maintenance before continuing. Also read https://wiki.archlinux.org/index.php/Enhance_system_stability. This is important, so make sure to read them!

Install smartmontools (it can be used to check smart data. HDDs use non-free firmware inside, but it's transparent to you but the smart data comes from it. Therefore, don't rely on it too much):
 # pacman -S smartmontools
 Read https://wiki.archlinux.org/index.php/S.M.A.R.T. to learn how to use it.

Configuring the desktop
.......................

Based on steps from General Recommendations (https://wiki.archlinux.org/index.php/General_recommendations#Graphical_user_interface) on the Arch wiki. The plan is to use LXDE and LXDM/LightDM, along with everything else that you would expect on other distributions that provide LXDE by default.

Installing Xorg
...............

Based on https://wiki.archlinux.org/index.php/Xorg.

Firstly, install it!
 # pacman -S xorg-server
 I also recommend installing this (contains lots of useful tools, including xrandr):
 # pacman -S xorg-server-utils

Install the driver. For me this was xf86-video-intel on the ThinkPad X60. T60 and macbook11/21 should be the same.
 # pacman -S xf86-video-intel
 For other systems you can try:
 # pacman -Ss xf86-video- | less
 Combined with looking at your lspci output, you can determine which driver is needed. By default, Xorg will revert to xf86-video-vesa which is a generic driver and doesn't provide true hardware acceleration.

Other drivers (not just video) can be found by looking at the xorg-drivers group:
 # pacman -Sg xorg-drivers

Mostly you will rely on a display manager, but in case you ever want to start X without one:
 # pacman -S xorg-xinit

<optional>
    Arch wiki recommends installing these, for testing that X works:
    # pacman -S xorg-twm xorg-xclock xterm
    Refer to https://wiki.archlinux.org/index.php/Xinitrc. and test X:
    # startx
    When you are satisfied, type exit in xterm, inside the X session.
    Uninstall them (clutter. eww): # pacman -S xorg-xinit xorg-twm xorg-xclock xterm
 </optional>

Xorg keyboard layout
....................

Refer to https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg.

Xorg uses a different configuration method for keyboard layouts, so you will notice that the layout you set in /etc/vconsole.conf earlier might not actually be the same in X.

To see what layout you currently use, try this on a terminal emulator in X:
 # setxkbmap -print -verbose 10

In my case, I wanted to use the Dvorak (UK) keyboard which is quite different from Xorg's default Qwerty (US) layout.

I'll just say it now: XkbModel can be pc105 in this case (ThinkPad X60, with a 105-key UK keyboard). If you use an American keyboard (typically 104 keys) you will want to use pc104.

XkbLayout in my case would be gb, and XkbVariant would be dvorak.

The Arch wiki recommends two different methods for setting the keyboard layout:
 https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_X_configuration_files and
 https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_localectl.

In my case, I chose to use the configuration file method:
 Create the file /etc/X11/xorg.conf.d/10-keyboard.conf and put this inside:
 Section "InputClass"
         Identifier "system-keyboard"
         MatchIsKeyboard "on"
         Option "XkbLayout" "gb"
         Option "XkbModel" "pc105"
         Option "XkbVariant" "dvorak"
 EndSection

For you, the steps above may differ if you have a different layout. If you use a US Qwerty keyboard, then you don't even need to do anything (though it might help, for the sake of being explicit).

Install LXDE
............

Desktop choice isn't that important to me, so for simplicity I decided to use LXDE. It's lightweight and does everything that I need. If you would like to try something different, refer to https://wiki.archlinux.org/index.php/Desktop_environment

Refer to https://wiki.archlinux.org/index.php/LXDE.

Install it, choosing 'all' when asked for the default package list:
 # pacman -S lxde obconf

I didn't want the following, so I removed them:
 # pacman -R lxmusic lxtask

I also lazily installed all fonts:
 # pacman -S $(pacman -Ssq ttf-)

LXDE comes with a terminal. You probably want a browser to go with that; I choose GNU IceCat, part of the GNU project (https://gnu.org/):
 # pacman -S icecat
 And a mail client:
 # pacman -S icedove

In IceCat, go to Preferences :: Advanced and disable GNU IceCat Health Report.

I also like to install these:
 # pacman -S xsensors stress htop

Enable LXDM (the default display manager, providing a graphical login):
 # systemctl enable lxdm.service
 It will start when you boot up the system. To start it now, do:
 # systemctl start lxdm.service

Log in with your standard (non-root) user that you created earlier. It is advisable to also create an xinitrc rule in case you ever want to start lxde without lxdm. Read https://wiki.archlinux.org/index.php/Xinitrc.

Open LXterminal:
 $ cp /etc/skel/.xinitrc ~
 Open .xinitrc and add the following plus a line break at the bottom of the file.
 # Probably not needed. The same locale info that we set before
 # Based on advice from the LXDE wiki export LC_ALL=en_GB.UTF-8
 export LANGUAGE=en_GB.UTF-8
 export LANG=en_GB.UTF-8

 # Start lxde desktop
 exec startlxde
 Now make sure that it is executable:
 $ chmod +x .xinitrc

LXDE - clock
............

In Digital Clock Settings (right click the clock) I set the Clock Format to %Y/%m/%d %H:%M:%S

LXDE - font
...........

NOTE TO SELF: come back to this later.

LXDE - screenlock
.................

Arch wiki recommends to use xscreensaver:
 # pacman -S xscreensaver

Under Preferences :: Screensaver in the LXDE menu, I chose Mode: Blank Screen Only, setting Blank After, Cycle After and Lock Screen After (checked) to 10 minutes.

You can now lock the screen with Logout :: Lock Screen in the LXDE menu.

LXDE - automounting
...................

Refer to https://wiki.archlinux.org/index.php/File_manager_functionality.

I chose to ignore this for now. NOTE TO SELF: come back to this later.

LXDE - disable suspend
......................

When closing the laptop lid, the system suspends. This is annoying at least to me. NOTE TO SELF: disable it, then document the steps here.

LXDE - battery monitor
......................

Right click lxde panel and Add/Remove Panel Items. Click Add and select Battery Monitor, then click Add. Close and then right-click the applet and go to Battery Monitor Settings, check the box that says Show Extended Information. Now click Close. When you hover the cursor over it, it'll show information about the battery.

LXDE - Network Manager
......................

Refer to https://wiki.archlinux.org/index.php/LXDE#Network_Management. Then I read: https://wiki.archlinux.org/index.php/NetworkManager.

Install Network Manager:
 # pacman -S networkmanager

You will also want the graphical applet:
 # pacman -S network-manager-applet
 Arch wiki says that an autostart rule will be written at /etc/xdg/autostart/nm-applet.desktop

I want to be able to use a VPN at some point, so the wiki tells me to do:
 # pacman -S networkmanager-openvpn

LXDE uses openbox, so I refer to:
 https://wiki.archlinux.org/index.php/NetworkManager#Openbox.

It tells me for the applet I need:
 # pacman -S xfce4-notifyd gnome-icon-theme
 Also, for storing authentication details (wifi) I need:
 # pacman -S gnome-keyring

I wanted to quickly enable networkmanager:
 # systemctl stop dhcpcd
 # systemctl start NetworkManager
 Enable NetworkManager at boot time:
 # systemctl enable NetworkManager

Restart LXDE (log out, and then log back in).

I added the volume control applet to the panel (right click panel, and add a new applet). I also later changed the icons to use the gnome icon theme, in lxappearance.

Installing Trisquel GNU/Linux-libre with full disk encryption (including /boot)
-------------------------------------------------------------------------------

Libreboot on x86 uses the GRUB payload (http://www.coreboot.org/Payloads#GRUB_2) by default, which means that the GRUB configuration file (where your GRUB menu comes from) is stored directly alongside libreboot and its GRUB payload executable, inside the flash chip. In context, this means that installing distributions and managing them is handled slightly differently compared to traditional BIOS systems.

On most systems, the /boot partition has to be left unencrypted while the others are encrypted. This is so that GRUB, and therefore the kernel, can be loaded and executed since the firmware can't open a LUKS volume. Not so with libreboot! Since GRUB is already included directly as a payload, even /boot can be encrypted. This protects /boot from tampering by someone with physical access to the system.

This works in Trisquel 7, and probably Trisquel 6. Boot the 'net installer' (Install Trisquel in Text Mode). How to boot a GNU/Linux installer (How to install GNU/Linux on a libreboot system).

NOTE: When finishing implementing this setup, if the boot stalls when running cryptomount -a, try removing the DVD drive (on thinkpads).

This guide is *only* for the GRUB payload. If you use the depthcharge payload, ignore this section entirely.

Set a strong user password (lots of lowercase/uppercase, numbers and symbols).

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

When the installer asks you to set up encryption (ecryptfs) for your home directory, select 'Yes' if you want to: LUKS is already secure and performs well. Having ecryptfs on top of it will add noticeable performance penalty, for little security gain in most use cases. This is therefore optional, and not recommended. Choose 'no'.

Your user password should be different from the LUKS password which you will set later on. Your LUKS password should, like the user password, be secure.

Partitioning
............

Choose 'Manual' partitioning:

  * Select drive and create new partition table

  * Single large partition. The following are mostly defaults:

       * Use as: physical volume for encryption

       * Encryption: aes

       * key size: 256

       * IV algorithm: xts-plain64

       * Encryption key: passphrase

       * erase data: Yes (only choose 'No' if it's a new drive that doesn't contain your private data)

  * Select 'configure encrypted volumes'

       * Create encrypted volumes

       * Select your partition

       * Finish

       * Really erase: Yes

       * (erase will take a long time. be patient)

       * (if your old system was encrypted, just let this run for about a minute to make sure that the LUKS header is wiped out)

  * Select encrypted space:

       * use as: physical volume for LVM

       * Choose 'done setting up the partition'

  * Configure the logical volume manager:

       * Keep settings: Yes

  * Create volume group:

       * Name: matrix (you can use whatever you want here, this is just an example)

       * Select crypto partition

  * Create logical volume

       * select matrix (or whatever you named it before)

       * name: root (you can use whatever you want here, this is just an example)

       * size: default, minus 2048 MB

  * Create logical volume

       * select matrix (or whatever you named it before)

       * name: swap (you can use whatever you want here, this is just an example)

       * size: press enter

Further partitioning
....................

Now you are back at the main partitioning screen. You will simply set mountpoints and filesystems to use.

  * LVM LV root

       * use as: ext4

       * mount point: /

       * done setting up partition

  * LVM LV swap

       * use as: swap area

       * done setting up partition

  * Now you select 'Finished partitioning and write changes to disk'.

Kernel
......

Installation will ask what kernel you want to use. linux-generic is fine.

Tasksel
.......

Choose "Trisquel Desktop Environment" if you want GNOME, "Trisquel-mini Desktop Environment" if you want LXDE or "Triskel Desktop Environment" if you want KDE. If you want to have no desktop (just a basic shell) when you boot or if you want to create your own custom setup, then choose nothing here (don't select anything). You might also want to choose some of the other package groups; it's up to you.

Postfix configuration
.....................

If asked, choose "No Configuration" here (or maybe you want to select something else. It's up to you.)

Install the GRUB boot loader to the master boot record
......................................................

Choose 'Yes'. It will fail, but don't worry. Then at the main menu, choose 'Continue without a bootloader'. You could also choose 'No'. Choice is irrelevant here.

You do not need to install GRUB at all, since in libreboot you are using the GRUB payload (for libreboot) to boot your system directly.

Clock UTC
.........

Just say 'Yes'.

Booting your system
...................

At this point, you will have finished the installation. At your GRUB payload, press C to get to the command line.

Do that:
 grub> cryptomount -a
 grub> set root='lvm/matrix-root'
 grub> linux /vmlinuz root=/dev/mapper/matrix-root cryptdevice=/dev/mapper/matrix-root:root
 grub> initrd /initrd.img
 grub> boot

ecryptfs
........

If you didn't encrypt your home directory, then you can safely ignore this section.

Immediately after logging in, do that:
 $ sudo ecryptfs-unwrap-passphrase

This will be needed in the future if you ever need to recover your home directory from another system, so write it down and keep the note somewhere secret. Ideally, you should memorize it and then burn the note (or not even write it down, and memorize it still)>

Modify grub.cfg (CBFS)
......................

Now you need to set it up so that the system will automatically boot, without having to type a bunch of commands.

Modify your grub.cfg (in the firmware) using this tutorial; just change the default menu entry 'Load Operating System' to say this inside:

cryptomount -a
 set root='lvm/matrix-root'
 linux /vmlinuz root=/dev/mapper/matrix-root cryptdevice=/dev/mapper/matrix-root:root
 initrd /initrd.img

Without specifying a device, the -a parameter tries to unlock all detected LUKS volumes. You can also specify -u UUID or -a (device).

Additionally, you should set a GRUB password. This is not your LUKS password, but it's a password that you have to enter to see GRUB. This protects your system from an attacker simply booting a live USB and re-flashing your firmware. This should be different than your LUKS passphrase and user password.

Use of the diceware method is recommended, for generating secure passphrases (as opposed to passwords).

The GRUB utility can be used like so:
 $ grub-mkpasswd-pbkdf2

Give it a password (remember, it has to be secure) and it'll output something like:
 grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711

Use of the diceware method is recommended, for generating secure passphrases (instead of passwords).

Put that in the grub.cfg (the one for CBFS inside the ROM) before the 'Load Operating System' menu entry like so (example):

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711

MAKE SURE TO DO THIS ON grubtest.cfg *BEFORE* DOING IT ON grub.cfg. Then select the menu entry that says Switch to grubtest.cfg and test that it works. Then copy that to grub.cfg once you're satisfied. WHY? BECAUSE AN INCORRECTLY SET PASSWORD CONFIG MEANS YOU CAN'T AUTHENTICATE, WHICH MEANS 'BRICK'.

(emphasis added, because it's needed. This is a common roadblock for users)

Obviously, replace it with the correct hash that you actually got for the password that you entered. Meaning, not the hash that you see above!

After this, you will have a modified ROM with the menu entry for cryptomount, and the entry before that for the GRUB password. Flash the modified ROM using this tutorial.

Troubleshooting Trisquel
........................

A user reported issues when booting with a docking station attached on an X200, when decrypting the disk in GRUB. The error AHCI transfer timed out was observed. The workaround was to remove the docking station.

Further investigation revealed that it was the DVD drive causing problems. Removing that worked around the issue.

"sudo wodim -prcap" shows information about the drive:
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/sr0
Using /dev/cdrom of unknown capabilities
Device type    : Removable CD-ROM
Version        : 5
Response Format: 2
Capabilities   :
Vendor_info    : 'HL-DT-ST'
Identification : 'DVDRAM GU10N    '
Revision       : 'MX05'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.

Drive capabilities, per MMC-3 page 2A:

  Does read CD-R media
  Does write CD-R media
  Does read CD-RW media
  Does write CD-RW media
  Does read DVD-ROM media
  Does read DVD-R media
  Does write DVD-R media
  Does read DVD-RAM media
  Does write DVD-RAM media
  Does support test writing

  Does read Mode 2 Form 1 blocks
  Does read Mode 2 Form 2 blocks
  Does read digital audio blocks
  Does restart non-streamed digital audio reads accurately
  Does support Buffer-Underrun-Free recording
  Does read multi-session CDs
  Does read fixed-packet CD media using Method 2
  Does not read CD bar code
  Does not read R-W subcode information
  Does read raw P-W subcode data from lead in
  Does return CD media catalog number
  Does return CD ISRC information
  Does support C2 error pointers
  Does not deliver composite A/V data

  Does play audio CDs
  Number of volume control levels: 256
  Does support individual volume control setting for each channel
  Does support independent mute setting for each channel
  Does not support digital output on port 1
  Does not support digital output on port 2

  Loading mechanism type: tray
  Does support ejection of CD via START/STOP command
  Does not lock media on power up via prevent jumper
  Does allow media to be locked in the drive via PREVENT/ALLOW command
  Is not currently in a media-locked state
  Does not support changing side of disk
  Does not have load-empty-slot-in-changer feature
  Does not support Individual Disk Present feature

  Maximum read  speed:  4234 kB/s (CD  24x, DVD  3x)
  Current read  speed:  4234 kB/s (CD  24x, DVD  3x)
  Maximum write speed:  4234 kB/s (CD  24x, DVD  3x)
  Current write speed:  4234 kB/s (CD  24x, DVD  3x)
  Rotational control selected: CLV/PCAV
  Buffer size in KB: 1024
  Copy management revision supported: 1
  Number of supported write speeds: 4
  Write speed # 0:  4234 kB/s CLV/PCAV (CD  24x, DVD  3x)
  Write speed # 1:  2822 kB/s CLV/PCAV (CD  16x, DVD  2x)
  Write speed # 2:  1764 kB/s CLV/PCAV (CD  10x, DVD  1x)
  Write speed # 3:   706 kB/s CLV/PCAV (CD   4x, DVD  0x)

Supported CD-RW media types according to MMC-4 feature 0x37:
  Does write multi speed       CD-RW media
  Does write high  speed       CD-RW media
  Does write ultra high speed  CD-RW media
  Does not write ultra high speed+ CD-RW media

Git
===

Building libreboot from source
------------------------------

This section relates to building libreboot from source, and working with the git repository.

Install build dependencies
..........................

For Trisquel 7, you can run the following command:
 $ sudo ./build dependencies trisquel7

For Parabola, you can run the following command:
 $ sudo ./build dependencies parabola
 or:
 # ./build dependencies parabola

For other GNU/Linux distributions, you can adapt the existing scripts.

Get the full source code from metadata (git clone)
..................................................

If you downloaded libreboot from git, then there are some steps to download and patch the source code for all relevant dependencies. The archive in the git repository used to be available as a tarball called 'libreboot_meta.tar.gz'. It contains 'metadata' (scripts) which define how the source was created (where it came from).

You can use the scripts included to download everything.

First, install the build dependencies.

Since libreboot makes extensive use of git, you need to configure git properly. If you have not yet configured git, then the minimum requirement is:
 $ git config --global user.name ``Your Name''
 $ git config --global user.email your@emailaddress.com
 This is what will also appear in git logs if you ever commit your own changes to a given repository. For more information, see http://git-scm.com/doc.

Another nice config for you (optional, but recommended):
 $ git config --global core.editor nano
 $ git config --global color.status auto
 $ git config --global color.branch auto
 $ git config --global color.interactive auto
 $ git config --global color.diff auto

After that, run the script:
 $ ./download all

What this did was download everything (grub, coreboot, memtest86+, bucts, flashrom) at the versions last tested for this release, and patch them. Read the script in a text editor to learn more.

To build the ROM images, see build.

How to build ``bucts'' (for LenovoBIOS X60/X60S/X60T/T60)
.........................................................

This is for Lenovo BIOS users on the ThinkPad X60/X60S, X60 Tablet and T60. If you have coreboot or libreboot running already, ignore this.

BUC.TS isn't really specific to these laptops, but is a bit inside the a register in the chipset on some Intel systems.

Bucts is needed when flashing in software the X60/X60S/X60T/T60 ROM while Lenovo BIOS is running; external flashing will be safe regardless. Each ROM contains identical data inside the two final 64K region in the file*. This corresponds to the final two 64K regions in the flash chip. Lenovo BIOS will prevent you from writing the final one, so running ``bucts 1'' will set the system to boot from the other block instead (which is writeable along with everything beneath it when using a patched flashrom. see build_flashrom). After shutting down and booting up after the first flash of libreboot, the final 64K block is writeable so you flash the ROM again with an unpatched flashrom and run ``bucts 0'' to make the system boot from the normal (highest) block again.

*Libreboot ROM images have identical data in those two 64KiB regions because dd is used to do that, by the build system. If you're building from upstream (coreboot), you have to do it manually.

BUC.TS is backed up (powered) by the NVRAM battery (or CMOS battery, as some people call it). On thinkpads, this is typically in a yellow plastic package with the battery inside, connected via power lines to the mainboard. Removing that battery removes power to BUC.TS, resetting the bit back to 0 (if you previously set it to 1).

``BUC'' means ``Backup Control'' (it's a register) and ``TS'' means ``Top Swap'' (it's a status bit). Hence ``bucts'' (BUC.TS). TS 1 and TS 0 corresponds to bucts 1 and bucts 0.

If you have the binary release archive, you'll find executables under ./bucts/. Otherwise if you need to build from source, continue reading.

First, install the build dependencies.

To build bucts, do this in the main directory:
 $ ./build module bucts

To statically compile it, do this:
 $ ./build module bucts static

The ``builddeps'' script in libreboot_src also makes use of builddeps-bucts.

How to build flashrom
.....................

Flashrom is the utility for flashing/dumping ROM images. This is what you will use to install libreboot.

Flashrom source code is included in libreboot_src.tar.xz and libreboot_util.tar.xz.
 If you downloaded from git, follow build_meta before you proceed.

If you are using the binary release archive, then there are already binaries included under ./flashrom/. The flashing scripts will try to choose the correct one for you. Otherwise if you wish to re-build flashrom from source, continue reading.

First, install the build dependencies.

To build it, do the following in the main directory:
 $ ./build module flashrom

To statically compile it, do the following in the main directory:
 $ ./build module flashrom static

After you've done that, under ./flashrom/ you will find the following executables:

  * flashrom

       * For flashing while coreboot or libreboot is running.

  * flashrom_lenovobios_sst

       * This is patched for flashing while Lenovo BIOS is running on an X60 or T60 with the SST25VF016B (SST) flash chip.

  * flashrom_lenovobios_macronix

       * This is patched for flashing while Lenovo BIOS is running on an X60 or T60 with the MX25L1605D (Macronix) flash chip.

The ``builddeps'' script in libreboot_src also makes use of builddeps-flashrom.

Configuring libreboot
.....................

Before building a ROM in libreboot (or coreboot, for that matter), you need to configure it. Configuration files should already be included, so you don't need to do anything. This information is only for reference. If you are updating or modifying coreboot-libre, and need to update the configs in any way, refer to newboard_libreboot.

If you've already built a kernel before, you know how to use this interface.

dmidecode
.........

There is certain information that can be useful to enter in particular:

  * Local version string

  * SMBIOS Serial Number

  * SMBIOS Manufacturer

  * SMBIOS Version

  * SMBIOS Product name

This information can be obtained using:
 $ sudo dmidecode
 # dmidecode

Specifically, it's good practise to enter the same information for libreboot that you found when running this with the original BIOS or firmware. libreboot has already done this for you. This information is for reference, in the hope that it will be useful.

In practise, this information is useless and you can just leave it on the defaults that coreboot uses (this is what libreboot does, on most boards).

GRUB payload
............

GRUB is one of the payloads that libreboot targets.

Configurations are then saved as files called ``.config''. Copies of each configuration used for each system type by the libreboot build scripts are stored in resources/libreboot/config/grub/

Generic configuration (file: resources/libreboot/config/payload/board/config)

  * General setup / Expert mode = enable

  * General / Use CMOS for configuration values = enable

  * Mainboard / Mainboard vendor = Name of manufacturer

  * Mainboard / Mainboard model = Model name

  * Mainboard / ROM chip size = Size of chip

  * Chipset / Include CPU microcode in CBFS = Do not include microcode updates

  * Devices / Use native graphics initialization = enable

  * Display / Keep VESA framebuffer = disable (disable for text-mode graphics, enable for coreboot vesa framebuffer)

       * Libreboot provides this with text-mode enabled by default, but it automatically patches a copy of the config at build time to enable coreboot framebuffer for a separate set of ROM images, in each system.

  * Generic Drivers / USB 2.0 EHCI debug dongle support = Enable

  * Generic Drivers / Enable early (pre-RAM) usbdebug = Enable

  * Generic Drivers / Type of dongle = Net20DC or compatible

  * Generic Drivers / Digitizer = Present

  * Console / USB dongle console output = enable

  * Payload / Add a payload = An ELF executable payload

  * Payload / Payload path and filename = grub.elf

Now go back into Devices:

  * Devices / Run VGA Option ROMs = disable

  * Devices / Run Option ROMs on PCI devices = disable

The resulting .config file was saved as resources/libreboot/config/payload/board/config and is used by the build scripts for this system.

Configuring libreboot for chromebooks - Depthcharge payload
...........................................................

Depthcharge is one of the payloads that libreboot targets.

Configurations are then saved as files called ``.config''. Copies of each configuration used for each system type by the libreboot build scripts are stored in resources/libreboot/config/depthcharge/

Configuration for chromebooks (file: resources/libreboot/config/depthcharge/board/config)

  * Mainboard / Mainboard vendor = Google

  * Mainboard / Mainboard model = Name of board

  * Chipset / ChromeOS / Build for ChromeOS = enable

  * Chipset / ChromeOS / Verify firmware with vboot. = disable

  * Payload / Add a payload = An ELF executable payload

  * Payload / Payload path and filename = depthcharge.elf

The resulting .config file was saved as resources/libreboot/config/depthcharge/board/config and is used by the build scripts for this system.

How to build the ROM images
...........................

You don't need to do much, as there are scripts already written for you that can build everything automatically.

You can build libreboot from source on a 32-bit (i686) or 64-bit (x86_64) system. Recommended (if possible): x86_64. ASUS KFSN4-DRE has 64-bit CPUs. On a ThinkPad T60, you can replace the CPU (Core 2 Duo T5600, T7200 or T7600. T5600 recommended) for 64-bit support. On an X60s, you can replace the board with one that has a Core 2 Duo L7400 (you could also use an X60 Tablet board with the same CPU). On an X60, you can replace the board with one that has a Core 2 Duo T5600 or T7200 (T5600 is recommended). All MacBook2,1 laptops are 64-bit, as are all ThinkPad X200, X200S, X200 Tablet, R400, T400 and T500 laptops. Warning: MacBook1,1 laptops are all 32-bit only.

First, install the build dependencies.

If you downloaded libreboot from git, refer to build_meta.

Build all of the components used in libreboot:
 $ ./build module all

You can also build each modules separately, using ./build module modulename. To see the possible values for modulename, use:
 $ ./build module list

After that, build the ROM images (for all boards):
 $ ./build roms withgrub
 Alternatively, you can build for a specific board or set of boards. For example:
 $ ./build roms withgrub x60
 $ ./build roms withgrub x200_8mb
 $ ./build roms withgrub x60 x200_8mb
 The list of board options can be found by looking at the directory names in resources/libreboot/config/grub/.

For those boards which use the depcharge payload, you must use: $ ./build roms withdepthcharge
 You can also build for a specific board or set of boards. For example:
 $ ./build roms withdepthcharge veyron_speedy

To clean (reverse) everything, do the following:
 $ ./build clean all

The ROM images will be stored under bin/payload/, where payload could be grub, depthcharge, seabios, or whatever other payload those images were built for.

Preparing release archives (optional)
.....................................

This is only confirmed to work (tested) in Trisquel 7. Parabola *fails* at this stage (for now). For all other distros, YMMV.

This is mainly intended for use with the git repository. These commands will work in the release archive (_src), unless otherwise noted below.

The archives will appear under release/${version}/; ${version} will either be set using git describe or, if a version file already exists (_src release archive), then it will simply re-use that.

Tag the current commit, and that version will appear in both the ${version} string on the directory under release/, and in the file names of the archives. Otherwise, whatever git uses for git describe --tags HEAD will be used.

Utilities (static executables):
 $ ./build release util

Archive containing flashrom and bucts source code:
 $ ./build release tobuild

Documentation archive (does not work on _src release archive, only git):
 $ ./build release docs

ROM image archives:
 $ ./build release roms

Source code archive:
 $ ./build release src

SHA512 sums of all other release archives that have been generated:
 $ ./build release sha512sums

If you are building on an i686 host, this will build statically linked 32-bit binaries in the binary release archive that you created, for: nvramtool, cbfstool, ich9deblob, cbmem.

If you are building on an x86_64 host, this will build statically linked 32- *and* 64-bit binaries for cbmem, ich9deblob, cbfstool and nvramtool.

To include statically linked i686 and x86_64 binaries for bucts and flashrom, you will need to build them on a chroot, a virtual system or a real system where the host uses each given architecture. These packages are difficult to cross-compile, and the libreboot project is still figuring out how to deal with them.

The same applies if you want to include statically linked flashrom binaries for ARM.

  * cbfstool

  * ich9gen

  * ich9deblob

  * flashrom

If you are building binaries on a live system or chroot (for flashrom/bucts), you can use the following to statically link them:
 $ ./build module flashrom static
 $ ./build module bucts static

The same conditions as above apply for ARM (except, building bucts on ARM is pointless, and for flashrom you only need the normal executable since the lenovobios_sst and _macronix executables are meant to run on an X60/T60 while lenovo bios is present, working around the security restrictions).

The command that you used for generating the release archives will also run the following command:
 $ ./build release tobuild
 The archive tobuild.tar.xz will have been created under release/, containing bucts, flashrom and all other required resources for building them.

You'll find that the files libreboot_util.tar.xz and libreboot_src.tar.xz have been created, under release/.

The ROM images will be stored in separate archives for each system, under release/rom/.

Maintaining libreboot
---------------------

This section relates to maintaining libreboot.

Do not follow anything here to the letter; is it only a rough guide representing how libreboot is maintained (for reference).

This section of the documentation applies mainly to the development version of libreboot, which is hosted in a git repository. It is not intended for the release versions of libreboot.

Overview
........

The way the libreboot project is run is very similar to how a GNU/Linux distribution project is run (but for the boot firmware, not your operating system). Thus, libreboot is a coreboot distribution.

This page demonstrates on a high level how libreboot is maintained, how the project is run, how everything goes together, etc. For a more detailed guide, refer to each subsection for the various components/modules used in libreboot.

Updating coreboot-libre
.......................

NOTE: it helps to own all libreboot-compatible systems here, or have reliable (and fast) access to a team of testers.

Coreboot-libre is the name of the deblobbed coreboot sources used in libreboot. It is also the name of the collection of scripts used for deblobbing coreboot, on each new update.

This section shows an example of how to update (re-base) to the latest version of coreboot, how to update the deblobbing scripts, and so on. This does not teach you how to change what custom patches are used, nor does it tell you how to add new boards to libreboot. It assumes that you simply want to re-base to the latest version (for instance, there could be bug fixes that you want). For those things not listed in this section, you can refer to other sections on this page instead.

Open these files in your editor (you will most likely be editing them):

  * resources/scripts/helpers/download/coreboot

  * resources/scripts/helpers/build/module/coreboot

  * resources/utilities/coreboot-libre/deblob

  * resources/utilities/coreboot-libre/nonblobs

  * resources/utilities/coreboot-libre/nonblobs_notes

  * resources/scripts/helpers/build/roms/helper

  * resources/scripts/helpers/build/roms/withgrub

If you already had a coreboot/ directory in your libreboot tree, delete it:
 $ rm -Rf coreboot/

Firstly, download coreboot. Do not use ./download coreboot for this, just clone coreboot, as it does in that script, like so:
 $ git clone http://review.coreboot.org/coreboot

$ cd coreboot/
 Get the ID of the latest commit in this clone, by reading the commit ID using e.g.:
 $ git log
 In resources/scripts/helpers/download/coreboot you will find a line that says git reset --hard and then a commit ID next to it. Replace this with the commit ID of the latest commit from the coreboot version that you just downloaded.

You must also checkout the vboot submodule:
 $ git submodule update --init --checkout -- 3rdparty/vboot/

Delete the .git* resources. For example:
 $ rm -Rf .git* 3rdparty/*/.git*
 ...this is to avoid the deblobbing script from picking up files in there as blobs, which would be only false positives and increase the amount of time taken. Now come out of coreboot:
 $ cd ../

Check all coreboot file names/paths in deblob; if any of them no longer exist at that name/path in the coreboot tree that you downloaded, delete the reference(s) in deblob.

Check all coreboot file names/paths in nonblobs; if any of them no longer exist at that name/path in the coreboot tree that you downloaded, delete the reference in nonblobs.

Now, back in the main root directory of libreboot (git repository), run the deblob script. This is to prevent the findblobs scripts from finding the blobs that are already deleted when running the deblob script. Like so:
 $ ./resources/utilities/coreboot-libre/deblob

Now search for new blobs:
 $ cd resources/utilities/coreboot-libre/
 $ ./findblobs
 WARNING: this will take a *long* time. Be patient! What this will do is look through the coreboot source directory, looking for blobs. It will not find the blobs that you deleted before (because they no longer exist), and it will ignore any files listed in nonblobs.

Once the findblobs script has finished, check the file tocheck (from the root, this will be resources/utilities/coreboot-libre/tocheck). These are the files detected as blobs; some might be blobs, some not. The findblobs script doesn't know how to determine between blobs and non-blobs, it only knows patterns. Distinguishing between blobs and non-blobs must be performed by you, the human being.

  * Files in tocheck that you identify as blobs, should be added appropriately to resources/utilities/coreboot-libre/deblob

  * Files in tocheck that you identify as non-blobs, should be added appropriately to resources/utilities/coreboot-libre/nonblobs - also, if you feel it necessary, add an explanation of it in resources/utilities/coreboot-libre/nonblobs_notes

Now come back to the main libreboot root directory (root of the git clone). If you are still in resources/utilities/coreboot-libre/ for instance, you would do something like:
 $ cd ../../../

Now delete the coreboot directory:
 $ rm -Rf coreboot/

Download coreboot again, only this time, using the download script. The download script also applies custom patches to coreboot (see resources/scripts/helpers/download/coreboot); if they do not apply anymore, you will have to re-base them and then update resources/scripts/helpers/download/coreboot accordingly. Anyway, download coreboot like so:
 $ ./download coreboot

If the custom patches no longer apply, and you have to re-base (or replace?) some patches, please do this in coreboot upstream, not in libreboot. Then re-include new patches from upstream, into libreboot. Here is coreboot's guide for contributing patches:
 http://www.coreboot.org/Git.

Update all configs:
 $ ./build config grubupdate
 $ ./build config dcupdate
 This simply takes all of the coreboot .config files from resources/libreboot/config/ and does make oldconfig on them. It usually works. If it doesn't, you'll need to recreate those configs from scratch using ./build config grubreplace or ./build config dcreplace (optionally add a config name), or ./build config grubmodify or ./build config dcmodify (ditto) (see config)

Finally, build *all* ROM images using the instructions at Git, to verify that everything still builds.

Once you've verified that building isn't broken, test *all* boards (you don't need to test all ROM images, only one vesafb and one txtmode image for each configuration). If you do not have all systems supported in libreboot, then you will need to get other testers for those boards.

If you have established a build issue, or a board no longer works (booting issues, bugs during/after boot, etc), you'll need to fix it upstream: http://www.coreboot.org/Git and then re-update coreboot (or apply patches from upstream).

You should also test the resulting ROM images from building with the new or modified coreboot revision.

Adding a new board to libreboot
...............................

Make sure that the board is supported, and that the patches are included (if there are custom patches that you need). Add configs for it like so (for GRUB payload):
 $ ./build config grubreplace payload/boardname
 Alternatively, for depthcharge payload:
 $ ./build config dcreplace payload/boardname

This can also be used for replacing an existing config.

Configure the board. Make sure to add the steps to the config section in Git.

When you're done, the config will be stored in resources/libreboot/config/. Now build-test it and then check that it actually works.

The following scripts may also need to be modified before building: resources/scripts/helpers/build/roms/withgrub and resources/scripts/helpers/build/roms/helper

The following can be used when updating coreboot-libre (GRUB payload):
 $ ./build config grubupdate
 You must also do this for boards that use the depthcharge payload:
 $ ./build config dcupdate
 (adding a board name on the end is optional, for either of these)

The following can be used if you want to modify an existing configuration (GRUB payload):
 $ ./build config grubmodify
 For those boards which use the depthcharge payload:
 $ ./build config dcmodify
 (adding a board name on the end is optional)

Examples (GRUB payload):
 $ ./build config grubmodify x60
 $ ./build config grubreplace x60
 $ ./build config grubupdate x60
 $ ./build config grubmodify kfsn4-dre
 $ ./build config grubreplace kfsn4-dre
 $ ./build config grubupdate kfsn4-dre

Examples (depthcharge payload):
 $ ./build config dcmodify veyron_speedy
 $ ./build config dcreplace veyron_speedy
 $ ./build config dcupdate veyron_speedy

Add/remove/modify patches in coreboot-libre
...........................................

Under resources/scripts/helpers/download/coreboot you can find the instructions used for patching coreboot.

Modify the commit ID on the git reset --hard line accordingly, and update the list of patches used accordingly. Do not cherry-pick from review.coreboot.org directly; instead, include the diff in resources/libreboot/patch/ and use git am (you can get the diff by using git-format-patch).

When you're done, simply download coreboot again:
 $ ./download coreboot

Finally, re-build the parts from coreboot that are used by the build system (also builds GCC):
 $ ./build module coreboot

Before running the above command, you can save time by copying out the crossgcc that you compiled before (from coreboot/util/crossgcc/) and then putting it back. After you've done that, run everything in resources/scripts/helpers/build/module/coreboot except for the part that builds GCC. Only do this if the version is correct.

You should also test the resulting ROM images from building with the new or modified coreboot revision.

Updating GRUB
.............

$ rm -Rf grub/
 $ git clone git://git.savannah.gnu.org/grub.git
 $ cd grub/
 $ git log

Open the file resources/scripts/helpers/download/grub and replace the commit ID on the line that performs git reset --hard with the commit ID of the GRUB revision that you just downloaded.

$ cd ../
 $ ./download grub

If it fails because of merge conflicts, you'll need to re-base or (as appropriate) remove the offending patch(es) in resources/scripts/helpers/download/grub.

Finally, verify that it will build:
 $ ./build module grub

Since GRUB is the payload in libreboot, you should also build the ROM images and test them, with this different GRUB version that you have prepared.

Change how the GRUB payload (grub.elf) is built (utility: grub-assemble)
........................................................................

Look in resources/utilities/grub-assemble/.

gen.sh creates ELF executables of GRUB with different configurations: text-mode or framebuffer mode in coreboot. Essentially, the text-mode version has no background nor any custom fonts, and contains MemTest86+. You probably don't need to modify these files at all.

modules.conf defines which modules will be included in the GRUB ELF executable.

Since GRUB is the payload in libreboot, you should also build the ROM images and test them, with this different GRUB version that you have prepared.

Modify the configuration used in GRUB
.....................................

Look in resources/scripts/helpers/build/roms/withgrub to see how the GRUB configuration files are generated.

You might need to modify this. You can also modify the default configuration by making changes to the files under resources/grub/config/

Since GRUB is the payload in libreboot, you should also build the ROM images and test them, with this different GRUB version that you have prepared.

Updating depthcharge
....................

The script to download depthcharge is: resources/scripts/helpers/download/depthcharge.

Patches are in resources/depthcharge/patch/.

The configuration used for depthcharge is located in depthcharge/board. Each board has a defconfig Kconfig configuration and a fmap.dts FMAP device-tree configuration. Those shouldn't need much attention, but when needed, it's best to modify them in the depthcharge tree (with patches) to keep things in one place.

Updating flashrom
.................

Modify these files: resources/scripts/helpers/download/flashrom and resources/scripts/helpers/build/module/flashrom.

Patches are in resources/flashrom/patch/

Updating bucts
..............

bucts doesn't really need updating, but the patches are in resources/bucts/patch, the download script is resources/scripts/helpers/download/bucts and the build script is resources/scripts/helpers/build/module/bucts.

Updating MemTest86+
...................

MemTest86+ doesn't really need updating, but the patches are in resources/memtest86plus/patch, the download script is resources/scripts/helpers/download/memtest86plus and the build script is resources/scripts/helpers/build/module/memtest86plus.

In the download script for memtest86plus, make sure to update the checksum that it matches for the downloaded source tarball.

Hardware security
=================

Security topics:

Security on the ThinkPad X60
----------------------------

Hardware modifications to enhance security on the ThinkPad X60. This tutorial is incomplete at the time of writing.

Hardware requirements
.....................

  * An X60

  * screwdriver

  * (in a later version of this tutorial: soldering iron and scalpel)

Software requirements
.....................

  * none (at least in the scope of the article as-is)

  * You probably want to encrypt your GNU/Linux install using LUKS

Rationale
.........

Most people think of security on the software side: the hardware is important aswell.

This tutorial deals with reducing the number of devices that have direct memory access that could communicate with inputs/outputs that could be used to remotely command the system (or leak data). All of this is purely theoretical for the time being.

Disassembly
...........

Firstly remove the bluetooth (if your X60 has this):
 The marked screws are underneath those stickers (marked in those 3 locations at the bottom of the LCD assembly):

 Now gently pry off the bottom part of the front bezel, and the bluetooth module is on the left (easily removable):

If your model was WWAN, remove the simcard (check anyway):
 Uncover those 2 screws at the bottom:

 SIM card (not present in the picture) is in the marked location:

 Replacement: USB dongle.

Now get into the motherboard.

Remove those screws:

Push the keyboard forward (carefully):

Lift the keyboard up and disconnect it from the board:

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:

You should now have this:

The following is a summary of what you will remove (already done to this system):

 Note: the blue lines represent antenna cables and modem cables. You don't need to remove these, but you can if you want (to make it tidier after removing other parts). I removed the antenna wires, the modem jack, the modem cable and also (on another model) a device inside the part where the wwan antenna goes (wasn't sure what it was, but I knew it wasn't needed). This is optional

Remove the microphone (can desolder it, but you can also easily pull it off with you hands). Already removed here:

 Rationale:
 Another reason to remove the microphone: If your computer gets see [1], compromised, it can record what you say, and use it to receive data from nearby devices if they're compromised too. Also, we do not know what the built-in microcode (in the CPU) is doing; it could theoretically be programmed to accept remote commands from some speaker somewhere (remote security hole). In other words, the system could already be compromised from the factory.

Remove the modem:

 (useless, obsolete device)

Remove the speaker:

 Reason: combined with the microphone issue, this could be used to leak data.
 If your computer gets see [1], compromised, it can be used to transmit data to nearby compromised devices. It's unknown if it can be turned into a microphone see [2],.
 Replacement: headphones/speakers (line-out) or external DAC (USB).

Remove the wlan (also remove wwan if you have it):

 Reason: has direct (and very fast) memory access, and could (theoretically) leak data over a side-channel.
 Wifi: The ath5k/ath9k cards might not have firmware at all. They might safe but could have access to the computer's RAM trough DMA. If people have an intel card(most X60s come with Intel wifi by default, until you change it),then that card runs a non-free firwamre and has access to the computer's RAM trough DMA! So the risk-level is very high.
 Wwan (3g modem): They run proprietary software! It's like AMT but over the GSM network which is probably even worse.
 Replacement: external USB wifi dongle. (or USB wwan/3g dongle; note, this has all the same privacy issues as mobile phones. wwan not recommended).

Not covered yet:
................

  * Disable cardbus (has fast/direct memory access)

  * Disable firewire (has fast/direct memory access)

  * Disable flashing the ethernet firmware

  * Disable SPI flash writes (can be re-enabled by unsoldering two parts)

  * Disable use of xrandr/edid on external monitor (cut 2 pins on VGA)

  * Disable docking station (might be possible to do it in software, in coreboot upstream as a Kconfig option)

Go to http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge.html or directly to the video: http://mirror.netcologne.de/CCC/congress/2013/webm/30c3-5529-en-Hardening_hardware_and_choosing_a_goodBIOS_webm.webm.

A lot of this tutorial is based on that video. Look towards the second half of the video to see how to do the above.

Also not covered yet:
.....................

  * Intrusion detection: randomized seal on screws
      Just put nail polish with lot of glider on the important screws, take some good pictures. Keep the pictures and make sure of their integrity. Compare the nail polish with the pictures before powering on the laptop.

  * Tips about preventing/mitigating risk of cold boot attack.

       * soldered RAM?

       * seal RAM door shut (possibly modified lower chassis) so that system has to be disassembled (which has to go through the nail polish)

       * wipe all RAM at boot/power-off/power-on? (patch in coreboot upstream?)

       * ask gnutoo about fallback patches (counts number of boots)

  * General tips/advice and web links showing how to detect physical intrusions.

  * For example: http://cs.tau.ac.il/~tromer/acoustic/ or http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper.

  * https://en.wikipedia.org/wiki/Tempest_%28codename%29

  * https://gitorious.org/gnutoo-for-coreboot/grub-assemble/source/a61f636797777a742f65f4c9c58032aa6a9b23c3:

Extra notes
...........

EC: Cannot be removed but can be mitigated: it contains non-free non-loadable code, but it has no access to the computer's RAM. It has access to the on-switch of the wifi, bluetooth, modem and some other power management features. The issue is that it has access to the keyboard, however if the software security howto (not yet written) is followed correctly, it won't be able to leak data to a local attacker. It has no network access but it may still be able to leak data remotely, but that requires someone to be nearby to recover the data with the help of an SDR and some directional antennas - See [3].

Intel 82573 Ethernet controller (http://www.coreboot.org/Intel_82573_Ethernet_controller) on the X60 seems safe, according to Denis.

Risk level
..........

  * Modem (3g/wwan): highest

  * Intel wifi: Near highest

  * Atheros PCI wifi: unknown, but lower than intel wifi.

  * Microphone: only problematic if the computer gets compromised.

  * Speakers: only problematic if the computer gets compromised.

  * EC: can be mitigated if following the guide on software security.

Further reading material (software security)
............................................

  * Installing Trisquel GNU/Linux with full disk encryption (including /boot)

  * Installing Parabola GNU/Linux with full disk encryption (including /boot)

  * Notes about DMA access and the docking station

References
..........

 1. physical access

     Explain that black hats, TAO, and so on might use a 0day to get in, and explain that in this case it mitigates what the attacker can do. Also the TAO do some evaluation before launching an attack: they take the probability of beeing caught into account, along with the kind of target. A 0day costs a lot of money, I heard that it was from 100000$ to 400000$, some other websites had prices 10 times lower but that but it was probably a typo. So if people increase their security it makes it more risky and more costly to attack people.

 2. microphone

     It's possible to turn headphones into a microphone, you could try yourself, however they don't record loud at all. Also intel cards have the capability to change a connector's function, for instance the microphone jack can now become a headphone plug, that's called retasking. There is some support for it in GNU/Linux but it's not very well known.

 3. Video (CCC)

     30c3-5356-en-Firmware_Fat_Camp_webm.webm from the 30th CCC. While their demo is experimental(their hardware also got damaged during the transport), the spies probably already have that since a long time. http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm

Security on the ThinkPad T60
----------------------------

Hardware modifications to enhance security on the ThinkPad T60. This tutorial is incomplete at the time of writing.

Hardware requirements
.....................

  * A T60

  * screwdriver

  * Rubbing or isopropyl alcohol, and thermal compound.

  * (in a later version of this tutorial: soldering iron and scalpel)

Software requirements
.....................

  * none (at least in the scope of the article as-is)

  * You probably want to encrypt your GNU/Linux install using LUKS

Rationale
.........

Most people think of security on the software side: the hardware is important aswell.

This tutorial deals with reducing the number of devices that have direct memory access that could communicate with inputs/outputs that could be used to remotely command the system (or leak data). All of this is purely theoretical for the time being.

Disassembly
...........

Remove those screws and remove the HDD:

Lift off the palm rest:

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:

Gently wedge both sides loose:

Remove that cable from the position:

Now remove that bezel. Remove wifi, nvram battery and speaker connector (also remove 56k modem, on the left of wifi):

 Reason: has direct (and very fast) memory access, and could (theoretically) leak data over a side-channel.
 Wifi: The ath5k/ath9k cards might not have firmware at all. They might safe but could have access to the computer's RAM trough DMA. If people have an intel card(most T60 laptops come with Intel wifi by default, until you change it),then that card runs a non-free firwamre and has access to the computer's RAM trough DMA! So the risk-level is very high.

Remove those screws:

Disconnect the power jack:

Remove nvram battery (we will put it back later):

Disconnect cable (for 56k modem) and disconnect the other cable:

Disconnect speaker cable:

Disconnect the other end of the 56k modem cable:

Make sure you removed it:

Unscrew those:

Make sure you removed those:

Disconnect LCD cable from board:

Remove those screws then remove the LCD assembly:

Once again, make sure you removed those:

Remove the shielding containing the motherboard, then flip it over. Remove these screws, placing them on a steady surface in the same layout as they were in before you removed them. Also, you should mark each screw hole after removing the screw (a permanent marker pen will do), this is so that you have a point of reference when re-assembling the system:

Remove microphone (soldering iron not needed. Just wedge it out gently):

 Rationale:
 Another reason to remove the microphone: If your computer getssee [1], compromised, it can record what you say, and use it to receive data from nearby devices if they're compromised too. Also, we do not know what the built-in microcode (in the CPU) is doing; it could theoretically be programmed to accept remote commands from some speaker somewhere (remote security hole). In other words, the system could already be compromised from the factory.

Remove infrared:

Remove cardbus (it's in a socket, no need to disable. Just remove the port itself):

 Rationale:
 It has direct memory access and can be used to extract sensitive details (such as LUKS keys). See 'GoodBIOS' video linked at the end (speaker is Peter Stuge, a coreboot hacker). The video covers X60 but the same topics apply to T60.

Before re-installing the upper chassis, remove the speaker:

 Reason: combined with the microphone issue, this could be used to leak data.
 If your computer getssee [1], compromised, it can be used to transmit data to nearby compromised devices. It's unknown if it can be turned into a microphonesee [2].
 Replacement: headphones/speakers (line-out) or external DAC (USB).

Remove the wwan:

 Wwan (3g modem): They run proprietary software! It's like AMT but over the GSM network which is probably even worse.
 Replacement: external USB wifi dongle. (or USB wwan/3g dongle; note, this has all the same privacy issues as mobile phones. wwan not recommended).

This is where the simcard connector is soldered. See notes above about wwan. Remove simcard by removing battery and then it's accessible (so, remember to do this when you re-assemble. or you could do it now?)

Put those screws back:

Put it back into lower chassis:

Attach LCD and insert screws (also, attach the lcd cable to the board):

Insert those screws:

On the CPU (and there is another chip south-east to it, sorry forgot to take pic) clean off the old thermal paste (with the alcohol) and apply new (Artic Silver 5 is good, others are good too) you should also clean the heatsink the same way

Attach the heatsink and install the screws (also, make sure to install the AC jack as highlighted):

Reinstall that upper bezel:

Do that:

Attach keyboard and install nvram battery:

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:

Remove those covers and unscrew:

Gently pry off the front bezel (sorry, forgot to take pics).

Remove bluetooth module:

Re-attach the front bezel and re-insert the screws (sorry, forgot to take pics).

It lives!

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:

Not covered yet
...............

  * Disable flashing the ethernet firmware

  * Disable SPI flash writes (can be re-enabled by unsoldering two parts)

  * Disable use of xrandr/edid on external monitor (cut 2 pins on VGA)

  * Disable docking station (might be possible to do it in software, in coreboot upstream as a Kconfig option)

Go to http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge.html or directly to the video: http://mirror.netcologne.de/CCC/congress/2013/webm/30c3-5529-en-Hardening_hardware_and_choosing_a_goodBIOS_webm.webm.

A lot of this tutorial is based on that video. Look towards the second half of the video to see how to do the above.

Also not covered yet
....................

  * Intrusion detection: randomized seal on screws
      Just put nail polish with lot of glider on the important screws, take some good pictures. Keep the pictueres and make sure of their integrity. Compare the nail polish with the pictures before powering on the laptop.

  * Tips about preventing/mitigating risk of cold boot attack.

       * soldered RAM?

       * wipe all RAM at boot/power-off/power-on? (patch in coreboot upstream?)

       * ask gnutoo about fallback patches (counts number of boots)

  * General tips/advice and web links showing how to detect physical intrusions.

  * For example: http://cs.tau.ac.il/~tromer/acoustic/ or http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper.

  * https://en.wikipedia.org/wiki/Tempest_%28codename%29

  * https://gitorious.org/gnutoo-for-coreboot/grub-assemble/source/a61f636797777a742f65f4c9c58032aa6a9b23c3:

Extra notes
...........

EC: Cannot be removed but can be mitigated: it contains non-free non-loadable code, but it has no access to the computer's RAM. It has access to the on-switch of the wifi, bluetooth, modem and some other power management features. The issue is that it has access to the keyboard, however if the software security howto (not yet written) is followed correctly, it won't be able to leak data to a local attacker. It has no network access but it may still be able to leak data remotely, but that requires someone to be nearby to recover the data with the help of an SDR and some directional antennassee [3].

Intel 82573 Ethernet controller (http://www.coreboot.org/Intel_82573_Ethernet_controller) on the X60 seems safe, according to Denis.

Risk level
..........

  * Modem (3g/wwan): highest

  * Intel wifi: Near highest

  * Atheros PCI wifi: unknown, but lower than intel wifi.

  * Microphone: only problematic if the computer gets compromised.

  * Speakers: only problematic if the computer gets compromised.

  * EC: can be mitigated if following the guide on software security.

Further reading material (software security)
............................................

  * Installing Trisquel GNU/Linux with full disk encryption (including /boot)

  * Installing Parabola GNU/Linux with full disk encryption (including /boot)

  * Notes about DMA access and the docking station

References
..........

 1. physical access

     Explain that black hats, TAO, and so on might use a 0day to get in, and explain that in this case it mitigates what the attacker can do. Also the TAO do some evaluation before launching an attack: they take the probability of beeing caught into account, along with the kind of target. A 0day costs a lot of money, I heard that it was from 100000$ to 400000$, some other websites had prices 10 times lower but that but it was probably a typo. So if people increase their security it makes it more risky and more costly to attack people.

 2. microphone

     It's possible to turn headphones into a microphone, you could try yourself, however they don't record loud at all. Also intel cards have the capability to change a connector's function, for instance the microphone jack can now become a headphone plug, that's called retasking. There is some support for it in GNU/Linux but it's not very well known.

 3. Video (CCC)

     30c3-5356-en-Firmware_Fat_Camp_webm.webm from the 30th CCC. While their demo is experimental(their hardware also got damaged during the transport), the spies probably already have that since a long time. http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm

Notes about DMA access and the docking station
----------------------------------------------

Use case:
---------
Usually when people do full disk encryption, it's not really full disk,
instead they still have a /boot in clear.

So an evil maid attack can still be done, in two passes:
1) Clone the hdd, Infect the initramfs or the kernel.
2) Wait for the user to enter its password, recover the password,
luksOpen the hdd image.

I wanted a real full-disk encryption so I've put grub in flash and I
have the following: The HDD has a LUKS rootfs(containing /boot) on an
lvm partition, so no partition is in clear.

So when the computer boots it executes coreboot, then grub as a payload.
Grub then opens the LUKS partition and loads the kernel and initramfs
from there.

To prevent hardware level tempering(like reflashing), I used nail
polish with a lot of gilder, that acts like a seal. Then a high
resolution picture of it is taken, to be able to tell the difference.

The problem:
------------
But then comes the docking port issue: Some LPC pins are exported
there, such as the CLKRUN and LDRQ#.

LDRQ# is "Encoded DMA/Bus Master Request": "Only needed by
peripherals that need DMA or bus mastering. Requires an
individual signal per peripheral. Peripherals may not share
an LDRQ# signal."

So now DMA access is possible trough the dock connector.
So I want to be able to turn that off.

If I got it right, the X60 has 2 superio, one is in the dock, and the
other one is in the laptop, so we have:
                            ________________
 _________________         |                |
|                 |        | Dock connector:|
|Dock: NSC pc87982|<--LPC--->D_LPC_DREQ0    |
|_________________|        |_______^________|
                                   |
                                   |
                                   |
                                   |
                ___________________|____
               |                   v    |
               | SuperIO:        DLDRQ# |
               | NSC pc87382     LDRQ#  |
               |___________________^____|
                                   |
                                   |
                                   |
                                   |
                ___________________|___
               |                   v   |
               | Southbridge:    LDRQ0 |
               | ICH7                  |
               |_______________________|

The code:
---------
Now if I look at the existing code, there is some superio drivers, like
pc87382 in src/superio/nsc, the code is very small.
The only interesting part is the pnp_info pnp_dev_info struct.

Now if I look inside src/mainboard/lenovo/x60 there is some more
complete dock driver:

Inside dock.c I see some dock_connect and dock_disconnect functions.

Such functions are called during the initialisation (romstage.c) and
from the X60 SMI handler (smihandler.c).

Questions:
----------
1) Would the following be sufficent to prevent DMA access from the
outside:
> int dock_connect(void)
> {
>          int timeout = 1000;
> +        int val;
> +
> +        if (get_option(&val, "dock") != CB_SUCCESS)
> +                val = 1;
> +        if (val == 0)
> +                return 0;
>          [...]
> }
>
> void dock_disconnect(void) {
> +        if (dock_present())
> +                return;
>          [...]
> }
2) Would an nvram option be ok for that? Should a Kconfig option be
added too?

> config DOCK_AUTODETECT
>         bool "Autodetect"
>         help
>           The dock is autodetected. If unsure select this option.
>
> config DOCK_DISABLED
>         bool "Disabled"
>         help
>           The dock is always disabled.
>
> config DOCK_NVRAM_ENABLE
>         bool "Nvram"
>         help
>           The dock autodetection is tried only if it is also enabled
> trough nvram.

Hardware maintenance
====================

This section relates to hardware maintenance on supported targets.

ThinkPad X60/X60s/X60T Change keyboard
--------------------------------------

Use this guide to replace the keyboard on your ThinkPad X60. Also works for X60s and X60 Tablet.

Although slightly different, this guide can also be followed for the ThinkPad X200, X200S and X200 Tablet. The screws are in more or less the same place, and it's the same procedure.

Just follow these steps and then reverse.

This tutorial is incomplete, and only pictures for now.

Changing the fan/heatsink on the ThinkPad X60
---------------------------------------------

This guide will teach you how to replace the fan and heatsink on your ThinkPad X60.

Hardware requirements
.....................

  * isopropyl alcohol (sometimes called rubbing alcohol)

  * your new fan and/or heatsink

  * CPU thermal compound (some say Arctic MX-4 is good, others are also 'ok')

  * Something to spread the paste with

Software requirements (for CPU stress testing)
..............................................

  * xsensors utility

  * stress utility

Disassembly
...........

Remove those screws:

Push the keyboard forward (carefully):

Lift the keyboard up and disconnect it from the board:

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:

You should now have this:

Disconnect the wifi antenna cables, the modem cable and the speaker:

Unroute the cables along their path, carefully lifting the tape that holds them in place. Then, disconnect the modem cable (other end) and power connection and unroute all the cables so that they dangle by the monitor hinge on the right-hand side:

Disconnect the monitor from the motherboard, and unroute the grey antenna cable, carefully lifting the tape that holds it into place:

Carefully lift the remaining tape and unroute the left antenna cable so that it is loose:

Remove those screws:

Remove those screws:

Carefully remove the plate, like so:

Remove the SATA connector:

Now remove the motherboard (gently) and cast the lcd/chassis aside:

Look at that black tape above the heatsink, remove it:

Now you have removed it:

Disconnect the fan and remove all the screws, heatsink will easily come off:

Remove the old paste with a cloth (from the CPU and heatsink) and then clean both of them with the alcohol (to remove remaining residue of the paste). Apply a pea-sized amount of paste to the both chipsets that the heatsink covered and spread it evenly (uniformally). Finally reinstall the heatsink, reversing previous steps.

stress -c 2 command can be used to push the CPU to 100%, and xsensors (or watch sensors command) can be used to monitor heat. Below 90C is ok.

ThinkPad X60/X60s How to change the LCD panel
---------------------------------------------

This tutorial is incomplete, and only pictures for now.

ThinkPad T60 15.1" changing LCD panel
-------------------------------------

This is for the 15.1" T60. If you have another size then the procedure will differ; for example, on 14.1" you have to remove the hinges and the procedure is a bit more involved than on 15.1".

Disassembly
...........

Remove those covers and unscrew:

Gently pry off the front bezel.

Remove inverter board:

Disconnect LCD cable:

Remove the panel:

Move the rails (left and right side) from the old panel to the new one and then attach LCD cable:

Insert panel (this one is an LG-Philips LP150E05-A2K1, and there are others. See supported_t60_list):

Insert new inverter board (see supported_t60_list for what is recommended on your LCD panel):

Now re-attach the front bezel and put all the screws in.

It lives!

ThinkPad T60 change the fan/heatsink
------------------------------------

Using this guide you can also change/upgrade the CPU.

Hardware requirements - T60 heatsink
....................................

  * rubbing alcohol or isopropyl alcohol, and thermal compound for changing CPU heatsink (procedure involves removing heatsink)

  * thermal compound/paste (Arctic MX-4 is good. Others are also good.)

Software requirements - T60 heatsink
....................................

  * xsensors

  * stress

Disassembly - T60 heatsink
..........................

Remove those screws and remove the HDD:

Lift off the palm rest:

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:

Gently wedge both sides loose:

Remove that cable from the position:

Remove the bezel (sorry forgot to take pics).

On the CPU (and there is another chip south-east to it, sorry forgot to take pic) clean off the old thermal paste (with the alcohol) and apply new (Artic Silver 5 is good, others are good too) you should also clean the heatsink the same way

This is also an opportunity to change the CPU to another one. For example if you had a Core Duo T2400, you can upgrade it to a better processor (higher speed, 64-bit support). A Core 2 Duo T7600 was installed here.

Attach the heatsink and install the screws (also, make sure to install the AC jack as highlighted):

Reinstall that upper bezel:

Do that:

Attach keyboard:

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:

It lives!

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:

Depthcharge payload
===================

This section relates to the depthcharge payload used in libreboot.

CrOS security model
-------------------

CrOS (Chromium OS/Chrome OS) devices such as Chromebooks implement a strict security model to ensure that these devices do not become compromised, that is implemented as the verified boot (vboot) reference, most of which is executed within depthcharge. A detailed overview of the CrOS security model is available on the dedicated page.

In spite of the CrOS security model, depthcharge won't allow booting kernels without verifying their signature and booting from external media or legacy payload unless explicitly allowed: see configuring verified boot parameters.

Developer mode screen
---------------------

The developer mode screen can be accessed in depthcharge when developer mode is enabled.
 Developer mode can be enabled from the see recovery mode screen.

It allows booting normally, booting from internal storage, booting from external media (when enabled), booting from legacy payload (when enabled), showing information about the device and disabling developer mode.

Holding the developer mode screen
.................................

As instructed on the developer mode screen, the screen can be held by pressing Ctrl + H in the first 3 seconds after the screen is shown. After that delay, depthcharge will resume booting normally.

Booting normally
................

As instructed on the developer mode screen, a regular boot will happen after 3 seconds (if developer mode screen is not held).
 The default boot medium (internal storage, external media, legacy payload) is shown on screen.

Booting from different mediums
..............................

Depthcharge allows booting from different mediums, when they are allowed (see configuring verified boot parameters, to enable or disable boot mediums).
 As instructed on the developer mode screen, booting from various mediums can be triggered by pressing various key combinations:

  * Internal storage: Ctrl + D

  * External media: Ctrl + U (when enabled)

  * Legacy payload: Ctrl + L (when enabled)

Showing device information
..........................

As instructed on the developer mode screen, showing device information can be triggered by pressing Ctrl + I or Tab.
 Various information is shown, including vboot non-volatile data, TPM status, GBB flags and key hashes.

Warnings
........

The developer mode screen will show warnings when:

  * Booting kernels without verifying their signature is enabled

  * Booting from external media is enabled

  * Booting legacy payloads is enabled

Recovery mode screen
--------------------

The recovery mode screen can be accessed in depthcharge, by pressing Escape + Refresh + Power when the device is off.

It allows recovering the device from a bad state by booting from a trusted recovery media. When accessed with the device in a good state, it also allows enabling developer mode.

Recovering from a bad state
...........................

When the device fails to verify the signature of a piece of the boot software or when an error occurs, it is considered to be in a bad state and will instruct the user to reboot to recovery mode.
 Recovery mode boots using only software located in write-protected memory, that is considered to be trusted and safe.

Recovery mode then allows recovering the device by booting from a trusted recovery media, that is automatically detected when recovery mode starts. When no external media is found or when the recovery media is invalid, instructions are shown on screen.
 Trusted recovery media are external media (USB drives, SD cards, etc) that hold a kernel signed with the recovery key.

Google provides images of such recovery media for Chrome OS (which are not advised to users as they contain proprietary software).
 They are signed with Google's recovery keys, that are pre-installed on the device when it ships.

When replacing the full flash of the device, the pre-installed keys are replaced. When the recovery private key is available (e.g. when using self-generated keys), it can be used to sign a kernel for recovery purposes.

Enabling developer mode
.......................

As instructed on the recovery mode screen, developer mode can be enabled by pressing Ctrl + D.
 Instructions to confirm enabling developer mode are then shown on screen.

Configuring verified boot parameters
------------------------------------

Depthcharge's behavior relies on the verified boot (vboot) reference implementation, that can be configured with parameters stored in the verified boot non-volatile storage.
 These parameters can be modified with the crossystem tool, that requires sufficient privileges to access the verified boot non-volatile storage.

crossystem relies on mosys, that is used to access the verified boot non-volatile storage on some devices. crossystem and mosys are both free software and their source code is made available by Google: crossystem (https://chromium.googlesource.com/chromiumos/platform/vboot_reference/). mosys (https://chromium.googlesource.com/chromiumos/platform/mosys/).
 These tools are not distributed along with Libreboot yet. However, they are preinstalled on the device, with ChromeOS.

Some of these parameters have the potential of weakening the security of the device. In particular, disabling kernels signature verification, external media boot and legacy payload boot can weaken the security of the device.

The following parameters can be configured:

  * Kernels signature verification:

       - Enabled with:
           # crossystem dev_boot_signed_only=1

       - Disabled with:
           # crossystem dev_boot_signed_only=0

  * External media boot:

       - Enabled with:
           # crossystem dev_boot_usb=1

       - Disabled with:
           # crossystem dev_boot_usb=0

  * Legacy payload boot:

       - Enabled with:
           # crossystem dev_boot_legacy=1

       - Disabled with:
           # crossystem dev_boot_legacy=0

  * Default boot medium:

       - Internal storage:
           # crossystem dev_default_boot=disk

       - External media:
           # crossystem dev_default_boot=usb

       - Legacy payload:
           # crossystem dev_default_boot=legacy

Grub payload
============

This section relates to the GRUB payload used in libreboot.

Changing the background image in GRUB
-------------------------------------

cbfstool is found in coreboot under util/, and can be compiled.

./cbfstool yourrom.rom remove background.png -n background.png
 ./cbfstool yourrom.rom add -f background.png -n background.png -t raw

When you've done this, re-flash your ROM and you should have a new background at boot time.

Setting font in GRUB (for reference)
------------------------------------

You don't need to do this unless you would like to change the default font yourself. (this is just for reference. It has already been done for you)

The old font used was Unifont, and this had some missing characters: for instance, the border showed ??? characters instead of lines.

I tried DeJavu Sans Mono from this website: dejavu-fonts.org (http://dejavu-fonts.org/wiki/Download)

Specifically, the version that I chose was the latest at the time of writing (Saturday 21 June 2014): this one (http://sourceforge.net/projects/dejavu/files/dejavu/2.34/dejavu-fonts-ttf-2.34.tar.bz2)

This is a free font that is also contained in GNU/Linux distributions like Trisquel or Parabola.

$ cd libreboot_src/grub
 compile grub (the build scripts info on how to do this)
 come back out into libreboot_src/resources/grub:
 $ cd ../libreboot_src/resources/grub/font

I took Dejavu Sans Mono from dejavu (included in this version of libreboot) and did:
 $ ../../../grub/grub-mkfont -o dejavusansmono.pf2 dejavu-fonts-ttf-2.34/ttf/DejaVuSansMono.ttf

I then added the instructions to 'gen.sh' script in grub-assemble to include resources/grub/dejavusansmono.pf2 in all of the ROM images, at the root of the GRUB memdisk.
 I then added that instructions to the grub.cfg files (to load the font):
 loadfont (memdisk)/dejavusansmono.pf2

GRUB keyboard layouts (for reference)
-------------------------------------

Custom keyboard layout in GRUB (for reference)
..............................................

Keymaps are stored in resources/utilities/grub-assemble/keymap/.

Example (French Azerty):
 $ ckbcomp fr > frazerty

 Go in grub directory:
 cat frazerty | ./grub/grub-mklayout -o frazerty.gkb

You must make sure that the files are named keymap and keymap.gkb (where 'keymap' can be whatever you want).

Then from the above example, you would put frazerty in resources/utilities/grub-assemble/keymap/original/ and the frazerty.gkb file goes under resources/utilities/grub-assemble/keymap/

The build scripts will automatically see this, and automatically build ROM images with your custom layout (given the name) and include them under bin. Example: libreboot_frazerty.rom.

UK Dvorak keyboard layout in GRUB (for reference)
.................................................

ukdvorak had to be created manually, based on usdvorak. diff them (under resources/utilities/grub-assemble/keymap/original) to see how ukdvorak file was created

$ cat ukdvorak | ./grub/grub-mklayout -o ukdvorak.gkb

Miscellaneous
=============

High Pitched Whining Noise on Idle (how to remove in Trisquel 7)
----------------------------------------------------------------

Start powertop automatically at boot time:

Included with libreboot is a script called 'powertop.trisquel7'. Run this as root and it will setup powertop to run with --auto-tune at boot time. Load the file in your text editor to see how it does that.

$ sudo ./resources/scripts/misc/poertop.trisquel7

Might want to run with --calibrate first

If powertop doesn't work, another way (reduces battery life slightly) is to add processor.max_cstate=2 to the linux line in grub.cfg, using this guide.

High Pitched Whining Noise on Idle (how to remove in Parabola)
--------------------------------------------------------------

The folloing removes most of the noise. It reduces what is a high frequency whine (that not everyone can hear) to a slight buzz (which most people can't hear or doesn't bother most people).

This is not perfect! The full solution is still not discovered but this is a step towards that. Also, in some instances you will need to run 'sudo poertop --auto-tune' again. This needs to be implemented properly in coreboot itself!

On the X60 with coreboot or libreboot, there is a high pitched sound when idle. So far we have use processor.max_cstate=2 or idle=halt in GRUB. These consume power. Stop using them!

Be root
 $ su -

Installed powertop:
 # pacman -S powertop

and added the folloing to /etc/systemd/system/powertop.service :

[Unit]
Description=Powertop tunings

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/powertop --auto-tune
# "powertop --auto-tune" still needs a terminal for some reason. Possibly a bug?
Environment="TERM=xterm"

[Install]
WantedBy=multi-user.target

Finally, as root do that:
 # systemctl enable powertop
 # systemctl start powertop

The next time you boot the system, the buzz will be gone.

Might want to run with --calibrate first

If powertop doesn't work, another way (reduces battery life slightly) is to add processor.max_cstate=2 to the linux line in grub.cfg, using this guide.

X60/T60: Serial port - how to use (for dock owners)
---------------------------------------------------

For the Thinkpad X60 you can use the "UltraBase X6" dock (for the X60 Tablet it is called X6 Tablet UltraBase). For the ThinkPad T60, you can use the "Advanced Mini Dock".

If you are using one of the ROM images with 'serial' in the name, then you have serial port enabled in libreboot and you have memtest86+ included inside the ROM. Connect your null modem cable to the serial port on the dock and connect the other end to a 2nd system using your USB Serial adapter.

On the 2nd system, you can try this (using GNU Screen):
 $ sudo screen /dev/ttyUSB0 115200

How to quit GNU Screen: Ctrl+A then release and press K, and then press Y.

There are also others like Minicom but I like GNU Screen.

By doing this before booting the X60/T60, you will see console output from libreboot. You will also see GRUB displaying on the serial output, and you will be able to see MemTest86+ on the serial output as well. You can also configure your distro so that a terminal (TTY) is accessible from the serial console.

The folloing guide is for Ubuntu, and can be followed for Trisquel 6.0 which is based on Ubuntu 12.04 (should also work in Trisquel 7, based on Ubuntu 14.04) to enable a serial console using GeTTY:
 https://help.ubuntu.com/community/SerialConsoleHoto

Note: part of the tutorial above requires changing your grub.cfg. Just change the linux line to add instructions for enabling getty. See grub_cbfs.

Power Management Beeps on Thinkpads
-----------------------------------

When disconnecting or connecting the charger, a beep occurs. When the battery goes to a critically low charge level, a beep occurs. Nvramtool is included in libreboot, and can be used to enable or disable this behaviour.

Disable or enable beeps when removing/adding the charger:
 $ sudo ./nvramtool - power_management_beeps=Enable
 $ sudo ./nvramtool - power_management_beeps=Disable

Disable or enable beeps when battery is low:
 $ sudo ./nvramtool - low_battery_beep=Enable
 $ sudo ./nvramtool - low_battery_beep=Disable

A reboot is required, for these changes to take effect.

Finetune backlight control on intel gpu's.
------------------------------------------

Sometimes the backlight control value (BLC_PWM_CTL) set by libreboot is not ideal. The result is either flicker, which could cause nausea or epilepsy or an uneven backlight and/or coil whine coming from the display. To fix this a different value for the gpu reg BLC_PWM_CTL needs to be set. See p94 of https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0.pdf for more information on this reg. The tool for setting registry values on intel gpu's is included in intel-gpu-tools. Install intel-gpu-tools: sudo apt-get install intel-gpu-tools

You can set values:

 sudo intel_reg write 0x00061254 <your_value>

The value set has the following structure:

bits [31:16] is PWM divider.   PWM / PWM_divider = frequency

bits [15:0] is the duty cycle and determines the portion of the backlight modulation frequency. A value of 0 will mean that the display is off. A value equal to the backlight modulation frequency means full on. The value should not be larger than the backlight modulation frequency.

On displays with a CCFL backlight start from: 0x60016001 To verify if all modes work as desired use:

 xbacklight -set 10

and gradually increase until 100.

Displays with a LED backlight need a higher PWM frequency. Do the same thing but start from 0x01290129 . Try setting different values until you have found a value which presents no issue.

It is important to know that there are four failure modes:

 1. flickering very fast, which could cause epilepsy (frequency is too low. decrease divider)

 2. randomly flickering in random intervals - driver IC cannot keep up with toggling the mosfet (frequency too high, increase divider)

 3.  backlight is uneven. (CCFL specific, frequency is too high. increase divider)

 4.  frequency is in audible range and causes coils to whine (frequency is too low. decrease divider)

To check for flickering try moving your laptop while looking at it.

A higher frequency equals higher power consumption. You want to find the highest good working value for the divider (lowest frequency).

Next this value should be set at boot: either add
intel_reg write 0x00061254 <your_ideal_value>

before exit 0 in /etc/rc.local

or create a systemd service file  /etc/systemd/system/backlight.service:
[Unit]
Description=Set BLC_PWM_CTL to a good value
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/intel_reg write 0x00061254 <your_value>
[Install]
WantedBy=multi-user.target
Now start and enable it: sudo systemctl start backlight && sudo systemctl enable backlight

Special note on i945:

i945 behaves differently. Bit 16 needs to be 1 and the duty cycle is not updated when backlight is changed. There are no available datasheets on this target so why it behaves in such a way is not known. So to find a working value BLC_PWM_CTL set bit 16 to 1 and make sure PWM divider == duty cycle. see https://review.coreboot.org/#/c/10624/ on bit 16. The cause of this issue is that i945, in contrast with to GM45, is set to work in BLM Legacy Mode. This makes backlight more complicated since the duty cycle is derived from 3 instead of 2 registers using the following formula:
if(BPC[7:0] <> xFF) then BPCR[15:0] * BPC[7:0] Else BPCR[15:0]
BPC is  LBB - PCI Backlight Control Register, described on http://www.mouser.com/pdfdocs/945gmedatasheet.pdf on page 315. BPCR is BLC_PWM_CTL described in https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0.pdf on page 94. More research needs to be done on this target so proceed with care.

Get EDID: Find out the name (model) of your LCD panel
-----------------------------------------------------

Get the panel name with sudo get-edid | strings
 Or look in /sys/class/drm/card0-LVDS-1/edid

Alternatively you can use i2cdump. In Trisquel, this is in the package i2c-tools.
 $ sudo modprobe i2c-dev
 $ sudo i2cdump -y 5 0x50 (you might have to change the value for -y)
 $ sudo rmmod i2c-dev
 You'll see the panel name in the output (from the EDID dump).

If neither of these options work (or they are unavailable), physically removing the LCD panel is an option. Usually, there will be information printed on the back.

Look at resources/scripts/helpers/misc/libreboot_usb_bugfix

Put this script in /etc/init.d/ on debian-based systems.

About the libreboot project
***************************

GNU Libreboot is a free BIOS or UEFI replacement (free as in freedom (https://www.gnu.org/philosophy/free-sw.html)); libre boot firmware that initializes the hardware and starts a bootloader for your operating system.

It's also an open source BIOS, but open source fails (https://www.gnu.org/philosophy/open-source-misses-the-point.html) to promote freedom; please call libreboot free software (https://www.gnu.org/philosophy/free-sw.html).

Since 14 May 2016, Libreboot is part of the GNU project (https://www.gnu.org/).

Libreboot originally began during December 2013, as a commercial effort by the Ministry of Freedom (https://minifree.org/) to achieve RYF (https://www.fsf.org/resources/hw/endorsement/respects-your-freedom) endorsement for a modified ThinkPad X60 (the first system to ever be added to libreboot).

Back then, the name libreboot didn't exist; the project was nameless, referring to itself as a deblobbed version of coreboot. The project named itself libreboot at some point during early 2014, and has since rapidly expanded to support more hardware and become more user-friendly.

Libreboot is a coreboot (http://coreboot.org/) distribution (distro) with proprietary software removed, intended to be a free (https://www.fsf.org/about/what-is-free-software) (libre) `BIOS' replacement for your computer. The project is aimed at users, attempting to make coreboot as easy to use as possible. Read the full Free Software definition (https://www.gnu.org/philosophy/free-sw.html).

Libreboot has many practical advantages over proprietary (https://gnu.org/philosophy/proprietary/) boot firmware, such as faster boot speeds and better security. You can install GNU/Linux with encrypted /boot/, verify GPG signatures on your kernel (http://www.coreboot.org/GRUB2#signed_kernels), put a kernel in the flash chip and more.

The libreboot project has three main goals:
===========================================

  * Recommend and distribute only free software. Coreboot distributes certain pieces of proprietary software which is needed on some systems. Examples can include things like CPU microcode updates, memory initialization blobs and so on. The coreboot project sometimes recommends adding more blobs which it does not distribute, such as the Video BIOS or Intel's Management Engine. However, a lot of dedicated and talented individuals in coreboot work hard to replace these blobs whenever possible.

  * Support as much hardware as possible! Libreboot supports less hardware than coreboot, because most systems from coreboot still require certain proprietary software to work properly. Libreboot is an attempt to support as much hardware as possible, without any proprietary software.

  * Make coreboot easy to use. Coreboot is notoriously difficult to install, due to an overall lack of user-focussed documentation and support. Most people will simply give up before attempting to install coreboot.

      Libreboot attempts to bridge this divide, making sure that everything from building to installing coreboot is automated, as much as is feasibly possible. Secondly, the project produces documentation aimed at non-technical users. Thirdly, the project attempts to provide excellent user support via mailing lists and IRC.

      Libreboot already comes with a payload (GRUB), flashrom and other needed parts. Everything is fully integrated, in a way where most of the complicated steps that are otherwise required, are instead done for the user in advance.

      You can download ROM images for your libreboot system and install them, without having to build anything from source. The build system is also fully automated, so building from source is easy if you wanted to do that (for whatever reason).

Libreboot is a coreboot distribution, not a coreboot fork
=========================================================

Libreboot is not a fork of coreboot. Every so often, the project re-bases on the latest version of coreboot, with the number of custom patches in use minimized.

All new coreboot development should be done in coreboot (upstream), not libreboot! Libreboot is about deblobbing and packaging coreboot in a user-friendly way, where most work is already done for the user.

For example, if you wanted to add a new board to libreboot, you should add it to coreboot first. Libreboot will automatically receive your code at a later date, when it updates itself.

The deblobbed coreboot tree used in libreboot is referred to as coreboot-libre, to distinguish it as a component of libreboot.

Libreboot is a `stable' version of coreboot
===========================================

  * Coreboot uses the rolling release (https://en.wikipedia.org/wiki/Rolling_release) model, which means that it is not guaranteed to be stable, or to even work at all on a given day. Coreboot does have a strict code review process, but being such a large project with so many contributors, regressions are always possible.

  * Libreboot freezes on a particular revision of coreboot, making sure that everything works properly, making fixes on top of that and repeating this during each subsequent update to a later version of coreboot. By doing this, it provides a stronger guarantee to the user that the firmware will be reliable, and not break their system.

How do I know what version I'm running?
***************************************

If you are at least 127 commits after release 20150518 (commit message build/roms/helper: add version information to CBFS) (or you have any upstream stable release of libreboot after 20150518), then you can press C at the GRUB console, and use this command to find out what version of libreboot you have:
 cat (cbfsdisk)/lbversion
 This will also work on non-release images (the version string is automatically generated, using git describe --tags HEAD), built from the git repository. A file named version will also be included in the archives that you downloaded (if you are using release archives).

If it exists, you can also extract this lbversion file by using the cbfstool utility which libreboot includes, from a ROM image that you either dumped or haven't flashed yet. In GNU/Linux, run cbfstool on your ROM image (libreboot.rom, in this example):
 $ ./cbfstool libreboot.rom extract -n lbversion -f lbversion
 You will now have a file, named lbversion, which you can read in whatever program it is that you use for reading/writing text files.

For git, it's easy. Just check the git log.

For releases on or below 20150518, or snapshots generated from the git repository below 127 commits after 20150518, you can find a file named commitid inside the archives. If you are using pre-built ROM images from the libreboot project, you can press C in GRUB for access to the terminal, and then run this command:
 lscoreboot
 You may find a date in here, detailing when that ROM image was built. For pre-built images distributed by the libreboot project, this is a rough approximation of what version you have, because the version numbers are dated, and the release archives are typically built on the same day as the release; you can correlate that with the release information: see Libreboot release information.

You can also check the documentation that came with your archives, and in Libreboot release information will be the information about the version of libreboot that you are using.

Generally speaking, it is advisable to use the latest version of libreboot.

GNU Free Documentation License
******************************

     [file gfdl-1.3.txt not included]