path: root/docs/libreboot.texi

\input texinfo @c -*-texinfo-*-
@setfilename libreboot.info
@settitle GNU Libreboot documentation

@documentencoding UTF-8

@ignore
A few notes:
- Nodes cannot share the same name in texinfo files. Therefore I had to change some of the node names. I usually did this by appending the name of the hardware in question to the original node name.
- I removed .html extensions from the text that displays for references, e.g. See bbb_setup.html --> See bbb_setup
- In texinfo, section numbering does not go below the @subsubsection level. Because the Table of Contents section is already a chapter, many sections do not have numbers and therefore do not appear in the texinfo-generated table of contents.
- I removed @anchor statements where they were unused (almost everywhere)
- The @copying section currently appears at the top of the page in html and info output for testing purposes.
TODO:
- Images do not display in .info. Some nodes therefore appear blank.
- Some image files are contained in @uref statments -- consider changing to @image
- Some references to other sections of the documentation are in @emph statements -- consider changing to @ref
- Formatting pdf/ps/dvi output
- Strikethrough
- Internationalization
- Structure: subsubheadings
- Suppliers page (../../suppliers)?
@end ignore

@copying
Copyright @copyright{} 2014, 2015, 2016 Leah Woods <info@@minifree.org>@* 
Copyright @copyright{} 2015 Paul Kocialkowski <contact@@paulk.fr>@*
Copyright @copyright{} 2015 Alex David <opdecirkel@@gmail.com>@*
Copyright @copyright{} 2015 Patrick "P. J." McDermott <pj@@pehjota.net>@*
Copyright @copyright{} 2015 Albin Söderqvist@*
Copyright @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 @uref{../resources/licenses/gfdl-1.3.txt,gfdl-1.3.txt}

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

@quotation
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.
@end quotation

@end copying

@ifnottex
@paragraphindent 0
@end ifnottex

@titlepage
@title GNU Libreboot documentation
@insertcopying
@end titlepage

@ifnottex
@insertcopying
@end ifnottex

@summarycontents
@contents

