libreboot
/
lbwww
1
0
Fork 0
Code Packages Projects Releases Activity

libreboot site 

new one
hslick-master
Leah Rowe 2021-05-18 13:21:48 +01:00
commit 501e77d996
149 changed files with 37900 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored Normal file
View File

@ -0,0 +1,3 @@
*.html
/news/index*
*feed.xml

4
site.cfg Normal file
View File

@ -0,0 +1,4 @@
TITLE="-T Libreboot"
CSS="--css /global.css"
DOMAIN="http://81.187.191.155/"
BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage

451
site/COPYING Normal file
View File

@ -0,0 +1,451 @@
GNU Free Documentation License
Version 1.3, 3 November 2008
Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
<https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible
for modifications made by others.
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein. The "Document", below,
refers to any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license if you
copy, modify or distribute the work in a way requiring permission
under copyright law.
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall
subject (or to related matters) and contains nothing that could fall
directly within that overall subject. (Thus, if the Document is in
part a textbook of mathematics, a Secondary Section may not explain
any mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License. If a
section does not fit the above definition of Secondary then it is not
allowed to be designated as Invariant. The Document may contain zero
Invariant Sections. If the Document does not identify any Invariant
Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License. A Front-Cover Text may
be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent.
An image format is not Transparent if used for any substantial amount
of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML, PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG. Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML, PostScript or PDF produced by some word
processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
The "publisher" means any person or entity that distributes copies of
the Document to the public.
A section "Entitled XYZ" means a named subunit of the Document whose
title either is precisely XYZ or contains XYZ in parentheses following
text that translates XYZ in another language. (Here XYZ stands for a
specific section name mentioned below, such as "Acknowledgements",
"Dedications", "Endorsements", or "History".) To "Preserve the Title"
of such a section when you modify the Document means that it remains a
section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document. These Warranty
Disclaimers are considered to be included by reference in this
License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has
no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no
other conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present
the full title with all words of the title equally prominent and
visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using
public has access to download using public-standard network protocols
a complete Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure
that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that
edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to
give them a chance to provide you with an updated version of the
Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add
to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section Entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the section all
the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements"
or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History"
in the various original documents, forming one section Entitled
"History"; likewise combine any sections Entitled "Acknowledgements",
and any sections Entitled "Dedications". You must delete all sections
Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other
documents released under this License, and replace the individual
copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the rules
of this License for verbatim copying of each of the documents in all
other respects.
You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert a
copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that
document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights
of the compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License does not
apply to the other works in the aggregate which are not themselves
derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole
aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions
of those notices and disclaimers. In case of a disagreement between
the translation and the original version of this License or a notice
or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve
its Title (section 1) will typically require changing the actual
title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense, or distribute it is void, and
will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license
from a particular copyright holder is reinstated (a) provisionally,
unless and until the copyright holder explicitly and finally
terminates your license, and (b) permanently, if the copyright holder
fails to notify you of the violation by some reasonable means prior to
60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, receipt of a copy of some or all of the same material does
not give you any rights to use it.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the
GNU Free Documentation License from time to time. Such new versions
will be similar in spirit to the present version, but may differ in
detail to address new problems or concerns. See
https://www.gnu.org/licenses/.
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation. If the Document
specifies that a proxy can decide which future versions of this
License can be used, that proxy's public statement of acceptance of a
version permanently authorizes you to choose that version for the
Document.
11. RELICENSING
"Massive Multiauthor Collaboration Site" (or "MMC Site") means any
World Wide Web server that publishes copyrightable works and also
provides prominent facilities for anybody to edit those works. A
public wiki that anybody can edit is an example of such a server. A
"Massive Multiauthor Collaboration" (or "MMC") contained in the site
means any set of copyrightable works thus published on the MMC site.
"CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
license published by Creative Commons Corporation, a not-for-profit
corporation with a principal place of business in San Francisco,
California, as well as future copyleft versions of that license
published by that same organization.
"Incorporate" means to publish or republish a Document, in whole or in
part, as part of another Document.
An MMC is "eligible for relicensing" if it is licensed under this
License, and if all works that were first published under this License
somewhere other than this MMC, and subsequently incorporated in whole or
in part into the MMC, (1) had no cover texts or invariant sections, and
(2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site
under CC-BY-SA on the same site at any time before August 1, 2009,
provided the MMC is eligible for relicensing.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:
Copyright (c) YEAR YOUR NAME.
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 is included in the section entitled "GNU
Free Documentation License".
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.

6
site/README Normal file
View File

@ -0,0 +1,6 @@
this is the website for libreboot.org
Refer to the libreboot website for information
This website is built using a static site generator named Panbash.
Refer to the Panbash documentation: see https://panbash.org/

99
site/contact.md Normal file
View File

@ -0,0 +1,99 @@
---
title: Contact
x-toc-enable: true
...
**TODO: mailing lists, mastodon server and peertube account.**
User support
============
IRC or Reddit are recommended, if you wish to ask for support (IRC recommended).
See below for information about IRC and Reddit.
Development discussion
======================
Mailing lists are planned for the future. For now, see notes
on [the Git page](git.md) for information about how to assist with development.
Instructions are also on that page for sending patches (via pull requests).
IRC chatroom
============
![](https://av.libreboot.org/logo/logo.svg){.imgright}
IRC is the main way to contact the Libreboot project. `#libreboot` on Freenode
IRC.
Webchat:
<https://webchat.freenode.net/?channels=libreboot>
Freenode is one of the oldest IRC networks, used for Free Software projects.
Find more about them here: <https://freenode.net/>
If you wish to connect using your preferred client (such as weechat or irssi),
the connection info is as follows:
* Server: `chat.freenode.net`
* Channel: `#libreboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
We recommend that you use port `6697` with TLS encryption enabled.
Here are some guides for various IRC clients:
Weechat
-------
<https://weechat.org/files/doc/stable/weechat_quickstart.en.html>
Irssi
-----
Couldn't find any guides on Freenode's website. Just use the above info.
Here is a guide for configuring SASL:
<https://freenode.net/kb/answer/irssi>
Hexchat
-------
Couldn't find any guides on Freenode's website, but this is a useful guide for
configuring SASL:
<https://freenode.net/kb/answer/hexchat>
Tor
---
You can use Tor, when connecting to Freenode. This may be beneficial, because
Freenode is censored in some countries. Read this article:
<https://freenode.net/kb/answer/chat>
Social media
============
Libreboot exists officially on many places.
Twitter and Mastodon
--------------------
News announcements: <https://twitter.com/libreboot/>
The founder and lead developer, Leah Rowe, is also on Twitter and Mastodon:
* <https://twitter.com/n4of7> (use nitter to avoid non-free JavaScript)
* <https://mas.to/@libreleah>
Leah can also be contacted by her email address:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Mostly used as a support channel, and also for news announcements:
<https://www.reddit.com/r/libreboot/>

422
site/contrib.md Normal file
View File

@ -0,0 +1,422 @@
---
title: Project contributors
x-toc-enable: true
...
This list does not necessarily reflect who is currently working on the project,
but it lists some people who have contributed to the project in meaningful ways.
If we forgot to mention you here, let us know and we'll add you. (or if
you don't want to be mentioned, let us know and we'll remove your
entry)
Information about who works on Libreboot, and how the project is run, can
be found on this page: [who.md](who.md)
You can know the history of the Libreboot project, simply by reading this page.
It goes into detail about all of the major contributions to the project, and in
general how the project was created (and who helped create it).
Leah Rowe
---------
**Founder of the Libreboot project, and currently the lead developer.** Leah
works on all aspects of Libreboot, such as:
* General management. Leah handles all outside contributions to Libreboot,
reviews pull requests, deals with bug reports, delegates tasks when necessary
or desirable. Leah controls the libreboot.org server infrastructure, hosted
in her lab (of course it runs Libreboot!)
* Leah has the final say on all decisions, taking input via discussion with
members of the public, mostly on IRC. Leah oversees releases of Libreboot,
and generally keeps the project going. Without Leah, there would be no Libreboot!
* The build system (lbmk, short for Libreboot Make). This is the automated build
system that sits at the heart of Libreboot; it downloads, patches, configures
and compiles the relevant components like coreboot, GNU GRUB and generates
the Libreboot ROM images that you can find in release archives.
* Upstream work on coreboot, when necessary (and other projects that Libreboot
uses). This means also working with people from outside of the Libreboot
project, to get patches merged (among other things) on the upstream projects
that Libreboot uses
* Providing user support on IRC
* *Commercial* user support via her company listed
on [the suppliers page](/suppliers.md)
Leah is also responsible for [osboot.org](https://osboot.org/) which is heavily
based on Libreboot, but with different project goals.
Other people are listed below, in alphabetical order:
Alyssa Rosenzweig
-----------------
Switched the website to use markdown in lieu of handwritten HTML and custom
PHP. **Former libreboot project maintainer (sysadmin for libreboot.org).**
Alyssa wrote the original static site generator (bash scripts converting
markdown to html, via pandoc) for libreboot.org. This static site generator has
now been heavily modified and forked into a formal project, by Leah Rowe:
<https://panbash.org/> (panbash is Leah's work, not Alyssa's, but it's based on
Alyssa's original work on the static site generator that Libreboot used to use;
the Libreboot website is now built with Panbash)
Andrew Robbins
--------------
Worked on large parts of Libreboot's build system and related documentation.
Andrew joined the Libreboot project as a full time developer during June 2017.
IRC nick `and_who` on #libreboot IRC. **Former libreboot project maintainer.**
Andrew was in charge of development for a rewrite of the Libreboot build system
which was later scrapped, but a lot of features were implemented in that build
system. The fundamental design of that new build system was no good, but aspects
of it are now being implemented in the old one; development resumed on the old
build system in late 2020, after the rewrite, which started in 2016, failed to
produce releases. The work on that rewrite has been *archived* for reference.
Andrew initially contributed a few fixes to Libreboot, and I, Leah Rowe, later
recruited him to be a full time developer. I greatly appreciate his contributions
to the Libreboot project.
Arthur Heymans
--------------
Merged a patch from coreboot into libreboot, enabling C3 and C4 power
states to work correctly on GM45 laptops. This was a long-standing issue
before Athur's contribution. Arthur also fixed VRAM size on i945 on
GM45 systems, allowing maximum VRAM allocation for the onboard GPUs on
these systems, another longstanding issue in libreboot. Contact **apvh**
in the \#libreboot IRC channel. **Former libreboot project maintainer**.
Arthur also did work on the Libreboot build system, when he was a member of the
project. He still works on coreboot, to this day, and Libreboot greatly
benefits from his work. His contributions to the coreboot project, and Libreboot,
are invaluable.
Damien Zammit
-------------
Maintains the Gigabyte GA-G41M-ES2L coreboot port, which is integrated
in libreboot. Also works on other hardware for the benefit of the
libreboot project. Contact **damo22** on the freenode IRC network. This
person's website is [zammit.org](http://www.zammit.org/). **Former libreboot
project maintainer.**
Damien didn't work directly on Libreboot itself, but he worked heavily with
Leah Rowe, integrating patches and new board ports into Libreboot, based on
Damien's upstream work on coreboot.
Denis Carikli
-------------
Based on the work done by Peter Stuge, Vladimir Serbineko and others in
the coreboot project, got native graphics initialization to work on the
ThinkPad X60, allowing it to be supported in libreboot. Denis gave
a lot of advice and helped found the libreboot project. Contact
**GNUtoo-irssi** in the \#libreboot IRC channel. Denis is also one of
the founders of the [Replicant](http://replicant.us/) project.
Denis was a mentor to Leah Rowe in the early days, when she founded the
Libreboot project. A lot of the decision decisions taken, especially with the
Libreboot build system (lbmk), were inspired from talks with Denis.
Denis taught Leah about registers used by Intel GPUs for backlight control. In
the early days, the ThinkPad X60 and T60 laptops in Libreboot did not have
backlight control working, so the brightness was always 100%. With Denis's help,
Leah was able to get backlight controls working by reverse engineering the
correct values to write in those registers. Based on this, a simple fix was
written in coreboot; however, the fix just wrote directly to the register and
didn't work with ACPI based brightness controls. Others in coreboot later
improved it, making ACPI-based backlight controls work properly, based on this
earlier work.
Jeroen Quint
------------
Contributed several fixes to the libreboot documentation, relating to
installing Parabola with full disk encryption on libreboot systems.
Contact **Jezza** in the \#libreboot IRC channel.
Joshua Gay
----------
Joshua is former FSF staff.
Joshua helped with the early founding of the Libreboot project, in his capacity
(at that time) as the FSF's licensing and compliance manager. It was his job to
review products sent into to the FSF for review; the FSF has a certification
program called *Respects Your Freedom* (RYF) where the FSF will promote your
company's products if it comes with all Free Software.
I, Leah Rowe, was initially just selling ThinkPad X60 laptops with regular
coreboot on them, and this included CPU microcode updates. At the time, I didn't
think much of that. Joshua contacted me, in his capacity at the FSF, and asked
if I would be interested in the FSF's RYF program; I was very surprised that the
FSF would take me seriously, and I said yes. This is what started the early
work on Libreboot. Joshua showed me all the problems my products had, and from
that, the solution was clear:
A project needed to exist, providing a fully free version of coreboot, without
any binary blobs. At the time (and this is still true today), coreboot was not
entirely free software and shipped with binary blobs by default. In particular,
CPU microcode updates were included by default, on all x86 machines. Working
with Joshua who reviewed my work, I created a fully free version of coreboot.
At first, it wasn't called Libreboot, and the work was purely intended for my
company (at that time called Gluglug) to be promoted by the FSF.
Joshua used his media connections at the FSF to heavily promote my work, and
on December 13th, 2013, the Libreboot project was born (but not called that).
Joshua made sure that everyone knew what I was doing!
A few months later, the name *Libreboot* was coined, and the domain name
*libreboot.org* was registered. At that point, the Libreboot project (in early
2014) was officially born. Once again, Joshua provided every bit of help he
could, heavily promoting the project and he even wrote this article on the FSF
website, announcing it:
<https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
Klemens Nanni
-------------
Made many fixes and improvements to the GRUB configuration used in
libreboot, and several tweaks to the build system. Contact **kl3** in
the \#libreboot IRC channel.
Leah Rowe initially helped Klemens get his project, autoboot, off the ground.
Autoboot (website autoboot.org) is no longer online, but was a fork of Libreboot
with different project goals; in late 2020, Leah Rowe decided to create her
own new fork of Libreboot called *osboot*, heavily inspired by Klemens's earlier
work. See: <https://osboot.org/>
The following is an archive of autoboot.org, from when it was online back in
2016: <http://web.archive.org/web/20160414205513/http://autoboot.org/> (the
autoboot website went offline a few months later, after Klemens abandoned the
project)
Lisa Marie Maginnis
-------------------
Lisa is a former sysadmin at the Free Software Foundation. In the early days of
the project, she provided Leah with a lot of technical advice. She initially
created the Libreboot IRC channel on Freenode, when Leah did not know how to
use IRC, and also handed +F founder status to Leah for the channel. As an FSF
sysadmin, it was Lisa's job to maintain a lot of the infrastructure used by
Libreboot; at the time, mailing lists on the GNU Savannah website were used by
the Libreboot project. Lisa was also the one who originally encouraged Leah to
have Libreboot join the GNU project (a decision that was later, rather
regrettably, reversed). When Paul Kocialkowski was a member of the project in
2016, she helped him get help from the FSF; he was the leader of the Replicant
project at the time, which had funding from the FSF, and the FSF authorized him
to use some of that funding for his work on Libreboot, thanks to Lisa's
encouragement while she worked at the FSF.
Lisa also stepped in when Leah Rowe missed her LibrePlanet 2016 talk. Leah was
scheduled to do a talk about Libreboot, but didn't show up in time. Lisa, along
with Patrick McDermott (former Libreboot developer, who was present at that
conference) did the talk in Leah's place. The talk was never recorded, but the
Free Software Foundation has these photos of that talk on their LibrePlanet
website (the woman with the blue hair is Lisa, and the long-haired dude with the
moustache is Patrick):
<https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
(archive link: <http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>)
<https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
(archive link: <http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>)
Fun fact: Patrick is also the lead developer of ProteanOS, an FSF-endorsed
embedded OS project: <http://proteanos.com/> (uses BusyBox and Linux-libre)
Leah Rowe ran *2* LibrePlanet workshops; one in 2015 and another in 2016, while
visiting Boston, MA, USA on both occasions to attend these conferences. These
workshops were for Libreboot installations. People came to both workshops, to
have Libreboot installed onto their computers. As FSF sysadmin, at that time,
Lisa provided all of the infrastructure and equipment used at those workshops.
Without her help, those workshops would have not been possible.
When the ASUS KGPE-D16 mainboard (high-end server board) was ported to Libreboot,
Leah, working with Timothy Pearson (the one who ported it), shared patches back
and forth with Lisa around mid 2016, mostly raminit patches, to get the board
running at the FSF offices. This work ultimately lead to a most wonderful
achievement:
The <https://www.gnu.org/> and <https://www.fsf.org/> websites now run on
Librebooted ASUS KGPE-D16 based servers, on a fully free GNU+Linux distro. This
means that the FSF now has full software freedom for their hosting infrastructure.
The FSF also provides access to this infrastructure for many other projects
(besides GNU projects); for example, Trisquel uses a D16 provided by the FSF
for their development server used for building Trisquel releases and testing
changes to the Trisquel GNU+Linux distribution. Trisquel is a fully free
GNU+Linux distribution, heavily promoted by the FSF.
Lisa was a strong supporter of Libreboot in the very early days of the project,
and her contributions were invaluable. I, Leah Rowe, owe her a debt of gratitude.
Marcus Moeller
--------------
Made the libreboot logo.
Patrick "P. J." McDermott
---------------------------
Patrick also did a lot of research and wrote the libreboot FAQ section
relating to the [Intel Management Engine](../faq.md#intelme), in addition
to making several improvements to the build system in libreboot. **Former
libreboot project maintainer.**
In 2016, Leah Rowe ran a Libreboot installation workshop at the FSF's
LibrePlanet conference. Working alongside Leah, Patrick helped run the workshop
and assisted with installing Libreboot onto people's machines.
Paul Kocialkowski
-----------------
Ported the ARM (Rockchip RK3288 SoC) based *Chromebook* laptops to
libreboot. Also one of the main [Replicant](http://www.replicant.us/)
developers. Contact Paul on the libreboot IRC channel by the alias
**paulk** or **paulk-&lt;hostname&gt;** (hostname is variable). **Former
libreboot project maintainer.**
Paul Menzel
-----------
Investigated and fixed a bug in coreboot on the ThinkPad X60/T60 exposed
by Linux kernel 3.12 and up, which caused 3D acceleration to stop
working and video generally to become unstable. The issue was that coreboot,
when initializing the Intel video chipset, was mapping *GTT Stolen Memory* in
the wrong place, because the code was based on kernel code and the Linux kernel
had the same bug. When Linux fixed it, it exposed the same bug in coreboot.
Paul worked with Libreboot on
this, sending patches to test periodically until the bug was fixed
in coreboot, and then helped her integrate the fix in libreboot. Contact
**PaulePanter** in the \#libreboot IRC channel.
Peter Stuge
-----------
Helped write the [FAQ section about DMA](../faq.md#hddssd-firmware), and provided
general advice in the early days of the project. Peter was a coreboot developer
in those days, and a major developer in the *libusb* project (which flashrom
makes heavy use of).
Peter also wrote the *bucts* utility used to set Backup Control (BUC) Top Swap
(TS) bit on i945 laptops such as ThinkPad X60/T60, which is useful for a
workaround to flash Libreboot without using external hardware; on this machine,
with Lenovo BIOS present, it's possible to flash everything except the main
bootblock, but Intel platforms have 2 bootblocks, and you specify which one is
to be used by setting the TS bit. You then boot with only one bootblock flashed
(by the coreboot project's bootblock on that machine), and afterwards you reset
bucts before flashing the ROM again, to flash the main bootblock. Libreboot
hosts a copy of his work, because his website hosting bucts is no longer
responsive.
Steve Shenton
-------------
Steve did the early reverse engineering work on the Intel Flash Descriptor used
by ICH9M machines such as ThinkPad X200. He created a C struct defining (using
bitfields in C) this descriptor region. With some clever tricks, he was able to
discover the existence of a bit in the descriptor for *disabling* the Intel ME
(management engine) on those platforms.
His initial proof of concept only defined the descriptor, and would do this:
* Read the default descriptor and GbE regions from a Lenovo X200 ROM (default
firmware, not coreboot)
* Disable the ME, by setting 2 bits in the descriptor
* Disable the ME region
* Move descriptor+GbE (12KiB in total) next to each other
* Allocate the remaining flash space to the BIOS region
* Generated the 12KiB descriptor+GbE region, based on this, to insert into a
coreboot ROM image.
In the early days, before Libreboot supported GM45+ICH9M platforms such as
ThinkPad X200/T400, you could use those machines but to avoid the Intel ME you
had to flash it without a descriptor region. This worked fine in those days,
because the ME only handled TPM and AMT on those machines, and the system would
work normally, but that Intel Flash Descriptor also handles the Intel GbE NVM
region in flash, which is used for the Intel Gigabit Ethernet interface.
So you either had Intel ME, or no ethernet support. Steve figured out how to
disable the Intel ME via 2 toggle bits in the descriptor, and also how to
remove the Intel ME region from flash.
Based on his research, I, Leah Rowe, working alongside Steve, also reverse
engineered the layout of the Intel GbE NVM (non-volatile memory) region in the
boot flash. This region defines configuration options for the onboard Intel
GbE NIC, if present.
Based on this, I was able to take Steve's initial proof of concept and write
the `ich9gen` utility, which generates an Intel Flash Descriptor and GbE NVM
region, from scratch, without an Intel ME region defined. It is this tool,
the `ich9gen` tool, that Libreboot uses to provide ROM images for GM45+ICH9M
platforms (such as ThinkPad X200/T400/T500/W500), with a fully functional
descriptor and functional Gigabit Ethernet, but *without* needing Intel
Management Engine (ME) firmware, thus making those machines *libre* (the ME
is fully disabled, when you use a descriptor+gbe image generated by `ich9gen`).
With *my* `ich9gen` tool (Steve's tool was called `ich9deblob`), you didn't
need a dump of the original Lenovo BIOS firmware anymore! I could not have
written this tool, without Steve's initial proof of concept. I worked with him,
extensively, for many months. All GM45+ICH9M support (X200, T400, etc) in
Libreboot is made possible because of the work he did, back in 2014.
Swift Geek
----------
Contributed a patch for ich9gen to generate 16MiB descriptors. Contact
**swiftgeek** in the IRC channel. **Former libreboot project maintainer.**
After that, Swift Geek slowly became more involved until he became a full time
developer. Swift Geeks contributions were never really in the form of *code*,
but what he lacked in code, he made up for in providing excellent support, both
to users and other developers, helping others learn more about technology at a
low level.
When Swift Geek was a member of the project, his role was largely providing
user support (in the IRC channel), and conducting research. Swift Geek knows a
lot about hardware. Swift Geek also did some upstream development on GNU GRUB.
Swift Geek has provided technical advice on numerous occasions, to Leah Rowe,
and helped her to improve her soldering skills in addition to teaching her
some repair skills, to the point where she can now repair most faults on
ThinkPad mainboards (while looking at the schematics and boardview).
Working alongside Andrew Robbins, Swift Geek oversaw the development of a
rewritten Libreboot build system
which was later scrapped, but a lot of features were implemented in that build
system. The fundamental design of that new build system was no good, but aspects
of it are now being implemented in the old one; development resumed on the old
build system in late 2020, after the rewrite, which started in 2016, failed to
produce releases. The work on that rewrite has been *archived* for reference.
I, Leah Rowe, greatly appreciate Swift Geek's contributions to the Libreboot
project.
Timothy Pearson
---------------
Ported the ASUS KGPE-D16 board to coreboot for the company Raptor
Engineering of which Timothy is the CEO.
Timothy maintains this code in coreboot,
helping the project with the libreboot integration for it. This person's
contact details are on the raptor site, or you can ping **tpearson** on
the freenode IRC network.
Vladimir Serbinenko
-------------------
Ported many of the thinkpads supported in libreboot, to coreboot, and
made many fixes in coreboot which benefited the libreboot project.
Contact **phcoder** in the \#coreboot IRC channel on freenode.
Vladimir wrote a lot of the original video initialization code used by various
Intel platforms in Libreboot, when flashing it (now rewritten
by others in Ada, for libgfxinit in coreboot, but originally it was written in
C and included directly in coreboot; libgfxinit is a 3rdparty submodule of
coreboot).

130
site/docs/bsd/freebsd.md Normal file
View File

@ -0,0 +1,130 @@
---
title: How to install FreeBSD on x86 GNU GRUB payload
x-toc-enable: true
...
FreeBSD might show graphical corruption during bootup. You can fix this by
altering the order in which kernel modules/drivers are loaded. First, try moving
video to an earlier stage on the boot process, or try moving it to a later stage
instead. With this, you should be able to get a working display.
freebsd.img is the installation image for FreeBSD. Adapt the filename
accordingly, for whatever FreeBSD version you use.
Prepare the USB drive (in FreeBSD)
----------------------------------
[This page](https://www.freebsd.org/doc/handbook/bsdinstall-pre.html) on
the FreeBSD website shows how to create a bootable USB drive for
installing FreeBSD. Use the *dd* on that page.
Prepare the USB drive (in NetBSD)
---------------------------------
[This
page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
on the NetBSD website shows how to create a NetBSD bootable USB drive
from within NetBSD itself. You should use the *dd* method documented
there; you can use this with any ISO, including FreeBSD.
Prepare the USB drive (in LibertyBSD or OpenBSD)
------------------------------------------------
If you downloaded your ISO on a LibertyBSD or OpenBSD system, here is
how to create the bootable FreeBSD USB drive:
Connect the USB drive. Check dmesg:
dmesg | tail
Check to confirm which drive it is, for example, if you think its sd3:
disklabel sd3
Check that it wasn't automatically mounted. If it was, unmount it. For
example:
doas umount /dev/sd3i
dmesg told you what device it is. Overwrite the drive, writing the
FreeBSD installer to it with dd. For example:
doas dd if=freebsd.img of=/dev/rsdXc bs=1M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Prepare the USB drive (in GNU+Linux)
------------------------------------
If you downloaded your ISO on a GNU+Linux system, here is how to create
the bootable FreeBSD USB drive:
Connect the USB drive. Check dmesg:
dmesg
Check lsblk to confirm which drive it is:
lsblk
Check that it wasn't automatically mounted. If it was, unmount it. For
example:
sudo umount /dev/sdX\*
umount /dev/sdX\*
dmesg told you what device it is. Overwrite the drive, writing your
distro ISO to it with dd. For example:
sudo dd if=freebsd.img of=/dev/sdX bs=8M; sync
dd if=freebsd.img of=/dev/sdX bs=8M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Installing FreeBSD without full disk encryption
-----------------------------------------------
Press C in GRUB to access the command line:
grub> kfreebsd (usb0,gpt3)/boot/kernel/kernel
grub> set FreeBSD.vfs.mountfrom=ufs:/dev/da1p3\
grub> boot
It will start booting into the FreeBSD installer. Follow the normal
process for installing FreeBSD.
Installing FreeBSD with full disk encryption
--------------------------------------------
TODO
Booting
-------
TODO
Configuring Grub
----------------
TODO
Troubleshooting
===============
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 FreeBSD
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 corebootfb ROM images. There ROM images
have `corebootfb` in the file name, and they start in a high resolution frame
buffer, provided by coreboot's `libgfxinit` library.
won't boot...something about file not found
---------------------------------------------
Your device names (i.e. usb0, usb1, sd0, sd1, wd0, ahci0, hd0, etc) and
numbers may differ. Use TAB completion.

80
site/docs/bsd/index.md Normal file
View File

@ -0,0 +1,80 @@
---
title: BSD operating systems
x-toc-enable: true
...
This section is largely x86-centric, pertaining to use of BSD operating systems.
Although not as popular, BSD systems are also (in most cases) *Free Software*,
but they are non-copyleft.
Libreboot is capable of booting many BSD systems. This section mostly documents
the peculiarities of Libreboot as it pertains to BSD; you can otherwise refer to
the official documentation for whatever BSD system you would like to use.
Video modes
===========
For BSD systems, it is desirable that you boot in *text mode*. ROM images
with `txtmode` in the file name, on x86 systems, boot up with int10h text mode
in use. This is the most "compatible" option, and BSD operating systems have
excellent support for text-mode startup. Many of them also support *kernel mode
setting* (KMS) nowadays, which you *need* if you want a graphical desktop on
the X window system. The reason is that Libreboot does not currently implement
int10h VGA modes on x86 systems. However, basic video initialization is
provided on all platforms (int10h text mode, or coreboot framebuffer).
Combined with the use of SeaBIOS payload, BSD systems (and any other OS that
can boot in text mode) will *just work*. If your BSD system supports kernel
mode setting, it can set up a framebuffer without making use of int10h VGA
modes. In this case, the driver (e.g. Intel video driver) will set modes
directly, and implement its own framebuffer.
Booting with a coreboot framebuffer will also work well on most BSD systems.
These ROM images have `corebootfb` in the filename, on recent Libreboot releases.
In this setup, you should make sure that your BSD system has a `corebootfb`
driver (to make use of the coreboot framebuffer), but when switching to X, your
video driver (e.g. Intel video driver) may already support kernel mode setting
which means that the coreboot framebuffer will no longer be used at that point.
Booting BSD
===========
On x86 platforms, Libreboot currently provides the choice of GNU GRUB and/or
SeaBIOS payload. You can use *either* payload, to boot BSD operating systems.
SeaBIOS payload
---------------
It is highly recommended that you use the SeaBIOS payload. ROM images are
available in the latest Libreboot release, which start with the SeaBIOS payload.
The ROM images with GNU GRUB *also* have SeaBIOS available in the boot menu.
GNU GRUB, when compiled as a coreboot payload, runs on *bare metal* and it can
boot any other coreboot payload if you use the `chainloader` command.
The way to use SeaBIOS is fairly self-explanatory. SeaBIOS functions the way
you would expect on a typical computer. Libreboot currently lacks any sort of
documentation for SeaBIOS, but you can refer to their
website: <https://seabios.org/SeaBIOS>
SeaBIOS is *especially* recommended if you're doing an encrypted installation.
The benefit to using SeaBIOS is that it's basically more reliable. For example,
ZFS support is less reliable in GRUB, but a FreeBSD system booted in SeaBIOS
would work just fine because you'd be using FreeBSD's own bootloader in that
instance.
GNU GRUB payload
----------------
GRUB can directly boot many BSD kernels, but support for this is quite unreliable
compared to its support for booting Linux kernels. However, you *can* use GRUB.
When you use GNU GRUB directly, in this way, the various BSD bootloaders are
bypassed entirely.
We have separate pages for each BSD system:
* [How to install NetBSD on x86 GNU GRUB payload](netbsd.md)
* [How to install OpenBSD on x86 GNU GRUB payload](openbsd.md)
* [How to install FreeBSD on a x86 GNU GRUB payload](freebsd.md)

148
site/docs/bsd/netbsd.md Normal file
View File

@ -0,0 +1,148 @@
---
title: How to install NetBSD on x86 GNU GRUB payload
x-toc-enable: true
...
GRUB supports booting NetBSD kernels directly. However, you're better off
simply using the SeaBIOS payload; BSD works well with BIOS or UEFI setups.
GRUB is acceptable for booting unencrypted BSD installations. However,
encrypted BSD installations will probably require the use of SeaBIOS/Tianocore.
Prepare the USB drive (in NetBSD)
---------------------------------
[This
page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
on the NetBSD website shows how to create a NetBSD bootable USB drive
from within NetBSD itself. You should use the *dd* method documented
there.
Prepare the USB drive (in FreeBSD)
----------------------------------
[This page](https://www.freebsd.org/doc/handbook/bsdinstall-pre.html) on
the FreeBSD website shows how to create a bootable USB drive for
installing FreeBSD. Use the *dd* on that page. You can also use the same
instructions with a NetBSD ISO image.
Prepare the USB drive (in OpenBSD or NetBSD)
-----------------------------------------------
If you downloaded your ISO on a OpenBSD or NetBSD system, here is how
to create the bootable NetBSD USB drive:
Connect the USB drive. Check dmesg:
dmesg | tail
Check to confirm which drive it is, for example, if you think its sd3:
disklabel sd3
Check that it wasn't automatically mounted. If it was, unmount it. For
example:
doas umount /dev/sd3i
dmesg told you what device it is. Overwrite the drive, writing the
NetBSD installer to it with dd. For example:
doas netbsd.iso of=/dev/rsdXc bs=1M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Prepare the USB drive (in GNU+Linux)
------------------------------------
If you downloaded your ISO on a GNU+Linux system, here is how to create
the bootable NetBSD USB drive:
Connect the USB drive. Check dmesg:
dmesg
Check lsblk to confirm which drive it is:
lsblk
Check that it wasn't automatically mounted. If it was, unmount it. For
example:
sudo umount /dev/sdX\*
umount /dev/sdX\*
dmesg told you what device it is. Overwrite the drive, writing your
distro ISO to it with dd. For example:
sudo dd if=install60.fs of=/dev/sdX bs=8M; sync
dd if=netbsd.iso of=/dev/sdX bs=8M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Installing NetBSD without full disk encryption
----------------------------------------------
You might have to use an external USB keyboard during the installation.
Press C to access the GRUB terminal.
grub> knetbsd -r sd0a (usb0,netbsd1)/netbsd
grub> boot
It will start booting into the NetBSD installer. Follow the normal
process for installing NetBSD.
Installing NetBSD with full disk encryption
-------------------------------------------
TODO
Booting
-------
Press C in GRUB to access the command line:
grub> knetbsd -r wd0a (ahci0,netbsd1)/netbsd
grub> boot
NetBSD will start booting. Yay!
Configuring Grub
----------------
If you don't want to drop to the GRUB command line and type in a
command to boot NetBSD every time, you can create a GRUB configuration
that's aware of your NetBSD installation and that will automatically be
used by libreboot.
On your NetBSD root partition, create the `/grub` directory and add
the file `libreboot_grub.cfg` to it. Inside the
`libreboot_grub.cfg` add these lines:
default=0
timeout=3
menuentry "NetBSD" {
knetbsd -r wd0a (ahci0,netbsd1)/netbsd
}
The next time you boot, you'll see the old Grub menu for a few seconds,
then you'll see the a new menu with only NetBSD on the list. After 3
seconds NetBSD will boot, or you can hit enter to boot.
Troubleshooting
===============
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 NetBSD
it can be problematic when they are trying to switch to a framebuffer
because it doesn't exist.
won't boot...something about file not found
---------------------------------------------
Your device names (i.e. usb0, usb1, sd0, sd1, wd0, ahci0, hd0, etc) and
numbers may differ. Use TAB completion.

180
site/docs/bsd/openbsd.md Normal file
View File

@ -0,0 +1,180 @@
---
title: How to install OpenBSD on x86 GNU GRUB payload
x-toc-enable: true
...
This guide is written for OpenBSD 6.1, but it can be adapted easily for other
versions (of OpenBSD).
If you want an encrypted install, use SeaBIOS instead of GRUB and go here:
<https://www.openbsd.org/faq/faq4.html> (official installation guide, which
says how to use encryption)
GRUB supports booting OpenBSD kernels directly. However, you're better off
simply using the SeaBIOS payload; BSD works well with BIOS or UEFI setups.
GRUB is acceptable for booting unencrypted BSD installations. However,
encrypted BSD installations will probably require the use of SeaBIOS/Tianocore.
install61.fs is the installation image for OpenBSD 6.1. Adapt the
filename accordingly, for a different OpenBSD version or LibertyBSD.
Prepare the USB drive (in LibertyBSD or OpenBSD)
------------------------------------------------
If you downloaded your ISO on a LibertyBSD or OpenBSD system, here is
how to create the bootable LibertyBSD/OpenBSD USB drive:
Connect the USB drive and check the system message buffer:
dmesg | tail
Check to confirm which drive it is, for example, if you think it's `sd3`:
disklabel sd3
Check that it wasn't automatically mounted. If it was, unmount it:
doas umount /dev/sd3i
Now write the OpenBSD installer to the drive with `dd`:
doas dd if=install60.fs of=/dev/rsdXc bs=1M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Prepare the USB drive (in NetBSD)
---------------------------------
[This
page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
on the NetBSD website shows how to create a NetBSD bootable USB drive
from within NetBSD itself. You should use the `dd` method documented
there. This will also work with the OpenBSD image.
Prepare the USB drive (in FreeBSD)
----------------------------------
[This page](https://www.freebsd.org/doc/handbook/bsdinstall-pre.md) on
the FreeBSD website shows how to create a bootable USB drive for
installing FreeBSD. Use the `dd` on that page. You can also use the same
instructions with a OpenBSD ISO image.
Prepare the USB drive (in GNU+Linux)
------------------------------------
If you downloaded your ISO on a GNU+Linux system, here is how to create
the bootable OpenBSD USB drive:
Connect the USB drive. Check dmesg:
dmesg
Check lsblk to confirm which drive it is:
lsblk
Check that it wasn't automatically mounted. If it was, unmount it. For
example:
sudo umount /dev/sdX\*
umount /dev/sdX\*
dmesg told you what device it is. Overwrite the drive, writing your
distro ISO to it with dd. For example:
sudo dd if=install61.fs of=/dev/sdX bs=8M; sync
dd if=install61.fs of=/dev/sdX bs=8M; sync
You should now be able to boot the installer from your USB drive.
Continue reading, for information about how to do that.
Installing OpenBSD without full disk encryption
-----------------------------------------------
Press C in GRUB to access the command line:
grub> kopenbsd (usb0,openbsd1)/6.1/amd64/bsd.rd
grub> boot
It will start booting into the OpenBSD installer. Follow the normal
process for installing OpenBSD.
Installing OpenBSD with full disk encryption
--------------------------------------------
Not working. You can modify the above procedure (installation w/o
encryption) to install OpenBSD using full disk encryption, and it
appears to work, except that it's not yet clear how to actually *boot* an
OpenBSD+FDE installation using osboot+Grub2. If you get it working,
please let us know.
If booting in text mode (framebuffer mode might also work), it might be
possible to chainload the OpenBSD or LibertyBSD bootloader from the MBR
section on the internal storage device. This way, it would be possible
to boot with an encrypted OpenBSD or LibertyBSD installation. Please let
us know (contact details are on the osboot homepage) if you get it
working this way.
Alternatively, it would be good to port OpenBSD either natively as a
coreboot payload, or port it to libpayload (payload library in coreboot;
it has a basic C library and a few functions for certain operations e.g.
text/bitmap). *This would be ideal, because then it would be possible
to boot a truly fully encrypted OpenBSD or LibertyBSD installation, by
putting everything in the flash chip.*
Alternatively, modifying GRUB to support booting fully encrypted OpenBSD
installations would be possible, but probably not feasible; it's an
alien codebase to the OpenBSD project, not tightly integrated and the
OpenBSD bootloader already works.
Booting
-------
Press C in GRUB to access the command line:
grub> kopenbsd -r sd0a (ahci0,openbsd1)/bsd
grub> boot
OpenBSD will start booting. Yay!
Configuring Grub
----------------
If you don't want to drop to the GRUB command line and type in a
command to boot OpenBSD every time, you can create a GRUB configuration
that's aware of your OpenBSD installation and that will automatically
be used by osboot.
On your OpenBSD root partition, create the `/grub` directory and add the file
`osboot_grub.cfg` to it. Inside the `osboot_grub.cfg` add these lines:
default=0
timeout=3
menuentry "OpenBSD" {
kopenbsd -r sd0a (ahci0,openbsd1)/bsd
}
If your OpenBSD installation uses a GPT scheme, use the `gpt4` partition
instead of `openbsd1`.
The next time you boot, you'll see the old Grub menu for a few seconds,
then you'll see the a new menu with only OpenBSD on the list. After 3
seconds OpenBSD will boot, or you can hit enter to boot.
Troubleshooting
===============
Most of these issues occur when using osboot 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 OpenBSD
it can be problematic when they are trying to switch to a framebuffer
because it doesn't exist.
Won't boot...something about file not found
---------------------------------------------
Your device names (i.e. usb0, usb1, sd0, sd1, wd0, ahci0, hd0, etc) and
numbers may differ. Use TAB completion.

270
site/docs/build/index.md vendored Normal file
View File

@ -0,0 +1,270 @@
---
title: Build from source
x-toc-enable: true
...
Libreboot's build system is named `lbmk`, short for `Libreboot Make`, and this
document describes how to use it. With this guide, you can know how to compile
Libreboot from the available source code.
This version, if hosted live on libreboot.org, assumes that you are using
the `lbmk` git repository, which
you can download using the instructions on [the code review page](../../git.md).
If you're using a release archive of Libreboot, please refer to the
documentation included with *that* release. Libreboot releases are only intended
as *snapshots*, not for development. For proper development, you should always
be working directly in the Libreboot git repository.
The following document describes how `lbmk` works, and how you can make changes
to it: [Libreboot maintenance manual](../maintain/)
Git
===
Libreboot's build system uses Git, extensively. You should perform the steps
below, *even if you're using a release archive*.
Before you use the build system, please know: the build system itself uses
Git extensively, when downloading software like coreboot and patching it.
You should make sure to initialize your Git properly, before you begin or else
the build system will not work properly. Do this:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Change the name and email address to whatever you want, when doing this.
You may also want to follow more of the steps here:
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>
Python
======
Python 2 *and* 3 are used by different parts of the build system, not directly
but because certain projects Libreboot depends upon uses it.
You should have this configuration on your OS:
python
python2
python3
Running `python` should give you python 3.x.
Running `python2` should give you python 2.x.
Running `python3` should give you python 3.x.
Therefore, you should install both python2 and python3 in your distro.
GNU Make
========
Libreboot Make includes a file called `Makefile`. You can still use
the `lbmk` build system directly, or you can use GNU Make. The `Makefile`
simply runs `lbmk` commands. However, using `lbmk` directly will offer you
much more flexibility; for example, the Makefile currently cannot build single
ROM images (it just builds all of them, for all boards).
You must ensure that all build dependencies are installed. If you're running
Ubuntu or similar distribution (Debian, Trisquel, etc) you can do this:
sudo make install-dependencies-ubuntu
Now, simply build the coreboot images like so:
make
This single command will build ROM images for *every* board integrated in
Libreboot. If you only wish to build a limited set, you can use `lbmk` directly:
./build libreboot roms x200_8mb
You can specify more than one argument:
./build libreboot roms x200_8mb x60
ROM images appear under the newly created `bin/` directory in the build system.
For other commands, simply read the `Makefile` in your favourite text editor.
The `Makefile` is simple, because it merely runs `lbmk` commands, so it's very
easy to know what commands are available by simply reading it.
Standard `clean` command available (cleans all modules except `crossgcc`):
make clean
To clean your `crossgcc` builds:
make crossgcc-clean
To build release archives:
make release
Build without using GNU Make
============================
The `Makefile` is included just for *compatibility*, so that someone who
instictively types `make` will get a result.
Actual development/testing is always done using `lbmk` directly, and this
includes when building from source. Here are some instructions to get you
started:
First, install build dependencies
---------------------------------
Libreboot includes a script that automatically installs apt-get dependencies
in Ubuntu 20.04. It works well in other apt-get distros (such as Trisquel and
Debian):
sudo ./build dependencies ubuntu2004
Technically, any GNU+Linux distribution can be used to build Libreboot.
However, you will have to write your own script for installing build
dependencies.
Libreboot Make (lbmk) automatically runs all necessary commands; for example
`./build payload grub` will automatically run `./build module grub` if the
required utilities for GRUB are not built, to produce payloads.
As a result, you can now (after installing the correct build dependencies) run
just a single command, from a fresh Git clone, to build the ROM images:
./build libreboot roms
or even just build specific ROM images, e.g.:
./build libreboot roms x60
If you wish to build payloads, you can also do that. For example:
./build payload grub
./build payload seabios
Previous steps will be performed automatically. However, you can *still* run
individual parts of the build system manually, if you choose. This may be
beneficial when you're making changes, and you wish to test a specific part of
lbmk.
Therefore, if you only want to build ROM images, just do the above. Otherwise,
please continue reading!
Second, download all of the required software components
--------------------------------------------------------
If you didn't simply run `./build libreboot roms` (with or without extra
arguments), you can still perform the rest of the build process manually. Read
on! You can read about all available scripts in `lbmk` by reading
the [Libreboot maintenance manual](../maintain/); lbmk is designed to be modular
which means that each script *can* be used on its own (if that's not true, for
any script, it's a bug that should be fixed).
It's as simple as that:
./download all
The above command downloads all modules defined in the Libreboot build system.
However, you can download modules individually.
This command shows you the list of available modules:
./download list
Example of downloading an individual module:
./download coreboot
./download seabios
./download grub
./download flashrom
Third, build all of the modules:
--------------------------------
Building a module means that it needs to have already been downloaded.
Currently, the build system does not automatically do pre-requisite steps
such as this, so you must verify this yourself.
Again, very simple:
./build module all
This builds every module defined in the Libreboot build system, but you can
build modules individually.
The following command lists available modules:
./build module list
Example of building specific modules:
./build module grub
./build module seabios
./build module flashrom
Commands are available to *clean* a module, which basically runs make-clean.
You can list these commands:
./build clean list
Clean all modules like so:
./build clean all
Example of cleaning specific modules:
./build clean grub
./build clean cbutils
Fourth, build all of the payloads:
---------------------------------
Very straight forward:
./build payload all
You can list available payloads like so:
./build payload list
Example of building specific payloads:
./build payload grub
./build payload seabios
The build-payload command is is a prerequsite for building ROM images.
Fifth, build the ROMs!
----------------------
Run this command:
./build libreboot roms
Each board has its own configuration in `lbmk` under `resources/coreboot/`
which specifies which payloads are supported.
By default, all ROM images are built, for all boards. If you wish to build just
a specific board, you can specify the board name based on the directory name
for it under `resources/coreboot/`. For example:
./build libreboot roms x60
Board names, like above, are the same as the directory names for each board,
under `resources/coreboot/` in the build system.
That's it!
If all went well, ROM images should be available to you under bin/

184
site/docs/depthcharge/index.md Normal file
View File

@ -0,0 +1,184 @@
---
title: Depthcharge payload
x-toc-enable: true
...
TODO: NUKE. depthcharge was dropped in recent releases.
TODO: replace with uboot information. ARM has been dropped for now
NOTE: this only applies to the older Libreboot 20160907 release
TODO: NUKE! (this info is in the documentation provided by Libreboot 20160907)
This section relates to the depthcharge payload used in libreboot.
CrOS security model
===================
CrOS (Chromium OS/Chrome OS) devices such as Chromebooks implement a strict
security model to ensure that these devices do not become compromised, that is
implemented as the verified boot (vboot) reference, most of which is executed
within depthcharge. A detailed overview of the CrOS security model is available
on the dedicated page.
In spite of the CrOS security model, depthcharge won't allow booting kernels
without verifying their signature and booting from external media or legacy
payload unless explicitly allowed: see [configuring verified boot
parameters](#configuring_verified_boot_parameters).
Developer mode screen
=====================
The developer mode screen can be accessed in depthcharge when developer mode is
enabled. Developer mode can be enabled from the recovery mode screen.
It allows booting normally, booting from internal storage, booting from
external media (when enabled), booting from legacy payload (when enabled),
showing information about the device and disabling developer mode.
Holding the developer mode screen
---------------------------------
As instructed on the developer mode screen, the screen can be held by pressing
*Ctrl + H* in the first 3 seconds after the screen is shown. After that delay,
depthcharge will resume booting normally.
Booting normally
----------------
As instructed on the developer mode screen, a regular boot will happen after *3
seconds* (if developer mode screen is not held).
The default boot medium (internal storage, external media, legacy payload) is
shown on screen.
Booting from different mediums
------------------------------
Depthcharge allows booting from different mediums, when they are allowed (see
[configuring verified boot parameters](#configuring_verified_boot_parameters)
to enable or disable boot mediums).
As instructed on the developer mode screen, booting from various mediums can be
triggered by pressing various key combinations:
- Internal storage: *Ctrl + D*
- External media: *Ctrl + U* (when enabled)
- Legacy payload: *Ctrl + L* (when enabled)
Showing device information
--------------------------
As instructed on the developer mode screen, showing device information can be
triggered by pressing *Ctrl + I* or *Tab*. Various information is shown,
including vboot non-volatile data, TPM status, GBB flags and key hashes.
Warnings
--------
The developer mode screen will show warnings when:
- Booting kernels without verifying their signature is enabled
- Booting from external media is enabled
- Booting legacy payloads is enabled
Recovery mode screen
====================
The recovery mode screen can be accessed in depthcharge, by pressing *Escape +
Refresh + Power* when the device is off.
It allows recovering the device from a bad state by booting from a trusted
recovery media. When accessed with the device in a good state, it also allows
enabling developer mode.
Recovering from a bad state
---------------------------
When the device fails to verify the signature of a piece of the boot software
or when an error occurs, it is considered to be in a bad state and will
instruct the user to reboot to recovery mode.
Recovery mode boots using only software located in write-protected memory, that
is considered to be trusted and safe.
Recovery mode then allows recovering the device by booting from a trusted
recovery media, that is automatically detected when recovery mode starts. When
no external media is found or when the recovery media is invalid, instructions
are shown on screen.
Trusted recovery media are external media (USB drives, SD cards, etc) that hold
a kernel signed with the recovery key.
Google provides images of such recovery media for Chrome OS (which are not
advised to users as they contain proprietary software).
They are signed with Google's recovery keys, that are pre-installed on the
device when it ships.
When replacing the full flash of the device, the pre-installed keys are
replaced. When the recovery private key is available (e.g. when using
self-generated keys), it can be used to sign a kernel for recovery purposes.
Enabling developer mode
-----------------------
As instructed on the recovery mode screen, developer mode can be enabled by
pressing *Ctrl + D*. Instructions to confirm enabling developer mode are then
shown on screen.
Configuring verified boot parameters
====================================
Depthcharge's behavior relies on the verified boot (vboot) reference
implementation, that can be configured with parameters stored in the verified
boot non-volatile storage.
These parameters can be modified with the `crossystem` tool, that requires
sufficient privileges to access the verified boot non-volatile storage.
`crossystem` relies on `mosys`, that is used to access the verified boot
non-volatile storage on some devices. `crossystem` and `mosys` are both free
software and their source code is made available by Google:
[crossystem](https://chromium.googlesource.com/chromiumos/platform/vboot_reference/).
[mosys](https://chromium.googlesource.com/chromiumos/platform/mosys/).
These tools are not distributed along with Libreboot yet. However, they are
preinstalled on the device, with ChromeOS.
Some of these parameters have the potential of *weakening the security of the
device*. In particular, disabling kernels signature verification, external
media boot and legacy payload boot can weaken the security of the device.
The following parameters can be configured:
Kernels signature verification:
crossystem dev_boot_signed_only=1 # enable
crossystem dev_boot_signed_only=0 # disable
External media boot:
crossystem dev_boot_usb=1 # enable
crossystem dev_boot_usb=0 # disable
Legacy payload boot:
crossystem dev_boot_legacy=1 # enable
crossystem dev_boot_legacy=0 # disable
Default boot medium:
crossystem dev_default_boot=disk # internal storage
crossystem dev_default_boot=usb # external media
crossystem dev_default_boot=legacy # legacy payload
Copyright © 2015 Paul Kocialkowski <contact@paulk.fr>\
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 this license is found in [../fdl-1.3.md](../fdl-1.3.md)

518
site/docs/gnulinux/configuring_parabola.md Normal file
View File

@ -0,0 +1,518 @@
---
title: Configuring Parabola (Post-Install)
x-toc-enable: true
...
TODO: this guide is horribly outdated. Update it! This guide was last updated
in 2017.
This is the guide for setting up Parabola GNU+Linux-Libre, after completing
the installation steps outlined in [Installing Parabola or Arch GNU+Linux-Libre with Full-Disk Encryption (including /boot)](encrypted_parabola.md).
It will cover installing and configuring a graphical desktop environment,
as well as some applications that make the system more user friendly.
For this example, we chose the *MATE Desktop Environment* as our graphical interface.
*This guide was valid on 2017-06-02. If you see any changes that should
to be made at the present date, please get in touch with the Libreboot
project (or [make those changes yourself](https://libreboot.org/git.html#editing-the-website-and-documentation-wiki-style))!*
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 any Debian-based GNU+Linux distribution (e.g., Trisquel, Debian, and Devuan),
without hiding any details from the user.
Paradoxically, as you get more advanced, Parabola can actually become
*easier to use*, when you want to set up your system in a special way,
compared to what most distributions provide. You will find over time
that other distributions tend to *get in your way*.
A lot of the steps in this guide will refer to ArchWiki. 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.
**NOTE: 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 ArchWiki will sometimes use bad language, such as calling the whole
system Linux, using the term **open-source**/**closed-source**,
and it will sometimes recommend the use of proprietary software.
You need to be careful about this when reading anything on ArchWiki.
Some of these steps require internet access. To get initial access
for setting up the system (I'll go into networking later),
just connect your system to a router, via an ethernet cable,
and run the following command:
systemctl start dhcpcd.service
You can stop it later (if needed), by using systemd's `stop` option:
systemctl stop dhcpcd.service
For most people, this should be enough, but if you don't have DHCP enabled
on your network, then you should setup your network connection first:
[Set Up Network Connection in Parabola](#network).
## Configure pacman
`pacman` (*pac*kage *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 Trisquel, Debian, or Devuan, this can be used to
add, remove, and update the software on your computer.
For more information related to `pacman`, review the following articles on the Arch Wiki:
* [Configuring pacman](https://wiki.parabolagnulinux.org/Installation_Guide#Configure_pacman)
* [Using pacman](https://wiki.archlinux.org/index.php/Pacman)
* [Additional Repositories](https://wiki.parabolagnulinux.org/Official_Repositories)
## Updating Parabola
Parabola is kept up-to-date, using `pacman`. When you are updating Parabola,
make sure to refresh the package list, *before* installing any new updates:
pacman -Syy
**NOTE: 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, actually update the system:
pacman -Syu
**NOTE: Before installing packages with** `pacman -S`**, always update first,
using the two commands 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 home page](https://www.parabola.nu/) and [Arch home page](https://www.archlinux.org/),
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 never a good idea to leave your installation
too outdated. 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.
The *Parabola* IRC channel ([**\#parabola**](https://webchat.freenode.net/) 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, when new updates are made to
the repositories; separate 'testing' repositories exist for this exact
reason. Despite what many people may 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 (this is why Arch/Parabola provide such extensive documenatation).
## 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 (e.g, if you wanted to
re-install it, or install the distro on another computer).
You should also read the ArchWiki article on [System Maintenance](https://wiki.archlinux.org/index.php/System_maintenance),
before continuing. Also, read their article on [enhancing system stability](https://wiki.archlinux.org/index.php/Enhance_system_stability).
This is important, so make sure to read them both!*
Install `smartmontools`; it can be used to check smart data. HDDs use
non-free firmware inside; it's transparent to you, but the smart
data comes from it. Therefore, don't rely on it too much), and then read
the ArchWiki [article](https://wiki.archlinux.org/index.php/S.M.A.R.T.) on it, to learn how to use it:
pacman -S smartmontools
### Cleaning the Package Cache
*This section provides a brief overview of how to manage the directory that stores
a cache of all downloaded packages. For more information,
check out the Arch Wiki guide for [Cleaning the Package Cache](https://wiki.archlinux.org/index.php/Pacman#Cleaning_the_package_cache).*
Here's how to use `pacman`, to clean out all old packages that are cached:
pacman -Sc
The Wiki cautions that this should be used with care. For example, since
older packages are deleted from the repository, if you encounter issues
and want to revert back to an older package, then it's useful to have the
caches available. Only do this ,if you are sure that you won't need it.
The Wiki also mentions this method for removing everything from the
cache, including currently installed packages that are cached:
pacman -Scc
This is inadvisable, since it means re-downloading the package again, if
you wanted to quickly re-install it. This should only be used when disk
space is at a premium.
### pacman Command Equivalents
If you are coming from another GNU+Linux distribution, you probably want to know
the command equivalents for the various `apt-get`-related commands that you often use.
For that information, refer to [Pacman/Rosetta](https://wiki.archlinux.org/index.php/Pacman/Rosetta),
so named, because it serves as a Rosetta Stone to the esoteric pacman language.
## 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 (i.e,. converting) an existing
Arch system to a Parabola system), installing it will also
fail, if these packages are installed, citing them as conflicts; the
recommended solution is then to delete the offending packages, and
continue installing `your-freedom`.
## Add a User
This is based on the Arch Wiki guide to [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 with the `useradd` command (self explanatory):
useradd -m -G wheel -s /bin/bash *your_user_name*
Set a password, using `passwd`:
passwd *your_user_name*
Like with the installation of Parabola, use of the [*diceware method*](http://world.std.com/~reinhold/diceware.html) is recommended,
for generating secure passphrases.
### Configure sudo
Now that we have a normal user account, we'll want to configure `sudo`,
so that user is able to run commands as **root** (e.g., installing software);
this will be necessary to flash the ROM later on. Refer to ArchWiki's [sudo](https://wiki.archlinux.org/index.php/Sudo) documentation.
The first step is to install the `sudo` package:
pacman -S sudo
After installation, we must configure it. To do so, we must modify **/etc/sudoers**.
This file must *always* be modified with the `visudo` command. `visudo` can be
difficult for beginners to use, so we'll want to edit the file with `nano`,
but the trick is that we just can't do this:
nano /etc/sudoers
Because, this will cause us to edit the file directly, which is not the way
it was designed to be edited, and could lead to problems with the system.
Instead, to temporarily allow us to use `nano` to edit the file,
we need to type this into the terminal:
EDITOR=nano visudo
This will open the **/etc/sudoers** file in `nano`, and we can now safely make changes to it.
To give the user we created earlier to ability to use `sudo`, we need to navigate
to the end of the file, and add this line on the end:
your_username ALL=(ALL) ALL
Obviously, type in the name of the user you created, instead of **your_username**.
Save the file, and exit `nano`; your user now has the ability to use `sudo`.
## systemd
`systemd` is the name of the program for managing services in Parabola;
It is a good idea to become familiar with it. Read the Arch Wiki article on [systemd](https://wiki.archlinux.org/index.php/systemd),
as well as their [Basic systemctl usage](https://wiki.archlinux.org/index.php/systemd#Basic_systemctl_usage) article,
to gain a full understanding. *This is very important! Make sure to read them.*
An example of a **service** could be a VPN (allowing you to connect to an outside network),
an applet in the system tray that tells you the weather for your city,
a sound manager (to make sure you can hear sound through speakers or headphones),
or DHCP (which allows you to get an IP address, to connect to the internet).
These are just a few examples; there are countless others.
`systemd` is a controversial init system; A [forum post](https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530)
has an explanation behind the Arch development team's decision to use it.
The **manpage** should also help:
man systemd
The section on **unit types** is especially useful.
According to the wiki, `systemd's` journal keeps logs of a size up to 10% of the
total size that your root 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 (that's what the wiki recommends).
Open **/etc/systemd/journald.conf**, and find this line:
#SystemMaxUse=
Change it to this:
SystemMaxUse=50M
Restart `journald`:
systemctl restart systemd-journald
The wiki recommends that if the journal gets too large, you can also
simply delete (`rm -Rf`) everything inside **/var/log/journald**, but
recommends backing it up. This shouldn't be necessary, since you
already set the size limit above, and `systemd` will automatically start
to delete older records, when the journal size reaches it's limit (according to systemd developers).
Finally, the wiki mentions **temporary files**, and the utility for
managing them.
man systemd-tmpfiles
To delete the temporary files, you can use the `clean` option:
systemd-tmpfiles --clean
According to the **manpage**, this *"cleans all files and directories with
an age parameter"*. According to ArchWiki, this reads information
in **/etc/tmpfiles.d** and **/usr/lib/tmpfiles.d**, to know what actions to perform.
Therefore, it is a good idea to read what's stored in these locations, to get a better understanding.
I looked in **/etc/tmpfiles.d/** and found that it was empty on my system.
However, **/usr/lib/tmpfiles.d** contained some files. The first one was
**etc.conf**, containing information and a reference to this **manpage**:
man tmpfiles.d
Read that **manpage**, and then continue studying all the files.
The `systemd` developers tell me that it isn't usually necessary
to manually touch the `systemd-tmpfiles utility`, at all.
## Interesting Repositories
In their [kernels](https://wiki.parabolagnulinux.org/Repositories#kernels) article,
the Parabola wiki mentions a repository called `[kernels]`, for custom kernels
that aren't in the default **base**. It might be worth looking into what is available there,
depending on your use case.
I enabled it on my system, to see what was in it. Edit **/etc/pacman.conf**,
and below the **extra** section add:
[kernels]
Include = /etc/pacman.d/mirrorlist*
Now, sync with the newly-added repository:
pacman -Syy
Lastly, list all available packages in this repository:
pacman -Sl kernels
In the end, I decided not to install anything from it,
but I kept the repository enabled regardless.
## Setup a Network Connection in Parabola
Read the ArchWiki guide to [Configuring the Network](https://wiki.archlinux.org/index.php/Configuring_Network).
### Set the Hostname
This should be the same as the hostname that you set in **/etc/hostname**,
when installing Parabola. You should also do it with `systemd`.
If you chose the hostname *parabola*, do it this way:
hostnamectl set-hostname parabola
This writes the specified hostname to **/etc/hostname**.
More information can be found in these **manpages**:
man hostname
info hostname
man hostnamectl
Check **/etc/hosts**, to make sure that the hostname that you put in there
during installation is still on each line:
127.0.0.1 localhost.localdomain localhost parabola
::1 localhost.localdomain localhost parabola
You'll note that I set both lines; the second line is for IPv6. Since more and
more ISPs are providing this now, it's good to be have it enabled, just in case.
The `hostname` utility is part of the `inetutils` package, and is in the **core** repository,
installed by default (as part of the **base** package).
### Network Status
According to ArchWiki, [udev](https://wiki.archlinux.org/index.php/Udev) should already detect
the ethernet chipset, and automatically load the driver for it at boot time.
You can check this in the **Ethernet controller** section, when running the `lspci` command:
lspci -v
Look at the remaining sections **Kernel driver in use** and **Kernel modules**.
In my case, it was as follows:
Kernel driver in use: e1000e
Kernel modules: e1000e
Check that the driver was loaded, by issuing `dmesg | grep module_name`.
In my case, I did:
dmesg | grep e1000e
### Network Device Names
According to the ArchWiki guide on [Configuring Network Device Names](https://wiki.archlinux.org/index.php/Configuring_Network#Device_names),
it is important to note that the old interface names that you might be used to
(e.g., `eth0`, `wlan0`, `wwan0`, etc.), if you come from a distribution like Debian or Trisquel,
are no longer applicable. Instead, `systemd` creates device names
starting with `en` (for ethernet), `wl` (for wi-fi), and `ww` (for wwan),
with a fixed identifier that it automatically generates.
An example device name for your ethernet chipset would be `enp0s25`,
and is never supposed to change.
If you want to enable the old names, ArchWiki recommends adding `net.ifnames=0`
to your kernel parameters (in Libreboot context, this would be accomplished by following
the instructions in [How to replace the default GRUB configuration file](grub_cbfs.md)).
For background information, read [Predictable Network Interface Names](http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/).
To show what the device names are for your system, run the following command:
ls /sys/class/net
[Changing the device names](https://wiki.archlinux.org/index.php/Configuring_Network#Change_device_name) is possible,
but for the purposes of this guide, there is no reason to do it.
### Network Setup
Aside from the steps mentioned above, I choose to ignore most of Networking section on the wiki;
this is because I will be installing the *MATE Desktop Environment*, and thus will
be using the `NetworkManger` client (with its accompanying applet) to manage the network.
If you wish to choose a different program, here are some other
[network manager options](https://wiki.archlinux.org/index.php/List_of_applications/Internet#Network_managers)
that you could use.
## Configuring the Graphical Desktop Environment
Since we are going with the *MATE Desktop Environment*, we will primarily be following
the instructions on the [Arch Linux Package Repository](https://wiki.mate-desktop.org/archlinux_custom_repo) page,
but will also refer to the [General Recommendations](https://wiki.archlinux.org/index.php/General_recommendations#Graphical_user_interface)
on ArchWiki.
### Installing Xorg
The first step is to install [**Xorg**](https://wiki.archlinux.org/index.php/Xorg);
this provides an implementation of the `X Window System`, which is used to provide
a graphical intefrace in GNU+Linux:
pacman -S xorg-server
We also need to install the driver for our hardware. Since I am using a Thinkpad X200,
I will use `xf86-video-intel`; it should be the same on the other Thinkpads,
as well as the Macbook 1,1 and 2,1.
pacman -S xf86-video-intel
For other systems, you can try:
pacman -Ss xf86-video- | less
When this is combined with looking at your `lspci` output, you can determine which
driver is needed. By default, `Xorg` will revert to `xf86-video-vesa`,
which is a generic driver, and doesn't provide true hardware acceleration.
Other drivers (not just video) can be found by looking at the `xorg-drivers` group:
pacman -Sg xorg-drivers
### Xorg Keyboard Layout
`xorg` uses a different configuration method for keyboard layouts than Parabola,
so you will notice that the layout you set in **/etc/vconsole.conf** earlier might
not actually be the same in `xorg`.
Check ArchWiki's article on [Xorg's keyboard configuration](https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg), for more information.
To see what layout you currently use, try this on a terminal emulator in `xorg`:
setxkbmap -print -verbose 10
I'm simply using the default Qwerty (US) keyboard, so there isn't anything I need
to change here; if you do need to make any changes, ArchWiki recommends two ways
of doing it: manually updating [configuration files](https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_X_configuration_files) or using the [localectl](https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg#Using_localectl) command.
### Installing MATE
Now we have to install the desktop environment itself. According to the Arch Linux Package Repository,
if we want all of the MATE Desktop, we need to install two packages:
pacman -Syy mate mate-extra
The last step is to install a Display Manager; for MATE, we will be using `lightdm`
(it's the recommended Display Manager for the MATE Desktop); for this, we'll folow the instructions [on the MATE wiki](https://wiki.mate-desktop.org/archlinux_custom_repo#display_manager_recommended),
with one small change: the `lightdm-gtk3-greeter` package doesn't exist in Parabola's repositories.
So, instead we will install the `lightdm-gtk-greeter` package; it performs the same function.
We'll also need the `accountsservice` package, which gives us the login window itself:
pacman -Syy lightdm-gtk3-greeter accountsservice
After installing all the required packages, we need to make it so that the MATE Desktop Environment
will start automatically, whenever we boot our computer; to do this, we have to enable the display manager, `lightdm`,
as well as the service that will prompt us with a login window, `accounts-daemon`:
systemctl enable lightdm
systemctl enable accounts-daemon
Now you have installed the *MATE Desktop Environment*,If you wanted
to install another desktop environment, check out some [other options](https://wiki.archlinux.org/index.php/Desktop_environment) on ArchWiki.
### Configuring Network Manager in MATE
Now that we have installed the Mate Desktop environment, and booted into it,
we need to set up the network configuration in our graphical environment.
The MATE Desktop wiki recommends that we use Network Manager; an
article about Network Manager can be found
[on ArchWiki](https://wiki.archlinux.org/index.php/NetworkManager).
We need to install the NetworkManager package:
pacman -S networkmanager
We will also need the Network Manager applet, which will allow us to manage our
networks from the system tray:
pacman -S network-manager-applet
Finally, we need to start the service (if we want to use it now), or enable it,
(so that it will activate automatically, at startup).
systemctl enable NetworkManager.service
If you need VPN support, you will also want to install the `networkmanager-openvpn` package.
**NOTE: You do not want multiple networking services running at the same time;
they will conflict, so, if using Network Manager, you want to stop/disable any
others from running. Examples of other services that will probably intefere
with Network Manager are** `dhcpcd` **and** `wifi-menu`**.**
You can see all currently-running services with this command:
systemctl --type=service
And you can stop them using this command:
systemctl stop service_name.service
If you want to disable those services, meaning that you no longer want them to start
when the computer boots up, you will need to use `systemctl's` `disable` option,
instead of `stop`.
Now you have a fully-functional graphical environment for your Parabola installation,
including networking. All you have to do is reboot, and you will be prompted to log in,
with a familiar graphical login prompt. You can also now, more easily [modify the GRUB configuration](grub_cbfs.md),
install new applications, and/or make whatever other changes you want to your system.

369
site/docs/gnulinux/encrypted_debian.md Normal file
View File

@ -0,0 +1,369 @@
---
title: Encrypted Debian GNU+Linux
x-toc-enable: true
...
This guide is written for the Debian distribution, but it should also
work for Devuan with the net installer. Other Debian based GNU+Linux
distributions may also work, using these instructions.
This guide assumes that you are using the GNU GRUB bootloader as a coreboot
payload. In this configuration, GNU GRUB runs on *bare metal* instead of
relying on BIOS or UEFI. GNU GRUB has support for directly reading LUKS volumes
and it can directly boot your Linux kernel this way. With GRUB already in the
boot flash, this means that your `/boot/` directory (containing your Linux
kernel) can be fully encrypted. The same cannot be said for most other systems,
and no other coreboot payload provides this functionality.
If booting in text mode
=======================
Libreboot ROM images are provided, which will either boot the system in classic
text mode, or with a framebuffer implemented by coreboot for video display
initialization (not to be confused with int10h VGA modes).
*Text mode* is the default video mode on *most* x86 platforms, using `INT 10H`
functions. It's an interrupt service that text-mode applications use, a hangover
from the days of CS/M and DOS. In this mode, no framebuffer exists and Libreboot
currently does not implement VGA modes. The Debian net installer will attempt
to use VGA modes that most implementations of INT 10H provide. Therefore, you
must force Debian's installation program to operate in text mode.
To boot the Debian net installer, make sure to specify `fb=false` on the linux
kernel parameters in GRUB. This will boot the installer in text mode instead
of using a framebuffer. By default, the netinstaller will try to switch to a
high resolution framebuffer. Due to lack of INT10H video BIOS services and mode
switching support in `libgfxinit`, this will fail.
In *some* setups, you don't need this. For example, if you're using an add-on
PCIe GPU on a desktop/server board (e.g. ASUS KGPE-D16/KCMA-D8, Gigabyte
GA-G41M-ES2L), you would use SeaBIOS payload with text-mode startup, but the
Video BIOS *option ROM* in your add-on graphics card would be executed, and it
would presumably handle INT10H VGA modes.
Boot the installer
==================
Libreboot on x86 can use the GNU GRUB bootloader as a bare metal coreboot
[payload](http://www.coreboot.org/Payloads#GRUB_2) if you wish, 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 or UEFI 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 guide is written for Debian net installer. You can download the ISO
from the homepage on [debian.org](https://www.debian.org/). Use this on
the GRUB terminal to boot it from USB (for 64-bit Intel or AMD):
set root='usb0'
linux /install.amd/vmlinuz
initrd /install.amd/initrd.gz
boot
If you are on a 32-bit system (e.g. X60):
set root='usb0'
linux /install.386/vmlinuz
initrd /install.386/initrd.gz
boot
[This guide](grub_boot_installer.md) shows how to create a boot USB
drive with the Debian ISO image.
*This guide is only for the GRUB payload. If you use the depthcharge payload,
ignore this section entirely.*
Note: on some thinkpads, a faulty DVD drive can cause the cryptomount -a step
during boot to fail. If this happens to you, try removing the drive.
Set a strong user password (lots of lowercase/uppercase, numbers and symbols).
Use of the *diceware method* is recommended, for generating secure passphrases
(instead of passwords).
When the installer asks you to set up encryption (ecryptfs) for your home
directory, select 'Yes' if you want to: *LUKS is already secure and performs
well. Having ecryptfs on top of it will add noticeable performance penalty, for
little security gain in most use cases. This is therefore optional, and not
recommended. Choose 'no'.*
*Your user password should be different from the LUKS password which
you will set later on. Your LUKS password should, like the user
password, be secure.*
Partitioning
============
Choose 'Manual' partitioning:
- Select drive and create new partition table
- Single large partition. The following are mostly defaults:
- Use as: physical volume for encryption
- Encryption: aes
- key size: whatever default is given to you
- IV algorithm: whatever default is given to you
- Encryption key: passphrase
- erase data: Yes (only choose 'No' if it's a new drive that
doesn't contain your private data)
- Select 'configure encrypted volumes'
- Create encrypted volumes
- Select your partition
- Finish
- Really erase: Yes
- (erase will take a long time. be patient)
- (if your old system was encrypted, just let this run for about a
minute to make sure that the LUKS header is wiped out)
- Select encrypted space:
- use as: physical volume for LVM
- Choose 'done setting up the partition'
- Configure the logical volume manager:
- Keep settings: Yes
- Create volume group:
- Name: `matrix` (use this exact name)
- Select crypto partition
- Create logical volume
- select `matrix` (use this exact name)
- name: `rootvol` (use this exact name)
- size: default, minus 2048 MB
- Create logical volume
- select `matrix` (use this exact name)
- name: `swap` (user this exact name)
- size: press enter
Further partitioning
====================
Now you are back at the main partitioning screen. You will simply set
mountpoints and filesystems to use.
- LVM LV rootvol
- use as: btrfs
- mount point: /
- done setting up partition
- LVM LV swap
- use as: swap area
- done setting up partition
- Now you select 'Finished partitioning and write changes to disk'.
Kernel
======
Installation will ask what kernel you want to use. linux-generic is
fine, but you can choose whatever you want here.
Tasksel
=======
For Debian, use the *MATE* option, or one of the others if you want. The
Libreboot project recommends MATE, unless you're saavy enough to choose
something else.
If you want debian-testing, then you should only select barebones
options here and change the entries in /etc/apt/sources.list after
install to point to the new distro, and then run `apt-get update` and
`apt-get dist-upgrade` as root, then reboot and run `tasksel` as
root. This is to avoid downloading large packages twice.
NOTE: If you want the latest up to date version of the Linux kernel,
Debian's kernel is sometimes outdated, even in the testing distro. You
might consider using [this repository](https://jxself.org/linux-libre/)
instead, which contains the most up to date versions of the Linux
kernel. These kernels are also deblobbed, like Debian's kernels, so you
can be sure that no binary blobs are present.
Postfix configuration
=====================
If asked, choose `No Configuration` here (or maybe you want to
select something else. It's up to you.)
Install the GRUB boot loader to the master boot record
======================================================
Choose `No`, and then it will still ask you what HDD to install GRUB on. Select
your HDD/SSD from the automatically generated list.
The installer will provide GRUB on your HDD/SSD, but not try to install it to
an MBR section. However, the `/boot/grub/grub.cfg` on your system will be
maintained automatically by `apt-get` when handling kernel packages.
Clock UTC
=========
Just say 'Yes'.
**At this point, your Debian system is installed. Shut down when the installer
tells you to.**
Booting your system
===================
If you didn't install GRUB during the net installation process, don't worry.
You can boot your installed system manually, using the *terminal* in GRUB on
your boot flash (the version that Libreboot gives you).
At this point, you will have finished the installation. At your GRUB
payload, press C to get to reach the GRUB terminal and enter these commands:
cryptomount -a
set root='lvm/matrix-rootvol'
linux /vmlinuz root=/dev/mapper/matrix-rootvol cryptdevice=/dev/mapper/matrix-rootvol:root
initrd /initrd.img
boot
**If you did install GRUB, ignore the above. Just select the default `Load
Operating System` menu option and it should fully boot into your system.**
When you type your encryption passphrase in GRUB, it will seem like the process
has stalled. The same will be true when you load your linux kernel in Debian.
Just be patient and it will boot. If you see errors, just press enter to skip
them until you see the Debian GRUB menu.
ecryptfs
========
If you didn't encrypt your home directory, then you can safely ignore
this section.
Immediately after logging in, do that:
sudo ecryptfs-unwrap-passphrase
This will be needed in the future if you ever need to recover your home
directory from another system, so write it down and keep the note
somewhere secret. Ideally, you should memorize it and then burn the note
(or not even write it down, and memorize it still)>
LUKSv2
======
LUKSv2 is fully supported nowadays, in recent Libreboot releases. The old
Libreboot release, version 20160907 (and earlier releases), did not support
LUKSv2 in GNU GRUB. By default, modern Debian distributions will use LUKSv2.
You do not need to downgrade LUKSv2 to v1, but you shouldn't use any of the
special features that LUKSv2 offers. Basically, the partitioning should be
done exactly the same way as with LUKSv1 (but with newer encryption/hashing
algorithms used by LUKSv2 partitions). This is because of limitations in the
implementation of LUKSv2 in GNU GRUB. GRUB uses its own custom implementation,
instead of directly adapting the Linux kernel implementation.
Generate distro's grub.cfg
==========================
**If `/boot/grub/grub.cfg` already exists, ignore this step.**
Now you need to set it up so that the system will automatically boot,
without having to type a bunch of commands.
Install grub-coreboot if not already installed:
apt-get install grub-coreboot
Modify or add following lines to /etc/default/grub
GRUB_CMDLINE_LINUX="cryptdevice=/dev/mapper/matrix-rootvol:root"
GRUB_ENABLE_CRYPTODISK=y
Copy fonts/backgrounds to /boot/grub and
generate grub.cfg using following command:
grub-install --target=i386-coreboot
[Refer to this guide](grub_hardening.md) for further guidance on
hardening your GRUB configuration, for security purposes.
Troubleshooting
===============
A user reported issues when booting with a docking station attached on
an X200, while decrypting the disk in GRUB. The error `AHCI transfer
timed out` was observed. The workaround was to remove the docking
station or remove the CD/DVD drive.
Here is the information on that DVD drive, which said user had:
"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

498
site/docs/gnulinux/encrypted_parabola.md Normal file
View File

@ -0,0 +1,498 @@
---
title: Installing Parabola or Arch GNU+Linux-Libre, with Full-Disk Encryption (including /boot)
x-toc-enable: true
...
TODO: this guide is horribly outdated. Update it, based on the latest Parabola
versions.
Also see:
[Installing Hyperbola GNU+Linux, with Full-Disk Encryption (including /boot)](https://wiki.hyperbola.info/en:guide:encrypted_installation)
This guide covers how to install Parabola GNU+Linux-Libre, with full disk encryption,
including **/boot** (the boot directory). On most systems, **/boot** has
to be left unencrypted, while the other partition(s) are encrypted.
This is so that GRUB (and therefore the kernel) can be loaded and executed,
because most firmware can’t open a LUKS volume; however, with libreboot,
GRUB is already included as a [payload](http://www.coreboot.org/Payloads#GRUB_2),
so even **/boot** can be encrypted; this protects **/boot** from tampering
by someone with physical access to the system.
**NOTE: This guide is *only* for the GRUB payload.
If you use the depthcharge payload, ignore this section entirely.**
This guide borrows heavily from the Parabola wiki, and will constantly link to it.
For those new to Parabola GNU+Linux-Libre, check their [Beginner section](https://wiki.parabola.nu/Beginners%27_guide#Beginners) for an overview.
## Minumum Requirements
You can find the minimum requirements to run Parabola GNU+Linux
[on the Parabola wiki](https://wiki.parabola.nu/Beginners%27_guide#Minimum_system_requirements).
## Preparation
### Download the latest ISO
For this guide, I used the *2016.11.03* ISO; the most current image is
available on Parabola's
[downloads page](https://wiki.parabola.nu/Get_Parabola#Release_images_for_x86_64_and_i686_architectures).
If you are a complete beginner with GNU+Linux, choose the *Mate Desktop ISO*.
it is easier to install Parabola with this version, because it allows you
access to a web browser, so you can copy and paste commands right into the terminal,
without worrying about typos.
**NOTE: You should never blindly copy-and-paste any commands. In this guide,
copying and pasting is to ensure that no errors are made when entering the commands,
so that you don't effectively "brick" your installation, and have to start over.
It's important to understand what each command does before you use it,
so be sure to read the Parabola/Archi Wiki documentation on the command,
as well as its** `man` **page.**
If you are not a beginner, choose the *Main Live ISO*.
Only choose the *TalkingParabola ISO*, if you are blind or visually impaired.
### Choose the Installation Device
Refer to the Parabola wiki, for finding and choosing the proper installation device,
whether you are using an [Optical Disk](https://wiki.parabola.nu/Beginners%27_guide#Optical_Disks),
or a [USB drive](https://wiki.parabola.nu/Beginners%27_guide#USB_flash_drive).
### Boot Parabola's Install Environment
After downloading the ISO, and creating some kind of bootable media,
you will need to boot into the Live image. If you are unsure of how to do so,
see [How to boot a GNU+Linux installer](grub_boot_installer.md),
and move on to the next step; otherwise, just go to the next step.
Once booted into the environment, either open the **`MATE Terminal`** application
(if using the MATE Desktop ISO), or simply just enter the commands listed below
(if using any of the other ISO's).
## Setting Up Keyboard Layout
To begin the installation, you must first select the proper [keyboard layout](https://wiki.parabola.nu/Beginners%27_guide#Changing_Keyboard).
## Establish an Internet Connection
You will also need to [set up a network connection](https://wiki.parabola.nu/Beginners%27_guide#Establish_an_internet_connection),
to install packages.
## Preparing the Storage Device for Installation
You need to prepare the storage device that we will use to install the operating system.
You can use same [device name](https://wiki.parabola.nu/Beginners%27_guide#USB_flash_drive)
that you used earlier, to determine the installation device for the ISO.
### Wipe Storage Device
You want to make sure that the device you're using doesn't contain any plaintext
copies of your personal data. If the drive is new, then you can skip the rest of this section;
if it's not new, then there are two ways to handle it:
1. If the drive were not previously encrypted, securely wipe it with the `dd` command;
you can either choose to fill it with zeroes or random data; I chose random data (e.g., `urandom`),
because it's more secure. Depending on the size of the drive, this could take a while to complete:
~~~
dd if=/dev/urandom of=/dev/sdX; sync
~~~
2. If the drive were previously encrypted, all you need to do is wipe the LUKS header.
The size of the header depends upon the specific model of the hard drive;
you can find this information by doing some research online.
Refer to this [article](https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/), for more information about LUKS headers.
You can either fill the header with zeroes, or with random data; again, I chose random data, using `urandom`:
~~~
head -c 3145728 /dev/urandom > /dev/sdX; sync
~~~
Also, if you're using an SSD, there are a two things you should keep in mind:
- There are issues with TRIM; it's not enabled by default through LUKS,
and there are security issues, if you do enable it. See [this page](https://wiki.archlinux.org/index.php/Dm-crypt#Specialties) for more info.
- Make sure to read [this article](https://wiki.archlinux.org/index.php/Solid_State_Drives),
for information on managing SSD's in Arch Linux (the information applies to Parabola, as well).
### Formatting the Storage Device
Now that all the personal data has been deleted from the disk, it's time to format it.
We'll begin by creating a single, large partition on it, and then encrypting it using LUKS.
#### Create the LUKS partition
You will need the `device-mapper` kernel module during the installation;
this will enable us to set up our encrypted disk. To load it, use the following command:
modprobe dm_mod
We then need to select the **device name** of the drive we're installing the operating system on;
see the above method, if needed, for figuring out device names.
Now that we have the name of the correct device, we need to create the partition on it.
For this, we will use the `cfdisk` command:
cfdisk /dev/sdX
1. Use the arrow keys to select your partition, and if there is already a partition
on the drive, select **Delete**, and then **New**.
2. For the partition size, leave it as the default, which will be the entire drive.
3. You will see an option for **Primary** or **Logical**; choose **Primary**,
and make sure that the partition type is **Linux (83)**.
4. Select **Write**; it will ask you if you are sure that you want to overwrite the drive.
5. Type **yes**, and press enter. A message at the bottom will appear, telling you that
the partition table has been altered.
6. Select **Quit**, to return you to the main terminal.
Now that you have created the partition, it's time to create the encrypted volume on it,
using the `cryptsetup` command, like this:
cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool \
--iter-time 500 --use-random --verify-passphrase --type luks1 luksFormat /dev/sdXY
These are just recommended defaults; if you want to use anything else,
or to find out what options there are, run `man cryptsetup`.
>**NOTE: the default iteration time is 2000ms (2 seconds),
>if not specified when running the cryptsetup command. You should set a lower time than this;
>otherwise, there will be an approximately 20-second delay when booting your
>system. We recommend 500ms (0.5 seconds), and this is included in the
>prepared** `cryptsetup` **command above. Keep in mind that the iteration time
>is for security purposes (it mitigates brute force attacks), so anything lower
>than 0.5 seconds is probably not very secure.**
You will now be prompted to enter a passphrase; be sure to make it *secure*.
For passphrase security, length is more important than complexity
(e.g., **correct-horse-battery-staple** is more secure than **bf20$3Jhy3**),
but it's helpful to include several different types of characters
(e.g., uppercase/lowercase letters, numbers, special characters).
The password length should be as long as you are able to remember,
without having to write it down, or store it anywhere.
Use of the [**diceware**](http://world.std.com/~reinhold/diceware.html) method
is recommended, for generating secure passphrases (rather than passwords).
#### Create the Volume Group and Logical Volumes
The next step is to create two Logical Volumes within the LUKS-encrypted partition:
one will contain your main installation, and the other will contain your swap space.
We will create this using, the [Logical Volume Manager (LVM)](https://wiki.archlinux.org/index.php/LVM).
First, we need to open the LUKS partition, at **/dev/mapper/lvm**:
cryptsetup luksOpen /dev/sdXY lvm
Then, we create LVM partition:
pvcreate /dev/mapper/lvm
Check to make sure tha the partition was created:
pvdisplay
Next, we create the volume group, inside of which the logical volumes will
be created. In libreboot's case, we will call this group **matrix**.
If you want to have it work via *Load Operating System (incl. fully
encrypted disks) [o]* it needs to be called **matrix** (as it is harcoded
in libreboot's grub.cfg on the flash)
vgcreate matrix /dev/mapper/lvm
Check to make sure that the group was created:
vgdisplay
Lastly, we need to create the logical volumes themselves, inside the volume group;
one will be our swap, cleverly named **swapvol**, and the other will be our root partition,
equally cleverly named as **rootvol**.
1. We will create the **swapvol** first (again, choose your own name, if you like).
Also, make sure to [choose an appropriate swap size](http://www.linux.com/news/software/applications/8208-all-about-linux-swap-space)
(e.g., **2G** refers to two gigabytes; change this however you see fit):
~~~
lvcreate -L 2G matrix -n swapvol
~~~
2. Now, we will create a single, large partition in the rest of the space, for **rootvol**:
~~~
# lvcreate -l +100%FREE matrix -n rootvol
~~~
You can also be flexible here, for example you can specify a **/boot**, a **/**,
a **/home**, a **/var**, or a **/usr** volume. For example, if you will be running a
web/mail server then you want **/var** (where logs are stored) 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), just a root and a swap will do.
Verify that the logical volumes were created correctly:
lvdisplay
#### Make the rootvol and swapvol Partitions Ready for Installation
The last steps of setting up the drive for installation are turning **swapvol**
into an active swap partition, and formatting **rootvol**.
To make **swapvol** into a swap partition, we run the `mkswap` (i.e., make swap) command:
mkswap /dev/matrix/swapvol
Activate the **swapvol**, allowing it to now be used as swap,
using `swapon` (i.e., turn swap on) command:
swapon /dev/matrix/swapvol
Now I have to format **rootvol**, to make it ready for installation;
I do this with the `mkfs` (i.e., make file system) command.
I choose the **ext4** filesystem, but you could use a different one,
depending on your use case:
mkfs.ext4 /dev/matrix/rootvol
Lastly, I need to mount **rootvol**. Fortunately, GNU+Linux has a directory
for this very purpose: **/mnt**:
mount /dev/matrix/rootvol /mnt
#### Separate boot and home logical volumes
You could also create two separate logical volumes for **/boot** and **/home**,
but such a setup would be for advanced users,
and is thus not covered in this guide.
If separate boot logical volume is used, it has to be named **boot**
in order for libreboot to use it.
The setup of the drive and partitions is now complete; it's time to actually install Parabola.
## Select a Mirror
The first step of the actual installation is to choose the server from where
we will need to download the packages; for this, we will again refer to the [Parabola Wiki](https://wiki.parabola.nu/Beginners%27_guide#Select_a_mirror).
For beginners, I recommend that the edit the file using `nano` (a command-line text editor);
you can learn more about it on [their website](https://www.nano-editor.org/); for non-beginners,
simply edit it with your favorite text editor.
## Install the Base System
We need to install the essential applications needed for your Parabola installation to run;
refer to [Install the Base System](https://wiki.parabola.nu/Beginners%27_guide#Install_the_base_system), on the Parabola wiki.
## Generate an fstab
The next step in the process is to generate a file known as an **fstab**;
the purpose of this file is for the operating system to identify the storage device
used by your installation. [On the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Generate_an_fstab) are the instructions to generate that file.
## Chroot into and Configure the System
Now, you need to `chroot` into your new installation, to complete the setup
and installation process. **Chrooting** refers to changing the root directory
of an operating system to a different one; in this instance, it means changing your root
directory to the one you created in the previous steps, so that you can modify files
and install software onto it, as if it were the host operating system.
To `chroot` into your installation, follow the instructions [on the
Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Chroot_and_configure_the_base_system).
### Setting up the Locale
Locale refers to the language that your operating system will use, as well as some
other considerations related to the region in which you live. To set this up,
follow the instructions [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Locale).
### Setting up the Consolefont and Keymap
This will determine the keyboard layout of your new installation; follow the instructions [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Console_font_and_keymap).
### Setting up the Time Zone
You'll need to set your current time zone in the operating system; this will enable applications
that require accurate time to work properly (e.g., the web browser).
To do this, follow the instructions [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Time_zone).
### Setting up the Hardware Clock
To make sure that your computer has the right time, you'll have to set the time in your computer's internal clock.
Follow the instructions [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Hardware_clock) to do that.
### Setting up the Kernel Modules
Now we need to make sure that the kernel has all the modules that it needs
to boot the operating system. To do this, we need to edit a file called **mkinitcpio.conf**.
More information about this file can be found [in the Parabola beginner's guide](https://wiki.parabola.nu/Mkinitcpio),
but for the sake of this guide, you simply need to run the following command.
nano /etc/mkinitcpio.conf
There are several modifications that we need to make to the file:
1. Change the value of the uncommented `MODULES` line to `i915`.
* This forces the driver to load earlier, so that the console font you selected earlier
isn’t wiped out after getting to login.
* If you are using a **Macbook 2,1** you will also need to add `hid-generic`,
`hid`, and `hid-apple` inside the quotation marks, in order to have
a working keyboard when asked to enter the LUKS password.
Make sure to separate each module by one space.
2. Change the value of the uncommented `HOOKS` line to the following:
~~~
base udev autodetect modconf block keyboard keymap consolefont encrypt lvm2 filesystems fsck shutdown
~~~
here's what each module does:
* `keymap` adds to *initramfs* the keymap that you specified in **/etc/vconsole.conf**
* `consolefont` adds to *initramfs* the font that you specified in **/etc/vconsole.conf**
* `encrypt` adds LUKS support to the initramfs - needed to unlock your disks at boot time
* `lvm2` adds LVM support to the initramfs - needed to mount the LVM partitions at boot time
* `shutdown` is needed according to Parabola wiki, for unmounting devices (such as LUKS/LVM) during shutdown
After modifying the file and saving it, we need to update the kernel(s) with the new settings.
Before doing this, we want to install a Long-Term Support (LTS) kernel as a backup, in the event
that we encounter problems with the default Linux-Libre kernel (which is continually updated).
We will also install the `grub` package, which we will need later,
to make our modifications to the GRUB configuration file:
pacman -S linux-libre-lts grub
Then, we update both kernels like this, using the `mkinitcpio` command:
mkinitcpio -p linux-libre
mkinitcpio -p linux-libre-lts
### Setting up the Hostname
Now we need to set up the hostname for the system; this is so that our device
can be identified by the network. Refer to [the hostname section](https://wiki.parabola.nu/Beginners%27_guide#Hostname)
of the Parabola wiki's Beginner's Guide. You can make the hostname anything you like;
for example, if you wanted to choose the hostname **parabola**,
you would run the `echo` command, like this:
echo parabola > /etc/hostname
And then you would modify **/etc/hosts** like this, adding the hostname to it:
nano /etc/hosts
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost parabola
::1 localhost.localdomain localhost parabola
### Configure the Network
Now that we have a hostname, we need to configure the settings for the rest of the network.
Instructions for setting up a wired connection are [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Wired),
and instructions for setting up a wireless connection are [in the Parabola beginner's guide](https://wiki.parabola.nu/Beginners%27_guide#Wireless_2).
### Set the root Password
The **root** account has control over all the files in the computer; for security,
we want to protect it with a password. The password requirements given above,
for the LUKS passphrase, apply here as well. You will set this password with the `passwd` command:
passwd
### Extra Security Tweaks
There are some final changes that we can make to the installation, to make it
significantly more secure; these are based on the [Security](https://wiki.archlinux.org/index.php/Security) section of the Arch wiki.
#### Key Strengthening
We will want to open the configuration file for password settings, and increase
the strength of our **root** password:
nano /etc/pam.d/passwd
Add `rounds=65536` at the end of the uncommented 'password' line; in simple terms,
this will force an attacker to take more time with each password guess, mitigating
the threat of brute force attacks.
#### Restrict Access to Important Directories
You can prevent any user, other than the root user, from accessing the most important
directories in the system, using the `chmod` command; to learn more about this command,
run `man chmod`:
chmod 700 /boot /etc/{iptables,arptables}
#### Lockout User After Three Failed Login Attempts
We can also setup the system to lock a user's account, after three failed login attempts.
To do this, we will need to edit the file **/etc/pam.d/system-login**,
and comment out this line:
auth required pam\_tally.so onerr=succeed file=/var/log/faillog*\
You could also just delete it. Above it, put the following line:
auth required pam\_tally.so deny=2 unlock\_time=600 onerr=succeed file=/var/log/faillog
This configuration will lock the user out for ten minutes.
You can unlock a user's account manually, using the **root** account, with this command:
pam_tally --user *theusername* --reset
#### Generate grub.cfg
Edit configuration in `/etc/default/grub`, remembering to use UUID when poitning to mbr/gpt partition.
Use `blkid` to get list of devices with their respective UUIDs.
For details see [parabola wiki.](https://wiki.parabola.nu/Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_5)
Next generate grub.cfg with:
grub-mkconfig -o /boot/grub/grub.cfg
If you have separate `/boot` partition, don't forget to add `boot` symlink inside that points to current directory
cd /boot; ln -s . boot
## Unmount All Partitions and Reboot
Congratulations! You have finished the installation of Parabola GNU+Linux-Libre.
Now it is time to reboot the system, but first, there are several preliminary steps:
Exit from `chroot`, using the `exit` command:
exit
Unmount all of the partitions from **/mnt**, and "turn off" the swap volume:
umount -R /mnt
swapoff -a
Deactivate the **rootvol** and **swapvol** logical volumes:
lvchange -an /dev/matrix/rootvol
lvchange -an /dev/matrix/swapvol
Lock the encrypted partition (i.e., close it):
cryptsetup luksClose lvm
Shutdown the machine:
shutdown -h now
After the machine is off, remove the installation media, and turn it on.
## Booting the installation manually from GRUB
When you forget to configure or misconfigure grub on your hdd, you have to manually boot
the system by entering a series of commands into the GRUB command line.
After the computer starts, Press `C` to bring up the GRUB command line.
You can either boot the normal kernel, or the LTS kernel we installed;
here are the commands for the normal kernel:
grub> cryptomount -a
grub> set root='lvm/matrix-rootvol'
grub> linux /boot/vmlinuz-linux-libre root=/dev/matrix/rootvol cryptdevice=/dev/sda1:root
grub> initrd /boot/initramfs-linux-libre.img
grub> boot
If you're trying to boot the LTS kernel, simply add **-lts** to the end
of each command that contains the kernel (e.g., **/boot/vmlinuz-linux-libre**
would be **/boot/vmlinuz/linux-libre-lts**).
**NOTE: on machines with native sata, during boot a (faulty) optical disc drive (like dvd) can cause
the** `cryptomount -a` **command to fail/hang, as well as the error** `AHCI transfer timed out`
**The workaround was to remove the DVD drive.**
## Follow-Up Tutorial: Configuring Parabola
The next step of the setup process is to modify the configuration file that
GRUB uses, so that we don't have to manually type in those commands above, each time we want
to boot our system.
To make this process much easier, we need to install a graphical interface,
as well as install some other packages that will make the system more user-friendly.
These additions will also sharply reduce the probability of "bricking" our computer.
[Configuring Parabola (Post-Install)](configuring_parabola.md) provides an example setup, but don't feel
as if you must follow it verbatim (of course, you can, if you want to);
Parabola is user-centric and very customizable, which means that you have maximum control
of the system, and a near-limitless number of options for setting it up. For more information,
read [The Arch Way](https://wiki.archlinux.org/index.php/The_Arch_Way) (Parabola also follows it).
After setting up the graphical interface, refer to [How to Modify GRUB Configuration](grub_cbfs.md),
for instructions on doing just that, as well as flashing the ROM (if necessary).

197
site/docs/gnulinux/encrypted_trisquel.md Normal file
View File

@ -0,0 +1,197 @@
---
title: Installing Trisquel GNU+Linux with Full-Disk Encryption (including /boot)
x-toc enable: true
...
TODO: this guide needs to be updated based on the latest Trisquel 9.0 release.
This guide is written for the Trisquel 7.0 (Belenos) GNU+Linux distribution, but it should also work for Trisquel 6.0 (Toutatis).
Do not precisely follow this guide for Trisquel 9.0. There are a lot of steps
needed after the installation, especially if you're using `btrfs` for your
file system. If you're using the `ext4` file system, this guide will probably
just work for Trisquel 9. TODO: update this guide!
## Gigabyte GA-G41M-ES2L
To boot the Trisquel net installer, make sure to specify fb=false on the linux
kernel parameters in GRUB. This will boot the installer in text mode instead
of using a framebuffer.
## Boot the Installation Media
Boot your operating system, with the installation media. If you don't know how to do so, refer to [How to Prepare and Boot a USB Installer in Libreboot Systems](grub_boot_installer.md).
When the Trisquel GRUB screen appears, select the `Install Trisquel in Text Mode` option.
## Select a Language
The first part of the installation is to select your system's language; I chose `English`.
## Select Your Location
You will need to select your location; I choose `United States`.
## Configure the Keyboard
You need to select the right layout for your keyboard; if you want to installer to do it automatically, choose `Yes`, and it will ask you whether or not a series of keys are present on your keyboard. Simply choose `Yes` or `No`, accordingly.
If you don't want the installer to automatically detect your keyboard layout, choose `No`, and simply select it from a list.
## Configure the Network
### Choose the Network Inteface
You will need to select the network interface to be used for the installation. If you have an ethernet (i.e., wired) connection, choose `etho0`; otherwise, choose `wlan0` (for wireless).
If you choose `wlan0`, enter the passphrase that corresponds to your wireless network's WPA/WPA2 key (Your wireless network should have a password, and no modern router should be using the [WEP protocol](https://en.wikipedia.org/wiki/Wired_Equivalent_Privacy)).
### Choose Your Hostname
You will need to choose a hostname for the system, which identifies your computer to the network; it can be anything, but it must only consist of numbers, uppercase and lowercase letters, and dashes `-`.
### Choose a Mirror of the Trisquel Archive
Choose the server from where you will download the Trisquel packages needed for the installation. The choices are separated by country; simply select the one that is closest to where you are.
After you select the country, you will be taken to a list of different individual servers. If there is more than one option, choose the one that is closest to you; otherwise, select whichever one is available.
The last step of setting up the network will be entering an HTTP proxy (if you need one to access the network). If you have one, type it here; otherwise, press `Tab`, and then choose `Continue` (using the arrow keys).
## Loading Additional Components
Now the installer needs to download some more packages, to continue the installation. Depending on your network bandwidth, this could take up to a few minutes to complete.
## Set Up Users and Passwords
Enter the full name of the user here. You can use your real name, or just a pseudonym; then, choose `Continue`.
Then it will ask you to enter a *username*. Pick whatever you like, and enter it here. Select `Continue`.
Choose a passphrase (better than a password). The [diceware](http://world.std.com/~reinhold/diceware.html) method is highly recommended for coming up with one.
I recommend combining the *diceware* method with something personal about yourself. An example of this would be to choose four words from the *diceware* list, and then come up with a fifth "word" (i.e., a combination of characters that is unique to you, like some name plus a number/special character); this combination dramatically increases the security of a *diceware* passphrase (i.e., even if someone had the entire *diceware* word list, they couldn't figure out your passphrase through brute force).
**NOTE: This would be difficult for a person to do, even if you *only* used words from the list**.
For example, say that your cat's name is **Max**, and he is three years old; you could do something like this:
diceware_word_1 diceware_word_2 diceware_word_3 diceware_word_4 Max=3old
This has a large degree of randomness (due to the usage of the *diceware* method), and also contains a unique piece of personal information that someone would need to know you, in order to guess; it's a very potent combination.
After entering this password twice, choose `Continue`.
It will now ask you if you want to encrypt your home directory. Remember, this is *NOT* to be confused with encrypting your entire disk (the purpose of this guide); it will just be the files that reside in `~`, and it uses a different encryption protocol (`ecryptfs`). If you want to encrypt your home directory here, choose `Yes`; however, since we are going to encrypt the entire installation, that would not only be redundant, but it would also add a noticeable performance penalty, for little security gain in most use cases. This is therefore optional, and *NOT* recommended. Choose `No`.
## Configure the Clock
The installer will try to auto-detect your time zone; if it chooses correctly, select `Yes`; otherwise, choose `No`, and it will prompt you to select the correct one.
## Partition Disks
Now it's time to partition the disk; you will be shown several options; choose `Manual` partitioning.
1. Use the arrow keys to select the drive (look for a matching size and manufacturer name in the description), and press `Enter`. It will ask you if you want to create a new, empty partition table on the device; choose `Yes`.
2. Your drive will now show as having a single partition, labeled `#1`; select it (it will say `FREE SPACE` beside it), and press `Enter`.
3. Choose `Create a new partition`. By default, the partition size will be the whole drive; leave it as-is, and select `Continue`.
4. When it asks for partition type, go with `Primary`; you'll be taken to a screen with a list of information about your new partition; make sure to fill out each field as follows (using the up and down arrows to navigate, and `Enter` to modify an option):
* Use as: `physical volume for encryption`
* Encryption method: `Device-mapper (dm-crypt)`
* Encryption: `aes`
* key size: `256`
* IV algorithm: `xts-plain64`
* Encryption key: `passphrase`
* Erase data: `Yes`
For the `Erase data` field, only choose `No`, if this is either a new drive that doesn't have any of your plaintext data, or else if it previously had full-disk encryption.
5. Choose `Done setting up the partition`. It will take you back to the main partitioning menu.
6. Choose `Configure encrypted volumes`; the installer will ask if you want to write the changes to disk, and configure the encrypted volumes; choose `Yes`.
7. Select `Create encrypted volumes`.
8. Select your partition with the arrow keys (pressing `Spacebar` will make an `*` appear between the brackets; that's how you know it's been selected). Press `Tab`, and choose `Continue`.
9. Select `Finish`. You will be asked if you really want to erase the drive; choose `Yes` (Erase will take a long time, so be patient. If your old system were encrypted, just let this run for about a minute, and then choose `Cancel`; this will make sure that the LUKS header is completely wiped out).
10. Now you need to enter a passphrase for encrypting the entire disk. Make sure that this is different from your user password that you created earlier, but still use the [diceware](http://world.std.com/~reinhold/diceware.html) method to create it. You will have to enter the password twice; afterwards, you will be returned to the main partitioning menu.
11. You will now see your encrypted device at the top of the device list. It will begin with something like this: `Encrypted volume (sdXY_crypt)`. Choose the partition labeled `#1`.
12. Change the value of `Use as` to `physical volume for LVM`. Then choose `Done setting up the partition`; you will be taken back to the main partitioning menu.
13. Choose `Configure the Logical Volume Manager`. You will be asked if you want to `Keep current partition layout and configure LVM`; choose `Yes`.
14. Choose `Create volume group`. You will have to enter a name for the group; use **matrix**. Select the encrypted partition as the device (by pressing `Spacebar`, which will make an `*` appear between the brackets; that's how you know it's been selected). Press `Tab`, and choose `Continue`.
15. Choose `Create logical volume`. Select the volume group you created in the previous step (i.e., **matrix**), and name it **rootvol**; make the size the entire drive minus 2048 MB (for the swap space). Press `Enter`.
16. Choose `Create logical volume` again, and select **matrix**. Name this one **swap**, and make the size the default value (it should be about 2048MB). Press `Enter`, and then choose `Finish`.
17. Now you are back at the main partitioning screen. You will simply set the mount points and filesystems to use for each partition you just created. Under `LVM VG matrix, LV rootvol`, select the first partition: `#1`. Change the values in this section to reflect the following; then choose `Done setting up partition`:
* use as: `ext4`
* mount point: `/`
18. Under `LVM VG matrix, LV swap`, select the first partition: `#1`. Change the value of `use as` to `swap area`. Choose `Done setting up partition`.
19. Finally, when back at the main partitioning screen, choose `Finish partitioning and write changes to disk`. It will ask you to verify that you want to do this; choose `Yes`.
## Installing the Base System
The hardest part of the installation is done; the installer will now download and install the packages necessary for your system to boot/run. The rest of the process will be mostly automated, but there will be a few things that you have to do yourself.
### Choose a Kernel
It will ask you which kernel you want to use; choose `linux-generic`.
**NOTE: After installation, if you want the most up-to-date version of the Linux kernel (Trisquel's kernel is sometimes outdated, even in the testing distro), you might consider using [this repository](https://jxself.org/linux-libre/) instead. These kernels are also deblobbed, like Trisquel's (meaning there are no binary blobs present).**
### Update Policy
You have to select a policy for installing security updates; I recommend that you choose `Install security updates automatically`, but you can choose not to, if you prefer.
### Choose a Desktop Environment
When prompted to choose a desktop environment, use the arrow keys to navigate the choices, and press `Spacebar` to choose an option; here are some guidelines:
* If you want *GNOME*, choose **Trisquel Desktop Environment**
* If you want *LDXE*, choose **Trisquel-mini Desktop Environment**
* If you want *KDE*, choose **Triskel Desktop Environment**
You might also want to choose some of the other package groups (or none of them, if you want a basic shell); it's up to you. Once you've chosen the option you want, press `Tab`, and then choose `Continue`.
## Install the GRUB boot loader to the master boot record
The installer will ask you if you want to install the GRUB bootloader to the master boot record; choose `Yes`. While you do not need to install GRUB bootloader, since in Libreboot, you are using the GRUB payload on the ROM to boot your syste, you still need to install grub package (preferably `grub-coreboot`) and generate distro's `grub.cfg` with `grub-mkconfig`.
The next window will prompt you to enter a `Device for boot loader installation`. Leave the line blank; press `Tab`, and choose `Continue`.
## System Clock
The installer will ask if your system clock is set to UTC; choose `Yes`.
## Finishing the Installation
The installer will now give you a message that the installation is complete. Choose `Continue`, remove the installation media, and the system will automatically reboot.
## Booting your system manually
At this point, you will have finished the installation. To boot system manually, at your GRUB boot screen, press `C` to get to the command line, and enter the following commands at the `grub>` prompt:
grub> cryptomount -a
grub> set root='lvm/matrix-rootvol'
grub> linux /vmlinuz root=/dev/mapper/matrix-rootvol \
>cryptdevice=/dev/mapper/matrix-rootvol:root
grub> initrd /initrd.img
grub> boot
Without specifying a device, **cryptomount's** `-a` parameter tries to unlock *all* detected LUKS volumes (i.e., any LUKS-encrypted device that is connected to the system). You can also specify `-u` (for a UUID). Once logged into the operating system, you can find the UUID by using the `blkid` command:
sudo blkid
## ecryptfs
If you didn't encrypt your home directory, then you can safely ignore this section; if you did choose to encrypt it, then after you log in, you'll need to run this command:
sudo ecryptfs-unwrap-passphrase
This will be needed in the future, if you ever need to recover your home directory from another system. Write it down, or (preferably) store it using a password manager (I recommend `keepass`,`keepasX`, or `keepassXC`).
## Modify grub.cfg (CBFS)
As the last step of the proccess you *can* modify your **grub.cfg** file (in the firmware), and flash the new configuration, [using this tutorial](grub_cbfs.md); this is so you can make your GRUB configuration much more secure, by following [this guide](grub_hardening.md). This step is entirely optional, libreboot supports FDE scheme without any changes to its grub.cfg.
## Troubleshooting
During boot, some Thinkpads have a faulty DVD drive, which can cause the `cryptomount -a` command to fail, as well as the error `AHCI transfer timed out` (when the Thinkpad X200 is connected to an UltraBase). For both issues, the workaround was to remove the DVD drive (if using the UltraBase, then the whole device must be removed).
Copyright © 2014, 2015 Leah Rowe <info@minifree.org>
Copyright © 2017 Elijah Smith <esmith1412@posteo.net>
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 this license is found in [../fdl-1.3.md](../fdl-1.3.md)

181
site/docs/gnulinux/grub_boot_installer.md Normal file
View File

@ -0,0 +1,181 @@
---
title: Installing GNU+Linux
x-toc-enable: true
...
# Introduction
This guide assumes that you are using the GNU GRUB bootloader directly.
If you're using SeaBIOS, it's quite intuitive and works similarly to other BIOS
software; refer to the documentation on <https://seabios.org/SeaBIOS>.
This guide explains how to prepare a bootable USB for Libreboot systems that
can be used to install several GNU+Linux distributions. For this guide, you
will only need a USB flash drive and the `dd` utility (it's installed into all
GNU+Linux distributions, by default).
These instructions are intended to be generic, applicable to just about any
GNU+Linux distribution.
## Prepare the USB Drive in GNU+Linux
If you downloaded your ISO while on an existing GNU+Linux system, here is how
to create the bootable GNU+Linux USB drive:
Connect the USB drive. Check `lsblk`, to confirm its device name
(e.g., **/dev/sdX**):
lsblk
For this example, let's assume that our drive's name is `sdb`. Make sure that
it's not mounted:
sudo umount /dev/sdb
Overwrite the drive, writing your distro ISO to it with `dd`. For example, if
we are installing *Foobarbaz* GNU+Linux, and it's located in our Downloads
folder, this is the command we would run:
sudo dd if=~/Downloads/foobarbaz.iso of=/dev/sdb bs=8M; sync
That's it! You should now be able to boot the installer from your USB drive
(the instructions for doing so will be given later).
## Prepare the USB drive in NetBSD
[This page](https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/)
on the NetBSD website shows how to create a NetBSD bootable USB drive, from
within NetBSD itself. You should the `dd` method documented there. This will
work with any GNU+Linux ISO image.
## Prepare the USB drive in FreeBSD
[This page](https://www.freebsd.org/doc/handbook/bsdinstall-pre.html) on the
FreeBSD website shows how to create a bootable USB drive for installing
FreeBSD. Use the `dd` method documented. This will work with any GNU+Linux ISO
image.
## Prepare the USB drive in LibertyBSD or OpenBSD
If you downloaded your ISO on a LibertyBSD or OpenBSD system, here is how to
create the bootable GNU+Linux USB drive:
Connect the USB drive. Run `lsblk` to determine which drive it is:
lsblk
To confirm that you have the correct drive, use `disklabel`. For example,
if you thought the correct drive were **sd3**, run this command:
disklabel sd3
Make sure that the device isn't mounted, with `doas`; if it is, this command
will unmount it:
doas umount /dev/sd3i
The `lsblk` command told you what device it is. Overwrite the drive, writing
the OpenBSD installer to it with `dd`. Here's an example:
doas dd if=gnulinux.iso of=/dev/rsdXc bs=1M; sync
That's it! You should now be able to boot the installer from your USB drive
(the instructions for doing so will be given later).
## Debian or Devuan net install
Download the Debian or Devuan net installer. You can download the Debian ISO
from [the Debian homepage](https://www.debian.org/), or the Devuan ISO from
[the Devuan homepage](https://www.devuan.org/).
Secondly, create a bootable USB drive using the commands in
[#prepare-the-usb-drive-in-gnulinux](#prepare-the-usb-drive-in-gnulinux).
Thirdly, boot the USB and enter these commands in the GRUB terminal
(for 64-bit Intel or AMD):
set root='usb0'
linux /install.amd/vmlinuz
initrd /install.amd/initrd.gz
boot
If you are on a 32-bit system (e.g. some Thinkpad X60's) then you will need to
use these commands (this is also true for 32-bit running on 64-bit machines):
set root='usb0'
linux /install.386/vmlinuz
initrd /install.386/initrd.gz
boot
## Booting ISOLINUX Images (Automatic Method)
Boot it in GRUB using the `Parse ISOLINUX config (USB)` option. A new menu
should appear in GRUB, showing the boot options for that distro; this is a GRUB
menu, converted from the usual ISOLINUX menu provided by that distro.
## Booting ISOLINUX Images (Manual Method)
These are generic instructions. They may or may not be correct for your
distribution. You must adapt them appropriately, for whatever GNU+Linux
distribution it is that you are trying to install.
If the `ISOLINUX parser` or `Search for GRUB configuration` options won't work,
then press `C` in GRUB to access the command line, then run the `ls` command:
ls
Get the device name from the above output (e.g., `usb0`). Here's an example:
cat (usb0)/isolinux/isolinux.cfg
Either the output of this command will be the ISOLINUX menuentries for that
ISO, or link to other `.cfg` files (e.g, **/isolinux/foo.cfg**). For example,
if the file found were **foo.cfg**, you would use this command:
cat (usb0)/isolinux/foo.cg`
And so on, until you find the correct menuentries for ISOLINUX.
For Debian-based distros (e.g., Ubuntu, Devuan), there are typically
menuentries listed in **/isolinux/txt.cfg** or **/isolinux/gtk.cfg**. For
dual-architecture ISO images (i686 and x86\_64), there may be separate files
directories for each architecture. Just keep searching through the image,
until you find the correct ISOLINUX configuration file.
**NOTE: Debian 8.6 ISO only lists 32-bit boot options in txt.cfg.
This is important, if you want 64-bit booting on your system. Devuan versions
based on Debian 8.x may also have the same issue.**
Now, look at the ISOLINUX menuentry; it'll look like this:
kernel /path/to/kernel append PARAMETERS initrd=/path/to/initrd ...
GRUB works similarly; here are some example GRUB commands:
set root='usb0'
linux /path/to/kernel PARAMETERS MAYBE_MORE_PARAMETERS
initrd /path/to/initrd
boot
Note: `usb0` may be incorrect. Check the output of the `ls` command (in GRUB),
to see a list of USB devices/partitions. Of course, this will vary from distro
to distro. If you did all of that correctly, then it should now be booting your
USB drive in the way that you specified.
## Troubleshooting
Most of these issues occur when using Libreboot with coreboot's `text-mode`
with libgfxinit for video initialization. This mode is useful for text mode
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 no mode switching support is present (Linux/BSD kernels
do Kernel Mode Setting, so they are able to initialize a frame buffer in bare
metal regardless of whatever coreboot is doing).
### debian-installer Graphical Corruption in Text-Mode (Debian and Devuan)
When using the ROM images that use Coreboot's `text mode`, instead of the
coreboot framebuffer, while using libgfxinit, booting the Debian or Devuan net
installer results in graphical corruption, because it is trying to switch to a
framebuffer while no mode switching support is present. Use this kernel
parameter on the `linux` line, when booting it:
fb=false
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.

179
site/docs/gnulinux/grub_cbfs.md Normal file
View File

@ -0,0 +1,179 @@
---
title: Modifying grub.cfg in CBFS
x-toc-enable: true
...
Before you follow this guide, it is advisable that you have the ability to
flash externally, just in case something goes wrong.
This guide assumes that you use the GNU GRUB bootloader as your default
payload. In this configuration, GNU GRUB is flashed alongside coreboot and runs
on *bare metal* as a native coreboot payload and does *not* use BIOS or UEFI
services (but it *can* load and execute SeaBIOS, in addition to any other
coreboot payload, by chainloading it).
In most circumstances, this guide will not benefit you. Libreboot's default
GRUB configuration file contains scripting logic within it that intelligently
searches for GRUB partitions installed onto a partition on your SSD, HDD or
USB drive installed on your computer. If such a file is found, libreboot's
default GRUB configuration is configured to switch automatically to that
configuration. While not perfect, the logic *does* work with most
configurations.
Therefore, you should only follow *this* guide if the automation (described
above) does not work. It goes without saying that modifying the default GRUB
configuration is risky, because a misconfiguration could create what's called
a *soft brick* where your machine is effectively useless and, in that scenario,
may or may not require external flashing equipment for restoring the machine to
a known state.
Compile flashrom and cbfstool
=============================
Libreboot does not currently distribute utilities pre-compiled. It only
provides ROM images pre-compiled, where feasible. Therefore, you have to build
the utilities from source.
As for the ROM, there are mainly three methods for obtaining a libreboot ROM
image:
1. Dump the contents of the the main *boot flash* on your system, which already
has libreboot installed (with GNU GRUB as the default payload). Extract the
GRUB configuration from *that* ROM image.
2. Extract it from a libreboot ROM image supplied by the libreboot project, on
the libreboot website or mirrors of the libreboot website.
3. Build the ROM yourself, using the libreboot build system. Instructions for
how to do this are covered in the following article:
[How to build libreboot from source](../build/)
In either case, you will use the `cbfstool` supplied in the Libreboot build
system.
This can be found under `coreboot/*/util/cbfstool/` as source code,
where `*` can be any coreboot source code directory for a given mainboard.
The directory named `default` should suffice.
Install the build dependencies. For Ubuntu 20.04 and similar, you can run
the following command in the libreboot build system, from the root directory
of the libreboot Git repository.
./build dependencies ubuntu2004
Then, download coreboot:
./download coreboot
Finally, compile the `cbutils` module:
./build module cbutils
Among other things, this will produce a `cbfstool` executable under any of the
subdirectories in `coreboot/` under `util/cbfstool/cbfstool
For example: `coreboot/default/util/cbfstool/cbfstool`
The `cbfstool` utility is what you shall use. It is used to manipulate CBFS
(coreboot file system) which is a file system contained within the coreboot
ROM image; as a *coreboot distribution*, libreboot inherits this technology.
You will also want to build `flashrom` which libreboot recommends for reading
from and/or writing to the boot flash. In the libreboot build system, you can
build it by running this command:
./build module flashrom
An executable will be available at `flashrom/flashrom` after you have done
this.
Dump the boot flash
===================
If you wish to modify your *existing* libreboot ROM, which was installed on
your computer, you can use `flashrom` to acquire it.
Simply run the following, after using libreboot's build system to compile
flashrom:
sudo ./flashrom/flashrom -p internal -r dump.bin
If flashrom complains about multiple flash chip definitions, do what it says to
rectify your command and run it again.
You may want to use the following, instead of `-p internal`:
`-p internal:laptop=force_I_want_a_brick,boardmismatch=force`
Do not let the word *brick* fools you. This merely disables the safety checks
in flashrom, which is sometimes necessary depending on what ROM was already
flashed, versus the new ROM image.
The `internal` option assumes that internal read/write is possible; this is
when you read from and/or write to the boot flash from an operating systems
(usually GNU+Linux) that is *running on* the target system.
In other cases, you may need to connect an SPI programmer externally (with the
machine powered down) and read the contents of the boot flash.
[Learn how to externally reprogram these chips](../install/spi.md)
Extract grub.cfg
================
Libreboot images that use the GNU GRUB bootloader will have *two* configuration
files in CBFS:
* `grub.cfg`
* `grubtest.cfg`
We recommend that you modify `grubtest.cfg` first, and boot. Select the boot
menu option for loading `grubtest.cfg` and verify that your new config works
correctly. If it doesn't, keep modifying `grubtest.cfg` until it does work.
When that it done, copy the changes over to `grub.cfg
You can use the following commands to modify the contents of CBFS, where
GRUB's configuration file is concerned (dump.bin is the ROM that you dumped,
or it could refer to the libreboot ROM image that you compiled or otherwise
acquired).
Show the contents of CBFS, in your ROM:
cbfstool dump.bin print
Extract `grub.cfg` (substitude with `grubtest.cfg` as desired):
cbfstool dump.bin extract -n grub.cfg -f grub.cfg
You will now have a file named `grub.cfg`.
Make your desired modifications. You should then delete the old `grub.cfg`
from your ROM image.
Insert new grub.cfg
===================
Remove the old `grub.cfg` (substitute with `grubtest.cfg` as desired):
cbfstool dump.bin remove -n grub.cfg
Add your modified `grub.cfg` (substitute with `grubtest.cfg` as desired):
cbfstool dump.bin add -f grub.cfg -n grub.cfg -t raw
Flash the modified ROM image
============================
Your modified `dump.bin` or other modified libreboot ROM can then be re-flashed
using:
sudo ./flashrom -p internal -w dump.bin
If a `-c` option is required, use it and specify a flash chip name. This is
only useful when `flashrom` complains about multiple flash chips being
detected.
If flashrom complains about wrong chip/board, make sure that your ROM is for
the correct system. If you're sure, you can disable the safety checks by running
this instead:
sudo ./flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w dump.bin
If you need to use external flashing equipment, see the link above to the
Raspberry Pi page.

265
site/docs/gnulinux/grub_hardening.md Normal file
View File

@ -0,0 +1,265 @@
---
title: Hardening GNU GRUB
x-toc-enable: true
...
This article only applies to those people who use the GNU GRUB bootloader as
their default payload (options besides GNU GRUB are also available in
Libreboot). Whenever this article refers to GNU GRUB, or configuration files
used in GNU GRUB, it is referring exclusively to those files hosted in CBFS
(coreboot file system) in the Libreboot ROM image. In this configuration, GNU
GRUB is running on *bare metal* as a coreboot payload (instead of relying on
BIOS or UEFI services, like it does on *most* x86 based configurations).
This guide deals with various ways in which you can harden your GNU GRUB
configuration, for security purposes. These steps are optional, but *strongly*
recommended by the Libreboot project.
GNU GRUB provides *many* advanced security features, which most people don't
know about but are fully documented on the Libreboot website. Read on!
This article doesn't cover how to dump your ROM, or flash a new one. Please
read other sections in the Libreboot documentation if you don't know how to do
that. As such, this is an *expert only* guide. There is a great possibility for
bricking your system if you follow this guide incorrectly, or otherwise don't
know what you're doing.
GRUB secure boot with GPG
=========================
GNU GRUB contains code, based on [GnuPG](https://gnupg.org/), that can verify
PGP signatures on *any* type of file, on any storage medium supported by
GNU GRUB (it supports basically everything, including CBFS which is short
for coreboot file system and it is what we will focus on in this article).
We will be using this functionality to verify the signature of a Linux kernel,
at boot time. In conjunction with reproducible builds (both Libreboot and your
Linux kernel), this can greatly improve system security; Debian is an excellent
example of a GNU+Linux distribution that is fully reproducible nowadays (in
stable releases).
For your reference: a reproducible build is one where, given a precise (and
well documented) development setup, the exact same binary can be produced each
time the source code is compiled when that *very same development setup* is
replicated by another person. In other words, the file checksum (e.g.
SHA512 hash) will be exactly the same at all times. In practise, this means
that metadata such as time stamps are not included in the binary, or if they
are, they are constant (in many scenarios, it's based on the date of a Git
commit ID that the build is based on, if the software is built from a Git
repository). More information about reproducible builds can be found here:
<https://reproducible-builds.org/>
Reproducibility is a key goal of the Libreboot project, though it has not yet
achieved that goal. However, it is an important part of any secure system. We
suggest that, when securing your Libreboot system as instructed by this guide,
you should also use a reproducible GNU+Linux distribution (because checking GPG
signatures on a non-reproducible binary, such as a Linux kernel, is meaningless
if that binary can be compromised as a result of literally not being able to
verify that the source code *actually* corresponds to the provided binary,
which is exactly what reproducible builds allow). If *someone else* compiles an
executable for you, and that executable is non-reproducible, you have no way to
verify that the source code they provided *actually* corresponds to the binary
they gave you. Based on these facts, we can observe that checking GPG
signatures will improve your *operational* security, but only in specific
circumstances under *controlled conditions*.
This tutorial assumes you have a Libreboot image (ROM) that you wish to modify,
which from now on we will refer to simply as *`my.rom`*. It should go without
saying that this ROM uses the GNU GRUB bootloader as payload. This page shows
how to modify grubtest.cfg, which means that signing and password protection
will work after switching to it in the main boot menu and bricking due to
incorrect configuration will be impossible. After you are satisfied with the
new setup, you should transfer the new settings to grub.cfg to make your
machine truly secure.
First, extract the old grubtest.cfg and remove it from the Libreboot
image:
cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
cbfstool my.rom remove -n grubtest.cfg
You can build `cbfstool` in the Libreboot build system. Run this command:
./build module cbutils
This assumes that you already downloaded coreboot:
./download coreboot
This, in turn, assumes that you have installed the build dependencies for
Libreboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
./build dependencies ubuntu2004
The `cbfstool` executables will be under each coreboot directory, under
each `coreboot/boardname/` directory for each board. Just pick one, presumably
from the coreboot directory for your board. Libreboot creates multiple coreboot
archives for different board revisions, on different boards.
References:
* [GRUB manual](https://www.gnu.org/software/grub/manual/html_node/Security.html#Security)
* [GRUB info pages](http://git.savannah.gnu.org/cgit/grub.git/tree/docs/grub.texi)
* [SATA connected storage considered dangerous.](../../faq.md#hddssd-firmware)
* [Coreboot GRUB security howto](https://www.coreboot.org/GRUB2#Security)
GRUB Password
=============
The security of this setup depends on a good GRUB password as GPG signature
checking can be disabled through the interactive console:
set check_signatures=no
This is useful because it allows you to occasionally boot unsigned live CD/USB
media and such. You might consider supplying signatures on a USB stick, but the
signature checking code currently looks for `/path/to/filename.sig` when
verifying `/path/to/filename` and, as such, it will be impossible to supply
signatures in any other location (unless the software is modified accordingly).
It's worth noting that this is not your LUKS password but, rather, a password
that you must enter in order to use *restricted* functionality (such as the
GNU GRUB terminal for executing commands). This behaviour protects your system
from an attacker simply booting a live USB key (e.g. live GNU+Linux
distribution) for the purpose of flashing modified boot firmware, which from
your perspective is *compromised* boot firmware. *This should be different than
your LUKS passphrase and user password.*
GNU GRUB supports storing salted, hashed passwords in the configuration file.
This is a far more secure configuration, because an attacker cannot simply read
your password as *plain text* inside said file.
Use of the *diceware method* is *strongly* recommended, for generating secure
passphrases (as opposed to passwords). The diceware method involves rolling
dice to generate random numbers, which are then used as an index to pick a
random word from a large dictionary of words. You can use any language (e.g.
English, German). Look it up on a search engine. Diceware method is a way to
generate secure passphrases that are very hard (almost impossible, with enough
words) to crack, while being easy enough to remember. On the other hand, most
kinds of secure passwords are hard to remember and easier to crack. Diceware
passphrases are harder to crack because of far higher entropy (there are many
words available to use, but only about 50 commonly used symbols in
pass*words*). This high level of entropy is precisely what makes such pass
phrases secure, even if an attacker knows exactly which dictionary you used!
The GRUB password can be stored in one of two ways:
* plaintext
* protected with [PBKDF2](https://en.wikipedia.org/wiki/Pbkdf2)
We will *obviously* use the latter method. Generating the PBKDF2 derived key is
done using the `grub-mkpasswd-pbkdf2` utility. You can get it by
installing GRUB version 2. Generate a key by giving it a password:
NOTE: This utility is included under the `grub/` directory, when you build
GRUB using the Libreboot build system. Run the following commands (assuming
you have the correct build dependencies installed) to build GNU GRUB, from the
Libreboot Git repository:
./download grub
./build module grub
The following executable will then be available under the `grub/` directory:
grub-mkpasswd-pbkdf2
Its output will be a string of the following form:
grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS
Now open my.grubtest.cfg and put the following before the menu entries
(prefered above the functions and after other directives). Of course use
the pbdkf string that you had generated yourself:
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
Obviously, replace it with the correct hash that you actually obtained for the
password you entered. In other words, *do not use the hash that you see above!*
With this configuration in place, you must now enter the passphrase *every
single time you boot your computer*. This completely restricts an attacker in
such a way that they cannot simply boot an arbitrary operating system on your
computer. NOTE: An attacker could still open your system and re-flash new
firmware externally. You should implement some detection mechanism, such as
epoxy applied in a *random pattern* on every screw; this slows down the attack
and means that you will know someone tampered with it because they cannot
easily re-produce the exact same blob of epoxy in the same pattern (when you
apply it, swirl it around a bit for a few minutes while it cures. The purpose
is not to prevent disassembly, but to slow it down and make it detectable when
it has occured).
Another good thing to do, if we chose to load signed on-disk GRUB
configurations, is to remove (or comment out) `unset superusers` in
function try\_user\_config:
function try_user_config {
set root="${1}"
for dir in boot grub grub2 boot/grub boot/grub2; do
for name in '' autoboot_ libreboot_ coreboot_; do
if [ -f /"${dir}"/"${name}"grub.cfg ]; then
#unset superusers
configfile /"${dir}"/"${name}"grub.cfg
fi
done
done
}
The `unset superusers` command disables password authentication, which will
allow the attacker to boot an arbitrary operating system, regardless of
signature checking. The default Libreboot configuration is tweaked for *easy of
use* by end users, and it is *not* done with security in mind (though security
is preferred). Thus, Libreboot is less restrictive by default. What you are
doing, per this article, is making your system *more secure* but at the expense
of user-friendliness.
That just about covers it, where password setup is concerned!
GPG keys
========
First, generate a GPG keypair to use for signing. Option RSA (sign only)
is ok.
WARNING: GRUB does not read ASCII armored keys. When attempting to
trust ... a key filename it will print `error: bad signature` on the screen.
mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key
Now that we have a key, we can sign some files with it. We must sign:
- a kernel
- (if we have one) an initramfs
- (if we wish to transfer control to it) an on-disk `grub.cfg`
- `grubtest.cfg` (so that you can go back to `grubtest.cfg` after signature
checking is enforced. You can always get back to `grub.cfg` by pressing ESC,
but, afterwards, `grubtest.cfg` is not signed and it will not load.
Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `libreboot_grub.cfg`. We will sign them by running the following
commands:
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign libreboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
Of course, some further modifications to my.grubtest.cfg will be required. We
need to *trust* the key and enable signature enforcement (put this before menu
entries):
trust (cbfsdisk)/boot.key
set check_signatures=enforce
What remains now is to include the modifications into the Libreboot image
(ROM):
cbfstool my.rom add -n boot.key -f boot.key -t raw
cbfstool my.rom add -n grubtest.cfg -f my.grubtest.cfg -t raw
cbfstool my.rom add -n grubtest.cfg.sig -f my.grubtest.cfg.sig -t raw
Now, flash it. If it works, copy it over to `grub.cfg` in CBFS.

370
site/docs/gnulinux/guix_system.md Normal file
View File

@ -0,0 +1,370 @@
---
title: Encrypted Guix GNU+Linux
x-toc-enable: true
...
Objective
=========
To provide step-by-step guide for setting up guix system (stand-alone guix)
with full disk encryption (including /boot) on devices powered by Libreboot.
Scope
=====
Any users, for their generalised use cases, need not stumble away from this
guide to accomplish the setup.
Advanced users, for deviant use cases, will have to explore outside this
guide for customisation; although this guide provides information that is
of paramount use.
Process
=======
Preparation
-----------
In your current GNU+Linux System, open terminal as root user.
Insert USB drive and get the USB device name /dev/sdX, where “X” is the
variable to make a note of.
lsblk
Unmount the USB drive just in case if it’s auto-mounted.
umount /dev/sdX
Download the latest (a.b.c) Guix System ISO Installer Package (sss) and
it’s GPG Signature; where “a.b.c” is the variable for version number and
“sss” is the variable for system architecture.
wget https://ftp.gnu.org/gnu/guix/guix-system-install-a.b.c.sss-linux.iso.xz
wget https://ftp.gnu.org/gnu/guix/guix-system-install-a.b.c.sss-linux.iso.xz.sig
Import required public key.
gpg --keyserver pool.sks-keyservers.net --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
Verify the GPG Signature of the downloaded package.
gpg --verify guix-system-install-a.b.c.sss-linux.iso.xz.sig
Extract the ISO Image from the downloaded package.
xz -d guix-system-install-a.b.c.sss-linux.iso.xz
Write the extracted ISO Image to the USB drive.
dd if=guix-system-install-a.b.c.sss-linux.iso of=/dev/sdX; sync
Reboot the device.
reboot
Pre-Installation
----------------
On reboot, as soon as you see the Libreboot Graphic Art, press arrow keys
to change the menu entry.
Choose “Search for GRUB2 configuration on external media [s]” and wait
for the Guix System from USB drive to load.
Set your keyboard layout lo, where “lo” is the two-letter keyboard layout
code (example: us or uk).
loadkeys lo
Unblock network interfaces (if any).
rfkill unblock all
Get the names of your network interfaces.
ifconfig -a
Bring your required network interface nwif (wired or wireless) up, where
“nwif” is the variable for interface name. For wired connections,
this should be enough.
ifconfig nwif up
For wireless connection, create a configuration file using text editor,
where “fname” is the variable for any desired filename.
nano fname.conf
Choose, type and save ONE of the following snippets, where ‘nm’ is the
name of the network you want to connect, ‘pw’ is the corresponding
network’s password or passphrase and ‘un’ is user identity.
For most private networks:
network={
ssid="nm"
key_mgmt=WPA-PSK
psk="pw"
}
(or)
For most public networks:
network={
ssid="nm"
key_mgmt=NONE
}
(or)
For most organisational networks:
network={
ssid="nm"
scan_ssid=1
key_mgmt=WPA-EAP
identity="un"
password="pw"
eap=PEAP
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}
Connect to the configured network, where “fname” is the filename and
“nwif” is the network interface name.
wpa_supplicant -c fname.conf -i nwif -B
Assign an IP address to your network interface, where “nwif” is the
network interface name.
dhclient -v nwif
Obtain the device name /dev/sdX in which you would like to deploy and
install Guix System, where “X” is the variable to make a note of.
lsblk
Wipe the respective device. Wait for the command operation to finish.
dd if=/dev/urandom of=/dev/sdX; sync
Load device-mapper module in the current kernel.
modprobe dm_mod
Partition the respective device. Just do, GPT --> New --> Write --> Quit;
defaults will be set.
cfdisk /dev/sdX
Encrypt the respective partition.
cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --iter-time 500 --use-random --verify-passphrase luksFormat /dev/sdX1
Obtain and note down the “LUKS UUID”.
cryptsetup luksUUID /dev/sdX1
Open the respective encrypted partition, where “partname” is any
desired partition name.
cryptsetup luksOpen /dev/sdX1 partname
Make filesystem on the respective partition, where “fsname” is any
desired filesystem name.
mkfs.btrfs -L fsname /dev/mapper/partname
Mount the respective filesystem under the current system.
mount LABEL=fsname /mnt
Create a btrfs-supported NOCOW swap file with no compression and make it
readable cum writable only by root.
touch /mnt/swapfile`
chattr +C /mnt/swapfile`
btrfs property set /mnt/swapfile compression none`
dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=2048
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile
Installation
------------
Make the installation packages to be written on the respective
mounted filesystem.
herd start cow-store /mnt
Create the required directory.
mkdir /mnt/etc
Create, edit and save the configuration file by typing the following
code snippet. WATCH-OUT for variables in the code snippet and
replace them with your relevant values.
nano /mnt/etc/config.scm
Snippet:
(use-modules
(gnu)
(gnu system nss))
(use-service-modules
xorg
desktop)
(use-package-modules
certs
gnome)
(operating-system
(host-name "hostname")
(timezone "Zone/SubZone")
(locale "ab_XY.1234")
(keyboard-layout
(keyboard-layout
"xy"
"altgr-intl"))
(bootloader
(bootloader-configuration
(bootloader
(bootloader
(inherit grub-bootloader)
(installer #~(const #t))))
(keyboard-layout keyboard-layout)))
(mapped-devices
(list
(mapped-device
(source
(uuid "luks-uuid"))
(target "partname")
(type luks-device-mapping))))
(file-systems
(append
(list
(file-system
(device
(file-system-label "fsname"))
(mount-point "/")
(type "btrfs")
(dependencies mapped-devices)))
%base-file-systems))
(users
(append
(list
(user-account
(name "username")
(comment "Full Name")
(group "users")
(supplementary-groups '("wheel" "netdev" "audio" "video" "lp" "cdrom" "tape" "kvm"))))
%base-user-accounts))
(packages
(append
(list
nss-certs)
%base-packages))
(services
(append
(list
(extra-special-file "/usr/bin/env"
(file-append coreutils "/bin/env"))
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)))
(service gnome-desktop-service-type))
%desktop-services))
(name-service-switch %mdns-host-lookup-nss))
Initialise new Guix System.
guix system init /mnt/etc/config.scm /mnt
Reboot the device.
reboot
Post-Installation
------------
On reboot, as soon as you see the Libreboot Graphic Art, choose
the option 'Load Operating System [o]'
Enter LUKS Key, for Libreboot's grub, as prompted.
You may have to go through warning prompts by repeatedly
pressing the "enter/return" key.
You will now see guix's grub menu from which you can go with the
default option.
Enter LUKS Key again, for kernel, as prompted.
Upon GNOME Login Screen, login as "root" with password field empty.
Open terminal from the GNOME Dash.
Set passkey for "root" user. Follow the prompts.
passwd root
Set passkey for "username" user. Follow the prompts.
passwd username
Update the guix distribution. Wait for the process to finish.
guix pull
Update the search paths.
export PATH="$HOME/.config/guix/current/bin:$PATH"
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
Update the guix system. Wait for the process to finish.
guix system reconfigure /etc/config.scm
Reboot the device.
reboot
Conclusion
==========
Everything should be stream-lined from now. You can follow your
regular boot steps without requiring manual intervention. You can
start logging in as regualar user with the respective "username".
You will have to periodically (at your convenient time) login as root
and do the update/upgrade part of post-installation section, to keep your
guix distribution and guix system updated.
That is it! You have now setup guix system with full-disk encryption
on your device powered by Libreboot. Enjoy!
References
==========
[1] Guix Manual (http://guix.gnu.org/manual/en/).
Acknowledgements
================
[1] Thanks to Guix Developer, Clement Lassieur (clement@lassieur.org),
for helping me with the Guile Scheme Code for the Bootloader Configuration.

67
site/docs/gnulinux/index.md Normal file
View File

@ -0,0 +1,67 @@
---
title: GNU+Linux installation guides
x-toc-enable: true
...
This page is useful for those who wish to use the GRUB GRUB payload directly.
If you're using SeaBIOS, the boot process will work similarly to traditional
BIOS systems; refer to the SeaBIOS documentation
on <https://seabios.org/SeaBIOS>
GNU+Linux is the operating system of choice, for Libreboot development. It is
highly recommended over any other operating system, precisely because it consists
of [Free Software](https://www.gnu.org/philosophy/free-sw.html) (free as in
freedom). There *are* other free operating systems, such as BSD, but most of
the software in a typical GNU+Linux system is also *copylefted*. To learn more
about the importance of copyleft, read this page on the GNU website:
<https://www.gnu.org/licenses/copyleft.html>
Useful links
============
Refer to the following pages:
* [How to Prepare and Boot a USB Installer in Libreboot Systems](grub_boot_installer.md)
* [Modifying the GRUB Configuration in Libreboot Systems](grub_cbfs.md)
* [Guix System with Full-Disk Encryption on Libreboot](guix_system.md)
* [Installing Parabola or Arch GNU+Linux-Libre, with Full-Disk Encryption (including /boot)](encrypted_parabola.md)
* Follow-Up Tutorial: [Configuring Parabola (Post-Install)](configuring_parabola.md)
* [Installing Hyperbola GNU+Linux, with Full-Disk Encryption (including /boot)](https://wiki.hyperbola.info/en:guide:encrypted_installation)
* [Installing Trisquel GNU+Linux-Libre, with Full-Disk Encryption (including /boot)](encrypted_trisquel.md)
* [Installing Debian or Devuan GNU+Linux-Libre, with Full-Disk Encryption (including /boot)](encrypted_debian.md)
* [How to Harden Your GRUB Configuration, for Security](grub_hardening.md)
Fedora won't boot?
==================
This may also apply to CentOS or Redhat. Chroot guide can be found on
[fedora website](https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#restoring-bootloader-using-live-disk)
linux16 issue
-------------
When you use Libreboot's default GRUB config, and libreboot's grub uses fedora's
default `grub.cfg` (in `/boot/grub2/grub.cfg`), fedora by default makes use of the
`linux16` command, whereas it should be saying `linux`
Do this in fedora:
Open `/etc/grub.d/10_linux`
Set the `sixteenbit` variable to an empty string, then run:
grub2-mkconfig -o /boot/grub2/grub.cfg
BLS issue
---------
With [newer versions of fedora](https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault),
scripts from grub package default to generating [BLS](https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/)
instead of `grub.cfg`. To change that behaviour add following line
to `/etc/default/grub` (or modify existing one if it already exists):
GRUB_ENABLE_BLSCFG=false
Then generate `grub.cfg` with:
grub2-mkconfig -o /boot/grub2/grub.cfg

52
site/docs/grub/index.md Normal file
View File

@ -0,0 +1,52 @@
---
title: GRUB payload
x-toc-enable: true
...
TODO: this guide should be reviewed and updated. Some info might be out of
date.
[GNU GRUB](https://www.gnu.org/software/grub/) already has excellent
documentation, but there are aspects of Libreboot that deserve special
treatment. Libreboot provides the option to boot GNU GRUB directly, running on
bare metal (instead of using BIOS or UEFI services).
[The GNU+Linux section](../gnulinux/) also has Libreboot-specific guides for
dealing with GNU+Linux distributions when using GNU GRUB directly, in this
setup. [A similar section exists for BSD operating systems](../bsd/)
GRUB keyboard layouts
=====================
It is possible to use *any* keymap in GNU GRUB.
Custom keyboard layout
----------------------
Keymaps are stored in `resources/grub/keymap/`
You can use the `ckbcomp` program to generate a keymap, based on Xorg keymap
files:
ckbcomp fr > frazerty
When you build GRUB from source, you can use the `grub-mklayout` program to
create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
When you've built GRUB, using `lbmk` (libreboot build system), take your kepmap
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
cat frazerty | ./grub/grub-mklayout -o frazerty.gkb
Place the newly created `.gkb` file under `resources/grub/keymap` in lbmk. When
you build Libreboot, a ROM image with GRUB payload and your newly created
keymap will be available under the `bin/` directory.
[Learn how to build Libreboot ROM images](../build/)
Many keymaps exist in the Libreboot build system, but sometimes you must
manually tweak the file created by `ckbcomp`, adjusting the scan codes in that
file, before converting to a GRUB keymap file. Therefore, it would be unwise to
automatically add all keymaps in GRUB.
If you've added a keymap to lbmk, and it works,
[please submit a patch!](../../git.md)

183
site/docs/hardware/c201.md Normal file
View File

@ -0,0 +1,183 @@
---
title: ASUS Chromebook C201
x-toc-enable: true
...
NOTE: support for this machine is dropped in recent Libreboot releases. It will
be re-added at a later date. For now, please use Libreboot 20160907 on this
machine.
NOTE: much of this page is outdated. for instance, it references cafe beverage
who later revealed herself to be Alyssa Rosenzweig, who then launched the
Panfrost project.
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.
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
Google's intent with CrOS devices
==================================
CrOS (Chromium OS/Chrome OS) devices, such as Chromebooks, were not
designed with the intent of bringing more freedom to users. However,
they run with a lot of free software at the boot software and embedded
controller levels, since free software gives Google enough flexibility
to optimize various aspects such as boot time and most importantly, to
implement the CrOS security system, that involves various aspects of the
software. Google does hire a lot of Coreboot developers, who are
generally friendly to the free software movement and try to be good
members of the free software community, by contributing code back.
CrOS devices are designed (from the factory) to actually coax the user
into using proprietary web services (SaaSS) that invade the user's
privacy (ChromeOS is literally just the Google Chrome browser when you
boot up, itself proprietary and comes with proprietary add-ons like
flash. It's only intended for SaaSS, not actual, real computing).
Google is even a member of the *PRISM* program, as outlined by Edward
Snowden. See notes about ChromeOS below. The libreboot project
recommends that the user replace the default *ChromeOS* with a
distribution that can be used in freedom, without invading the user's
privacy.
We also use a similar argument for the MacBook and the ThinkPads that
are supported in libreboot. Those laptops are supported, in spite of
Apple and Lenovo, companies which are actually *hostile* to the free
software movement.
Considerations about ChromeOS and free operating systems
========================================================
This laptop comes preinstalled (from the factory) with Google ChromeOS.
This is a GNU+Linux distribution, but it's not general purpose and it
comes with proprietary software. It's designed for SaaSS. Libreboot
recommends that users of this laptop replace it with another
distribution.
Debian GNU+Linux
----------------
<https://wiki.debian.org/InstallingDebianOn/Asus/C201> shows how to
install Debian.
Devuan GNU+Linux
----------------
<https://notabug.org/dimkr/devsus> produces bootable and installable
Devuan images.
Parabola GNU+Linux
------------------
See:
<https://lists.gnu.org/archive/html/libreboot/2015-12/msg00026.html>
In this discussion thread (on the old GNU Libreboot mailing lists), there are
instructions for installing Parabola on C201 and other rockchip chromebooks
supported by Libreboot.
Caution: Video acceleration requires a non-free blob, software rendering can be used instead.
=============================================================================================
The C201 has a Mali T GPU, which requires a non-free blob. A driver,
Tamil, was written, but its source code has not been released. The
developer has so-far [withheld
it](http://libv.livejournal.com/27461.html). Use software rendering to
avoid the blob instead. Most tasks can still be performed without video
acceleration, without any noticeable performance penalty.
In practise, this means that certain things like games, blender and
GNOME shell (or other fancy desktops) won't work well. The libreboot
project recommends a lightweight desktop which does not need video
acceleration, such as *XFCE* or *LXDE*.
As it is unlikely that Tamil will be released, the
[chai](https://notabug.org/cafe/chai) project is writing a driver as
well. Ask on IRC if you think you can contribute.
Caution: WiFi requires a non-free blob, a USB dongle can be used instead.
=========================================================================
These laptops have non-removeable (soldered on) M.2 Type 1216 card
with WiFi+Bluetooth, which requires non-free firmware to be loaded by
the Linux kernel in order to work.
The libreboot project recommends using an external USB wifi dongle that
works with free software. See
[\#recommended\_wifi](./#recommended_wifi).
There are 2 companies (endorsed by Free Software Foundation, under their
*Respects your Freedom* guidelines), that sell USB WiFi dongles
guaranteed to work with free software (i.e. linux-libre kernel):
- [ThinkPenguin sells
them](https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb)
(company based in USA)
- [Tehnoetic sells
them](https://tehnoetic.com/tehnoetic-wireless-adapter-gnu-linux-libre-tet-n150)
(company based in Europe)
These wifi dongles use the AR9271 (atheros) chipset, supported by the
free *ath9k\_htc* driver in the Linux kernel. They work in *linux-libre*
too.
EC firmware is free software!
=============================
It's free software. Google provides the source. Build scripts will be
added later, with EC sources provided in libreboot, and builds of the EC
firmware.
This is unlike the other current libreboot laptops (Intel based). In
practise, you can (if you do without the video/wifi blobs, and replace
ChromeOS with a distribution that respects your freedom) be more free
when using one of these laptops.
The libreboot FAQ briefly describes what an *EC* is:
[../../faq.md#firmware-ec](../../faq.md#firmware-ec)
No microcode!
=============
Unlike x86 (e.g. Intel/AMD) CPUs, ARM CPUs do not use microcode, not
even built in. On the Intel/AMD based libreboot systems, there is still
microcode in the CPU (not considered problematic by the FSF, provided
that it is reasonably trusted to not be malicious, since it's part of
the hardware and read-only), but we exclude microcode updates (volatile
updates which are uploaded at boot time by the boot firmware, if
present), which are proprietary software.
On ARM CPUs, the instruction set is implemented in circuitry, without
microcode.
Depthcharge payload
===================
These systems do not use the GRUB payload. Instead, they use a payload
called depthcharge, which is common on CrOS devices. This is free
software, maintained by Google.
Flash chip write protection: the screw
======================================
It's next to the flash chip. Unscrew it, and the flash chip is
read-write. Screw it back in, and the flash chip is read-only. It's
called the screw.
*The screw* is accessible by removing other screws and gently prying off
the upper shell, where the flash chip and the screw are then directly
accessible. User flashing from software is possible, without having to
externally re-flash, but the flash chip is SPI (SOIC-8 form factor) so
you can also externally re-flash if you want to. In practise, you only
need to externally re-flash if you brick the laptop; read
[../install/spi.md](../install/spi.md) for an example
of how to set up an SPI programmer.
Write protection is useful, because it prevents the firmware from being
re-flashed by any malicious software that might become executed on your
GNU+Linux system, as root. In other words, it can prevent a
firmware-level *evil maid* attack. It's possible to write protect on
all current libreboot systems, but CrOS devices make it easy. The screw
is such a stupidly simple idea, which all designs should implement.

17
site/docs/hardware/d510mo.md Normal file
View File

@ -0,0 +1,17 @@
---
title: Intel D510MO and D410PT desktop boards
...
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.
NOTE: D410PT is another name and it's the same board. Flash the exact same
ROM and it should work.
NOTE: This board has a working framebuffer in Grub, but in GNU+Linux in
native resolution the display is unusable due to some raminit issues.
This board can however be used for building a headless server.
Flashing instructions can be found at
[../install/d510mo.md](../install/d510mo.md)

78
site/docs/hardware/d945gclf.md Normal file
View File

@ -0,0 +1,78 @@
---
title: Intel D945GCLF desktop board
x-toc-enable: true
...
If you just want flashing instructions, go to
[../install/d945gclf.md](../install/d945gclf.md)
Introduction
============
This board is a mini-itx desktop board for 2008. It uses an atom 230,
which is a singe core CPU but it is hyperthreaded so it appears to have
2 thread to the OS. The flash chip is very small, 512KiB, so grub2 does
not fit, which is why libreboot has to use seabios on this target. Full
disk encryption like on other supported targets will not be possible, so
plan accordingly.
This board has a 945gc chipset which is the desktop equivalent of 945gm
which can be found in the Lenovo x60/t60 or macbook2,1. This chipset
features an ICH7 southbridge. It has 1 DIMM slot that can accommodate up
to 2G of DDR2 RAM.
Connectivity-wise it has 1 PCI slot, a 10/100 ethernet port, 4 usb slot
and 4 usb ports, with one internal header and 2 SATA ports.
The D945GCLF2 is an upgraded version of this board. The differences are:
1 more USB header, 10/100/1000 ethernet and a dual core cpu (also
hyperthreaded). Since the board is almost identical (and coreboot code
seem to indicate that it works, since MAX\_CPU=4 is set), it is believed
that it should also work but this is untested.
Remarks about vendor bios:
--------------------------
- Without coreboot/libreboot this board is utery useless, since the
vendor bios is very bad. It cannot boot from any HDD whether it is
connected to the SATA port or USB. With libreboot it works just
fine.
- The vendor bios write protects the flash so it requires external
flashing to install libreboot on this device. Once libreboot is
flashed there is no problem to update the firmware internally
Here is an image of the board:\
![](https://av.libreboot.org/d945gclf/d945gclf.jpg)\
Here is an image of the D945GCLF2 board:\
![](https://av.libreboot.org/d945gclf/20160923_141521.jpg){width="80%" height="80%"}\
And SPI SOIC8 flash chip\
![](https://av.libreboot.org/d945gclf/20160923_141550.jpg){width="50%" height="50%"}
How to replace thermal paste and fan
------------------------------------
This board comes with very crappy disposable loud fan, that one has no
bearings, which can not be repaired or oiled properly, do not waste your
time trying to fix it, just buy one chinese same size fan\
![](https://av.libreboot.org/d945gclf/20160923_141620.jpg){width="50%" height="50%"}
![](https://av.libreboot.org/d945gclf/20160923_141614.jpg){width="50%" height="50%"}\
Make sure that new one has same wiring\
![](https://av.libreboot.org/d945gclf/20160923_142618.jpg){width="50%" height="50%"}\
This is a new one, with bearing and maintenable\
![](https://av.libreboot.org/d945gclf/20160923_141738.jpg){width="50%" height="50%"}
![](https://av.libreboot.org/d945gclf/20160923_141814.jpg){width="50%" height="50%"}\
Now remove the both coolers rotating them a bit, slowly, then clean both
silicons and both coolers (removing cmos battery first is recommended)\
![](https://av.libreboot.org/d945gclf/20160923_141601.jpg){width="50%" height="50%"}\
Put a little bit of non conductive thermal paste on both silicons (only
cpu silicon iis shown on that image)\
![](https://av.libreboot.org/d945gclf/20160923_142031.jpg){width="50%" height="50%"}\
Before assembling new fan, some need new longer screws, make sure having
these (on the left is original one, too short for new fan)\
![](https://av.libreboot.org/d945gclf/20160923_141659.jpg){width="50%" height="50%"}\
After that, assemble your new fan into CPU cooler\
![](https://av.libreboot.org/d945gclf/20160923_141635.jpg){width="50%" height="50%"}\
Finally assemle both coolers on both chips, do not forget put in the CPU
fan connector back, and you are done.

37
site/docs/hardware/ga-g41m-es2l.md Normal file
View File

@ -0,0 +1,37 @@
---
title: Gigabyte GA-G41M-ES2L desktop board
...
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.
You need to set a custom MAC address in GNU+Linux for the NIC to work.
In /etc/network/interfaces on debian-based systems like Debian or
Devuan, this would be in the entry for your NIC:\
hwaddress ether macaddressgoeshere
Alternatively:
cbfstool libreboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
Modify the MAC address in the file `rt8168-macaddress` and then:
cbfstool libreboot.rom remove -n rt8168-macaddress
cbfstool libreboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
Now you have a different MAC address hardcoded. In the above example, the ROM
image is named `libreboot.rom` for your board. You can find cbfstool
under `coreboot/default/util/cbfstool/` after running the following command
in the build system:
./build module cbutils
You can learn more about using the build system, lbmk, here:\
[Libreboot build instructions](../build/)
Flashing instructions can be found at
[../install/](../install/)

0
site/docs/hardware/hwdumps/x200/biosdecode.err.log Normal file
View File

24
site/docs/hardware/hwdumps/x200/biosdecode.log Normal file
View File

@ -0,0 +1,24 @@
# biosdecode 2.12
VPD present.
BIOS Build ID: 6DET65WW
Box Serial Number: L3AAR0B
Motherboard Serial Number: 1ZFDS89N4DD
Machine Type/Model: 7459GW4
SMBIOS 2.4 present.
Structure Table Length: 2464 bytes
Structure Table Address: 0x000E0010
Number Of Structures: 68
Maximum Structure Size: 120 bytes
BIOS32 Service Directory present.
Revision: 0
Calling Interface Address: 0x000FDC80
ACPI 2.0 present.
OEM Identifier: LENOVO
RSD Table 32-bit Address: 0x79B5B843
XSD Table 64-bit Address: 0x0000000079B5B8AB
PNP BIOS 1.0 present.
Event Notification: Not Supported
Real Mode 16-bit Code Address: E2CA:1868
Real Mode 16-bit Data Address: 0040:0000
16-bit Protected Mode Code Address: 0x000F97BD
16-bit Protected Mode Data Address: 0x00000400

208
site/docs/hardware/hwdumps/x200/codec#0 Normal file
View File

@ -0,0 +1,208 @@
Codec: Conexant CX20561 (Hermosa)
Address: 0
AFG Function Id: 0x1 (unsol 1)
MFG Function Id: 0x2 (unsol 1)
Vendor Id: 0x14f15051
Subsystem Id: 0x17aa20ff
Revision Id: 0x100000
Modem Function Group: 0x2
Default PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
Power states: D0 D1 D2 D3 CLKSTOP
Power: setting=D0, actual=D0
GPIO: io=4, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
Control: name="Speaker Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Speaker Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Device: name="CX20561 Analog", type="Audio", device=0
Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=0
Amp-Out vals: [0x4a 0x4a]
Converter: stream=8, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Node 0x11 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L
Control: name="Headphone Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Headphone Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=0
Amp-Out vals: [0x4a 0x4a]
Converter: stream=8, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Node 0x12 [Audio Output] wcaps 0x211: Stereo Digital
Control: name="IEC958 Playback Con Mask", index=0, device=0
Control: name="IEC958 Playback Pro Mask", index=0, device=0
Control: name="IEC958 Playback Default", index=0, device=0
Control: name="IEC958 Playback Switch", index=0, device=0
Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
Device: name="CX20561 Digital", type="SPDIF", device=1
Converter: stream=8, channel=0
Digital:
Digital category: 0x0
IEC Coding Type: 0x0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Node 0x13 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Control: name="Beep Playback Volume", index=0, device=0
ControlAmp: chs=1, dir=Out, idx=0, ofs=0
Control: name="Beep Playback Switch", index=0, device=0
ControlAmp: chs=1, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0
Amp-Out vals: [0x00]
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
Device: name="CX20561 Analog", type="Audio", device=0
Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=0
Amp-In vals: [0x50 0x50] [0x50 0x50]
Converter: stream=4, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 2
0x1d* 0x17
Node 0x15 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L
Control: name="Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=1, ofs=0
Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=0
Amp-In vals: [0x50 0x50]
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 1
0x18
Node 0x16 [Pin Complex] wcaps 0x400581: Stereo
Control: name="Headphone Jack", index=0, device=0
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x042140f0: [Jack] HP Out at Ext Right
Conn = 1/8, Color = Green
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=02, enabled=1
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 2
0x10 0x11*
Node 0x17 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
Control: name="Dock Mic Boost Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Control: name="Dock Mic Jack", index=0, device=0
Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00001224: IN Detect
Vref caps: 50 80
Pin Default 0x61a190f0: [N/A] Mic at Sep Rear
Conn = 1/8, Color = Pink
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=03, enabled=1
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Node 0x18 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
Control: name="Mic Boost Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Control: name="Mic Jack", index=0, device=0
Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00001224: IN Detect
Vref caps: 50 80
Pin Default 0x04a190f0: [Jack] Mic at Ext Right
Conn = 1/8, Color = Pink
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=04, enabled=1
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Node 0x19 [Pin Complex] wcaps 0x400581: Stereo
Control: name="Dock Headphone Jack", index=0, device=0
Pincap 0x00000014: OUT Detect
Pin Default 0x612140f0: [N/A] HP Out at Sep Rear
Conn = 1/8, Color = Green
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x40: OUT
Unsolicited: tag=01, enabled=1
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 2
0x10 0x11*
Node 0x1a [Pin Complex] wcaps 0x400501: Stereo
Control: name="Speaker Phantom Jack", index=0, device=0
Pincap 0x00010010: OUT EAPD
EAPD 0x2: EAPD
Pin Default 0x901701f0: [Fixed] Speaker at Int N/A
Conn = Analog, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1b [Pin Complex] wcaps 0x400500: Mono
Pincap 0x00010010: OUT EAPD
EAPD 0x2: EAPD
Pin Default 0x40f001f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 2
0x10* 0x11
Node 0x1c [Pin Complex] wcaps 0x400701: Stereo Digital
Control: name="SPDIF Phantom Jack", index=0, device=0
Pincap 0x00000010: OUT
Pin Default 0x40f001f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Connection: 1
0x12
Node 0x1d [Pin Complex] wcaps 0x40040b: Stereo Amp-In
Control: name="Internal Mic Boost Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Control: name="Internal Mic Phantom Jack", index=0, device=0
Amp-In caps: ofs=0x00, nsteps=0x04, stepsize=0x2f, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00000020: IN
Pin Default 0x90a601f0: [Fixed] Mic at Int N/A
Conn = Digital, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Power states: D0 D1 D2 D3
Power: setting=D0, actual=D0
Node 0x1e [Vendor Defined Widget] wcaps 0xf00000: Mono

0
site/docs/hardware/hwdumps/x200/cpuinfo.err.log Normal file
View File

52
site/docs/hardware/hwdumps/x200/cpuinfo.log Normal file
View File

@ -0,0 +1,52 @@
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
stepping : 6
microcode : 0x60c
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 4787.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
stepping : 6
microcode : 0x60c
cpu MHz : 1600.000
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips : 4787.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

0
site/docs/hardware/hwdumps/x200/dmesg.err.log Normal file
View File

1066
site/docs/hardware/hwdumps/x200/dmesg.log Normal file
View File

File diff suppressed because it is too large Load Diff

0
site/docs/hardware/hwdumps/x200/dmidecode.err.log Normal file
View File

587
site/docs/hardware/hwdumps/x200/dmidecode.log Normal file
View File

@ -0,0 +1,587 @@
# dmidecode 2.12
SMBIOS 2.4 present.
68 structures occupying 2464 bytes.
Table at 0x000E0010.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: LENOVO
Version: 6DET65WW (3.15 )
Release Date: 08/24/2010
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 8192 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
BIOS Revision: 3.21
Firmware Revision: 1.6
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 7459GW4
Version: ThinkPad X200
Serial Number: L3AAR0B
UUID: 93861E01-4A15-11CB-8F2C-D4BC407E0839
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: ThinkPad X200
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: LENOVO
Product Name: 7459GW4
Version: Not Available
Serial Number: 1ZFDS89N4DD
Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer: LENOVO
Type: Notebook
Lock: Not Present
Version: Not Available
Serial Number: Not Available
Asset Tag: 1S7459GW4L3AAR0B
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
Handle 0x0004, DMI type 126, 13 bytes
Inactive
Handle 0x0005, DMI type 126, 13 bytes
Inactive
Handle 0x0006, DMI type 4, 35 bytes
Processor Information
Socket Designation: None
Type: Central Processor
Family: Other
Manufacturer: GenuineIntel
ID: 76 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 23, Stepping 6
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
Voltage: 1.2 V
External Clock: 266 MHz
Max Speed: 2400 MHz
Current Speed: 2400 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x000A
L2 Cache Handle: 0x000C
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0007, DMI type 5, 20 bytes
Memory Controller Information
Error Detecting Method: None
Error Correcting Capabilities:
None
Supported Interleave: One-way Interleave
Current Interleave: One-way Interleave
Maximum Memory Module Size: 4096 MB
Maximum Total Memory Size: 8192 MB
Supported Speeds:
Other
Supported Memory Types:
DIMM
SDRAM
Memory Module Voltage: 2.9 V
Associated Memory Slots: 2
0x0008
0x0009
Enabled Error Correcting Capabilities:
Unknown
Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: DIMM Slot 1
Bank Connections: 0 1
Current Speed: 42 ns
Type: DIMM SDRAM
Installed Size: 2048 MB (Double-bank Connection)
Enabled Size: 2048 MB (Double-bank Connection)
Error Status: OK
Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
Socket Designation: DIMM Slot 2
Bank Connections: 2 3
Current Speed: 42 ns
Type: DIMM SDRAM
Installed Size: Not Installed
Enabled Size: Not Installed
Error Status: OK
Handle 0x000A, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L1 Cache
Configuration: Enabled, Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Instruction
Associativity: 8-way Set-associative
Handle 0x000B, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L1 Cache
Configuration: Enabled, Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Data
Associativity: 8-way Set-associative
Handle 0x000C, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 3072 kB
Maximum Size: 3072 kB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 8-way Set-associative
Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: External Monitor
External Connector Type: DB-15 female
Port Type: Video Port
Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: Microphone Jack
External Connector Type: Mini Jack (headphones)
Port Type: Audio Port
Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: Headphone Jack
External Connector Type: Mini Jack (headphones)
Port Type: Audio Port
Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: Modem
External Connector Type: RJ-11
Port Type: Modem Port
Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: Ethernet
External Connector Type: RJ-45
Port Type: Network Port
Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: USB 1
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: USB 2
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: Not Available
Internal Connector Type: None
External Reference Designator: USB 3
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0015, DMI type 126, 9 bytes
Inactive
Handle 0x0016, DMI type 126, 9 bytes
Inactive
Handle 0x0017, DMI type 126, 9 bytes
Inactive
Handle 0x0018, DMI type 126, 9 bytes
Inactive
Handle 0x0019, DMI type 126, 9 bytes
Inactive
Handle 0x001A, DMI type 126, 9 bytes
Inactive
Handle 0x001B, DMI type 126, 13 bytes
Inactive
Handle 0x001C, DMI type 10, 6 bytes
On Board Device Information
Type: Other
Status: Disabled
Description: IBM Embedded Security hardware
Handle 0x001D, DMI type 11, 5 bytes
OEM Strings
String 1: IBM ThinkPad Embedded Controller -[7XHT24WW-1.06 ]-
Handle 0x001E, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Abbreviated
Installable Languages: 1
enUS
Currently Installed Language: enUS
Handle 0x001F, DMI type 15, 25 bytes
System Event Log
Area Length: 0 bytes
Header Start Offset: 0x0000
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x0000
Status: Valid, Not Full
Change Token: 0x000000FC
Header Format: Type 1
Supported Log Type Descriptors: 1
Descriptor 1: POST error
Data Format 1: POST results bitmap
Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x0021, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0020
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: SODIMM
Set: None
Locator: DIMM 1
Bank Locator: Bank 0/1
Type: DDR3
Type Detail: Synchronous
Speed: 1066 MHz
Manufacturer: 02FE
Serial Number: F4BB7CA2
Asset Tag: 0839
Part Number: EBJ21UE8BASA-AE-E
Handle 0x0022, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0020
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: SODIMM
Set: None
Locator: DIMM 2
Bank Locator: Bank 2/3
Type: DDR2
Type Detail: Synchronous
Speed: 1066 MHz
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Handle 0x0023, DMI type 18, 23 bytes
32-bit Memory Error Information
Type: OK
Granularity: Unknown
Operation: Unknown
Vendor Syndrome: Unknown
Memory Array Address: Unknown
Device Address: Unknown
Resolution: Unknown
Handle 0x0024, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0007FFFFFFF
Range Size: 2 GB
Physical Array Handle: 0x0020
Partition Width: 2
Handle 0x0025, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0007FFFFFFF
Range Size: 2 GB
Physical Device Handle: 0x0021
Memory Array Mapped Address Handle: 0x0024
Partition Row Position: 1
Handle 0x0026, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x0007FFFFC00
Ending Address: 0x0007FFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x0022
Memory Array Mapped Address Handle: 0x0024
Partition Row Position: 1
Handle 0x0027, DMI type 21, 7 bytes
Built-in Pointing Device
Type: Track Point
Interface: PS/2
Buttons: 3
Handle 0x0028, DMI type 126, 26 bytes
Inactive
Handle 0x0029, DMI type 126, 26 bytes
Inactive
Handle 0x002A, DMI type 24, 5 bytes
Hardware Security
Power-On Password Status: Disabled
Keyboard Password Status: Disabled
Administrator Password Status: Disabled
Front Panel Reset Status: Unknown
Handle 0x002B, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x002C, DMI type 131, 17 bytes
OEM-specific Type
Header and Data:
83 11 2C 00 01 02 03 FF FF 1F 00 00 00 00 00 02
00
Strings:
BOOTINF 20h
BOOTDEV 21h
KEYPTRS 23h
Handle 0x002D, DMI type 131, 22 bytes
OEM-specific Type
Header and Data:
83 16 2D 00 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 01
Strings:
TVT-Enablement
Handle 0x002E, DMI type 132, 7 bytes
OEM-specific Type
Header and Data:
84 07 2E 00 02 D8 36
Handle 0x002F, DMI type 133, 5 bytes
OEM-specific Type
Header and Data:
85 05 2F 00 01
Strings:
KHOIHGIUCCHHII
Handle 0x0030, DMI type 134, 13 bytes
OEM-specific Type
Header and Data:
86 0D 30 00 30 10 08 20 00 00 00 00 00
Handle 0x0031, DMI type 134, 16 bytes
OEM-specific Type
Header and Data:
86 10 31 00 00 49 4E 54 43 01 01 00 00 02 01 02
Strings:
TPM INFO
System Reserved
Handle 0x0032, DMI type 135, 13 bytes
OEM-specific Type
Header and Data:
87 0D 32 00 54 50 07 00 01 00 00 00 00
Handle 0x0033, DMI type 135, 18 bytes
OEM-specific Type
Header and Data:
87 12 33 00 54 50 07 01 01 B9 05 00 00 00 00 00
00 00
Handle 0x0034, DMI type 135, 35 bytes
OEM-specific Type
Header and Data:
87 23 34 00 54 50 07 02 42 41 59 20 49 2F 4F 20
01 00 02 00 00 0B 00 48 1C 3E 18 02 00 0B 00 40
1C 3A 18
Handle 0x0035, DMI type 135, 34 bytes
OEM-specific Type
Header and Data:
87 22 35 00 54 50 07 04 01 06 01 01 02 00 02 01
02 00 03 01 02 00 04 01 02 00 05 01 02 00 06 01
02 00
Handle 0x0036, DMI type 135, 10 bytes
OEM-specific Type
Header and Data:
87 0A 36 00 54 50 07 03 01 0A
Handle 0x0037, DMI type 136, 6 bytes
OEM-specific Type
Header and Data:
88 06 37 00 5A 5A
Handle 0x0038, DMI type 126, 28 bytes
Inactive
Handle 0x0039, DMI type 138, 40 bytes
OEM-specific Type
Header and Data:
8A 28 39 00 14 01 02 01 40 02 01 40 02 01 40 02
01 40 01 40 42 49 4F 53 20 50 61 73 73 77 6F 72
64 20 46 6F 72 6D 61 74
Handle 0x003A, DMI type 139, 37 bytes
OEM-specific Type
Header and Data:
8B 25 3A 00 11 01 0A 00 00 00 00 00 00 00 00 00
00 50 57 4D 53 20 4B 65 79 20 49 6E 66 6F 72 6D
61 74 69 6F 6E
Handle 0x003B, DMI type 140, 67 bytes
OEM-specific Type
Header and Data:
8C 43 3B 00 4C 45 4E 4F 56 4F 0B 00 01 9A 13 CD
C4 7A 2A 8E 76 C3 C4 4E B9 B1 DD 4E 7C 01 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 00 00 00 00 00 00 00 00 00
00 00 00
Handle 0x003C, DMI type 140, 47 bytes
OEM-specific Type
Header and Data:
8C 2F 3C 00 4C 45 4E 4F 56 4F 0B 01 01 08 00 BF
DA 3C 04 5C 72 D9 7D 0D 79 DE 46 98 23 10 B1 00
00 00 00 10 00 10 00 10 01 D0 00 20 01 00 01
Handle 0x003D, DMI type 140, 63 bytes
OEM-specific Type
Header and Data:
8C 3F 3D 00 4C 45 4E 4F 56 4F 0B 02 01 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 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
Handle 0x003E, DMI type 140, 17 bytes
OEM-specific Type
Header and Data:
8C 11 3E 00 4C 45 4E 4F 56 4F 0B 03 01 00 00 00
00
Handle 0x003F, DMI type 140, 19 bytes
OEM-specific Type
Header and Data:
8C 13 3F 00 4C 45 4E 4F 56 4F 0B 04 01 B2 00 53
4D 20 00
Handle 0x0040, DMI type 129, 8 bytes
OEM-specific Type
Header and Data:
81 08 40 00 01 01 02 01
Strings:
Intel_ASF
Intel_ASF_001
Handle 0x0041, DMI type 130, 20 bytes
OEM-specific Type
Header and Data:
82 14 41 00 24 41 4D 54 01 01 01 01 01 A5 0B 04
00 00 00 00
Handle 0x0042, DMI type 131, 64 bytes
OEM-specific Type
Header and Data:
83 40 42 00 14 00 00 00 00 00 40 2A 00 00 00 00
F8 00 17 29 00 00 00 00 2D 00 00 00 00 00 04 00
64 04 03 00 01 00 01 15 C8 00 F5 10 00 00 00 00
00 00 00 00 07 00 00 00 76 50 72 6F 00 00 00 00
Handle 0x0043, DMI type 127, 4 bytes
End Of Table

1
site/docs/hardware/hwdumps/x200/ectool.err.log Normal file
View File

@ -0,0 +1 @@
bash: ectool: command not found

0
site/docs/hardware/hwdumps/x200/ectool.log Normal file
View File

14
site/docs/hardware/hwdumps/x200/flashrom_info.err.log Normal file
View File

@ -0,0 +1,14 @@
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See http://www.flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
========================================================================
Proceeding anyway because user forced us to.

289
site/docs/hardware/hwdumps/x200/flashrom_info.log Normal file
View File

@ -0,0 +1,289 @@
flashrom v0.9.6.1-r1563 on Linux 3.13.0-39-lowlatency (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian
Command line (3 args): flashrom -V -p internal:laptop=force_I_want_a_brick
Calibrating delay loop... OS timer resolution is 1 usecs, 1578M loops per second, 10 myus = 11 us, 100 myus = 114 us, 1000 myus = 1002 us, 10000 myus = 10004 us, 4 myus = 5 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "LENOVO"
DMI string system-product-name: "7459GW4"
DMI string system-version: "ThinkPad X200"
DMI string baseboard-manufacturer: "LENOVO"
DMI string baseboard-product-name: "7459GW4"
DMI string baseboard-version: "Not Available"
DMI string chassis-type: "Notebook"
Laptop detected via DMI.
Found chipset "Intel ICH9M-E" with PCI ID 8086:2917. Enabling flash write...
0xfff80000/0xffb80000 FWH IDSEL: 0x0
0xfff00000/0xffb00000 FWH IDSEL: 0x0
0xffe80000/0xffa80000 FWH IDSEL: 0x0
0xffe00000/0xffa00000 FWH IDSEL: 0x0
0xffd80000/0xff980000 FWH IDSEL: 0x0
0xffd00000/0xff900000 FWH IDSEL: 0x0
0xffc80000/0xff880000 FWH IDSEL: 0x0
0xffc00000/0xff800000 FWH IDSEL: 0x0
0xff700000/0xff300000 FWH IDSEL: 0x4
0xff600000/0xff200000 FWH IDSEL: 0x5
0xff500000/0xff100000 FWH IDSEL: 0x6
0xff400000/0xff000000 FWH IDSEL: 0x7
0xfff80000/0xffb80000 FWH decode enabled
0xfff00000/0xffb00000 FWH decode enabled
0xffe80000/0xffa80000 FWH decode enabled
0xffe00000/0xffa00000 FWH decode enabled
0xffd80000/0xff980000 FWH decode enabled
0xffd00000/0xff900000 FWH decode enabled
0xffc80000/0xff880000 FWH decode enabled
0xffc00000/0xff800000 FWH decode enabled
0xff700000/0xff300000 FWH decode disabled
0xff600000/0xff200000 FWH decode disabled
0xff500000/0xff100000 FWH decode disabled
0xff400000/0xff000000 FWH decode disabled
Maximum FWH chip size: 0x400000 bytes
BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0
Root Complex Register Block address = 0xfed1c000
GCS = 0x7b0461: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x1 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
WARNING: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x3f04 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=63, SME=0
0x08: 0x00001000 (FADDR)
0x50: 0x00001a1b (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0x1a, BRRA 0x1b
0x54: 0x00000000 FREG0: WARNING: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
0x58: 0x07ff0600 FREG1: BIOS region (0x00600000-0x007fffff) is read-write.
0x5C: 0x05f50001 FREG2: WARNING: Management Engine region (0x00001000-0x005f5fff) is locked.
0x60: 0x05f705f6 FREG3: Gigabit Ethernet region (0x005f6000-0x005f7fff) is read-write.
0x64: 0x05ff05f8 FREG4: Platform Data region (0x005f8000-0x005fffff) is read-write.
0x74: 0x9fff07e0 PR0: WARNING: 0x007e0000-0x01ffffff is read-only.
0x84: 0x85ff85f8 PR4: WARNING: 0x005f8000-0x005fffff is locked.
Please send a verbose log to flashrom@flashrom.org if this board is not listed on
http://flashrom.org/Supported_hardware#Supported_mainboards yet.
Writes have been disabled. You can enforce write support with the
ich_spi_force programmer option, but it will most likely harm your hardware!
If you force flashrom you will get no support if something breaks.
0x90: 0x04 (SSFS)
SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
0x91: 0x000000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=0
0x94: 0x5006 (PREOP)
0x96: 0x143b (OPTYPE)
0x98: 0x05200302 (OPMENU)
0x9C: 0x0601209f (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00002005 (LVSCC)
LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
SPI Read Configuration: prefetching disabled, caching enabled, OK.
The following protocols are supported: FWH, SPI.
Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L16PT, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L020, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L080, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L016, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L032, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25LQ032, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF021, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF041A, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF081, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF321, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF321A, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF641(A), 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DQ161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25F512B, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25FS010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25FS040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF041, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF161A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26F004, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45CS1282, 16896 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB011D, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB021D, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB041D, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB081D, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB161D, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB321C, 4224 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB321D, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB642D, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for EMST F25L008A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B05, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B05T, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B10T, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B20T, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B40T, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B80T, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B16T, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B32T, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B64T, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F05, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q80(A), 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q32(A/B), 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25QH16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25QH32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1005, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L2005, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L4005, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L8005, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1605, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1635D, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1635E, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L3205, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L3235D, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L6405, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Chip status register is 00
Chip status register: Status Register Write Disable (SRWD) is not set
Chip status register: Bit 6 is not set
Chip status register: Block Protect 3 (BP3) is not set
Chip status register: Block Protect 2 (BP2) is not set
Chip status register: Block Protect 1 (BP1) is not set
Chip status register: Block Protect 0 (BP0) is not set
Chip status register: Write Enable Latch (WEL) is not set
Chip status register: Write In Progress (WIP/BUSY) is not set
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) at physical address 0xff800000.
Probing for Macronix MX25L12805, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx N25Q064, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV016B, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV020, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV080B, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Sanyo LF25FW203A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL004A, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL008A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL016A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL032A, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25LF040A, 512 kB: Invalid OPCODE 0xab, will not execute.
Probing for SST SST25LF080A, 1024 kB: Invalid OPCODE 0xab, will not execute.
Probing for SST SST25VF010, 128 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF064C, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF040, 512 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF040B, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF040B.REMS, 512 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF080B, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P05-A, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P05, 64 kB: Ignoring RES in favour of RDID.
Probing for ST M25P10-A, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P10, 128 kB: Ignoring RES in favour of RDID.
Probing for ST M25P20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P40-old, 512 kB: Ignoring RES in favour of RDID.
Probing for ST M25P80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Unknown SFDP-capable chip, 0 kB: Invalid OPCODE 0x5a, will not execute.
Receiving SFDP signature failed.
Probing for AMIC unknown AMIC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel unknown Atmel SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon unknown Eon SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix unknown Macronix SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC unknown PMC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST unknown SST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Generic unknown SPI chip (REMS), 0 kB: Invalid OPCODE 0x90, will not execute.
Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x0a, id2 0xce, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Found Macronix flash chip "MX25L6405" (8192 kB, SPI).
No operations were specified.
Restoring MMIO space at 0x7f9c951da8a0
Restoring PCI config space for 00:1f:0 reg 0xdc

16
site/docs/hardware/hwdumps/x200/flashrom_read.err.log Normal file
View File

@ -0,0 +1,16 @@
========================================================================
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing.
See http://www.flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your laptop
and write may brick your laptop.
Read and probe may irritate your EC and cause fan failure, backlight
failure and sudden poweroff.
You have been warned.
========================================================================
Proceeding anyway because user forced us to.
Transaction error!
Read operation failed!

292
site/docs/hardware/hwdumps/x200/flashrom_read.log Normal file
View File

@ -0,0 +1,292 @@
flashrom v0.9.6.1-r1563 on Linux 3.13.0-39-lowlatency (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian
Command line (5 args): flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin
Calibrating delay loop... OS timer resolution is 2 usecs, 1579M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1004 us, 10000 myus = 10014 us, 8 myus = 9 us, OK.
Initializing internal programmer
No coreboot table found.
DMI string system-manufacturer: "LENOVO"
DMI string system-product-name: "7459GW4"
DMI string system-version: "ThinkPad X200"
DMI string baseboard-manufacturer: "LENOVO"
DMI string baseboard-product-name: "7459GW4"
DMI string baseboard-version: "Not Available"
DMI string chassis-type: "Notebook"
Laptop detected via DMI.
Found chipset "Intel ICH9M-E" with PCI ID 8086:2917. Enabling flash write...
0xfff80000/0xffb80000 FWH IDSEL: 0x0
0xfff00000/0xffb00000 FWH IDSEL: 0x0
0xffe80000/0xffa80000 FWH IDSEL: 0x0
0xffe00000/0xffa00000 FWH IDSEL: 0x0
0xffd80000/0xff980000 FWH IDSEL: 0x0
0xffd00000/0xff900000 FWH IDSEL: 0x0
0xffc80000/0xff880000 FWH IDSEL: 0x0
0xffc00000/0xff800000 FWH IDSEL: 0x0
0xff700000/0xff300000 FWH IDSEL: 0x4
0xff600000/0xff200000 FWH IDSEL: 0x5
0xff500000/0xff100000 FWH IDSEL: 0x6
0xff400000/0xff000000 FWH IDSEL: 0x7
0xfff80000/0xffb80000 FWH decode enabled
0xfff00000/0xffb00000 FWH decode enabled
0xffe80000/0xffa80000 FWH decode enabled
0xffe00000/0xffa00000 FWH decode enabled
0xffd80000/0xff980000 FWH decode enabled
0xffd00000/0xff900000 FWH decode enabled
0xffc80000/0xff880000 FWH decode enabled
0xffc00000/0xff800000 FWH decode enabled
0xff700000/0xff300000 FWH decode disabled
0xff600000/0xff200000 FWH decode disabled
0xff500000/0xff100000 FWH decode disabled
0xff400000/0xff000000 FWH decode disabled
Maximum FWH chip size: 0x400000 bytes
BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0
Root Complex Register Block address = 0xfed1c000
GCS = 0x7b0461: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x1 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
WARNING: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x3f04 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=63, SME=0
0x08: 0x00000000 (FADDR)
0x50: 0x00001a1b (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0x1a, BRRA 0x1b
0x54: 0x00000000 FREG0: WARNING: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
0x58: 0x07ff0600 FREG1: BIOS region (0x00600000-0x007fffff) is read-write.
0x5C: 0x05f50001 FREG2: WARNING: Management Engine region (0x00001000-0x005f5fff) is locked.
0x60: 0x05f705f6 FREG3: Gigabit Ethernet region (0x005f6000-0x005f7fff) is read-write.
0x64: 0x05ff05f8 FREG4: Platform Data region (0x005f8000-0x005fffff) is read-write.
0x74: 0x9fff07e0 PR0: WARNING: 0x007e0000-0x01ffffff is read-only.
0x84: 0x85ff85f8 PR4: WARNING: 0x005f8000-0x005fffff is locked.
Please send a verbose log to flashrom@flashrom.org if this board is not listed on
http://flashrom.org/Supported_hardware#Supported_mainboards yet.
Writes have been disabled. You can enforce write support with the
ich_spi_force programmer option, but it will most likely harm your hardware!
If you force flashrom you will get no support if something breaks.
0x90: 0x04 (SSFS)
SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
0x91: 0x004240 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=2, SME=0, SCF=0
0x94: 0x5006 (PREOP)
0x96: 0x143b (OPTYPE)
0x98: 0x05200302 (OPMENU)
0x9C: 0x0601209f (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00002005 (LVSCC)
LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
SPI Read Configuration: prefetching disabled, caching enabled, OK.
The following protocols are supported: FWH, SPI.
Probing for AMIC A25L05PT, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L05PU, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L10PT, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L10PU, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L20PT, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L20PU, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L40PT, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L40PU, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L80P, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L16PT, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L16PU, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L020, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L080, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L016, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25L032, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for AMIC A25LQ032, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF021, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF041A, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF081, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF321, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF321A, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DF641(A), 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25DQ161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25F512B, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25FS010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT25FS040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF041, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF081A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF161, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26DF161A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT26F004, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45CS1282, 16896 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB011D, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB021D, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB041D, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB081D, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB161D, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB321C, 4224 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB321D, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel AT45DB642D, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for EMST F25L008A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B05, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B05T, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B10T, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B20T, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B40T, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B80T, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B16T, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B32T, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25B64T, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F05, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25F32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q80(A), 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q32(A/B), 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25QH16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon EN25QH32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for GigaDevice GD25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1005, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L2005, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L4005, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L8005, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1605, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1635D, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L1635E, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L3205, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L3235D, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix MX25L6405, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Chip status register is 00
Chip status register: Status Register Write Disable (SRWD) is not set
Chip status register: Bit 6 is not set
Chip status register: Block Protect 3 (BP3) is not set
Chip status register: Block Protect 2 (BP2) is not set
Chip status register: Block Protect 1 (BP1) is not set
Chip status register: Block Protect 0 (BP0) is not set
Chip status register: Write Enable Latch (WEL) is not set
Chip status register: Write In Progress (WIP/BUSY) is not set
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) at physical address 0xff800000.
Probing for Macronix MX25L12805, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx M25PE16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Numonyx N25Q064, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV010, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV016B, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV020, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV040, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV080B, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC Pm25LV512, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Sanyo LF25FW203A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL004A, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL008A, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL016A, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL032A, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Spansion S25FL064A, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25LF040A, 512 kB: Invalid OPCODE 0xab, will not execute.
Probing for SST SST25LF080A, 1024 kB: Invalid OPCODE 0xab, will not execute.
Probing for SST SST25VF010, 128 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF016B, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF032B, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF064C, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF040, 512 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF040B, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST SST25VF040B.REMS, 512 kB: Invalid OPCODE 0x90, will not execute.
Probing for SST SST25VF080B, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P05-A, 64 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P05, 64 kB: Ignoring RES in favour of RDID.
Probing for ST M25P10-A, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P10, 128 kB: Ignoring RES in favour of RDID.
Probing for ST M25P20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P40-old, 512 kB: Ignoring RES in favour of RDID.
Probing for ST M25P80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25P128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST M25PX64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25Q128, 16384 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X10, 128 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X20, 256 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X40, 512 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X80, 1024 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X16, 2048 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X32, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Winbond W25X64, 8192 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Unknown SFDP-capable chip, 0 kB: Invalid OPCODE 0x5a, will not execute.
Receiving SFDP signature failed.
Probing for AMIC unknown AMIC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Atmel unknown Atmel SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Eon unknown Eon SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Macronix unknown Macronix SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for PMC unknown PMC SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for SST unknown SST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Sanyo unknown Sanyo SPI chip, 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Generic unknown SPI chip (RDID), 0 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2017
Probing for Generic unknown SPI chip (REMS), 0 kB: Invalid OPCODE 0x90, will not execute.
Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x0a, id2 0xce, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0x4e, id2 0x41, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xba, id2 0x8e, id1 is normal flash content, id2 is normal flash content
Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0x50, id2 0x09, id1 parity violation, id1 is normal flash content, id2 is normal flash content
Found Macronix flash chip "MX25L6405" (8192 kB, SPI).
Reading flash... SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0
SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=63, SME=0, SCF=0
Running OPCODE 0x03 failed at address 0x001000 (payload length was 64).
FAILED.
Restoring MMIO space at 0x7f53b721c8a0
Restoring PCI config space for 00:1f:0 reg 0xdc

11
site/docs/hardware/hwdumps/x200/input_bustypes.log Normal file
View File

@ -0,0 +1,11 @@
0019
0000
0000
0019
0019
0011
0011
0019
0019
0000
0000

1
site/docs/hardware/hwdumps/x200/inteltool.err.log Normal file
View File

@ -0,0 +1 @@
bash: inteltool: command not found

0
site/docs/hardware/hwdumps/x200/inteltool.log Normal file
View File

0
site/docs/hardware/hwdumps/x200/ioports.err.log Normal file
View File

60
site/docs/hardware/hwdumps/x200/ioports.log Normal file
View File

@ -0,0 +1,60 @@
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC cmd
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
03c0-03df : vga+
0800-080f : pnp 00:01
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1000-1003 : ACPI PM1a_EVT_BLK
1004-1005 : ACPI PM1a_CNT_BLK
1008-100b : ACPI PM_TMR
1010-1015 : ACPI CPU throttle
1020-102f : ACPI GPE0_BLK
1030-1033 : iTCO_wdt
1050-1050 : ACPI PM2_CNT_BLK
1060-107f : iTCO_wdt
1180-11ff : pnp 00:01
15e0-15ef : pnp 00:01
1600-167f : pnp 00:01
1680-169f : pnp 00:01
1800-1807 : 0000:00:02.0
1830-1837 : 0000:00:03.3
1830-1837 : serial
1838-183b : 0000:00:1f.2
1838-183b : ahci
183c-183f : 0000:00:1f.2
183c-183f : ahci
1840-185f : 0000:00:19.0
1860-187f : 0000:00:1a.0
1860-187f : uhci_hcd
1880-189f : 0000:00:1a.1
1880-189f : uhci_hcd
18a0-18bf : 0000:00:1a.2
18a0-18bf : uhci_hcd
18c0-18df : 0000:00:1d.0
18c0-18df : uhci_hcd
18e0-18ff : 0000:00:1d.1
18e0-18ff : uhci_hcd
1c00-1c1f : 0000:00:1d.2
1c00-1c1f : uhci_hcd
1c20-1c3f : 0000:00:1f.2
1c20-1c3f : ahci
1c40-1c47 : 0000:00:1f.2
1c40-1c47 : ahci
1c48-1c4f : 0000:00:1f.2
1c48-1c4f : ahci
1c60-1c7f : 0000:00:1f.3
2000-2fff : PCI Bus 0000:05
3000-3fff : PCI Bus 0000:02
4000-4fff : PCI Bus 0000:03

0
site/docs/hardware/hwdumps/x200/lspci.err.log Normal file
View File

2287
site/docs/hardware/hwdumps/x200/lspci.log Normal file
View File

File diff suppressed because it is too large Load Diff

1
site/docs/hardware/hwdumps/x200/lspnp.err.log Normal file
View File

@ -0,0 +1 @@
bash: lspnp: command not found

0
site/docs/hardware/hwdumps/x200/lspnp.log Normal file
View File

0
site/docs/hardware/hwdumps/x200/lsusb.err.log Normal file
View File

820
site/docs/hardware/hwdumps/x200/lsusb.log Normal file
View File

@ -0,0 +1,820 @@
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1d.7
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x38
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1d.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1d.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x06
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1d.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:1a.7
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 6
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x58
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1a.2
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x04
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 004 Device 002: ID 0a5c:2145 Broadcom Corp. BCM2045B (BDC-2.1) [Bluetooth Controller]
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a5c Broadcom Corp.
idProduct 0x2145 BCM2045B (BDC-2.1) [Bluetooth Controller]
bcdDevice 3.52
iManufacturer 1 Lenovo Computer Corp
iProduct 2 ThinkPad Bluetooth with Enhanced Data Rate II
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 216
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 0
iInterface 0
Device Firmware Upgrade Interface Descriptor:
bLength 7
bDescriptorType 33
bmAttributes 7
Will Not Detach
Manifestation Tolerant
Upload Supported
Download Supported
wDetachTimeout 5000 milliseconds
wTransferSize 64 bytes
Device Status: 0x0001
Self Powered
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1a.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x06
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.13
iManufacturer 3 Linux 3.13.0-39-lowlatency uhci_hcd
iProduct 2 UHCI Host Controller
iSerial 1 0000:00:1a.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Device Status: 0x0001
Self Powered

1
site/docs/hardware/hwdumps/x200/msrtool.err.log Normal file
View File

@ -0,0 +1 @@
bash: msrtool: command not found

0
site/docs/hardware/hwdumps/x200/msrtool.log Normal file
View File

1
site/docs/hardware/hwdumps/x200/nvramtool.err.log Normal file
View File

@ -0,0 +1 @@
bash: nvramtool: command not found

0
site/docs/hardware/hwdumps/x200/nvramtool.log Normal file
View File

8
site/docs/hardware/hwdumps/x200/pin_hwC0D0 Normal file
View File

@ -0,0 +1,8 @@
0x16 0x042140f0
0x17 0x61a190f0
0x18 0x04a190f0
0x19 0x612140f0
0x1a 0x901701f0
0x1b 0x40f001f0
0x1c 0x40f001f0
0x1d 0x90a601f0

1
site/docs/hardware/hwdumps/x200/superiotool.err.log Normal file
View File

@ -0,0 +1 @@
bash: superiotool: command not found

0
site/docs/hardware/hwdumps/x200/superiotool.log Normal file
View File

7
site/docs/hardware/imac52.md Normal file
View File

@ -0,0 +1,7 @@
---
title: Apple iMac 5,2
...
Information to be written soon, but this board is merged in libreboot.
Just refer back to the [hardware section](./) and [install guides](../install/)

85
site/docs/hardware/index.md Normal file
View File

@ -0,0 +1,85 @@
---
title: Hardware compatibility list
x-toc-enable: true
...
This sections relates to known hardware compatibility in libreboot.
For installation instructions, refer to [../install/](../install/).
NOTE: For T60/R60 thinkpads, make sure that it has an Intel GPU, not an ATI GPU
because coreboot lacks native video initialization for the ATI GPUs on these
machines.
(for later machines like T500, T400, ATI GPU doesn't matter, because it also
has an Intel GPU, and Libreboot uses the Intel one)
Supported hardware
==================
Libreboot supports the following systems in this release:
### Desktops (AMD, Intel, x86)
- [Gigabyte GA-G41M-ES2L motherboard](ga-g41m-es2l.md)
- [Intel D510MO and D410PT motherboards](d510mo.md)
- [Intel D945GCLF](d945gclf.md)
- [Apple iMac 5,2](imac52.md)
### Servers/workstations (AMD, x86)
- [ASUS KCMA-D8 motherboard](kcma-d8.md)
- [ASUS KGPE-D16 motherboard](kgpe-d16.md)
- [ASUS KFSN4-DRE motherboard](kfsn4-dre.md)
### Laptops (ARM)
- [ASUS Chromebook C201](c201.md)
### Laptops (Intel, x86)
- [Lenovo ThinkPad X200](x200.md)
- [Lenovo ThinkPad R400](r400.md)
- [Lenovo ThinkPad T400](t400.md)
- [Lenovo ThinkPad T500](t500.md)
- [Lenovo ThinkPad W500](t500.md)
- [Lenovo ThinkPad R500](r500.md)
- [Apple MacBook1,1 and MacBook2,1](macbook21.md)
'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.
EC update on i945 (X60, T60) and GM45 (X200, T400, T500, R400, W500, R500)
==============================================================
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running libreboot is unknown. Libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery
handling.
How to find what EC version you have (i945/GM45)
------------------------------------------------
In GNU+Linux, you can try this:
grep 'at EC' /proc/asound/cards
Sample output:
ThinkPad Console Audio Control at EC reg 0x30, fw 7WHT19WW-3.6
7WHT19WW is the version in different notation, use search engine to find
out regular version - in this case it's a 1.06 for x200 tablet

215
site/docs/hardware/kcma-d8.md Normal file
View File

@ -0,0 +1,215 @@
---
title: ASUS KCMA-D8 desktop/workstation board
x-toc-enable: true
...
Introduction
============
Specifications available here:
<https://www.asus.com/uk/Commercial-Servers-Workstations/KCMAD8/>
Quite a nice board; can have up to 16 Opteron 4200/4300 CPU cores, with up to
64GiB of RAM. It holds its own against more modern machines, especially when
compiling large source trees (for compilers, what you want is high RAM and more
CPU cores).
This is a desktop board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
Libreboot also supports it. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them, merged into libreboot many
years ago.
Note that not all boards are compatible. See [board status](#boardstatus)
below to determine compatibility with your board.
Flashing instructions can be found at
[../install/](../install/) - note that external
flashing is required (e.g. RPi), if the proprietary (ASUS) firmware is
currently installed. If you already have libreboot/osboot/coreboot, by default
it is possible to re-flash using software running in GNU+Linux on the kcma-d8,
without using external hardware.
If you currently have the ASUS firmware, please ignore the above link and
instead refer to the section below:
Flashing
========
The default ASUS firmware write-protects the flash, so you have to remove the
chip and re-flash it using external hardware.
It has a 25XX NOR flash (SPI protocol) in a P-DIP 8 socket, which looks like
this:
![](https://av.libreboot.org/dip8/dip8.jpg)
The default chip is a 2MiB one, but we recommend upgrading it to a 16MiB chip.
NOTE: If you're already running Libreboot, you probably don't
need to re-flash externally. Refer instead to the generic instructions on
this page: [../install/](../install/)
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
PCI option ROMs
===============
Unlike Libreboot 20160907, Libreboot in newer releases now supports finding and
loading PCI option ROMs automatically, both in GRUB and SeaBIOS on this machine.
So for example, if you wish to use an add-on graphics card, you can! It's no
problem, and should work just fine.
CPU coolers
===========
With some creativity, standard AM3+ coolers will work fine.
2 x Socket C32 (LGA1207) available, so you can use 2 CPUs. (up to 32GiB per CPU)
CPU compatibility
=================
- Opteron 4100 series: Incompatible
- Opteron 4200 series: Compatible, does not require microcode updates
- Opteron 4300 series: Compatible, requires microcode updates (nonfree!)
"Requires" means needed for stability. Opteron 4200 series CPUs work very well,
even without microcode updates. Because the updates are non-free, Libreboot does
not include them.
In particular, the 4200 series works well with hardware virtualization even
without the microcode updates; 4300 series on the other hand is more dependent
upon these microcode updates.
Microcode configures the logic gate arrays inside your CPU, to implement the
instruction set architecture, which in turn is what enables *instructions* to
execute on your CPU. What do you think will happen if you don't have these
updates? The answer is: bugs are possible, and the updates fix those bugs.
AMD CPUs are generally better engineered than Intel ones, and work much nicer
without updates compared to Intel CPUs, but CPU manufacturers design their chips
to accept updates for a reason!
Board status (compatibility) {#boardstatus}
============================
There are two ways to identify a supported KCMA-D8 board:
1. Serial number (sticker attached to the 24-pin ATX power connector)
2. BIOS version (sticker next to CPU slot 1, last four digits)
Supported boards begin with a serial number of **B9S2xxxxxxxx** or above where
the first character refers to the year of manufacture (A = 2010, B = 2011, etc.)
and the following character the month in hexadecimal (1...9, A, B, C). Thus, any
board produced September 2011 *or later* are compatible with Libreboot. Boards
originally shipped with BIOS version **2001** or higher are also compatible.
For help locating these identifying markers, see [ASUS documentation for determining Opteron 4200 series compatibility](https://web.archive.org/web/20200710022605/https://dlcdnets.asus.com/pub/ASUS/mb/SocketC%281027%29/KCMA-D8/Manual&QVL/How_to_identify_MB_supporting_Opteron_4200_CPU.pdf)
For more detailed information regarding the coreboot port, see
<https://raptorengineeringinc.com/coreboot/kcma-d8-status.php>
Form factor {#formfactor}
===========
This board is ATX form factor. While the [ATX standard, version 2.2](https://web.archive.org/web/20120725150314/http://www.formfactors.org/developer/specs/atx2_2.pdf)
specifies board dimensions 305mm x 244mm, this board measures 305mm x 253mm;
please ensure that your case supports this extra ~cm in width.
IPMI iKVM module add-on {#ipmi}
=======================
Don't use it. It uses proprietary firmware and adds a backdoor (remote
out-of-band management chip, similar to the [Intel Management
Engine](../../faq.md#intelme). Fortunately, the firmware is
unsigned (possible to replace) and physically separate from the
mainboard since it's on the add-on module, which you don't have to
install.
Flash chips {#flashchips}
===========
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 (and nowadays there is LinuxBoot, for which
we would recommend a 16MiB boot flash)
*DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip
extractor. These can be found online. See
<http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools>*
Ideally, you should not hot-swap. Only remove the IC when the system is
powered down and disconnected from mains.
Native graphics initialization {#graphics}
==============================
Only text-mode is known to work, but linux(kernel) can initialize the
framebuffer display (if it has KMS - kernel mode setting).
NOTE: This section relates to the onboard ASpeed GPU. You *can* use an add-on
PCI-E GPU in one of the available slots on the mainboard. Nvidia GTX 780 cards
are what Libreboot recommends; it has excellent support in Nouveau (free Linux
kernel / mesa driver for Nvidia cards) and generally works well; however, the
performance won't be as high in Nouveau, compared to the non-free Nvidia driver
because the Nouveau driver can't increase the GPU clock (it doesn't know how,
as of 18 March 2021).
Current issues {#issues}
==============
- Opteron 4100 series CPUs are currently incompatible
- LRDIMM memory modules are currently incompatible
(use UDIMMs please)
- Memory initialization is still problematic for some modules. We
recommend avoiding Kingston and Super Talent modules for this reason.
The coreboot wiki has some information about RAM compatibility. The wiki is
deprecated but the info on it is still correct for this board. Some other
considerations:
- Booting from USB mass storage devices is currently broken under GRUB.
Consequently, the textmode ROM with SeaBIOS is recommended otherwise
in order to install an operating system you will need a hard disk with
a pre-installed OS or will have to plug in another HDD or CD/DVD
reader in order to boot OS installation media.
- SeaBIOS lacked serial console support out-of-the-box in release 20160907
and as such a workaround using SGABIOS is necessary. You can find
instructions on how to do this on the
[Notabug issue tracker](http://web.archive.org/web/20210416011941/https://notabug.org/libreboot/libreboot/issues/736)
TODO: test whether this is still the case in Libreboot, which uses a newer
version of coreboot nowadays)
- 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).
NOTE: SeaBIOS can load PCI-E option ROMs, and by default it will do so in
Libreboot, so you could use it. However, you could *also* simply
install 16MiB NOR flash with linuxboot payload in it, and use linuxboot
which has the Linux kernel, which can use SAS drives without needing that
option ROM; then it can kexec another linux kernel, which in turn also can
can use those drives. Or just put a standard linux kernel and initramfs
in cbfs and chainload that from GRUB, with the right parameters.
- IPMI iKVM module (optional add-on card) uses proprietary firmware.
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the Libreboot
project recommends not installing the module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In
practise, out-of-band management isn't very useful anyway (or at
the very least, it's not a major inconvenience to not have it).
- Graphics: only text-mode works. See [\#graphics](#graphics)
Hardware specifications {#specifications}
-----------------------
Check the ASUS website.

107
site/docs/hardware/kfsn4-dre.md Normal file
View File

@ -0,0 +1,107 @@
---
title: ASUS KFSN4-DRE server/workstation board
x-toc-enable: true
...
This is a server board using AMD hardware (Fam10h). It can also be used
for building a high-powered workstation. Powered by libreboot.
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
Form factor {#formfactor}
===========
These boards use the SSI EEB 3.61 form factor; make sure that your case
supports this. This form factor is similar to E-ATX in that the size is
identical, but the position of the screws are different.
Flash chips {#flashchips}
===========
These boards use LPC flash (not SPI), in a PLCC socket. The default
flash size 1MiB (8Mbits), and can be upgraded to 2MiB (16Mbits).
SST49LF080A is the default that the board uses. SST49LF016C is an
example of a 2MiB (16Mbits) chip, which might work. It is believed that
2MiB (16Mbits) is the maximum size available for the flash chip.
*DO NOT hot-swap the chip with your bare hands. Use a PLCC chip
extractor. These can be found online. See
<http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools>*
Native graphics initialization {#graphics}
==============================
Native graphics initialization exists (XGI Z9s) for this board.
Framebuffer- and text-mode both work. A serial port is also available.
Memory
======
DDR2 533/667 Registered ECC. 16 slots. Total capacity up to 64GiB.
Hex-core CPUs {#hexcore}
=============
PCB revision 1.05G is the latest version of this board and the best one
(the revision number is be printed on the board), if you want to use
dual hex-core CPUs (Opteron 2400/8400 series), though only two board
configurations are believed to support them. Other revisions are
believed to only support dual quad-core CPUs.
To be sure your board supports a CPU check the official ASUS website here:
<https://www.asus.com/support/cpu_support>. Note: not all CPUs are listed.
If you are running a Hex-Core CPU on any board version, please contact us.
Board configurations {#configurations}
==============
There are 7 different configurations of this board: "standard", 2S, iKVM,
iKVM/IST, SAS, SAS/iKVM and SAS/iKVM/IST.
The 2S boards have two PCI-E slots with the numbers of lanes shared,
making each slot have 8 lanes.
The iKVM boards are so called because they offer a remote real-time access
to the machine through a removable PCI management card, their hardware is
the same as the non-iKVM ones.
The SAS versions have a 4-port SAS controller and a four 7-pin SAS connectors
instead of the PCI-E 8x slot which is present in all the other board configurations.
Note: the SAS functionality is **not supported** by libreboot.
The IST versions with PCB revision 1.05G are the ones who are believed to
support the six core Opteron Istanbul processors (2400 and 8400 series).
Current issues {#issues}
==============
- There seems to be a 30 second bootblock delay (observed by
tpearson); the system otherwise boots and works as expected. See
[text/kfsn4-dre/bootlog.txt](text/kfsn4-dre/bootlog.txt) - this uses
the 'simple' bootblock, while tpearson uses the 'normal'
bootblock, which tpearson suspects may be a possible cause. This
person says that they will look into it. [This
config](http://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asus/kfsn4-dre/4.0-10101-g039edeb/2015-06-27T03:59:16Z/config.txt;h=4742905c185a93fbda8eb14322dd82c70641aef0;hb=055f5df4e000a97453dfad6c91c2d06ea22b8545)
doesn't have the issue.
- Text-mode is jittery and it may not be usable, so it's recommended
to flash the BIOS with the coreboot frame-buffer image (kfsn4-dre_corebootfb.rom).
The jitter disappears if using KMS once the kernel starts, but it will
remain, if booting the kernel in text-mode.
- Booting from USB mass storage devices is not possible; neither GRUB
nor SeaBIOS detect USB drives when present. USB keyboards function
under both GRUB and SeaBIOS, albeit slowly under GRUB (several seconds per
character typed).
- To install an operating system you will need a hard disk
with a pre-installed OS otherwise you have to plug in another hard disk or
a CD/DVD reader in order to boot a copy of the installer of your OS, since
the USB booting doesn't work.
Other information
=================
[specifications](https://web.archive.org/web/20181212180051/http://ftp.tekwind.co.jp/pub/asustw/mb/Socket%20F/KFSN4-DRE/Manual/e3335_kfsn4-dre.pdf)

221
site/docs/hardware/kgpe-d16.md Normal file
View File

@ -0,0 +1,221 @@
---
title: ASUS KGPE-D16 server/workstation board
x-toc-enable: true
...
Introduction
============
This is a server board using AMD hardware (Fam10h *and Fam15h* CPUs
available). It can also be used for building a high-powered workstation.
Powered by libreboot. The coreboot port was done by Timothy Pearson of
Raptor Engineering Inc. and, working with them (and sponsoring the
work), merged into libreboot.
*Memory initialization is still problematic, for some modules. We
recommend avoiding Kingston modules.*
*For working configurations see <https://www.coreboot.org/Board:asus/kgpe-d16>.*
Flashing instructions can be found at
[../install/\#flashrom](../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.
CPU compatibility
=================
*Use Opteron 6200 series (works without microcode updates, including hw
virt).* 6300 series needs microcode updates, so avoid those CPUs. 6100
series is too old, and mostly untested.
Board status (compatibility) {#boardstatus}
============================
See <https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php>.
Form factor {#formfactor}
===========
These boards use the SSI EEB 3.61 form factor; make sure that your case
supports this. This form factor is similar to E-ATX in that the size is
identical, but the position of the screws are different.
IPMI iKVM module add-on {#ipmi}
=======================
Don't use it. It uses proprietary firmware and adds a backdoor (remote
out-of-band management chip, similar to the [Intel Management
Engine](../../faq.md#intelme). Fortunately, the firmware is
unsigned (possibly to replace) and physically separate from the
mainboard since it's on the add-on module, which you don't have to
install.
Flash chips {#flashchips}
===========
2MiB flash chips are included by default, on these boards. It's on a
P-DIP 8 slot (SPI chip). The flash chip can be upgraded to higher sizes:
4MiB, 8MiB or 16MiB. With at least 8MiB, you could feasibly fit a
compressed linux+initramfs image (BusyBox+Linux system) into CBFS and
boot that, loading it into memory.
Libreboot has configs for 2, 4, 8 and 16 MiB flash chip sizes (default
flash chip is 2MiB).
*DO NOT hot-swap the chip with your bare hands. Use a P-DIP 8 chip
extractor. These can be found online. See
<http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools>*
This guide shows how to flash the chip:\
[25xx NOR flashing guide](../install/spi.md)
Native graphics initialization {#graphics}
==============================
Only text-mode is known to work, but linux(kernel) can initialize the
framebuffer display (if it has KMS - kernel mode setting).
Current issues {#issues}
==============
- LRDIMM memory modules are currently incompatible
- SAS (via PIKE 2008 module) requires non-free option ROM (and
SeaBIOS) to boot from it (theoretically possible to replace, but you
can put a kernel in CBFS or on SATA and use that to boot GNU, which
can be on a SAS drive. The linux kernel can use those SAS drives
(via PIKE module) without an option ROM).
- SeaBIOS lacked serial console support out-of-the-box in release 20160907
and as such a workaround using SGABIOS is necessary. You can find
instructions on how to do this on the
[Notabug issue tracker](http://web.archive.org/web/20210416011941/https://notabug.org/libreboot/libreboot/issues/736)
- IPMI iKVM module (optional add-on card) uses proprietary firmware.
Since it's for remote out-of-band management, it's theoretically a
backdoor similar to the Intel Management Engine. Fortunately, unlike
the ME, this firmware is unsigned which means that a free
replacement is theoretically possible. For now, the libreboot
project recommends not installing the module. [This
project](https://github.com/facebook/openbmc) might be interesting
to derive from, for those who want to work on a free replacement. In
practise, out-of-band management isn't very useful anyway (or at
the very least, it's not a major inconvenience to not have it).
- Graphics: only text-mode works. See [\#graphics](#graphics)
Hardware specifications {#specifications}
-----------------------
The information here is adapted, from the ASUS website.
### Processor / system bus
- 2 CPU sockets (G34 compatible)
- HyperTransport™ Technology 3.0
- CPUs supported:
- AMD Opteron 6100 series (Fam10h. No IOMMU support. *Not*
recommended - old. View errata datasheet here:
<http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf>)
- AMD Opteron 6200 series (Fam15h, with full IOMMU support in
libreboot - *highly recommended - fast, and works well without
microcode updates, including virtualization*)
- AMD Opteron 6300 series (Fam15h, with full IOMMU support in
libreboot. *AVOID LIKE THE PLAGUE - virtualization is broken
without microcode updates.*
- NOTE: 6300 series CPUs have buggy microcode built-in, and
libreboot recommends avoiding the updates. The 6200 series CPUs
have more reliable microcode. Look at this errata datasheet:
<http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Guide.pdf>
(see Errata 734 - this is what kills the 6300 series)
- 6.4 GT/s per link (triple link)
### Core logic
- AMD SR5690
- AMD SP5100
### Memory compatibility (with libreboot)
- *Total Slots:* 16 (4-channel per CPU, 8 DIMM per CPU), ECC
- *Capacity:* Maximum up to 256GB RDIMM (Tested max 128GB)
- *Memory Type that is compatible:*
- DDR3 1600/1333/1066/800 UDIMM\*
- DDR3 1600/1333/1066/800 RDIMM\*
- *Compatible sizes per memory module:*
- 16GB, 8GB, 4GB, 3GB, 2GB, 1GB RDIMM
- 8GB, 4GB, 2GB, 1GB UDIMM
### Expansion slots
- *Total slot:* 6
- *Slot Location 1:* PCI 32bit/33MHz
- *Slot Location 2:* PCI-E x16 (Gen2 X8 Link)
- *Slot Location 3:* PCI-E x16 (Gen2 X16 Link), Auto switch to x8
link if slot 2 is occupied
- *Slot Location 4:* PCI-E x8 (Gen2 X4 Link)
- *Slot Location 5:* PCI-E x16 (Gen2 X16 Link)
- *Slot Location 6:* PCI-E x16 (Gen2 X16 Link), Auto turn off if
slot 5 is occupied, For 1U FH/FL Card, MIO supported
- *Additional Slot 1:* PIKE slot (for SAS drives. See notes above)
- Follow SSI Location\#
### Form factor {#form-factor}
- SSI EEB 3.61 (12"x13")
### ASUS features
- Fan Speed Control
- Rack Ready (Rack and Pedestal dual use)
### Storage
- *SATA controller:*
- AMD SP5100
- 6 x SATA2 300MB/s
- *SAS/SATA Controller:*
- ASUS PIKE2008 3Gbps 8-port SAS card included
### Networking
- 2 x Intel® 82574L + 1 x Mgmt LAN
### Graphics
- Aspeed AST2050 with 8MB VRAM
### On board I/O
- 1 x PSU Power Connector (24-pin SSI power connector + 8-pin SSI
12V + 8-pin SSI 12V power connector)
- 1 x Management Connector , Onboard socket for management card
- 3 x USB pin header , Up to 6 Devices
- 1 x Internal A Type USB Port
- 8 x Fan Header , 4pin (3pin/4pin fan dual support)
- 2 x SMBus
- 1 x Serial Port Header
- 1 x TPM header
- 1 x PS/2 KB/MS port
### Back I/O ports
- 1 x External Serial Port
- 2 x External USB Port
- 1 x VGA Port
- 2 x RJ-45
- 1 x PS/2 KB/Mouse
### Environment
- *Operation temperature:* 10C \~ 35C
- *Non operation temperature:* -40C \~ 70C
- *Non operation humidity:* 20% \~ 90% ( Non condensing)
### Monitoring
- CPU temperatures
- Fan speed (RPM)
### Note:
- \* DDR3 1600 can only be supported with AMD Opteron 6300/6200 series
processor

99
site/docs/hardware/mac_address.md Normal file
View File

@ -0,0 +1,99 @@
---
title: Changing the MAC address
x-toc-enable: true
...
Introduction (GM45+e1000)
=========================
This section is applicable to all Libreboot-supported laptops with the
mobile 4 series chipset (as shown in `$ lspci`)
that use the e1000 ethernet controller (e.g. T400, X200).
The R500 is an exception to this as it does not use the built-in e1000.
On all these laptops, the
[MAC address](https://en.wikipedia.org/wiki/MAC_address)
for the built-in gigabit ethernet controller is stored inside the flash chip,
along with Libreboot and other configuration data. Therefore, installing
Libreboot will overwrite it.
Thus, for these laptops, prebuilt Libreboot already contains a generic
MAC address in the configuration section. This address is `00:f5:f0:40:71:fe
in builds before 2018-01-16 and `00:4c:69:62:72:65` (see the ascii character
set) afterwards.
Unless you change it, your computer will boot and use it. This can lead
to network problems if you have more than one Libreboot computer on
the same layer2 network (e.g. on the same network switch). The switch
(postman) will simply not know who to deliver to as the MAC (house) addresses
will be the same.
To prevent these address clashes, you can either modify prebuilt Libreboot
to use an address of your own choosing or you can change the address in your
operating system's boot scripts.
In either case, it is a good idea to write down the address that your
computer originally had.
Obtaining the existing MAC address
==================================
The existing MAC address may be obtained by the following methods:
1. Run `ip link` or `ifconfig` in a terminal/console/shell;
find your ethernet device (e.g., **enpXXX** or **ethXXX**),
and look for a set of 12 colon-delimited
[hexadecimal digits](https://en.wikipedia.org/wiki/Hexadecimal).
For example: `00:f3:f0:45:91:fe`.
* `$ ip link
... link/ether ??:??:??:??:??:?? brd ...
* Alternatively:
ifconfig
... ether ??:??:??:??:??:?? txqueuelen ...
2. Otherwise you can read the white label that is often found on the
motherboard under the memory sticks:
![](https://av.libreboot.org/t400/macaddress1.jpg)
3. The MAC address is usually listed on the laptop chassis as well. This one
will be incorrect if the motherboard was changed and the stickers were not
updated.
Changing the MAC address in the operating system
================================================
There are three portable ways of doing so:
1. Using the new iproute2 package:
ip link set <interface> down
ip link set dev <interface> address 00:4c:69:62:72:65
ip link set <interface> up
2. Using the old `ifconfig` command:
ifconfig <interface> hw ether 00:4c:69:62:72:65
3. Using the macchanger package.
You can use use of these three methods in your operating system's
init scripts or you can use your operating system's own networking
configuration. Refer to your operating system's documentation for
how to do this.
Changing the MAC address on X200/T400/T500/W500
===============================================
On GM45 laptops with ICH9M southbridge and Intel PHY module, the MAC address
is hardcoded in boot flash, which means it can be changed if you re-flash.
See [ich9utils documentation](../install/ich9utils.md)

200
site/docs/hardware/macbook21.md Normal file
View File

@ -0,0 +1,200 @@
---
title: MacBook2,1 and MacBook1,1
x-toc-enable: true
...
There is an Apple laptop called the macbook1,1 from 2006 which uses the
same i945 chipset as the ThinkPad X60/T60. A developer (Mono Moosbart) ported
the Macbook2,1 to coreboot, working alongside Vladimir Serbinenko. The ROM
images also work on the macbook1,1. Libreboot's support and documentation for
this is based on the Libreboot project, which also supports macbook2,1
Some macbook2,1 models are late 2006, others are early 2007.
You do not need to use external flashing equipment when flashing the MacBook2,1
but the MacBook1,1 requires external flashing equipment while running Apple EFI
firmware.
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.
Compatibility
=============
The following pages list many models of MacBook1,1 and MacBook2,1:
* <http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook1,1>
* <http://www.everymac.com/ultimate-mac-lookup/?search_keywords=MacBook2,1>
Models
------
Specifically (Order No. / Model No. / CPU) for macbook 1,1:
* MA255LL/A / A1181 (EMC 2092) / Core Duo T2500 *(tested - working)*
* MA254LL/A / A1181 (EMC 2092) / Core Duo T2400 *(tested - working)*
* MA472LL/A / A1181 (EMC 2092) / Core Duo T2500 (untested)
For macbook 2,1:
* MA699LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T5600 *(tested -
working)*
* MA701LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 *(tested -
working)*
* MB061LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7200 (untested)
* MA700LL/A / A1181 (EMC 2121) / Intel Core 2 Duo T7200 *(tested -
working)*
* MB063LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 (works)
* MB062LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 *(tested -
working)*
Internal flashing
=================
Macbook2,1 can always be flashed internally, even if running Apple firmware:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w your.rom
Macbook1,1 same as above, but if running Apple firmware see below for
external flashing.
External flashing
=================
macbook1,1 requires external flashing, if running the default Apple firmware.
macbook2,1 can be flased internally, regardless.
If running coreboot, libreboot or Libreboot, you can already internally re-flash.
[This page shows disassembly
guides](https://www.ifixit.com/Device/MacBook_Core_2_Duo)
Locate the flash. It'll be a SOIC8, which looks like this:
![](https://av.libreboot.org/chip/soic8.jpg)
motherboard. [How to remove the
motherboard](https://www.ifixit.com/Guide/MacBook+Core+2+Duo+PRAM+Battery+Replacement/529).
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
You need to replace OS X with GNU+Linux before flashing Libreboot. (OSX
won't run at all in Libreboot), if you wish to internally flash on a macbook21.
Libreboot won't boot OSX either (well, maybe with Tianocore it would, but that's
untested and OSX is inferior to GNU+Linux). In general you should think of
your Macbook like a regular laptop, for the purposes of anything coreboot.
If it's a macbook2,1 with the core2duo processors, you can run
a 64-bit distro. For macbook 1,1 the CPU probably only has 32-bit support.
GNU+Linux on Apple EFI firmware
===============================
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.)
Coreboot wiki page
==================
The following page has some information:
* <https://www.coreboot.org/Board:apple/macbook21>
Issues and solutions/workarounds
================================
There is one mouse button only, however multiple finger tapping
works. Battery life is poor compared to X60/T60. The Apple logo on the
back is a hole, exposing the backlight, which means that it glows. You
should [cover it up](http://cweiske.de/tagebuch/tuxbook.htm).
*The MacBook2,1 comes with a webcam which does not work with free
software. Webcams are a privacy and security risk; cover it up! Or
remove it.*
Enable AltGr
------------
The keyboard has a keypad enter instead of an AltGr. The first key on
the right side of the spacebar is the Apple "command" key. On its
right is the keypad enter. We can make it act as an AltGr.
If your operating system is Trisquel or other dpkg-based distribution,
there is an easy solution. Under root (or sudo) run
dpkg-reconfigure keyboard-configuration
and select the option "apple laptop", leave other settings as their
defaults until you are given the option "Use Keypad Enter as
AltGr". Select this. The keypad enter key will then act as an AltGr
everywhere.
For Parabola or other systemd-based distributions you can enable AltGr
manually. Simply add the line
KEYMAP_TOGGLE=lv3:enter_switch
to the file /etc/vconsole.conf and then restart the computer.
Enable 3-finger tap
-------------------
A user submitted a utility to enable 3-finger tap on this laptop. It's
available at *resources/utils/macbook21-three-finger-tap* in the
Libreboot git repository.
Make touchpad more responsive
-----------------------------
Linux kernels of version 3.15 or lower might make the touchpad
extremely sluggish. A user reported that they could get better
response from the touchpad with the following in their xorg.conf:
Section "InputClass"
Identifier "Synaptics Touchpad"
Driver "synaptics"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "synaptics"
The next two values determine how much pressure one needs
for tapping, moving the cursor and other events.
Option "FingerLow" "10"
Option "FingerHigh" "15"
Do not emulate mouse buttons in the touchpad corners.
Option "RTCornerButton" "0"
Option "RBCornerButton" "0"
Option "LTCornerButton" "0"
Option "LBCornerButton" "0"
One finger tap = left-click
Option "TapButton1" "1"
Two fingers tap = right-click
Option "TapButton2" "3"
Three fingers tap = middle-mouse
Option "TapButton3" "2"
Try to not count the palm of the hand landing on the touchpad
as a tap. Not sure if helps.
Option "PalmDetect" "1"
The following modifies how long and how fast scrolling continues
after lifting the finger when scrolling
Option "CoastingSpeed" "20"
Option "CoastingFriction" "200"
Smaller number means that the finger has to travel less distance
for it to count as cursor movement. Larger number prevents cursor
shaking.
Option "HorizHysteresis" "10"
Option "VertHysteresis" "10"
Prevent two-finger scrolling. Very jerky movement
Option "HorizTwoFingerScroll" "0"
Option "VertTwoFingerScroll" "0"
Use edge scrolling
Option "HorizEdgeScroll" "1"
Option "VertEdgeScroll" "1"
EndSection

63
site/docs/hardware/r400.md Normal file
View File

@ -0,0 +1,63 @@
---
title: ThinkPad R400
x-toc-enable: true
...
It is believed that all or most R400 laptops are compatible. See notes
about [CPU
compatibility](../install/r400_external.html#cpu_compatibility) for
potential incompatibilities.
There are two possible flash chip sizes for the R400: 4MiB (32Mbit) or
8MiB (64Mbit). This can be identified by the type of flash chip below
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The R400 laptops come with the ME (and sometimes AMT in addition)
before flashing libreboot. Libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
EC update {#ecupdate}
=========
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running libreboot is unknown. Libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery
handling.
Compatibility (without blobs) {#compatibility_noblobs}
-----------------------------
### Hardware virtualization (vt-x) {#hwvirt}
The R400, when run without CPU microcode updates in coreboot, currently
kernel panics if running QEMU with vt-x enabled on 2 cores for the
guest. With a single core enabled for the guest, the guest panics (but
the host is fine). Working around this in QEMU might be possible; if
not, software virtualization should work fine (it's just slower).
On GM45 hardware (with libreboot), make sure that the *kvm* and
*kvm\_intel* kernel modules are not loaded, when using QEMU.
The following errata datasheet from Intel might help with investigation:
<http://download.intel.com/design/mobile/specupdt/320121.pdf>
The R400 is almost identical to the X200, code-wise. See
[x200.md](x200.md).
TODO: put hardware register logs here like on the [X200](x200.md) and
[T400](t400.md) page.

23
site/docs/hardware/r500.md Normal file
View File

@ -0,0 +1,23 @@
---
title: ThinkPad R500
x-toc-enable: true
...
This board as basically identical to the T500, and has very similar disassembly.
You must take it apart and flash the chip externally.
The chip is 4MiB NOR flash (SPI protocol) is SOIC8 form factory.
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](../install/spi.md)
Unlike other GM45+ICH9M thinkpads in Libreboot, the R500 doesn't have an Intel
PHY (for Gigabit Ethernet). However, Libreboot still includes an Intel flash
descriptor, but with just the descriptor and BIOS region. The `ich9gen` program
supports this fully.
Therefore, you do not have to worry about the MAC address. The onboard NIC for
ethernet is made by Broadcom (and works in linux-libre).
Refer to T500 disassembly guide. The R500 disassembly procedure is almost
identical.

63
site/docs/hardware/t400.md Normal file
View File

@ -0,0 +1,63 @@
---
title: ThinkPad T400
x-toc-enable: true
...
Introduction
============
It is believed that all or most laptops of the model T400 are compatible. See notes
about [CPU
compatibility](../install/t400_external.html#cpu_compatibility) for
potential incompatibilities.
There are two possible flash chip sizes for the T400: 4MiB (32Mbit) or
8MiB (64Mbit). This can be identified by the type of flash chip below
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T400 laptops come with the ME (and sometimes AMT in addition)
before flashing libreboot. Libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
EC update {#ecupdate}
=========
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running libreboot is unknown. Libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery
handling.
Compatibility (without blobs) {#compatibility_noblobs}
-----------------------------
### Hardware virtualization (vt-x) {#hwvirt}
The T400, when run without CPU microcode updates in coreboot, currently
kernel panics if running QEMU with vt-x enabled on 2 cores for the
guest. With a single core enabled for the guest, the guest panics (but
the host is fine). Working around this in QEMU might be possible; if
not, software virtualization should work fine (it's just slower).
On GM45 hardware (with libreboot), make sure that the *kvm* and
*kvm\_intel* kernel modules are not loaded, when using QEMU.
The following errata datasheet from Intel might help with investigation:
<http://download.intel.com/design/mobile/specupdt/320121.pdf>
The T400 is almost identical to the X200, code-wise. See
[x200.md](x200.md).

65
site/docs/hardware/t500.md Normal file
View File

@ -0,0 +1,65 @@
---
title: ThinkPad T500
x-toc-enable: true
...
Introduction
============
It is believed that all or most T500 laptops are compatible. See notes
about [CPU
compatibility](../install/t500_external.html#cpu_compatibility) for
potential incompatibilities.
W500 is also compatible, and mostly the same design as T500.
There are two possible flash chip sizes for the T500: 4MiB (32Mbit) or
8MiB (64Mbit). This can be identified by the type of flash chip below
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The T500 laptops come with the ME (and sometimes AMT in addition)
before flashing libreboot. Libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
EC update {#ecupdate}
=========
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running libreboot is unknown. Libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. bettery battery
handling.
Compatibility (without blobs) {#compatibility_noblobs}
-----------------------------
### Hardware virtualization (vt-x) {#hwvirt}
The T500, when run without CPU microcode updates in coreboot, currently
kernel panics if running QEMU with vt-x enabled on 2 cores for the
guest. With a single core enabled for the guest, the guest panics (but
the host is fine). Working around this in QEMU might be possible; if
not, software virtualization should work fine (it's just slower).
On GM45 hardware (with libreboot), make sure that the *kvm* and
*kvm\_intel* kernel modules are not loaded, when using QEMU.
The following errata datasheet from Intel might help with investigation:
<http://download.intel.com/design/mobile/specupdt/320121.pdf>
The T500 is almost identical to the X200, code-wise. See
[x200.md](x200.md).

3871
site/docs/hardware/text/kfsn4-dre/bootlog.txt Normal file
View File

File diff suppressed because it is too large Load Diff

196
site/docs/hardware/text/x200s/cblog00.txt Normal file
View File

@ -0,0 +1,196 @@
USB
coreboot-4.0-7318-g129462d Mon Dec 8 22:08:18 GMT 2014 starting...
running main(bist = 0)
WARNING: Ignoring S4-assertion-width violation.
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using low power mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:b
2:51:b
DDR mask 5, DDR 3
Bank 0 populated:
Raw card type: F
Row addr bits: 14
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
SFF platform unsupported in RCOMP initialization.
USB
coreboot-4.0-7318-g129462d Mon Dec 8 22:08:18 GMT 2014 starting...
running main(bist = 0)
Interrupted RAM init, reset required.
USB
coreboot-4.0-7318-g129462d Mon Dec 8 22:08:18 GMT 2014 starting...
running main(bist = 0)
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using low power mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:b
2:51:b
DDR mask 5, DDR 3
Bank 0 populated:
Raw card type: F
Row addr bits: 14
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
SFF platform unsupported in RCOMP initialization.
USB
coreboot-4.0-7318-g129462d Mon Dec 8 22:08:18 GMT 2014 starting...
running main(bist = 0)
Interrupted RAM init, reset required.
USB
coreboot-4.0-7318-g129462d Mon Dec 8 22:08:18 GMT 2014 starting...
running main(bist = 0)
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using low power mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:b
2:51:b
DDR mask 5, DDR 3
Bank 0 populated:
Raw card type: F
Row addr bits: 14
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
SFF platform unsupported in RCOMP initialization.

1569
site/docs/hardware/text/x200s/cblog01.txt Normal file
View File

File diff suppressed because it is too large Load Diff

77
site/docs/hardware/text/x200s/cblog02.txt Normal file
View File

@ -0,0 +1,77 @@
USB
coreboot-4.0-7551-ge420139-dirty Wed Dec 10 16:34:05 GMT 2014 starting...
running main(bist = 0)
WARNING: Ignoring S4-assertion-width violation.
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using high performance mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:b
2:51:b
DDR mask 5, DDR 3
Bank 0 populated:
Raw card type: F
Row addr bits: 14
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 2
tAAmin: 105
tCKmin: 15
Max clock: 533 MHz
CAS: 0x01c0
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
Memory configured in dual-channel assymetric mode.
Memory map:
TOM = 384MB
TOLUD = 384MB
TOUUD = 384MB
REMAP: base = 65535MB
limit = 0MB
usedMEsize: 0MB
Performing Jedec initialization at address 0x00000000.
Performing Jedec initialization at address 0x08000000.
Performing Jedec initialization at address 0x10000000.
Final timings for group 0 on channel 0: 6.1.0.3.2
Final timings for group 1 on channel 0: 6.0.2.6.3
Final timings for group 2 on channel 0: 6.1.2.0.1
Final timings for group 3 on channel 0: 6.1.0.7.3
Timing under-/overflow during receive-enable calibration.

158
site/docs/hardware/text/x200s/cblog03.txt Normal file
View File

@ -0,0 +1,158 @@
USB
coreboot-4.0-7551-ge420139-dirty Wed Dec 10 16:34:05 GMT 2014 starting...
running main(bist = 0)
WARNING: Ignoring S4-assertion-width violation.
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using high performance mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:ff
2:51:b
DDR mask 4, DDR 3
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
DIMMs support 666 MHz, but chipset only runs at up to 533. Limiting...
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Changing memory frequency: old 3, new 6.
Setting IGD memory frequencies for VCO #1.
Memory configured in single-channel mode.
Memory map:
TOM = 128MB
TOLUD = 128MB
TOUUD = 128MB
REMAP: base = 65535MB
limit = 0MB
usedMEsize: 0MB
Performing Jedec initialization at address 0x00000000.
Final timings for group 0 on channel 1: 6.0.2.6.4
Final timings for group 1 on channel 1: 6.0.2.6.4
Final timings for group 2 on channel 1: 6.0.2.8.3
Final timings for group 3 on channel 1: 6.0.2.8.6
Lower bound for byte lane 0 on channel 1: 0.0
Upper bound for byte lane 0 on channel 1: 10.4
Final timings for byte lane 0 on channel 1: 5.2
Lower bound for byte lane 1 on channel 1: 0.0
Upper bound for byte lane 1 on channel 1: 11.2
Final timings for byte lane 1 on channel 1: 5.5
Lower bound for byte lane 2 on channel 1: 0.0
Upper bound for byte lane 2 on channel 1: 10.5
Final timings for byte lane 2 on channel 1: 5.2
Lower bound for byte lane 3 on channel 1: 0.0
Upper bound for byte lane 3 on channel 1: 9.7
Final timings for byte lane 3 on channel 1: 4.7
Timing overflow during read training.
Read training failure: lower bound.
USB
coreboot-4.0-7551-ge420139-dirty Wed Dec 10 16:34:05 GMT 2014 starting...
running main(bist = 0)
Interrupted RAM init, reset required.
USB
coreboot-4.0-7551-ge420139-dirty Wed Dec 10 16:34:05 GMT 2014 starting...
running main(bist = 0)
Stepping B3
2 CPU cores
AMT enabled
capable of DDR2 of 800 MHz or lower
VT-d enabled
GMCH: GS45, using high performance mode by default
TXT enabled
Render frequency: 533 MHz
IGD enabled
PCIe-to-GMCH enabled
GMCH supports DDR3 with 1067 MT or less
GMCH supports FSB with up to 1067 MHz
SMBus controller enabled.
0:50:ff
2:51:b
DDR mask 4, DDR 3
Bank 1 populated:
Raw card type: B
Row addr bits: 15
Col addr bits: 10
byte width: 1
page size: 1024
banks: 8
ranks: 1
tAAmin: 105
tCKmin: 12
Max clock: 666 MHz
CAS: 0x07e0
DIMMs support 666 MHz, but chipset only runs at up to 533. Limiting...
Trying CAS 7, tCK 15.
Found compatible clock / CAS pair: 533 / 7.
Timing values:
tCLK: 15
tRAS: 20
tRP: 7
tRCD: 7
tRFC: 104
tWR: 8
tRD: 11
tRRD: 4
tFAW: 20
tWL: 6
Setting IGD memory frequencies for VCO #1.
Memory configured in single-channel mode.
Memory map:
TOM = 128MB
TOLUD = 128MB
TOUUD = 128MB
REMAP: base = 65535MB
limit = 0MB
usedMEsize: 0MB
Performing Jedec initialization at address 0x00000000.
Final timings for group 0 on channel 1: 6.0.2.7.6
Final timings for group 1 on channel 1: 6.0.2.6.6
Final timings for group 2 on channel 1: 6.0.2.8.7
Final timings for group 3 on channel 1: 6.1.0.2.5
Lower bound for byte lane 0 on channel 1: 0.0
Upper bound for byte lane 0 on channel 1: 10.3
Final timings for byte lane 0 on channel 1: 5.1
Lower bound for byte lane 1 on channel 1: 0.0
Upper bound for byte lane 1 on channel 1: 11.3
Final timings for byte lane 1 on channel 1: 5.5
Lower bound for byte lane 2 on channel 1: 0.0
Upper bound for byte lane 2 on channel 1: 10.5
Final timings for byte lane 2 on channel 1: 5.2
Lower bound for byte lane 3 on channel 1: 0.0
Upper bound for byte lane 3 on channel 1: 9.6
Final timings for byte lane 3 on channel 1: 4.7
Timing overflow during read training.
Read training failure: lower bound.

165
site/docs/hardware/x200.md Normal file
View File

@ -0,0 +1,165 @@
---
title: ThinkPad X200
x-toc-enable: true
...
Introduction
============
It is believed that all X200 laptops are compatible. X200S and X200
Tablet will also work, [depending on the configuration](#x200s).
It may be possible to put an X200 motherboard in an X201 chassis, though this
is currently untested by the libreboot project. The same may also apply between
X200S and X201S; again, this is untested. *It's most likely true.*
There are two possible flash chip sizes for the X200: 4MiB (32Mbit) or
8MiB (64Mbit). This can be identified by the type of flash chip below
the palmrest: 4MiB is SOIC-8, 8MiB is SOIC-16.
*The X200 laptops come with the ME (and sometimes AMT in addition)
before flashing libreboot. Libreboot disables and removes it by using a
modified descriptor: see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)
Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)
EC update {#ecupdate}
=========
It is recommended that you update to the latest EC firmware version. The
[EC firmware](../../faq.md#ec-embedded-controller-firmware) is separate from
libreboot, so we don't actually provide that, but if you still have
Lenovo BIOS then you can just run the Lenovo BIOS update utility, which
will update both the BIOS and EC version. See:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
- [X200, X200s, X200si BIOS Update](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x200/downloads/ds015007)
- [X200t BIOS Update](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-tablet-laptops/thinkpad-x200-tablet/downloads/ds018814)
NOTE: this can only be done when you are using Lenovo BIOS. How to
update the EC firmware while running libreboot is unknown. Libreboot
only replaces the BIOS firmware, not EC.
Updated EC firmware has several advantages e.g. better battery
handling.
Battery Recall {#batteryrecall}
=========
[On 21 April 2015, Lenovo expanded a recall on Lenovo batteries found in some ThinkPad models, which includes the X200 and X200S.](https://pcsupport.lenovo.com/cr/en/solutions/hf004122)
To find out if you are affected, use [this Lenovo tool.](https://lenovobattery2014.orderz.com/)
Lenovo advises that owners of the recalled models "should turn off the system, remove the battery,
and only power your ThinkPad by plugging in the AC adapter and power cord."
Upon battery verification, Lenovo will replace recalled batteries free of charge.
Battery replacement instructions for the X200/X200s are found [on this page.](https://pcsupport.lenovo.com/cr/en/parts/pd003507/)
Compatibility (without blobs) {#compatibility_noblobs}
-----------------------------
### Hardware virtualization (vt-x) {#hwvirt}
The X200, when run without CPU microcode updates in coreboot, currently
kernel panics if running QEMU with vt-x enabled on 2 cores for the
guest. With a single core enabled for the guest, the guest panics (but
the host is fine). Working around this in QEMU might be possible; if
not, software virtualization should work fine (it's just slower).
On GM45 hardware (with libreboot), make sure that the *kvm* and
*kvm\_intel* kernel modules are not loaded, when using QEMU.
The following errata datasheet from Intel might help with investigation:
<http://download.intel.com/design/mobile/specupdt/320121.pdf>
Anecdotal reports from at least 1 user suggests that some models with
CPU microcode 1067a (on the CPU itself) might work with vt-x in
libreboot.
LCD compatibility list {#lcd_supported_list}
----------------------
LCD panel list (X200 panels listed there):
<http://www.thinkwiki.org/wiki/TFT_display>
All LCD panels for the X200, X200S and X200 Tablet are known to work.
The X200 Tablet has a screen rotation button on its bezel. Depending
on the operating system it might or might not rotate the screen, the
digitizer (stylus), or the trackpoint accordingly. Utilities are
provided to fix this at *resources/utilities/x200t-screen-rotation* in
the libreboot git repository.
### AFFS/IPS panels {#ips}
#### X200
Adapted from
<https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X200>
Look at wikipedia for difference between TN and IPS panels. IPS have
much better colour/contrast than a regular TN, and will typically have
good viewing angles.
These seem to be from the X200 tablet. You need to find one without the
glass touchscreen protection on it (might be able to remove it, though).
It also must not have a digitizer on it (again, might be possible to
just simply remove the digitizer).
- BOE-Hydis HV121WX4-120, HV121WX4-110 or HV121WX4-100 - cheap-ish,
might be hard to find
- Samsung LTN121AP02-001 - common to find, cheap
*If your X200 has an LED backlit panel in it, then you also need to get
an inverter and harness cable that is compatible with the CCFL panels.
To see which panel type you have, see
[\#led\_howtotell](#led_howtotell). If you need the inverter/cable, here
are part numbers: 44C9909 for CCFL LVDS cable with bluetooth and camera
connections, and 42W8009 or 42W8010 for the inverter.*
There are glossy and matte versions of these. Matte means anti-glare,
which is what you want (in this authors opinion).
Refer to the HMM (hardware maintenance manual) for how to replace the
screen.
Sources:
- [ThinkPad Forums - Matte AFFS Panel on
X200](http://forum.thinkpads.com/viewtopic.php?f=2&t=84941)
- [ThinkPad Forums - Parts for X200 AFFS
Mod](http://forum.thinkpads.com/viewtopic.php?p=660662#p660662)
- [ThinkWiki.de - X200 Displayumbau](http://thinkwiki.de/X200_Displayumbau)
### X200S
<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.
How to tell if it has an LED or CCFL? {#led_howtotell}
-------------------------------------
Some X200s have a CCFL backlight and some have an LED backlight, in their LCD
panel. This also means that the inverters will vary, so you must be careful if
ever replacing either the panel and/or inverter. (a CCFL inverter is
high-voltage and will destroy an LED backlit panel).
CCFLs contain mercury. An X200 with a CCFL backlight will (unless it has been
changed to an LED, with the correct inverter. Check with your supplier!) say
the following: *"This product contains Lithium Ion Battery, Lithium Battery and
a lamp which contains mercury; dispose according to local, state or federal
laws"* (one with an LED backlit panel will say something different).
Hardware register dumps {#regdumps}
-----------------------
The coreboot wiki
[shows](http://www.coreboot.org/Motherboard_Porting_Guide) how to
collect various logs useful in porting to new boards. Following are
outputs from the X200:
- BIOS 3.15, EC 1.06
- [hwdumps/x200/](hwdumps/x200/)

100
site/docs/index.md Normal file
View File

@ -0,0 +1,100 @@
---
title: Documentation
...
Information about Libreboot releases can be found at
[release.md](release.md). Always check [libreboot.org](/) for updates. New
releases of Libreboot are announced in the [news section](../news/) of the
website.
[Answers to Frequently Asked Questions about Libreboot](../faq.md).
Installing libreboot
====================
- [What systems can I use libreboot on?](hardware/)
- [How to install libreboot](install/)
Installing operating systems
============================
- [How to install GNU+Linux on a libreboot system](gnulinux/)
- [How to install BSD on a libreboot system](bsd/)
Information for developers
==========================
- [How to compile the libreboot source code](git/)
- [Depthcharge payload](depthcharge/) (OBSOLETE in current Libreboot releases)
- [GRUB payload](grub/)
Other information
=================
- [Miscellaneous](misc/)
- [List of codenames](misc/codenames.md)
How do I know what version I'm running? {#version}
========================================
If you are at least 127 commits after release 20150518 (commit message
*build/roms/helper: add version information to CBFS*) (or you have any
*upstream* stable release of libreboot after 20150518), then you can
press C at the GRUB console, and use this command to find out what
version of libreboot you have:
cat (cbfsdisk)/lbversion
Alternatively, you may run this command in GRUB:
lscoreboot
If you're using SeaBIOS, information is provided there aswell.
This will also work on non-release images (the version string is
automatically generated, using `git describe --tags HEAD`), built from
the git repository. A file named `version` will also be included in the
archives that you downloaded (if you are using release archives).
If it exists, you can also extract this `lbversion` file by using the
`cbfstool` utility which libreboot includes, from a ROM image that you
either dumped or haven't flashed yet. In your distribution, run
cbfstool on your ROM image (`libreboot.rom`, in this example):
./cbfstool libreboot.rom extract -n lbversion -f lbversion
You will now have a file, named `lbversion`, which you can read in
whatever program it is that you use for reading/writing text files.
For git, it's easy. Just check the git log.
For releases on or below 20150518, or snapshots generated from the git
repository below 127 commits after 20150518, you can find a file named
*commitid* inside the archives. If you are using pre-built ROM images
from the libreboot project, you can press C in GRUB for access to the
terminal, and then run this command:
lscoreboot
You may find a date in here, detailing when that ROM image was built.
For pre-built images distributed by the libreboot project, this is a
rough approximation of what version you have, because the version
numbers are dated, and the release archives are typically built on the
same day as the release; you can correlate that with the release
information in [release.md](release.md).
For 20160818, note that the lbversion file was missing from CBFS on GRUB
images. You can still find out what libreboot version you have by
comparing checksums of image dumps (with the descriptor blanked out with
00s, and the same done to the ROMs from the release archive, if you are
on a GM45 laptop).
There may also be a ChangeLog file included in your release archive, so
that you can look in there to figure out what version you have.
You can also check the documentation that came with your archives, and
in *docs/release.html* 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.

224
site/docs/install/c201.md Normal file
View File

@ -0,0 +1,224 @@
---
title: ASUS Chromebook C201 installation guide
x-toc-enable: true
...
TODO: NUKE. ARM has been dropped from Libreboot, for now.
TODO: Replace this with documentation about uboot instead
TODO: integrate uboot in libreboot, both as a generic bootloader payload for
coreboot, and on its own, for hardware initialization of many targets.
The version of Depthcharge used here is very old, from 2016, and support for
this laptop was dropped in recent releases. It will be re-added at a later
date. If you wish to use Libreboot on this board, right now you must install
Libreboot 20160907. This page has been retained on libreboot.org for now, but
you should refer to the documentation provided in the Libreboot 20160907
release if you want to learn more. NOTE: in that release, the documentation is
written in raw HTML, because the Markdown-based static site generator used on
libreboot.org had not yet been written at that point.
These instructions are for installing Libreboot to the ASUS Chromebook
C201 (more known under a name [*veyron speedy*](../misc/codenames.md)).
Since the device ships with Coreboot, the installation
instructions are the same before and after flashing Libreboot for the
first time.
Look at the [list of ROM images](#rom) to see which image is compatible
with your device.
Libreboot can be installed internally from the device, with sufficient
privileges. The installation process requires using *Google's modified
version of flashrom*, that has support for reflashing the Chromebook's
SPI flash. Otherwise, flashing externally will work with the upstream
flashrom version.
*Google's modified version of flashrom* is free software and its
source code is made available by Google:
[flashrom](https://chromium.googlesource.com/chromiumos/third_party/flashrom/).\
It is not distributed along with Libreboot yet. However, it is
preinstalled on the device, with ChromeOS.
Installing Libreboot internally requires sufficient privileges on the system
installed on the device. When the device has ChromeOS installed (as it does
initially), it is necessary to gain root privileges in ChromeOS, to be able to
access a root shell.
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 [recovery mode
screen](../depthcharge/#recovery_mode_screen) and [enabling developer
mode](../depthcharge/#enabling_developer_mode) are available on the page
dedicated to [depthcharge](../depthcharge/).
Once developer mode is enabled, the device will boot to the [developer
mode screen](../depthcharge/#developer_mode_screen). ChromeOS can be
booted by waiting for 30 seconds (the delay is shortened in Libreboot)
or by pressing *Ctrl + D*
After the system has booted, root access can be enabled by clicking on
the *Enable debugging features* link. A confirmation dialog will ask
whether to proceed.\
After confirming by clicking *Proceed*, the device will reboot and ask
for the root password to set. Finally, the operation has to be confirmed
by clicking *Enable*.
After setting the root password, it becomes possible to log-in as root.
A tty prompt can be obtained by pressing *Ctrl + Alt + Next*. The
*Next* key is the one on the top left of the keyboard.
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.
Configuring verified boot parameters
------------------------------------
It is recommended to have access to the [developer mode
screen](../depthcharge/#developer_mode_screen) and to [configure the
following verified boot
parameters](../depthcharge/#configuring_verified_boot_parameters):
- Kernels signature verification: *disabled*
- External media boot: *enabled*
Those changes can be reverted later, when the device is known to be in a
working state.
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 *read-only* part of the flash.
To access the screw, the device has to be opened. There are 8 screws to
remove from the bottom of the device, as shown on the picture below. Two
are hidden under the top pads. After removing the screws, the keyboard
plastic part can be carefully detached from the rest. *Beware: there
are cables attached to it!* It is advised to flip the keyboard plastic
part over, as shown on the picture below. The write protect screw is
located next to the SPI flash chip, circled in red in the picture below.
It has to be removed.
[![Screws](https://av.libreboot.org/c201/screws.jpg)](https://av.libreboot.org/c201/screws.jpg) [![WP
screw](https://av.libreboot.org/c201/wp-screw.jpg)](https://av.libreboot.org/c201/wp-screw.jpg)
The write protect screw can be put back in place later, when the device
is known to be in a working state.
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 *read-only* coreboot partition, that becomes
writable after removing the write-protect screw.
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 `veyron_speedy` release (or build) have to be
transferred to the device.
The following operations have to be executed with root privileges on the
device (e.g. using the `root` account). In addition, the
`cros-flash-replace` script has to be made executable:
chmod a+x cros-flash-replace
The SPI flash has to be read first:
flashrom -p host -r flash.img
*Note: it might be a good idea to copy the produced flash.img file at
this point and store it outside of the device for backup purposes.*
Then, the `cros-flash-replace` script has to be executed as such:
sudo bash ./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:
flashrom -p host -w flash.img
You should also see within the output the following:
Verifying flash... VERIFIED.
Shut down. The device will now boot to Libreboot.
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
`WP#` since after removing the screw it is pulled up weakly to 3v3. Before
writing to the chip externally, the battery has to be unplugged.
Battery connector is located under the heat spreader, that has to be
unscrewed from the rest of the case. It is located on
the right and has colorful cables, as shown on the picture below.
[![SPI flash
layout](https://av.libreboot.org/c201/spi-flash-layout.jpg)](https://av.libreboot.org/c201/spi-flash-layout.jpg)
[![Battery
connector](https://av.libreboot.org/c201/battery-connector.jpg)](https://av.libreboot.org/c201/battery-connector.jpg)
All the files from the `veyron_speedy` release (or build) have to be
transferred to the host.
The following operations have to be executed with root privileges on the
host (e.g. using the `root` account). In addition, the
`cros-flash-replace` script has to be made executable:
chmod a+x cros-flash-replace
The SPI flash has to be read first (using the right spi programmer):
flashrom -p *programmer* -r flash.img
*Note: it might be a good idea to copy the produced flash.img file at
this point and store it outside of the device for backup purposes.*
Then, the `cros-flash-replace` script has to be executed as such:
./cros-flash-replace flash.img coreboot ro-frid
If any error is shown, it is definitely a bad idea to go further than
this point.
The resulting flash image can then be flashed back (using the right spi
programmer):
flashrom -p *programmer* -w flash.img
You should also see within the output the following:
Verifying flash... VERIFIED.
The device will now boot to Libreboot.
Installing Debian
---------------------
Debian is recommended for this device (which is on that list.
See <https://wiki.debian.org/InstallingDebianOn/Asus/C201>.
Also look at the HCL entry for operating systems (Debian, Devuan, Parabola):
<https://libreboot.org/docs/hardware/c201.md>

23
site/docs/install/d510mo.md Normal file
View File

@ -0,0 +1,23 @@
---
title: D510MO flashing tutorial
...
This guide is for those who want libreboot on their Intel D510MO
motherboard while they still have the original BIOS present.
NOTE: D410PT is another designation and it's the same board. Flash the same ROM.
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
Flashing instructions {#clip}
=====================
Refer to [spi.md](spi.md) for how to re-flash externally.
This is an image of the flash chip, for reference:\
![](https://av.libreboot.org/d510mo/d510mo.jpg)

17
site/docs/install/d945gclf.md Normal file
View File

@ -0,0 +1,17 @@
---
title: Intel D945GCLF flashing tutorial
...
This guide is for those who want libreboot on their Intel D945GCLF
motherboard while they still have the original BIOS present.
For information about this board, go to
[../hardware/d945gclf.md](../hardware/d945gclf.md)
Flashing instructions {#clip}
=====================
Refer to [spi.md](spi.md) for how to re-flash externally.
Here is an image of the flash chip:\
![](https://av.libreboot.org/d945gclf/d945gclf_spi.jpg)

62
site/docs/install/ga-g41m-es2l.md Normal file
View File

@ -0,0 +1,62 @@
---
title: GA-G41M-ES2L flashing tutorial
...
This guide is for those who want libreboot on their Intel GA-G41M-ES2L
motherboard while they still have the original BIOS present.
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
Flashing instructions {#clip}
=====================
Refer to [spi.md](spi.md) for how to set up an SPI programmer for
external flashing. *You can only externally reprogram one of the chips
at a time, and you need to disable the chip that you're not flashing,
by connecting 3v3 to /CS of that chip, so you will actually need second test
clip or IC pin mini grabber.*
NOTE: on GA-G41M-ES2L, the flash shares a common voltage plane with the
southbridge, which draws a lot of current. This will cause under-voltage on
most SPI flashers, so do not use the 3.3V rail from your flasher. Do not
connect +3.3V to the chip. Instead, turn the board on and then turn it off by
holding the power button. With the board powered down, but plugged in, there
will be a 3.3V supply from the ATX PSU. You can then flash, but DO NOT connect
the +3.3V supply from your SPI flasher!
NOTE: You should use a resistor in series, between 1K to 10K ohms, for the 3.3v
connection to the CS pin. This is to protect from over-current.
Here is an image of the flash chip:\
![](https://av.libreboot.org/ga-g41m-es2l/ga-g41m-es2l.jpg)
Internal flashing is possible. Boot with the proprietary BIOS and
GNU+Linux. There are 2 flash chips (one is 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 can still boot the system with just the main flash chip
connected, after desoldering the backup chip. This has been tested while
libreboot was already installed onto the main chip.
NOTE: If you don't flash both chips, the recovery program from the default
factory BIOS will kick in and your board will be soft bricked. Make sure that
you flash both chips!
NOTE: You need the latest flashrom. Just get it on flashrom.org from
their SVN or Git repos.
NOTE: due to a bug in the hardware, the MAC address is hardcoded in
coreboot-libre. Therefore, you must set your own MAC address in your
operating system.

547
site/docs/install/ich9utils.md Normal file
View File

@ -0,0 +1,547 @@
---
title: ich9utils
x-toc-enable: true
...
Introduction
============
The `ich9utils` utility in Libreboot is used to manipulate Intel Flash
Descriptors for ICH9M on laptops such as ThinkPad X200 or T400. Specifically,
the `ich9gen` utility can generate 12KiB descriptor+GbE files for inserting
into the start of a ROM, where everything after that is the BIOS region. These
are special descriptors with the Intel ME region disabled, and Intel ME itself
fully disabled.
ich9utils is handled by the `lbmk` (libreboot-make) build system, but the code
itself is hosted in a separate repository. You can check the Git repositories
linked on [../../git.md](../../git.md) if you wish to download and use it.
It is very *uncommon*, on GM45/ICH9M systems, to have an Intel Flash Descriptor
and GbE but *without* an Intel ME. On *most* of these systems (without Libreboot,
Libreboot or coreboot), there is either descriptor+GbE+ME+BIOS or just BIOS,
where on systems with just the BIOS region an Intel GbE NIC is not present.
In Libreboot (and Libreboot), we provide descriptor+GbE images with Intel ME
disabled and not present in the ROM; this enables the Intel GbE NIC to be used,
while not having an Intel ME present. A consequence of this is that the
malicious features of ME (such as AMT) are not present, however the Intel ME
also handles TPM which is therefore disabled in this setup.
NOTE: If you accidentally flash a ROM *without* descriptor+GbE, it will still
work but the Intel GbE NIC will be dysfunctional. If you do that, just boot up
and correct the problem (and you can use a USB/cardbus/expresscard NIC or WiFi
for internet if necessary). That is the *main reason* why `ich9utils` was
written in the first place; it was already very possible to boot without an
Intel ME by simply not having a descriptor or anything in ROM, just coreboot.
The purpose of `ich9gen` specifically is to get the Intel GbE NIC working but
without the Intel ME being enabled!
ICH9 based systems were the last generation that could be booted *without* an
Intel ME. Future platforms (such as Sandybridge and Ivybridge) require an
Intel ME since the ME on those platforms also handles power management and
some minor initialization functions. On ICH9 based systems (such as X200 or
T400) the Intel ME only handles AMT and TPM, and there's no 30 minute timer
(if you boot later platforms without an Intel ME and descriptor, or invalid
Intel ME firmware, the system will either not boot or will turn off after 30
minutes per a watchdog reset timer).
More information about the ME can be found at
<http://www.coreboot.org/Intel_Management_Engine> and
<http://me.bios.io/Main_Page>.
Another project: <http://io.netgarage.org/me/>
ich9utils
=========
You can find `ich9utils` on the [Git page](../../git.md) or you can download
`lbmk` from the same page and run the following command in there:
./build module ich9utils
You can also find it in the source code tar archives, on Libreboot releases.
In `lbmk`, you can use the following command to generate descriptors:
./build descriptors ich9m`
The Libreboot build system will use the descriptors under `descriptors/ich9m`
when building ROM images for these machines.
Alternatively, you can just clone `ich9utils` directly and run `make` in the
directory, and run the `ich9gen` program directly.
ICH9 show utility {#ich9show}
================
The *ich9show* utility outputs the entire contents of the descriptor and GbE
regions in a given ROM image as supplied by the user. Output is in Markdown
format (Pandoc variant) so that it can be converted easily into various
formats. It could even be piped *directly* into pandoc!
ICH9 gen utility {#ich9gen}
================
When you simply run `ich9gen` without any arguments, it generates
descriptor+GbE images with a default MAC address in the GbE region. If you wish
to use a custom macaddress, you can supply an argument like so:
ich9gen --macaddress 00:1f:16:80:80:80
The above MAC address is just an example. It is recommended that you use the
MAC address officially assigned to your NIC.
Three new files will be created:
- `ich9fdgbe_4m.bin`: this is for GM45 laptops with the 4MB flash
chip.
- `ich9fdgbe_8m.bin`: this is for GM45 laptops with the 8MB flash
chip.
- `ich9fdgbe_16m.bin`: this is for GM45 laptops with the 16MB flash
chip.
These files contain the descriptor+GbE region and are suitable for systems
that have an Intel GbE NIC present. The flash regions (as defined by the
Intel Flash Descriptor) are set *read-write* which means that you can also
re-flash using `flashrom -p internal` in your operating system running on
that machine. This is the default setup used when Libreboot's build system
compiles ROM images.
Alternative versions of these files are also created, which have `ro` in the
filename. If you use *those* versions, all flash regions (as defined by the
Intel Flash Descriptor) will be set to *read only*. This can be useful, for
security purposes, if you wish to ensure that malicious software in your
operating system cannot simply re-flash new firmware.
The region setup created by these descriptors is as follows:
* First 4KiB of flash is: Intel Flash Descriptor
* Next 8KiB after Descriptor: Intel GbE region
* Rest of the flash, after GbE: BIOS region (BIOS region will have Libreboot)
The GbE region contains configuration data for your Intel GbE NIC. You can
find information about this in Intel datasheets, and it is very well described
in the `ich9utils` source code.
Assuming that your Libreboot image is named **libreboot.rom**, copy the
file to where **libreboot.rom** is located and then insert the
descriptor+gbe file into the ROM image.
For 16MiB flash chips:
dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 8MiB flash chips:
dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 4MiB flash chips:
dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
If you wish to have read-only flash (write protected flash), substitute the
above examples with descriptor+GbE images that have `ro` in the filename. RO
here means *read only*, not *Romania*!
The above commands assume that in coreboot you have specified the CBFS size
as no more than the size of the flash, minus 12KiB.
NOTE: `ich9gen` also generates descriptors without a GbE region, where in
those descriptors the Intel GbE is not specified. Those are highly experimental,
and *theoretical* since no such system exists in the wild where ICH9 is used,
no Intel GbE NIC present *and* descriptor present; on such systems, the vendor
will just supply a descriptor-less setup. Those GbE-less descriptor images
created by `ich9gen` are only 4KiB in size, and should *never be used* except
for fun, like, basically shits and/or giggles.
For shits and giggles, R500 ROM images in Libreboot use these no-GbE descriptor
images generated by ich9gen. However, a descriptorless setup would also work
just fine. ThinkPad R500 doesn't have an Intel PHY in it, and it instead uses
a Broadcom NIC for ethernet. In descriptorless mode, ICH9M works very similarly
to older ICH7 chipsets.
Your libreboot.rom image is now ready to be flashed on the system. Refer
back to [../install/\#flashrom](../install/#flashrom) for how to flash
it.
Write-protecting the flash chip
-------------------------------
The `ich9gen` utility (see below) generates two types of descriptor+GbE setup:
* read-write
* read-only
Read on for more information. Use the `ro` files mentioned below, and your
flash will be read-only in software (you can still externally re-flash and read
the contents of flash).
For ease of use, Libreboot provides ROMs that are read-write by default. In
practise, you can boot a Linux kernel with access to lower memory disabled
which will make software re-flashing impossible (unless you reboot with such
memory protections disabled, e.g. `iomem=relaxed` kernel parameter).
ICH9 deblob utility {#ich9deblob}
===================
This was the tool originally used to disable the ME on X200 (later
adapted for other systems that use the GM45 chipset).
[ich9gen](#ich9gen) now supersedes it; ich9gen is better because it does
not rely on dumping the factory.rom image (whereas, ich9deblob does).
Simply speaking, `ich9deblob` takes an original dump of the boot flash, where
that boot flash contains a descriptor that defines the existence of Intel ME,
and modifies it. The Intel Flash Descriptor is modified to disable the ME
region. It disables the ME itself aswell. The GbE region is moved to the
location just after the descriptor. The BIOS region is specified as being
after the descriptor+GbE regions, filling the rest of the boot flash.
The GbE region is largely unedited when using this utility.
Run it like so, with `factory.rom` in the same directory:
./ich9deblob
The `factory.rom` file is your dump of the vendor boot flash. Older versions
of this utility have this file name hardcoded, and for compatibility reasons
it will still work in this manner. However, you can now specify your own file
name.
For example:
./ich9deblob lenovo.rom
A 12kiB file named **deblobbed\_descriptor.bin** will now appear. **Keep
this and the factory.rom stored in a safe location!** The first 4KiB
contains the descriptor data region for your system, and the next 8KiB
contains the gbe region (config data for your gigabit NIC). These 2
regions could actually be separate files, but they are joined into 1
file in this case.
A 4KiB file named **deblobbed\_4kdescriptor.bin** will alternatively
appear, if no GbE region was detected inside the ROM image. This is
usually the case, when a discrete NIC is used (eg Broadcom) instead of
Intel. Only the Intel NICs need a GbE region in the flash chip.
Assuming that your Libreboot image is named **libreboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **libreboot.rom** is located
and then run:
dd if=deblobbed_descriptor.bin of=libreboot.rom bs=12k count=1 conv=notrunc
Alternatively, if you got a the **deblobbed\_4kdescriptor.bin** file (no
GbE defined), do this:
dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=4k count=1 conv=notrunc
(it's very unlikely that you would ever see this. Descriptor without GbE is
very rare, probably non-existant, but theoretically possible and this functionality
is implemented based on Intel datasheets)
The utility will also generate 4 additional files:
* `mkdescriptor.c`
* `mkdescriptor.h`
* `mkgbe.c`
* `mkgbe.h`
These are *self-written* by `ich9deblob`. The `ich9gen` utility was created,
based on this very functionality, with some tweaks made afterwards.
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
build `ich9gen` executable will be able to re-create the very same 12KiB
file from scratch, based on the C structs, this time **without** the
need for a` factory.rom` dump!
You should now have a **libreboot.rom** image containing the correct 4K
descriptor and 8K gbe regions, which will then be safe to flash. Refer
back to [index.md/\#gm45](index.md/#gm45) for how to flash
it.
demefactory utility {#demefactory}
===================
This utility has never been tested, officially, but it *should* work.
This takes a `factory.rom` dump and disables the ME/TPM, but leaves the
region intact. It also sets all regions read-write. Simply put, this means
that you can use the original factory firmware but without the Intel ME enabled.
The ME interferes with flash read/write in flashrom, and the default
descriptor locks some regions. The idea is that doing this will remove
all of those restrictions.
Simply run (with `factory.rom` in the same directory):
./demefactory
It will generate a 4KiB descriptor file (only the descriptor, no GbE).
Insert that into a factory.rom image (NOTE: do this on a copy of it.
Keep the original factory.rom stored safely somewhere):
dd if=demefactory_4kdescriptor.bin of=factory_nome.rom bs=4k count=1 conv=notrunc
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.
The sections below are adapted from (mostly) IRC logs related to early
development getting the ME removed on GM45. They are useful for
background information. This could not have been done without sgsit's
help.
Early notes {#early_notes}
-----------
- <http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf>
page 230 mentions about descriptor and non-descriptor mode (which
wipes out gbe and ME/AMT).
- ~~**See reference to HDA\_SDO (disable descriptor security)**~~
strap connected GPIO33 pin is it on ICH9-M (X200). HDA\_SDO applies
to later chipsets (series 6 or higher). Disabling descriptor
security also disables the ethernet according to sgsit. sgsit's
method involves use of 'soft straps' (see IRC logs below) instead
of disabling the descriptor.
- **and the location of GPIO33 on the x200s: (was an external link.
Putting it here instead)**
[https://av.libreboot.org/x200/gpio33_location.jpg](https://av.libreboot.org/x200/gpio33_location.jpg) -
it's above the number 7 on TP37 (which is above the big intel chip
at the bottom)
- The ME datasheet may not be for the mobile chipsets but it doesn't
vary that much. This one gives some detail and covers QM67 which is
what the X201 uses:
<http://www.intel.co.uk/content/dam/www/public/us/en/documents/datasheets/6-chipset-c200-chipset-datasheet.pdf>
Flash chips {#flashchips}
-----------
- X200 laptop (Mocha-1):
ICH9-M overrides ifd permissions with a strap connected to GPIO33 pin (see IRC notes below)
- The X200 can be found with any of the following flash
chips:
- ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip
- MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb
(4MiB) chip
- MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb
(8MiB) chip
- Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip
sgsit says that the X200s (Pecan-1) with the 64Mb flash chips are (probably)
the ones with AMT (alongside the ME), whereas the 32Mb chips contain
only the ME.
Early development notes {#early_development_notes}
-----------------------
Start (hex) End (hex) Length (hex) Area Name
----------- --------- ------------ ---------
00000000 003FFFFF 00400000 Flash Image
00000000 00000FFF 00001000 Descriptor Region
00000004 0000000F 0000000C Descriptor Map
00000010 0000001B 0000000C Component Section
00000040 0000004F 00000010 Region Section
00000060 0000006B 0000000C Master Access Section
00000060 00000063 00000004 CPU/BIOS
00000064 00000067 00000004 Manageability Engine (ME)
00000068 0000006B 00000004 GbE LAN
00000100 00000103 00000004 ICH Strap 0
00000104 00000107 00000004 ICH Strap 1
00000200 00000203 00000004 MCH Strap 0
00000EFC 00000EFF 00000004 Descriptor Map 2
00000ED0 00000EF7 00000028 ME VSCC Table
00000ED0 00000ED7 00000008 Flash device 1
00000ED8 00000EDF 00000008 Flash device 2
00000EE0 00000EE7 00000008 Flash device 3
00000EE8 00000EEF 00000008 Flash device 4
00000EF0 00000EF7 00000008 Flash device 5
00000F00 00000FFF 00000100 OEM Section
00001000 001F5FFF 001F5000 ME Region
001F6000 001F7FFF 00002000 GbE Region
001F8000 001FFFFF 00008000 PDR Region
00200000 003FFFFF 00200000 BIOS Region
Start (hex) End (hex) Length (hex) Area Name
----------- --------- ------------ ---------
00000000 003FFFFF 00400000 Flash Image
00000000 00000FFF 00001000 Descriptor Region
00000004 0000000F 0000000C Descriptor Map
00000010 0000001B 0000000C Component Section
00000040 0000004F 00000010 Region Section
00000060 0000006B 0000000C Master Access Section
00000060 00000063 00000004 CPU/BIOS
00000064 00000067 00000004 Manageability Engine (ME)
00000068 0000006B 00000004 GbE LAN
00000100 00000103 00000004 ICH Strap 0
00000104 00000107 00000004 ICH Strap 1
00000200 00000203 00000004 MCH Strap 0
00000ED0 00000EF7 00000028 ME VSCC Table
00000ED0 00000ED7 00000008 Flash device 1
00000ED8 00000EDF 00000008 Flash device 2
00000EE0 00000EE7 00000008 Flash device 3
00000EE8 00000EEF 00000008 Flash device 4
00000EF0 00000EF7 00000008 Flash device 5
00000EFC 00000EFF 00000004 Descriptor Map 2
00000F00 00000FFF 00000100 OEM Section
00001000 00002FFF 00002000 GbE Region
00003000 00202FFF 00200000 BIOS Region
Build Settings
--------------
Flash Erase Size = 0x1000
It's a utility called 'Flash Image Tool' for ME 4.x that was used for
this. You drag a complete image into in and the utility decomposes the
various components, allowing you to set soft straps.
This tool is proprietary, for Windows only, but was used to deblob the
X200. End justified means, and the utility is no longer needed since the
ich9deblob utility (documented on this page) can now be used to create
deblobbed descriptors.
GBE (gigabit ethernet) region in SPI flash {#gbe_region}
------------------------------------------
Of the 8K, about 95% is 0xFF. The data is the gbe region is fully
documented in this public datasheet:
<http://www.intel.co.uk/content/dam/doc/application-note/i-o-controller-hub-9m-82567lf-lm-v-nvm-map-appl-note.pdf>
The only actual content found was:
00 1F 1F 1F 1F 1F 00 08 FF FF 83 10 FF FF FF FF
08 10 FF FF C3 10 EE 20 AA 17 F5 10 86 80 00 00
01 0D 00 00 00 00 05 06 20 30 00 0A 00 00 8B 8D
02 06 40 2B 43 00 00 00 F5 10 AD BA F5 10 BF 10
AD BA CB 10 AD BA AD BA 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 01 00 40 28 12 07 40 FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF D9 F0
20 60 1F 00 02 00 13 00 00 80 1D 00 FF 00 16 00
DD CC 18 00 11 20 17 00 DD DD 18 00 12 20 17 00
00 80 1D 00 00 00 1F
The first part is the MAC address set to all 0x1F. It's repeated haly
way through the 8K area, and the rest is all 0xFF. This is all
documented in the datasheet.
The GBe region starts at 0x20A000 bytes from the \*end\* of a factory
image and is 0x2000 bytes long. In Libreboot (deblobbed) the descriptor
is set to put gbe directly after the initial 4K flash descriptor. So the
first 4K of the ROM is the descriptor, and then the next 8K is the gbe
region.
### GBE region: change MAC address {#gbe_region_changemacaddress}
According to the datasheet, it's supposed to add up to 0xBABA but can
actually be others on the X200.
<https://web.archive.org/web/20150912070329/https://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums>
*"One of those engineers loves classic rock music, so they selected
0xBABA"*
In honour of the song *Baba O'Reilly* by *The Who* apparently. We're
not making this stuff up...
0x3ABA, 0x34BA, 0x40BA and more have been observed in the main Gbe
regions on the X200 factory.rom dumps. The checksums of the backup
regions match BABA, however. We think `0xBABA` is the only correct checksum,
because those other, similar checksums were only ever found in the "backup"
GbE regions on factory ROM dumps. In Libreboot, we simply use `0xBABA` and
ensure that both 4KiB regions in GbE NVM have that checksum.
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 `ich9deblob.c` in ich9utils.
- Add the first 0x3F 16bit numbers (unsigned) of the GBe descriptor
together (this includes the checksum value) and that has to add up
to 0xBABA. In other words, the checksum is 0xBABA minus the total of
the first 0x3E 16bit numbers (unsigned), ignoring any overflow.
Flash descriptor region {#flash_descriptor_region}
-----------------------
<http://www.intel.co.uk/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf>
from page 850 onwards. This explains everything that is in the flash
descriptor, which can be used to understand what Libreboot is doing
about modifying it.
How to deblob:
- patch the number of regions present in the descriptor from 5 - 3
- originally descriptor + bios + me + gbe + platform
- modified = descriptor + bios + gbe
- the next stage is to patch the part of the descriptor which defines
the start and end point of each section
- then cut out the gbe region and insert it just after the region
- all this can be substantiated with public docs (ICH9 datasheet)
- the final part is flipping 2 bits. Halting the ME via 1 MCH soft
strap and 1 ICH soft strap
- the part of the descriptor described there gives the base address
and length of each region (bits 12:24 of each address)
- to disable a region, you set the base address to 0xFFF and the
length to 0
- and you change the number of regions from 4 (zero based) to 2
There's an interesting parameter called 'ME Alternate disable', which
allows the ME to only handle hardware errata in the southbridge, but
disables any other functionality. This is similar to the 'ignition' in
the 5 series and higher but using the standard firmware instead of a
small 128K version. Useless for Libreboot, though.
To deblob GM45, you chop out the platform and ME regions and correct the
addresses in flReg1-4. Then you set meDisable to 1 in ICHSTRAP0 and
MCHSTRAP0.
How to patch the descriptor from the factory.rom dump
- map the first 4k into the struct (minus the gbe region)
- set NR in FLMAP0 to 2 (from 4)
- adjust BASE and LIMIT in flReg1,2,3,4 to reflect the new location of
each region (or remove them in the case of Platform and ME)
- set meDisable to 1/true in ICHSTRAP0 and MCHSTRAP0
- extract the 8k GBe region and append that to the end of the 4k
descriptor
- output the 12k concatenated chunk
- Then it can be dd'd into the first 12K part of a coreboot image.
- the GBe region always starts 0x20A000 bytes from the end of the ROM
This means that Libreboot's descriptor region will simply define the
following regions:
- descriptor (4K)
- gbe (8K)
- bios (rest of flash chip. CBFS also set to occupy this whole size)
The data in the descriptor region is little endian, and it represents
bits 24:12 of the address (bits 12-24, written this way since bit 24 is
nearer to left than bit 12 in the binary representation).
So, *x << 12 = address*
If it's in descriptor mode, then the first 4 bytes will be 5A A5 F0 0F.
platform data partition in boot flash (factory.rom / lenovo bios) {#platform_data_region}
-----------------------------------------------------------------
Basically useless for Libreboot, since it appears to be a blob. Removing
it didn't cause any issues in Libreboot. We think it's just random data that
the manufacturer can put there, to use in their firmware. Intel datasheets seem
to suggest that the platform region serves no specific function except to
provide a region in flash for the hardware manufacturer to use, for whatever
purpose (probably just to store other configuration data, to be used by software
running from the BIOS region as per region layout specified in the descriptor).
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, on the X200
thinkpads that were tested.

7
site/docs/install/index.css Normal file
View File

@ -0,0 +1,7 @@
nav#TOC {
min-width:100%;
max-width:100%;
width:100%;
padding:0;
margin:0;
}

449
site/docs/install/index.md Normal file
View File

@ -0,0 +1,449 @@
---
title: Installation instructions
x-toc-enable: true
...
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.
Libreboot flashing can be risky business. Please ensure that you have external
flashing equipment, in case anything goes wrong. The general rule of thumb with
firmware is this: if it's non-free, replace it, but if you're already running
free firmware and it works nicely for you, you do not need to update it.
However, you might want to tweak it or try out newer releases of Libreboot if
they have bug fixes for your board, and/or new security fixes.
If you're already running libre firmware on your board, you should decide for
sure whether you wish to risk it. See changelogs on
the [release logs](../release.md) and decide for yourself.
Which systems are supported?
============================
[Refer to the hardware compatibility page](../hardware/)
MAC address on GM45+ICH9M hardware (ThinkPad X200/R400/T400/T500/W500)
======================================================================
The MAC address is stored in a region of the boot flashed called *GbE NVM*
which is short for *gigabit ethernet non-volatile memory*. Refer to the
following article:
[ich9utils documentation](ich9utils.md)
Libreboot puts a default MAC address in the available ROM images, but this is
a generic MAC address and it's identical on every ROM image. Technically, you
can use it but if you encounter other Libreboot users on the same ethernet
switch, using the same physical network as you, you will encounter a MAC
address conflict.
NOTE: R500 thinkpads do not have an Intel gigabit ethernet NIC, so on that
laptop you can just flash the default ROM and you do not have to worry.
There are also some Intel X4X platforms that use an ICH10 southbridge,
supported in Libreboot, but these are flashed in a *descriptorless* setup,
which means that the MAC address is irrelevant (either there will be an Intel
PHY module that is now unusable, and you use an add-on card, or it doesn't use
an Intel PHY module and the onboard NIC is usable).
Install via host CPU (internal flashing)
========================================
On all mainboards is a built-in programmer, which can read, erase and rewrite
the boot flash. However, it is not always usable by default. For example, it
may be configured to restrict write privileges by the host CPU.
In some situations, the host CPU can rewrite/erase/dump the boot flash.
This is called *internal flashing*. This means that you will run software,
namely `flashrom`, to read/erase/write the contents of the boot flash from a
running operating system on the target device.
NOTE: please also read the sections further down this page. On some systems,
external flashing is required. This means that you power the system down and
use a special tool that connects to and reprograms the boot flash.
NOTE: in some cases, external flashing is possible but special steps are
required. This depends on your mainboard. Again, please read this page
carefully.
Run flashrom on host CPU
------------------------
You can simply take any ROM image from the Libreboot project, and flash it.
Boot a GNU+Linux distribution on the target device, and install flashrom.
In some cases, this is not possible or there are other considerations. Please
read this section *carefully*.
### Flash chip size
Use this to find out:
flashrom -p internal
In the output will be information pertaining to your boot flash.
### Howto: read/write/erase the boot flash (PLEASE CHECK LIST OF EXCEPTIONS BELOW BEFORE YOU ATTEMPT THIS!!!!)
How to read the current chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -r dump.bin
You should still make several dumps, even if you're flashing internally, to
ensure that you get the same checksums. Check each dump using `sha1sum`
How to erase and rewrite the chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w libreboot.rom
If successful, it will either say `VERIFIED` or it will say that the chip
contents are identical to the requested image.
NOTE: there are exceptions where the above is not possible. Read about them in
the sections below:
### Exceptions
#### If your boot flash is currently write-protected
[You must flash it externally](spi.md)
#### ASUS Chromebook C201 (regardless of firmware)
Ignore this section. Instead, refer to the following guide:
[ASUS Chromebook C201 installation guide](c201.md)
NOTE: C201 is dropped in recent Libreboot releases, but will be added later
with u-boot instead of the depthcharge bootloader. For now, use Libreboot
20160907 on this machine.
#### Lenovo ThinkPad X200/X200S/X200T/T400/T400S/T500/W500/R400/R500 running non-free Lenovo BIOS
If you're running one of these, it cannot be flashed internally if you're still
running the non-free Lenovo BIOS firmware.
[You must flash it externally](spi.md)
See notes further down on this page. We have guides for specific thinkpads,
related to disassembly and reassembly so that you can access the flash.
Please also see notes about the built-in MAC address inside the boot flash, for
the onboard NIC (ethernet one); not relevant on R500, which doesn't use an
Intel NIC.
#### Intel D510MO and D410PT running non-free Intel BIOS
[You must flash it externally](spi.md)
D410PT is more or less the same board as D510MO, but we would like more info
about this board. If you have a D410PT mainboard, please contact the Libreboot
project via IRC and ping `leah` before you flash it. When you do so, please
reference this paragraph on this web page.
#### Gigabyte GA-G41M-ES2l (any firmware)
Ignore this section. Internal flashing *is* possible, but there are two chips
and you must flash both chips. Refer to the guide:\
[Gigabyte GA-G41M-ES2L installation guide](ga-g41m-es2l.html)
#### Macbook1,1 running non-free Apple EFI firmware
This laptop requires external flashing. Remove the mainboard and refer to
the [external flashing guide](spi.md); if Libreboot is already running, you
can flash internally.
MacBook2,1 can be flashed internally.
#### ASUS KFSN4-DRE?
Simply boot GNU+Linux with the default vendor firmware, and flash it internally,
but before you do: take a push pin, remove the metal pin, and superglue the
plastic part to the chip. Then remove the chip after you booting your
GNU+Linux system. Install a new chip, and flash *that*.
This board uses LPC flash in a PLCC32 socket. This coreboot page shows an
example of the push pin as a proof of concept:
<http://www.coreboot.org/Developer_Manual/Tools#Chip_removal_tools>
#### ASUS KGPE-D16 running non-free ASUS BIOS
[You must flash it externally](spi.md)
#### ASUS KCMA-D8 running non-free ASUS BIOS
[You must flash it externally](spi.md)
#### ASUS D945GCLF running non-free Intel BIOS
[You must flash it externally](spi.md)
#### ThinkPad X60/X60S/X60T/T60 with Lenovo BIOS {#flashrom_lenovobios}
Here are a list of targets:
* ThinkPad X60/X60S/X60T: flash the X60 ROM
* ThinkPad T60 with Intel GPU: flash the T60 ROM
* ThinkPad T60 with ATI GPU: flash the Headless T60 ROM (no video init, but you
can get a serial console on the RS232 port if you use the Advanced Dock or
Advanced Mini Dock. Connect to it from another machine, using null modem
cable and USB serial adapter; GNU Screen can connect to the serial console
and you will run it at 115200 baud rate. agetty/fgetty in GNU+Linux can give
you a serial console in your OS)
Download and build flashrom, using the instructions
on [the Git page](../../git.md), and download the `bucts` software using the
notes on that very same page.
You can replace Lenovo BIOS with Libreboot, using flashrom running on the host
CPU. However, there are some considerations.
Firstly, make sure that the yellow CMOS battery is installed, and functioning
correctly. You could check the voltage. The battery is a CR2032
coin cell and it *should* be providing a 3V signal. You should check this while
it is connected to the board, because this will give a more accurate reading
(if the battery is weak, it will have severe voltage drop when there is any
load on it, which there will be. This coincell powers the real-time clock and
CMOS memory).
Lenovo BIOS restricts write access, but there is a weakness in it. With a
specially patched flashrom binary, you can easily flash it but the top 64KiB
region of the boot flash, containing your bootblock, cannot be flashed just
yet. However, there is a register called the *Backup Control* or *BUC* register
and in that register is a status bit called *Top Swap* or *TS*.
There are *2* bootblocks possible. The *other* bootblock is below the upper
64KiB one, which can't be flashed, but the lower one can. By using bucts, you
can set the machine to boot using that lower 64KiB bootblock, which is
read-write. You do this by setting the BUC.TS register to 1, using the `bucts`
program referenced below.
Libreboot ROM images already have the upper 64KiB bootblock copied to the lower
one, so you don't have to worry about copying it yourself.
If you build flashrom using the libreboot build system, there will be three
binaries:
* `flashrom`
* `flashrom_i945_sst`
* `flashrom_i945_mx`
It's these last two binaries that you should use. Now compile bucts (just
run `make` in the bucts source directory).
Run the bucts tool:
sudo ./bucts 1
Ensure that your CMOS battery is connected too. Now you must determine whether
you have Macronix or SST. An X60/T60 thinkpad will have either an SST or a
Macronix chip. The Macronix chip will have "MX" written on the chip. You will
use `flashrom_i945_sst` for the SST chip, and `flashrom_i945_mx` for the
Macronix chip.
Now run flashrom (for SST):
sudo ./flashrom_i945_sst -p internal -w coreboot.rom
Or Macronix:
sudo ./flashrom_i945_mx -p internal -w coreboot.rom
NOTE: you *can* just run both. One of them will succeed. It is perfectly
harmless to run both versions of flashrom. In fact, you should do so!
You'll see a lot of errors. This is normal. You should see something like:
Reading old flash chip contents... done.
Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
spi_block_erase_52 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
Transaction error!
spi_block_erase_d8 failed during command execution at address 0x1f0000
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_60 failed during command execution
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_c7 failed during command execution
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
If you see this, rejoice! It means that the flash was successful. Please do not
panic. Shut down now, and wait a few seconds, then turn back on again.
Flash the ROM for a second time. For this second flashing attempt, the upper
64KiB bootblock is now read-write. Use the *unpatched* flashrom binary:
sudo ./flashrom -p internal -w libreboot.rom
To reset bucts, do this:
sudo ./bucts 0
ONLY set bucts back to 0 if you're sure that the upper 64KiB bootblock is
flashed. It is flashed if flashrom said VERIFIED when running the above
command.
If it said VERIFIED, shut down. If it didn't say VERIFIED, make sure bucts is
still set to 1, and consult the libreboot project on IRC for advice, and avoid
shutting down your system until you get help.
If all went well, Libreboot should now be booting and you should be able to
boot into your operating system.
If you messed up, there are external flashing instructions. See main navigation
menu on this page. These "external" instructions teach you how to flash
externally, using special equipment (requires disassembling your laptop and
removing the mainboard).
Install using external flashing equipment
=========================================
In many situations, the host CPU is restricted from rewriting/erasing/dumping
the boot flash. In this situations, you must re-flash the chip (containing the
boot firmware) externally. This is called *external flashing*.
DO NOT buy CH341A! Read the above link, which explains why you shouldn't use it.
CH341A will damage your flash chip, and other components on your mainboard.
How to use external flashing equipment
--------------------------------------
Refer to the following article:\
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
ASUS KFSN4-DRE
--------------
TODO: Document PLCC32 (LPC) flashing. The only Libreboot target that uses this
is ASUS KFSN4-DRE. On that one, internal flashing is possible from the vendor
firmware, with flashrom running on the host CPU (it is recommended to hotswap
a new chip and flash the new chip, after booting into a GNU+Linux system).
TARGET: Apple Macbook2,1, Macbook1,1 and iMac5,2 (i945 platform)
----------------------------------------------------------------
iMac5,2 is essentially the same board as Macbook2,1, and it is compatible with
Libreboot.
Refer to the following article:\
[Macbook2,1 and MacBook1,1 installation guide](../hardware/macbook21.md)
iMac5,2 isn't documented but you can find the flash chip on that board quite
easily. See the generic flashing guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
TARGET: Gigabyte GA-G41M-ES2L mainboard
---------------------------------------
Refer to the following article:\
[Gigabyte GA-G41M-ES2L](ga-g41m-es2l.md)
TARGET: Intel D510MO and D410PT mainboards
------------------------------------------
Refer to the following article:\
[Intel D510MO and D410PT boards](d510mo.md)
TARGET: Intel D945GCLF mainboard
--------------------------------
Refer to the following article:\
[Intel D945GCLF](d945gclf.md)
TARGET: ASUS KGPE-D16 mainboard
-------------------------------
Refer to the following article:\
[ASUS KGPE-D16](kgpe-d16.md)
TARGET: ASUS KCMA-D8 mainboard
------------------------------
Refer to the following article:\
[ASUS KCMA-D8](../hardware/kcma-d8.md)
TARGET: ASUS Chromebook C201 laptop
----------------------------
Refer to the following article:\
[ASUS Chromebook C201](c201.md)
TARGET: Lenovo ThinkPad X60 laptop
----------------------------------
Refer to the following article:\
[ThinkPad X60](x60_unbrick.md)
TARGET: Lenovo ThinkPad X60 Tablet laptop
-----------------------------------------
Refer to the following article:\
[ThinkPad X60 Tablet](x60tablet_unbrick.md)
TARGET: Lenovo ThinkPad T60 laptop
----------------------------------
Refer to the following article:\
[ThinkPad T60](t60_unbrick.md)
TARGET: Lenovo ThinkPad X200 laptop
-----------------------------------
Refer to the following article:\
[ThinkPad X200](x200_external.md)
TARGET: Lenovo ThinkPad X200S or X200 Tablet laptop
---------------------------------------------------
Software-wise, identical to regular X200 but SMD rework skills are required.
You must de-solder the default flash chip, and replace it with another one.
Refer to the following article:\
[25xx NOR flashing guide](spi.md)
That guide, linked above, has instructions for how to deal with these machines.
TARGET: Lenovo ThinkPad T400 laptop
-----------------------------------
Refer to the following article:\
[ThinkPad T400](t400_external.md)
TARGET: Lenovo ThinkPad T400S laptop
------------------------------------
Software-wise, identical to regular T400 but SMD rework skills are required.
You must de-solder the default flash chip, and replace it with another one.
Refer to the following article:\
[25xx NOR flashing guide](spi.md)
TARGET: Lenovo ThinkPad R400 laptop
-----------------------------------
Refer to the following article:\
[ThinkPad R400](r400_external.md)
TARGET: Lenovo ThinkPad T500 or W500 laptop
-------------------------------------------
These two laptops have identical mainboard, except for a few minor changes.
Refer to the following article:\
[ThinkPad T500/W500](t500_external.md)
TARGET: Lenovo ThinkPad R500 laptop
-----------------------------------
Refer to the following laptop:\
[ThinkPad R500](../hardware/r500.md)

29
site/docs/install/kgpe-d16.md Normal file
View File

@ -0,0 +1,29 @@
---
title: KGPE-D16 external flashing instructions
x-toc-enable: true
...
Initial flashing instructions for KGPE-D16.
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.
*Memory initialization is still problematic, for some modules. We
recommend avoiding Kingston modules.*
For more general information about this board, refer to
[../hardware/kgpe-d16.md](../hardware/kgpe-d16.md).
TODO: show photos here, and other info.
External programmer
===================
Refer to [spi.md](spi.md) for a guide on how to re-flash externally.
The flash chip is in a PDIP 8 socket (SPI flash chip) on the
motherboard, which you take out and then re-flash with libreboot, using
the programmer. *DO NOT* remove the chip with your hands. Use a chip
extractor tool.

211
site/docs/install/r400_external.md Normal file
View File

@ -0,0 +1,211 @@
---
title: Flashing the ThinkPad R400
x-toc-enable: true
...
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)
Libreboot T400 {#t400}
==============
You may also be interested in the smaller, more portable [Libreboot
T400](t400_external.md).
Serial port {#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.
A note about CPUs
=================
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:R400) has a list of
CPUs for this system. The Core 2 Duo P8400 and P8600 are believed to
work in libreboot. The Core 2 Duo T9600 was confirmed to work, so the
T9400 probably also works. *The Core 2 Duo T5870/5670 and Celeron M
575/585 are untested!*
Quad-core CPUs
--------------
Incompatible. Do not use.
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 "Dual Graphics" (previously
"switchable graphics"). In the *BIOS setup* program for lenovobios,
you can specify that the system will use one or the other (but not
both).
Libreboot is known to work on systems with only the Intel GPU, using
native graphics initialization. On systems with switchable graphics, the
Intel GPU is used and the ATI GPU is disabled, so native graphics
initialization works all the same.
CPU paste required
==================
See [\#paste](#paste).
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
MAC address {#macaddress}
===========
Refer to [mac\_address.md](../hardware/mac_address.md).
External flashing
=================
Refer to [spi.md](spi.md) as a guide for external re-flashing.
Disassembly
-----------
Remove all screws:\
![](https://av.libreboot.org/r400/0000.jpg)\
Remove the HDD and optical drive:\
![](https://av.libreboot.org/r400/0001.jpg)\
Remove the hinge screws:\
![](https://av.libreboot.org/r400/0002.jpg) ![](https://av.libreboot.org/r400/0003.jpg)
Remove the palm rest and keyboard:\
![](https://av.libreboot.org/r400/0004.jpg) ![](https://av.libreboot.org/r400/0005.jpg)
Remove these screws, and then remove the bezel:\
![](https://av.libreboot.org/r400/0006.jpg) ![](https://av.libreboot.org/r400/0007.jpg)
Remove the speaker screws, but don't remove the speakers yet (just set
them loose):\
![](https://av.libreboot.org/r400/0008.jpg) ![](https://av.libreboot.org/r400/0009.jpg)
![](https://av.libreboot.org/r400/0010.jpg)
Remove these screws, and then remove the metal plate:\
![](https://av.libreboot.org/r400/0011.jpg) ![](https://av.libreboot.org/r400/0012.jpg)
![](https://av.libreboot.org/r400/0013.jpg)
Remove the antennas from the wifi card, and then start unrouting them:\
![](https://av.libreboot.org/r400/0014.jpg) ![](https://av.libreboot.org/r400/0015.jpg)
![](https://av.libreboot.org/r400/0016.jpg) ![](https://av.libreboot.org/r400/0017.jpg)
![](https://av.libreboot.org/r400/0018.jpg) ![](https://av.libreboot.org/r400/0019.jpg)
Disconnect the LCD cable from the motherboard:\
![](https://av.libreboot.org/r400/0020.jpg) ![](https://av.libreboot.org/r400/0021.jpg)
![](https://av.libreboot.org/r400/0022.jpg) ![](https://av.libreboot.org/r400/0023.jpg)
Remove the hinge screws, and then remove the LCD panel:\
![](https://av.libreboot.org/r400/0024.jpg) ![](https://av.libreboot.org/r400/0025.jpg)
![](https://av.libreboot.org/r400/0026.jpg) ![](https://av.libreboot.org/r400/0027.jpg)
Remove this:\
![](https://av.libreboot.org/r400/0028.jpg) ![](https://av.libreboot.org/r400/0029.jpg)
Remove this long cable (there are 3 connections):\
![](https://av.libreboot.org/r400/0030.jpg) ![](https://av.libreboot.org/r400/0031.jpg)
![](https://av.libreboot.org/r400/0032.jpg) ![](https://av.libreboot.org/r400/0033.jpg)
Disconnect the speaker cable, and remove the speakers:\
![](https://av.libreboot.org/r400/0034.jpg)
Remove the heatsink screws, remove the fan and then remove the
heatsink/fan:\
![](https://av.libreboot.org/r400/0035.jpg) ![](https://av.libreboot.org/r400/0036.jpg)
![](https://av.libreboot.org/r400/0037.jpg) ![](https://av.libreboot.org/r400/0038.jpg)
Remove the NVRAM battery:\
![](https://av.libreboot.org/r400/0039.jpg) ![](https://av.libreboot.org/r400/0040.jpg)
Remove this screw:\
![](https://av.libreboot.org/r400/0041.jpg) ![](https://av.libreboot.org/r400/0042.jpg)
Disconnect the AC jack:\
![](https://av.libreboot.org/r400/0043.jpg) ![](https://av.libreboot.org/r400/0044.jpg)
Remove this screw and then remove what is under it:\
![](https://av.libreboot.org/r400/0045.jpg)
Remove this:\
![](https://av.libreboot.org/r400/0046.jpg)
Lift the motherboard (which is still inside the cage) from the side on
the right, removing it completely:\
![](https://av.libreboot.org/r400/0047.jpg) ![](https://av.libreboot.org/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: ![](https://av.libreboot.org/r400/0049.jpg)
![](https://av.libreboot.org/r400/0050.jpg)
Remove the motherboard from the cage, and the SPI flash chip will be
next to the memory slots:\
![](https://av.libreboot.org/r400/0051.jpg) ![](https://av.libreboot.org/r400/0052.jpg)
Now, you should be ready to install libreboot.
Read [this article](spi.md) to learn how you may flash the chip, which is near
to the RAM.
Thermal paste (IMPORTANT)
=========================
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.
![](https://av.libreboot.org/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.
Memory
======
In DDR3 machines with Cantiga (GM45/GS45/PM45), northbridge requires sticks
that will work as PC3-8500 (faster PC3/PC3L sticks can work as PC3-8500).
Non-matching pairs may not work. Single module (meaning, one of the slots
will be empty) will currently only work in slot 0.
NOTE: according to users reports, non matching pairs (e.g. 1+2 GiB) might
work in some cases.
Make sure that the RAM you buy is the 2Rx8 configuration when buying 4GiB sticks
(In other words: maximum of 2GiB per rank, 2 ranks per card).
[This page](http://www.forum.thinkpads.com/viewtopic.php?p=760721) might
be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://av.libreboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://av.libreboot.org/t400/boot0.jpg) ![](https://av.libreboot.org/t400/boot1.jpg)
Now [install GNU+Linux](../gnulinux/).

802
site/docs/install/spi.md Normal file
View File

@ -0,0 +1,802 @@
---
title: Read/write 25XX NOR flash via SPI protocol
x-toc-enable: true
...
This guide will teach you how to use various tools for externally reprogramming
a 25xx NOR flash via SPI protocol. This is the most common type of flash IC for
computers that coreboot runs on. Almost every system currently supported by
Libreboot uses this type of boot flash; the only exception is ASUS KFSN4-DRE,
which uses LPC flash in a PLCC32 socket, which you can simply hot-swap after
booting the vendor firmware, and then flash internally. Simple!
We will be using
the [flashrom](https://flashrom.org/Flashrom) software which is written to
dump, erase and rewrite these flash chips.
Libreboot currently documents how to use these SPI programmers:
* Raspberry Pi (RPi)
* BeagleBone Black (BBB)
Many other SPI programmers exist. More of them will be documented on this page,
at a date in the future.
TODO: document the following SPI flashers:
* A64-OLinuXino
* STM32 Blue Pill
Most systems in Libreboot have to be re-flashed externally, using instructions
on this and similar guides, the first time you flash. However, on all currently
supported systems, it's possible that you can re-flash *internally* when
Libreboot is running.
*Internal* flashing means that the host CPU on your system can re-program the
SPI flash, using an on-board SPI programmer (which all boards have). You do this
from GNU+Linux, with flashrom.
*This* guide that you're reading now is for using an *external* programmer. It
is called *external* because it's not the *internal* one on your mainboard.
Do not use CH341A!
==================
NOR flashes on Libreboot systems run on 3.3V DC, and this includes data lines.
CH341A has 5V logic levels on data lines, which will damage your SPI flash and
also the southbridge that it's connected to, plus anything else that it's
connected to.
These ch341a programmers are unfortunately very popular. DO NOT use it unless
you have fixed the issue. You CAN fix it so that the data lines are 3.3v, if
you follow the notes here:
<https://www.eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/>
In practise, most people will not fix their ch341a and instead just risk it,
so no documentation will be provided for ch341a on this website. It is best
to discourage use of that device.
In case it's not clear:
Please do not buy the ch341a! It is incorrectly engineered for the purpose of
ROM flashing on systems with 3.3v SPI (which is most coreboot systems). DO NOT
USE IT! This issue still isn't fixed by the manufacturer, and it doesn't look
like they will ever fix it.
If you see someone talking about CH341A, please direct them to this page and
tell them why the CH341A is bad.
Identify which flash type you have
==================================
In all of them, a dot or marking shows pin 1 (in the case of WSON8, pad 1).
Use the following photos and then look at your board. When you've figured out
what type of chip you have, use that knowledge and the rest of this guide, to
accomplish your goal, which is to read from and/or write to the boot flash.
SOIC8
-----
![](https://av.libreboot.org/chip/soic8.jpg)
SOIC16
------
![](https://av.libreboot.org/chip/soic16.jpg)
SOIC8 and SOIC16 are the most common types, but there are others:
WSON8
-----
It will be like this on an X200S or X200 Tablet:\
![](https://av.libreboot.org/x200t_flash/X200T-flashchip-location.jpg)
On T400S, it is in this location near the RAM:\
![](https://av.libreboot.org/t400s/soic8.jpg)\
NOTE: in this photo, the chip has been replaced with SOIC8
DIP8
----
![](https://av.libreboot.org/dip8/dip8.jpg)
Software configuration
======================
BeagleBone Black (BBB)
----------------------
SSH into your BeagleBone Black. It is assumed that you are running Debian 9 on
your BBB. You will run `flashrom` from your BBB.
NOTE: This section is out of date, because it is written for Debian 9 (running
on the BBB)
Run the following commands as root to enable spidev:
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
Verify that the spidev devices now exist:
ls /dev/spidev*
Output:
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1
Now the BBB is ready to be used for flashing. The following systemd service
file can optionally be enabled to make this persistent across reboots.
```
[Unit]
Description=Enable SPI function on pins
[Service]
Type=oneshot
ExecStart=config-pin P9.17 spi_cs
ExecStart=config-pin P9.18 spi
ExecStart=config-pin P9.21 spi
ExecStart=config-pin P9.22 spi_sclk
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
```
Now test flashrom:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
It is important to use `spispeed=512` or a lower number such as 256 or 128,
because otherwise the BBB will be quite unstable.
Example output:
Calibrating delay loop... OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
This means that it's working (the clip isn't connected to any flash
chip, so the error is fine).
Caution about BBB
-----------------
BeagleBone Black is not recommended, because it's very slow and unstable for
SPI flashing, and nowadays much better options exist. We used to mainly
recommend the BBB, because of the fact that it can be used with entirely Free
Software on it, but nowadays there are superior options such as:
* [A64-OlinuXino](https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware)
* STM32 Blue Pill
* Teensy
In particular, the A64-OlinuXino works as reliably as the Raspberry Pi, and it
is a full SBC (single-board computer), but unlike the Raspberry Pi, the
A64-OlinuXino has full schematics available and it can be used with entirely
Free Software on it. Unlike the BeagleBone Black, the A64-OlinuXino is highly
reliable and *fast* when you use it for SPI flashing.
These other programmers will be documented at a future date.
Rasberry Pi (RPi)
-----------------
SSH into your Raspberry Pi. You will run `flashrom` from your Raspberry Pi.
You must configure `spidev` on your Raspberry Pi. This is a special driver in
the Linux kernel; technically, the driver name is `spi-bcm2835`.
This page has info:\
<https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md>
In your Raspberry Pi, which we assume you're running the latest Raspbian version
on, do this:
sudo raspi-config
Under the Interface section, you can enable SPI.
The device for communicating via SPI as at `/dev/spidev0.0`
Install flashrom
----------------
If you're using a BBB or RPi, you will do this while SSH'd into those.
Flashrom is the software that you will use, for dumping, erasing and rewriting
the contents of your NOR flash.
In the Libreboot build system, from the Git repository, you can download and
install flashrom. Do this after downloading the
[lbmk Git repository](https://notabug.org/libreboot/lbmk):
cd lbmk
sudo ./build dependencies ubuntu2004
./download flashrom
./build module flashrom
If the `ubuntu2004` script complains about missing dependencies, just modify
the script and remove those dependencies. The script is located
at `resources/scripts/build/dependencies/ubuntu2004` and it is written for
Ubuntu 20.04, but it should work fine in other GNU+Linux distributions that use
the `apt-get` package manager.
A `flashrom/` directory will be present, with a `flashrom` executable inside
of it. If you got an error about missing package when running the dependencies
command above, tweak `resources/scripts/build/dependencies/ubuntu2004`. That
script downloads and installs build dependencies in apt-get and it is intended
for use on x86-64 systems running Ubuntu 20.04, but it should work in Raspbian
on the Raspberry Pi.
Alternatively, you may download flashrom directly from upstream
at <https://flashrom.org/Flashrom>
If you're flashing a Macronix flashchip on a ThinkPad X200, you will want to
use a special patched version of flashrom, which you can download here:
<https://vimuser.org/hackrom.tar.xz> - patched source code is available, and a
binary is also available that you can simply run. Pass the `--workaround-mx`
argument in flashrom. This mitigates stability issues.
If you downloaded the flashrom source code directly, you can go into the
directory and simply type `make`. In the Libreboot build system, build
dependencies are documented in script located
at `resources/scripts/build/dependencies/` which you can install
using the `apt-get` software.
How to use flashrom
===================
Read past these sections, further down this page, to learn about specific chip
types and how to wire them.
Reading
-------
Before flashing a new ROM image, it is highly advisable that you dump the
current chip contents to a file.
Run this command to see if 25xx flash is detected, with your RPi properly
wired.
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768
For BBB, you must use a lower speed and a different device path:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
On BBB, never use a speed higher than `spispeed=512`. In some cases, you may
even need to go as low as `spispeed=128`. The BBB is highly unstable and
unreliable for SPI flashing. When you're reading, take multiple dumps and
verify that the checksums match, before you flash. You may have to flash your
chip several times!
NOTE: On some systems, higher speeds will be unstable. On those systems, try
lower speed like `spispeed=4096` or even `spispeed=2048` which should, in most
cases, work just fine but it will obviously be slower. The `spispeed=32768`
setting works just fine on most setups if you use short wires, within 10cm.
If flash chip is detected you may try reading (dumping) the flash contents now,
or you can try flashing it with a new ROM.
Dump it like so (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r dump.bin
For BBB, do this:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r dump.bin
It is advisable to take a *2nd* dump, e.g. `dump2.bin`, and then check sha1sum:
sha1sum dump*.bin
If the checksums match, it indicates that you have a good dump. If they do not,
check your wiring. Wires should be within 10cm length for best stability, and
they should all be the same length (3.3V VCC and GND wires can be longer).
This advice is *especially* applicable to the BBB, which is highly unreliable.
Writing
-------
Next, run this command (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/libreboot.rom
If using BBB:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/libreboot.rom
If using BBB, you may have to use a lower speed than 512. You may also have to
re-flash several times before it works fully.
Again, use a lower `spispeed` value if you need to, for stability.
Once that command outputs the following, the flash has completed
successfully. If not, just flash again.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
If it says "VERIFIED" or says that the chip contents are identical to the
requested image, then the chip is properly flashed.
Hardware configuration
======================
Refer to the above guidance about software configuration. The following advice
will teach you how to wire each type of flash chip.
WARNINGS
--------
Do not connect a 3.3V DC power source until your chip is otherwise properly
wired. For instance, do not connect a test clip that has 3.3V DC attached.
Do not *disconnect* your chip from the flasher until you've disconnected or
turned off the 3.3V DC power source.
BE CAREFUL that you are indeed supplying 3.3V DC to the chip. All SPI flashes
on all currently supported Libreboot hardware run on 3.3V DC and logic at that
level too.
It is important to CHECK that you are running on the current voltage, when you
do anything with these chips. Lower than 3.3V won't damage anything, but higher
will fry your chip (on most chips, the tolerated voltage range is between 2.7V
and 3.6V, but 3.3V is the most ideal level).
DO NOT connect more than 1 DC power source to your flash chip either!
Mixing voltages like that can easily cause damage to your equipment, and to
your chip/mainboard.
MISO/MOSI/CS/CLK lines
----------------------
You may want to add 47ohm series resistors on these lines, when flashing the
chips. Only do it on those lines (NOT the 3.3V or GND lines). This provides
some protection from over-current. On Intel platforms, the SPI flash is usually
connected via such resistors, directly to the Southbridge chipset.
ISP programming and VCC diode
-----------------------------
ISP means in-system programming. It's when you flash a chip that is already
mounted to the mainboard of your computer that you wish to install Libreboot
on.
It may be beneficial to modify the mainboard so that the SPI flash is powered
(on the VCC pin) through a diode, but please note: a diode will cause a voltage
drop. The tolerated range for VCC on these chips is 2.7V to 3.6V DC. If you do
this, please also ensure that the WP and HOLD pins are still held to a high
logic state; each via their own resistor (1K to 10K ohms) connected to the
*same* 3.3V DC source going through the diode.
The reason is simple: on most systems, the flash shares a common 3.3V DC rail
with many other components on the board, which draw a lot of current. Further,
if you accidentally provide too much voltage or cause an overcurrent, you could
fry those other components but if there is diode protection, you'll only fry
the boot flash (and it is very easy to replace, if you have good soldering
skills).
When you've placed the diode, ensure that VCC on the chip is isolated from all
other components on that board, which share the same 3.3V DC rail. Further,
ensure that the pull-up resistors for WP/HOLD are *only* connected to the side
of the diode that has continuity with the VCC pin (this is important because if
they're not, they won't be held high while doing ISP flashing, even if they're
still held high when the mainboard is fully powered on).
Furthermore: ensure that the SPI flash is operating at 2.7 to 3.6V when fully
powered on, after installing the diode.
If it's a desktop/workstation/server board (not a laptop), you could de-solder
the SOIC8/WSON8 if it uses that, and replace with an IC socket (for SOIC8,
WSON8 or DIP8, whatever you want), because then you could easily just insert
the flash into a breadboard when flashing.
TODO: Make a page on libreboot.org, showing how to do this on all mainboards
supported by Libreboot.
GPIO pins on BeagleBone Black (BBB)
-----------------------------------
Use this image for reference when connecting the pomona to the BBB:
<https://beagleboard.org/Support/bone101#headers> (D0 = MISO or connects
to MISO).
On that page, look at the *P9 header*. It is what you will use to wire up your
chip for flashing.
GPIO pins on Raspberry Pi (RPi)
-------------------------------
Diagram of the 26 GPIO Pins of the Raspberry Pi Model B (for the Model
B+ with 40 pins, start counting from the right and leave 14 pins):
![](https://av.libreboot.org/rpi/0012.png) ![](https://av.libreboot.org/rpi/0013.png)
Use this as a reference for the other sections in this page, seen below:
SOIC8/DIP8/WSON8 wiring diagram
-------------------------------
Refer to this diagram:
Pin \# 25xx signal RPi(GPIO) BBB(P9 header)
------ ----------- ---------- --------------
1 CS 24 17
2 MISO 21 21
3 *not used* *not used* *not used*
4 GND 25 1
5 MOSI 19 18
6 CLK 23 22
7 *not used* *not used* *not used*
8 3.3V 1 3
On your SOIC8, there will be a dot in one of the corners. The dot is pin 1.
NOTE: pins 3 and 7 are WP/HOLD pins. If flashing a chip on a breadboard, please
use pull-up resistors on those (see notes below), and decoupling capacitor on
pin 8 (VCC).
NOTE: On X60/T60 thinkpads, don't connect pin 8. Instead, plug in your the PSU
to the charging port on your mainboard, but do not power on the mainboard. This
will provide a stable 3.3V voltage, with adequate current levels. On those
laptops, this is necessary because the flash shares a common 3.3V DC rail with
many other ICs that all draw quite a lot of current.
SOIC16 wiring diagram (Raspberry Pi)
------------------------------------
RPi GPIO header:\
![](https://av.libreboot.org/rpi/0009.png)
![](https://av.libreboot.org/rpi/0010.png)
BBB P9 header:\
<https://beagleboard.org/static/images/cape-headers.png>
Refer to this diagram:
Pin \# 25xx signal RPi(GPIO) BBB(P9 header)
-------- -------------- ----------- --------------
1 *not used* *not used* *not used*
2 3.3V 1 3
3 *not used* *not used* *not used*
4 *not used* *not used* *not used*
5 *not used* *not used* *not used*
6 *not used* *not used* *not used*
7 CS\# 24 17
8 MISO 21 21
9 *not used* *not used* *not used*
10 GND 25 1
11 *not used* *not used* *not used*
12 *not used* *not used* *not used*
13 *not used* *not used* *not used*
14 *not used* *not used* *not used*
15 MOSI 19 18
16 SCLK 23 22
Refer to the RPi GPIO guide above, on this page.
On your SOIC16, there will be a dot in one of the corners. The dot is pin 1.
NOTE: pins 1 and 9 are WP/HOLD pins. If flashing a chip on a breadboard, please
use pull-up resistors on those (see notes below), and decoupling capacitor on
pin 2 (VCC).
Pull-up resistors and decoupling capacitors
-------------------------------------------
**Do this for chips mounted to a breadboard. Ignore this section if you're
flashing a chip that is already soldered to a mainboard.**
This section is only relevant if you're flashing a new chip that is not yet
mounted to a mainboard. You need pull-up resistors on the WP and HOLD pins,
and decoupling capacitors on the VCC pin. If the chip is already mounted to a
board, whether soldered or in a socket, these capacitors and resistors will
probably already exist on the board and you can just flash it without pulling
WP/HOLD high, and without capacitors(just connect your external 3.3V DC power
source).
The best way is as follows:
* Insert the DIP8 IC into a breadboard (2.54mm holes), if it's DIP8
* Insert WSON8 into a WSON8 socket and put on a breadboard, if WSON8
* Insert SOIC8 into a SOIC8 socket and put on a broadboard, if SOIN8
* Wire an SPI flasher, using 2.54mm dupont leads, to the breadboard, using
the correct wiring (see link to SPI flashing guides below)
SOIC8/WSON8/DIP8: pin 3 and 7 must be held to a high logic state, which means
that each pin
has its own pull-up resistor to VCC (from the 3.3v voltage plane that pin 8
connects to); anything from 1Kohm to 10Kohm will do. When you're flashing a chip
that's already on a laptop/desktop/server mainboard, pin 3 and 7 are likely
already held high, so you don't need to bother.
SOIC8/WSON8/DIP8: pin 8, which is 3.3v VCC, will already have decoupling capacitors on it
if the chip is on a mainboard, but lone chip flashing means that these capacitors
do not exist. A capacitor passes AC but blocks DC. Due to electromagnetic
indunctance, and RF noise from high-speed switching ICs, a DC voltage line isn't
actually straight (when viewed on an oscilloscope), but actually has low voltage
AC mixed in; on a particularly noisy line under high load, noise of around 300mV
or more is common. To smooth out that noise, you wire capacitors from the DC
line to ground, with the side of the capacitor on VCC as close to the IC's VCC
pin as possible. We recommend that you use ceramic capacitors for this purpose.
The recommended capacitors for this are: 100nF and 4.7uF ceramic capacitors.
Electrolytic capacitors are inferior for this, because they have higher ESR
(ceramic capacitors have super low ESR, which is very good for decoupling).
The result of using a decoupling capacitor is that some of the noise on the DC
line is filtered to ground, making the DC signal much cleaner/straighter (when
seen on an oscilloscope).
SOIC16: same as above, but use a SOIC16 socked on a breadboard. On SOIC16,
WP/HOLD are not pin 3/7 like above, but instead pins 1 and 9, so wire your
pull-up resistors on those. 3.3v VCC on SOIC16 is pin 2, so wire your
decoupling capacitors up on that.
SOIC8/WSON8/DIP8/SOIC16 not mounted to a mainboard
--------------------------------------------------
If your system has lower capacity SPI flash, you can upgrade. On *most* systems,
SPI flash is memory mapped and the maximum (in practise) that you can use is a
16MiB chip. For example, KGPE-D16 and KCMA-D8 mainboards in Libreboot have
2MiB flash by default, but you can easily upgrade these. Another example is the
ThinkPad X200S, X200 Tablet and T400S, all of which have WSON8 where the best
course of action is to replace it with a SOIC8 flash chip.
In all such cases, flashing a new chip should be done using a breadboard, not
a test clip. You will use 2.54mm dupont leads to connect your Raspberry Pi.
For data lines, make sure that all wires are the same length, and about 10cm
in length (don't use longer lengths than this).
Some advice:
* DIP8: Strong choice is Winbond W25Q128FVIQ. It is a direct drop-in replacement
* SOIC8 is possible: Winbond W25Q128FVSIG is a strong choice.
* DIP8 using adapter and SOIC8 is also possible. Use a 208-mil 1.27mm SOP8/SOIC8
to DIP8 adapter PCB with a
2.54mm 4-pin header on each side (square pins), then you can slot that in as
though it were a normal P-DIP 8 IC. This page shows a perfect example:
<https://coolcomponents.co.uk/products/soic-to-dip-adapter-8-pin>
* The above SOP8/DIP8 adapter is actually what we recommend, if you're going
that route. It's made by Sparkfun and widely available; you don't have to buy
from that particular website. The part number is: BOB-13655
* If you use a SOP/DIP adapter with a SOIC8 IC, you'll have to solder it
obviously. K tip is a nice choice for soldering ICs like these. Use good
flux and 60/40 leaded solder (or 63/37), none of that Rohs lead-free crap.
If you go for a SOIC8, mounted it to the SOP to DIP adapter (208mil 1.27mm one)
and solder 2.54mm headers to it. You could put the 2.54mm pins in a breadboard,
then solder the chip to the adapter PCB and mount that to the pins on the
breadboard, to keep it aligned, and solder that. Whith the PCB on the pins, and
the pins in the breadboard, push the pins inwards a little bit.
This is for a new SOIC8 chip, but you can get sockets similar to the one in the
video, but for WSON8. Sometimes they are called DFN8 or QFN8 sockets. Get one
that is 1.27mm pitch.
If you're flashing/dumping a lone WSON8, get a WSON8/QFN8/DFN8 socket (1.27mm
pitch) and mount it to a breadboard for flashing. If your mainboard's landing
pads for the flash IC can take a SOIC8, we recommend that you use a SOIC8
instead because a test clip is possible later on when you wish to re-flash it,
however you may be dealing with a board where replacing existing WSON8 with
SOIC8 is desirable; in that case, you might still want to dump the contents of
the original WSON8.
Here is a SOIC8 in a socket, mounted to a breadboard, for flashing:\
![](https://av.libreboot.org/rpi/soic8_socket.jpg)
Here is a photo of a DIP8 IC:\
![](https://av.libreboot.org/dip8/dip8.jpg)
Here is a photo of a SOIC8 in 1.27mm 208mil SOP to DIP adapter:\
![](https://av.libreboot.org/dip8/sop8todip8.jpg)
Here is a video of that SOIC8 (in socket) being flashed:\
<https://yewtu.be/watch?v=tguch_iPBZQ>\
NOTE: DIP8 and WSON8-in-socket, and SOIC16-in-socket, are basically the same,
just adapt accordingly.
If you're replacing a DIP8 but using SOIC8 on an adapter, solder it to the
adapter first, then insert 2.54mm headers (square pins) into a breadboard to
keep them aligned. Put the SOIC8 on the PCB, onto the pins, and push the pins
inwards a little bit, and solder that. Alternatively to the breadboard, you
can just put the 2.54mm pins directly in the DIP8 socket and mount the SOIC8 +
adapter onto that, and solder that. Use quality rosin flux (not acid based)
and good 60/40 or 63/37 leaded solder (don't use lead-free):
![](https://av.libreboot.org/dip8/adapter_breadboard.jpg)
![](https://av.libreboot.org/dip8/adapter.jpg)
![](https://av.libreboot.org/dip8/sop8todip8.jpg)
SOIC8/SOIC16 soldered to a mainboard
------------------------------------
This is an example of *in-system programming* or *ISP* for short.
SOIC8:\
Pomona 5252 is a SOIC8 test clip. There are others available, but this is the
best one. Use that. Use the SOIC8 diagram (see above) to wire up your Raspberry
Pi.
Your mainboard likely already pulls WP/HOLD (pins 3 and 7) high, so don't
connect these. 3.3v VCC on SOIC8's pin 8 probably already has decoupling
capacitors on the mainboard, so just hook that up without using a capacitor.
SOIC16:\
Pomona 5250 is a SOIC16 test clip. There are others available, but this is the
best one. Use that. Use the SOIC16 diagram (see above) to wire up your Raspberry
Pi. WP/HOLD pins are pins 1 and 9, and likely already held high, so no pull-up
resistors needed. You do not need a decoupling capacitor for pin 2 (VCC) either
because the mainboard will already have one.
Here is an example of a test clip connected for SOIC16:\
![](https://av.libreboot.org/rpi/0002.jpg)
And here is an example photo for SOIC8:\
![](https://av.libreboot.org/x60/th_bbb_flashing.jpg)
DIP8 soldered to the mainboard
------------------------------
It is extremely cursed for DIP8 to be soldered directly to the mainboard. It is
usually mounted to a socket.
The pins are large enough that you can just use test hooks to wire up your chip
for flashing. You might want to de-solder the chip, using a solder vacuum
(extractor) tool, and then you can install a socket in its place. You can then
insert the DIP8 IC into the socket.
In the Libreboot project, we have never heard of a board where the DIP8 is
directly soldered. It is almost always mounted in a socket.
Your DIP8 IC has the same pinout as a SOIC8 IC.
Replace WSON8 IC with SOIC8
---------------------------
You *can* connect a SOIC8 test clip, but you will struggle to get good
connections and it will be extremely unreliable. DO NOT solder to the pads of
the WSON8 directly; some people do this, but you shouldn't do it, because you
can easily damage the pads that way.
WSON8 has the same pinout as SOIC8, but it's a ball mounted QFN (quad flat
pack, no leads). There are no clips for it. Sometimes referred to as QFN8
On all currently supported Libreboot hardware, boards that have WSON8 can also
have a SOIC8 because the pads are long enough to accomodate either type of
chip.
A good choice of soldering iron would be a T12-D08 or T12-K tip, on a T12
soldering station. KSGER makes nice soldering stations:\
<https://yewtu.be/watch?v=w0nZCK7B-0U>
The case on that KSGER station is not grounded by default, so you should
modify it to ground the case, in case of an electrical fault. This is for your
safety. This video shows how to do it:\
<https://yewtu.be/watch?v=-6IZ_sBgw8I>
Use quality 60/40 or 63/37 lead+tin solder. Do not use lead-free! Lead-free is
not suitable for hobbyist use such as this. Use quality *rosin* flux. Fluxes
with an acid base should never be used. Amtech and MG Chemicals make good flux
pastes. Use it in a dispenser tube. Some of these fluxes will contain adapic
acid which has a low pH level, and it is simply used as a mild activator. So
long as you clean the flux afterwards, you should be fine.
Make sure to have a copper wire brush and a wet sponge handy. You wipe the iron
on the wire brush and tap it on the wet sponge(to remove oxides) to keep it
clean. Always clean your tip constantly. Also, after cleaning it, always re-tin
the tip with fresh solder, to prevent the tip from oxidizing!
Make sure to buy 99.9% isopropyl alcohol. Don't buy weaker solutions because
they contain water, and don't use other chemicals because most other chemicals
are corrosive. You use the isopropyl to clean the area you're soldering, before
soldering it, and then soak up the wet alcohol with a cloth. You will also use
it to clean off any flux that you used.
Use of flux is very important, to get a good solder joint, because it removes
oxides and prevents further oxidation during soldering, ensuring that the solder
flows properly, otherwise the solder will ball up and you won't get a good
joint.
In case you're not comfortable with soldering, we have some excellent videos
linked on the [FAQ page](../../faq.md) which you can watch.
Here is a video example for ThinkPad X200 Tablet:\
<https://yewtu.be/watch?v=oUYHzOQXx80>\
(X200S and T400S also require this)
Alternatively, here are photos:
WSON8 IC:\
![](https://av.libreboot.org/rpi/wson8/0001.jpg)
Surround a large area around the chip with layers of kapton tape, and then
aluminium foil. This will act as a heat shield, to reduce the risk of re-flowing
other solder joints (which can make them turn into cold joints, and you risk
knocking them off of the board):\
![](https://av.libreboot.org/rpi/wson8/0002.jpg)\
Notice that the kapton+foil does not cover the chip itself, or the solder pads.
It's important that these are exposed to the heat.
Use a hot air rework station, set to about 330-340C. The reason for the higher
temperature is because air doesn't conduct heat as efficiently as an iron, so
you must use a higher temperature. You should put lots of rosin flux above the
IC. Do not hold the nozel too close to the board. The diameter of the nozel
should be slightly higher than the length of the chip. Apply even heat, at high
air flow.
While blasting the chip with hot air, hold the chip with tweezers but do not
use any real force. Do not try to forcefully pry off the chip. Simply hold the
chip with your tweezers, gently nudging it until it feels like the chip can
move freely. While in this state, the solder is fully melted and the chip can
be lifted off with ease.
If you're doing it correctly, the chip will come off within 1 minute, like so:\
![](https://av.libreboot.org/rpi/wson8/0003.jpg)
Add fresh solder to the pads, including the thermal pad:\
![](https://av.libreboot.org/rpi/wson8/0004.jpg)
Now wick it out using a copper braid, dunked in rosin flux:\
![](https://av.libreboot.org/rpi/wson8/0005.jpg)
Ensure that all of the solder is removed:\
![](https://av.libreboot.org/rpi/wson8/0006.jpg)\
You will notice that one of the pads doesn't have all of the solder removed.
The pad on the top-left in this photo. This is intentional, to show you a
comparison for reference. The other pads are free of solder.
You *can* simply solder the chip unflashed, and flash it using a test clip.
Alternatively, you can put the SOIC8 in a socket on a breadboard, and flash it
before soldering it. If you wish to dump the contents of the WSON8, you can
put the removed WSON8 in a socket on a breadboard and dump it using your
SPI flasher.
Align the new SOIC8, and tack it in the corner pins. Then solder it fully. Use
lots of flux!\
![](https://av.libreboot.org/rpi/wson8/0007.jpg)\
A T12-D08 tip is being used in this photo, but a mini chisel, mini hoof or
knife (e.g. T12-K) tip would be ideal.
Ensure that all the joints are perfect. A good solder joint is shiny, and with
concave fillets where the solder has flowed. Observe:\
![](https://av.libreboot.org/rpi/wson8/0008.jpg)
After you're done, use a soft bristle brush and 99.9% isopropyl alcohol to
break up the remaining flux, then soak up the flux using a cloth, while the
alcohol is still wet. 99.9% isopropyl is the best liquid to use, because it
evaporates quickly and it does not leave a corrosive residue.
-------------------------------------------------------------------------------
LICENSING
=========
This page is released under different copyright terms than most other pages
on this website.
This page and the photos on it are available under
[CC BY SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/legalcode.txt)
Check the Git repository for history of who owns what part of the document.
Photos showing a BeagleBone Black are under the normal GNU Free Documentation
license like other pages and images on this website, or you can use them under
the CC-BY-SA 4.0 license if you wish (I, Leah Rowe, own all BBB photos shown
on this page, except for the one on the beaglebone website, and that one is
merely linked here, instead of being hosted on the av.libreboot.org server).
This version of the page is hosted in the `lbwww` git repository, with images
for it hosted in the `lbwww-img` repository. Images and this page were both
forked from the *old* Libreboot git repository, which was available here:
<https://notabug.org/libreboot/libreboot/> (you can still download it but this
repository is no longer worked on. You can find both the website and images
under the `www/` and/or `docs/` directory, in that repository)

224
site/docs/install/t400_external.md Normal file
View File

@ -0,0 +1,224 @@
---
title: Flashing the ThinkPad T400 externally
x-toc-enable: true
...
Initial flashing instructions for 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.
An
["HMM"](https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/43y6629_05.pdf#page=386)
(Hardware Maintenance Manual) detailing the process of [dis]assembly
is available for this model. Be careful when reassembling the laptop as
the screws on page 114 (with title "1130 Keyboard bezel") are swapped
and if you follow the HMM you will punch a hole through the bezel in the
upper right corner.
Serial port {#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.
A note about CPUs
=================
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T400) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work in libreboot.
T9600, T9500, T9550 and T9900 are all compatible, as reported by users.
Quad-core CPUs
--------------
Very likely to be compatible, but requires hardware modification.
Based on info from German forum post about installing Core Quad CPU on T500 found in coreboot mailing list. Currently work in progress and no guide available.
- [Coreboot mailing list post](https://mail.coreboot.org/pipermail/coreboot/2016-November/082463.html)
- [German forum post about install Core Quad on T500](https://thinkpad-forum.de/threads/199129)
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 *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.
CPU paste required
==================
See [\#paste](#paste).
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
MAC address {#macaddress}
===========
Refer to [mac\_address.md](../hardware/mac_address.md).
How to flash externally
=========================
Refer to [spi.md](spi.md) as a guide for external re-flashing.
The procedure
-------------
Remove *all* screws, placing them in the order that you removed them:\
![](https://av.libreboot.org/t400/0001.jpg) ![](https://av.libreboot.org/t400/0002.jpg)
Remove those three screws then remove the rear bezel:\
![](https://av.libreboot.org/t400/0003.jpg) ![](https://av.libreboot.org/t400/0004.jpg)
![](https://av.libreboot.org/t400/0005.jpg) ![](https://av.libreboot.org/t400/0006.jpg)
Remove the speakers:\
![](https://av.libreboot.org/t400/0007.jpg) ![](https://av.libreboot.org/t400/0008.jpg)
![](https://av.libreboot.org/t400/0009.jpg) ![](https://av.libreboot.org/t400/0010.jpg)
![](https://av.libreboot.org/t400/0011.jpg)
Remove the wifi:\
![](https://av.libreboot.org/t400/0012.jpg) ![](https://av.libreboot.org/t400/0013.jpg)
Remove this cable:\
![](https://av.libreboot.org/t400/0014.jpg) ![](https://av.libreboot.org/t400/0015.jpg)
![](https://av.libreboot.org/t400/0016.jpg) ![](https://av.libreboot.org/t400/0017.jpg)
![](https://av.libreboot.org/t400/0018.jpg)
Unroute those antenna wires:\
![](https://av.libreboot.org/t400/0019.jpg) ![](https://av.libreboot.org/t400/0020.jpg)
![](https://av.libreboot.org/t400/0021.jpg) ![](https://av.libreboot.org/t400/0022.jpg)
![](https://av.libreboot.org/t400/0023.jpg)
Remove the LCD assembly:\
![](https://av.libreboot.org/t400/0024.jpg) ![](https://av.libreboot.org/t400/0025.jpg)
![](https://av.libreboot.org/t400/0026.jpg) ![](https://av.libreboot.org/t400/0027.jpg)
![](https://av.libreboot.org/t400/0028.jpg) ![](https://av.libreboot.org/t400/0029.jpg)
![](https://av.libreboot.org/t400/0030.jpg) ![](https://av.libreboot.org/t400/0031.jpg)
Disconnect the NVRAM battery:\
![](https://av.libreboot.org/t400/0033.jpg)
Disconnect the fan:\
![](https://av.libreboot.org/t400/0034.jpg)
Unscrew these:\
![](https://av.libreboot.org/t400/0035.jpg) ![](https://av.libreboot.org/t400/0036.jpg)
![](https://av.libreboot.org/t400/0037.jpg) ![](https://av.libreboot.org/t400/0038.jpg)
Unscrew the heatsink, then lift it off:\
![](https://av.libreboot.org/t400/0039.jpg) ![](https://av.libreboot.org/t400/0040.jpg)
Disconnect the power jack:\
![](https://av.libreboot.org/t400/0041.jpg) ![](https://av.libreboot.org/t400/0042.jpg)
Loosen this:\
![](https://av.libreboot.org/t400/0043.jpg)
Remove this:\
![](https://av.libreboot.org/t400/0044.jpg) ![](https://av.libreboot.org/t400/0045.jpg)
![](https://av.libreboot.org/t400/0046.jpg) ![](https://av.libreboot.org/t400/0047.jpg)
![](https://av.libreboot.org/t400/0048.jpg)
Unscrew these:\
![](https://av.libreboot.org/t400/0049.jpg) ![](https://av.libreboot.org/t400/0050.jpg)
Remove this:\
![](https://av.libreboot.org/t400/0051.jpg) ![](https://av.libreboot.org/t400/0052.jpg)
Unscrew this:\
![](https://av.libreboot.org/t400/0053.jpg)
Remove the motherboard (the cage is still attached) from the right hand
side, then lift it out:\
![](https://av.libreboot.org/t400/0054.jpg) ![](https://av.libreboot.org/t400/0055.jpg)
![](https://av.libreboot.org/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): ![](https://av.libreboot.org/t400/0057.jpg) ![](https://av.libreboot.org/t400/0058.jpg)
![](https://av.libreboot.org/t400/0059.jpg) ![](https://av.libreboot.org/t400/0060.jpg)
![](https://av.libreboot.org/t400/0061.jpg) ![](https://av.libreboot.org/t400/0062.jpg)
Separate the motherboard:\
![](https://av.libreboot.org/t400/0063.jpg) ![](https://av.libreboot.org/t400/0064.jpg)
Connect your programmer, then connect GND and 3.3V\
![](https://av.libreboot.org/t400/0065.jpg) ![](https://av.libreboot.org/t400/0066.jpg)
![](https://av.libreboot.org/t400/0067.jpg) ![](https://av.libreboot.org/t400/0069.jpg)
![](https://av.libreboot.org/t400/0070.jpg) ![](https://av.libreboot.org/t400/0071.jpg)
A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is
also fine:\
![](https://av.libreboot.org/t400/0072.jpg)
Of course, make sure to turn on your PSU:\
![](https://av.libreboot.org/x200/disassembly/0013.jpg)
Now, you should be ready to install libreboot.
Refer to the external flashing instructions [here](spi.md), and when you're
done, re-assemble your laptop.
Thermal paste (IMPORTANT)
=========================
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.
![](https://av.libreboot.org/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.
Memory
======
In DDR3 machines with Cantiga (GM45/GS45/PM45), northbridge requires sticks
that will work as PC3-8500 (faster PC3/PC3L sticks can work as PC3-8500).
Non-matching pairs may not work. Single module (meaning, one of the slots
will be empty) will currently only work in slot 0.
NOTE: according to users reports, non matching pairs (e.g. 1+2 GiB) might
work in some cases.
Make sure that the RAM you buy is the 2Rx8 configuration when buying 4GiB sticks
(In other words: maximum of 2GiB per rank, 2 ranks per card).
[This page](http://www.forum.thinkpads.com/viewtopic.php?p=760721) might
be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://av.libreboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://av.libreboot.org/t400/boot0.jpg) ![](https://av.libreboot.org/t400/boot1.jpg)
Now [install GNU+Linux](../gnulinux/).

375
site/docs/install/t500_external.md Normal file
View File

@ -0,0 +1,375 @@
---
title: Flashing the T500 with a BeagleBone Black
x-toc-enable: true
...
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.
W500 is also mostly compatible with this guide.
Libreboot T400 {#t400}
==============
You may also be interested in the smaller, more portable [Libreboot
T400](t400_external.md).
Serial port {#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.
A note about CPUs
=================
[ThinkWiki](http://www.thinkwiki.org/wiki/Category:T500) has a list of
CPUs for this system. The Core 2 Duo P8400, P8600 and P8700 are believed
to work in libreboot. The T9600 was also tested on the T400 and
confirmed working.
T9550 and T9900 was tested by a user, and is compatible as reported in the IRC channel.
T9500 and T9400 may also work, but YMMV.
Quad-core CPUs
--------------
Very likely to be compatible, but requires hardware modification.
Based on info from German forum post about installing Core Quad CPU on T500 found in coreboot mailing list. Currently work in progress and no guide available.
Q9100 is compatible and confirmed working (after hw mod), as reported by users in the IRC
channel
- [Coreboot mailing list post](https://mail.coreboot.org/pipermail/coreboot/2016-November/082463.html)
- [German forum post about install Core Quad on T500](https://thinkpad-forum.de/threads/199129)
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 *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.
CPU paste required
==================
See [\#paste](#paste).
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
MAC address {#macaddress}
===========
Refer to [mac\_address.md](../hardware/mac_address.md).
Initial BBB configuration
=========================
Refer to [spi.md](spi.md) as a guide for external re-flashing.
The following shows how to connect clip to the BBB (on the P9 header),
for SOIC-16 (clip: Pomona 5252):
POMONA 5252 (correlate with the BBB guide)
=== ethernet jack and VGA port ====
NC - - 21
1 - - 17
NC - - NC
NC - - NC
NC - - NC
NC - - NC
18 - - 3.3V (PSU)
22 - - NC - this is pin 1 on the flash chip
=== SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
The following shows how to connect clip to the BBB (on the P9 header),
for SOIC-8 (clip: Pomona 5250):
POMONA 5250 (correlate with the BBB guide)
=== RAM slots ====
18 - - 1
22 - - NC
NC - - 21
3.3V (PSU) - - 17 - this is pin 1 on the flash chip
=== slot where the AC jack is connected ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
The procedure
-------------
Remove all screws:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t500/0001.jpg) ![](https://av.libreboot.org/t500/0002.jpg)
Remove the HDD/SSD and optical drive:\
![](https://av.libreboot.org/t500/0003.jpg) ![](https://av.libreboot.org/t500/0004.jpg)
Remove the palm rest:\
![](https://av.libreboot.org/t500/0005.jpg) ![](https://av.libreboot.org/t500/0006.jpg)
Remove the keyboard and rear bezel:\
![](https://av.libreboot.org/t500/0007.jpg) ![](https://av.libreboot.org/t500/0008.jpg)
![](https://av.libreboot.org/t500/0009.jpg) ![](https://av.libreboot.org/t500/0010.jpg)
![](https://av.libreboot.org/t500/0011.jpg) ![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t500/0013.jpg) ![](https://av.libreboot.org/t500/0017.jpg)
![](https://av.libreboot.org/t500/0018.jpg)
Remove this frame, and then remove the wifi chip:\
![](https://av.libreboot.org/t500/0014.jpg) ![](https://av.libreboot.org/t500/0015.jpg)
![](https://av.libreboot.org/t500/0016.jpg)
Remove the speakers:\
![](https://av.libreboot.org/t500/0019.jpg) ![](https://av.libreboot.org/t500/0020.jpg)
![](https://av.libreboot.org/t500/0021.jpg) ![](https://av.libreboot.org/t500/0022.jpg)
![](https://av.libreboot.org/t500/0023.jpg) ![](https://av.libreboot.org/t500/0024.jpg)
![](https://av.libreboot.org/t500/0025.jpg)
Remove the NVRAM battery (already removed in this photo):\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t500/0027.jpg)
Unroute the antenna wires:\
![](https://av.libreboot.org/t500/0028.jpg) ![](https://av.libreboot.org/t500/0029.jpg)
![](https://av.libreboot.org/t500/0030.jpg) ![](https://av.libreboot.org/t500/0031.jpg)
Disconnect the LCD cable from the motherboard:\
![](https://av.libreboot.org/t500/0032.jpg) ![](https://av.libreboot.org/t500/0033.jpg)
Remove the LCD assembly hinge screws, and then remove the LCD assembly:\
![](https://av.libreboot.org/t500/0034.jpg) ![](https://av.libreboot.org/t500/0035.jpg)
![](https://av.libreboot.org/t500/0036.jpg)
Remove the fan and heatsink:\
![](https://av.libreboot.org/t500/0037.jpg) ![](https://av.libreboot.org/t500/0038.jpg)
![](https://av.libreboot.org/t500/0039.jpg)
Remove this screw:\
![](https://av.libreboot.org/t500/0040.jpg)
Remove these cables, keeping note of how and in what arrangement they
are connected:\
![](https://av.libreboot.org/t500/0041.jpg) ![](https://av.libreboot.org/t500/0042.jpg)
![](https://av.libreboot.org/t500/0043.jpg) ![](https://av.libreboot.org/t500/0044.jpg)
![](https://av.libreboot.org/t500/0045.jpg) ![](https://av.libreboot.org/t500/0046.jpg)
![](https://av.libreboot.org/t500/0047.jpg) ![](https://av.libreboot.org/t500/0048.jpg)
![](https://av.libreboot.org/t500/0049.jpg)
Disconnect the power jack:\
![](https://av.libreboot.org/t500/0050.jpg) ![](https://av.libreboot.org/t500/0051.jpg)
Remove the motherboard and cage from the base (the marked hole is where
those cables were routed through):\
![](https://av.libreboot.org/t500/0052.jpg) ![](https://av.libreboot.org/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):\
![](https://av.libreboot.org/t500/0054.jpg) ![](https://av.libreboot.org/t500/0055.jpg)
Also remove this:\
![](https://av.libreboot.org/t500/0056.jpg) ![](https://av.libreboot.org/t500/0057.jpg)
Separate the motherboard from the cage:\
![](https://av.libreboot.org/t500/0058.jpg) ![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t500/0060.jpg)
Connect your programmer, then connect GND and 3.3V\
![](https://av.libreboot.org/t500/0061.jpg)\
![](https://av.libreboot.org/t400/0067.jpg) ![](https://av.libreboot.org/t400/0069.jpg)
![](https://av.libreboot.org/t400/0070.jpg) ![](https://av.libreboot.org/t400/0071.jpg)
A dedicated 3.3V PSU was used to create this guide, but at ATX PSU is
also fine:\
![](https://av.libreboot.org/t400/0072.jpg)
Of course, make sure to turn on your PSU:\
![](https://av.libreboot.org/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
[bbb\_setup.html\#bbb\_access](bbb_setup.html#bbb_access).
Test that flashrom works:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
In this case, the output was:
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.
How to backup factory.rom (change the -c option as neeed, for your flash
chip):
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
Note: the `-c` option is not required in libreboot's patched
flashrom, because the redundant flash chip definitions in *flashchips.c*
have been removed.\
Now compare the 3 images:
sha512sum factory\*.rom
If the hashes match, then just copy one of them (the factory.rom) to a
safe place (on a drive connected to another system, not the BBB). This
is useful for reverse engineering work, if there is a desirable
behaviour in the original firmware that could be replicated in coreboot
and libreboot.
While there is a default MAC address inside the gbe region of flash image,
it is not one you want to use. Make sure to change the MAC address to the one
that is correct for your system, for **later internal flash**,
but always remember to **flash unmodfied txtmode image first** as it is known
to work and only this variant provides memtest. You can follow instructions
at [ich9utils.md#ich9gen](ich9utils.md#ich9gen)
to change the MAC address inside the libreboot image.
Now flash it:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V
![](https://av.libreboot.org/x200/disassembly/0015.jpg)
You might see errors, but if it says `Verifying flash... VERIFIED` at
the end, then it's flashed and should boot. If you see errors, try
again (and again, and again); the message `Chip content is identical to
the requested image` is also an indication of a successful
installation.
Example output from running the command (see above):
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.
Thermal paste (IMPORTANT)
=========================
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.
![](https://av.libreboot.org/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.
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
[../hardware/\#recommended\_wifi](../hardware/#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:\
![](https://av.libreboot.org/t400/0012.jpg) ![](https://av.libreboot.org/t400/ar5b95.jpg)
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).
Memory
======
In DDR3 machines with Cantiga (GM45/GS45/PM45), northbridge requires sticks
that will work as PC3-8500 (faster PC3/PC3L sticks can work as PC3-8500).
Non-matching pairs may not work. Single module (meaning, one of the slots
will be empty) will currently only work in slot 0.
NOTE: according to users reports, non matching pairs (e.g. 1+2 GiB) might
work in some cases.
Make sure that the RAM you buy is the 2Rx8 configuration when buying 4GiB sticks
(In other words: maximum of 2GiB per rank, 2 ranks per card).
[This page](http://www.forum.thinkpads.com/viewtopic.php?p=760721) might
be useful for RAM compatibility info (note: coreboot raminit is
different, so this page might be BS)
The following photo shows 8GiB (2x4GiB) of RAM installed:\
![](https://av.libreboot.org/t400/memory.jpg)
Boot it!
--------
You should see something like this:
![](https://av.libreboot.org/t500/0062.jpg)
Now [install GNU+Linux](../gnulinux/).

221
site/docs/install/t60_unbrick.md Normal file
View File

@ -0,0 +1,221 @@
---
title: ThinkPad T60 Recovery guide
x-toc-enable: true
...
This section documents how to recover from a bad flash that prevents
your ThinkPad T60 from booting.
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in Libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
lower one (the one before the top one) is used. This bootblock is the first
code that executes, during *romstage* as per coreboot hardware initialization.
BUC is short for *Backup Control* and TS is short for *Top Swap*. This is a
special register on Intel platforms. Lenovo BIOS sets PRx registers, preventing
software re-flashing, but there is a bug in the protection, allowing everything
*except* the upper 64KiB from being flashed. By default, coreboot only puts a
bootblock in the upper region. If you flash such a ROM, while bucts is set to 1,
the system won't boot because there's not a valid bootblock; this is common if
you're re-flashing when coreboot is already installed, and you didn't set bucts
back to 0.
When you install on X60/T60 the first time, you set this bucts bit to 1, then
you re-flash a second time and set it back to 0.
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:\
![](https://av.libreboot.org/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:
<http://www.coreboot.org/Board:lenovo/x60/Installation>. (it says x60,
but instructions for t60 are identical)
Brick type 2: bad ROM image {#recovery}
===========================================
In this instance, you might have flashed a ROM without the top bootblock copied
to the lower 64KiB section in the ROM, and you flashed the ROM for the first
time (from Lenovo BIOS), in which case there is not a valid bootblock.
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:\
![](https://av.libreboot.org/t60_dev/0001.JPG) ![](https://av.libreboot.org/t60_dev/0002.JPG)
Lift off the palm rest:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t60_dev/0004.JPG) ![](https://av.libreboot.org/t60_dev/0005.JPG)
![](https://av.libreboot.org/t60_dev/0006.JPG)
Gently wedge both sides loose:\
![](https://av.libreboot.org/t60_dev/0007.JPG) ![](https://av.libreboot.org/t60_dev/0008.JPG)
Remove that cable from the position:\
![](https://av.libreboot.org/t60_dev/0009.JPG) ![](https://av.libreboot.org/t60_dev/0010.JPG)
Now remove that bezel. Remove wifi, nvram battery and speaker connector
(also remove 56k modem, on the left of wifi):\
![](https://av.libreboot.org/t60_dev/0011.JPG)
Remove those screws:\
![](https://av.libreboot.org/t60_dev/0012.JPG)
Disconnect the power jack:\
![](https://av.libreboot.org/t60_dev/0013.JPG)
Remove nvram battery:\
![](https://av.libreboot.org/t60_dev/0014.JPG)
Disconnect cable (for 56k modem) and disconnect the other cable:\
![](https://av.libreboot.org/t60_dev/0015.JPG) ![](https://av.libreboot.org/t60_dev/0016.JPG)
Disconnect speaker cable:\
![](https://av.libreboot.org/t60_dev/0017.JPG)
Disconnect the other end of the 56k modem cable:\
![](https://av.libreboot.org/t60_dev/0018.JPG)
Make sure you removed it:\
![](https://av.libreboot.org/t60_dev/0019.JPG)
Unscrew those:\
![](https://av.libreboot.org/t60_dev/0020.JPG)
Make sure you removed those:\
![](https://av.libreboot.org/t60_dev/0021.JPG)
Disconnect LCD cable from board:\
![](https://av.libreboot.org/t60_dev/0022.JPG)
Remove those screws then remove the LCD assembly:\
![](https://av.libreboot.org/t60_dev/0023.JPG) ![](https://av.libreboot.org/t60_dev/0024.JPG)
![](https://av.libreboot.org/t60_dev/0025.JPG)
Once again, make sure you removed those:\
![](https://av.libreboot.org/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:
![](https://av.libreboot.org/t60_dev/0027.JPG) ![](https://av.libreboot.org/t60_dev/0028.JPG)
![](https://av.libreboot.org/t60_dev/0029.JPG) ![](https://av.libreboot.org/t60_dev/0031.JPG)
![](https://av.libreboot.org/t60_dev/0032.JPG) ![](https://av.libreboot.org/t60_dev/0033.JPG)
This photo shows the flash chip, near the RAM, with numbers of pins written:
![](https://av.libreboot.org/t60_dev/0030.JPG)
Refer to the external flashing guide:
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
NOTE: Do not use the 3.3v rail from your SPI programmer. Leave that disconnected.
For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
when the clip is connected. Before removing the clip, disconnect the charger.
This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
X60 shares a common 3.3V rail with many other components on the mainboard,
which all draw a lot of current, more than your flasher can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or
lower (e.g. `spispeed=512`) is recommended on this board. The flashing becomes
unstable, on this machine, when you use higher speeds.
Reverse the steps to re-assemble your system, after you've flashed the chip.
It should be `Verifying flash... VERIFIED` at the end. If flashrom
complains about multiple flash chip definitions detected, then choose
one of them following the instructions in the output.
Put those screws back:\
![](https://av.libreboot.org/t60_dev/0047.JPG)
Put it back into lower chassis:\
![](https://av.libreboot.org/t60_dev/0048.JPG)
Attach LCD and insert screws (also, attach the lcd cable to the board):\
![](https://av.libreboot.org/t60_dev/0049.JPG)
Insert those screws:\
![](https://av.libreboot.org/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\
![](https://av.libreboot.org/t60_dev/0051.JPG)
Attach the heatsink and install the screws (also, make sure to install
the AC jack as highlighted):\
![](https://av.libreboot.org/t60_dev/0052.JPG)
Reinstall that upper bezel:\
![](https://av.libreboot.org/t60_dev/0053.JPG)
Do that:\
![](https://av.libreboot.org/t60_dev/0054.JPG) ![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/t60_dev/0056.JPG) ![](https://av.libreboot.org/t60_dev/0057.JPG)
Place keyboard and (sorry, forgot to take pics) reinstall the palmrest
and insert screws on the underside:\
![](https://av.libreboot.org/t60_dev/0058.JPG)
It lives!\
![](https://av.libreboot.org/t60_dev/0071.JPG) ![](https://av.libreboot.org/t60_dev/0072.JPG)
![](https://av.libreboot.org/t60_dev/0073.JPG)
Always stress test ('stress -c 2' and xsensors. below 90C is ok) when
replacing cpu paste/heatsink:\
![](https://av.libreboot.org/t60_dev/0074.JPG)

150
site/docs/install/x200_external.md Normal file
View File

@ -0,0 +1,150 @@
---
title: First-time ThinkPad X200 flashing
x-toc-enable: true
...
This guide is for those who want libreboot on their ThinkPad X200 while
they still have the original Lenovo BIOS present. This guide can also be
followed (adapted) if you brick your X200, to know how to recover.
If you have the original Lenovo firmware running, you will need to take the
keyboard and palmrest off so that you can access the flash chip, which is just
underneath the palm rest. You will then connect an external SPI programmer, to
re-flash the chip externally while it is powered off with the battery removed.
NOTE: This guide only applies to the regular X200. For X200S and X200 Tablet
flashing, please read other guides available on libreboot.org.
Flash chip size
===============
Run this command on x200 to find out flash chip model and its size:
flashrom -p internal
MAC address
===========
Refer to [mac\_address.md](../hardware/mac_address.md).
The procedure
-------------
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:\
![](https://av.libreboot.org/x200/disassembly/0003.jpg)
Gently push the keyboard towards the screen, then lift it off, and optionally
disconnect it from the board:\
![](https://av.libreboot.org/x200/disassembly/0004.jpg)
![](https://av.libreboot.org/x200/disassembly/0005.jpg)
Disconnect the cable of the fingerpring reader, and then pull up the palm rest,
lifting up the left and right side of it:\
![](https://av.libreboot.org/x200/disassembly/0006.1.jpg)
![](https://av.libreboot.org/x200/disassembly/0006.jpg)
This shows the location of the flash chip, for both SOIC-8 and SOIC-16:\
![](https://av.libreboot.org/x200/x200_soic16.jpg)
![](https://av.libreboot.org/x200/x200_soic8.jpg)
Lift back the tape that covers a part of the flash chip, and then
connect the clip:\
![](https://av.libreboot.org/x200/disassembly/0008.jpg)
Now, you should be ready to install libreboot.
Refer to the [SPI programming instructions](spi.md).
When you're done, put the system back together. If it doesn't boot, try other
RAM modules because raminit is very unreliable on this platform (in coreboot).
Memory
======
In DDR3 machines with Cantiga (GM45/GS45/PM45), northbridge requires sticks
that will work as PC3-8500 (faster PC3/PC3L sticks can work as PC3-8500).
Non-matching pairs may not work. Single module (meaning, one of the slots
will be empty) will currently only work in slot 0.
NOTE: according to users reports, non matching pairs (e.g. 1+2 GiB) might
work in some cases.
Make sure that the RAM you buy is the 2Rx8 configuration when buying 4GiB sticks
(In other words: maximum of 2GiB per rank, 2 ranks per card).
In this photo, 8GiB of RAM (2x4GiB) is installed:
![](https://av.libreboot.org/x200/disassembly/0018.jpg)
Boot it!
--------
You should see something like this:
![](https://av.libreboot.org/x200/disassembly/0019.jpg)
Now [install GNU+Linux](../gnulinux/).
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):
![](https://av.libreboot.org/x200/gpio33_location.jpg)
By default we would see this in lenovobios, when trying flashrom -p
internal -w rom.rom:
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00001000-0x005f5fff) is locked.
With GPIO33 grounded during boot, this disabled the flash protections as
set by descriptor, and stopped the ME from starting. The output changed
to:
The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.
The part in bold is what got us. This was still observed:
PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.
It is actually possible to disable these protections. Lenovobios does,
when updating the BIOS (proprietary one). One possible way to go about
this would be to debug the BIOS update utility from Lenovo, to find out
how it's disabling these protections. Some more research is available
here:
<http://www.coreboot.org/Board:lenovo/x200/internal_flashing_research>
Of course, it's likely that the Lenovo BIOS is checking for some bit in memory
that tells it not to disable flashing, and then it won't set PRx registers. The
way the Lenovo BIOS updater works is, it is executed in Windows first and then
a reboot happens, triggering the re-flashing to happen during early boot. It is
probably setting something in memory and loading the ROM, plus a payload program
that does the flashing; Lenovo BIOS then probably sees that and runs that, instead
of setting PRx and going for normal boot. It is theoretically possible that we
could discover how this works, by debugging the Lenovo BIOS update utility (in
Windows), and then replicate what it is doing, with some tool for GNU+Linux,
then load a flashrom binary into memory and the ROM to flash (for the BIOS
region). You would do this with GPIO33 grounded, and the payload program would
actually flash the entire chip, with just a normal Libreboot image.
It's possible. The above is likely the only way that the Lenovo BIOS updater
program works. So if we discover precisely how to do that, then you could
just connect some pogo pins to ground GPIO33, then boot up, run some software
(which would have to be written) that does the above.
On a related note, libreboot has a utility that could help with
investigating this:
[ich9utils.md#demefactory](ich9utils.md#demefactory)

229
site/docs/install/x60_unbrick.md Normal file
View File

@ -0,0 +1,229 @@
---
title: ThinkPad X60 Recovery guide
x-toc-enable: true
...
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 from booting.
ROM images for this machine are well-tested in Libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
lower one (the one before the top one) is used. This bootblock is the first
code that executes, during *romstage* as per coreboot hardware initialization.
BUC is short for *Backup Control* and TS is short for *Top Swap*. This is a
special register on Intel platforms. Lenovo BIOS sets PRx registers, preventing
software re-flashing, but there is a bug in the protection, allowing everything
*except* the upper 64KiB from being flashed. By default, coreboot only puts a
bootblock in the upper region. If you flash such a ROM, while bucts is set to 1,
the system won't boot because there's not a valid bootblock; this is common if
you're re-flashing when coreboot is already installed, and you didn't set bucts
back to 0.
When you install on X60/T60 the first time, you set this bucts bit to 1, then
you re-flash a second time and set it back to 0.
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:\
![](https://av.libreboot.org/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:
<http://www.coreboot.org/Board:lenovo/x60/Installation>.
Brick type 2: bad ROM image {#recovery}
===========================================
In this instance, you might have flashed a ROM without the top bootblock copied
to the lower 64KiB section in the ROM, and you flashed the ROM for the first
time (from Lenovo BIOS), in which case there is not a valid bootblock.
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:\
![](https://av.libreboot.org/x60_unbrick/0000.jpg)
Push the keyboard forward (carefully):\
![](https://av.libreboot.org/x60_unbrick/0001.jpg)
Lift the keyboard up and disconnect it from the board:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/x60_unbrick/0003.jpg)
You should now have this:\
![](https://av.libreboot.org/x60_unbrick/0004.jpg)
Disconnect the wifi antenna cables, the modem cable and the speaker:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/x60_unbrick/0008.jpg)
Carefully lift the remaining tape and unroute the left antenna cable so
that it is loose:\
![](https://av.libreboot.org/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):\
![](https://av.libreboot.org/x60_unbrick/0011.jpg)
Remove those screws:\
![](https://av.libreboot.org/x60_unbrick/0012.jpg)
Carefully remove the plate, like so:\
![](https://av.libreboot.org/x60_unbrick/0013.jpg)
Remove the SATA connector:\
![](https://av.libreboot.org/x60_unbrick/0014.jpg)
Now remove the motherboard (gently) and cast the lcd/chassis aside:\
![](https://av.libreboot.org/x60_unbrick/0015.jpg)
Lift back that tape and hold it with something. Highlighted is the SPI
flash chip:\
![](https://av.libreboot.org/x60_unbrick/0016.jpg)
Here is another photo, with the numbers of the pins written:\
![](https://av.libreboot.org/x60_unbrick/0017.jpg)\
This photo shows an SPI flasher used, with SOIC8 test clip:\
![](https://av.libreboot.org/x60/th_bbb_flashing.jpg)
Refer to the following guide:\
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
NOTE: Do not use the 3.3v rail from your raspberry pi. Leave that disconnected.
For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
when the clip is connected. Before removing the clip, disconnect the charger.
This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
X60 shares a common 3.3V rail with many other components on the mainboard,
which all draw a lot of current, more than your programmer can provide.
Example RPi command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or
lower (e.g. `spispeed=512`) is recommended on this board. The flashing becomes
unstable, on this machine, when you use higher speeds.
Reverse the steps to re-assemble your system, after you've flashed the chip.
It should be `Verifying flash... VERIFIED` at the end. If flashrom
complains about multiple flash chip definitions detected, then choose
one of them following the instructions in the output.
Remove the programmer and put it away somewhere. Put back the tape and
press firmly over it:\
![](https://av.libreboot.org/x60_unbrick/0026.jpg)
Your empty chassis:\
![](https://av.libreboot.org/x60_unbrick/0027.jpg)
Put the motherboard back in:\
![](https://av.libreboot.org/x60_unbrick/0028.jpg)
Reconnect SATA:\
![](https://av.libreboot.org/x60_unbrick/0029.jpg)
Put the plate back and re-insert those screws:\
![](https://av.libreboot.org/x60_unbrick/0030.jpg)
Re-route that antenna cable around the fan and apply the tape:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/x60_unbrick/0032.jpg)
Re-insert that screw:\
![](https://av.libreboot.org/x60_unbrick/0033.jpg)
Route the black antenna cable like so:\
![](https://av.libreboot.org/x60_unbrick/0034.jpg)
Tuck it in neatly like so:\
![](https://av.libreboot.org/x60_unbrick/0035.jpg)
Route the modem cable like so:\
![](https://av.libreboot.org/x60_unbrick/0036.jpg)
Connect modem cable to board and tuck it in neatly like so:\
![](https://av.libreboot.org/x60_unbrick/0037.jpg)
Route the power connection and connect it to the board like so:\
![](https://av.libreboot.org/x60_unbrick/0038.jpg)
Route the antenna and modem cables neatly like so:\
![](https://av.libreboot.org/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):\
![](https://av.libreboot.org/x60_unbrick/0040.jpg)
Connect the modem cable:\
![](https://av.libreboot.org/x60_unbrick/0041.jpg)
Connect the speaker:\
![](https://av.libreboot.org/x60_unbrick/0042.jpg)
You should now have this:\
![](https://av.libreboot.org/x60_unbrick/0043.jpg)
Re-connect the upper chassis:\
![](https://av.libreboot.org/x60_unbrick/0044.jpg)
Re-connect the keyboard:\
![](https://av.libreboot.org/x60_unbrick/0045.jpg)
Re-insert the screws that you removed earlier:\
![](https://av.libreboot.org/x60_unbrick/0046.jpg)
Power on!\
![](https://av.libreboot.org/x60_unbrick/0047.jpg)
Operating system:\
![](https://av.libreboot.org/x60_unbrick/0049.jpg)

27
site/docs/install/x60flashscript.patch Normal file
View File

@ -0,0 +1,27 @@
From 34270811fce1ecf0bcf3b1363b0dc3dbf284ab09 Mon Sep 17 00:00:00 2001
From: Leah Rowe <info@minifree.org>
Date: Wed, 10 Jun 2015 22:53:28 +0000
Subject: flash script: fix a really really really dumb mistake
---
diff --git a/flash b/flash
index c96b915..04fd274 100755
--- a/flash
+++ b/flash
@@ -95,12 +95,12 @@ if [ "$mode" = "i945lenovo_firstflash" ] || [ "$mode" = "i945lenovo_secondflash"
# git or libreboot_src
bucts="./bucts/bucts"
flashrom_lenovobios_sst="./flashrom/flashrom_lenovobios_sst"
- flashrom_lenovobios_macronix="./flashrom/flashrom_lenovobios_sst"
+ flashrom_lenovobios_macronix="./flashrom/flashrom_lenovobios_macronix"
else
# libreboot_util
bucts="./bucts/$arch/bucts"
flashrom_lenovobios_sst="./flashrom/$arch/flashrom_lenovobios_sst"
- flashrom_lenovobios_macronix="./flashrom/$arch/flashrom_lenovobios_sst"
+ flashrom_lenovobios_macronix="./flashrom/$arch/flashrom_lenovobios_macronix"
fi
# anti-bricking precaution
--
cgit v0.9.0.2

131
site/docs/install/x60tablet_unbrick.md Normal file
View File

@ -0,0 +1,131 @@
---
title: ThinkPad X60 Tablet Recovery guide
x-toc-enable: true
...
This section documents how to recover from a bad flash that prevents
your ThinkPad X60 Tablet from booting.
ROM images for this machine are well-tested in Libreboot, so bricks are rare.
The most common cause of a brick is operator error, when flashing a ROM image.
In *most* cases, the cause will be that there is no bootblock, or an invalid
one.
Brick type 1: bucts not reset. {#bucts_brick}
==============================
You still have Lenovo BIOS, or you had libreboot running and you flashed
another ROM; and you had bucts 1 set and the ROM wasn't dd'd.\* or if
Lenovo BIOS was present and libreboot wasn't flashed.
There are *2* 64KiB bootblocks possible, in the upper part of the ROM image.
By default (bucts set to 0), the top one is used. If bucts is set to 1, the
lower one (the one before the top one) is used. This bootblock is the first
code that executes, during *romstage* as per coreboot hardware initialization.
BUC is short for *Backup Control* and TS is short for *Top Swap*. This is a
special register on Intel platforms. Lenovo BIOS sets PRx registers, preventing
software re-flashing, but there is a bug in the protection, allowing everything
*except* the upper 64KiB from being flashed. By default, coreboot only puts a
bootblock in the upper region. If you flash such a ROM, while bucts is set to 1,
the system won't boot because there's not a valid bootblock; this is common if
you're re-flashing when coreboot is already installed, and you didn't set bucts
back to 0.
When you install on X60/T60 the first time, you set this bucts bit to 1, then
you re-flash a second time and set it back to 0.
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:\
![](https://av.libreboot.org/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:
<http://www.coreboot.org/Board:lenovo/x60/Installation>.
Brick type 2: bad ROM image {#recovery}
===========================================
In this instance, you might have flashed a ROM without the top bootblock copied
to the lower 64KiB section in the ROM, and you flashed the ROM for the first
time (from Lenovo BIOS), in which case there is not a valid bootblock.
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).
![](https://av.libreboot.org/x60t_unbrick/0000.JPG)
Remove those screws:\
![](https://av.libreboot.org/x60t_unbrick/0001.JPG)
Remove the HDD:\
![](https://av.libreboot.org/x60t_unbrick/0002.JPG)
Push keyboard forward to loosen it:\
![](https://av.libreboot.org/x60t_unbrick/0003.JPG)
Lift:\
![](https://av.libreboot.org/x60t_unbrick/0004.JPG)
Remove those:\
![](https://av.libreboot.org/x60t_unbrick/0005.JPG)
![](https://av.libreboot.org/x60t_unbrick/0006.JPG)
Also remove that (marked) and unroute the antenna cables:\
![](https://av.libreboot.org/x60t_unbrick/0007.JPG)
For some X60T laptops, you have to unroute those too:\
![](https://av.libreboot.org/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:\
![](https://av.libreboot.org/x60t_unbrick/0008.JPG)
Remove that screw and then remove the board:\
![](https://av.libreboot.org/x60t_unbrick/0009.JPG)
This photo shows the flash location:\
![](https://av.libreboot.org/x60t_unbrick/0011.JPG)
This photo shows an SPI flasher used, with SOIC8 test clip:\
![](https://av.libreboot.org/x60/th_bbb_flashing.jpg)
Refer to the external flashing guide:
[Externally rewrite 25xx NOR flash via SPI protocol](spi.md)
NOTE: Do not use the 3.3v rail from your SPI programmer. Leave that disconnected.
For 3.3v, plug your charger into the mainboard (but do not power on the mainboard)
when the clip is connected. Before removing the clip, disconnect the charger.
This will provide adequate 3.3v DC at correct current levels. The SPI flash on an
X60 Tablet shares a common 3.3V rail with many other components on the mainboard,
which all draw a lot of current, more than most flashers can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or
lower (e.g. `spispeed=512`) is recommended on this board. The flashing becomes
unstable, on this machine, when you use higher speeds.
Reverse the steps to re-assemble your system, after you've flashed the chip.

251
site/docs/maintain/index.md Normal file
View File

@ -0,0 +1,251 @@
resources/
resources/coreboot
resources/coreboot/default
resources/coreboot/default/board.cfg
resources/coreboot/default/patches
resources/coreboot/default/patches/0001-lenovo-x230-change-pci_mmio_size-from-1024-to-2048-f.patch
resources/coreboot/default/patches/0002-lenovo-x230-set-default-VRAM-allocation-of-224MiB-in.patch
resources/coreboot/default/patches/0003-lenovo-x220-change-pci_mmio_size-from-1024-to-2048.patch
resources/coreboot/default/patches/0004-lenovo-x220-increase-default-VRAM-size-to-224MiB-in-.patch
resources/coreboot/default/patches/0005-lenovo-t420-change-default-VRAM-allocation-to-224MiB.patch
resources/coreboot/default/patches/0006-lenovo-t420s-change-default-vram-allocation-to-224Mi.patch
resources/coreboot/default/patches/0007-hardcode-tianocore-revisions-and-don-t-automatically.patch
resources/coreboot/default/patches/0008-lenovo-x200-set-VRAM-to-256MiB-by-default.patch
resources/coreboot/default/patches/0009-lenovo-x60-64MiB-Video-RAM-changed-to-default-previo.patch
resources/coreboot/default/patches/0010-lenovo-t400-set-vram-to-256MiB-by-default-instead-of.patch
resources/coreboot/default/patches/0011-nb-intel-gm45-Reserve-MMIO-and-firmware-memory-below.patch
resources/coreboot/default/patches/0012-lenovo-t60-make-64MiB-VRAM-the-default-in-cmos.defau.patch
resources/coreboot/default/patches/0013-lenovo-x230-introduce-FHD-variant.patch
resources/coreboot/default/patches/0014-apple-macbook21-Set-default-VRAM-to-64MiB-instead-of.patch
resources/coreboot/default/patches/0015-lenovo-t430-change-default-vram-on-intel-gpu-to-224M.patch
resources/coreboot/kcma-d8_2mb
resources/coreboot/kcma-d8_2mb/board.cfg
resources/coreboot/kcma-d8_2mb/config
resources/coreboot/kcma-d8_2mb/config/libgfxinit_txtmode
resources/coreboot/kcma-d8_2mb/config/vgarom_txtmode
resources/coreboot/kcma-d8_2mb/patches
resources/coreboot/kcma-d8_2mb/patches/0001-Revert-Revert-nb-amd-mct_ddr3-Fix-RDIMM-training-fai.patch
resources/coreboot/kcma-d8_2mb/patches/0002-Allow-loading-Option-ROM.patch
resources/coreboot/kcma-d8_2mb/patches/0003-Tweak-cmos-defaults-for-KCMA-D8.patch
resources/coreboot/r500_4mb
resources/coreboot/r500_4mb/board.cfg
resources/coreboot/r500_4mb/config
resources/coreboot/r500_4mb/config/libgfxinit_corebootfb
resources/coreboot/r500_4mb/config/libgfxinit_txtmode
resources/coreboot/t400_16mb
resources/coreboot/t400_16mb/board.cfg
resources/coreboot/t400_16mb/config
resources/coreboot/t400_16mb/config/libgfxinit_corebootfb
resources/coreboot/t400_16mb/config/libgfxinit_txtmode
resources/coreboot/t400_4mb
resources/coreboot/t400_4mb/board.cfg
resources/coreboot/t400_4mb/config
resources/coreboot/t400_4mb/config/libgfxinit_corebootfb
resources/coreboot/t400_4mb/config/libgfxinit_txtmode
resources/coreboot/t400_8mb
resources/coreboot/t400_8mb/board.cfg
resources/coreboot/t400_8mb/config
resources/coreboot/t400_8mb/config/libgfxinit_corebootfb
resources/coreboot/t400_8mb/config/libgfxinit_txtmode
resources/coreboot/t420_8mb
resources/coreboot/t420_8mb/board.cfg
resources/coreboot/t420_8mb/config
resources/coreboot/t420_8mb/config/libgfxinit_corebootfb
resources/coreboot/t420_8mb/config/libgfxinit_txtmode
resources/coreboot/t420_8mb/flash.layout
resources/coreboot/t420s_8mb
resources/coreboot/t420s_8mb/board.cfg
resources/coreboot/t420s_8mb/config
resources/coreboot/t420s_8mb/config/libgfxinit_corebootfb
resources/coreboot/t420s_8mb/config/libgfxinit_txtmode
resources/coreboot/t420s_8mb/flash.layout
resources/coreboot/t440p_12mb
resources/coreboot/t440p_12mb/board.cfg
resources/coreboot/t440p_12mb/config
resources/coreboot/t440p_12mb/config/libgfxinit_corebootfb
resources/coreboot/t440p_12mb/config/libgfxinit_txtmode
resources/coreboot/t440p_12mb/flash.layout
resources/coreboot/t60_intelgpu
resources/coreboot/t60_intelgpu/board.cfg
resources/coreboot/t60_intelgpu/config
resources/coreboot/t60_intelgpu/config/libgfxinit_corebootfb
resources/coreboot/t60_intelgpu/config/libgfxinit_txtmode
resources/coreboot/w500_16mb
resources/coreboot/w500_16mb/board.cfg
resources/coreboot/w500_16mb/config
resources/coreboot/w500_16mb/config/libgfxinit_corebootfb
resources/coreboot/w500_16mb/config/libgfxinit_txtmode
resources/coreboot/w500_4mb
resources/coreboot/w500_4mb/board.cfg
resources/coreboot/w500_4mb/config
resources/coreboot/w500_4mb/config/libgfxinit_corebootfb
resources/coreboot/w500_4mb/config/libgfxinit_txtmode
resources/coreboot/w500_8mb
resources/coreboot/w500_8mb/board.cfg
resources/coreboot/w500_8mb/config
resources/coreboot/w500_8mb/config/libgfxinit_corebootfb
resources/coreboot/w500_8mb/config/libgfxinit_txtmode
resources/coreboot/x200_16mb
resources/coreboot/x200_16mb/board.cfg
resources/coreboot/x200_16mb/config
resources/coreboot/x200_16mb/config/libgfxinit_corebootfb
resources/coreboot/x200_16mb/config/libgfxinit_txtmode
resources/coreboot/x200_4mb
resources/coreboot/x200_4mb/board.cfg
resources/coreboot/x200_4mb/config
resources/coreboot/x200_4mb/config/libgfxinit_corebootfb
resources/coreboot/x200_4mb/config/libgfxinit_txtmode
resources/coreboot/x200_8mb
resources/coreboot/x200_8mb/board.cfg
resources/coreboot/x200_8mb/config
resources/coreboot/x200_8mb/config/libgfxinit_corebootfb
resources/coreboot/x200_8mb/config/libgfxinit_txtmode
resources/coreboot/x220_8mb
resources/coreboot/x220_8mb/board.cfg
resources/coreboot/x220_8mb/config
resources/coreboot/x220_8mb/config/libgfxinit_corebootfb
resources/coreboot/x220_8mb/config/libgfxinit_txtmode
resources/coreboot/x220_8mb/flash.layout
resources/coreboot/x230_12mb
resources/coreboot/x230_12mb/board.cfg
resources/coreboot/x230_12mb/config
resources/coreboot/x230_12mb/config/libgfxinit_corebootfb
resources/coreboot/x230_12mb/config/libgfxinit_txtmode
resources/coreboot/x230_12mb/flash.layout
resources/coreboot/x230_fhd_12mb
resources/coreboot/x230_fhd_12mb/board.cfg
resources/coreboot/x230_fhd_12mb/config
resources/coreboot/x230_fhd_12mb/config/libgfxinit_corebootfb
resources/coreboot/x230_fhd_12mb/config/libgfxinit_txtmode
resources/coreboot/x230_fhd_12mb/flash.layout
resources/coreboot/x230t_12mb
resources/coreboot/x230t_12mb/board.cfg
resources/coreboot/x230t_12mb/config
resources/coreboot/x230t_12mb/config/libgfxinit_corebootfb
resources/coreboot/x230t_12mb/config/libgfxinit_txtmode
resources/coreboot/x230t_12mb/flash.layout
resources/coreboot/x60
resources/coreboot/x60/board.cfg
resources/coreboot/x60/config
resources/coreboot/x60/config/libgfxinit_corebootfb
resources/coreboot/x60/config/libgfxinit_txtmode
resources/coreboot/macbook21
resources/coreboot/macbook21/config
resources/coreboot/macbook21/config/libgfxinit_corebootfb
resources/coreboot/macbook21/config/libgfxinit_txtmode
resources/coreboot/macbook21/board.cfg
resources/coreboot/macbook11
resources/coreboot/macbook11/config
resources/coreboot/macbook11/config/libgfxinit_corebootfb
resources/coreboot/macbook11/config/libgfxinit_txtmode
resources/coreboot/macbook11/board.cfg
resources/coreboot/t430s_16mb
resources/coreboot/t430s_16mb/config
resources/coreboot/t430s_16mb/config/libgfxinit_corebootfb
resources/coreboot/t430s_16mb/config/libgfxinit_txtmode
resources/coreboot/t430s_16mb/flash.layout
resources/coreboot/t430s_16mb/board.cfg
resources/coreboot/kcma-d8_16mb
resources/coreboot/kcma-d8_16mb/config
resources/coreboot/kcma-d8_16mb/config/libgfxinit_txtmode
resources/coreboot/kcma-d8_16mb/config/vgarom_txtmode
resources/coreboot/kcma-d8_16mb/board.cfg
resources/coreboot/t500_8mb
resources/coreboot/t500_8mb/board.cfg
resources/coreboot/t500_8mb/config
resources/coreboot/t500_8mb/config/libgfxinit_corebootfb
resources/coreboot/t500_8mb/config/libgfxinit_txtmode
resources/coreboot/t500_4mb
resources/coreboot/t500_4mb/board.cfg
resources/coreboot/t500_4mb/config
resources/coreboot/t500_4mb/config/libgfxinit_corebootfb
resources/coreboot/t500_4mb/config/libgfxinit_txtmode
resources/coreboot/t500_16mb
resources/coreboot/t500_16mb/board.cfg
resources/coreboot/t500_16mb/config
resources/coreboot/t500_16mb/config/libgfxinit_corebootfb
resources/coreboot/t500_16mb/config/libgfxinit_txtmode
resources/grub
resources/grub/config
resources/grub/config/AUTHORS
resources/grub/config/COPYING
resources/grub/config/extra
resources/grub/config/extra/common.cfg
resources/grub/config/extra/corebootfb.cfg
resources/grub/config/extra/txtmode.cfg
resources/grub/config/grub_memdisk.cfg
resources/grub/config/menuentries
resources/grub/config/menuentries/common.cfg
resources/grub/config/menuentries/corebootfb.cfg
resources/grub/config/menuentries/txtmode.cfg
resources/grub/keymap
resources/grub/keymap/deqwertz.gkb
resources/grub/keymap/esqwerty.gkb
resources/grub/keymap/frazerty.gkb
resources/grub/keymap/frdvbepo.gkb
resources/grub/keymap/itqwerty.gkb
resources/grub/keymap/svenska.gkb
resources/grub/keymap/ukdvorak.gkb
resources/grub/keymap/ukqwerty.gkb
resources/grub/keymap/usdvorak.gkb
resources/grub/keymap/usqwerty.gkb
resources/grub/keymap/colemak.gkb
resources/grub/modules.list
resources/memtest86plus
resources/memtest86plus/patch
resources/memtest86plus/patch/0001-config.h-beep_mode-and-baud_rate.patch
resources/scripts
resources/scripts/build
resources/scripts/build/clean
resources/scripts/build/clean/cbutils
resources/scripts/build/clean/crossgcc
resources/scripts/build/clean/flashrom
resources/scripts/build/clean/grub
resources/scripts/build/clean/memtest86plus
resources/scripts/build/clean/payloads
resources/scripts/build/clean/rom_images
resources/scripts/build/clean/seabios
resources/scripts/build/clean/tianocore
resources/scripts/build/clean/ich9utils
resources/scripts/build/dependencies
resources/scripts/build/dependencies/arch
resources/scripts/build/dependencies/ubuntu2004
resources/scripts/build/descriptors
resources/scripts/build/descriptors/ich9m
resources/scripts/build/module
resources/scripts/build/module/cbutils
resources/scripts/build/module/flashrom
resources/scripts/build/module/grub
resources/scripts/build/module/memtest86plus
resources/scripts/build/module/ich9utils
resources/scripts/build/osboot
resources/scripts/build/osboot/roms
resources/scripts/build/osboot/roms_helper
resources/scripts/build/payload
resources/scripts/build/payload/seabios
resources/scripts/build/payload/tianocore
resources/scripts/build/payload/grub
resources/scripts/build/release
resources/scripts/build/release/roms
resources/scripts/build/release/src
resources/scripts/download
resources/scripts/download/coreboot
resources/scripts/download/flashrom
resources/scripts/download/grub
resources/scripts/download/memtest86plus
resources/scripts/download/seabios
resources/scripts/download/tianocore
resources/scripts/download/dejavusansmono
resources/scripts/download/ich9utils
resources/scripts/download/www
resources/scripts/update
resources/scripts/update/coreboot
resources/scripts/update/coreboot/configs
resources/scripts/update/tianocore
resources/scripts/update/tianocore/configs
resources/seabios
resources/seabios/config
resources/seabios/config/libgfxinit
resources/seabios/config/vgarom
resources/tianocore
resources/tianocore/dummy.coreboot.config

1332
site/docs/maintain/index.old Normal file
View File

File diff suppressed because it is too large Load Diff

117
site/docs/misc/codenames.md Normal file
View File

@ -0,0 +1,117 @@
---
title: Product Codenames
x-toc-enable: true
...
TODO: this page could do with an update. More info, about more boards
Introduction
============
This document lists product codenames for some hardware.
Please note that just because a certain device is listed here does NOT mean
that it is supported in Libreboot. For supported devices refer to the
installation documentation.
### A note on GPUs
Some laptops come with and without a discrete GPU (dGPU). Whether the
motherboard includes one or not can be determined by (in descending order
of reliability):
- often thorough disassembly and searching for the actual chip
- looking at white PCB markings near RAM slots / under keyboard
and comparing with some known codenames (if not available FRU ID sticker)
listed below.
- sometimes by looking at heatsink grills: on
discrete GPU laptops these will look orange and on intergrated ones
they will appear silver.
List of models and codenames
============================
### Codenames
- Asus Chromebook C201PA: speedy\_rk3288, veyron-speedy
- ThinkPad X60: KS Note (Sumo)
- ThinkPad X60s (slim): KS Note-2 / KS-2 (Kabuki)
- ThinkPad X60 Tablet: Dali (Same PCB as KS Note-2, different EC firmware)
- ThinkPad X200: Mocha-1
- ThinkPad X200s (slim): Pecan-1
- ThinkPad X200 Tablet: Caramel-1
- ThinkPad R400/T400: Malibu-3
- with discrete GPU (dGPU), at board revision 0: "MLB3D-0
- with only integrated GPU (iGPU), at board revision 0: "MLB3I-0"
- ThinkPad T500/W500: Coronado-5
- with dGPU (radeon): "COR5D-0" (last number is the board revision)
- with only iGPU: "COR5I-0"
- ThinkPad T400s (slim): Shinai-MV
- ThinkPad R500: Waikiki-3
- T6x (whole family): Davinci. They don't have codename label in
silkscreen so you need to use FRU label of the board, which is placed
under RAM sticks.
- T60:
- with dGPU (radeon): Magi-0 (last number is the board revision)
- with iGPU: Lisa-0
- R60(e): RP-1, RP-2 - Rockwell / Picasso
- With ThinkPads on Intel platforms newer than Montevina (Except T410),
the codenames become more consistent. All boards have the following
appended based on the type of graphics they have:
- with dGPU: SWG (SWitchable Graphics)
- with only iGPU: UMA (Unified Memory Access)
*Note that Intel platforms newer than Montevina are not supported by libreboot
yet!. Currently only Calistoga and Montevina platforms are supported.
- These are the known model codenames:
- ThinkPad T410: NOZOMI-1 # EXT/INT
- ThinkPad T410s: SHINAI-2 # SWG/UMA
- ThinkPad T420: NOZOMI-3 # SWG/UMA
- ThinkPad T420s: SHINAI-3 # SWG/UMA
- ThinkPad T430: NOZOMI-4 # SWG/UMA
- ThinkPad T430s: SHINAI-4 # SWG/UMA
- ThinkPad T520: KENDO-1
- ThinkPad W520: KENDO-1 WS
- ThinkPad T520: KENDO-3
- ThinkPad W520: KENDO-3 WS
- ThinkPad T530: KENDO-4
- ThinkPad W530: KENDO-4 WS
- ThinkPad T-series dock codenames:
- Advanced Mini Dock - Donatello
- Advanced Mini Dock (lacking SuperIO) - Donatello-lite
- Advanced Dock - Rodin
- Dock II - Aswan
- Mini Dock - Seville
- Port Replicator II - Seville-lite
### Miscellaneous
- [Calistoga](https://ark.intel.com/products/codename/5950/Calistoga):
945GM/945PM chipset family name
- Napa: calistoga based platform
- [Cantiga](https://ark.intel.com/products/codename/26552/Cantiga):
GM45/GS45/PM45 chipset family name.
This is the chipset used in T400,X200 and similar.
- Montevina: cantiga based platform.
- PMH: the Power Management Hub is a gate array for managing the power
up/down sequence. It is additionally tasked with extending EC's I/O.
Its later version was called "Thinker-1", and eventually it was merged
with PMIC (Rinkan) as ThinkEngine (Do not confuse it with EC chip which is also
has ThinkEngine logo on ThinkPad boards)
- Kozak, Tsurumai, Rinkan: These are successive versions of power management
ICs for Notebook PCs. Tsurumai chip marking is "TB62501F" and datasheet
of it fully describes its operation.
See also
========
- Many more Intel codenames can be found at
[Wikipedia](https://en.wikipedia.org/wiki/List_of_Intel_codenames).
- For ThinkPads see [Documentation/thinkpad/codenames.csv @ Coreboot]
(https://review.coreboot.org/cgit/coreboot.git/tree/Documentation/thinkpad/codenames.csv)

301
site/docs/misc/index.md Normal file
View File

@ -0,0 +1,301 @@
---
title: Miscellaneous
x-toc-enable: true
...
TODO: this page is very old, and could do with an update.
High Pitched Whining Noise on Idle in Debian or Devuan
======================================================================
Start powertop automatically at boot time.
Included with libreboot is a script called 'powertop.debian'. Run this
as root and it will setup powertop to run with --auto-tune at boot
time. Load the file in your text editor to see how it does that.
sudo ./resources/scripts/misc/powertop.debian
Might want to run with --calibrate first
If powertop doesn't work, another way (reduces battery life slightly)
is to add *processor.max\_cstate=2* to the *linux* line in grub.cfg,
using [this guide](../gnulinux/grub_cbfs.md).
High Pitched Whining Noise on Idle in Parabola
==============================================================
The following 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 powertop --auto-tune' again. This needs to be implemented
properly in coreboot itself!
On the X60 with coreboot or libreboot, there is a high pitched sound
when idle. So far we have use processor.max\_cstate=2 or idle=halt in
GRUB. These consume power. Stop using them!
Be root
su -
Installed powertop:
pacman -S powertop
and added the following to /etc/systemd/system/powertop.service :
[Unit]
Description=Powertop tunings
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/powertop --auto-tune
"powertop --auto-tune" still needs a terminal for some reason. Possibly a bug?
Environment="TERM=xterm"
[Install]
WantedBy=multi-user.target
Finally, as root do that:
systemctl enable powertop
systemctl start powertop
The next time you boot the system, the buzz will be gone.
Might want to run with --calibrate first
If powertop doesn't work, another way (reduces battery life slightly)
is to add *processor.max\_cstate=2* to the *linux* line in grub.cfg,
using [this guide](../gnulinux/grub_cbfs.md).
X60/T60: Serial port - how to use (for dock owners)
[Note: using a grsec enabled kernel will disable the powertop function. ](https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options)
===================================================
For the Thinkpad X60 you can use the "UltraBase X6" dock (for the
X60 Tablet it is called X6 Tablet UltraBase). For the ThinkPad T60, you
can use the "Advanced Mini Dock".
If you are using one of the ROM images with 'serial' in the name, then
you have serial port enabled in libreboot and you have memtest86+
included inside the ROM. Connect your null modem cable to the serial
port on the dock and connect the other end to a 2nd system using your
USB Serial adapter.
On the 2nd system, you can try this (using GNU Screen):
sudo screen /dev/ttyUSB0 115200
How to quit GNU Screen: Ctrl+A then release and press K, and then press
Y.
There are also others like Minicom but I like GNU Screen
By doing this before booting the X60/T60, you will see console output
from libreboot. You will also see GRUB displaying on the serial output,
and you will be able to see MemTest86+ on the serial output aswell. You
can also configure your distro so that a terminal (TTY) is accessible
from the serial console.
The following guide is for Ubuntu, but it should work in Debian and
Devuan, to enable a serial console using GeTTY:\
<https://help.ubuntu.com/community/SerialConsoleHowto> (we DO NOT
recommend Ubuntu, because it contains non-free software in the default
repos. Use Debian or Devuan)
Note: part of the tutorial above requires changing your grub.cfg. Just
change the `linux` line to add instructions for enabling getty. See
[../gnulinux/grub\_cbfs.md](../gnulinux/grub_cbfs.md).
Finetune backlight control on intel gpu's
=========================================
Sometimes the backlight control value (BLC\_PWM\_CTL) set by libreboot
is not ideal. The result is either flicker, which could cause nausea or
epilepsy or an uneven backlight and/or coil whine coming from the
display. To fix this a different value for the gpu reg BLC\_PWM\_CTL
needs to be set. See p94 of
<https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0.pdf>
for more information on this reg. The tool for setting registry values
on intel gpu's is included in intel-gpu-tools. Install intel-gpu-tools:
sudo apt-get install intel-gpu-tools
You can set values:
sudo intel_reg write 0x00061254 your_value_in_C_hex_format
NOTE: on older versions of this utility, use `intel_reg_write` instead.
The value set has the following structure: bits [31:16] is PWM
divider. PWM / PWM\_divider = frequency bits [15:0] is the duty cycle
and determines the portion of the backlight modulation frequency. A
value of 0 will mean that the display is off. A value equal to the
backlight modulation frequency means full on. The value should not be
larger than the backlight modulation frequency.
On displays with a CCFL backlight start from: 0x60016001 To verify if
all modes work as desired use: `xbacklight -set 10` and gradually
increase until 100. Displays with an LED backlight need a lower
backlight modulation. Do the same thing but start from 0x01290129 . Try
setting different values until you have found a value which presents no
issue.
It is important to know that there are four failure modes:
1. flickering very fast, which could cause epilepsy (frequency is too
low. decrease divider)
2. randomly flickering in random intervals - driver IC cannot keep up
with toggling the mosfet (frequency too fast, increase divider)
3. frequency is in audible range and causes coils to whine (frequency
is too high. increase divider)
4. backlight is uneven. (CCFL specific, frequency is too high. increase
divider)
To check for flickering try moving your laptop while looking at it.
A higher frequency equals higher power consumption. You want to find the
highest good working value.
Next this value should be set at boot: either add
intel_reg write 0x00061254 &ltyour_ideal_value>
NOTE: on older versions of this utility, use `intel_reg_write` instead.
before exit 0 in /etc/rc.local or create a systemd service file
/etc/systemd/system/backlight.service:
[Unit]
Description=Set BLC_PWM_CTL to a good value
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/intel_reg write 0x00061254 &ltyour_value>
[Install]
WantedBy=multi-user.target
Now start and enable it:
sudo systemctl start backlight && sudo systemctl enable backlight
Special note on i945:
i945 behaves differently. Bit 16 needs to be 1 and the duty cycle is not
updated when backlight is changed. There are no available datasheets on
this target so why it behaves in such a way is not known. So to find a
working value BLC\_PWM\_CTL set bit 16 to 1 and make sure PWM divider ==
duty cycle. see <https://review.coreboot.org/#/c/10624/> on bit 16. The
cause of this issue is that i945, in contrast with to GM45, is set to
work in BLM Legacy Mode. This makes backlight more complicated since the
duty cycle is derived from 3 instead of 2 registers using the following
formula: if(BPC[7:0] <> xFF) then BPCR[15:0] \* BPC[7:0]
Else BPCR[15:0] BPC is LBB - PCI Backlight Control Register, described
on <http://www.mouser.com/pdfdocs/945gmedatasheet.pdf> on page 315. BPCR
is BLC\_PWM\_CTL described in
<https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0.pdf>
on page 94. More research needs to be done on this target so proceed
with care.
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.
You need to write changes in a libreboot rom image, and flash it, in order
to apply them. You can either use a pre-compiled rom image, or create an image
from the current one in your computer. See here
<https://libreboot.org/docs/gnulinux/grub_cbfs.html#get-the-rom-image> for
more information on how to do that.
Once you have a libreboot rom image, say 'libreboot.rom', you can write
changes on the image with the following commands.
Disable or enable beeps when removing/adding the charger:
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Disable
Disable or enable beeps when battery is low:
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Disable
You can check that the parameters are set in the image with :
sudo ./nvramtool -C libreboot.rom -a
Finally, you need to flash the rom with this new image. See here
<https://libreboot.org/docs/gnulinux/grub_cbfs.html#with-re-flashing-the-rom>
for a detailed explanation.
Get EDID: Find out the name (model) of your LCD panel
=====================================================
Get the panel name:
sudo get-edid | strings
Or look in `/sys/class/drm/card0-LVDS-1/edid`
Alternatively you can use i2cdump. In Debian and Devuan, this is in the
package i2c-tools.
sudo modprobe i2c-dev
sudo i2cdump -y 5 0x50 (you might have to change the value for
-y)
sudo rmmod i2c-dev
You'll see the panel name in the output (from the EDID dump).
If neither of these options work (or they are unavailable), physically
removing the LCD panel is an option. Usually, there will be information
printed on the back.
e1000e driver trouble shooting (Intel NICs)
===========================================
Example error, ¿may happen on weird and complex routing schemes(citation
needed for cause):
e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang
Possible workaround, tested by Nazara: Disable C-STATES.
*NOTE: this also disables power management, because disabling C-States
means that your CPU will now be running at full capacity (and therefore
using more power) non-stop, which will drain battery life if this is a
laptop. If power usage is a concern, then you should not use this.
(we're also not sure whether this workaround is appropriate)*
To disable c-states, do this in GNU+Linux:
for i in /sys/devices/system/cpu/cpu/cpuidle/state/disable;
do
echo 1 > $i;
done
You can reproduce this issue more easily by sending lots of traffic
across subnets on the same interface (NIC).
More information, including logs, can be found on [this
page](http://web.archive.org/web/20210416010634/https://notabug.org/libreboot/libreboot/issues/23).
USB keyboard wakeup on GM45 laptops
===================================
Look at resources/scripts/helpers/misc/libreboot\_usb\_bugfix
Put this script in /etc/init.d/ on debian-based systems.

1479
site/docs/release.md Normal file
View File

File diff suppressed because it is too large Load Diff

84
site/donate.md Normal file
View File

@ -0,0 +1,84 @@
---
title: Donate to Libreboot
x-toc-enable: true
...
Introduction
============
Donate money to the Libreboot project. Your money will be used
to fund development and pay people who work on these projects. Some of the money
received will be donated to the
[Free Software Foundation](https://www.fsf.org/).
I, Leah Rowe, am founder of Libreboot. I am also the lead
developer of Libreboot. I use whatever money is received to fund development;
this also includes paying the other developers for their time on the project.
Send money via Patreon
======================
Go here for information:
<https://www.patreon.com/libreleah>
You can contribute money there, using a number of payment options that Patreon
supports.
Send money via Bitcoin
======================
Send money to this bitcoin wallet:
bc1qc7yz0e3uum5nwln08dr65zapqz7xrqhuk3aqm9
This bitcoin wallet is owned and operated by Leah Rowe. This bitcoin address
was last updated on 16 January 2021; keep an eye on this page in case this
bitcoin address changes in the future.
How will your money be used?
============================
I, Leah Rowe, am founder and lead developer of
[Libreboot](https://libreboot.org/). I
work with other developers too. This page is intended to raise money to financially
assist such development on both Libreboot and osboot, both of which provide
coreboot-based hardware initialization on supported machines.
The word *donation* and *donate* may be used here, but legally speaking it is
not a donation. You are simply sending money to Leah Rowe. I use whatever money
is received to pay for development costs.
My own work is focused on:
* Adding new boards from coreboot whenever feasible
* Experimenting with coreboot payloads; for years I've preferred GNU GRUB,
but lately I've been experimenting more with SeaBIOS, Tianocore and linuxboot,
the latter of which is not yet present in osboot and Tianocore/linuxboot
are both currently absent in Libreboot but will be added. For ARM (rockchip
and so on) I've been experimenting with UBoot; ARM support is quite weak
in Libreboot, so this is something that I was to improve.
* Providing excellent documentation, written for non-technical users (with
developer documentation also provided, either in osboot/Libreboot or
submitted upstream to projects such as coreboot)
* Working on upstream projects such as coreboot and GRUB (bug fixes, mostly,
though I myself added ThinkPad T400 support to coreboot many years ago and
huge improvements were made to it by other people in that project. I've also
commissioned work on new coreboot ports in the past, and paid for such work)
* Work on the Libreboot and osboot build systems (lbmk and rbmk, not paper)
* Generally running the project, coordinating development and handling releases
* I also provide user support on IRC
TODO: COREBOOT FORK
-------------------
Fork coreboot. For years, Libreboot has simply applied deblob scripts on the
upstream coreboot repository, but this is no longer feasible; coreboot has
deleted many boards over the years, and maintaining these scripts has become
much harder because multiple coreboot revisions have to be used.
So, on the agenda is this: fork coreboot, and re-add those deleted boards.
Maintain a proper fork of coreboot, while trying to stay as close to upstream
as possible (to make development easier), while making decisions that are more
optimal for Libreboot. Then Libreboot can use that fork, instead of deblobbing
upstream.

Some files were not shown because too many files have changed in this diff Show More