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 © 2015 Paul Kocialkowski <contact@@paulk.fr>@*
Copyright © 2015 Alex David <opdecirkel@@gmail.com>@* Copyright © 2015 Patrick
"P. J." McDermott <pj@@pehjota.net>@* Copyright © 2015 Albin Söderqvist@*
Copyright © 2015 Jeroen Quint <jezza@@diplomail.ch>@*

Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.3 or any later version
published by the Free Software Foundation; with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found
at @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}

@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: the onboard NIC does not work when libreboot is installed. This is being
investigated by damo22 in the libreboot IRC channel.

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