@node Top
@top GNU Libreboot documentation
Information about this release can be found by consulting the release notes (see @ref{Libreboot release information,release}). Always check @uref{http://libreboot.org,libreboot.org} for updates.

@menu
* Libreboot release information::
* Table of contents::
* About the libreboot project::
* How do I know what version I'm running?::

Appendix
* GNU Free Documentation License::
@end menu

@node Libreboot release information
@chapter Libreboot release information
Release date: Day Month Year.

Installation instructions can be found @ref{Installation,here}. Building instructions (for source code) can be found @ref{Building libreboot from source, here}. 

@menu
* Machines supported in this release::
* Changes for this release relative to r20150518::      Earliest changes last, recent changes first
@end menu

@node Machines supported in this release
@section Machines supported in this release:
@itemize
@item
@strong{ASUS Chromebook C201}
@itemize
@item
Check notes: @xref{ASUS Chromebook C201}. @c @strong{@emph{hcl/c201.html}}
@item
NOTE: not in libreboot 20150518. Only in git. for now.
@end itemize

@item
@strong{Gigabyte GA-G41M-ES2L desktop board}
@itemize
@item
Check notes: @xref{Gigabyte GA-G41M-ES2L motherboard}. @c @strong{@emph{hcl/ga-g41m-es2l.html}}
@item
@strong{NOTE: not in libreboot 20150518. Only in git, for now.}
@end itemize

@item
@strong{Intel D510MO desktop board}
@itemize
@item
Check notes: @xref{Intel D510MO motherboard}.  @c @strong{@emph{hcl/d510mo.html}}
@item
@strong{NOTE: not in libreboot 20150518. Only in git, for now.}
@end itemize

@item
@strong{ASUS KFSN4-DRE server board}
@itemize
@item
PCB revision 1.05G is the best version (can use 6-core CPUs)
@item
Check notes: @xref{ASUS KFSN4-DRE motherboard}.  @c @strong{@emph{hcl/kfsn4-dre.html}}
@item
@strong{NOTE: not in libreboot 20150518. Only in git, for now.}
@end itemize

@item
@strong{ASUS KGPE-D16 server board}
@itemize
@item
Check notes: @xref{ASUS KGPE-D16 motherboard}. @c  @strong{@emph{hcl/kgpe-d16.html}}
@item
@strong{NOTE: not in libreboot 20150518. Only in git, for now.}
@end itemize

@item
@strong{ASUS KCMA-D8 desktop/workstation board}
@itemize
@item
Check notes: @xref{ASUS KCMA-D8 motherboard}. @c @strong{@emph{hcl/kcma-d8.html}}
@item
@strong{NOTE: not in libreboot 20150518. Only in git, for now.}
@end itemize

@item
@strong{ThinkPad X60/X60s}
@itemize
@item
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.
@end itemize

@item
@strong{ThinkPad X60 Tablet} (1024x768 and 1400x1050) with digitizer support
@itemize
@item
See @ref{Lenovo ThinkPad X60/X60s} for list of supported LCD panels
@item
It is unknown whether an X61 Tablet can have it's mainboard replaced with an X60 Tablet motherboard.
@end itemize

@item
@strong{ThinkPad T60} (Intel GPU) (there are issues; see below):
@itemize
@item
See notes below for exceptions, and see @ref{Supported T60 list} for known working LCD panels.
@item
It is unknown whether a T61 can have it's mainboard replaced with a T60 motherboard.
@item
See @uref{https://libreboot.org/docs/future/index.html#t60_cpu_microcode} @c @strong{@emph{future/index.html#t60_cpu_microcode}}.
@item
T60P (and T60 laptops with ATI GPU) will likely never be supported: @xref{Lenovo ThinkPad T60}.  @c @strong{@emph{hcl/index.html#t60_ati_intel}}
@end itemize

@item
@strong{ThinkPad X200}
@itemize
@item
X200S and X200 Tablet are also supported, conditionally; @pxref{X200S and X200 Tablet}.  @c @strong{@emph{hcl/x200.html#x200s}}
@item
@strong{ME/AMT}: libreboot removes this, permanently. @xref{GM45 chipsets - remove the ME}.  @c @strong{@emph{hcl/gm45_remove_me.html}}
@end itemize

@item
@strong{ThinkPad R400}
@itemize
@item
See @strong{@emph{hcl/r400.html}}
@item
@strong{ME/AMT}: libreboot removes this, permanently. @xref{GM45 chipsets - remove the ME}. @c @strong{@emph{hcl/gm45_remove_me.html}}
@end itemize

@item
@strong{ThinkPad T400}
@itemize
@item
See @strong{@emph{hcl/t400.html}}
@item
@strong{ME/AMT}: libreboot removes this, permanently. @xref{GM45 chipsets - remove the ME}. @c @strong{@emph{hcl/gm45_remove_me.html}}
@end itemize

@item
@strong{ThinkPad T500}
@itemize
@item
See @strong{@emph{hcl/t500.html}}
@item
@strong{ME/AMT}: libreboot removes this, permanently. @xref{GM45 chipsets - remove the ME}. @c @strong{@emph{hcl/gm45_remove_me.html}}
@end itemize

@item
@strong{Apple MacBook1@comma{}1} (MA255LL/A, MA254LL/A, MA472LL/A)
@itemize
@item
@xref{Apple Macbook1-1,Macbook1@comma{}1}. @c See @strong{@emph{hcl/index.html#macbook11}}.
@end itemize

@item
@strong{Apple MacBook2@comma{}1} (MA699LL/A, MA701LL/A, MB061LL/A, MA700LL/A, MB063LL/A, MB062LL/A)
@itemize
@item
@xref{Apple Macbook2-1,Macbook2@comma{}1}. @c See @strong{@emph{hcl/index.html#macbook21}}.
@end itemize

@end itemize

@node Changes for this release relative to r20150518
@section Changes for this release, relative to r20150518 (earliest changes last, recent changes first)
@itemize
@item
Changelog not yet generated. Clone the git repository and check the git logs.
@end itemize


@node Table of contents
@chapter Table of contents

@menu
* Hardware compatibility::      Hardware compatibility list
* Installation::                How to install libreboot
* GNU/Linux distributions::     How to install GNU/Linux on a libreboot system
* Git::                         How to use the git repository and build/maintain libreboot from source
* Hardware security::           
* Hardware maintenance::        Hardware maintenance
* Depthcharge::                 Depthcharge payload
* GRUB::                        GRUB payload
* Miscellaneous::
@end menu


@c
@c NOTE: this is one way of structuring the file I tried
@c
@ignore
@include include/hardware-compatibility.texi 
@include include/installation.texi    
@include include/installing-gnu-linux.texi      
@include include/git.texi                       
@include include/security.texi                  
@include include/hardware-maintenance.texi      
@include include/depthcharge-payload.texi       
@include include/grub-payload.texi              
@include include/misc.texi
@end ignore

@node Hardware compatibility
@section Hardware compatibility
This section relates to known hardware compatibility in libreboot.

@menu
* List of supported hardware::
* Recommended wifi chipsets::
* GM45 chipsets - remove the ME::
* LCD compatibility on GM45 laptops::
@end menu

@node List of supported hardware
@subsection List of supported hardware
Libreboot supports the following systems in this release:
@itemize @bullet

@item Desktops (AMD, Intel x86)
@itemize @minus
@item Gigabyte GA-G41M-ES2L motherboard @c (@xref{Gigabyte GA-G41M-ES2L motherboard})
@item Intel D510MO motherboard @c (@xref{Intel D510MO motherboard})
@item ASUS KCMA-D8 motherboard @c (@xref{ASUS KCMA-D8 motherboard})
@end itemize

@item Servers/workstations (AMD, x86)
@itemize @minus
@item ASUS KFSN4-DRE motherboard @c (@xref{ASUS KFSN4-DRE motherboard})
@item ASUS KGPE-D16 motherboard @c (@xref{ASUS KGPE-D16 motherboard})
@end itemize

@item Laptops (ARM)
@itemize @minus
@item ASUS Chromebook C201 @c (@xref{ASUS Chromebook C201})
@end itemize

@item Laptops (Intel x86)
@itemize @minus
@item Lenovo ThinkPad X60/X60s @c (@xref{Lenovo ThinkPad X60/X60s})
@item Lenovo ThinkPad X60 Tablet @c (@xref{Lenovo ThinkPad X60 Tablet})
@item Lenovo ThinkPad T60 @c (@xref{Lenovo ThinkPad T60})
@item Lenovo ThinkPad X200 @c (@xref{Lenovo ThinkPad X200})
@item Lenovo ThinkPad R400 @c (@xref{Lenovo ThinkPad R400})
@item Lenovo ThinkPad T400 @c (@xref{Lenovo ThinkPad T400})
@item Lenovo ThinkPad T500 @c (@xref{Lenovo ThinkPad T500})
@item Apple MacBook1,1 @c (@xref{Apple MacBook1,1})
@item Apple MacBook2,1 @c (@xref{Apple MacBook2,1})
@end itemize

@end itemize

`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).


@menu
* Gigabyte GA-G41M-ES2L motherboard::
* Intel D510MO motherboard::
* ASUS KCMA-D8 motherboard::
* ASUS KFSN4-DRE motherboard::
* ASUS KGPE-D16 motherboard::
* ASUS Chromebook C201::
* 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:: @c commas cannot be used in node names
* Apple Macbook2-1::
@end menu



@node Gigabyte GA-G41M-ES2L motherboard
@subsubsection 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: @uref{https://lists.nongnu.org/archive/html/libreboot-dev/2015-12/msg00011.html,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

@strong{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 @ref{How to update/install,flashrom}.


@node Intel D510MO motherboard
@subsubsection Intel D510MO motherboard
This is a desktop board using intel hardware. It can make for quite a nifty desktop. Powered by libreboot.

@strong{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 @ref{Flashing Intel D510MO}. 



@node ASUS KCMA-D8 motherboard
@subsubsection ASUS KCMA-D8 motherboard
This is a desktop board using AMD hardware (Fam10h @strong{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 @uref{https://raptorengineeringinc.com/,Raptor Engineering Inc.} and, working with Timothy (and sponsoring the work) merged into libreboot.

@strong{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.}

@strong{Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..}

Flashing instructions can be found at @ref{How to update/install,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.

@itemize

@item
CPU compatibility
@itemize
@item
@strong{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.
@end itemize

@item
Board status compatibility
@itemize
@item
See @uref{https://raptorengineeringinc.com/coreboot/kcma-d8-status.php,https://raptorengineeringinc.com/coreboot/kcma-d8-status.php}.
@end itemize

@item
Form factor
@itemize
@item
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.
@end itemize

@item
IPMI iKVM module add-on
@itemize
@item
Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the @uref{http://libreboot.org/faq/#intelme,Intel Management Engine}. 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.
@end itemize

@item
Flash chips
@itemize
@item
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.
@item
Libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default flash chip is 2MiB).
@item
@strong{DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip extractor. These can be found online. See @uref{http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools,http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools}}
@end itemize

@item
Native graphics initialization
@anchor{native-graphics-kcma-d8}
@itemize
@item
Only text-mode is known to work, but linux(kernel) can initialize the framebuffer display (if it has KMS - kernel mode setting).
@end itemize

@item
Current issues
@itemize
@item
LRDIMM memory modules are currently incompatible
@item
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).
@item
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. @uref{https://github.com/facebook/openbmc,This project} 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).
@item
Graphics: only text-mode works. See @ref{native-graphics-kcma-d8,graphics}. 
@end itemize

@item
Hardware specifications
@itemize
@item
Check ASUS website for specs

@end itemize
@end itemize


@node ASUS KFSN4-DRE motherboard
@subsubsection 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.

@strong{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 @ref{How to update/install,flashrom}. 

@itemize

@item
Form factor
@itemize
@item
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.
@end itemize

@item
Flash chips
@itemize
@item
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.
@item
@strong{DO NOT hot-swap the chip with your bare hands. Use a PLCC chip extractor. These can be found online. See @uref{http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools,http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools}}
@end itemize

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

@item
Memory
@itemize
@item
DDR2 533/667 Registered ECC. 16 slots. Total capacity up to 64GiB.
@end itemize

@item
Hex-core CPUs
@itemize
@item
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.
@end itemize

@item
Current issues
@itemize
@item
There seems to be a 30 second bootblock delay (observed by tpearson); the system otherwise boots and works as expected. See @uref{../resources/text/kfsn4-dre/bootlog.txt,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. @uref{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,This config} doesn't have the issue. 
@item
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).
@end itemize

@item
Other information
@itemize
@item
@uref{ftp://ftp.sgi.com/public/Technical%20Support/Pdf%20files/Asus/kfsn4-dre.pdf,specifications}
@end itemize

@end itemize

@node ASUS KGPE-D16 motherboard @c TODO: Nodes?
@subsubsection ASUS KGPE-D16 server/workstation board
This is a server board using AMD hardware (Fam10h @strong{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 @uref{https://raptorengineeringinc.com/,Raptor Engineering Inc.} and, working with Timothy (and sponsoring the work) merged into libreboot.

@strong{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.}

@strong{Memory initialization is still problematic, for some modules. We recommend avoiding Kingston modules..}

Flashing instructions can be found at @ref{How to update/install,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. 

@itemize

@item
CPU compatibility
@itemize @minus
@item
@strong{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.
@end itemize

@item
Board status compatibility
@itemize @minus
@item
See @uref{https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php,https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php}.
@end itemize

@item
Form factor
@itemize @minus
@item
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.
@end itemize

@item
IPMI iKVM module add-on
@itemize @minus
@item
Don't use it. It uses proprietary firmware and adds a backdoor (remote out-of-band management chip, similar to the @uref{http://libreboot.org/faq/#intelme,Intel Management Engine}. 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. 
@end itemize

@item
Flash chips
@itemize @minus
@item
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.
@item
Libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default flash chip is 2MiB).
@item
@strong{DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip extractor. These can be found online. See @uref{http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools,http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools}}
@end itemize

@item
Native graphics initialization
@anchor{native-graphics-kgpe-d16}
@itemize @minus
@item 
Only text-mode is known to work, but linux(kernel) can initialize the framebuffer display (if it has KMS - kernel mode setting).
@end itemize

@item
Current issues
@itemize @minus
@item 
LRDIMM memory modules are currently incompatible
@item
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).
@item
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. @uref{https://github.com/facebook/openbmc,This project} 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).
@item
Graphics: only text-mode works. See @ref{native-graphics-kgpe-d16,graphics}. @c @ref{#graphics,#graphics} 
@end itemize

@end itemize
@menu
* ASUS KGPE-D16 Hardware specifications::
@end menu


@node ASUS KGPE-D16 Hardware specifications
@c @subsubheading ASUS KGPE-D16 Hardware specifications
@itemize

@item Processor / system bus
@itemize
@item
2 CPU sockets (G34 compatible)
@item
HyperTransport(TM) Technology 3.0 @c FIX FIX FIX -- TM
@item
CPUs supported:
@itemize
@item
AMD Opteron 6100 series (Fam10h. No IOMMU support. @strong{Not} recommended - old. View errata datasheet here: @uref{http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf,http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf})
@item
AMD Opteron 6200 series (bulldozer cores) (Fam15h, with full IOMMU support in libreboot. @strong{highly recommended - fast, and works well without microcode updates, including virtualization})
@item
AMD Opteron 6300 series (piledriver cores) (Fam15h, with full IOMMU support in libreboot. @strong{AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates}
@item
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: @uref{http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf,http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf}
(see Errata 734 - this is what kills the 6300 series)
@end itemize

@item
6.4 GT/s per link (triple link)
@end itemize

@item Core logic
@itemize
@item
AMD SR5690
@item
AMD SP5100
@end itemize

@item Memory compatibility with libreboot
@itemize
@item
@strong{Total Slots:} 16 (4-channel per CPU, 8 DIMM per CPU), ECC
@item
@strong{Capacity:} Maximum up to 256GB RDIMM
@item
@strong{Memory Type that is compatible:}
@itemize
@item
DDR3 1600/1333/1066/800 UDIMM*
@item
DDR3 1600/1333/1066/800 RDIMM*
@end itemize

@item
@strong{Compatible sizes per memory module:}
@itemize
@item
16GB, 8GB, 4GB, 3GB, 2GB, 1GB RDIMM
@item
8GB, 4GB, 2GB, 1GB UDIMM
@end itemize

@end itemize

@item Expansion slots
@itemize
@item
@strong{Total slot:} 6
@item
@strong{Slot Location 1:} PCI 32bit/33MHz
@item
@strong{Slot Location 2:} PCI-E x16 (Gen2 X8 Link)
@item
@strong{Slot Location 3:} PCI-E x16 (Gen2 X16 Link), Auto switch to x8 link if slot 2 is occupied
@item
@strong{Slot Location 4:} PCI-E x8 (Gen2 X4 Link)
@item
@strong{Slot Location 5:} PCI-E x16 (Gen2 X16 Link)
@item
@strong{Slot Location 6:} PCI-E x16 (Gen2 X16 Link), Auto turn off if slot 5 is occupied, For 1U FH/FL Card, MIO supported
@item
@strong{Additional Slot 1:} PIKE slot (for SAS drives. See notes above)
@item
Follow SSI Location#
@end itemize

@item Form factor
@itemize
@item
SSI EEB 3.61 (12"x13")
@end itemize

@item ASUS features
@itemize
@item
Fan Speed Control
@item
Rack Ready (Rack and Pedestal dual use)
@end itemize

@item Storage
@itemize
@item
@strong{SATA controller:}
@itemize
@item
AMD SP5100
@item
6 x SATA2 300MB/s
@end itemize

@item
@strong{SAS/SATA Controller:}
@itemize
@item
ASUS PIKE2008 3Gbps 8-port SAS card included
@end itemize

@end itemize

@item Networking
@itemize
@item
2 x Intel@registeredsymbol{} 82574L + 1 x Mgmt LAN
@end itemize

@item Graphics
@itemize
@item
Aspeed AST2050 with 8MB VRAM
@end itemize

@item On board I/O
@itemize
@item
1 x PSU Power Connector (24-pin SSI power connector + 8-pin SSI 12V + 8-pin SSI 12V power connector)
@item
1 x Management Connector , Onboard socket for management card
@item
3 x USB pin header , Up to 6 Devices
@item
1 x Internal A Type USB Port
@item
8 x Fan Header , 4pin (3pin/4pin fan dual support)
@item
2 x SMBus
@item
1 x Serial Port Header
@item
1 x TPM header
@item
1 x PS/2 KB/MS port
@end itemize

@item Back I/O ports
@itemize
@item
1 x External Serial Port
@item
2 x External USB Port
@item
1 x VGA Port
@item
2 x RJ-45
@item
1 x PS/2 KB/Mouse
@end itemize

@item Environment
@itemize
@item
@strong{Operation temperature:} 10C ~ 35C
@item
@strong{Non operation temperature:} -40C ~ 70C
@item
@strong{Non operation humidity:} 20% ~ 90% ( Non condensing)
@end itemize

@item Monitoring
@itemize
@item
CPU temperatures
@item
Fan speed (RPM)
@end itemize

@item Note
@itemize
@item
DDR3 1600 can only be supported with AMD Opteron 6300/6200 series processor
@end itemize

@end itemize


@node ASUS Chromebook C201
@subsubsection ASUS Chromebook C201
@strong{DO NOT BUY THIS LAPTOP YET!!!!!!!!!!! This is intended mainly for developers at the moment (libreboot developers, and developers of libre GNU/Linux distributions). This laptop currently has @emph{zero} support from libre distros. Parabola theoretically supports it, by installing Arch first and then migrating to Parabola using the migration guide on the Parabola wiki, but it's not very well tested and does not have many packages --- in our opinion, Parabola does not really support this laptop. There are also several issues. Read this page for more information. This laptop can still be used reasonably, in freedom, but it requires a lot of work. Most users will be disappointed.}

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 @uref{http://www.replicant.us/,Replicant} developer, ported this laptop to libreboot. Thank you, Paul!

@strong{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.}

@strong{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 @ref{How to update/install,flashrom}.  

@menu
* Intent::              Google's intent with CrOS devices
* Considerations::      Considerations about ChromeOS and free operating systems
* Video blobs::          Caution: Video acceleration requires a non-free blob, software rendering can be used instead
* WiFi blobs::           Caution: WiFi requires a non-free blob, a USB dongle can be used instead
* EC Firmware::         EC firmware is free software!
* Microcode::           No microcode!
* Depthcharge payload - CrOS::
* The Screw::           Flash chip write protection: the screw
@end menu

@node Intent
@ifinfo
@subsubheading Google's intent with CrOS devices
@end ifinfo
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 @uref{https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html,proprietary web services} (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 @emph{PRISM} program, as outlined by Edward Snowden. See notes about ChromeOS below. The libreboot project recommends that the user replace the default @emph{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 @emph{hostile} to the free software movement.


@node Considerations
@ifinfo
@subsubheading Considerations about ChromeOS and free operating systems
@end ifinfo
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 @emph{@uref{https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html,SaaSS}}. Libreboot recommends that users of this laptop replace it with another distribution.

The FSF has a @uref{https://www.gnu.org/distros/free-distros.html,list of distributions} that are 100% free software. Only one of them is confirmed to work on ARM CrOS devices. Parabola looks hopeful: @uref{https://www.parabola.nu/news/parabola-supports-armv7/,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.

@strong{We need these distributions to be ported as soon as possible.}

@node Video blobs
@ifinfo
@subsubheading Caution: Video acceleration requires a non-free blob, software rendering can be used instead.
@end ifinfo
The lima driver source code for the onboard Mali GPU is not released. The developer withheld it for personal reasons. 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 @emph{XFCE} or @emph{LXDE}.

The lima developer wrote this blog post, which sheds light on the story: @uref{http://libv.livejournal.com/27461.html,http://libv.livejournal.com/27461.html}

@node WiFi blobs
@ifinfo
@subsubheading Caution: WiFi requires a non-free blob, a USB dongle can be used instead.
@end ifinfo
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. @xref{Recommended wifi chipsets}. @c See @uref{index.html#recommended_wifi,index.html#recommended_wifi}.

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

@itemize
@item
@uref{https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb,ThinkPenguin sells them} (company based in USA)
@item
@uref{https://tehnoetic.com/tehnoetic-wireless-adapter-gnu-linux-libre-tet-n150,Tehnoetic sells them} (company based in Europe)
@end itemize

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

@node EC Firmware
@ifinfo
@subsubheading EC firmware is free software!
@end ifinfo
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 @emph{EC} is: @uref{http://libreboot.org/faq/#firmware-ec,http://libreboot.org/faq/#firmware-ec}

@node Microcode
@ifinfo
@subsubheading No microcode!
@end ifinfo
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.

@node Depthcharge payload - CrOS
@ifinfo
@subsubheading Depthcharge payload
@end ifinfo
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.

@node The Screw
@ifinfo
@subsubheading Flash chip write protection: the screw
@end ifinfo
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.

@emph{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 @ref{How to program an SPI flash chip with BeagleBone Black,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 @emph{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.



@node Lenovo ThinkPad X60/X60s
@subsubsection Lenovo ThinkPad X60/X60s
Native gpu initialization (`native graphics') which replaces the proprietary VGA Option ROM (`@uref{https://en.wikipedia.org/wiki/Video_BIOS,Video BIOS}' or `VBIOS'), all known LCD panels are currently compatible:

To find what LCD panel you have, see: @ref{Get EDID - Find out the name of your LCD panel,Get EDID}.

@itemize
@item
TMD-Toshiba LTD121ECHB: #
@item
CMO N121X5-L06: #
@item
Samsung LTN121XJ-L07: #
@item
BOE-Hydis HT121X01-101: #
@end itemize

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 @strong{after} libreboot is installed. See Recommended wifi chipsets for replacements. @c ADD REF



@node Lenovo ThinkPad X60 Tablet
@subsubsection Lenovo ThinkPad X60 Tablets
Native gpu initialization (`native graphics') which replaces the proprietary VGA Option ROM (`@uref{https://en.wikipedia.org/wiki/Video_BIOS,Video BIOS}' or `VBIOS').

To find what LCD panel you have, see: @ref{Get EDID - Find out the name of your LCD panel,Get EDID}. @c @uref{../misc/index.html#get_edid_panelname,../misc/index.html#get_edid_panelname}. 

There are 5 known LCD panels for the X60 Tablet:

@itemize
@item
@strong{X60T XGA (1024x768):}
@itemize
@item
BOE-Hydis HV121X03-100 (works)
@item
Samsung LTN121XP01 (does not work. blank screen)
@item
BOE-Hydis HT12X21-351 (does not work. blank screen)
@end itemize

@item
@strong{X60T SXGA+ (1400x1050):}
@itemize
@item
BOE-Hydis HV121P01-100 (works)
@item
BOE-Hydis HV121P01-101 (works)
@end itemize

@end itemize

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. @strong{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 @strong{after} libreboot is installed. See Recommended wifi chipsets for replacements. @c ADD REF

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:

@verbatim
# 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
@end verbatim


@node Lenovo ThinkPad T60
@subsubsection 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 T60@strong{p} 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):@*@* @image{../resources/images/t60_dev/t60_unbrick,,,,jpg} 

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: @uref{https://en.wikipedia.org/wiki/Video_BIOS,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).

@menu
* Supported T60 list::
@end menu

@node Supported T60 list
Native gpu initialization ('native graphics') which replaces the proprietary VGA Option ROM ('@uref{https://en.wikipedia.org/wiki/Video_BIOS,Video BIOS}' or 'VBIOS').

To find what LCD panel you have, see: @ref{Get EDID - Find out the name of your LCD panel,Get EDID}. @c @uref{../misc/index.html#get_edid_panelname,../misc/index.html#get_edid_panelname}.

@strong{Some T60s have ATI GPUs, and all T60P laptops have ATI GPUs These are incompatible! See @ref{Lenovo ThinkPad T60,t60_ati_intel} for how to remedy this.}

How to dump the EDID:@*

Tested LCD panels: @strong{working(compatible)}

@itemize
@item
TMD-Toshiba LTD141EN9B (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)
@item
Samsung LTN141P4-L02 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)
@item
LG-Philips LP150E05-A2K1 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)
@item
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)
@item
BOE-Hydis HV150UX1-100 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)
@end itemize

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

@itemize
@item
Samsung LTN141XA-L01 (14.1" 1024x768)
@item
LG-Philips LP150X09 (15.1" 1024x768)
@item
Samsung LTN150XG (15.1" 1024x768)
@item
LG-Philips LP150E06-A5K4 (15.1" 1400x1050) (also, not an official T60 screen)
@item
Samsung LTN154X3-L0A (15.4" 1280x800)
@item
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)
@item
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)
@end itemize

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

@itemize
@item
CMO(IDtech?) N141XC (14.1" 1024x768)
@item
BOE-Hydis HT14X14 (14.1" 1024x768)
@item
TMD-Toshiba LTD141ECMB (14.1" 1024x768)
@item
Boe-Hydis HT14P12 (14.1" 1400x1050) (FRU P/N 41W1478 recommended for the inverter board)
@item
CMO (IDtech?) 13N7068 (15.1" 1024x768)
@item
CMO (IDtech?) 13N7069 (15.1" 1024x768)
@item
BOE-Hydis HV150P01-100 (15.1" 1400x1050) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)
@item
BOE-Hydis HV150UX1-102 (15.1" 1600x1200) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)
@item
IDtech IAQX10S (15.1" 2048x1536) (P/N 42T0078 FRU 42T0079 or P/N 41W1338 recommended for the inverter board)
@item
Samsung LTN154P2-L05 (42X4641 42T0329) (15.4" 1680x1050)
@item
LG-Philips LP154W02-TL10 (13N7020 42T0423) (15.4" 1680x1050)
@item
LG-Philips LP154WU1-TLB1 (42T0361) (15.4" 1920x1200) @strong{(for T61p but it might work in T60. Unknown!)}
@item
Samsung LTN154U2-L05 (42T0408 42T0574) (15.4" 1920x1200) @strong{(for T61p but it might work in T60. Unknown!)}
@end itemize

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 @strong{after} libreboot is installed. See Recommended wifi chipsets for replacements. @c ADD REF


@node Lenovo ThinkPad X200
@subsubsection ThinkPad X200
It is believed that all X200 laptops are compatible. @ref{X200S and X200 Tablet,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. @strong{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.

@strong{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: @pxref{GM45 chipsets - remove the ME,gm45_remove_me}} (contains notes, plus instructions).

Flashing instructions can be found at @ref{How to update/install,flashrom} 

@menu
* Compatibility without blobs - X200::
* X200S and X200 Tablet::
* Trouble undocking button doesn't work::
* LCD compatibility list - X200::
* How to tell if it has an LED or CCFL?::
* Hardware register dumps::
* RAM S3 and microcode updates::
* Unsorted notes::
@end menu

@node Compatibility without blobs - X200
@ifinfo
@subsubheading Compatibility without blobs - X200
@end ifinfo
@c @subsubheading Hardware virtualization vt-x
@c @menu
@c * Hardware virtualization vt-x::
@c @end menu

@c @node Hardware virtualization vt-x
@c @subsubheading Hardware virtualization (vt-x)
@c @anchor{#hardware-virtualization-vt-x}
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 @emph{kvm} and @emph{kvm_intel} kernel modules are not loaded, when using QEMU.

The following errata datasheet from Intel might help with investigation: @uref{http://download.intel.com/design/mobile/specupdt/320121.pdf,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.

@node X200S and X200 Tablet
@ifinfo
@subsubheading X200S and X200 Tablet.
@end ifinfo
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 @uref{https://www.cs.cmu.edu/~410/doc/minimal_boot.pdf,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: @uref{../resources/text/x200s/cblog00.txt,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: @uref{../resources/text/x200s/cblog01.txt,cblog01.txt}. The memory modules in this case are 2x4GB. @strong{However, not all configurations work: @uref{../resources/text/x200s/cblog02.txt,cblog02.txt} (2x2GB) and @uref{../resources/text/x200s/cblog03.txt,cblog03.txt} (1x2GB) show a failed bootup.} @emph{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 @uref{http://review.coreboot.org/#/c/7786/,http://review.coreboot.org/#/c/7786/} (libreboot merges this patch in coreboot-libre now. Check the 'getcb' script in src or git).
@menu
* Proper GS45 raminit::
@end menu

@node Proper GS45 raminit @c FIX FIX FIX: node issues?
@c @subsubheading Proper GS45 raminit
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.

@node Trouble undocking button doesn't work
@ifinfo
@subsubheading Trouble undocking (button doesn't work)
@end ifinfo
This person seems to have a workaround: @uref{https://github.com/the-unconventional/libreboot-undock,https://github.com/the-unconventional/libreboot-undock}

@node LCD compatibility list - X200
@ifinfo
@subsubheading LCD compatibility list
@end ifinfo
LCD panel list (X200 panels listed there): @uref{http://www.thinkwiki.org/wiki/TFT_display,http://www.thinkwiki.org/wiki/TFT_display}

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

@menu
* AFFS/IPS panels::
* X200S::
@end menu

@node AFFS/IPS panels
@c @subsubheading AFFS/IPS panels
@c @menu
@c * X200::
@c @end menu

X200
@c @subsubheading X200
@c @anchor{#x200}
Adapted from @uref{https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X200,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).

@itemize
@item
BOE-Hydis HV121WX4-120, HV121WX4-110 or HV121WX4-100 - cheap-ish, might be hard to find
@item
Samsung LTN121AP02-001 - common to find, cheap
@end itemize

@strong{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, @pxref{How to tell if it has an LED or CCFL?,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.} @c ADD REF

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:

@itemize
@item
@uref{http://forum.thinkpads.com/viewtopic.php?f=2&t=84941,ThinkPad Forums - Matte AFFS Panel on X200}
@item
@uref{http://forum.thinkpads.com/viewtopic.php?p=660662#p660662,ThinkPad Forums - Parts for X200 AFFS Mod}
@item
@uref{http://thinkwiki.de/X200_Displayumbau,ThinkWiki.de - X200 Displayumbau} (achtung: du musst lesen und/oder spreche deutsch; oder ein freund fur hilfe)
@end itemize

@node X200S
@c @subsubheading X200S
@uref{http://forum.thinkpads.com/viewtopic.php?p=618928#p618928,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.

@c @ref{#pagetop,Back to top of page.}

@node How to tell if it has an LED or CCFL?
@c @subsubheading How to tell if it has an LED or CCFL?
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 (@strong{}unless it has been changed to an LED, with the correct inverter. Check with your supplier!) the following: @emph{"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).


@node Hardware register dumps
@c @subsubheading Hardware register dumps
The coreboot wiki @uref{http://www.coreboot.org/Motherboard_Porting_Guide,shows} how to collect various logs useful in porting to new boards. Following are outputs from the X200:

@itemize
@item
BIOS 3.15, EC 1.06
@itemize
@item
@uref{../resources/misc/dumps/x200/,x200_dumps/}
@end itemize

@end itemize

@node RAM S3 and microcode updates
@c @subsubheading RAM, S3 and microcode updates
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.

@uref{http://www.forum.thinkpads.com/viewtopic.php?p=760721,This page} 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: @* $ @strong{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.)

@strong{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.
@c @menu
@c * Unsorted notes::
@c @end menu

@node Unsorted notes
@c @subsubheading Unsorted notes
@c @anchor{#unsorted-notes}
@verbatim
<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
@end verbatim


@node Lenovo ThinkPad R400
@subsubsection Lenovo ThinkPad R400
It is believed that all or most R400 laptops are compatible. See notes about @ref{A note about CPUs - R400,r400_external,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.

@strong{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 @ref{GM45 chipsets - remove the ME,gm45_remove_me}} (contains notes, plus instructions). 

Flashing instructions can be found at @ref{How to update/install,flashrom}. 

@menu
* Compatibility without blobs - R400::
* LCD Compatibility - R400::
@end menu

@node Compatibility without blobs - R400
@c @subsubheading Compatibility (without blobs)
@c @menu
@c * Hardware virtualization vt-x::
@c @end menu
@itemize
@item
Hardware virtualization vt-x
@c @subsubheading Hardware virtualization (vt-x)
@c @anchor{#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 @emph{kvm} and @emph{kvm_intel} kernel modules are not loaded, when using QEMU.

The following errata datasheet from Intel might help with investigation: @uref{http://download.intel.com/design/mobile/specupdt/320121.pdf,http://download.intel.com/design/mobile/specupdt/320121.pdf}
@end itemize

The R400 is almost identical to the X200, code-wise. @xref{Lenovo ThinkPad X200,x200}. 

TODO: put hardware register logs here like on the @uref{x200.html,X200} and @uref{t400.html,T400} page. 

@node LCD Compatibility - R400 @c Fixed a typo here: previously 'LCD compatibily'
@c @subsubheading LCD compatibility
Not all LCD panels are compatible yet. @xref{LCD compatibility on GM45 laptops,gm45_lcd}. 



@node Lenovo ThinkPad T400
@subsubsection Lenovo ThinkPad T400
It is believed that all or most T400 laptops are compatible. See notes about @ref{A note about CPUs - T400,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.

@strong{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 @ref{GM45 chipsets - remove the ME,gm45_remove_me}} (contains notes, plus instructions) 

Flashing instructions can be found at @ref{How to update/install,flashrom}. 

@menu
* Compatibility without blobs - T400::
* LCD compatibility - T400::
* Hardware register dumps - T400::
@end menu

@node Compatibility without blobs - T400
@c @subsubheading Compatibility (without blobs)

@itemize
@item
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 @emph{kvm} and @emph{kvm_intel} kernel modules are not loaded, when using QEMU.

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

The T400 is almost identical to the X200, code-wise. @xref{Lenovo ThinkPad X200,x200}. 
@end itemize

@node LCD compatibility - T400
@c @subsubheading LCD compatiblity
Not all LCD panels are compatible yet. @xref{LCD compatibility on GM45 laptops,gm45_lcd}. 

@node Hardware register dumps - T400
@c @subsubheading Hardware register dumps
The coreboot wiki @uref{http://www.coreboot.org/Motherboard_Porting_Guide,shows} how to collect various logs useful in porting to new boards. Following are outputs from the T400:

@itemize
@item
T400 with @strong{Winbond W25X64} flash chip (8MiB, SOIC-16) and Lenovo BIOS 2.02 (EC firmware 1.01):
@itemize
@item
@uref{../resources/misc/dumps/logs-t400-bios2.02-ec1.01/,logs-t400-bios2.02-ex1.01}
@end itemize

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


@node Lenovo ThinkPad T500
@subsubsection Lenovo ThinkPad T500
It is believed that all or most T500 laptops are compatible. See notes about @ref{A note about CPUs - T500,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.

@strong{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 @ref{GM45 chipsets - remove the ME,gm45_remove_me}} (contains notes, plus instructions) 

Flashing instructions can be found at @ref{How to update/install,flashrom}. 

@menu
* Compatibility without blobs - T500::
* LCD compatibility - T500::
* Descriptor and Gbe differences::
* Hardware register dumps - T500::
@end menu

@node Compatibility without blobs - T500
@c @subsubheading Compatibility (without blobs)
@itemize
@item
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 @emph{kvm} and @emph{kvm_intel} kernel modules are not loaded, when using QEMU.

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

The T500 is almost identical to the X200, code-wise. See @ref{Lenovo ThinkPad X200,x200}. 
@end itemize

@node LCD compatibility - T500
@c @subsubheading LCD compatibility
Not all LCD panels are compatible yet. See @ref{LCD compatibility on GM45 laptops,gm45_lcd}. 

@node Descriptor and Gbe differences
@c @subsubheading Descriptor and Gbe differences
See @uref{../resources/misc/dumps/t500_x200_descriptor/descriptor_diff_t500_x200.txt,descriptor_diff_t500_x200.txt} and @uref{../resources/misc/dumps/t500_x200_descriptor/gbe_diff_t500_x200.txt,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:@* $ @strong{diff -u t500gbe x200gbe}@* $ @strong{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 @ref{ICH9 gen utility,ich9gen}) was re-used on the T500, and it still worked.

@node Hardware register dumps - T500
@c @subsubheading Hardware register dumps
The coreboot wiki @uref{http://www.coreboot.org/Motherboard_Porting_Guide,shows} how to collect various logs useful in porting to new boards. Following are outputs from the T500:

@itemize
@item
T500 with @strong{Macronix MX25L3205D} flash chip (4MiB, SOIC-8) and Lenovo BIOS 3.13 7VET83WW (EC firmware 1.06):
@itemize
@item
@uref{../resources/misc/dumps/t500log/,t500log/}
@end itemize

@end itemize


@node Apple Macbook1-1
@subsubsection 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 @ref{Apple Macbook2-1,MacBook2@,1} to coreboot, the ROM images also work on the macbook1,1. 

You can refer to @ref{Apple Macbook2-1,MacBook2@,1} 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:
@itemize
@item
@uref{http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook1,1,http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook1,1}
@end itemize

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

@itemize
@item
MA255LL/A / A1181 (EMC 2092) / Core Duo T2500 @strong{(tested - working)}
@item
MA254LL/A / A1181 (EMC 2092) / Core Duo T2400 @strong{(tested - working)}
@item
MA472LL/A / A1181 (EMC 2092) / Core Duo T2500 (untested)
@end itemize

Also of interest: @ref{How to build the ROM images,config_macbook21}. 

Unbricking: @uref{https://www.ifixit.com/Device/MacBook_Core_2_Duo,this page shows disassembly guides} and mono's page (see @ref{Apple Macbook2-1,MacBook2@,1}) shows the location of the SPI flash chip on the motherboard. @uref{https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529,How to remove the motherboard}. 

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 @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup}. 



@node Apple Macbook2-1
@subsubsection 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:@* @strong{$ wget -m -p -E -k -K -np http://macbook.donderklumpen.de/}@* @strong{$ wget -m -p -E -k -K -np http://macbook.donderklumpen.de/coreboot/}@* Use @strong{-e robots=off} if using this trick for other sites and the site restricts using robots.txt

@strong{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}
@menu
* Installing GNU/Linux distributions on Apple EFI firmware::
* Information about coreboot::
* coreboot wiki page::
* Compatible models::
@end menu

@node Installing GNU/Linux distributions on Apple EFI firmware
@c @subsubheading Installing GNU/Linux distributions (on Apple EFI firmware)
@itemize
@item
Parabola GNU/Linux installation on a macbook2,1 with Apple EFI firmware (this is a copy of Mono's page, see above) @c ADD REF???
@end itemize

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 @ref{MacBook2-1 install,flashrom_macbook21}.

@node Information about coreboot
@c @subsubheading Information about coreboot
@itemize
@item
Coreboot on the macbook2,1 (this is a copy of Mono's page, see above) 
@end itemize

@node coreboot wiki page
@c @subsubheading coreboot wiki page
@itemize
@item
@uref{http://www.coreboot.org/Board:apple/macbook21,http://www.coreboot.org/Board:apple/macbook21}
@end itemize

@node Compatible models
@c @subsubheading Compatible models
It is believed that all models are compatible, listed here:

@itemize
@item
@uref{http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook2,1,http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook2,1}
@end itemize

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

@itemize
@item
MA699LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T5600 @strong{(tested - working)}
@item
MA701LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 @strong{(tested - working)}
@item
MB061LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7200 (untested)
@item
MA700LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 @strong{(tested - working)}
@item
MB063LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 (untested)
@item
MB062LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 @strong{(tested - working)}
@end itemize

Also of interest: @ref{How to build the ROM images,config_macbook21}. 

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

For external flashing, refer to @ref{How to program an SPI flash chip with BeagleBone Black,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): @uref{http://review.coreboot.org/#/c/7923/,http://review.coreboot.org/#/c/7923/}.

@strong{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:

@verbatim
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
@end verbatim

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 @emph{resources/utilities/macbook21-three-finger-tap} in the libreboot git repository. The script is for GNOME, confirmed to work in Trisquel 7.


@node Recommended wifi chipsets
@subsection Recommended wifi chipsets
The following are known to work well:
@itemize
@item
@uref{http://h-node.org/search/results/en/1/search/wifi/ar9285,Atheros AR5B95} (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.
@item
@uref{http://h-node.org/wifi/view/en/116/Atheros-Communications-Inc--AR928X-Wireless-Network-Adapter--PCI-Express---rev-01-,Atheros AR928X} chipset; mini PCI-E. Most of these are half-height, so you will need a half>full height mini PCI express adapter/bracket
@item
Unex DNUA-93F (chipset: @uref{http://h-node.org/search/results/en/1/search/wifi/ar9271,Atheros AR9271}); USB.
@item
Any of the chipsets listed at @uref{https://www.fsf.org/resources/hw/endorsement/respects-your-freedom,https://www.fsf.org/resources/hw/endorsement/respects-your-freedom}
@item
Any of the chipsets listed at @uref{http://h-node.org/wifi/catalogue/en/1/1/undef/undef/yes?,http://h-node.org/wifi/catalogue/en/1/1/undef/undef/yes?}
@end itemize

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

@itemize
@item
ar5bhb116 ar9382 ABGN
@item
[0200]: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter (PCI-Express) [168c:001c]
@end itemize


@node GM45 chipsets - remove the ME
@subsection GM45 chipsets: remove the ME (manageability engine)
This sections relates to disabling and removing the ME (Intel @strong{M}anagement @strong{E}ngine) 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 @uref{http://www.coreboot.org/Intel_Management_Engine,http://www.coreboot.org/Intel_Management_Engine} and @uref{http://me.bios.io/Main_Page,http://me.bios.io/Main_Page}.

Another project recently found: @uref{http://io.smashthestack.org/me/,http://io.smashthestack.org/me/}

@menu
* ICH9 gen utility::
* ICH9 deblob utility::
* demefactory utility::
* Notes - GM45 ME removal::
@end menu

@node ICH9 gen utility
@subsubsection ICH9 gen utility
It is no longer necessary to use @ref{ICH9 deblob utility,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.

ich9gen executables can be found under ./ich9deblob/ statically compiled in libreboot_util. If you are using src or git, build ich9gen from source with:@* $ @strong{./build module ich9deblob}@* The executable will appear under resources/utilities/ich9deblob/

Run:@* $ @strong{./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 @strong{ip addr} or @strong{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:@* $ @strong{./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:

@itemize
@item
@strong{ich9fdgbe_4m.bin}: this is for GM45 laptops with the 4MB flash chip.
@item
@strong{ich9fdgbe_8m.bin}: this is for GM45 laptops with the 8MB flash chip.
@item
@strong{ich9fdgbe_16m.bin}:  this is for GM45 laptops with the 16MB flash chip.
@end itemize

Assuming that your libreboot image is named @strong{libreboot.rom}, copy the file to where @strong{libreboot.rom} is located and then insert the descriptor+gbe file into the ROM image.  For 16MiB flash chips:@* $ @strong{dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=1 count=12k conv=notrunc}@* For 8MiB flash chips:@* $ @strong{dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=1 count=12k conv=notrunc}@* For 4MiB flash chips:@* $ @strong{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 @ref{How to update/install,flashrom}. for how to flash it. 

@menu
* Write-protecting the flash chip::
@end menu

@node Write-protecting the flash chip
@ifinfo
@subsubheading Write-protecting the flash chip
@end ifinfo
Look in @emph{resources/utilities/ich9deblob/src/descriptor/descriptor.c} for the following lines in the @emph{descriptorHostRegionsUnlocked} function:

@verbatim
   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;
@end verbatim

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

@verbatim
    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 */
@end verbatim

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 @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup}.

Change them all to 0x0, then re-compile ich9gen. After you have done that, follow the notes in @ref{ICH9 deblob utility,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 @emph{-p internal:ich_spi_force=yes} but this won't actually work; it'll just brick your laptop.

For external flashing guides, refer to @ref{Installation}. 

@node ICH9 deblob utility
@subsubsection ICH9 deblob utility
@strong{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). @ref{ICH9 gen utility,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 @strong{./build module all} or @strong{./build module ich9deblob} from the main directory (./), otherwise you can build it like so:@* $ @strong{./build module ich9deblob}@* An executable file named @strong{ich9deblob} will now appear under resources/utilities/ich9deblob/

If you are working with libreboot_util release archive, you can find the utility included, statically compiled (for i686 and x86_64 on GNU/Linux) under ./ich9deblob/.

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

A 12kiB file named @strong{deblobbed_descriptor.bin} will now appear. @strong{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 @strong{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 @strong{libreboot.rom}, copy the @strong{deblobbed_descriptor.bin} file to where @strong{libreboot.rom} is located and then run:@* $ @strong{dd if=deblobbed_descriptor.bin of=libreboot.rom bs=1 count=12k conv=notrunc}

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

The utility will also generate 4 additional files:

@itemize
@item
mkdescriptor.c
@item
mkdescriptor.h
@item
mkgbe.c
@item
mkgbe.h
@end itemize

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 @strong{ich9gen} executable will be able to re-create the very same 12KiB file from scratch, based on the C structs, this time @strong{without} the need for a factory.rom dump!

You should now have a @strong{libreboot.rom} image containing the correct 4K descriptor and 8K gbe regions, which will then be safe to flash. Refer back to @ref{How to update/install,flashrom}. for how to flash it.

@node demefactory utility
@subsubsection 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):@* $ @strong{./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):@* $ @strong{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:

@verbatim
<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.
@end verbatim

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 @emph{resources/utilities/ich9deblob/}

@node Notes - GM45 ME removal
@subsubsection 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.

@menu
* Early notes::
* Flash chips::
* Early development notes::
* GBE gigabit ethernet region in SPI flash::
* GBE region - change MAC address::
* Flash descriptor region::
* platform data partition in boot flash factoryrom / lenovo bios::
@end menu

@node Early notes
@ifinfo
@subsubheading Early notes
@end ifinfo
@itemize
@item
@uref{http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf,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).
@item
textstrikeout@{@strong{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. @c ADD STRIKEOUT
@item
@strong{and the location of GPIO33 on the x200s: (was an external link. Putting it here instead)} @uref{../resources/images/x200/gpio33_location.jpg,../resources/images/x200/gpio33_location.jpg} - it's above the number 7 on TP37 (which is above the big intel chip at the bottom)
@item
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: @uref{http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf,http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf}
@end itemize

@node Flash chips
@ifinfo
@subsubheading Flash chips
@end ifinfo
@itemize
@item
Schematics for X200 laptop: @uref{http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf,http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf} @strong{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:
@itemize
@item
ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip
@item
MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb (4MiB) chip
@item
MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb (8MiB) chip
@item
Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip
@end itemize

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.
@item
Schematics for X200s laptop: @uref{http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf,http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf}.
@end itemize

@node Early development notes
@ifinfo
@subsubheading Early development notes
@end ifinfo

@verbatim

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

@end verbatim

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.

@node GBE gigabit ethernet region in SPI flash
@ifinfo
@subsubheading GBE (gigabit ethernet) region in SPI flash
@end ifinfo
Of the 8K, about 95% is 0xFF. The data is the gbe region is fully documented in this public datasheet: @uref{http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf,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:

@verbatim

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  
@end verbatim

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.
@c @menu
@c * GBE region change MAC address::
@c @end menu

@node GBE region - change MAC address
@ifinfo
@subsubheading GBE region: change MAC address
@end ifinfo
According to the datasheet, it's supposed to add up to 0xBABA but can actually be others on the X200. @uref{https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums,https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums}

@emph{"One of those engineers loves classic rock music, so they selected 0xBABA"}

In honour of the song @emph{Baba O'Reilly} by @emph{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.

@itemize
@item
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.
@end itemize

@node Flash descriptor region
@ifinfo
@subsubheading Flash descriptor region
@end ifinfo
@uref{http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf,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:

@itemize
@item
patch the number of regions present in the descriptor from 5 - 3
@item
originally descriptor + bios + me + gbe + platform
@item
modified = descriptor + bios + gbe
@item
the next stage is to patch the part of the descriptor which defines the start and end point of each section
@item
then cut out the gbe region and insert it just after the region
@item
all this can be substantiated with public docs (ICH9 datasheet)
@item
the final part is flipping 2 bits. Halting the ME via 1 MCH soft strap and 1 ICH soft strap
@item
the part of the descriptor described there gives the base address and length of each region (bits 12:24 of each address)
@item
to disable a region, you set the base address to 0xFFF and the length to 0
@item
and you change the number of regions from 4 (zero based) to 2
@end itemize

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

@itemize
@item
map the first 4k into the struct (minus the gbe region)
@item
set NR in FLMAP0 to 2 (from 4)
@item
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)
@item
set meDisable to 1/true in ICHSTRAP0 and MCHSTRAP0
@item
extract the 8k GBe region and append that to the end of the 4k descriptor
@item
output the 12k concatenated chunk
@item
Then it can be dd'd into the first 12K part of a coreboot image.
@item
the GBe region always starts 0x20A000 bytes from the end of the ROM
@end itemize

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

@itemize
@item
descriptor (4K)
@item
gbe (8K)
@item
bios (rest of flash chip. CBFS also set to occupy this whole size)
@end itemize

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, @emph{x << 12 = address}

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

@node platform data partition in boot flash factoryrom / lenovo bios
@ifinfo
@subsubheading platform data partition in boot flash (factory.rom / lenovo bios)
@end ifinfo
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.


@node LCD compatibility on GM45 laptops
@subsection 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.

@strong{All X200/X200S/X200T LCD panels are believed to be compatible.}

@menu
* The problem::
* Current workaround::
* Differences in dmesg::
@end menu


@node The problem
@subsubsection 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.

@node Current workaround
@subsubsection 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 @strong{i915.lvds_channel_mode=2} as a kernel option in grub.cfg.

@node Differences in dmesg
@subsubsection Differences in dmesg (kernel parameter added)
@uref{https://01.org/linuxgraphics/documentation/how-report-bugs,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.

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

@uref{http://www.coreboot.org/pipermail/coreboot/attachments/20150712/d2e214bb/attachment-0003.txt,dmesg with lenovobios} (lenovobios) - For the same line, it says dual-channel lvds configuration.
@menu
* EDID::
@end menu

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

@verbatim
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    ................
@end verbatim

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:

@verbatim
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
@end verbatim

Another incompatible (T400) screen:

@verbatim
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    ................
@end verbatim

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):

@verbatim
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
@end verbatim

Another compatible T400 screen:

@verbatim
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    ................
@end verbatim





@node Installation
@section 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.

@c ADD itemize block here to show subsections?

@menu
* Software methods::
* Hardware methods::
@end menu


@node Software methods
@subsection Software methods


@menu
* List of ROM images in libreboot::     Pre-compiled images for user convenience
* QEMU::                                ROM images for QEMU
* How to update/install::               If you are already running libreboot or coreboot
* ThinkPad X60/T60 install::            Initial installation guide if running proprietary firmware
* MacBook2-1 install::                 Initial installation guide if running proprietary firmware
* ASUS Chromebook C201 install::        Installing Libreboot internally, from the device
@end menu
@c QUESTION: Should the device-specific instructions be moved to their own nodes on this level?


@node List of ROM images in libreboot
@subsubsection 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: @strong{_@emph{keymap}_@emph{mode}.rom}

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

@emph{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 @ref{GRUB keyboard layouts - for reference,grub_keyboard}.

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

Examples of how to use libreboot ROM images in QEMU:

@itemize
@item
$ @strong{qemu-system-i386 -M q35 -m 512 -bios qemu_q35_ich9_keymap_mode.rom}
@item
$ @strong{qemu-system-i386 -M pc -m 512 -bios qemu_i440fx_piix4_keymap_mode.rom}
@end itemize

You can optionally specify the @strong{-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.


@node How to update/install
@subsubsection 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.

@strong{If you are using libreboot_src or git, then make sure that you built the sources first (see @ref{How to build the ROM images,build}).}

Look at the @ref{List of ROM images in libreboot,list of ROM images} to see which image is compatible with your device.
@menu
* Are you currently running the original proprietary firmware?::
* ASUS KFSN4-DRE?::
* ASUS KGPE-D16?::
* ASUS KCMA-D8?::
* Are you currently running libreboot or coreboot?::
* MAC address on GM45 X200/R400/T400/T500::
* Flash chip size::
* All good?::
@end menu

@node Are you currently running the original proprietary firmware?
@c @subsubheading Are you currently running the original, proprietary firmware?
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 @ref{ThinkPad X60/T60 install,flashrom_lenovobios}. MacBook2,1 users running Apple EFI should refer to @ref{MacBook2-1 install,flashrom_macbook21}.

X200 users, refer to @ref{ThinkPad X200/X200S/X200T,x200_external}, R400 users refer to @ref{ThinkPad R400,r400_external}, T400 users refer to @ref{ThinkPad T400,t400_external}, T500 users refer to @ref{ThinkPad T500,t500_external}.

@node ASUS KFSN4-DRE?
@c @subsubheading ASUS KFSN4-DRE?
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.

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

Do check the HCL entry: @ref{ASUS KFSN4-DRE motherboard,kfsn4-dre-hcl}.

@node ASUS KGPE-D16?
@c @subsubheading ASUS KGPE-D16?
If you have the proprietary BIOS, you need to flash libreboot externally. See @ref{KGPE-D16,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).

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

Do check the HCL entry: @ref{ASUS KGPE-D16 motherboard,kgpe-d16-hcl}.

@node ASUS KCMA-D8?
@c @subsubheading ASUS KCMA-D8?
If you have the proprietary BIOS, you need to flash libreboot externally. See @ref{KCMA-D8,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).

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

Do check the HCL entry: @ref{ASUS KCMA-D8 motherboard,kcma-d8-hcl} 

@node Are you currently running libreboot or coreboot?
@c @subsubheading Are you currently running libreboot (or coreboot)?
X60/T60 users should be fine with this guide. If you write-protected the flash chip, please refer to @ref{ThinkPad X60 Recovery Guide,x60_unbrick}, @ref{ThinkPad X60 Tablet Recovery Guide,x60tablet_unbrick} or @ref{ThinkPad T60 Recovery Guide,t60_unbrick}. @emph{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 (@strong{@emph{libreboot does not write-protect the flash chip by default, so this probably applies to you}}), read on!

@node MAC address on GM45 X200/R400/T400/T500
@c @subsubheading MAC address on GM45 (X200/R400/T400/T500)
@strong{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. @emph{Make sure to change the MAC address inside the ROM image, before flashing it. The instructions on @ref{ICH9 gen utility,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.

@node Flash chip size
@c @subsubheading Flash chip size
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}

@node All good?
@c @subsubheading All good?
Excellent! Moving on...

Download the @emph{libreboot_util.tar.xz} archive, and extract it. Inside, you will find a directory called @emph{flashrom}. This contains statically compiled executable files of the @emph{flashrom} utility, which you will use to re-flash your libreboot system.

Simply use @emph{cd} on your terminal, to switch to the @emph{libreboot_util} directory. Inside, there is a script called @emph{flash}, which will detect what CPU architecture you have (e.g. i686, x86_64) and use the appropriate executable. It is also possible for you to build these executables from the libreboot source code archives.

How to update the flash chip contents:@* $ @strong{sudo ./flash update @ref{List of ROM images in libreboot,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:@* $ @strong{sudo ./flash forceupdate @ref{List of ROM images in libreboot,yourrom.rom}} 

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


@node ThinkPad X60/T60 install
@subsubsection ThinkPad X60/T60: Initial installation guide (if running the proprietary firmware)
@strong{This is for the ThinkPad X60 and T60 while running Lenovo BIOS. If you already have coreboot or libreboot running, then go to @ref{How to update/install,flashrom} instead!}

@strong{If you are flashing a Lenovo ThinkPad T60, be sure to read @ref{Supported T60 list,supported_t60_list}}

@strong{If you are using libreboot_src or git, then make sure that you built the sources first (see @ref{How to build the ROM images,build}).} 

@strong{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 @uref{http://www.coreboot.org/Board:lenovo/x60/Installation,http://www.coreboot.org/Board:lenovo/x60/Installation}.}

@strong{If you're using libreboot 20150518, note that there is a mistake in the flashing script. do this: @emph{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:@* $ @strong{sudo ./flash i945lenovo_firstflash @ref{List of ROM images in libreboot,yourrom.rom}.} 

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

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

See this link for more details: @uref{http://thread.gmane.org/gmane.linux.bios.flashrom/575,http://thread.gmane.org/gmane.linux.bios.flashrom/575}.

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

When you have booted up again, you must also do this:@* $ @strong{sudo ./flash i945lenovo_secondflash @ref{List of ROM images in libreboot,yourrom.rom}} 

If flashing fails at this stage, try the following:@* $ @strong{sudo ./flashrom/i686/flashrom -p internal:laptop=force_I_want_a_brick -w @ref{List of ROM images in libreboot,yourrom.rom}}

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

You should also see within the output the following:@* @strong{"Verifying flash... VERIFIED."}


@node MacBook2-1 install
@subsubsection MacBook2,1: Initial installation guide (if running the proprietary firmware)
@strong{If you have a MacBook1,1, refer to @ref{Apple Macbook1-1,macbook1-1} for flashing instructions.} 

@strong{This is for the MacBook2,1 while running Apple EFI firmware. If you already have coreboot or libreboot running, then go to @ref{How to update/install,flashrom} instead!} 

Be sure to read the information in @ref{Apple Macbook2-1,macbook2-1}. 

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

@strong{If you are using libreboot_src or git, then make sure that you built the sources first (see @ref{How to build the ROM images,build}).} 

Look at the @ref{List of ROM images in libreboot,list of ROM images} to see which image is compatible with your device. 

Use this flashing script, to install libreboot:@* $ @strong{sudo ./flash i945apple_firstflash @ref{List of ROM images in libreboot,yourrom.rom}} 

You should also see within the output the following:@* @strong{"Verifying flash... VERIFIED."}

Shut down.


@node ASUS Chromebook C201 install
@subsubsection 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.

@strong{DO NOT BUY THIS LAPTOP YET!!!!!!!!!!! This is intended mainly for developers at the moment (libreboot developers, and developers of libre GNU/Linux distributions). This laptop currently has @emph{zero} support from libre distros. Parabola theoretically supports it, by installing Arch first and then migrating to Parabola using the migration guide on the Parabola wiki, but it's not very well tested and does not have many packages - in our opinion, Parabola does not really support this laptop. There are also several issues. Read @ref{ASUS Chromebook C201,this page} for more information. This laptop can still be used reasonably, in freedom, but it requires a lot of work. Most users will be disappointed.} 

@strong{If you are using libreboot_src or git, then make sure that you built the sources first (see @ref{How to build the ROM images,build}).} 

Look at the @ref{List of ROM images in libreboot,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 @strong{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.

@strong{Google's modified version of flashrom} is free software and its source code is made available by Google: @uref{https://chromium.googlesource.com/chromiumos/third_party/flashrom/,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.

@menu
* Gaining root privileges on ChromeOS::
* Preparing the device for the installation::
* Installing Libreboot to the SPI flash::
@end menu


@node Gaining root privileges on ChromeOS
@c @subsubheading Gaining root privileges on ChromeOS

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 @ref{Recovery mode screen,recovery mode screen} and @ref{Enabling developer mode,enabling developer mode} are available on the page dedicated to @ref{Depthcharge,depthcharge}. 

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

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

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

@node Preparing the device for the installation
@c @subsubheading Preparing the device for the installation
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.

@menu
* Configuring verified boot parameters::
* Removing the write protect screw::
@end menu

@node Configuring verified boot parameters
@c @subsubheading Configuring verified boot parameters
It is recommended to have access to the @ref{Developer mode screen,developer mode screen} and to @ref{Configuring verified boot parameters for depthcharge,configure the following verified boot parameters}: 

@itemize
@item
Kernels signature verification: @emph{disabled}
@item
External media boot: @emph{enabled}
@end itemize

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

@node Removing the write protect screw
@c @subsubheading Removing the write protect screw
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 @emph{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. @strong{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.

@uref{../resources/images/c201/screws.jpg,@image{../resources/images/c201/screws,,,Screws,jpg}} @uref{../resources/images/c201/wp-screw.jpg,@image{../resources/images/c201/wp-screw,,,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.

@node Installing Libreboot to the SPI flash
@c @subsubheading Installing Libreboot to the SPI flash
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 @emph{read-only} coreboot partition, that becomes writable after removing the write-protect screw.
@menu
* Installing Libreboot internally from the device::
* Installing Libreboot externally with a SPI flash programmer::
@end menu

@node Installing Libreboot internally from the device
@c @subsubheading Installing Libreboot internally, from the device
Before installing Libreboot to the SPI flash internally, the device has to be reassembled.

All the files from the @strong{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 @emph{root} account). In addition, the @strong{cros-flash-replace} script has to be made executable:@* # @strong{chmod a+x cros-flash-replace}@*

The SPI flash has to be read first:@* # @strong{flashrom -p host -r flash.img}@* @strong{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 @strong{cros-flash-replace} script has to be executed as such:@* # @strong{./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:@* # @strong{flashrom -p host -w flash.img}@*

You should also see within the output the following:@* @strong{"Verifying flash... VERIFIED."}

Shut down. The device will now boot to Libreboot.

@node Installing Libreboot externally with a SPI flash programmer
@c @subsubheading Installing Libreboot externally, with a SPI flash programmer
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 @strong{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.

@uref{../resources/images/c201/spi-flash-layout.jpg,@image{../resources/images/c201/spi-flash-layout,,,SPI flash layout,jpg}} @uref{../resources/images/c201/battery-connector.jpg,@image{../resources/images/c201/battery-connector,,,Battery connector,jpg}}

All the files from the @strong{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 @emph{root} account). In addition, the @strong{cros-flash-replace} script has to be made executable:@* # @strong{chmod a+x cros-flash-replace}@*

The SPI flash has to be read first (using the right spi programmer):@* # @strong{flashrom -p @emph{programmer} -r flash.img}@* @strong{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 @strong{cros-flash-replace} script has to be executed as such:@* # @strong{./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):@* # @strong{flashrom -p @emph{programmer} -w flash.img}@*

You should also see within the output the following:@* @strong{"Verifying flash... VERIFIED."}

The device will now boot to Libreboot.




@node Hardware methods
@subsection Hardware methods

@menu
* How to program an SPI flash chip with BeagleBone Black::
* GA-G41M-ES2L flashing tutorial::
* Flashing Intel D510MO::
* Configuring EHCI debugging on the BeagleBone Black::
* KGPE-D16::                                                    Needed if running proprietary firmware, or to unbrick
* KCMA-D8::                                                     Needed if running proprietary firmware, or to unbrick
* ThinkPad X60 Recovery Guide::
* ThinkPad X60 Tablet Recovery Guide::
* ThinkPad T60 Recovery Guide::
* ThinkPad X200/X200S/X200T::                                   Needed if running proprietary firmware, or to unbrick
* ThinkPad R400::                                               Needed if running proprietary firmware, or to unbrick
* ThinkPad T400::                                               Needed if running proprietary firmware, or to unbrick
* ThinkPad T500::                                               Needed if running proprietary firmware, or to unbrick
@end menu


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

@menu
* Hardware requirements - BBB::
* Setting up the 33V DC PSU::
* Accessing the operating system on the BBB::
* Setting up spidev on the BBB::
* Connecting the Pomona 5250/5252::
* Notes about stability::
@end menu

@node Hardware requirements - BBB
@c @subsubheading Hardware requirements
Shopping list (pictures of this hardware is shown later):

@itemize
@item
A @uref{http://flashrom.org,Flashrom}-compatible external SPI programmer: @strong{BeagleBone Black}, sometimes referred to as 'BBB', (rev. C) is highly recommended.  You can buy one from @uref{https://www.adafruit.com,Adafruit} (USA), @uref{http://electrokit.com,Electrokit} (Sweden) or any of the distributors listed @uref{http://beagleboard.org/black,here} (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.
@item
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 @uref{http://www.hammondmfg.com/1593HAM.htm#BeagleBoneBlack,hammond plastic enclosure}.
@item
Clip for connecting to the flash chip: if you have a SOIC-16 flash chip (16 pins), you will need the @strong{Pomona 5252} or equivalent.  For SOIC-8 flash chips (8 pins), you will need the @strong{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.  @uref{http://farnell.com/,Farnell element 14} 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.  @strong{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.}
@item
@strong{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).
@itemize
@item
Getting a multimeter might be worthwhile, to verify that it's supplying 3.3V.
@end itemize

@item
@strong{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.  @strong{OPTIONAL. Only needed if not powering with the USB cable, or if you want to use @ref{ Configuring EHCI debugging on the BeagleBone Black,EHCI debug}}. 
@item
@strong{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
@itemize
@item
flying leads
@item
dupont (or other brand names)
@item
breadboard cables (since they are often used on breadboards).
@end itemize

@uref{https://www.adafruit.com,Adafruit} sell them, as do many others.  @strong{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.
@item
@strong{Mini USB A-B cable}: the BBB probably already comes with one.  @strong{OPTIONAL---only needed for @ref{ Configuring EHCI debugging on the BeagleBone Black,EHCI debug} or for serial/SSH access without ethernet cable (g_multi kernel module)}. 
@item
@strong{FTDI TTL cable or debug board}: used for accessing the serial console on the BBB.  @uref{http://elinux.org/Beagleboard:BeagleBone_Black_Serial,This page} contains a list.  @strong{OPTIONAL---only needed for serial console on the BBB, if not using SSH via ethernet cable.}
@end itemize

@node Setting up the 33V DC PSU
@c @subsubheading Setting up the 3.3V DC PSU
ATX PSU pinouts can be read on @uref{https://en.wikipedia.org/wiki/Power_supply_unit_%28computer%29#Wiring_diagrams,this Wikipedia page}.

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).

@strong{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:@* @image{../resources/images/x200/psu33,,,,jpg}

@node Accessing the operating system on the BBB
@c @subsubheading Accessing the operating system on the BBB
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.

@itemize
@item
Alternatives to SSH in case SSH fails::

You can also use a serial FTDI debug board with GNU Screen, to access the serial console.@* # @strong{screen /dev/ttyUSB0 115200}@* Here are some example photos:@* @image{../resources/images/x200/ftdi,,,,jpg} @image{../resources/images/x200/ftdi_port,,,,jpg}@*

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:@* # @strong{screen /dev/ttyACM0 115200}

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

@node Setting up spidev on the BBB
@c @subsubheading Setting up spidev on the BBB
Log on as root on the BBB, using either SSH or a serial console as defined in @ref{Accessing the operating system on the BBB,bbb_access}. Make sure that you have internet access on your BBB.

Follow the instructions at @uref{http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0,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 @uref{https://groups.google.com/forum/?_escaped_fragment_=msg/beagleboard/LPjCn4LEY2I/alozBGsbTJMJ#!msg/beagleboard/LPjCn4LEY2I/alozBGsbTJMJ,work around a bug} 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:

@verbatim
#!/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
@end verbatim

Run @strong{apt-get update} and @strong{apt-get upgrade} then reboot the BBB, before continuing.

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

@verbatim
/lib/firmware/BB-SPI0-01-00A0.dtbo
@end verbatim

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

@verbatim
 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
@end verbatim

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

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

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

Get flashrom from the libreboot_util release archive, or build it from libreboot_src/git if you need to. An ARM binary (statically compiled) for flashrom exists in libreboot_util releases. Put the flashrom binary on your BBB.

You may also need ich9gen, if you will be flashing an ICH9-M laptop (such as the X200). Get it from libreboot_util, or build it from libreboot_src, and put the ARM binary for it on your BBB.

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

Now test flashrom:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512}@* Output:

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

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

@node Connecting the Pomona 5250/5252
@c @subsubheading Connecting the Pomona 5250/5252
Use this image for reference when connecting the pomona to the BBB: @uref{http://beagleboard.org/Support/bone101#headers,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):

@verbatim
 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
@end verbatim

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

@verbatim
 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
@end verbatim

@strong{NC = no connection}

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

@strong{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, @strong{but} keep all other leads short (10cm or less)

You should now have something that looks like this:@* @image{../resources/images/x200/5252_bbb0,,,,jpg} @image{../resources/images/x200/5252_bbb1,,,,jpg}


@node Notes about stability
@c @subsubheading Notes about stability
@uref{http://flashrom.org/ISP,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:

@itemize
@item
"coax" with 0.1 mm core and aluminum foley (from my kitchen), add 100 Ohm resistors (serial)
@item
put heatshrink above the foley, for: CS, CLK, D0, D1
@item
Twisted pair used as core (in case more capacitors are needed)
@item
See this image: @uref{http://i.imgur.com/qHGxKpj.jpg,http://i.imgur.com/qHGxKpj.jpg}
@item
He was able to flash at 50MHz (lower speeds are also fine).
@end itemize



@node GA-G41M-ES2L flashing tutorial
@subsubsection 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.

@menu
* Flash chip size - GA-G41M-ES2L::
* Flashing instructions - GA-G41M-ES2L::
@end menu

@node Flash chip size - GA-G41M-ES2L
@ifinfo
@subsubheading Flash chip size
@end ifinfo
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}

@node Flashing instructions - GA-G41M-ES2L
@ifinfo
@subsubheading Flashing instructions - GA-G41M-ES2L
@end ifinfo
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup} for how to set up the BBB for flashing it externally, if you want to do that.

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!

Do refer to the @ref{Hardware compatibility,compatibility page} for more information about this board. 


@node Flashing Intel D510MO
@subsubsection 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.

@menu
* Flash chip size - D510MO::
* Flashing instructions - D510MO::
@end menu

@node Flash chip size  - D510MO
@c @subsubheading Flash chip size
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}

@node Flashing instructions - D510MO
@c @subsubheading Flashing instructions - D510MO
@image{../resources/images/d510mo/d510mo,,,,jpg} 

Use this image for reference, then refer to @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup} for how to set up the BBB for flashing it. 

Do refer to the @ref{Hardware compatibility,compatibility page} for more information about this board. 




@node Configuring EHCI debugging on the BeagleBone Black
@subsubsection 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:

@itemize
@item
@strong{host} - this is the computer you use, have tools, compiler, Internet, etc
@item
@strong{BBB} - Beaglebone Black (rev. B or higher, i use rev. C)
@item
@strong{target} - the computer you are trying to install liberboot
@end itemize

@menu
* Find USB port on the target that supports EHCI debug::
* Initial setup of BBB to act as EHCI debug dongle::
* Patch BBB's g_dbgp module::                   Optional, but highly recommended
* Configure libreboot with EHCI debug::
* Selecting HCD Index and USB Debug port::
* How to get the debug logs::
* Enable EHCI Debug on the target's kernel::    Optional , but recommended
* References::
@end menu


@node Find USB port on the target that supports EHCI debug
@c @subsubheading Find USB port on the target that supports EHCI debug
Not all USB controllers support EHCI debug (see: @uref{http://www.coreboot.org/EHCI_Debug_Port#Hardware_capability,EHCI Debug Port} ). Even more, if a USB controller supports EHCI debug, it is available only @strong{on a single port} that might or might not be exposed externally.

@itemize
@item
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)
@item
You need USB memory stick (the data on it will not be touched).
@item
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)
@end itemize

@itemize
@item
Download @xref{1-ehci-ref,,1}, @uref{http://www.coreboot.org/pipermail/coreboot/attachments/20080909/ae11c291/attachment.sh,this} shell script. 
@end itemize

@enumerate 
@item
Plug the usb stick in the first available usb port
@item
Run the script, you will get output similar to following:
@item
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
@item
Repeat the steps, plugging the USB stick in the next available port
@item
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).
@end enumerate

Remember (write down) for each port (external plug) you found that supports debug: @strong{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.

@anchor{1-ehci-ref}
The guys from coreboot were talking about including the script in coreboot distribution (check the status).

@node Initial setup of BBB to act as EHCI debug dongle
@c @subsubheading Initial setup of BBB to act as EHCI debug dongle
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:

@itemize
@item
power supply (5V, 2A(10W) is sufficient).
@item
an extra usb cable: A to mini-B
@end itemize

(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):

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

Unload all other g_* modules:

@verbatim
# lsmod
# rmmod g_multi
...
@end verbatim

Then load g_dbgp :

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

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:

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

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

@node Patch BBB's g_dbgp module
@c @subsubheading Patch BBB's g_dbgp module (optional, but highly recommended)
For the reasons why you need this, see: @uref{http://www.coreboot.org/EHCI_Gadget_Debug,EHCI Gadget Debug}.@*Make sure that you have cross compiling environment for arm-linux-gnueabihf setup on your @emph{host}.

@itemize
@item
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
@item
Get the BBB kernel ready on your host for cross-compiling:
@end itemize

@verbatim
$ 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
@end verbatim

@itemize
@item
Download the patch from @uref{http://www.coreboot.org/images/8/88/Ehci-debug-gadget-patches.tar.gz,here}
@item
tar -xf Ehci-debug-gadget-patches.tar.gz (will create dir: usbdebug-gadget)
@item
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)
@item
cd kernel (note that this is one more level: you should be in $work_dir/kernel/kernel)
@item
Apply the patches:
@end itemize

@verbatim
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@
@end verbatim

@itemize
@item
You should also apply the linux-libre @emph{deblob} script to turn it into linux-libre (deletes all the blobs from the linux kernel). @uref{http://www.fsfla.org/ikiwiki/selibre/linux-libre/,fsfla website} - see @uref{http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/,scripts}.
@item
Get your current BBB kernel config (from: /boot/config-<ver>) and copy it to your host as $work_dir/kernel/kernel/.config
@item
Set proper version number:
@itemize
@item
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"
@end itemize

@item
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
@item
Build the module:
@end itemize

@verbatim
$ 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
@end verbatim

@itemize
@item
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)
@item
copy the freshly compiled usb/gadget dir to /lib/modules/3.8.13-bone70/kernel/drivers/usb
@item
restart BBB
@item
Remove all g_* modules (rmmod g_<>)
@item
modprobpe g_dbgp
@end itemize

@node Configure libreboot with EHCI debug
@c @subsubheading Configure libreboot with EHCI debug
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:

@itemize
@item
Go to the libreboot dist root directory cd $libreboot_bin
@item
Locate the rom image for your target (I will call it: $img_path)
@item
Running the following command will extract the config in a file ./my_config:
@end itemize

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

@itemize
@item
Make sure that the following params in the config are set as following:
@end itemize

@verbatim
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)
@end verbatim

The following three are behind radio button in the menu. Only the first one @xref{2-ehci-ref,,2}, should be = y

@verbatim
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)
@end verbatim

@anchor{2-ehci-ref}
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 @uref{https://johnlewis.ie/coreboot-ehci-debug-gadget-demonstration/,here} (also tested/verified).

Then:@*

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

Also Debugging ---> Output verbose XYZ ) (@strong{FIXME} somebody verify these):

@verbatim
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)
@end verbatim

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(@strong{FIXME: link} about compiling libreboot.

@node Selecting HCD Index and USB Debug port
@c @subsubheading Selecting HCD Index and USB Debug port
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).

@itemize
@item
On T500 (with switchable GPU) the debug ports for both intel controllers is exposed.
@item
On x200t the debug ports for both intel controllers is exposed.
@end itemize

@node How to get the debug logs
@c @subsubheading How to get the debug logs
@itemize
@item
Plug the USB cable in the target's debug port (the one you found in step 1) and BBB's mini-B USB
@item
Make sure no other then g_dbgp of the g_* modules is loaded on your BBB
@item
On the BBB:
@end itemize

@verbatim
stty -icrnl -inlcr -F /dev/ttyGS0
cat /dev/ttyGS0
@end verbatim

@itemize
@item
Power on the target with libreboot
@item
You should see debug logs comming on your BBB console
@end itemize

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

@node Enable EHCI Debug on the target's kernel
@c @subsubheading Enable EHCI Debug on the target's kernel (optional, recommended)
You have to know how to compile kernel for your target.

@enumerate 
@item
Check if early debugging is already enabled: grep CONFIG_EARLY_PRINTK_DBGP /boot/config-<ver>
@item
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.
@item
Edit your grub configuration and add following to the kernel parameters @xref{20-ehci-ref,,20}, @xref{21-ehci-ref,21},: earlyprintk=dbgp,keep. Also, try: earlyprintk=dbgp<N>,keep where N is the debug port id if the first does not work. @c TYPO: kenel > kernel
@end enumerate

@node References
@c @subsubheading References
@c NOTE: Many of these are not referenced above.
@enumerate
@item @anchor{10-ehci-ref}
@uref{http://www.coreboot.org/EHCI_Debug_Port,EHCI Debug Port}

@item @anchor{11-ehci-ref}
@uref{https://johnlewis.ie/coreboot-ehci-debug-gadget-demonstration/,coreboot EHCI debug gadget demonstration}

@item @anchor{12-ehci-ref}
@uref{http://www.coreboot.org/EHCI_Gadget_Debug,EHCI Gadget Debug}

@item @anchor{13-ehci-ref}
@uref{http://www.coreboot.org/images/8/88/Ehci-debug-gadget-patches.tar.gz,Ehci-debug-gadget-patches.tar.gz}

@item @anchor{14-ehci-ref}
@uref{http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel,Compiling the BeagleBone Black Kernel}

@item @anchor{15-ehci-ref}
@uref{http://dumb-looks-free.blogspot.ca/2014/06/beaglebone-black-bbb-compile-kernel.html}

@item @anchor{16-ehci-ref}
@uref{http://dumb-looks-free.blogspot.fr/2014/06/beaglebone-black-bbb-kernal-headers.html}

@item @anchor{17-ehci-ref}
@uref{http://elinux.org/Building_BBB_Kernel,Building BBB Kernel}

@item @anchor{18-ehci-ref}
@uref{http://komposter.com.ua/documents/USB-2.0-Debug-Port%28John-Keys%29.pdf}

@item @anchor{19-ehci-ref}
@uref{http://cs.usfca.edu/~cruse/cs698s10/,Exploring USB at the Hardware/Software Interface}

@item @anchor{20-ehci-ref}
@uref{https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt}

@item @anchor{21-ehci-ref}
@uref{https://wiki.ubuntu.com/Kernel/Debugging/USBearlyprintk}

@strong{TODO}:

@enumerate 
@item
grub does not send messages to EHCI debug. Investigate.
@item
The section ``Configure libreboot with EHCI debug'' can be skipped/simplified if a common configuration works for all relevant targets is selected as defualt
@item
Patch and compule g_dbgp on BBB instead cross-compile
@item
Find a simple way to send debug messages from targets userland
@end enumerate
@end enumerate



@node KGPE-D16
@subsubsection Initial flashing instructions for KGPE-D16

@strong{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 @ref{ASUS KGPE-D16 motherboard,kgpe-d16}. 

TODO: show photos here, and other info.

@menu
* KGPE-D16 boards and full systems with libreboot preinstalled::
* External programmer - KGPE-D16::
@end menu

@node KGPE-D16 boards and full systems with libreboot preinstalled
@c @subsubheading KGPE-D16 boards (and full systems) with libreboot preinstalled
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 @uref{../../suppliers,suppliers} page for more information. 

@node External programmer - KGPE-D16
@c @subsubheading External programmer
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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. @strong{DO NOT} remove the chip with your hands. Use a chip extractor tool.




@node KCMA-D8
@subsubsection Initial flashing instructions for KCMA-D8
@strong{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 @ref{ASUS KCMA-D8 motherboard,kcma-d8}. 

TODO: show photos here, and other info.

@menu
* KCMA-D8 boards and full systems with libreboot preinstalled::
* External programmer - KCMA-D8::
@end menu

@node KCMA-D8  boards and full systems with libreboot preinstalled
@c @subsubheading KCMA-D8 boards (and full systems) with libreboot preinstalled
@c NOTE: I added this section from ./install/kgpe-d16.texi because it was linked to but nonexistent on website
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 @uref{../../suppliers,suppliers} page for more information. 

@node External programmer - KCMA-D8
@c @subsubheading External programmer
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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. @strong{DO NOT} remove the chip with your hands. Use a chip extractor tool.



@node ThinkPad X60 Recovery Guide
@subsubsection ThinkPad X60: Recovery guide

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

Types of brick:

@menu
* Bucts not reset - X60::
* Bad rom or user error - X60::
@end menu

@node Bucts not reset - X60
@c @subsubheading Brick type 1: bucts not reset.
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:@* @image{../resources/images/x60_unbrick/0004,,,,jpg}@*@* *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: @uref{http://www.coreboot.org/Board:lenovo/x60/Installation,http://www.coreboot.org/Board:lenovo/x60/Installation}.

@node Bad rom or user error - X60
@c @subsubheading Brick type 2: Bad rom (or user error), system won't boot
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:@* @image{../resources/images/x60_unbrick/0000,,,,jpg} @c IMAGES

Push the keyboard forward (carefully):@* @image{../resources/images/x60_unbrick/0001,,,,jpg}

Lift the keyboard up and disconnect it from the board:@* @image{../resources/images/x60_unbrick/0002,,,,jpg}

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:@* @image{../resources/images/x60_unbrick/0003,,,,jpg}

You should now have this:@* @image{../resources/images/x60_unbrick/0004,,,,jpg}

Disconnect the wifi antenna cables, the modem cable and the speaker:@* @image{../resources/images/x60_unbrick/0005,,,,jpg}

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:@* @image{../resources/images/x60_unbrick/0006,,,,jpg}

Disconnect the monitor from the motherboard, and unroute the grey antenna cable, carefully lifting the tape that holds it into place:@* @image{../resources/images/x60_unbrick/0008,,,,jpg}

Carefully lift the remaining tape and unroute the left antenna cable so that it is loose:@* @image{../resources/images/x60_unbrick/0009,,,,jpg}

Remove the screw that is highlighted (do NOT remove the other one; it holds part of the heatsink (other side) into place):@* @image{../resources/images/x60_unbrick/0011,,,,jpg}

Remove those screws:@* @image{../resources/images/x60_unbrick/0012,,,,jpg}

Carefully remove the plate, like so:@* @image{../resources/images/x60_unbrick/0013,,,,jpg}

Remove the SATA connector:@* @image{../resources/images/x60_unbrick/0014,,,,jpg}

Now remove the motherboard (gently) and cast the lcd/chassis aside:@* @image{../resources/images/x60_unbrick/0015,,,,jpg}

Lift back that tape and hold it with something. Highlighted is the SPI flash chip:@* @image{../resources/images/x60_unbrick/0016,,,,jpg}

Now wire up the BBB and the Pomona with your PSU.@* Refer to @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup} for how to setup the BBB for flashing.@* @strong{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)} @image{../resources/images/x60_unbrick/0017,,,,jpg}@* Correlate the following with the BBB guide linked above: 

@verbatim
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.
@end verbatim

Connecting the BBB and pomona (in this image, an external 3.3v DC PSU was used):@* @image{../resources/images/x60/th_bbb_flashing,,,,jpg}

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

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

It should be @strong{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:@* @image{../resources/images/x60_unbrick/0026,,,,jpg}

Your empty chassis:@* @image{../resources/images/x60_unbrick/0027,,,,jpg}

Put the motherboard back in:@* @image{../resources/images/x60_unbrick/0028,,,,jpg}

Reconnect SATA:@* @image{../resources/images/x60_unbrick/0029,,,,jpg}

Put the plate back and re-insert those screws:@* @image{../resources/images/x60_unbrick/0030,,,,jpg}

Re-route that antenna cable around the fan and apply the tape:@* @image{../resources/images/x60_unbrick/0031,,,,jpg}

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:@* @image{../resources/images/x60_unbrick/0032,,,,jpg}

Re-insert that screw:@* @image{../resources/images/x60_unbrick/0033,,,,jpg}

Route the black antenna cable like so:@* @image{../resources/images/x60_unbrick/0034,,,,jpg}

Tuck it in neatly like so:@* @image{../resources/images/x60_unbrick/0035,,,,jpg}

Route the modem cable like so:@* @image{../resources/images/x60_unbrick/0036,,,,jpg}

Connect modem cable to board and tuck it in neatly like so:@* @image{../resources/images/x60_unbrick/0037,,,,jpg}

Route the power connection and connect it to the board like so:@* @image{../resources/images/x60_unbrick/0038,,,,jpg}

Route the antenna and modem cables neatly like so:@* @image{../resources/images/x60_unbrick/0039,,,,jpg}

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):@* @image{../resources/images/x60_unbrick/0040,,,,jpg}

Connect the modem cable:@* @image{../resources/images/x60_unbrick/0041,,,,jpg}

Connect the speaker:@* @image{../resources/images/x60_unbrick/0042,,,,jpg}

You should now have this:@* @image{../resources/images/x60_unbrick/0043,,,,jpg}

Re-connect the upper chassis:@* @image{../resources/images/x60_unbrick/0044,,,,jpg}

Re-connect the keyboard:@* @image{../resources/images/x60_unbrick/0045,,,,jpg}

Re-insert the screws that you removed earlier:@* @image{../resources/images/x60_unbrick/0046,,,,jpg}

Power on!@* @image{../resources/images/x60_unbrick/0047,,,,jpg}

Trisquel live USB menu (using the GRUB ISOLINUX parser):@* @image{../resources/images/x60_unbrick/0048,,,,jpg}

Trisquel live desktop:@* @image{../resources/images/x60_unbrick/0049,,,,jpg}



@node ThinkPad X60 Tablet Recovery Guide
@subsubsection 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:

@menu
* Bucts not reset - X60 Tablet::
* Bad rom or user error - X60 Tablet::
@end menu

@node Bucts not reset - X60 Tablet
@c @subsubheading Brick type 1: bucts not reset.
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:@* @image{../resources/images/x60t_unbrick/0008,,,,JPG}@*@* *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: @uref{http://www.coreboot.org/Board:lenovo/x60/Installation,http://www.coreboot.org/Board:lenovo/x60/Installation}.

@node Bad rom or user error - X60 Tablet
@c @subsubheading Brick type 2: Bad rom (or user error), system won't boot
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).

@image{../resources/images/x60t_unbrick/0000,,,,JPG}

Remove those screws:@* @image{../resources/images/x60t_unbrick/0001,,,,JPG}

Remove the HDD:@* @image{../resources/images/x60t_unbrick/0002,,,,JPG}

Push keyboard forward to loosen it:@* @image{../resources/images/x60t_unbrick/0003,,,,JPG}

Lift:@* @image{../resources/images/x60t_unbrick/0004,,,,JPG}

Remove those:@* @image{../resources/images/x60t_unbrick/0005,,,,JPG}

@image{../resources/images/x60t_unbrick/0006,,,,JPG}

Also remove that (marked) and unroute the antenna cables:@* @image{../resources/images/x60t_unbrick/0007,,,,JPG}

For some X60T laptops, you have to unroute those too:@* @image{../resources/images/x60t_unbrick/0010,,,,JPG}

Remove the LCD extend board screws. Also remove those screws (see blue marks) and remove/unroute the cables and remove the metal plate:@* @image{../resources/images/x60t_unbrick/0008,,,,JPG}

Remove that screw and then remove the board:@* @image{../resources/images/x60t_unbrick/0009,,,,JPG}

Now wire up the BBB and the Pomona with your PSU.@* Refer to @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup} for how to setup the BBB for flashing.@* @strong{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)} @image{../resources/images/x60t_unbrick/0011,,,,JPG}@* Correlate the following with the BBB guide linked above: 

@verbatim
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.
@end verbatim

Connecting the BBB and pomona (in this image, an external 3.3v DC PSU was used):@* @image{../resources/images/x60/th_bbb_flashing,,,,jpg}

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

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

It should be @strong{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.



@node ThinkPad T60 Recovery Guide
@subsubsection ThinkPad T60 Recovery Guide
This section documents how to recover from a bad flash that prevents your ThinkPad T60 from booting.

Types of brick:

@menu
* Bucts not reset - T60::
* Bad rom or user error - T60::
@end menu

@node Bucts not reset - T60
@c @subsubheading Brick type 1: bucts not reset.
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:@* @image{../resources/images/t60_dev/0006,,,,JPG}@*@* *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: @uref{http://www.coreboot.org/Board:lenovo/x60/Installation,http://www.coreboot.org/Board:lenovo/x60/Installation}. (it says x60, but instructions for t60 are identical)

@node Bad rom or user error - T60
@c @subsubheading bad rom (or user error), system won't boot
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:@* @image{../resources/images/t60_dev/0001,,,,JPG} @image{../resources/images/t60_dev/0002,,,,JPG}

Lift off the palm rest:@* @image{../resources/images/t60_dev/0003,,,,JPG}

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:@* @image{../resources/images/t60_dev/0004,,,,JPG} @image{../resources/images/t60_dev/0005,,,,JPG} @image{../resources/images/t60_dev/0006,,,,JPG}

Gently wedge both sides loose:@* @image{../resources/images/t60_dev/0007,,,,JPG} @image{../resources/images/t60_dev/0008,,,,JPG}

Remove that cable from the position:@* @image{../resources/images/t60_dev/0009,,,,JPG} @image{../resources/images/t60_dev/0010,,,,JPG}

Now remove that bezel. Remove wifi, nvram battery and speaker connector (also remove 56k modem, on the left of wifi):@* @image{../resources/images/t60_dev/0011,,,,JPG}

Remove those screws:@* @image{../resources/images/t60_dev/0012,,,,JPG}

Disconnect the power jack:@* @image{../resources/images/t60_dev/0013,,,,JPG}

Remove nvram battery:@* @image{../resources/images/t60_dev/0014,,,,JPG}

Disconnect cable (for 56k modem) and disconnect the other cable:@* @image{../resources/images/t60_dev/0015,,,,JPG} @image{../resources/images/t60_dev/0016,,,,JPG}

Disconnect speaker cable:@* @image{../resources/images/t60_dev/0017,,,,JPG}

Disconnect the other end of the 56k modem cable:@* @image{../resources/images/t60_dev/0018,,,,JPG}

Make sure you removed it:@* @image{../resources/images/t60_dev/0019,,,,JPG}

Unscrew those:@* @image{../resources/images/t60_dev/0020,,,,JPG}

Make sure you removed those:@* @image{../resources/images/t60_dev/0021,,,,JPG}

Disconnect LCD cable from board:@* @image{../resources/images/t60_dev/0022,,,,JPG}

Remove those screws then remove the LCD assembly:@* @image{../resources/images/t60_dev/0023,,,,JPG} @image{../resources/images/t60_dev/0024,,,,JPG} @image{../resources/images/t60_dev/0025,,,,JPG}

Once again, make sure you removed those:@* @image{../resources/images/t60_dev/0026,,,,JPG}

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:@* @image{../resources/images/t60_dev/0027,,,,JPG} @image{../resources/images/t60_dev/0028,,,,JPG} @image{../resources/images/t60_dev/0029,,,,JPG} @image{../resources/images/t60_dev/0031,,,,JPG} @image{../resources/images/t60_dev/0032,,,,JPG} @image{../resources/images/t60_dev/0033,,,,JPG}

Now wire up the BBB and the Pomona with your PSU.@* Refer to @ref{How to program an SPI flash chip with BeagleBone Black,bbb_setup} for how to setup the BBB for flashing.@* @strong{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)}@* @image{../resources/images/t60_dev/0030,,,,JPG}@* Correlate the following with the BBB guide linked above: 

@verbatim
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.
@end verbatim

Connect the pomona from the BBB to the flash chip. No pics unfortunately. (use the text diagram above).

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

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

It should be @strong{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:@* @image{../resources/images/t60_dev/0047,,,,JPG}

Put it back into lower chassis:@* @image{../resources/images/t60_dev/0048,,,,JPG}

Attach LCD and insert screws (also, attach the lcd cable to the board):@* @image{../resources/images/t60_dev/0049,,,,JPG}

Insert those screws:@* @image{../resources/images/t60_dev/0050,,,,JPG}

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@* @image{../resources/images/t60_dev/0051,,,,JPG}

Attach the heatsink and install the screws (also, make sure to install the AC jack as highlighted):@* @image{../resources/images/t60_dev/0052,,,,JPG}

Reinstall that upper bezel:@* @image{../resources/images/t60_dev/0053,,,,JPG}

Do that:@* @image{../resources/images/t60_dev/0054,,,,JPG} @image{../resources/images/t60_dev/0055,,,,JPG}

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:@* @image{../resources/images/t60_dev/0056,,,,JPG} @image{../resources/images/t60_dev/0057,,,,JPG}

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:@* @image{../resources/images/t60_dev/0058,,,,JPG}

It lives!@* @image{../resources/images/t60_dev/0071,,,,JPG} @image{../resources/images/t60_dev/0072,,,,JPG} @image{../resources/images/t60_dev/0073,,,,JPG}

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:@* @image{../resources/images/t60_dev/0074,,,,JPG}


@node ThinkPad X200/X200S/X200T
@subsubsection 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.

@menu
* X200 laptops with libreboot pre-installed::
* Flash chip size - X200::
* MAC address - X200::
* Initial BBB configuration - X200::
* The procedure - X200::
* Wifi - X200::
* WWAN - X200::
* Memory - X200::
* Booting - X200::
* X200S and X200 Tablet users GPIO33 trick will not work::
@end menu


@node X200 laptops with libreboot pre-installed
@c @subsubheading X200 laptops with libreboot pre-installed
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 @uref{../../suppliers,suppliers} page for more information. 

@node Flash chip size - X200
@c @subsubheading Flash chip size - X200
Use this to find out:@* # @strong{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). @strong{Not all X200S/X200T are supported; see @ref{X200S and X200 Tablet,x200s}.} 


@node MAC address - X200
@c @subsubheading MAC address - X200
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:

@image{../resources/images/x200/disassembly/0002,,,,jpg} @image{../resources/images/x200/disassembly/0001,,,,jpg}

@node Initial BBB configuration - X200
@c @subsubheading Initial BBB configuration - X200
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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):

@verbatim
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:
            
@end verbatim

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

@verbatim
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?
@end verbatim

@strong{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:}@* @image{../resources/images/x200/wson_soldered,,,,jpg} @* 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 @ref{Flash chips,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. 

@node The procedure - X200
@c @subsubheading The procedure - X200
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:@* @image{../resources/images/x200/disassembly/0003,,,,jpg}

Push the keyboard forward, gently, then lift it off and disconnect it from the board:@* @image{../resources/images/x200/disassembly/0004,,,,jpg} @image{../resources/images/x200/disassembly/0005,,,,jpg}

Pull the palm rest off, lifting from the left and right side at the back of the palm rest:@* @image{../resources/images/x200/disassembly/0006,,,,jpg}

Lift back the tape that covers a part of the flash chip, and then connect the clip:@* @image{../resources/images/x200/disassembly/0007,,,,jpg} @image{../resources/images/x200/disassembly/0008,,,,jpg}

On pin 2 of the BBB, where you have the ground (GND), connect the ground to your PSU:@* @image{../resources/images/x200/disassembly/0009,,,,jpg} @image{../resources/images/x200/disassembly/0010,,,,jpg}

Connect the 3.3V supply from your PSU to the flash chip (via the clip):@* @image{../resources/images/x200/disassembly/0011,,,,jpg} @image{../resources/images/x200/disassembly/0012,,,,jpg}

Of course, make sure that your PSU is also plugged in and turn on:@* @image{../resources/images/x200/disassembly/0013,,,,jpg}

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):@* @image{../resources/images/x200/disassembly/0014,,,,jpg}

Now, you should be ready to install libreboot.

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

Log in as root on your BBB, using the instructions in @ref{Accessing the operating system on the BBB,bbb_access}. 

Test that flashrom works:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512}@* In this case, the output was:

@verbatim
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.
@end verbatim

How to backup factory.rom (change the -c option as neeed, for your flash chip):@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom}@* Note: the @strong{-c} option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in @emph{flashchips.c} have been removed.@* Now compare the 3 images:@* # @strong{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 @ref{ICH9 gen utility,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. @strong{Make sure to always change the MAC address to one that is correct for your system.} 

Now flash it:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V}

@image{../resources/images/x200/disassembly/0015,,,,jpg}

You might see errors, but if it says @strong{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 @strong{Chip content is identical to the requested image} is also an indication of a successful installation.

Example output from running the command (see above):

@verbatim
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.
@end verbatim

@node Wifi - X200
@c @subsubheading Wifi - X200
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 @ref{Recommended wifi chipsets,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:@* @image{../resources/images/x200/disassembly/0016,,,,jpg} @image{../resources/images/x200/disassembly/0017,,,,jpg}

@node WWAN - X200
@c @subsubheading WWAN - X200
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).

@node Memory - X200
@c @subsubheading Memory - X200
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.

@uref{http://www.forum.thinkpads.com/viewtopic.php?p=760721, This page} 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:@* @image{../resources/images/x200/disassembly/0018,,,,jpg}

@node Booting - X200
@c @subsubheading Boot it!
You should see something like this:

@image{../resources/images/x200/disassembly/0019,,,,jpg}

Now @ref{GNU/Linux distributions,install GNU/Linux}. 

@node X200S and X200 Tablet users GPIO33 trick will not work
@c @subsubheading X200S and X200 Tablet users: GPIO33 trick will not work.
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):@* @image{../resources/images/x200/gpio33_location,,,,jpg}

By default we would see this in lenovobios, when trying flashrom -p internal -w rom.rom:

@verbatim
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00001000-0x005f5fff) is locked.
@end verbatim

With GPIO33 grounded during boot, this disabled the flash protections as set by descriptor, and stopped the ME from starting. The output changed to:

@verbatim
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.
@end verbatim

The part in bold is what got us. This was still observed:

@verbatim
PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.
@end verbatim

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: @uref{http://www.coreboot.org/Board:lenovo/x200/internal_flashing_research,http://www.coreboot.org/Board:lenovo/x200/internal_flashing_research}

On a related note, libreboot has a utility that could help with investigating this: @ref{demefactory utility,demefactory} 



@node ThinkPad R400
@subsubsection 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)

@menu
* Libreboot T400::
* Serial port - R400::
* LCD compatibly - R400::
* A note about CPUs - R400::
* A note about GPUs - R400::
* CPU paste required - R400::
* Flash chip size - R400::
* MAC address - R400::
* Initial BBB configuration - R400::
* Disassembly - R400::
* Thermal paste - IMPORTANT - R400::
* Wifi - R400::
* WWAN - R400::
* Memory - R400::
* Booting - R400::
@end menu

@node Libreboot T400
@c @subsubheading Libreboot T400
You may also be interested in the smaller, more portable @ref{ThinkPad T400,Libreboot T400}. 

@node Serial port - R400
@c @subsubheading Serial port
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.

@node LCD compatibly - R400
@c @subsubheading LCD compatibly
Not all LCD panels are compatible yet. See @ref{LCD compatibility on GM45 laptops,gm45_lcd}. 

@node A note about CPUs - R400
@c @subsubheading A note about CPUs
@uref{http://www.thinkwiki.org/wiki/Category:R400,ThinkWiki} 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. @strong{The Core 2 Duo T5870/5670 and Celeron M 575/585 are untested!}
@itemize
@item
Quad-core CPUs
@itemize @minus
@item
Incompatible. Do not use.
@end itemize
@end itemize

@node A note about GPUs - R400
@c @subsubheading A note about GPUs
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 @emph{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.

@node CPU paste required - R400
@c @subsubheading CPU paste required
See @xref{paste-r400,,paste}.

@node Flash chip size - R400
@c @subsubheading Flash chip size
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}@*

@node MAC address - R400
@c @subsubheading MAC address
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:

@image{../resources/images/t400/macaddress0,,,,jpg} @image{../resources/images/t400/macaddress1,,,,jpg} @image{../resources/images/x200/disassembly/0001,,,,jpg}

@node Initial BBB configuration - R400
@c @subsubheading Initial BBB configuration 
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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):

@verbatim
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.
@end verbatim

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

@verbatim
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.
@end verbatim

@node Disassembly - R400
@c @subsubheading Disassembly
Remove all screws:@* @image{../resources/images/r400/0000,,,,jpg}@* Remove the HDD and optical drive:@* @image{../resources/images/r400/0001,,,,jpg}@* Remove the hinge screws:@* @image{../resources/images/r400/0002,,,,jpg} @image{../resources/images/r400/0003,,,,jpg}

Remove the palm rest and keyboard:@* @image{../resources/images/r400/0004,,,,jpg} @image{../resources/images/r400/0005,,,,jpg}

Remove these screws, and then remove the bezel:@* @image{../resources/images/r400/0006,,,,jpg} @image{../resources/images/r400/0007,,,,jpg}

Remove the speaker screws, but don't remove the speakers yet (just set them loose):@* @image{../resources/images/r400/0008,,,,jpg} @image{../resources/images/r400/0009,,,,jpg} @image{../resources/images/r400/0010,,,,jpg}

Remove these screws, and then remove the metal plate:@* @image{../resources/images/r400/0011,,,,jpg} @image{../resources/images/r400/0012,,,,jpg} @image{../resources/images/r400/0013,,,,jpg}

Remove the antennas from the wifi card, and then start unrouting them:@* @image{../resources/images/r400/0014,,,,jpg} @image{../resources/images/r400/0015,,,,jpg} @image{../resources/images/r400/0016,,,,jpg} @image{../resources/images/r400/0017,,,,jpg} @image{../resources/images/r400/0018,,,,jpg} @image{../resources/images/r400/0019,,,,jpg}

Disconnect the LCD cable from the motherboard:@* @image{../resources/images/r400/0020,,,,jpg} @image{../resources/images/r400/0021,,,,jpg} @image{../resources/images/r400/0022,,,,jpg} @image{../resources/images/r400/0023,,,,jpg}

Remove the hinge screws, and then remove the LCD panel:@* @image{../resources/images/r400/0024,,,,jpg} @image{../resources/images/r400/0025,,,,jpg} @image{../resources/images/r400/0026,,,,jpg} @image{../resources/images/r400/0027,,,,jpg}

Remove this:@* @image{../resources/images/r400/0028,,,,jpg} @image{../resources/images/r400/0029,,,,jpg}

Remove this long cable (there are 3 connections):@* @image{../resources/images/r400/0030,,,,jpg} @image{../resources/images/r400/0031,,,,jpg} @image{../resources/images/r400/0032,,,,jpg} @image{../resources/images/r400/0033,,,,jpg}

Disconnect the speaker cable, and remove the speakers:@* @image{../resources/images/r400/0034,,,,jpg}

Remove the heatsink screws, remove the fan and then remove the heatsink/fan:@* @image{../resources/images/r400/0035,,,,jpg} @image{../resources/images/r400/0036,,,,jpg} @image{../resources/images/r400/0037,,,,jpg} @image{../resources/images/r400/0038,,,,jpg}

Remove the NVRAM battery:@* @image{../resources/images/r400/0039,,,,jpg} @image{../resources/images/r400/0040,,,,jpg}

Remove this screw:@* @image{../resources/images/r400/0041,,,,jpg} @image{../resources/images/r400/0042,,,,jpg}

Disconnect the AC jack:@* @image{../resources/images/r400/0043,,,,jpg} @image{../resources/images/r400/0044,,,,jpg}

Remove this screw and then remove what is under it:@* @image{../resources/images/r400/0045,,,,jpg}

Remove this:@* @image{../resources/images/r400/0046,,,,jpg}

Lift the motherboard (which is still inside the cage) from the side on the right, removing it completely:@* @image{../resources/images/r400/0047,,,,jpg} @image{../resources/images/r400/0048,,,,jpg}

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: @image{../resources/images/r400/0049,,,,jpg} @image{../resources/images/r400/0050,,,,jpg}

Remove the motherboard from the cage, and the SPI flash chip will be next to the memory slots:@* @image{../resources/images/r400/0051,,,,jpg} @image{../resources/images/r400/0052,,,,jpg}

Connect your programmer, then connect GND and 3.3V@* @image{../resources/images/t400/0065,,,,jpg} @image{../resources/images/t400/0066,,,,jpg} @image{../resources/images/t400/0067,,,,jpg} @image{../resources/images/t400/0069,,,,jpg} @image{../resources/images/t400/0070,,,,jpg} @image{../resources/images/t400/0071,,,,jpg}

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:@* @image{../resources/images/t400/0072,,,,jpg}

Of course, make sure to turn on your PSU:@* @image{../resources/images/x200/disassembly/0013,,,,jpg}

Now, you should be ready to install libreboot.

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

Log in as root on your BBB, using the instructions in @ref{Accessing the operating system on the BBB,bbb_access}.

Test that flashrom works:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512}@* In this case, the output was:

@verbatim
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.
@end verbatim

How to backup factory.rom (change the -c option as neeed, for your flash chip):@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom}@* Note: the @strong{-c} option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in @emph{flashchips.c} have been removed.@* Now compare the 3 images:@* # @strong{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 @ref{ICH9 gen utility,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. @strong{Make sure to always change the MAC address to one that is correct for your system.}

Now flash it:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V}

@image{../resources/images/x200/disassembly/0015,,,,jpg}

You might see errors, but if it says @strong{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 @strong{Chip content is identical to the requested image} is also an indication of a successful installation.

Example output from running the command (see above):

@verbatim
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.
@end verbatim

@node Thermal paste - IMPORTANT - R400
@c @subsubheading Thermal paste (IMPORTANT)
@anchor{paste-r400}
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.

@image{../resources/images/t400/paste,,,,jpg}

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.

@node Wifi - R400
@c @subsubheading Wifi
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 @ref{Recommended wifi chipsets,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:@* @image{../resources/images/t400/0012,,,,jpg} @image{../resources/images/t400/ar5b95,,,,jpg}

@node WWAN - R400
@c @subsubheading WWAN
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).

@node Memory - R400
@c @subsubheading Memory
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.

@uref{http://www.forum.thinkpads.com/viewtopic.php?p=760721, This page} 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:@* @image{../resources/images/t400/memory,,,,jpg}

@node Booting - R400
@c @subsubheading Boot it!
You should see something like this:

@image{../resources/images/t400/boot0,,,,jpg} @image{../resources/images/t400/boot1,,,,jpg}

Now @ref{GNU/Linux distributions,install GNU/Linux}. 


@node ThinkPad T400
@subsubsection 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)

@menu
* T400 laptops with libreboot pre-installed::
* Serial port - T400::
* LCD compatibly - T400::
* A note about CPUs - T400::
* A note about GPUs - T400::
* CPU paste required - T400::
* Flash chip size - T400::
* MAC address - T400::
* Initial BBB configuration - T400::
* The procedure - T400::
* Thermal paste - IMPORTANT - T400::
* Wifi - T400::
* WWAN - T400::
* Memory - T400::
* Booting - T400::
@end menu

@node T400 laptops with libreboot pre-installed
@c @subsubheading T400 laptops with libreboot pre-installed
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.

@node Serial port - T400
@c @subsubheading Serial port
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.

@node LCD compatibly - T400
@c @subsubheading LCD compatibly
Not all LCD panels are compatible yet. See @ref{LCD compatibility on GM45 laptops,gm45_lcd}. 

@node A note about CPUs - T400
@c @subsubheading A note about CPUs
@uref{http://www.thinkwiki.org/wiki/Category:T400,ThinkWiki} 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.
@itemize
@item
Quad-core CPUs
@itemize @minus
@item
Incompatible. Do not use.
@end itemize
@end itemize

@node A note about GPUs - T400
@c @subsubheading A note about GPUs
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 @emph{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.

@node CPU paste required - T400
@c @subsubheading CPU paste required
See @xref{paste-t400,,paste}.

@node Flash chip size - T400
@c @subsubheading Flash chip size
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}@*

@node MAC address - T400
@c @subsubheading MAC address
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:

@image{../resources/images/t400/macaddress0,,,,jpg} @image{../resources/images/t400/macaddress1,,,,jpg} @image{../resources/images/x200/disassembly/0001,,,,jpg}


@node Initial BBB configuration - T400
@c @subsubheading Initial BBB configuration
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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):

@verbatim
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.
@end verbatim

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

@verbatim
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.
@end verbatim

@node The procedure - T400
@c @subsubheading The procedure
Remove @emph{all} screws, placing them in the order that you removed them:@* @image{../resources/images/t400/0001,,,,jpg} @image{../resources/images/t400/0002,,,,jpg}

Remove those three screws then remove the rear bezel:@* @image{../resources/images/t400/0003,,,,jpg} @image{../resources/images/t400/0004,,,,jpg} @image{../resources/images/t400/0005,,,,jpg} @image{../resources/images/t400/0006,,,,jpg}

Remove the speakers:@* @image{../resources/images/t400/0007,,,,jpg} @image{../resources/images/t400/0008,,,,jpg} @image{../resources/images/t400/0009,,,,jpg} @image{../resources/images/t400/0010,,,,jpg} @image{../resources/images/t400/0011,,,,jpg}

Remove the wifi:@* @image{../resources/images/t400/0012,,,,jpg} @image{../resources/images/t400/0013,,,,jpg}

Remove this cable:@* @image{../resources/images/t400/0014,,,,jpg} @image{../resources/images/t400/0015,,,,jpg} @image{../resources/images/t400/0016,,,,jpg} @image{../resources/images/t400/0017,,,,jpg} @image{../resources/images/t400/0018,,,,jpg}

Unroute those antenna wires:@* @image{../resources/images/t400/0019,,,,jpg} @image{../resources/images/t400/0020,,,,jpg} @image{../resources/images/t400/0021,,,,jpg} @image{../resources/images/t400/0022,,,,jpg} @image{../resources/images/t400/0023,,,,jpg}

Remove the LCD assembly:@* @image{../resources/images/t400/0024,,,,jpg} @image{../resources/images/t400/0025,,,,jpg} @image{../resources/images/t400/0026,,,,jpg} @image{../resources/images/t400/0027,,,,jpg} @image{../resources/images/t400/0028,,,,jpg} @image{../resources/images/t400/0029,,,,jpg} @image{../resources/images/t400/0030,,,,jpg} @image{../resources/images/t400/0031,,,,jpg}

Disconnect the NVRAM battery:@* @image{../resources/images/t400/0033,,,,jpg}

Disconnect the fan:@* @image{../resources/images/t400/0034,,,,jpg}

Unscrew these:@* @image{../resources/images/t400/0035,,,,jpg} @image{../resources/images/t400/0036,,,,jpg} @image{../resources/images/t400/0037,,,,jpg} @image{../resources/images/t400/0038,,,,jpg}

Unscrew the heatsink, then lift it off:@* @image{../resources/images/t400/0039,,,,jpg} @image{../resources/images/t400/0040,,,,jpg}

Disconnect the power jack:@* @image{../resources/images/t400/0041,,,,jpg} @image{../resources/images/t400/0042,,,,jpg}

Loosen this:@* @image{../resources/images/t400/0043,,,,jpg}

Remove this:@* @image{../resources/images/t400/0044,,,,jpg} @image{../resources/images/t400/0045,,,,jpg} @image{../resources/images/t400/0046,,,,jpg} @image{../resources/images/t400/0047,,,,jpg} @image{../resources/images/t400/0048,,,,jpg}

Unscrew these:@* @image{../resources/images/t400/0049,,,,jpg} @image{../resources/images/t400/0050,,,,jpg}

Remove this:@* @image{../resources/images/t400/0051,,,,jpg} @image{../resources/images/t400/0052,,,,jpg}

Unscrew this:@* @image{../resources/images/t400/0053,,,,jpg}

Remove the motherboard (the cage is still attached) from the right hand side, then lift it out:@* @image{../resources/images/t400/0054,,,,jpg} @image{../resources/images/t400/0055,,,,jpg} @image{../resources/images/t400/0056,,,,jpg}

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): @image{../resources/images/t400/0057,,,,jpg} @image{../resources/images/t400/0058,,,,jpg} @image{../resources/images/t400/0059,,,,jpg} @image{../resources/images/t400/0060,,,,jpg} @image{../resources/images/t400/0061,,,,jpg} @image{../resources/images/t400/0062,,,,jpg}

Separate the motherboard:@* @image{../resources/images/t400/0063,,,,jpg} @image{../resources/images/t400/0064,,,,jpg}

Connect your programmer, then connect GND and 3.3V@* @image{../resources/images/t400/0065,,,,jpg} @image{../resources/images/t400/0066,,,,jpg} @image{../resources/images/t400/0067,,,,jpg} @image{../resources/images/t400/0069,,,,jpg} @image{../resources/images/t400/0070,,,,jpg} @image{../resources/images/t400/0071,,,,jpg}

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:@* @image{../resources/images/t400/0072,,,,jpg}

Of course, make sure to turn on your PSU:@* @image{../resources/images/x200/disassembly/0013,,,,jpg}

Now, you should be ready to install libreboot.

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

Log in as root on your BBB, using the instructions in @ref{Accessing the operating system on the BBB,bbb_access}.

Test that flashrom works:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512}@* In this case, the output was:

@verbatim
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.
@end verbatim

How to backup factory.rom (change the -c option as neeed, for your flash chip):@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom}@* Note: the @strong{-c} option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in @emph{flashchips.c} have been removed.@* Now compare the 3 images:@* # @strong{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 @ref{ICH9 gen utility,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. @strong{Make sure to always change the MAC address to one that is correct for your system.}

Now flash it:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V}

@image{../resources/images/x200/disassembly/0015,,,,jpg}

You might see errors, but if it says @strong{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 @strong{Chip content is identical to the requested image} is also an indication of a successful installation.

Example output from running the command (see above):

@verbatim
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.
@end verbatim

@node Thermal paste - IMPORTANT - T400
@c @subsubheading Thermal paste (IMPORTANT)
@anchor{paste-t400}
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.

@image{../resources/images/t400/paste,,,,jpg}

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.

@node Wifi - T400
@c @subsubheading Wifi
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 @ref{Recommended wifi chipsets,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:@* @image{../resources/images/t400/0012,,,,jpg} @image{../resources/images/t400/ar5b95,,,,jpg}

@node WWAN - T400
@c @subsubheading WWAN
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).

@node Memory - T400
@c @subsubheading Memory
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.

@uref{http://www.forum.thinkpads.com/viewtopic.php?p=760721, This page} 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:@* @image{../resources/images/t400/memory,,,,jpg}

@node Booting - T400
@c @subsubheading Boot it!
You should see something like this:

@image{../resources/images/t400/boot0,,,,jpg} @image{../resources/images/t400/boot1,,,,jpg}

Now @ref{GNU/Linux distributions,install GNU/Linux}. 


@node ThinkPad T500
@subsubsection 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.

@menu
* Libreboot T400 - T500::
* Serial port - T500::
* LCD compatibly - T500::
* A note about CPUs - T500::
* A note about GPUs - T500::
* CPU paste required - T500::
* Flash chip size - T500::
* MAC address - T500::
* Initial BBB configuration - T500::
* The procedure - T500::
* Thermal paste - IMPORTANT - T500::
* Wifi - T500::
* WWAN - T500::
* Memory - T500::
* Booting - T500::
@end menu

@node Libreboot T400 - T500
@c @subsubheading Libreboot T400
You may also be interested in the smaller, more portable @ref{ThinkPad T400,Libreboot T400}. 

@node Serial port - T500
@c @subsubheading Serial port
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.

@node LCD compatibly - T500
@c @subsubheading LCD compatibly
Not all LCD panels are compatible yet. See @ref{LCD compatibility on GM45 laptops,gm45_lcd}. 

@node A note about CPUs - T500
@c @subsubheading A note about CPUs
@uref{http://www.thinkwiki.org/wiki/Category:T500,ThinkWiki} 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.

@itemize
@item
Quad-core CPUs
@itemize @minus
@item
Incompatible. Do not use.
@end itemize
@end itemize

@node A note about GPUs - T500
@c @subsubheading A note about GPUs
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 @emph{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.

@node CPU paste required - T500
@c @subsubheading CPU paste required
See @xref{paste-t500,,paste}.

@node Flash chip size - T500
@c @subsubheading Flash chip size
Use this to find out:@* # @strong{dmidecode | grep ROM\ Size}

@node MAC address - T500
@c @subsubheading MAC address
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:

@image{../resources/images/t400/macaddress0,,,,jpg} @image{../resources/images/t400/macaddress1,,,,jpg} @image{../resources/images/x200/disassembly/0001,,,,jpg}

@node Initial BBB configuration - T500
@c @subsubheading Initial BBB configuration
Refer to @ref{How to program an SPI flash chip with BeagleBone Black,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):

@verbatim
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.
@end verbatim

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

@verbatim
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.
@end verbatim


@node The procedure - T500
@c @subsubheading The procedure
Remove all screws:@* @image{../resources/images/t500/0000,,,,jpg}@* 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:@* @image{../resources/images/t500/0001,,,,jpg} @image{../resources/images/t500/0002,,,,jpg}

Remove the HDD/SSD and optical drive:@* @image{../resources/images/t500/0003,,,,jpg} @image{../resources/images/t500/0004,,,,jpg}

Remove the palm rest:@* @image{../resources/images/t500/0005,,,,jpg} @image{../resources/images/t500/0006,,,,jpg}

Remove the keyboard and rear bezel:@* @image{../resources/images/t500/0007,,,,jpg} @image{../resources/images/t500/0008,,,,jpg} @image{../resources/images/t500/0009,,,,jpg} @image{../resources/images/t500/0010,,,,jpg} @image{../resources/images/t500/0011,,,,jpg} @image{../resources/images/t500/0012,,,,jpg}

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:@* @image{../resources/images/t500/0013,,,,jpg} @image{../resources/images/t500/0017,,,,jpg} @image{../resources/images/t500/0018,,,,jpg}

Remove this frame, and then remove the wifi chip:@* @image{../resources/images/t500/0014,,,,jpg} @image{../resources/images/t500/0015,,,,jpg} @image{../resources/images/t500/0016,,,,jpg}

Remove the speakers:@* @image{../resources/images/t500/0019,,,,jpg} @image{../resources/images/t500/0020,,,,jpg} @image{../resources/images/t500/0021,,,,jpg} @image{../resources/images/t500/0022,,,,jpg} @image{../resources/images/t500/0023,,,,jpg} @image{../resources/images/t500/0024,,,,jpg} @image{../resources/images/t500/0025,,,,jpg}

Remove the NVRAM battery (already removed in this photo):@* @image{../resources/images/t500/0026,,,,jpg}

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:@* @image{../resources/images/t500/0027,,,,jpg}

Unroute the antenna wires:@* @image{../resources/images/t500/0028,,,,jpg} @image{../resources/images/t500/0029,,,,jpg} @image{../resources/images/t500/0030,,,,jpg} @image{../resources/images/t500/0031,,,,jpg}

Disconnect the LCD cable from the motherboard:@* @image{../resources/images/t500/0032,,,,jpg} @image{../resources/images/t500/0033,,,,jpg}

Remove the LCD assembly hinge screws, and then remove the LCD assembly:@* @image{../resources/images/t500/0034,,,,jpg} @image{../resources/images/t500/0035,,,,jpg} @image{../resources/images/t500/0036,,,,jpg}

Remove the fan and heatsink:@* @image{../resources/images/t500/0037,,,,jpg} @image{../resources/images/t500/0038,,,,jpg} @image{../resources/images/t500/0039,,,,jpg}

Remove this screw:@* @image{../resources/images/t500/0040,,,,jpg}

Remove these cables, keeping note of how and in what arrangement they are connected:@* @image{../resources/images/t500/0041,,,,jpg} @image{../resources/images/t500/0042,,,,jpg} @image{../resources/images/t500/0043,,,,jpg} @image{../resources/images/t500/0044,,,,jpg} @image{../resources/images/t500/0045,,,,jpg} @image{../resources/images/t500/0046,,,,jpg} @image{../resources/images/t500/0047,,,,jpg} @image{../resources/images/t500/0048,,,,jpg} @image{../resources/images/t500/0049,,,,jpg}

Disconnect the power jack:@* @image{../resources/images/t500/0050,,,,jpg} @image{../resources/images/t500/0051,,,,jpg}

Remove the motherboard and cage from the base (the marked hole is where those cables were routed through):@* @image{../resources/images/t500/0052,,,,jpg} @image{../resources/images/t500/0053,,,,jpg}

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):@* @image{../resources/images/t500/0054,,,,jpg} @image{../resources/images/t500/0055,,,,jpg}

Also remove this:@* @image{../resources/images/t500/0056,,,,jpg} @image{../resources/images/t500/0057,,,,jpg}

Separate the motherboard from the cage:@* @image{../resources/images/t500/0058,,,,jpg} @image{../resources/images/t500/0059,,,,jpg}

The flash chip is next to the memory slots. On this system, it was a SOIC-8 (4MiB or 32Mb) flash chip:@* @image{../resources/images/t500/0060,,,,jpg}

Connect your programmer, then connect GND and 3.3V@* @image{../resources/images/t500/0061,,,,jpg}@* @image{../resources/images/t400/0067,,,,jpg} @image{../resources/images/t400/0069,,,,jpg} @image{../resources/images/t400/0070,,,,jpg} @image{../resources/images/t400/0071,,,,jpg}

A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is also fine:@* @image{../resources/images/t400/0072,,,,jpg}

Of course, make sure to turn on your PSU:@* @image{../resources/images/x200/disassembly/0013,,,,jpg}

Now, you should be ready to install libreboot.

Flashrom binaries for ARM (tested on a BBB) are distributed in libreboot_util. Alternatively, libreboot also distributes flashrom source code which can be built.

Log in as root on your BBB, using the instructions in @ref{Accessing the operating system on the BBB,bbb_access}.

Test that flashrom works:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512}@* In this case, the output was:

@verbatim
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.
@end verbatim

How to backup factory.rom (change the -c option as neeed, for your flash chip):@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom}@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom}@* Note: the @strong{-c} option is not required in libreboot's patched flashrom, because the redundant flash chip definitions in @emph{flashchips.c} have been removed.@* Now compare the 3 images:@* # @strong{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 @ref{ICH9 gen utility,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. @strong{Make sure to always change the MAC address to one that is correct for your system.}

Now flash it:@* # @strong{./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V}

@image{../resources/images/x200/disassembly/0015,,,,jpg}

You might see errors, but if it says @strong{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 @strong{Chip content is identical to the requested image} is also an indication of a successful installation.

Example output from running the command (see above):

@verbatim
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.
@end verbatim


@node Thermal paste - IMPORTANT - T500
@c @subsubheading Thermal paste (IMPORTANT)
@anchor{paste-t500}
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.

@image{../resources/images/t400/paste,,,,jpg}

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.

@node Wifi - T500
@c @subsubheading Wifi
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 @ref{Recommended wifi chipsets,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:@* @image{../resources/images/t400/0012,,,,jpg} @image{../resources/images/t400/ar5b95,,,,jpg}

@node WWAN - T500
@c @subsubheading WWAN
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).

@node Memory - T500
@c @subsubheading Memory
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.

@uref{http://www.forum.thinkpads.com/viewtopic.php?p=760721, This page} 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:@* @image{../resources/images/t400/memory,,,,jpg}

@node Booting - T500
@c @subsubheading Boot it!
You should see something like this:

@image{../resources/images/t500/0062,,,,jpg}

Now @ref{GNU/Linux distributions,install GNU/Linux}.






@node GNU/Linux distributions
@section GNU/Linux distributions
This section relates to dealing with GNU/Linux distributions: preparing bootable USB drives, changing the default GRUB menu and so on.

@strong{This section is only for the *GRUB* payload. For depthcharge, instructions have yet to be written.}

@menu
* How to install GNU/Linux on a libreboot system::
* How to replace the default GRUB configuration file on a libreboot system::
* Writing a GRUB configuration file::
* Installing Parabola GNU/Linux-libre with full disk encryption::       (Including /boot)
* Configuring Parabola post-install::
* Installing Trisquel GNU/Linux-libre with full disk encryption::       (Including /boot)
@end menu


@node How to install GNU/Linux on a libreboot system
@subsection 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 @emph{dd}).

@strong{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.}

@menu
* Prepare the USB drive in GNU/Linux::
* Installing GNU/Linux with full disk encryption::
* GNU Guix System Distribution?::
* Trisquel net install?::
* Booting ISOLINUX images - automatic method::
* Booting ISOLINUX images - manual method::
* Troubleshooting GNU/Linux installation::
@end menu

@node Prepare the USB drive in GNU/Linux
@subsubsection Prepare the USB drive (in GNU/Linux)
Connect the USB drive. Check dmesg:@* @strong{$ dmesg}@* Check lsblk to confirm which drive it is:@* @strong{$ lsblk}

Check that it wasn't automatically mounted. If it was, unmount it. For example:@* @strong{$ sudo umount /dev/sdX*}@* @strong{# umount /dev/sdX*}

dmesg told you what device it is. Overwrite the drive, writing your distro ISO to it with dd. For example:@* @strong{$ sudo dd if=gnulinux.iso of=/dev/sdX bs=8M; sync}@* @strong{# 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.

@node Installing GNU/Linux with full disk encryption
@subsubsection Installing GNU/Linux with full disk encryption
@itemize
@item
@ref{Installing Trisquel GNU/Linux-libre with full disk encryption,Installing Trisquel GNU/Linux with full disk encryption (including /boot)} 
@item
@ref{Installing Parabola GNU/Linux-libre with full disk encryption,Installing Parabola GNU/Linux with full disk encryption (including /boot)} 
@end itemize

@node GNU Guix System Distribution?
@subsubsection GNU Guix System Distribution?
The Guix installers use the GRUB bootloader, unlike most GNU/Linux installers which will likely use ISOLINUX. @c TYPO: uses > use

To boot the Guix live USB install, select @strong{@emph{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 @strong{@emph{Load Config from (usb0)}}; select that, and it should boot.

Once you have installed Guix onto the main storage device, check @ref{1st option - don't re-flash,option1_dont_reflash} for hints on how to boot it. 

GuixSD (Guix System Distribution) is highly recommended; it's part of GNU, and @uref{https://www.gnu.org/distros/free-distros.html,endorsed} by the Free Software Foundation.

@node Trisquel net install?
@subsubsection 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 @emph{syslinux_configfile -i} (the @emph{Parse ISOLINUX} menu entries in the default GRUB configuration that libreboot uses).

@node Booting ISOLINUX images - automatic method
@subsubsection Booting ISOLINUX images (automatic method)
Boot it in GRUB using the @emph{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.

@node Booting ISOLINUX images - manual method
@subsubsection Booting ISOLINUX images (manual method)
@emph{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 @emph{Search for GRUB configuration} options won't work, then press C in GRUB to access the command line.@* grub> @strong{ls}@* Get the device from above output, eg (usb0). Example:@* grub> @strong{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> @strong{cat (usb0)/isolinux/foo.cfg}@* And so on, until you find the correct menuentries for ISOLINUX. @strong{The file @emph{/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 @emph{/isolinux/txt.cfg} or @emph{/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:@* @strong{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> @strong{set root='usb0'}@* grub> @strong{linux /path/to/kernel PARAMETERS MAYBE_MORE_PARAMETERS}@* grub> @strong{initrd /path/to/initrd}@* grub> @strong{boot}@* Note: @emph{usb0} may be incorrect. Check the output of the @emph{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.


@node Troubleshooting GNU/Linux installation
@subsubsection 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.

@menu
* Parabola won't boot in text-mode::
* Debian-installer graphical corruption in text-mode::  (Trisquel net install)
@end menu

@node Parabola won't boot in text-mode
@ifinfo
@subsubheading Parabola won't boot in text-mode
@end ifinfo
Use one of the ROM images with vesafb in the filename (uses coreboot framebuffer instead of text-mode).

@node Debian-installer graphical corruption in text-mode
@ifinfo
@subsubheading Debian-installer (trisquel net install) graphical corruption in text-mode
@end ifinfo
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:@* @strong{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: @uref{https://www.debian.org/releases/stable/i386/ch05s04.html,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.




@node How to replace the default GRUB configuration file on a libreboot system
@subsection How to replace the default GRUB configuration file on a libreboot system
Libreboot on x86 uses the GRUB @uref{http://www.coreboot.org/Payloads#GRUB_2,payload} 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).

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): @uref{http://lennartb.home.xs4all.nl/coreboot/col5.html,http://lennartb.home.xs4all.nl/coreboot/col5.html}.

@strong{This guide is *only* for the GRUB payload. If you use the depthcharge payload, ignore this section entirely.}

@menu
* Introduction - GRUB config::
* 1st option - don't re-flash::
* 2nd option - re-flash::
@end menu

@node Introduction - GRUB config
@subsubsection Introduction
Download the latest release from @uref{http://libreboot.org/,http://libreboot.org/} @*@strong{If you downloaded from git, refer to @ref{Get the full source code from metadata,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 @ref{How to program an SPI flash chip with BeagleBone Black,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. 

@node 1st option - don't re-flash
@subsubsection 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 @strong{/boot/grub/libreboot_grub.cfg} on the running system. The next time you boot, GRUB (in libreboot) will automatically switch to this configuration file. @strong{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 @emph{libreboot} GRUB configuration and use that for the libreboot_grub.cfg file, then follow @ref{Acquire the necessary utilities,tools}, @ref{Acquiring the correct ROM image,rom} and @ref{Extract grubtestcfg from the ROM image,extract_testconfig} to get the @strong{@emph{grubtest.cfg}}. Rename @strong{@emph{grubtest.cfg}} to @strong{@emph{libreboot_grub.cfg}} and save it to @strong{@emph{/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); @strong{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 @ref{Writing a GRUB configuration file,grub_config} for more information.


@node 2nd option - re-flash
@subsubsection 2nd option: re-flash
You can modify what is stored inside the flash chip quite easily. Read on to find out how.

@menu
* Acquire the necessary utilities::
* Acquiring the correct ROM image::
* Extract grubtestcfg from the ROM image::
* Re-insert the modified grubtestcfg into the ROM image::
* Testing::
* Final steps::
@end menu

@node Acquire the necessary utilities
@ifinfo
@subsubheading Acquire the necessary utilities
@end ifinfo
Use @strong{@emph{cbfstool}} and @strong{@emph{flashrom}}. There are available in the @emph{libreboot_util} release archive, or they can be compiled (see @ref{How to build flashrom,build_flashrom}). Flashrom is also available from the repositories:@* # @strong{pacman -S flashrom} 


@node Acquiring the correct ROM image
@ifinfo
@subsubheading Acquiring the correct ROM image
@end ifinfo
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 @emph{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:@* $ @strong{sudo flashrom -p internal -r libreboot.rom}@* # @strong{flashrom -p internal -r libreboot.rom}@* If you are told to specify the chip, add the option @strong{-c @{your chip@}} to the command, for example:@* # @strong{flashrom -c MX25L6405 -p internal -r libreboot.rom}

@node Extract grubtestcfg from the ROM image
@ifinfo
@subsubheading Extract grubtest.cfg from the ROM image
@end ifinfo
You can check the contents of the ROM image, inside CBFS:@* @strong{$ cd .../libreboot_util/cbfstool} @strong{$ ./cbfstool libreboot.rom print}

The files @emph{grub.cfg} and @emph{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 @emph{grubtest.cfg}. This is to reduce the possibility of bricking your device, so DO NOT SKIP THIS!

Extract grubtest.cfg from the ROM image:@* @strong{$ ./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 @ref{Writing a GRUB configuration file,grub_config} for more information.

@node Re-insert the modified grubtestcfg into the ROM image
@ifinfo
@subsubheading Re-insert the modified grubtest.cfg into the ROM image
@end ifinfo
Once your grubtest.cfg is modified and saved, delete the unmodified config from the ROM image:@* @strong{$ ./cbfstool libreboot.rom remove -n grubtest.cfg}

Next, insert the modified version:@* @strong{$ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw}

@node Testing
@ifinfo
@subsubheading Testing
@end ifinfo
@strong{Now you have a modified ROM. Refer back to @ref{How to update/install,flashrom} for information on how to flash it.@* $ @strong{cd /libreboot_util} # @strong{./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:@* # @strong{./flash forceupdate libreboot.rom}@* You should see @strong{"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.

@strong{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.}


@node Final steps
@ifinfo
@subsubheading Final steps
@end ifinfo
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:@* $ @strong{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:@* @strong{$ ./cbfstool libreboot.rom remove -n grub.cfg}

Add the modified version that you just made:@* @strong{$ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw}

@strong{Now you have a modified ROM. Again, refer back to @ref{How to update/install,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.} 


@node Writing a GRUB configuration file
@subsection Writing a GRUB configuration file
This section is for those systems which use the GRUB payload. @strong{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. @c NOTE: These > The following

@menu
* Obvious option::  Don't even modify the built-in grub.cfg
* Trisquel with full disk encryption - custom partition layout::
* Parabola GNU/Linux-libre::
@end menu


@node Obvious option
@subsubsection Obvious option: don't even modify the built-in grub.cfg
Use the menuentry that says something like @emph{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:@* $ @strong{cd /boot/grub/}@* $ @strong{ln -s grub.cfg libreboot_grub.cfg}

After that, your system should then boot automatically.

@node Trisquel with full disk encryption - custom partition layout
@subsubsection 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. @uref{http://www.rel4tion.org/people/fr33domlover/libreboot-fix/,http://www.rel4tion.org/people/fr33domlover/libreboot-fix/}

@strong{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:

@itemize
@item
@strong{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}
@item
@strong{initrd /boot/initrd.img-3.15.1-gnu.nonpae}
@end itemize

@strong{ro}, @strong{quiet}, @strong{splash}, @strong{crashkernel=384M-2G:64M,2G-:128M} and @strong{$vt_handoff} can be safely ignored.

I use this to get my partition layout:@* $ @strong{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. @strong{Note: when using @uref{http://jxself.org/linux-libre,jxself kernel releases}, 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):@* @strong{set root='ahci0,msdos1'}@* @strong{linux /vmlinuz root=UUID=3a008e14-4871-497b-95e5-fb180f277951}@* @strong{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).@* $ @strong{sudo -s} (or @strong{su -})@* # @strong{cd /boot/}@* # @strong{rm -f vmlinuz initrd.img}@* # @strong{ln -s yourkernel ksym}@* # @strong{ln -s yourinitrd isym}@* # @strong{exit}

Then your grubtest.cfg menu entry (for payload) becomes like that, for example if / was on sda2 and /boot was on sda1:@* @strong{set root='ahci0,msdos1'}@* @strong{linux /ksym root=/dev/sda2}@* @strong{initrd /isym}

There are lots of possible variations so please try to adapt.

@node Parabola GNU/Linux-libre
@subsubsection 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.


@node Installing Parabola GNU/Linux-libre with full disk encryption
@subsection Installing Parabola GNU/Linux-libre with full disk encryption including /boot
Libreboot on x86 uses the GRUB @uref{http://www.coreboot.org/Payloads#GRUB_2,payload} 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).

@strong{This guide is *only* for the GRUB payload. If you use the depthcharge payload, ignore this section entirely.}

@menu
* Booting the install environment:: @c Added
* Setting up the storage device:: @c Added
* Change keyboard layout::
* Establish an internet connection::
* Getting started::
* dm-mod::
* Create LUKS partition::
* Create LVM::
* Create / and swap partitions and mount::
* Continue with Parabola installation::
* Configure the system::
* Extra security tweaks::
* Unmount reboot!::
* Booting from GRUB::
* Follow-up tutorial configuring Parabola::
* Modify grubcfg inside the ROM::
* Bonus Using a key file to unlock /boot/::
* Further security tips::
* Troubleshooting Parabola::
@end menu

@node Booting the install environment
@subsubsection Booting the install environment
Boot Parabola's install environment. @ref{How to install GNU/Linux on a libreboot system,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 @uref{https://wiki.parabola.nu/Get_Parabola#Main_live_ISO,this page}.

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).

@node Setting up the storage device
@subsubsection 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 @uref{https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29,this page} 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 @uref{https://wiki.archlinux.org/index.php/Solid_State_Drives,this article}. 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:@* # @strong{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:@* # @strong{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. @uref{https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-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:@* # @strong{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).

@node Change keyboard layout
@subsubsection Change keyboard layout
Parabola live shell assumes US Qwerty. If you have something different, list the available keymaps and use yours:@* # @strong{localectl list-keymaps}@* # @strong{loadkeys LAYOUT}@* For me, LAYOUT would have been dvorak-uk.

@node Establish an internet connection
@subsubsection Establish an internet connection
Refer to @uref{https://wiki.parabola.nu/Beginners%27_guide#Establish_an_internet_connection,this guide}. Wired is recommended, but wireless is also explained there.

@node Getting started
@subsubsection Getting started
The beginning is based on @uref{https://wiki.parabolagnulinux.org/Installation_Guide,https://wiki.parabolagnulinux.org/Installation_Guide}. Then I referred to @uref{https://wiki.archlinux.org/index.php/Partitioning,https://wiki.archlinux.org/index.php/Partitioning} at first.

@node dm-mod
@subsubsection dm-mod
device-mapper will be used - a lot. Make sure that the kernel module is loaded:@* # @strong{modprobe dm-mod}

@node Create LUKS partition
@subsubsection Create LUKS partition
I am using MBR partitioning, so I use cfdisk:@* # @strong{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 @uref{https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation#Partitioning,https://wiki.archlinux.org/index.php/Dm-crypt/Drive_preparation#Partitioning}:@* I am then directed to @uref{https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption,https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption}.

Parabola forces you to RTFM. Do that.

It tells me to run:@* # @strong{cryptsetup benchmark} (for making sure the list below is populated)@* Then:@* # @strong{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:@* # @strong{man cryptsetup}

Following that page, based on my requirements, I do the following based on @uref{https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode,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:@* # @strong{cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --use-random --verify-passphrase luksFormat /dev/sda1} Choose a @strong{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 @emph{diceware method} is recommended, for generating secure passphrases (instead of passwords).

@node Create LVM
@subsubsection Create LVM
Now I refer to @uref{https://wiki.archlinux.org/index.php/LVM,https://wiki.archlinux.org/index.php/LVM}.

Open the LUKS partition:@* # @strong{cryptsetup luksOpen /dev/sda1 lvm}@* (it will be available at /dev/mapper/lvm)

Create LVM partition:@* # @strong{pvcreate /dev/mapper/lvm}@* Show that you just created it:@* # @strong{pvdisplay}

Now I create the volume group, inside of which the logical volumes will be created:@* # @strong{vgcreate matrix /dev/mapper/lvm}@* (volume group name is 'matrix' - choose your own name, if you like) Show that you created it:@* # @strong{vgdisplay}

Now create the logical volumes:@* # @strong{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 @uref{http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space,http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space}.@* # @strong{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:@* # @strong{lvdisplay}

@node Create / and swap partitions and mount
@subsubsection Create / and swap partitions, and mount
For the swapvol LV I use:@* # @strong{mkswap /dev/mapper/matrix-swapvol}@* Activate swap:@* # @strong{swapon /dev/matrix/swapvol}

For the root LV I use:@* # @strong{mkfs.ext4 /dev/mapper/matrix-root}

Mount the root (/) partition:@* # @strong{mount /dev/matrix/root /mnt}

@node Continue with Parabola installation
@subsubsection 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 @uref{https://wiki.parabolagnulinux.org/Installation_Guide,https://wiki.parabolagnulinux.org/Installation_Guide}. I also cross referenced @uref{https://wiki.archlinux.org/index.php/Installation_guide,https://wiki.archlinux.org/index.php/Installation_guide}.

Create /home and /boot on root mountpoint:@* # @strong{mkdir -p /mnt/home}@* # @strong{mkdir -p /mnt/boot}

Once all the remaining partitions, if any, have been mounted, the devices are ready to install Parabola.

In @strong{/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:@* # @strong{pacman -Syy}@* # @strong{pacman -Syu}@* # @strong{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:@* @ @ @ # @strong{pacman -Sy parabola-keyring}@* @ @ @ It says that if you get GPG errors, then it's probably an expired key and, therefore, you should do:@* @ @ @ # @strong{pacman-key --populate parabola}@* @ @ @ # @strong{pacman-key --refresh-keys}@* @ @ @ # @strong{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:@* @ @ @ # @strong{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):@* @ @ @ # @strong{date MMDDhhmm[[CC]YY][.ss]}@* @ @ @ I also had to install:@* @ @ @ # @strong{pacman -S archlinux-keyring}@* @ @ @ # @strong{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:@* @ @ @ @emph{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:@* @ @ @ # @strong{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:@* # @strong{pacstrap /mnt base base-devel wpa_supplicant dialog iw wpa_actiond}

@node Configure the system
@subsubsection Configure the system
Generate an fstab - UUIDs are used because they have certain advantages (see @uref{https://wiki.parabola.nu/Fstab#Identifying_filesystems,https://wiki.parabola.nu/Fstab#Identifying_filesystems}. If you prefer labels instead, replace the -U option with -L):@* # @strong{genfstab -U -p /mnt >> /mnt/etc/fstab}@* Check the created file:@* # @strong{cat /mnt/etc/fstab}@* (If there are any errors, edit the file. Do @strong{NOT} run the genfstab command again!)

Chroot into new system:@* # @strong{arch-chroot /mnt /bin/bash}

It's a good idea to have this installed:@* # @strong{pacman -S linux-libre-lts}

It was also suggested that you should install this kernel (read up on what GRSEC is):@* # @strong{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:@* # @strong{pacman -S wget}

Locale:@* # @strong{nano /etc/locale.gen}@* Uncomment your needed localisations. For example en_GB.UTF-8 (UTF-8 is highly recommended over other options).@* # @strong{locale-gen}@* # @strong{echo LANG=en_GB.UTF-8 > /etc/locale.conf}@* # @strong{export LANG=en_GB.UTF-8}

Console font and keymap:@* # @strong{nano /etc/vconsole.conf}@* In my case:

@verbatim
KEYMAP=dvorak-uk
FONT=lat9w-16
@end verbatim

Time zone:@* # @strong{ln -s /usr/share/zoneinfo/Europe/London /etc/localtime}@* (Replace Zone and Subzone to your liking. See /usr/share/zoneinfo)

Hardware clock:@* # @strong{hwclock --systohc --utc}

Hostname: Write your hostname to /etc/hostname. For example, if your hostname is parabola:@* # @strong{echo parabola > /etc/hostname}@* Add the same hostname to /etc/hosts:@* # @strong{nano /etc/hosts}@*

@verbatim
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1   localhost.localdomain   localhost   parabola
::1     localhost.localdomain   localhost   parabola
@end verbatim

Configure the network: Refer to @uref{https://wiki.parabola.nu/Beginners%27_guide#Configure_the_network,https://wiki.parabola.nu/Beginners%27_guide#Configure_the_network}.

Mkinitcpio: Configure /etc/mkinitcpio.conf as needed (see @uref{https://wiki.parabola.nu/Mkinitcpio,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. (# @strong{mkinitcpio -H hookname} gives information about each hook.) Specifically, for this use case:@* # @strong{nano /etc/mkinitcpio.conf}@* Then modify the file like so:

@itemize
@item
MODULES="i915"
@item
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 @strong{"hid-generic", "hid" and "hid-apple" modules to have a working keyboard when asked to enter the LUKS password.}
@item
HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt lvm2 filesystems fsck shutdown"
@item
Explanation:
@item
keymap adds to initramfs the keymap that you specified in /etc/vconsole.conf
@item
consolefont adds to initramfs the font that you specified in /etc/vconsole.conf
@item
encrypt adds LUKS support to the initramfs - needed to unlock your disks at boot time
@item
lvm2 adds LVM support to the initramfs - needed to mount the LVM partitions at boot time
@item
shutdown is needed according to Parabola wiki for unmounting devices (such as LUKS/LVM) during shutdown)
@end itemize

Now using mkinitcpio, you can create the kernel and ramdisk for booting with (this is different from Arch, specifying linux-libre instead of linux):@* # @strong{mkinitcpio -p linux-libre}@* Also do it for linux-libre-lts:@* # @strong{mkinitcpio -p linux-libre-lts}@* Also do it for linux-libre-grsec:@* # @strong{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 @uref{https://wiki.archlinux.org/index.php/SHA_password_hashes,https://wiki.archlinux.org/index.php/SHA_password_hashes}.@* # @strong{nano /etc/pam.d/passwd}@* Add rounds=65536 at the end of the uncommented 'password' line.@* # @strong{passwd root}@* Make sure to set a secure password! Also, it must never be the same as your LUKS password.

Use of the @emph{diceware method} is recommended, for generating secure passphrases (instead of passwords).

@node Extra security tweaks
@subsubsection Extra security tweaks
Based on @uref{https://wiki.archlinux.org/index.php/Security,https://wiki.archlinux.org/index.php/Security}.

Restrict access to important directories:@* # @strong{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:@* @emph{# auth required pam_tally.so onerr=succeed file=/var/log/faillog}@* Or just delete it. Above it, put:@* @emph{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:@* # @strong{pam_tally --user @emph{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.

@node Unmount reboot!
@subsubsection Unmount, reboot!
Exit from chroot:@* # @strong{exit}

unmount:@* # @strong{umount -R /mnt}@* # @strong{swapoff -a}

deactivate the lvm lv's:@* # @strong{lvchange -an /dev/matrix/root}@* # @strong{lvchange -an /dev/matrix/swapvol}@*

Lock the encrypted partition (close it):@* # @strong{cryptsetup luksClose lvm}

# @strong{shutdown -h now}@* Remove the installation media, then boot up again.

@node Booting from GRUB
@subsubsection 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> @strong{cryptomount -a}@* grub> @strong{set root='lvm/matrix-root'}@* grub> @strong{linux /boot/vmlinuz-linux-libre-lts root=/dev/matrix/root cryptdevice=/dev/sda1:root}@* grub> @strong{initrd /boot/initramfs-linux-libre-lts.img}@* grub> @strong{boot}@*

You could also make it load /boot/vmlinuz-linux-libre-grsec and /boot/initramfs-linux-libre-grsec.img

@node Follow-up tutorial configuring Parabola
@subsubsection 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! @ref{Configuring Parabola post-install,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 @uref{https://wiki.archlinux.org/index.php/The_Arch_Way,The Arch Way} (Parabola also follows it). 

@node Modify grubcfg inside the ROM
@subsubsection 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. @ref{How to replace the default GRUB configuration file on a libreboot system,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!

I will go for the re-flash option here. Firstly, cd to the libreboot_util/cbfstool/@{armv7l i686 x86_64@} directory. Dump the current firmware - where @emph{libreboot.rom} is an example: make sure to adapt:@* # @strong{flashrom -p internal -r libreboot.rom}@* If flashrom complains about multiple flash chips detected, add a @emph{-c} option at the end, with the name of your chosen chip is quotes.@* You can check if everything is in there (@emph{grub.cfg} and @emph{grubtest.cfg} would be really nice):@* $ @strong{./cbfstool libreboot.rom print}@* Extract grubtest.cfg:@* $ @strong{./cbfstool libreboot.rom extract -n grubtest.cfg -f grubtest.cfg}@* And modify:@* $ @strong{nano grubtest.cfg}

In grubtest.cfg, inside the 'Load Operating System' menu entry, change the contents to:

@verbatim
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
@end verbatim

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 @emph{-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:@* # @strong{systemctl start dhcpcd.service} Or make sure to get connected to the internet in any other way you prefer, at least.

Use of the @emph{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 @emph{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:@* # @strong{pacman -S grub flashrom dmidecode base-devel}@* Next, do:@* # @strong{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 @strong{password}, by the way) after @emph{'password_pbkdf2 root'} @emph{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 @strong{root} on both lines, feel free to choose another one) and the password hash which you copied):

@verbatim
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
@end verbatim

Save your changes in grubtest.cfg, then delete the unmodified config from the ROM image:@* $ @strong{./cbfstool libreboot.rom remove -n grubtest.cfg}@* and insert the modified grubtest.cfg:@* $ @strong{./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t raw}@*

Now refer to @uref{http://libreboot.org/install/index.html#flashrom,http://libreboot.org/install/index.html#flashrom}. Cd (up) to the libreboot_util directory and update the flash chip contents:@* # @strong{./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:@* # @strong{./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! @strong{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:@* $ @strong{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:@* $ @strong{./cbfstool libreboot.rom remove -n grub.cfg}@* Add the modified version that you just made:@* $ @strong{./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw}@*

Now you have a modified ROM. Once more, refer to @uref{http://libreboot.org/install/index.html#flashrom,http://libreboot.org/install/index.html#flashrom}. Cd to the libreboot_util directory and update the flash chip contents:@* # @strong{./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 @emph{grub-mkpasswd-pbkdf2} utility; GRUB is already part of libreboot, flashed alongside it as a @emph{payload}):@* # @strong{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.

@node Bonus Using a key file to unlock /boot/
@subsubsection 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:@* # @strong{dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile iflag=fullblock}@* Insert it into the luks volume:@* # @strong{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:@* # @strong{FILES="/etc/mykeyfile"}@* Create the initramfs image from scratch:@* # @strong{mkinitcpio -p linux-libre}@* # @strong{mkinitcpio -p linux-libre-lts}@* # @strong{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:@* # @strong{cryptkey=rootfs:/etc/mykeyfile}@* @* You can also place this inside the grub.cfg that exists in CBFS: @ref{How to replace the default GRUB configuration file on a libreboot system,grub_cbfs}. 

@node Further security tips
@subsubsection Further security tips
@uref{https://wiki.archlinux.org/index.php/Security,https://wiki.archlinux.org/index.php/Security}.@* @uref{https://wiki.parabolagnulinux.org/User:GNUtoo/laptop,https://wiki.parabolagnulinux.org/User:GNUtoo/laptop}

@node Troubleshooting Parabola
@subsubsection Troubleshooting Parabola
A user reported issues when booting with a docking station attached on an X200, when decrypting the disk in GRUB. The error @emph{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.

@verbatim

"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
@end verbatim



@node Configuring Parabola post-install
@subsection 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 @ref{Installing Parabola GNU/Linux-libre with full disk encryption,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. 

@strong{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; @emph{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 @emph{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 @emph{get in your way}.

@strong{This guide assumes that you already have Parabola installed. If you have not yet installed Parabola, then @ref{Installing Parabola GNU/Linux-libre with full disk encryption,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. @strong{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:@* # @strong{systemctl start dhcpcd.service}@* You can stop it later by running:@* # @strong{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:@* @ref{Setup a network connection in Parabola,Setup network connection in Parabola} 

@menu
* Configure pacman::
* Updating Parabola::
* Maintaining Parabola::
* your-freedom::
* Add a user::
* systemd::
* Interesting repositories::
* Setup a network connection in Parabola::
* System Maintenance::
* Configuring the desktop::
@end menu

@node Configure pacman
@subsubsection Configure pacman
pacman (@strong{pac}kage @strong{man}ager) 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 @uref{https://wiki.parabolagnulinux.org/Installation_Guide#Configure_pacman,https://wiki.parabolagnulinux.org/Installation_Guide#Configure_pacman} and from reading @uref{https://wiki.archlinux.org/index.php/Pacman,https://wiki.archlinux.org/index.php/Pacman} (make sure to read and understand this, it's very important) and @uref{https://wiki.parabolagnulinux.org/Official_Repositories,https://wiki.parabolagnulinux.org/Official_Repositories}

@node Updating Parabola
@subsubsection Updating Parabola
In the end, I didn't change my configuration for pacman. When you are updating, resync with the latest package names/versions:@* # @strong{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:@* # @strong{pacman -Syu}

@strong{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 @emph{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.

@node Maintaining Parabola
@subsubsection 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).

@c TODO: Itemize?
@menu
* Cleaning the package cache::
* pacman command equivalents::
@end menu

@node Cleaning the package cache
@ifinfo
@subsubheading Cleaning the package cache
@end ifinfo
@strong{The following is very important as you continue to use, update and maintain your Parabola system:@* @uref{https://wiki.archlinux.org/index.php/Pacman#Cleaning_the_package_cache,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:@* # @strong{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:@* # @strong{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.

@node pacman command equivalents
@ifinfo
@subsubheading pacman command equivalents
@end ifinfo
The following table lists other distro package manager commands, and their equivalent in pacman:@* @uref{https://wiki.archlinux.org/index.php/Pacman_Rosetta,https://wiki.archlinux.org/index.php/Pacman_Rosetta}


@node your-freedom
@subsubsection 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 @emph{your-freedom}.


@node Add a user
@subsubsection Add a user
Based on @uref{https://wiki.archlinux.org/index.php/Users_and_Groups,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:@* # @strong{useradd -m -G wheel -s /bin/bash @emph{yourusername}}@* Set a password:@* # @strong{passwd @emph{yourusername}}

Use of the @emph{diceware method} is recommended, for generating secure passphrases (instead of passwords).


@node systemd
@subsubsection 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 @uref{https://wiki.archlinux.org/index.php/systemd,https://wiki.archlinux.org/index.php/systemd} and @uref{https://wiki.archlinux.org/index.php/systemd#Basic_systemctl_usage,https://wiki.archlinux.org/index.php/systemd#Basic_systemctl_usage} to gain a full understanding. @strong{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.

@uref{https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530,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:@* # @strong{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:@* @emph{#SystemMaxUse=}@* Change it to say:@* @emph{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:@* # @strong{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.@* # @strong{man systemd-tmpfiles}@* The command for 'clean' is:@* # @strong{systemd-tmpfiles --clean}@* According to the manpage, this @emph{"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:@* # @strong{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.


@node Interesting repositories
@subsubsection Interesting repositories
Parabola wiki at @uref{https://wiki.parabolagnulinux.org/Repositories#kernels,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:@* @emph{[kernels]@* Include = /etc/pacman.d/mirrorlist}

Now sync with the repository:@* # @strong{pacman -Syy}

List all available packages in this repository:@* # @strong{pacman -Sl kernels}

In the end, I decided not to install anything from it but I kept the repository enabled regardless.


@node Setup a network connection in Parabola
@subsubsection Setup a network connection in Parabola
Read @uref{https://wiki.archlinux.org/index.php/Configuring_Network,https://wiki.archlinux.org/index.php/Configuring_Network}.

@menu
* Set the hostname::
* Network Status::
* Network device names::
* Network setup::
@end menu

@node Set the hostname
@ifinfo
@subsubheading Set the hostname
@end ifinfo
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):@* # @strong{hostnamectl set-hostname @emph{yourhostname}}@* This writes the specified hostname to /etc/hostname. More information can be found in these manpages:@* # @strong{man hostname}@* # @strong{info hostname}@* # @strong{man hostnamectl}

Add the same hostname to /etc/hosts, on each line. Example:@* @emph{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 @emph{hostname} utility is part of the @emph{inetutils} package and is in core/, installed by default (as part of @emph{base}).

@node Network Status
@ifinfo
@subsubheading Network Status
@end ifinfo
According to the Arch wiki, @uref{https://wiki.archlinux.org/index.php/Udev,udev} should already detect the ethernet chipset and load the driver for it automatically at boot time. You can check this in the @emph{"Ethernet controller"} section when running this command:@* # @strong{lspci -v}

Look at the remaining sections @emph{'Kernel driver in use'} and @emph{'Kernel modules'}. In my case it was as follows:@* @emph{Kernel driver in use: e1000e@* Kernel modules: e1000e}

Check that the driver was loaded by issuing @emph{dmesg | grep module_name}. In my case, I did:@* # @strong{dmesg | grep e1000e}

@node Network device names
@ifinfo
@subsubheading Network device names
@end ifinfo
According to @uref{https://wiki.archlinux.org/index.php/Configuring_Network#Device_names,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, @emph{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 @emph{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 @emph{net.ifnames=0} to your kernel parameters (in libreboot context, this would be accomplished by following the instructions in @ref{How to replace the default GRUB configuration file on a libreboot system,grub_cbfs}).

For background information, read @uref{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/,Predictable Network Interface Names}

Show device names:@* # @strong{ls /sys/class/net}

Changing the device names is possible (I chose not to do it):@* @uref{https://wiki.archlinux.org/index.php/Configuring_Network#Change_device_name,https://wiki.archlinux.org/index.php/Configuring_Network#Change_device_name}

@node Network setup
@ifinfo
@subsubheading Network setup
@end ifinfo
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:@* @uref{https://wiki.archlinux.org/index.php/List_of_applications/Internet#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.

@node System Maintenance
@subsubsection System Maintenance
Read @uref{https://wiki.archlinux.org/index.php/System_maintenance,https://wiki.archlinux.org/index.php/System_maintenance} before continuing. Also read @uref{https://wiki.archlinux.org/index.php/Enhance_system_stability,https://wiki.archlinux.org/index.php/Enhance_system_stability}. @strong{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):@* # @strong{pacman -S smartmontools}@* Read @uref{https://wiki.archlinux.org/index.php/S.M.A.R.T.,https://wiki.archlinux.org/index.php/S.M.A.R.T.} to learn how to use it.

@node Configuring the desktop
@subsubsection Configuring the desktop
Based on steps from @uref{https://wiki.archlinux.org/index.php/General_recommendations#Graphical_user_interface,General Recommendations} 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.

@menu
* Installing Xorg::
* Xorg keyboard layout::
* Install LXDE::
* LXDE - clock::
* LXDE - font::
* LXDE - screenlock::
* LXDE - automounting::
* LXDE - disable suspend::
* LXDE - battery monitor::
* LXDE - Network Manager::
@end menu

@node Installing Xorg
@ifinfo
@subsubheading Installing Xorg
@end ifinfo
Based on @uref{https://wiki.archlinux.org/index.php/Xorg,https://wiki.archlinux.org/index.php/Xorg}.

Firstly, install it!@* # @strong{pacman -S xorg-server}@* I also recommend installing this (contains lots of useful tools, including @emph{xrandr}):@* # @strong{pacman -S xorg-server-utils}

Install the driver. For me this was @emph{xf86-video-intel} on the ThinkPad X60. T60 and macbook11/21 should be the same.@* # @strong{pacman -S xf86-video-intel}@* For other systems you can try:@* # @strong{pacman -Ss xf86-video- | less}@* Combined with looking at your @emph{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 @emph{xorg-drivers} group:@* # @strong{pacman -Sg xorg-drivers}@*

Mostly you will rely on a display manager, but in case you ever want to start X without one:@* # @strong{pacman -S xorg-xinit}

<optional>@* @ @ @ Arch wiki recommends installing these, for testing that X works:@* @ @ @ # @strong{pacman -S xorg-twm xorg-xclock xterm}@* @ @ @ Refer to @uref{https://wiki.archlinux.org/index.php/Xinitrc,https://wiki.archlinux.org/index.php/Xinitrc}. and test X:@* @ @ @ # @strong{startx}@* @ @ @ When you are satisfied, type @strong{@emph{exit}} in xterm, inside the X session.@* @ @ @ Uninstall them (clutter. eww): # @strong{pacman -S xorg-xinit xorg-twm xorg-xclock xterm}@* </optional> @c TODO: Should be pacman -Rs? 

@node Xorg keyboard layout
@ifinfo
@subsubheading Xorg keyboard layout
@end ifinfo
Refer to @uref{https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg,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:@* # @strong{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: @emph{XkbModel} can be @emph{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 @emph{pc104}.

@emph{XkbLayout} in my case would be @emph{gb}, and @emph{XkbVariant} would be @emph{dvorak}.

The Arch wiki recommends two different methods for setting the keyboard layout:@* @uref{https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_X_configuration_files,https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_X_configuration_files} and@* @uref{https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_localectl,https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_localectl}.

In my case, I chose to use the @emph{configuration file} method:@* Create the file /etc/X11/xorg.conf.d/10-keyboard.conf and put this inside:@* @emph{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).

@node Install LXDE
@ifinfo
@subsubheading Install LXDE
@end ifinfo
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 @uref{https://wiki.archlinux.org/index.php/Desktop_environment,https://wiki.archlinux.org/index.php/Desktop_environment}

Refer to @uref{https://wiki.archlinux.org/index.php/LXDE,https://wiki.archlinux.org/index.php/LXDE}.

Install it, choosing 'all' when asked for the default package list:@* # @strong{pacman -S lxde obconf}

I didn't want the following, so I removed them:@* # @strong{pacman -R lxmusic lxtask}

I also lazily installed all fonts:@* # @strong{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 @emph{@uref{https://gnu.org/,GNU project}}:@* # @strong{pacman -S icecat}@* And a mail client:@* # @strong{pacman -S icedove}

In IceCat, go to @emph{Preferences :: Advanced} and disable @emph{GNU IceCat Health Report}.

I also like to install these:@* # @strong{pacman -S xsensors stress htop}

Enable LXDM (the default display manager, providing a graphical login):@* # @strong{systemctl enable lxdm.service}@* It will start when you boot up the system. To start it now, do:@* # @strong{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 @uref{https://wiki.archlinux.org/index.php/Xinitrc,https://wiki.archlinux.org/index.php/Xinitrc}.

Open LXterminal:@* $ @strong{cp /etc/skel/.xinitrc ~}@* Open .xinitrc and add the following plus a line break at the bottom of the file.@* @emph{# 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:@* $ @strong{chmod +x .xinitrc}

@node LXDE - clock
@ifinfo
@subsubheading LXDE - clock
@end ifinfo
In @strong{Digital Clock Settings} (right click the clock) I set the Clock Format to @emph{%Y/%m/%d %H:%M:%S}

@node LXDE - font
@ifinfo
@subsubheading LXDE - font
@end ifinfo
NOTE TO SELF: come back to this later.

@node LXDE - screenlock
@ifinfo
@subsubheading LXDE - screenlock
@end ifinfo
Arch wiki recommends to use @emph{xscreensaver}:@* # @strong{pacman -S xscreensaver}

Under @emph{Preferences :: Screensaver} in the LXDE menu, I chose @emph{Mode: Blank Screen Only}, setting @emph{Blank After}, @emph{Cycle After} and @emph{Lock Screen After} (checked) to 10 minutes.

You can now lock the screen with @emph{Logout :: Lock Screen} in the LXDE menu.


@node LXDE - automounting
@ifinfo
@subsubheading LXDE - automounting
@end ifinfo
Refer to @uref{https://wiki.archlinux.org/index.php/File_manager_functionality,https://wiki.archlinux.org/index.php/File_manager_functionality}.

I chose to ignore this for now. NOTE TO SELF: come back to this later.

@node LXDE - disable suspend
@ifinfo
@subsubheading LXDE - disable suspend
@end ifinfo
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.

@node LXDE - battery monitor
@ifinfo
@subsubheading LXDE - battery monitor
@end ifinfo
Right click lxde panel and @emph{Add/Remove Panel Items}. Click @emph{Add} and select @emph{Battery Monitor}, then click @emph{Add}. Close and then right-click the applet and go to @emph{Battery Monitor Settings}, check the box that says @emph{Show Extended Information}. Now click @emph{Close}. When you hover the cursor over it, it'll show information about the battery.

@node LXDE - Network Manager
@ifinfo
@subsubheading LXDE - Network Manager
@end ifinfo
Refer to @uref{https://wiki.archlinux.org/index.php/LXDE#Network_Management,https://wiki.archlinux.org/index.php/LXDE#Network_Management}. Then I read: @uref{https://wiki.archlinux.org/index.php/NetworkManager,https://wiki.archlinux.org/index.php/NetworkManager}.

Install Network Manager:@* # @strong{pacman -S networkmanager}

You will also want the graphical applet:@* # @strong{pacman -S network-manager-applet}@* Arch wiki says that an autostart rule will be written at @emph{/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:@* # @strong{pacman -S networkmanager-openvpn}

LXDE uses openbox, so I refer to:@* @uref{https://wiki.archlinux.org/index.php/NetworkManager#Openbox,https://wiki.archlinux.org/index.php/NetworkManager#Openbox}.

It tells me for the applet I need:@* # @strong{pacman -S xfce4-notifyd gnome-icon-theme}@* Also, for storing authentication details (wifi) I need:@* # @strong{pacman -S gnome-keyring}

I wanted to quickly enable networkmanager:@* # @strong{systemctl stop dhcpcd}@* # @strong{systemctl start NetworkManager}@* Enable NetworkManager at boot time:@* # @strong{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 @emph{lxappearance}.



@node Installing Trisquel GNU/Linux-libre with full disk encryption
@subsection Installing Trisquel GNU/Linux-libre with full disk encryption (including /boot)
Libreboot on x86 uses the GRUB @uref{http://www.coreboot.org/Payloads#GRUB_2,payload} 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). @uref{How to install GNU/Linux on a libreboot system,How to boot a GNU/Linux installer}. 

NOTE: When finishing implementing this setup, if the boot stalls when running cryptomount -a, try removing the DVD drive (on thinkpads).

@strong{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 @emph{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: @strong{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'.}

@strong{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.}

@menu
* Partitioning::
* Further partitioning::
* Kernel::
* Tasksel::
* Postfix configuration::
* Install the GRUB boot loader to the master boot record::
* Clock UTC::
* Booting your system::
* ecryptfs::
* Modify grubcfg CBFS::
* Troubleshooting Trisquel::
@end menu

@node Partitioning
@subsubsection Partitioning
Choose 'Manual' partitioning:

@itemize
@item
Select drive and create new partition table
@item
Single large partition. The following are mostly defaults:
@itemize
@item
Use as: physical volume for encryption
@item
Encryption: aes
@item
key size: 256
@item
IV algorithm: xts-plain64
@item
Encryption key: passphrase
@item
erase data: Yes (only choose 'No' if it's a new drive that doesn't contain your private data)
@end itemize

@item
Select 'configure encrypted volumes'
@itemize
@item
Create encrypted volumes
@item
Select your partition
@item
Finish
@item
Really erase: Yes
@item
(erase will take a long time. be patient)
@item
(if your old system was encrypted, just let this run for about a minute to make sure that the LUKS header is wiped out)
@end itemize

@item
Select encrypted space:
@itemize
@item
use as: physical volume for LVM
@item
Choose 'done setting up the partition'
@end itemize

@item
Configure the logical volume manager:
@itemize
@item
Keep settings: Yes
@end itemize

@item
Create volume group:
@itemize
@item
Name: @strong{matrix} (you can use whatever you want here, this is just an example)
@item
Select crypto partition
@end itemize

@item
Create logical volume
@itemize
@item
select @strong{matrix} (or whatever you named it before)
@item
name: @strong{root} (you can use whatever you want here, this is just an example)
@item
size: default, minus 2048 MB
@end itemize

@item
Create logical volume
@itemize
@item
select @strong{matrix} (or whatever you named it before)
@item
name: @strong{swap} (you can use whatever you want here, this is just an example)
@item
size: press enter
@end itemize

@end itemize

@node Further partitioning
@subsubsection Further partitioning
Now you are back at the main partitioning screen. You will simply set mountpoints and filesystems to use.

@itemize
@item
LVM LV root
@itemize
@item
use as: ext4
@item
mount point: /
@item
done setting up partition
@end itemize

@item
LVM LV swap
@itemize
@item
use as: swap area
@item
done setting up partition
@end itemize

@item
Now you select 'Finished partitioning and write changes to disk'.
@end itemize

@node Kernel
@subsubsection Kernel
Installation will ask what kernel you want to use. linux-generic is fine.

@node Tasksel
@subsubsection Tasksel
Choose @emph{"Trisquel Desktop Environment"} if you want GNOME, @emph{"Trisquel-mini Desktop Environment"} if you want LXDE or @emph{"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.

@node Postfix configuration
@subsubsection Postfix configuration
If asked, choose @emph{"No Configuration"} here (or maybe you want to select something else. It's up to you.)

@node Install the GRUB boot loader to the master boot record
@subsubsection 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.

@emph{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.}

@node Clock UTC
@subsubsection Clock UTC
Just say 'Yes'.

@node Booting your system
@subsubsection 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> @strong{cryptomount -a}@* grub> @strong{set root='lvm/matrix-root'}@* grub> @strong{linux /vmlinuz root=/dev/mapper/matrix-root cryptdevice=/dev/mapper/matrix-root:root}@* grub> @strong{initrd /initrd.img}@* grub> @strong{boot}

@node ecryptfs
@subsubsection ecryptfs
If you didn't encrypt your home directory, then you can safely ignore this section.

Immediately after logging in, do that:@* $ @strong{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)>

@node Modify grubcfg CBFS
@subsubsection 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) @ref{How to replace the default GRUB configuration file on a libreboot system,using this tutorial}; just change the default menu entry 'Load Operating System' to say this inside: 

@strong{cryptomount -a}@* @strong{set root='lvm/matrix-root'}@* @strong{linux /vmlinuz root=/dev/mapper/matrix-root cryptdevice=/dev/mapper/matrix-root:root}@* @strong{initrd /initrd.img}

Without specifying a device, the @emph{-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. @strong{This should be different than your LUKS passphrase and user password.}

Use of the @emph{diceware method} is recommended, for generating secure passphrases (as opposed to passwords).

The GRUB utility can be used like so:@* $ @strong{grub-mkpasswd-pbkdf2}

Give it a password (remember, it has to be secure) and it'll output something like:@* @strong{grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711}

Use of the @emph{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):@*

@verbatim
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
            
@end verbatim

MAKE SURE TO DO THIS ON grubtest.cfg *BEFORE* DOING IT ON grub.cfg. Then select the menu entry that says @emph{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 @ref{How to update/install,this tutorial}. 

@node Troubleshooting Trisquel
@subsubsection Troubleshooting Trisquel
A user reported issues when booting with a docking station attached on an X200, when decrypting the disk in GRUB. The error @emph{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.

@verbatim

"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
@end verbatim




@node Git
@section Git

@c TODO: Add some text here that connects these two things

@menu
* Building libreboot from source::
* Maintaining libreboot::
@end menu

@node Building libreboot from source
@subsection Building libreboot from source
This section relates to building libreboot from source, and working with the git repository.

@menu
* Install build dependencies::
* Get the full source code from metadata::
* How to build bucts for LenovoBIOS X60/X60S/X60T/T60::
* How to build flashrom::
* Configuring libreboot::
* How to build the ROM images::
@end menu

@node Install build dependencies
@subsubsection Install build dependencies
Before doing anything, you need the dependencies first. This is true if you want to build libreboot from source, with either libreboot_src.tar.xz or git. @strong{If you are using libreboot_util.tar.xz (binary archive) then you can ignore this, because ROM images and statically compiled executables for the utilities are included.}

For Trisquel 7, you can run the following command:@* $ @strong{sudo ./build dependencies trisquel7}

For Parabola, you can run the following command:@* $ @strong{sudo ./build dependencies parabola}@* or:@* # @strong{./build dependencies parabola}

For other GNU/Linux distributions, you can adapt the existing scripts.

@node Get the full source code from metadata
@subsubsection 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, @ref{Install build dependencies,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:@* $ @strong{git config --global user.name ``Your Name''}@* $ @strong{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 @uref{http://git-scm.com/doc,http://git-scm.com/doc}.

Another nice config for you (optional, but recommended):@* $ @strong{git config --global core.editor nano}@* $ @strong{git config --global color.status auto}@* $ @strong{git config --global color.branch auto}@* $ @strong{git config --global color.interactive auto}@* $ @strong{git config --global color.diff auto}

After that, run the script:@* $ @strong{./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 @ref{How to build the ROM images,build}. 

@node How to build bucts for LenovoBIOS X60/X60S/X60T/T60
@subsubsection How to build ``bucts'' (for LenovoBIOS X60/X60S/X60T/T60)
@strong{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 ``@strong{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 @ref{How to build flashrom,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 ``@strong{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.TS utility is included in libreboot_src.tar.xz and libreboot_util.tar.xz.@* @strong{If you downloaded from git, follow @ref{Get the full source code from metadata,build_meta} before you proceed.}

``BUC'' means ``@strong{B}ack@strong{u}p @strong{C}ontrol'' (it's a register) and ``TS'' means ``@strong{T}op @strong{S}wap'' (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, @ref{Install build dependencies,install the build dependencies}. 

To build bucts, do this in the main directory:@* $ @strong{./build module bucts}

To statically compile it, do this:@* $ @strong{./build module bucts static}

The ``builddeps'' script in libreboot_src also makes use of builddeps-bucts.

@node How to build flashrom
@subsubsection 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.@* @strong{If you downloaded from git, follow @ref{Get the full source code from metadata,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, @ref{Install build dependencies,install the build dependencies}. 

To build it, do the following in the main directory:@* $ @strong{./build module flashrom}

To statically compile it, do the following in the main directory:@* $ @strong{./build module flashrom static}

After you've done that, under ./flashrom/ you will find the following executables:

@itemize
@item
@strong{flashrom}
@itemize
@item
For flashing while coreboot or libreboot is running.
@end itemize

@item
@strong{flashrom_lenovobios_sst}
@itemize
@item
This is patched for flashing while Lenovo BIOS is running on an X60 or T60 with the SST25VF016B (SST) flash chip.
@end itemize

@item
@strong{flashrom_lenovobios_macronix}
@itemize
@item
This is patched for flashing while Lenovo BIOS is running on an X60 or T60 with the MX25L1605D (Macronix) flash chip.
@end itemize

@end itemize

The ``builddeps'' script in libreboot_src also makes use of builddeps-flashrom.

@node Configuring libreboot
@subsubsection 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 @ref{Adding a new board to libreboot,newboard_libreboot}. 

If you've already built a kernel before, you know how to use this interface.
@menu
* dmidecode::
* GRUB payload configuration::
* Depthcharge payload configuration::
@end menu

@node dmidecode
@ifinfo
@subsubheading dmidecode
@end ifinfo
There is certain information that can be useful to enter in particular:

@itemize
@item
Local version string
@item
SMBIOS Serial Number
@item
SMBIOS Manufacturer
@item
SMBIOS Version
@item
SMBIOS Product name
@end itemize

This information can be obtained using:@* @strong{$ sudo dmidecode}@* @strong{# 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. @strong{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).

@node GRUB payload configuration
@ifinfo
@subsubheading GRUB payload
@end ifinfo
GRUB is one of the payloads that libreboot targets.

Configurations are then saved as files called @strong{``.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)
@itemize
@item
General setup / Expert mode = @emph{enable}
@item
General / Use CMOS for configuration values = @emph{enable}
@item
Mainboard / Mainboard vendor = @emph{Name of manufacturer}
@item
Mainboard / Mainboard model = @emph{Model name}
@item
Mainboard / ROM chip size = @emph{Size of chip}
@item
Chipset / Include CPU microcode in CBFS = @emph{Do not include microcode updates}
@item
Devices / Use native graphics initialization = @emph{enable}
@item
Display / Keep VESA framebuffer = @emph{disable} (disable for text-mode graphics, enable for coreboot vesa framebuffer)
@itemize
@item
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.
@end itemize

@item
Generic Drivers / USB 2.0 EHCI debug dongle support = @emph{Enable}
@item
Generic Drivers / Enable early (pre-RAM) usbdebug = @emph{Enable}
@item
Generic Drivers / Type of dongle = @emph{Net20DC or compatible}
@item
Generic Drivers / Digitizer = @emph{Present}
@item
Console / USB dongle console output = @emph{enable}
@item
Payload / Add a payload = @emph{An ELF executable payload}
@item
Payload / Payload path and filename = @emph{grub.elf}
@end itemize

Now go back into Devices:

@itemize
@item
Devices / Run VGA Option ROMs = @emph{disable}
@item
Devices / Run Option ROMs on PCI devices = @emph{disable}
@end itemize

The resulting .config file was saved as resources/libreboot/config/@strong{payload/board/config} and is used by the build scripts for this system.

@node Depthcharge payload configuration
@ifinfo
@subsubheading Configuring libreboot for chromebooks - Depthcharge payload
@end ifinfo
Depthcharge is one of the payloads that libreboot targets.

Configurations are then saved as files called @strong{``.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)
@itemize
@item
Mainboard / Mainboard vendor = @emph{Google}
@item
Mainboard / Mainboard model = @emph{Name of board}
@item
Chipset / ChromeOS / Build for ChromeOS = @emph{enable}
@item
Chipset / ChromeOS / Verify firmware with vboot. = @emph{disable}
@item
Payload / Add a payload = @emph{An ELF executable payload}
@item
Payload / Payload path and filename = @emph{depthcharge.elf}
@end itemize

The resulting .config file was saved as resources/libreboot/config/@strong{depthcharge/board/config} and is used by the build scripts for this system.


@node How to build the ROM images
@subsubsection 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, @ref{Install build dependencies,install the build dependencies}. 

If you downloaded libreboot from git, refer to @ref{Get the full source code from metadata,build_meta}. 

Build all of the components used in libreboot:@* $ @strong{./build module all}

You can also build each modules separately, using @emph{./build module modulename}. To see the possible values for @emph{modulename}, use:@* $ @strong{./build module list}

After that, build the ROM images (for all boards):@* $ @strong{./build roms withgrub}@* Alternatively, you can build for a specific board or set of boards. For example:@* $ @strong{./build roms withgrub x60}@* $ @strong{./build roms withgrub x200_8mb}@* $ @strong{./build roms withgrub x60 x200_8mb}@* The list of board options can be found by looking at the directory names in @strong{resources/libreboot/config/grub/}.

For those boards which use the depcharge payload, you must use: $ @strong{./build roms withdepthcharge}@* You can also build for a specific board or set of boards. For example:@* $ @strong{./build roms withdepthcharge veyron_speedy}

To clean (reverse) everything, do the following:@* $ @strong{./build clean all}

The ROM images will be stored under @strong{bin/@emph{payload}/}, where @emph{payload} could be @emph{grub}, @emph{depthcharge}, @emph{seabios}, or whatever other payload those images were built for.
@menu 
* Preparing release archives - optional::
@end menu
@c TODO: Make into node under git.texi?

@node Preparing release archives - optional
@ifinfo
@subsubheading Preparing release archives (optional)
@end ifinfo
@strong{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 @emph{release/$@{version@}/}; $@{version@} will either be set using @emph{git describe} or, if a @emph{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 @emph{release/}, and in the file names of the archives. Otherwise, whatever git uses for @emph{git describe --tags HEAD} will be used.

Utilities (static executables):@* $ @strong{./build release util}

Archive containing flashrom and bucts source code:@* $ @strong{./build release tobuild}

Documentation archive (@strong{does not work on _src release archive, only git}):@* $ @strong{./build release docs}

ROM image archives:@* $ @strong{./build release roms}

Source code archive:@* $ @strong{./build release src}

SHA512 sums of all other release archives that have been generated:@* $ @strong{./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: @strong{nvramtool, cbfstool, ich9deblob, cbmem}.

If you are building on an x86_64 host, this will build statically linked 32- *and* 64-bit binaries for @strong{cbmem}, @strong{ich9deblob}, @strong{cbfstool} and @strong{nvramtool}.

@strong{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.

armv7l binaries (tested on a BeagleBone Black) are also included in libreboot_util, for:

@itemize
@item
cbfstool
@item
ich9gen
@item
ich9deblob
@item
flashrom
@end itemize

If you are building binaries on a live system or chroot (for flashrom/bucts), you can use the following to statically link them:@* $ @strong{./build module flashrom static}@* $ @strong{./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:@* $ @strong{./build release tobuild}@* The archive @strong{tobuild.tar.xz} will have been created under @strong{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 @strong{release/}.

The ROM images will be stored in separate archives for each system, under @strong{release/rom/}.



@node Maintaining libreboot
@subsection 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.

@menu
* Overview - maintaining libreboot::
* Updating coreboot-libre::
* Adding a new board to libreboot::
* Add/remove/modify patches in coreboot-libre::
* Updating GRUB::
* Change how the GRUB payload is built::
* Modify the configuration used in GRUB::
* Updating depthcharge::
* Updating flashrom::
* Updating bucts::
* Updating MemTest86+::
@end menu

@c TODO: What to do with this?
@c @item
@c @uref{../grub/index.html,Other maintenance-related tasks in GRUB}
@c @end itemize 

@node Overview - maintaining libreboot
@subsubsection 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 @emph{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.

@node Updating coreboot-libre
@subsubsection 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. @strong{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):

@itemize
@item
resources/scripts/helpers/download/coreboot
@item
resources/scripts/helpers/build/module/coreboot
@item
resources/utilities/coreboot-libre/deblob
@item
resources/utilities/coreboot-libre/nonblobs
@item
resources/utilities/coreboot-libre/nonblobs_notes
@item
resources/scripts/helpers/build/roms/helper
@item
resources/scripts/helpers/build/roms/withgrub
@end itemize

If you already had a coreboot/ directory in your libreboot tree, delete it:@* $ @strong{rm -Rf coreboot/}

Firstly, download coreboot. Do @strong{not} use @strong{./download coreboot} for this, just clone coreboot, as it does in that script, like so:@* $ @strong{git clone http://review.coreboot.org/coreboot}

$ @strong{cd coreboot/}@* Get the ID of the latest commit in this clone, by reading the commit ID using e.g.:@* $ @strong{git log}@* In @emph{resources/scripts/helpers/download/coreboot} you will find a line that says @emph{@strong{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 @emph{vboot} submodule:@* $ @strong{git submodule update --init --checkout -- 3rdparty/vboot/}

Delete the .git* resources. For example:@* $ @strong{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:@* $ @strong{cd ../}

Check all coreboot file names/paths in @emph{deblob}; if any of them no longer exist at that name/path in the coreboot tree that you downloaded, delete the reference(s) in @emph{deblob}.

Check all coreboot file names/paths in @emph{nonblobs}; if any of them no longer exist at that name/path in the coreboot tree that you downloaded, delete the reference in @emph{nonblobs}.

Now, back in the main root directory of libreboot (git repository), run the deblob script. This is to prevent the @emph{findblobs} scripts from finding the blobs that are already deleted when running the @emph{deblob} script. Like so:@* $ @strong{./resources/utilities/coreboot-libre/deblob}

Now search for new blobs:@* $ @strong{cd resources/utilities/coreboot-libre/}@* $ @strong{./findblobs}@* WARNING: this will take a @strong{*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 @emph{nonblobs}.

Once the @emph{findblobs} script has finished, check the file @emph{tocheck} (from the root, this will be @emph{resources/utilities/coreboot-libre/tocheck}). These are the files detected as blobs; some might be blobs, some not. The @emph{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.

@itemize
@item
Files in @emph{tocheck} that you identify as blobs, should be added appropriately to @emph{resources/utilities/coreboot-libre/deblob}
@item
Files in @emph{tocheck} that you identify as non-blobs, should be added appropriately to @emph{resources/utilities/coreboot-libre/nonblobs} - also, if you feel it necessary, add an explanation of it in @emph{resources/utilities/coreboot-libre/nonblobs_notes}
@end itemize

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:@* $ @strong{cd ../../../}

Now delete the coreboot directory:@* $ @strong{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 @emph{resources/scripts/helpers/download/coreboot} accordingly. Anyway, download coreboot like so:@* $ @strong{./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:@* @uref{http://www.coreboot.org/Git,http://www.coreboot.org/Git}.

Update all configs:@* $ @strong{./build config grubupdate}@* $ @strong{./build config dcupdate}@* This simply takes all of the coreboot @strong{.config} files from @emph{resources/libreboot/config/} and does @strong{make oldconfig} on them. It usually works. If it doesn't, you'll need to recreate those configs from scratch using @strong{./build config grubreplace} or @strong{./build config dcreplace} (optionally add a config name), or @strong{./build config grubmodify} or @strong{./build config dcmodify} (ditto) (see @ref{Configuring libreboot,config}) 

Finally, build *all* ROM images using the instructions at @ref{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: @uref{http://www.coreboot.org/Git,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.


@node Adding a new board to libreboot
@subsubsection 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):@* $ @strong{./build config grubreplace @emph{payload}/@emph{boardname}}@* Alternatively, for depthcharge payload:@* $ @strong{./build config dcreplace @emph{payload}/@emph{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 @ref{Git}. 

When you're done, the config will be stored in @emph{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: @emph{resources/scripts/helpers/build/roms/withgrub} and @emph{resources/scripts/helpers/build/roms/helper}

The following can be used when updating coreboot-libre (GRUB payload):@* $ @strong{./build config grubupdate}@* You must also do this for boards that use the depthcharge payload:@* $ @strong{./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):@* $ @strong{./build config grubmodify}@* For those boards which use the depthcharge payload:@* $ @strong{./build config dcmodify}@* (adding a board name on the end is optional)

Examples (GRUB payload):@* $ @strong{./build config grubmodify x60}@* $ @strong{./build config grubreplace x60}@* $ @strong{./build config grubupdate x60}@* $ @strong{./build config grubmodify kfsn4-dre}@* $ @strong{./build config grubreplace kfsn4-dre}@* $ @strong{./build config grubupdate kfsn4-dre}@*

Examples (depthcharge payload):@* $ @strong{./build config dcmodify veyron_speedy}@* $ @strong{./build config dcreplace veyron_speedy}@* $ @strong{./build config dcupdate veyron_speedy}


@node Add/remove/modify patches in coreboot-libre
@subsubsection Add/remove/modify patches in coreboot-libre
Under @strong{resources/scripts/helpers/download/coreboot} you can find the instructions used for patching coreboot.

Modify the commit ID on the @emph{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 @emph{git am} (you can get the diff by using git-format-patch).

When you're done, simply download coreboot again:@* $ @strong{./download coreboot}

Finally, re-build the parts from coreboot that are used by the build system (also builds GCC):@* $ @strong{./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 @emph{resources/scripts/helpers/build/module/coreboot} except for the part that builds GCC. @strong{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.


@node Updating GRUB
@subsubsection Updating GRUB
$ @strong{rm -Rf grub/}@* $ @strong{git clone git://git.savannah.gnu.org/grub.git}@* $ @strong{cd grub/}@* $ @strong{git log}

Open the file @emph{resources/scripts/helpers/download/grub} and replace the commit ID on the line that performs @emph{git reset --hard} with the commit ID of the GRUB revision that you just downloaded.

$ @strong{cd ../}@* $ @strong{./download grub}

If it fails because of merge conflicts, you'll need to re-base or (as appropriate) remove the offending patch(es) in @emph{resources/scripts/helpers/download/grub}.

Finally, verify that it will build:@* $ @strong{./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.


@node Change how the GRUB payload is built
@subsubsection Change how the GRUB payload (grub.elf) is built (utility: grub-assemble)
Look in @emph{resources/utilities/grub-assemble/}.

@emph{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.

@emph{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.


@node Modify the configuration used in GRUB
@subsubsection Modify the configuration used in GRUB
Look in @emph{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 @emph{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.


@node Updating depthcharge
@subsubsection Updating depthcharge
The script to download depthcharge is: @emph{resources/scripts/helpers/download/depthcharge}.

Patches are in @emph{resources/depthcharge/patch/}.

The configuration used for depthcharge is located in @emph{depthcharge/board}. Each board has a @emph{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.


@node Updating flashrom
@subsubsection Updating flashrom
Modify these files: @emph{resources/scripts/helpers/download/flashrom} and @emph{resources/scripts/helpers/build/module/flashrom}.

Patches are in @emph{resources/flashrom/patch/}


@node Updating bucts
@subsubsection Updating bucts
bucts doesn't really need updating, but the patches are in @emph{resources/bucts/patch}, the download script is @emph{resources/scripts/helpers/download/bucts} and the build script is @emph{resources/scripts/helpers/build/module/bucts}.


@node Updating MemTest86+
@subsubsection Updating MemTest86+
MemTest86+ doesn't really need updating, but the patches are in @emph{resources/memtest86plus/patch}, the download script is @emph{resources/scripts/helpers/download/memtest86plus} and the build script is @emph{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.







@node Hardware security
@section Hardware security
Security topics:

@menu
* ThinkPad X60/X60S - Hardware security::
* ThinkPad T60 - Hardware security::
* Notes about DMA and the docking station::
@end menu


@node ThinkPad X60/X60S - Hardware security
@subsection Security on the ThinkPad X60
Hardware modifications to enhance security on the ThinkPad X60. This tutorial is @strong{incomplete} at the time of writing.

@menu
* Hardware requirements - X60::
* Software requirements - X60::
* Rationale - X60::
* Disassembly - X60::
* Extra notes - X60::
* Risk level - X60::
* Further reading material - software security - X60::
* References - X60::
@end menu



@node Hardware requirements - X60
@subsubsection Hardware requirements
@itemize
@item
An X60
@item
screwdriver
@item
(in a later version of this tutorial: soldering iron and scalpel)
@end itemize

@node Software requirements - X60
@subsubsection Software requirements
@itemize
@item
none (at least in the scope of the article as-is)
@item
You probably want to encrypt your GNU/Linux install using LUKS
@end itemize

@node Rationale - X60
@subsubsection 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.

@node Disassembly - X60
@subsubsection 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):@* @image{../resources/images/x60_security/0000_bluetooth0,,,,jpg}@* Now gently pry off the bottom part of the front bezel, and the bluetooth module is on the left (easily removable):@* @image{../resources/images/x60_security/0000_bluetooth,,,,jpg}@*

If your model was WWAN, remove the simcard (check anyway):@* Uncover those 2 screws at the bottom:@* @image{../resources/images/x60_security/0000_simcard0,,,,jpg}@* SIM card (not present in the picture) is in the marked location:@* @image{../resources/images/x60_security/0000_simcard1,,,,jpg}@* Replacement: USB dongle.

Now get into the motherboard.

Remove those screws:@* @image{../resources/images/x60_security/0000,,,,jpg}

Push the keyboard forward (carefully):@* @image{../resources/images/x60_security/0001,,,,jpg}

Lift the keyboard up and disconnect it from the board:@* @image{../resources/images/x60_security/0002,,,,jpg}

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:@* @image{../resources/images/x60_security/0003,,,,jpg}

You should now have this:@* @image{../resources/images/x60_security/0004,,,,jpg}

The following is a summary of what you will remove (already done to this system):@* @image{../resources/images/x60_security/0001_overview,,,,jpg}@* 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). @strong{This is optional}

Remove the microphone (can desolder it, but you can also easily pull it off with you hands). Already removed here:@* @image{../resources/images/x60_security/0001_microphone,,,,jpg}@* @strong{Rationale:}@* Another reason to remove the microphone: If your computer gets @xref{physical-access-x60,,[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). @strong{In other words, the system could already be compromised from the factory.}

Remove the modem:@* @image{../resources/images/x60_security/0001_modem,,,,jpg}@* (useless, obsolete device)

Remove the speaker:@* @image{../resources/images/x60_security/0001_speaker,,,,jpg}@* Reason: combined with the microphone issue, this could be used to leak data.@* If your computer gets @xref{physical-access-x60,,[1]}, compromised, it can be used to transmit data to nearby compromised devices. It's unknown if it can be turned into a microphone @xref{microphone-x60,,[2]},.@* Replacement: headphones/speakers (line-out) or external DAC (USB).

Remove the wlan (also remove wwan if you have it):@* @image{../resources/images/x60_security/0001_wlan_wwan,,,,jpg}@* Reason: has direct (and very fast) memory access, and could (theoretically) leak data over a side-channel.@* @strong{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.@* @strong{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).

@menu
* Not covered yet - X60::
* Also not covered yet - X60::
@end menu

@node Not covered yet - X60
@ifinfo
@subsubheading Not covered yet:
@end ifinfo
@itemize
@item
Disable cardbus (has fast/direct memory access)
@item
Disable firewire (has fast/direct memory access)
@item
Disable flashing the ethernet firmware
@item
Disable SPI flash writes (can be re-enabled by unsoldering two parts)
@item
Disable use of xrandr/edid on external monitor (cut 2 pins on VGA)
@item
Disable docking station (might be possible to do it in software, in coreboot upstream as a Kconfig option)
@end itemize

Go to @uref{http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge.html,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: @uref{http://mirror.netcologne.de/CCC/congress/2013/webm/30c3-5529-en-Hardening_hardware_and_choosing_a_goodBIOS_webm.webm,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.

@node Also not covered yet - X60
@ifinfo
@subsubheading Also not covered yet:
@end ifinfo
@itemize
@item
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. @c TYPO: picueres > pictures
@item
Tips about preventing/mitigating risk of cold boot attack.
@itemize
@item
soldered RAM?
@item
seal RAM door shut (possibly modified lower chassis) so that system has to be disassembled (which has to go through the nail polish)
@item
wipe all RAM at boot/power-off/power-on? (patch in coreboot upstream?)
@item
ask gnutoo about fallback patches (counts number of boots)
@end itemize

@item
General tips/advice and web links showing how to detect physical intrusions.
@item
For example: @uref{http://cs.tau.ac.il/~tromer/acoustic/,http://cs.tau.ac.il/~tromer/acoustic/} or @uref{http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper,http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper}.
@item
@uref{https://en.wikipedia.org/wiki/Tempest_%28codename%29,https://en.wikipedia.org/wiki/Tempest_%28codename%29}
@item
https://gitorious.org/gnutoo-for-coreboot/grub-assemble/source/a61f636797777a742f65f4c9c58032aa6a9b23c3:
@end itemize

@node Extra notes - X60
@subsubsection 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 @strong{(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 @xref{video-ccc-x60,[3]}. 

@uref{http://www.coreboot.org/Intel_82573_Ethernet_controller,Intel 82573 Ethernet controller} on the X60 seems safe, according to Denis.
@ignore
@menu
@c * Risk level - X60::
@end menu
@end ignore

@node Risk level - X60
@subsubsection Risk level
@itemize
@item
Modem (3g/wwan): highest
@item
Intel wifi: Near highest
@item
Atheros PCI wifi: unknown, but lower than intel wifi.
@item
Microphone: only problematic if the computer gets compromised.
@item
Speakers: only problematic if the computer gets compromised.
@item
EC: can be mitigated if following the guide on software security.
@end itemize

@node Further reading material - software security - X60
@subsubsection Further reading material (software security)
@itemize
@item
@ref{Installing Trisquel GNU/Linux-libre with full disk encryption,Installing Trisquel GNU/Linux with full disk encryption (including /boot)}
@item
@ref{Installing Parabola GNU/Linux-libre with full disk encryption,Installing Parabola GNU/Linux with full disk encryption (including /boot)}
@item
@ref{Notes about DMA and the docking station,Notes about DMA access and the docking station}
@end itemize

@node References - X60
@subsubsection References

@enumerate
@item
physical access
@anchor{physical-access-x60}

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.

@item
microphone
@anchor{microphone-x60}

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.

@item 
Video (CCC)
@anchor{video-ccc-x60}

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. @uref{http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm,http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm}
@end enumerate



@node ThinkPad T60 - Hardware security
@subsection Security on the ThinkPad T60
Hardware modifications to enhance security on the ThinkPad T60. This tutorial is @strong{incomplete} at the time of writing.

@menu
* Hardware requirements - T60::
* Software requirements - T60::
* Rationale - T60::
* Disassembly - T60::
* Extra notes - T60::
* Risk level - T60::
* Further reading material - software security - T60::
* References - T60::
@end menu


@node Hardware requirements - T60
@subsubsection Hardware requirements
@itemize
@item
A T60
@item
screwdriver
@item
Rubbing or isopropyl alcohol, and thermal compound.
@item
(in a later version of this tutorial: soldering iron and scalpel)
@end itemize

@node Software requirements - T60
@subsubsection Software requirements
@itemize
@item
none (at least in the scope of the article as-is)
@item
You probably want to encrypt your GNU/Linux install using LUKS
@end itemize

@node Rationale - T60
@subsubsection 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.

@node Disassembly - T60
@subsubsection Disassembly
Remove those screws and remove the HDD:@* @image{../resources/images/t60_dev/0001,,,,JPG} @image{../resources/images/t60_dev/0002,,,,JPG}

Lift off the palm rest:@* @image{../resources/images/t60_dev/0003,,,,JPG}

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:@* @image{../resources/images/t60_dev/0004,,,,JPG} @image{../resources/images/t60_dev/0005,,,,JPG} @image{../resources/images/t60_dev/0006,,,,JPG}

Gently wedge both sides loose:@* @image{../resources/images/t60_dev/0007,,,,JPG} @image{../resources/images/t60_dev/0008,,,,JPG}

Remove that cable from the position:@* @image{../resources/images/t60_dev/0009,,,,JPG} @image{../resources/images/t60_dev/0010,,,,JPG}

Now remove that bezel. Remove wifi, nvram battery and speaker connector (also remove 56k modem, on the left of wifi):@* @image{../resources/images/t60_dev/0011,,,,JPG}@* Reason: has direct (and very fast) memory access, and could (theoretically) leak data over a side-channel.@* @strong{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:@* @image{../resources/images/t60_dev/0012,,,,JPG}

Disconnect the power jack:@* @image{../resources/images/t60_dev/0013,,,,JPG}

Remove nvram battery (we will put it back later):@* @image{../resources/images/t60_dev/0014,,,,JPG}

Disconnect cable (for 56k modem) and disconnect the other cable:@* @image{../resources/images/t60_dev/0015,,,,JPG} @image{../resources/images/t60_dev/0016,,,,JPG}

Disconnect speaker cable:@* @image{../resources/images/t60_dev/0017,,,,JPG}

Disconnect the other end of the 56k modem cable:@* @image{../resources/images/t60_dev/0018,,,,JPG}

Make sure you removed it:@* @image{../resources/images/t60_dev/0019,,,,JPG}

Unscrew those:@* @image{../resources/images/t60_dev/0020,,,,JPG}

Make sure you removed those:@* @image{../resources/images/t60_dev/0021,,,,JPG}

Disconnect LCD cable from board:@* @image{../resources/images/t60_dev/0022,,,,JPG}

Remove those screws then remove the LCD assembly:@* @image{../resources/images/t60_dev/0023,,,,JPG} @image{../resources/images/t60_dev/0024,,,,JPG} @image{../resources/images/t60_dev/0025,,,,JPG}

Once again, make sure you removed those:@* @image{../resources/images/t60_dev/0026,,,,JPG}

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:@* @image{../resources/images/t60_dev/0027,,,,JPG} @image{../resources/images/t60_dev/0028,,,,JPG} @image{../resources/images/t60_dev/0029,,,,JPG} @image{../resources/images/t60_dev/0031,,,,JPG} @image{../resources/images/t60_dev/0032,,,,JPG} @image{../resources/images/t60_dev/0033,,,,JPG}

Remove microphone (soldering iron not needed. Just wedge it out gently):@* @image{../resources/images/t60_dev/0039,,,,JPG}@* @strong{Rationale:}@* Another reason to remove the microphone: If your computer gets@xref{physical-access-t60,,[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). @strong{In other words, the system could already be compromised from the factory.}

Remove infrared:@* @image{../resources/images/t60_dev/0040,,,,JPG} @image{../resources/images/t60_dev/0042,,,,JPG}

Remove cardbus (it's in a socket, no need to disable. Just remove the port itself):@* @image{../resources/images/t60_dev/0041,,,,JPG}@* @strong{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:@* @image{../resources/images/t60_dev/0043,,,,JPG} @image{../resources/images/t60_dev/0044,,,,JPG}@* Reason: combined with the microphone issue, this could be used to leak data.@* If your computer gets@xref{physical-access-t60,,[1]}, compromised, it can be used to transmit data to nearby compromised devices. It's unknown if it can be turned into a microphone@xref{microphone-t60,,[2]}.@* Replacement: headphones/speakers (line-out) or external DAC (USB).

Remove the wwan:@* @image{../resources/images/t60_dev/0045,,,,JPG}@* @strong{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?)@* @image{../resources/images/t60_dev/0046,,,,JPG}

Put those screws back:@* @image{../resources/images/t60_dev/0047,,,,JPG}

Put it back into lower chassis:@* @image{../resources/images/t60_dev/0048,,,,JPG}

Attach LCD and insert screws (also, attach the lcd cable to the board):@* @image{../resources/images/t60_dev/0049,,,,JPG}

Insert those screws:@* @image{../resources/images/t60_dev/0050,,,,JPG}

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@* @image{../resources/images/t60_dev/0051,,,,JPG}

Attach the heatsink and install the screws (also, make sure to install the AC jack as highlighted):@* @image{../resources/images/t60_dev/0052,,,,JPG}

Reinstall that upper bezel:@* @image{../resources/images/t60_dev/0053,,,,JPG}

Do that:@* @image{../resources/images/t60_dev/0054,,,,JPG} @image{../resources/images/t60_dev/0055,,,,JPG}

Attach keyboard and install nvram battery:@* @image{../resources/images/t60_dev/0056,,,,JPG} @image{../resources/images/t60_dev/0057,,,,JPG}

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:@* @image{../resources/images/t60_dev/0058,,,,JPG}

Remove those covers and unscrew:@* @image{../resources/images/t60_dev/0059,,,,JPG} @image{../resources/images/t60_dev/0060,,,,JPG} @image{../resources/images/t60_dev/0061,,,,JPG}

Gently pry off the front bezel (sorry, forgot to take pics).

Remove bluetooth module:@* @image{../resources/images/t60_dev/0062,,,,JPG} @image{../resources/images/t60_dev/0063,,,,JPG}

Re-attach the front bezel and re-insert the screws (sorry, forgot to take pics).

It lives!@* @image{../resources/images/t60_dev/0071,,,,JPG} @image{../resources/images/t60_dev/0072,,,,JPG} @image{../resources/images/t60_dev/0073,,,,JPG}

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:@* @image{../resources/images/t60_dev/0074,,,,JPG}
@menu
* Not covered yet - T60::
* Also not covered yet - T60::
@end menu

@node Not covered yet - T60
@ifinfo
@subsubheading Not covered yet
@end ifinfo
@itemize
@item
Disable flashing the ethernet firmware
@item
Disable SPI flash writes (can be re-enabled by unsoldering two parts)
@item
Disable use of xrandr/edid on external monitor (cut 2 pins on VGA)
@item
Disable docking station (might be possible to do it in software, in coreboot upstream as a Kconfig option)
@end itemize

Go to @uref{http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge.html,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: @uref{http://mirror.netcologne.de/CCC/congress/2013/webm/30c3-5529-en-Hardening_hardware_and_choosing_a_goodBIOS_webm.webm,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.

@node Also not covered yet - T60
@ifinfo
@subsubheading Also not covered yet
@end ifinfo
@itemize
@item
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.
@item
Tips about preventing/mitigating risk of cold boot attack.
@itemize
@item
soldered RAM?
@item
wipe all RAM at boot/power-off/power-on? (patch in coreboot upstream?)
@item
ask gnutoo about fallback patches (counts number of boots)
@end itemize

@item
General tips/advice and web links showing how to detect physical intrusions.
@item
For example: @uref{http://cs.tau.ac.il/~tromer/acoustic/,http://cs.tau.ac.il/~tromer/acoustic/} or @uref{http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper,http://cyber.bgu.ac.il/content/how-leak-sensitive-data-isolated-computer-air-gap-near-mobile-phone-airhopper}.
@item
@uref{https://en.wikipedia.org/wiki/Tempest_%28codename%29,https://en.wikipedia.org/wiki/Tempest_%28codename%29}
@item
https://gitorious.org/gnutoo-for-coreboot/grub-assemble/source/a61f636797777a742f65f4c9c58032aa6a9b23c3:
@end itemize

@node Extra notes - T60
@subsubsection 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 @strong{(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@xref{video-ccc-t60,,[3]}.

@uref{http://www.coreboot.org/Intel_82573_Ethernet_controller,Intel 82573 Ethernet controller} on the X60 seems safe, according to Denis.

@ignore
@menu
@c * Risk level - T60::
@end menu
@end ignore

@node Risk level - T60
@subsubsection Risk level
@itemize
@item
Modem (3g/wwan): highest
@item
Intel wifi: Near highest
@item
Atheros PCI wifi: unknown, but lower than intel wifi.
@item
Microphone: only problematic if the computer gets compromised.
@item
Speakers: only problematic if the computer gets compromised.
@item
EC: can be mitigated if following the guide on software security.
@end itemize

@node Further reading material - software security - T60
@subsubsection Further reading material (software security)
@itemize
@item
@ref{Installing Trisquel GNU/Linux-libre with full disk encryption,Installing Trisquel GNU/Linux with full disk encryption (including /boot)}
@item
@ref{Installing Parabola GNU/Linux-libre with full disk encryption,Installing Parabola GNU/Linux with full disk encryption (including /boot)}
@item
@ref{Notes about DMA and the docking station,Notes about DMA access and the docking station}
@end itemize

@node References - T60
@subsubsection References

@enumerate
@item
physical access
@anchor{physical-access-t60}

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.

@item
microphone
@anchor{microphone-t60}

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.

@item
Video (CCC)
@anchor{video-ccc-t60}

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. @uref{http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm,http://berlin.ftp.media.ccc.de/congress/2013/webm/30c3-5356-en-Firmware_Fat_Camp_webm.webm}
@end enumerate

@c @bye


@node Notes about DMA and the docking station
@subsection Notes about DMA access and the docking station

@verbatim

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.
@end verbatim





@node Hardware maintenance
@section Hardware maintenance
This section relates to hardware maintenance on supported targets.

@menu
* ThinkPad X60/X60s/X60T Change keyboard::
* ThinkPad X60/X60S Change the fan/heatsink::
* ThinkPad X60/X60s How to change the LCD panel::
* ThinkPad T60 15.1" changing LCD panel::
* ThinkPad T60 change the fan/heatsink::
@end menu


@node ThinkPad X60/X60s/X60T Change keyboard
@subsection 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.

@image{../resources/images/x60_keyboard/1,,,,JPG}@*
@image{../resources/images/x60_keyboard/2,,,,JPG}@*
@image{../resources/images/x60_keyboard/3,,,,JPG}@*
@image{../resources/images/x60_keyboard/4,,,,JPG}@*
@image{../resources/images/x60_keyboard/5,,,,JPG}


@node ThinkPad X60/X60S Change the fan/heatsink
@subsection Changing the fan/heatsink on the ThinkPad X60

This guide will teach you how to replace the fan and heatsink on your ThinkPad X60.

@menu
* Hardware requirements - X60 heatsink::
* Software requirements for CPU stress testing - X60 heatsink::
* Disassembly::
@end menu

@node Hardware requirements - X60 heatsink
@subsubsection Hardware requirements
@itemize
@item
isopropyl alcohol (sometimes called rubbing alcohol)
@item
your new fan and/or heatsink
@item
CPU thermal compound (some say Arctic MX-4 is good, others are also 'ok')
@item
Something to spread the paste with
@end itemize

@node Software requirements for CPU stress testing - X60 heatsink
@subsubsection Software requirements (for CPU stress testing)
@itemize
@item
xsensors utility
@item
stress utility
@end itemize

@node Disassembly
@subsubsection Disassembly
Remove those screws:@* @image{../resources/images/x60_heatsink/0000,,,,jpg}

Push the keyboard forward (carefully):@* @image{../resources/images/x60_heatsink/0001,,,,jpg}

Lift the keyboard up and disconnect it from the board:@* @image{../resources/images/x60_heatsink/0002,,,,jpg}

Grab the right-hand side of the chassis and force it off (gently) and pry up the rest of the chassis:@* @image{../resources/images/x60_heatsink/0003,,,,jpg}

You should now have this:@* @image{../resources/images/x60_heatsink/0004,,,,jpg}

Disconnect the wifi antenna cables, the modem cable and the speaker:@* @image{../resources/images/x60_heatsink/0005,,,,jpg}

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:@* @image{../resources/images/x60_heatsink/0006,,,,jpg}

Disconnect the monitor from the motherboard, and unroute the grey antenna cable, carefully lifting the tape that holds it into place:@* @image{../resources/images/x60_heatsink/0008,,,,jpg}

Carefully lift the remaining tape and unroute the left antenna cable so that it is loose:@* @image{../resources/images/x60_heatsink/0009,,,,jpg}

Remove those screws:@* @image{../resources/images/x60_heatsink/0011,,,,jpg}

Remove those screws:@* @image{../resources/images/x60_heatsink/0012,,,,jpg}

Carefully remove the plate, like so:@* @image{../resources/images/x60_heatsink/0013,,,,jpg}

Remove the SATA connector:@* @image{../resources/images/x60_heatsink/0014,,,,jpg}

Now remove the motherboard (gently) and cast the lcd/chassis aside:@* @image{../resources/images/x60_heatsink/0015,,,,jpg}

Look at that black tape above the heatsink, remove it:@* @image{../resources/images/x60_heatsink/0016,,,,jpg}

Now you have removed it:@* @image{../resources/images/x60_heatsink/0017,,,,jpg}

Disconnect the fan and remove all the screws, heatsink will easily come off:@* @image{../resources/images/x60_heatsink/0018,,,,jpg}

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.

@strong{stress -c 2} command can be used to push the CPU to 100%, and @strong{xsensors} (or @strong{watch sensors} command) can be used to monitor heat. Below 90C is ok.


@node ThinkPad X60/X60s How to change the LCD panel
@subsection ThinkPad X60/X60s How to change the LCD panel

This tutorial is incomplete, and only pictures for now.

@image{../resources/images/x60_lcd_change/0001,,,,JPG}
@image{../resources/images/x60_lcd_change/0002,,,,JPG}
@image{../resources/images/x60_lcd_change/0003,,,,JPG}
@image{../resources/images/x60_lcd_change/0004,,,,JPG}
@image{../resources/images/x60_lcd_change/0005,,,,JPG}
@image{../resources/images/x60_lcd_change/0006,,,,JPG}
@image{../resources/images/x60_lcd_change/0007,,,,JPG}



@node ThinkPad T60 15.1" changing LCD panel
@subsection 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".

@menu
* Disassembly - T60 LCD::
@end menu

@node Disassembly - T60 LCD
@subsubsection Disassembly
Remove those covers and unscrew:@* @image{../resources/images/t60_dev/0059,,,,JPG} @image{../resources/images/t60_dev/0060,,,,JPG} @image{../resources/images/t60_dev/0061,,,,JPG}

Gently pry off the front bezel.

Remove inverter board:@* @image{../resources/images/t60_dev/0064,,,,JPG}

Disconnect LCD cable:@* @image{../resources/images/t60_dev/0065,,,,JPG}

Remove the panel:@* @image{../resources/images/t60_dev/0066,,,,JPG}

Move the rails (left and right side) from the old panel to the new one and then attach LCD cable:@* @image{../resources/images/t60_dev/0068,,,,JPG}

Insert panel (this one is an LG-Philips LP150E05-A2K1, and there are others. See @ref{Supported T60 list,supported_t60_list}):@* @image{../resources/images/t60_dev/0069,,,,JPG}

Insert new inverter board (see @ref{Supported T60 list,supported_t60_list} for what is recommended on your LCD panel):@* @image{../resources/images/t60_dev/0070,,,,JPG}

Now re-attach the front bezel and put all the screws in.

It lives!@* @image{../resources/images/t60_dev/0071,,,,JPG} @image{../resources/images/t60_dev/0072,,,,JPG} @image{../resources/images/t60_dev/0073,,,,JPG}


@node ThinkPad T60 change the fan/heatsink
@subsection ThinkPad T60 change the fan/heatsink

Using this guide you can also change/upgrade the CPU.

@menu
* Hardware requirements - T60 heatsink::
* Software requirements - T60 heatsink::
* Disassembly - T60 heatsink::
@end menu

@node Hardware requirements - T60 heatsink
@subsubsection Hardware requirements - T60 heatsink
@itemize
@item
rubbing alcohol or isopropyl alcohol, and thermal compound for changing CPU heatsink (procedure involves removing heatsink)
@item
thermal compound/paste (Arctic MX-4 is good. Others are also good.)
@end itemize

@node Software requirements - T60 heatsink
@subsubsection Software requirements - T60 heatsink
@itemize
@item
xsensors
@item
stress
@end itemize

@node Disassembly - T60 heatsink
@subsubsection Disassembly - T60 heatsink
Remove those screws and remove the HDD:@* @image{../resources/images/t60_dev/0001,,,,JPG} @image{../resources/images/t60_dev/0002,,,,JPG}

Lift off the palm rest:@* @image{../resources/images/t60_dev/0003,,,,JPG}

Lift up the keyboard, pull it back a bit, flip it over like that and then disconnect it from the board:@* @image{../resources/images/t60_dev/0004,,,,JPG} @image{../resources/images/t60_dev/0005,,,,JPG} @image{../resources/images/t60_dev/0006,,,,JPG}

Gently wedge both sides loose:@* @image{../resources/images/t60_dev/0007,,,,JPG} @image{../resources/images/t60_dev/0008,,,,JPG}

Remove that cable from the position:@* @image{../resources/images/t60_dev/0009,,,,JPG} @image{../resources/images/t60_dev/0010,,,,JPG}

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@* @image{../resources/images/t60_dev/0051,,,,JPG}

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):@* @image{../resources/images/t60_dev/0052,,,,JPG}

Reinstall that upper bezel:@* @image{../resources/images/t60_dev/0053,,,,JPG}

Do that:@* @image{../resources/images/t60_dev/0054,,,,JPG} @image{../resources/images/t60_dev/0055,,,,JPG}

Attach keyboard:@* @image{../resources/images/t60_dev/0056,,,,JPG}

Place keyboard and (sorry, forgot to take pics) reinstall the palmrest and insert screws on the underside:@* @image{../resources/images/t60_dev/0058,,,,JPG}

It lives!@* @image{../resources/images/t60_dev/0071,,,,JPG} @image{../resources/images/t60_dev/0072,,,,JPG} @image{../resources/images/t60_dev/0073,,,,JPG}

Always stress test ('stress -c 2' and xsensors. below 90C is ok) when replacing cpu paste/heatsink:@* @image{../resources/images/t60_dev/0074,,,,JPG}






@node Depthcharge
@section Depthcharge payload
This section relates to the depthcharge payload used in libreboot.

@menu
* CrOS security model::
* Developer mode screen::
* Recovery mode screen::
* Configuring verified boot parameters for depthcharge::
@end menu


@node CrOS security model
@subsection 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 @xref{Configuring verified boot parameters for depthcharge,configuring verified boot parameters}.

@node Developer mode screen
@subsection Developer mode screen
The developer mode screen can be accessed in depthcharge when developer mode is enabled.@* Developer mode can be enabled from the @xref{Recovery mode screen,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.
@menu
* Holding the developer mode screen::
* Booting normally::
* Booting from different mediums::
* Showing device information::
* Warnings::
@end menu

@node Holding the developer mode screen
@subsubsection Holding the developer mode screen
As instructed on the developer mode screen, the screen can be held by pressing @strong{Ctrl + H} in the first 3 seconds after the screen is shown. After that delay, depthcharge will resume booting normally.

@node Booting normally
@subsubsection Booting normally
As instructed on the developer mode screen, a regular boot will happen after @strong{3 seconds} (if developer mode screen is not held).@* The default boot medium (internal storage, external media, legacy payload) is shown on screen.

@node Booting from different mediums
@subsubsection Booting from different mediums
Depthcharge allows booting from different mediums, when they are allowed (see @xref{Configuring verified boot parameters for depthcharge,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:

@itemize
@item
Internal storage: @strong{Ctrl + D}
@item
External media: @strong{Ctrl + U} (when enabled)
@item
Legacy payload: @strong{Ctrl + L} (when enabled)
@end itemize

@node Showing device information
@subsubsection Showing device information
As instructed on the developer mode screen, showing device information can be triggered by pressing @strong{Ctrl + I} or @strong{Tab}.@* Various information is shown, including vboot non-volatile data, TPM status, GBB flags and key hashes.@*

@node Warnings
@subsubsection Warnings
The developer mode screen will show warnings when:

@itemize
@item
Booting kernels without verifying their signature is enabled
@item
Booting from external media is enabled
@item
Booting legacy payloads is enabled
@end itemize

@node Recovery mode screen
@subsection Recovery mode screen
The recovery mode screen can be accessed in depthcharge, by pressing @strong{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.
@menu
* Recovering from a bad state::
* Enabling developer mode::
@end menu

@node Recovering from a bad state
@subsubsection 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.

@node Enabling developer mode
@subsubsection Enabling developer mode
As instructed on the recovery mode screen, developer mode can be enabled by pressing @strong{Ctrl + D}.@* Instructions to confirm enabling developer mode are then shown on screen.

@node Configuring verified boot parameters for depthcharge
@subsection 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 @strong{crossystem} tool, that requires sufficient privileges to access the verified boot non-volatile storage.

@strong{crossystem} relies on @strong{mosys}, that is used to access the verified boot non-volatile storage on some devices. @strong{crossystem} and @strong{mosys} are both free software and their source code is made available by Google: @uref{https://chromium.googlesource.com/chromiumos/platform/vboot_reference/,crossystem}. @uref{https://chromium.googlesource.com/chromiumos/platform/mosys/,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 @strong{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:

@itemize
@item
Kernels signature verification:
@itemize @minus
@item
Enabled with:@* # @strong{crossystem dev_boot_signed_only=1}
@item
Disabled with:@* # @strong{crossystem dev_boot_signed_only=0}
@end itemize

@item
External media boot:
@itemize @minus
@item
Enabled with:@* # @strong{crossystem dev_boot_usb=1}
@item
Disabled with:@* # @strong{crossystem dev_boot_usb=0}
@end itemize

@item
Legacy payload boot:
@itemize @minus
@item
Enabled with:@* # @strong{crossystem dev_boot_legacy=1}
@item
Disabled with:@* # @strong{crossystem dev_boot_legacy=0}
@end itemize

@item
Default boot medium:
@itemize @minus
@item
Internal storage:@* # @strong{crossystem dev_default_boot=disk}
@item
External media:@* # @strong{crossystem dev_default_boot=usb}
@item
Legacy payload:@* # @strong{crossystem dev_default_boot=legacy}
@end itemize

@end itemize





@node GRUB
@section Grub payload
This section relates to the GRUB payload used in libreboot.

@menu
* Changing the background image in GRUB::
* Setting font in GRUB - for reference::
* GRUB keyboard layouts - for reference::
@end menu


@node Changing the background image in GRUB
@subsection Changing the background image in GRUB
Use cbfstool from libreboot_util, or libreboot_src/coreboot/util/cbfstool/ if you want to build from source.

./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.

@node Setting font in GRUB - for reference
@subsection 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: @uref{http://dejavu-fonts.org/wiki/Download,dejavu-fonts.org}

Specifically, the version that I chose was the latest at the time of writing (Saturday 21 June 2014): @uref{http://sourceforge.net/projects/dejavu/files/dejavu/2.34/dejavu-fonts-ttf-2.34.tar.bz2,this one}

This is a free font that is also contained in GNU/Linux distributions like Trisquel or Parabola.

@strong{$ cd libreboot_src/grub}@* compile grub (the build scripts info on how to do this)@* come back out into libreboot_src/resources/grub:@* @strong{$ cd ../libreboot_src/resources/grub/font}

I took Dejavu Sans Mono from dejavu (included in this version of libreboot) and did:@* @strong{$ ../../../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):@* @strong{loadfont (memdisk)/dejavusansmono.pf2}


@node GRUB keyboard layouts - for reference
@subsection GRUB keyboard layouts (for reference)

@menu
* Custom keyboard layout in GRUB - for reference::
* UK Dvorak keyboard layout in GRUB - for reference::
@end menu

@node Custom keyboard layout in GRUB - for reference
@subsubsection Custom keyboard layout in GRUB (for reference)
Keymaps are stored in resources/utilities/grub-assemble/keymap/.

Example (French Azerty):@* @strong{$ ckbcomp fr > frazerty}@*@* Go in grub directory:@* @strong{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 @strong{frazerty} in @strong{resources/utilities/grub-assemble/keymap/original/} and the @strong{frazerty.gkb} file goes under @strong{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: @strong{libreboot_frazerty.rom}.


@node UK Dvorak keyboard layout in GRUB - for reference
@subsubsection 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

@strong{$ cat ukdvorak | ./grub/grub-mklayout -o ukdvorak.gkb}




@node Miscellaneous
@section Miscellaneous

@menu
* High Pitched Whining Noise on Idle - Trisquel 7::
* High Pitched Whining Noise on Idle - Parabola::
* X60/T60 Serial port - how to use::                     for dock owners
* Power Management Beeps on Thinkpads::
* Get EDID - Find out the name of your LCD panel::
@end menu


@node High Pitched Whining Noise on Idle - Trisquel 7
@subsection High Pitched Whining Noise on Idle (how to remove in Trisquel 7)
@ignore
@menu
* Start powertop automatically at boot time::
@end menu
@end ignore

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.

$ @strong{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 @emph{processor.max_cstate=2} to the @emph{linux} line in grub.cfg, using @ref{How to replace the default GRUB configuration file on a libreboot system,this guide}. 

@node High Pitched Whining Noise on Idle - Parabola
@subsection 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@* @strong{$ su -}

Installed powertop:@* @strong{# pacman -S powertop}

and added the folloing to /etc/systemd/system/powertop.service :

@verbatim
[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
@end verbatim

Finally, as root do that:@* @strong{# systemctl enable powertop}@* @strong{# 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 @emph{processor.max_cstate=2} to the @emph{linux} line in grub.cfg, using @ref{How to replace the default GRUB configuration file on a libreboot system,this guide}.


@node X60/T60 Serial port - how to use
@subsection X60/T60: Serial port - how to use (for dock owners)
For the Thinkpad X60 you can use the @strong{"UltraBase X6"} dock (for the X60 Tablet it is called X6 Tablet UltraBase). For the ThinkPad T60, you can use the @strong{"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):@* @strong{$ 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:@* @uref{https://help.ubuntu.com/community/SerialConsoleHoto,https://help.ubuntu.com/community/SerialConsoleHoto}

Note: part of the tutorial above requires changing your grub.cfg. Just change the @strong{linux} line to add instructions for enabling getty. See @ref{How to replace the default GRUB configuration file on a libreboot system,grub_cbfs}. 

@node Power Management Beeps on Thinkpads
@subsection 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:@* $ @strong{sudo ./nvramtool - power_management_beeps=Enable}@* $ @strong{sudo ./nvramtool - power_management_beeps=Disable}

Disable or enable beeps when battery is low:@* $ @strong{sudo ./nvramtool - low_battery_beep=Enable}@* $ @strong{sudo ./nvramtool - low_battery_beep=Disable}

A reboot is required, for these changes to take effect.

@node Get EDID - Find out the name of your LCD panel
@subsection Get EDID: Find out the name (model) of your LCD panel
Get the panel name with @strong{sudo get-edid | strings}@* Or look in @strong{/sys/class/drm/card0-LVDS-1/edid}

Alternatively you can use i2cdump. In Trisquel, this is in the package i2c-tools.@* $ @strong{sudo modprobe i2c-dev}@* $ @strong{sudo i2cdump -y 5 0x50} (you might have to change the value for -y)@* $ @strong{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.



@node About the libreboot project
@chapter About the libreboot project
GNU Libreboot is a free BIOS or UEFI replacement (@uref{https://www.gnu.org/philosophy/free-sw.html,free as in freedom}); libre @i{boot firmware} that initializes the hardware and starts a bootloader for your operating
system.

It's also an open source BIOS, but open source @uref{https://www.gnu.org/philosophy/open-source-misses-the-point.html,fails} to promote freedom; @i{please call libreboot @strong{@uref{https://www.gnu.org/philosophy/free-sw.html,free software}}}.

Since 14 May 2016, Libreboot is part of the @uref{https://www.gnu.org/,GNU project}.

Libreboot originally began during December 2013, as a commercial effort by the @uref{https://minifree.org/,Ministry of Freedom} to achieve @uref{https://www.fsf.org/resources/hw/endorsement/respects-your-freedom,RYF} endorsement for a modified ThinkPad X60 (the first system to ever be added to libreboot).

Back then, the name @emph{libreboot} didn't exist; the project was nameless, referring to itself as a @emph{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 @uref{http://coreboot.org/,coreboot} distribution (distro) with proprietary software removed, intended to be a @uref{https://www.fsf.org/about/what-is-free-software,free} (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 @uref{https://www.gnu.org/philosophy/free-sw.html,Free Software definition}.

Libreboot has many practical advantages over @uref{https://gnu.org/philosophy/proprietary/,proprietary} boot firmware, such as faster boot speeds and better security. You can @ref{GNU/Linux distributions,install GNU/Linux with encrypted /boot/}, @uref{http://www.coreboot.org/GRUB2#signed_kernels,verify GPG signatures on your kernel}, put a kernel in the flash chip and more.
@menu
* The libreboot project has three main goals::
* Libreboot is a coreboot distribution not a coreboot fork::
* Libreboot is a 'stable' version of coreboot::
@end menu

@node The libreboot project has three main goals
@section The libreboot project has three main goals:
@itemize
@item
@emph{@strong{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 @emph{Management Engine}. However, a lot of dedicated and talented individuals in coreboot work hard to replace these blobs whenever possible.
@item
@emph{@strong{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.
@item
@emph{@strong{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).
@end itemize

@node Libreboot is a coreboot distribution not a coreboot fork
@section 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 @emph{coreboot-libre}, to distinguish it as a component of @emph{libreboot}.

@node Libreboot is a 'stable' version of coreboot
@section Libreboot is a `stable' version of coreboot
@itemize
@item
Coreboot uses the @uref{https://en.wikipedia.org/wiki/Rolling_release,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.
@item
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.
@end itemize


@node How do I know what version I'm running?
@chapter How do I know what version I'm running?
If you are at least 127 commits after release 20150518 (commit message @emph{build/roms/helper: add version information to CBFS}) (or you have any @strong{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:@* @strong{cat (cbfsdisk)/lbversion}@* This will also work on non-release images (the version string is automatically generated, using @emph{git describe --tags HEAD}), built from the git repository. A file named @emph{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 @emph{lbversion} file by using the @emph{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 (@emph{libreboot.rom}, in this example):@* $ @strong{./cbfstool libreboot.rom extract -n lbversion -f lbversion}@* You will now have a file, named @emph{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 @emph{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:@* @strong{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: @pxref{Libreboot release information}. 

You can also check the documentation that came with your archives, and in @ref{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.


@node GNU Free Documentation License
@appendix GNU Free Documentation License

@include ../resources/licenses/gfdl-1.3.txt

@bye