canoeboot
/
cbwww
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Censored Libreboot 20230710 website 

Signed-off-by: Leah Rowe <leah@libreboot.org>
master
Leah Rowe 2023-07-10 16:43:08 +01:00
commit 6a52fb9f57
184 changed files with 35979 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.gitignore vendored Normal file
View File

@ -0,0 +1,8 @@
*.html
/site/news/index*
/site/sitemap.md
/site/push
*feed.xml
*.sha1sum
*.hash
*.date

5
site.cfg Normal file
View File

@ -0,0 +1,5 @@
TITLE="-T Censored-libreboot"
DOMAIN="https://censored.libreboot.org/"
BLOGDIR="news/" # leave as empty string if you want the blog to be the homepage
CSS="--css /global.css"
LAZY="y"

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.

136
site/censorship.md Normal file
View File

@ -0,0 +1,136 @@
---
title: How is Censored Libreboot implemented (ie. censored)?
x-toc-enable: true
...
Introduction
============
For more context, please read the [Censored Libreboot c20230710 release
announcement](https://libreboot.org/news/censored-libreboot20230710.html)
*Censored Libreboot* is a glimpse of the state Libreboot would
be in, if it had never adopted the
[Binary Blob Reduction Policy](https://libreboot.org/news/policy.html). In
order to do this, many pages, and sources of information, were removed or
heavily re-worded (censored) in this version, compared to regular Libreboot. The
censored information/code would have never been permitted, under Libreboot's
previous [Binary Blob Extermination Policy](https://web.archive.org/web/20221107235850/https://libreboot.org/news/policy.html)
Support for many mainboards has been removed, in this censored version. The
website that you're reading
is based on the regular Libreboot website at the time of the
[Libreboot 20230625 release](https://libreboot.org/news/libreboot20230625.html).
Changes made in *Censored Libreboot*
====================================
Almost all of the website changes can be seen here, in this diff:
<https://codeberg.org/libreboot/lbwww/commit/23bf3b4c3d9473fd3fa6ee80907076667ea28ae7?style=split&whitespace=show-all>
The changes are so vast (about 8000 lines of text removed), that not all of them
show by default in the above link, but you can click "Show More" at the bottom
of that page. Codeberg is Libreboot's hosting provider for Git repositories, and
the website is hosted in Git.
For a list of code changes, you can refer to the [Censored Libreboot c20230710
release announcement](https://libreboot.org/news/censored-libreboot20230710.html)
The above link, and this page, demonstrate the *damage* that could be done to
Libreboot, in the name of cult-like ideological purity. Libreboot's policy is
simply to help as many people as possible install coreboot, with as few (or no)
binary blobs as possible.
Deleted web pages, in *Censored Libreboot*:
-------------------------------------------
All of these pages, which exist in the regular Libreboot website,
do not exist in the *censored* Libreboot website:
* <https://libreboot.org/docs/hardware/hp2560p.html>
* <https://libreboot.org/docs/hardware/hp2570p.html>
* <https://libreboot.org/docs/hardware/hp8200sff.html>
* <https://libreboot.org/docs/hardware/hp8300usdt.html>
* <https://libreboot.org/docs/hardware/hp9470m.html>
* <https://libreboot.org/docs/install/ivy_has_common.html>
* <https://libreboot.org/docs/install/ivy_has_common.uk.html>
* <https://libreboot.org/docs/install/ivy_internal.html>
* <https://libreboot.org/docs/install/nvmutilimport.html>
* <https://libreboot.org/docs/install/t420_external.html>
* <https://libreboot.org/docs/install/t440p_external.html>
* <https://libreboot.org/docs/install/x220_external.html>
* <https://libreboot.org/docs/install/x230_external.html>
* <https://libreboot.org/docs/linux/zfsbootmenu.html>
* <https://libreboot.org/docs/maintain/porting.html>
* <https://libreboot.org/docs/maintain/porting.uk.html>
* <https://libreboot.org/freedom-status.html>
* <https://libreboot.org/freedom-status.uk.html>
* <https://libreboot.org/news/e6400nvidia.html>
* <https://libreboot.org/news/freedom.html>
* <https://libreboot.org/news/gm45microcode.html>
* <https://libreboot.org/news/hp8200sff.html>
* <https://libreboot.org/news/hp8200sff.uk.html>
* <https://libreboot.org/news/hp_elitebooks.html>
* <https://libreboot.org/news/libreboot20221214.html>
* <https://libreboot.org/news/libreboot20230319.html>
* <https://libreboot.org/news/libreboot20230413.html>
* <https://libreboot.org/news/libreboot20230423.html>
* <https://libreboot.org/news/libreboot20230625.html>
* <https://libreboot.org/news/microcode.html>
* <https://libreboot.org/news/policy.de.html>
* <https://libreboot.org/news/policy.html>
* <https://libreboot.org/news/policy.uk.html>
* <https://libreboot.org/news/safety.html>
Heavily modified pages (not deleted)
------------------------------------
These pages have been modified heavily (a few of these aren't pages, but are
instead files like pandoc templates, used by Libreboot's static site
generator, namely the [Untitled Static Site Generator](https://untitled.vimuser.org)):
* [/contrib.md](/contrib.html) (censored version), versus original: <https://libreboot.org/contrib.html>
* [/contrib.uk.md](/contrib.uk.html) (censored version), versus original: <https://libreboot.org/contrib.uk.html>
* [/docs/bsd/index.md](/docs/bsd/index.html) (censored version), versus original: <https://libreboot.org/docs/bsd/index.html>
* [/docs/build/index.md](/docs/build/index.html) (censored version), versus original: <https://libreboot.org/docs/build/index.html>
* [/docs/build/index.uk.md](/docs/build/index.uk.html) (censored version), versus original: <https://libreboot.org/docs/build/index.uk.html>
* [/docs/hardware/e6400.md](/docs/hardware/e6400.html) (censored version), versus original: <https://libreboot.org/docs/hardware/e6400.html>
* [/docs/hardware/ga-g41m-es2l.md](/docs/hardware/ga-g41m-es2l.html) (censored version), versus original: <https://libreboot.org/docs/hardware/ga-g41m-es2l.html>
* [/docs/hardware/index.md](/docs/hardware/index.html) (censored version), versus original: <https://libreboot.org/docs/hardware/index.html>
* [/docs/hardware/kgpe-d16.md](/docs/hardware/kgpe-d16.html) (censored version), versus original: <https://libreboot.org/docs/hardware/kgpe-d16.html>
* [/docs/hardware/mac\_address.md](/docs/hardware/mac_address.html) (censored version), versus original: <https://libreboot.org/docs/hardware/mac_address.html>
* [/docs/install/chromebooks.md](/docs/install/chromebooks.html) (censored version), versus original: <https://libreboot.org/docs/install/chromebooks.html>
* [/docs/install/e6400.md](/docs/install/e6400.html) (censored version), versus original: <https://libreboot.org/docs/install/e6400.html>
* [/docs/install/index.md](/docs/install/index.html) (censored version), versus original: <https://libreboot.org/docs/install/index.html>
* [/docs/install/kgpe-d16.md](/docs/install/kgpe-d16.html) (censored version), versus original: <https://libreboot.org/docs/install/kgpe-d16.html>
* [/docs/install/nvmutil.md](/docs/install/nvmutil.html) (censored version), versus original: <https://libreboot.org/docs/install/nvmutil.html>
* [/docs/install/spi.md](/docs/install/spi.html) (censored version), versus original: <https://libreboot.org/docs/install/spi.html>
* [/docs/install/spi\_generic.md](/docs/install/spi_generic.html) (censored version), versus original: <https://libreboot.org/docs/install/spi_generic.html>
* [/docs/linux/index.md](/docs/linux/index.html) (censored version), versus original: <https://libreboot.org/docs/linux/index.html>
* [/docs/maintain/index.md](/docs/maintain/index.html) (censored version), versus original: <https://libreboot.org/docs/maintain/index.html>
* [/docs/maintain/testing.md](/docs/maintain/testing.html) (censored version), versus original: <https://libreboot.org/docs/maintain/testing.html>
* [/docs/uboot/index.md](/docs/uboot/index.html) (censored version), versus original: <https://libreboot.org/docs/uboot/index.html>
* [/docs/uboot/uboot-archlinux.md](/docs/uboot/uboot-archlinux.html) (censored version), versus original: <https://libreboot.org/docs/uboot/uboot-archlinux.html>
* [/download.md](/download.html) (censored version), versus original: <https://libreboot.org/download.html>
* [/download.uk.md](/download.uk.html) (censored version), versus original: <https://libreboot.org/download.uk.html>
* [/faq.md](/faq.html) (censored version), versus original: <https://libreboot.org/faq.html>
* [/faq.uk.md](/faq.uk.html) (censored version), versus original: <https://libreboot.org/faq.uk.html>
* [/footer.de.include](/footer.de.include) (censored version), versus original: <https://libreboot.org/footer.de.include>
* [/footer.include](/footer.include) (censored version), versus original: <https://libreboot.org/footer.include>
* [/footer.uk.include](/footer.uk.include) (censored version), versus original: <https://libreboot.org/footer.uk.include>
* [/footer.zh-cn.include](/footer.zh-cn.include) (censored version), versus original: <https://libreboot.org/footer.zh-cn.include>
* [/index.de.md](/index.de.html) (censored version), versus original: <https://libreboot.org/index.de.html>
* [/index.fr.md](/index.fr.html) (censored version), versus original: <https://libreboot.org/index.fr.html>
* [/index.md](/index.html) (censored version), versus original: <https://libreboot.org/index.html>
* [/index.uk.md](/index.uk.html) (censored version), versus original: <https://libreboot.org/index.uk.html>
* [/index.zh-cn.md](/index.zh-cn.html) (censored version), versus original: <https://libreboot.org/index.zh-cn.html>
* [/news/MANIFEST](/news/MANIFEST) (censored version), versus original: <https://libreboot.org/news/MANIFEST>
* [/news/audit.md](/news/audit.html) (censored version), versus original: <https://libreboot.org/news/audit.html>
* [/news/e6400.md](/news/e6400.html) (censored version), versus original: <https://libreboot.org/news/e6400.html>
* [/news/e6400.uk.md](/news/e6400.uk.html) (censored version), versus original: <https://libreboot.org/news/e6400.uk.html>
* [/news/usa-libre-part2.md](/news/usa-libre-part2.html) (censored version), versus original: <https://libreboot.org/news/usa-libre-part2.html>
* [/template.de.include](/template.de.include) (censored version), versus original: <https://libreboot.org/template.de.include>
* [/template.include](/template.include) (censored version), versus original: <https://libreboot.org/template.include>
* [/template.uk.include](/template.uk.include) (censored version), versus original: <https://libreboot.org/template.uk.include>
* [/template.zh-cn.include](/template.zh-cn.include) (censored version), versus original: <https://libreboot.org/template.zh-cn.include>

72
site/contact.de.md Normal file
View File

@ -0,0 +1,72 @@
---
title: Kontakt
x-toc-enable: true
...
**TODO: mailing lists, mastodon server and peertube account.**
User support
============
IRC oder Reddit werden bevorzugt, sofern Du eine Support Anfrage hast (IRC empfohlen).
Für Informationen bzgl. IRC and Reddit siehe unten.
Entwicklungs Diskussion
======================
Eine Mailing Liste ist für die Zukunft in Planung. Bis dahin, siehe unter
[der Git Seite](git.md) für Informationen wie Du dich an der Entwicklung beteiligen kannst.
Hier finden sich ebenso Anleitungen zum Senden von Patches (via Pull-Requests).
IRC Chatraum
============
IRC ist hauptsächlich der Weg um Kontakt Libreboot Projekt aufzunehmen. `#libreboot` auf Libera
IRC.
Webchat:
<https://web.libera.chat/#libreboot>
Libera ist eines der grössten IRC Netzwerke, welches für Libre Software Projekte verwendet wird.
Mehr Infos gibt es hier: <https://libera.chat/>
Wenn Du dich mit deinem bevorzugten IRC Klienten verbinden möchtest (z.B. weechat or irssi),
anbei die Verbindungsdetails:
* Server: `irc.libera.chat`
* Channel: `#libreboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
Wir empfehlen, dass Du Port `6697` mit aktivierter TLS Verschlüsselung verwendest.
Es wird empfohlen SASL für die Authentifizierung zu verwenden. Diese Seiten auf der Libera
Website erläutern wie dies funktioniert:
* WeeChat SASL Anleitung: <https://libera.chat/guides/weechat>
* Irssi SASL Anleitung: <https://libera.chat/guides/irssi>
* HexChat SASL Anleitung: <https://libera.chat/guides/hexchat>
Grundsätzlich solltest Du die Dokumentation der von Dir verwendeten IRC Software konsultieren.
Soziale Medien
============
Libreboot existiert offiziell an vielen Orten.
Mastodon
--------
Gründerin und Haupt-Entwicklerin, Leah Rowe, ist auf Mastodon:
* <https://mas.to/@libreleah>
Leah kann zudem unter dieser eMail kontaktiert werden:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Hauptsächlich verwendet als Support Kanal und für Veröffentlichung von Neuigkeiten:
<https://www.reddit.com/r/libreboot/>

72
site/contact.md Normal file
View File

@ -0,0 +1,72 @@
---
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
============
IRC is the main way to contact the libreboot project. `#libreboot` on Libera
IRC.
Webchat:
<https://web.libera.chat/#libreboot>
Libera is one of the largest IRC networks, used for Libre Software projects.
Find more about them here: <https://libera.chat/>
If you wish to connect using your preferred client (such as weechat or irssi),
the connection info is as follows:
* Server: `irc.libera.chat`
* Channel: `#libreboot`
* Port (TLS): `6697`
* Port (non-TLS): `6667`
We recommend that you use port `6697` with TLS encryption enabled.
It is recommend that you use SASL for authentication. These pages on the Libera
website tells you how:
* WeeChat SASL guide: <https://libera.chat/guides/weechat>
* Irssi SASL guide: <https://libera.chat/guides/irssi>
* HexChat SASL guide: <https://libera.chat/guides/hexchat>
In general, you should check the documentation provided by your IRC software.
Social media
============
libreboot exists officially on many places.
Mastodon
--------
The founder and lead developer, Leah Rowe, is on Mastodon:
* <https://mas.to/@libreleah>
Leah can also be contacted by this 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/>

72
site/contact.uk.md Normal file
View File

@ -0,0 +1,72 @@
---
title: Зв'язок
x-toc-enable: true
...
**TODO: списки розсилки, сервер mastodon та обліковий запис peertube.**
Підтримка користувачів
============
IRC або Reddit рекомендовані, якщо ви бажаєте попросити про допомогу (найкраще IRC).
Дивіться інформацію нижче щодо IRC та Reddit.
Обговорення розробки
======================
Списки розсилки плануються на майбутнє. Зараз, подивіться нотатки
на [сторінці Git](git.md) для інформації щодо допомоги з розробкою.
На цій сторінці також знаходяться інструкції по відправці патчів (через pull request'и).
Кімната IRC
============
IRC це головний спосіб зв'язку з проектом Libreboot. `#libreboot` на Libera
IRC.
Веб-версія:
<https://web.libera.chat/#libreboot>
Libera є однією з найбільших мереж IRC, використовуємих для проектів вільного програмного
забезпечення. Знайти про них більше можна тут: <https://libera.chat/>
Якщо ви бажаєте під'єднатися за допомогою вашого улюбленного клієнта (такого як weechat або irssi),
інформація для під'єднання наступна:
* Сервер: `irc.libera.chat`
* Канал: `#libreboot`
* Порт (TLS): `6697`
* Порт (не TLS): `6667`
Ми радимо вам використовувати порт `6697` з увімкненим TLS шифруванням.
Рекомендовано використовувати SASL для аутентифікації. Ці сторінки на веб-сайті Libera
пояснять вам як:
* Керівництво WeeChat SASL: <https://libera.chat/guides/weechat>
* Керівництво Irssi SASL: <https://libera.chat/guides/irssi>
* Керівництво HexChat SASL: <https://libera.chat/guides/hexchat>
Взагалі, вам варто перевірити документацію, яка передбачена вашою програмою IRC.
Соціальні мережі
============
Libreboot офіційно існує в багатьох місцях.
Mastodon
--------------------
Засновник та головний розробник, Лія Роу, є в Mastodon:
* <https://mas.to/@libreleah>
Також можливо зв'язатися з Лією за ії електронною адресою:
[leah@libreboot.org](mailto:leah@libreboot.org)
Reddit
------
Найбільше використовується як канал підтримки, та також для оголошення новин:
<https://www.reddit.com/r/libreboot/>

453
site/contrib.md Normal file
View File

@ -0,0 +1,453 @@
---
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.
* 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, 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
Caleb La Grange
---------------
**Secondary developer, number two to Leah.** Caleb is a full time libreboot developer
with a narrower focus. Caleb focuses on several areas of development:
* Build system. Caleb is responsible for improving and fixing the libreboot Make build
system. Specifically: binary blob management, automation, and reproducibility.
* Hardware modification. Caleb has a passion for hardware alteration; soldering,
desoldering, and testing libreboot software on the resulting hardware.
* Board porting. Anything supported in Coreboot can be ported to libreboot, Caleb
will test and port any board he can get his hands on. Additionally, anyone can
contact Caleb to generate libreboot roms for testing on their board.
* Documentation. Caleb actively maintains documentation on the above areas of
interest. Additionally, Caleb is responsible for disassembly guides with his own
pictures and diagrams for several boards.
* User support. Caleb is active on irc and willing to help any user interested in
using libreboot or in need of help.
* Project goals. Caleb collaborates with Leah on determining project goals.
Leah has the final say in every decision.
External projects
=================
Coreboot project
----------------
Without coreboot, the libreboot project simply would not be possible.
The people and companies that work on coreboot are numerous, and they make the
libreboot project what it is. The libreboot project makes heavy use of coreboot, to
provide hardware initialization.
GRUB
--------
GRUB is the bootloader used by libreboot. It goes without saying that the GRUB
developers enable libreboot, through their work.
SeaBIOS
-------
The libreboot firmware provides SeaBIOS as a payload option. SeaBIOS provides a
legacy x86 BIOS implementation.
U-Boot
------
Libreboot uses U-Boot as the coreboot payload on supported ARM Chromebooks.
Contributors in alphabetical order
==================================
Alper Nebi Yasak
----------------
Contributed the build system integration and documentation for using
U-Boot as payload, and initial Libreboot ports of some ARM Chromebooks
based on that.
Alper also does upstream development on U-Boot, e.g. continued an almost
complete port of the `gru-kevin` board and got it merged upstream.
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 (shell 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://untitled.vimuser.org/> (untitled 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 Untitled)
Andrew Robbins
--------------
Worked on large parts of Libreboot's old build system and related documentation.
Andrew joined the Libreboot project as a full time developer during June 2017,
until his departure in March 2021.
I, Leah Rowe, am very grateful to Andrew Robbins for his numerous contributions
over the years.
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 Arthur'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.
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.
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 Serbinenko 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.
Denis was a mentor to Leah Rowe in the early days, when she founded the
Libreboot project. A lot of the 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.
Ferass El Hafidi
--------
Added cstate 3 support on macbook21, enabling higher battery life and cooler
CPU temperatures on idle usage.
Also has a series of extensive improvements to the entire Libreboot system;
for example, Ferass made the entire build system use POSIX `sh`, removing
bashisms that previously plagued it.
This is IRC nick `f_` on Libreboot IRC. Cool guy!
Jeroen Quint
------------
Contributed several fixes to the libreboot documentation, relating to
installing on Arch-based systems with full disk encryption on libreboot
systems.
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 libre 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://web.archive.org/web/20171222063358/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.
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 Libreboot IRC channel, 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 Savannah website were used by
the Libreboot project. 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):
<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
<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 FSF and GNU 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.
Nicholas Chin
-------------
[Ported Dell Latitude E6400 to Libreboot](news/e6400.md).
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.
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.
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.
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 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).
Swiftgeek left the project in March 2021. I, Leah Rowe, wish him all the best
in his endeavours, and I'm very grateful to his numerous contributions over the
years.
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.
Vladimir Serbinenko
-------------------
Ported many of the thinkpads supported in libreboot, to coreboot, and
made many fixes in coreboot which benefited the libreboot project.
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).

449
site/contrib.uk.md Normal file
View File

@ -0,0 +1,449 @@
---
title: Учасники проекту
x-toc-enable: true
...
У цьому списку не обов'язково вказується, хто зараз працює над проектом,
але в ньому вказано людей, які зробили значний внесок у проект.
Якщо ми забули вас тут згадати, повідомте нам, і ми вас додамо. (або якщо
ви не хочете, щоб вас згадували, повідомте нас, і ми видалимо ваш
запис)
Інформацію про те, хто працює над libreboot і як працює проект, можна
знайти на цій сторінці: [who.md](who.md)
Ви можете дізнатися історію проекту libreboot, просто прочитавши цю сторінку.
Тут докладно розповідається про всі основні внески в проект і
загалом про те, як створювався проект (і хто допоміг його створити).
Лія Роу
---------
**Засновник проекту Libreboot, а зараз провідний розробник** Лія
працює над усіма аспектами libreboot, такими як:
* Загальне керівництво. Лія обробляє всі зовнішні внески до libreboot,
переглядає пул реквести, має справу із звітами про помилки, делегує завдання, коли це необхідно
або бажано. Лія контролює серверну інфраструктуру libreboot.org, розміщену
в її лабораторії.
* Лія має останнє слово щодо всіх рішень, беручи внесок через обговорення з
представниками громадськості, переважно на IRC. Лія контролює випуски libreboot
і загалом підтримує проект. Без Лії не було би Libreboot!
* Система збірки (lbmk, скорочення від libreboot Make). Це автоматизована
система збирання, яка лежить в серці libreboot; він завантажує, патчить, налаштовує
та компілює відповідні компоненти, такі як coreboot, GRUB, і генерує образи ROM
libreboot, які ви можете знайти в архівах випусків.
* Апстрім робота над coreboot, коли необхідно (та іншими проектами, які libreboot
використовує). Це також означає роботу з людьми поза межами проекту libreboot,
щоб об'єднати виправлення (між іншим) в апстрім проектах,
які libreboot використовує
* Надання підтримки користувачів на IRC
Калеб Ла Гранж
---------------
**Вторинний розробник, номер два для Лії.** Калеб - розробник libreboot на повний робочий день
з вузьким фокусом. Калеб зосереджується на кількох напрямках розвитку:
* Система побудови. Калеб відповідає за вдосконалення та виправлення системи побудови libreboot Make.
Зокрема, управління бінарними блобами, автоматизація та відтворюваність.
* Апаратна модифікація. Калеб має пристрасть до переробки апаратного забезпечення; паяння,
розпаювання, та тестування libreboot на отриманому обладнанні.
* Перенесення плати. Все, що підтримується в Coreboot, можна перенести на libreboot, Калеб
перевірить і перенесе будь-яку плату, до якої зможе потрапити. Крім того, будь-хто може
зв'язатись з Калебом, щоб створити образи libreboot для тестування на своїй платі.
* Документація. Калеб активно веде документацію щодо зазначених вище сфер
інтересу. Додатково, Калеб відповідає за посібники з розбирання з власними
малюнками та діаграмами для кількох плат.
* Підтримка користувачів. Калеб активний в irc і готовий допомогти будь-якому користувачеві, який зацікавлений в
використанні libreboot або потребує допомоги.
* Цілі проекту. Калеб співпрацює з Лією над визначенням цілей проекту.
Лія має останнє слово в кожному рішенні.
Зовнішні проекти
================
Проект Coreboot
----------------
Без coreboot проект libreboot був би просто неможливий.
Людей і компаній, які працюють над coreboot, багато, і вони роблять
проект libreboot таким, яким він є. Проект libreboot активно використовує coreboot
для ініціалізації обладнання.
GRUB
--------
GRUB - це завантажувач, який використовується libreboot. Само собою зрозуміло, що
розробники GRUB стимулюють libreboot своєю роботою.
SeaBIOS
-------
Прошивка libreboot надає SeaBIOS як опцію корисного навантаження. SeaBIOS забезпечує
застарілу реалізацію BIOS x86.
U-Boot
------
Libreboot використовує U-Boot як корисне навантаження coreboot на ноутбуках
ARM Chromebook з підтримкою coreboot.
Внески в алфавітному порядку
============================
Алісса Розенцвейг
-----------------
Переключила веб-сайт на використання розмітки замість рукописного HTML та користувацького
PHP. **Колишній супроводжувач проекту libreboot (системний адміністратор libreboot.org).**
Алісса написала оригінальний генератор статичних сайтів (скрипти `sh`, що перетворюють
markdown в html, через pandoc) для libreboot.org. Цей генератор статичних сайтів
був значно змінений і відгалужений Лією Роу у формальний проект:
<https://untitled.vimuser.org/> (untitled - це робота Лії, а не Алісси, але вона базується на
оригінальній роботі Аліси над генератором статичних сайтів, який раніше використовував Libreboot;
веб-сайт Libreboot тепер створено за допомогою Untitled)
Альпер Небі Ясак
----------------
Надав інтеграцію системи збірки та документацію для використання
U-Boot в якості корисного навантаження, та початкові порти Libreboot деяких ARM Chromebook
виходячи з того.
Альпер також займається розробкою на U-Boot, напр. продовжив майже завершений
порт плати `gru-kevin` і об'єднав його з апстрімом.
Артур Хейманс
--------------
Об'єднав патч із coreboot у libreboot, дозволяючи режимам живлення C3 та C4
правильно працювати на ноутбуках GM45. Це була давня проблема до внеску
Артура. Артур також виправив розмір відеопам'яті на i945 на системах
GM45, що дозволило максимально розподілити VRAM для вбудованих графічних процесорів
у цих системах, ще одна давня проблема в libreboot.
Артур також працював над системою збірки Libreboot, коли він був учасником
проекту. Він досі працює над coreboot, і Libreboot отримує велику
користь від його роботи. Його внесок у проект coreboot і Libreboot
неоціненний.
Володимир Сербіненко
-------------------
Перенес багато thinkpad, які підтримуються в libreboot, на coreboot, а
також зробив багато виправлень у coreboot, які принесли користь проекту libreboot.
Володимир написав багато вихідного коду ініціалізації відео, який використовується різними
платформами Intel у Libreboot, під час прошивки (зараз переписаний
іншими в Ada, для libgfxinit в coreboot, але спочатку він був написаний на
C і включений безпосередньо в coreboot; libgfxinit є субмодуль третьої сторони).
Демієн Замміт
-------------
Підтримує порт coreboot Gigabyte GA-G41M-ES2L, інтегрований у
libreboot. Також працює над іншим апаратним забезпеченням на користь
проекту libreboot.
Демієн не працював безпосередньо над самим Libreboot, але він багато працював з
Лією Роу, інтегруючи патчі та нові порти плати в Libreboot на основі
попередньої роботи Демієна над coreboot.
Денис Каріклі
-------------
На основі роботи, виконаної Пітером Стюджем, Володимиром Сербіненко та іншими
в проекті coreboot, вдалось налагодити нативну ініціалізацію графіки для роботи
на ThinkPad X60, що дозволяє підтримувати її в libreboot. Денис дав
багато порад і допоміг створити проект libreboot.
Денис був наставником Лії Роу в ранні дні, коли вона заснувала проект
Libreboot. Багато прийнятих рішень, особливо щодо системи збірки
Libreboot (lbmk), були натхненні розмовами з Денисом.
Денис навчив Лію про регістри, які використовуються графічним процесором Intel для керування підсвічуванням.
В ранні дні, ноутбуки ThinkPad X60 та T60 в Libreboot не мали працюючого
контроля підсвічуванням, тому яскравість завжди була 100%. За допомогою Дениса,
Лія змогла налаштувати керування підсвічуванням шляхом зворотньої розробки
правильних значень для запису в ці регістри. На основі цього в coreboot
було написано просте виправлення; однак виправлення перезаписувало безпосередньо регістр
і не працювало з елементами керування яскравістю на основі ACPI. Інші в coreboot
пізніше вдосконалили його, змусивши елементи керування підсвічуванням на основі ACPI працювати належним чином, на основі цієї
попередньої роботи.
Джерун Квінт
------------
Додав кілька виправлень до документації libreboot, пов'язаної зі
встановленням Arch з повним дисковим шифруванням у системах libreboot.
Джошуа Гей
----------
Джошуа колишній співробітник FSF.
Джошуа допоміг із раннім заснуванням проекту Libreboot, будучи
(на той час) менеджером з ліцензування та відповідності FSF. Його роботою було
переглядати продукти, надіслані до FSF для перевірки; FSF має програму
сертифікації, під назвою *Поважає Вашу Свободу* (Respects Your Freedom), за якою FSF рекламуватиме
продукти вашої компанії, якщо вони постачаються з усім вільним програмним
забезпеченням.
Я, Лія Роу, спочатку просто продавала ноутбуки ThinkPad X60 із звичайним
coreboot, і це включало оновлення мікрокоду ЦП. У той час
я не дуже про це думала. Джошуа зв'язався зі мною, в своїх повноваженнях FSF, і спитав,
чи зацікавить мене програма RYF FSF; Я була дуже здивована, що FSF
сприйме мене серйозно, і я сказала так. Саме з цього почалася рання робота
над Libreboot. Джошуа показав мені всі проблеми з моїми продуктами, і з
цього, рішення було очевидним:
Необхідно, щоб існував проект із повністю вільною версією coreboot без будь-яких
бінарних блобів. У той час (і це актуально й сьогодні) coreboot не був
повністю вільним програмним забезпеченням і за замовчуванням постачався з двійковими блобами. Зокрема,
оновлення мікрокоду ЦП включено за замовчуванням на всіх машинах x86. Працюючи
з Джошуа, я створила повністю вільну версію coreboot.
Спочатку він не називався Libreboot, і робота була призначена виключно для моєї
компанії (на той час вона називалася Gluglug), яку просувала FSF.
Джошуа використовував свої медійні зв'язки в FSF, щоб активно рекламувати мою роботу, і
13 грудня 2013 року народився проект Libreboot (але не названий так).
Джошуа переконався, щоб всі знали, що я роблю!
Через кілька місяців було створено назву *Libreboot* і зареєстровано доменне ім'я
*libreboot.org*. У цей момент офіційно народився проект Libreboot (на початку
2014 року). Знову Джошуа надав всю можливу допомогу,
активно просуваючи проект, і навіть написав цю статтю на веб-сайті FSF
оголосивши про це:
<https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
Ендрю Роббінс
--------------
Працював над великими частинами старої системи збірки Libreboot і пов'язаною документацією.
Ендрю приєднався до проекту Libreboot як штатний розробник у червні 2017,
до моменту свого відходу в березні 2021 року.
Я, Лія Роу, дуже вдячна Ендрю Роббінсу за його численні внески
протягом багатьох років.
Клеменс Нанні
-------------
Внесено багато виправлень і покращень у конфігурацію GRUB, яка використовується в
libreboot, а також кілька змін у системі збірки.
Ліза Марі Магінніс
-------------------
Ліза - колишній системний адміністратор Free Software Foundation. На перших днях
проекту вона давала Лії багато технічних порад. Спочатку вона створила
IRC-канал Libreboot, коли Лія не знала, як користуватися
IRC, а також передала +F статус засновника для каналу. Як системний
адміністратор FSF, роботою Лізи було підтримувати велику частину інфраструктури,
яку використовує Libreboot; на той час списки розсилки на веб-сайті Savannah
використовувалися проектом Libreboot. Коли Пол Коціалковскі був
учасником проекту в 2016 році, вона допомогла йому отримати допомогу від FSF; на той час він був
керівником проекту Replicant, який фінансував FSF, і FSF дозволив
йому використати частину цього фінансування для його роботи над Libreboot, завдяки Лізи
підтримці, коли вона працювала у FSF.
Ліза також втрутилася, коли Лія Роу пропустила виступ на LibrePlanet 2016. Лія мала
виступити з доповіддю про Libreboot, але не з'явилася вчасно. Ліза разом
із Патріком Макдермоттом (колишнім розробником Libreboot, який був присутній
на тій конференції) виступили замість Лії. Розмова ніколи не була записана, але
Фонд вільного програмного забезпечення має ці фотографії цієї розмови на веб-сайті LibrePlanet
(жінка з блакитним волоссям - Ліза, а довговолосий хлопець із вусами -
Патрік):
<http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
<http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
Цікавий факт: Патрік також є провідним розробником ProteanOS, проекту вбудованої
ОС, схваленого FSF: <http://proteanos.com/> (використовує BusyBox і Linux-libre)
Лія Роу провела *2* семінари LibrePlanet; один у 2015 році та інший у 2016 році,
відвідуючи Бостон, Массачусетс, США в обох випадках для участі в цих конференціях. Ці
семінари стосувалися встановлення Libreboot. Люди приходили на обидва семінари, щоб
встановити Libreboot на свої комп'ютери. Як системний адміністратор FSF, на той час,
Ліза забезпечила всю інфраструктуру та обладнання, яке використовувалося на цих семінарах.
Без її допомоги ці майстер-класи були б неможливими.
Коли материнська плата ASUS KGPE-D16 (серверна плата високого класу) була перенесена на Libreboot,
Лія, працюючи з Тімоті Пірсоном (той, хто її переніс),
приблизно в середині 2016 року поділилася з Лізою виправленнями, в основному виправленнями raminit, щоб отримати плату, яка працює в офісах FSF. Ця робота
зрештою призвела до чудового досягнення:
Веб-сайти FSF і GNU тепер працюють на, з встановленим Libreboot,
заснованих на ASUS KGPE-D16 серверах, на повністю вільному GNU+Linux дистрибутиві. Це
означає, що FSF тепер має повну свободу програмного забезпечення для своєї
інфраструктури хостингу.
FSF також надає доступ до цієї інфраструктури для багатьох інших проектів
(крім проектів GNU); наприклад, Trisquel використовує D16, наданий FSF
для свого сервера розробки, який використовується для створення випусків Trisquel і тестування
змін у дистрибутиві Trisquel GNU+Linux. Trisquel - це повністю вільний
GNU+Linux дистрибутив, активно просуваний FSF.
Ліза була сильною прихильницею Libreboot на перших днях проекту,
і її внесок був неоціненним. Я, Лія Роу, у боргу перед нею.
Маркус Мьоллер
--------------
Зробив логотип libreboot.
Nicholas Chin
-------------
[Ported Dell Latitude E6400 to Libreboot](news/e6400.md).
Патрік "П. Дж." Макдермотт
---------------------------
Патрік також провів багато досліджень і написав розділ поширених запитань libreboot,
пов'язаний із [Intel Management Engine](../faq.md#intelme), а також зробив кілька покращень у
системі збірки libreboot. **Колишній супроводжувач проекту
libreboot.**
У 2016 році Лія Роу провела семінар зі встановлення Libreboot на конференції FSF
LibrePlanet. Працюючи разом з Лією, Патрік допомагав вести семінар
та допомагав установлювати Libreboot на комп'ютери людей.
Пітер Стюдж
-----------
Допоміг написати [розділ поширених запитань про DMA](../faq.md#hddssd-firmware), та надав
загальні поради на перших днях проекту. У той час Пітер був розробником coreboot
і головним розробником проекту *libusb* (який flashrom
активно використовує).
Пітер також написав утиліту *bucts*, яка використовується для встановлення біта Top Swap
(TS) для керування резервним копіюванням (BUC) на ноутбуках i945, таких як ThinkPad X60/T60, яка є корисною для
обхідного шляху для прошивки Libreboot без використання зовнішнього обладнання; на цій машині,
з Lenovo BIOS, можна перепрошити все, крім головного завантажувального
блоку, але платформи Intel мають 2 завантажувальні блоки, і ви вказуєте, який із них
використовувати, встановленням біта TS. Потім ви завантажуєтеся лише з одним прошитим завантажувальним блоком
(завантажувальним блоком проекту coreboot на цій машині), а потім скидаєте
bucts перед повторною прошивкою ROM, щоб прошити основний завантажувальний блок. Libreboot
розміщує копію його роботи, оскільки його веб-сайт, на якому розміщено bucts,
більше не відповідає.
Пол Коціалковський
-----------------
Переніс ноутбуки Chromebook на основі ARM (Rockchip RK3288 SoC) до
libreboot. Також один із головних розробників [Replicant](http://www.replicant.us/).
Пол Менцель
-----------
Дослідив та виправив помилку в coreboot на ThinkPad X60/T60, яку виявляло
ядро Linux 3.12 і новіших версій, через яку прискорення 3D не
працювало, а відео загалом ставало нестабільним. Проблема полягала в тому, що
coreboot під час ініціалізації відеочіпсета Intel, відображав *GTT Stolen Memory* в
не тому місці, оскільки код базувався на коді ядра, а в ядрі Linux
була така сама помилка. Коли Linux це виправив, він виявив ту саму помилку в coreboot.
Пол працював над цим із Libreboot,
періодично надсилаючи патчі для тестування, доки помилку не було виправлено
в coreboot, а потім допоміг ій інтегрувати виправлення в libreboot.
Стів Шентон
-------------
Стів виконав першу роботу зі зворотньої розробки Intel Flash Descriptor, який використовується
на машинах ICH9M, таких як ThinkPad X200. Він створив структуру C, що визначає (використовуючи
бітові поля в C) цю область дескриптора. За допомогою деяких хитрих трюків він зміг
виявити існування біта в дескрипторі для *вимкнення* Intel ME
(management engine) на цих платформах.
Його початкове підтвердження концепції визначило лише дескриптор, і зробило би це:
* Читання дескриптора за замовчуванням і регіонів GbE з ROM Lenovo X200 (прошивка
за замовчуванням, не coreboot)
* Вимкнення ME, встановивши 2 біти в дескрипторі
* Вимкнення регіона ME
* Переміщення дескриптора+GbE (загалом 12КБ) поруч
* Виділення решти флеш-пам'яті для регіону BIOS
* На основі цього створено 12КБ регіон дескриптор+область GBE для вставки
в образ ROM coreboot.
У перші дні, до того, як Libreboot підтримував платформи GM45+ICH9M, такі як
ThinkPad X200/T400, ви могли використовувати ці машини, але щоб уникнути
Intel ME, вам доводилося виконувати прошивку без області дескриптора. У ті часи це працювало нормально,
тому що ME обробляв лише TPM та AMT на цих машинах, і система
працювала нормально, але Intel Flash Descriptor також обробляє область Intel GbE NVM
у флеш-пам'яті, яка використовується для інтерфейсу Intel Gigabit Ethernet.
Отже, ви або мали Intel ME, або не підтримували ethernet. Стів зрозумів, як
вимкнути Intel ME за допомогою 2 бітів перемикання в дескрипторі, а також як видалити область
Intel ME з флеш-пам'яті.
Ґрунтуючись на його дослідженні, я, Лія Роу, працюючи разом зі Стівом, також виконала зворотню розробку
області Intel GbE NVM (енергонезалежна пам'ять) у
завантажувальній флеш-пам'яті. Цей регіон визначає параметри конфігурації для вбудованої мережевої карти Intel
GbE, якщо присутня.
На основі цього я змогла взяти початкове підтвердження концепції та написати
утиліту `ich9gen`, яка генерує Intel Flash Descriptor та регіон GbE NVM,
з нуля, без визначення регіону Intel ME. Саме цей інструмент,
інструмент `ich9gen`, використовує Libreboot для надання образів ROM для GM45+ICH9M
платформ (таких як ThinkPad X200/T400/T500/W500), із повнофункціональним
дескриптором та функціональним Gigabit Ethernet, але *без* необхідності мікропрограми Intel
Management Engine (ME), що робить ці машини *вільними* (ME
повністю вимкнено, коли ви використовуєте образ дескриптора+gbe, створене `ich9gen`).
З *моїм* інструментом `ich9gen` (інструмент Стіва називався `ich9deblob`), вам більше
не потрібен був дамп оригінальної мікропрограми Lenovo BIOS! Я не могла би написати цей інструмент
без первинного підтвердження концепції Стіва. Я працювала з ним
протягом багатьох місяців. Вся GM45+ICH9M підтримка (X200, T400 і так далі) в
Libreboot стала можливою завдяки його роботі у 2014 році.
Тімоті Пірсон
---------------
Перенес плату ASUS KGPE-D16 до coreboot для компанії Raptor
Engineering, генеральним директором якої є Тімоті.
Тімоті підтримує цей код у coreboot, допомогаючи проекту,
з його інтеграцією з libreboot. Контактні
дані цієї людини є на сайті raptor.
**Підтримку D16 було припинено 19 листопада 2022 року. Ви все ще можете використовувати
старіші версії Libreboot, і старіші випуски.**
Swift Geek
----------
Додав патч для ich9gen для створення дескрипторів розміром 16MiB.
Після цього Swift Geek повільно почав долучатися, поки не став розробником на повний
робочий день. Внески Swift Geek насправді ніколи не були у формі *коду*,
але те, що йому не вистачало в коді, він компенсував чудовою підтримкою як для користувачів,
так і для інших розробників, допомагаючи іншим дізнатися більше про технології на
низькому рівні.
Коли Swift Geek був учасником проекту, його роль здебільшого полягала в
наданні підтримки користувачам (на каналі IRC) і проведенні досліджень. Swift Geek знає
багато про апаратне забезпечення. Swift Geek також зробив деяку апстрім розробку GRUB.
Swift Geek неодноразово надавав технічні поради Лії Роу
та допоміг їй покращити її навички паяння, а також навчив її
деяким навичкам ремонту, до того моменту, коли вона тепер може виправляти більшість несправностей
на материнських платах ThinkPad (під час перегляду схем та бордв'ю).
Swiftgeek залишив проект у березні 2021 року. Я, Лія Роу, бажаю його всього найкращого в його
починаннях і дуже вдячна за його численні внески протягом багатьох
років.
vitali64
--------
Додав підтримку cstate 3 на macbook21, що забезпечує тривалий термін служби батареї
та нижчу температуру процесора під час простою. vitali64 на irc

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

@ -0,0 +1,171 @@
---
title: BSD operating systems
x-toc-enable: true
...
Guide last updated on 16 November 2022.
NOTE: This guide pertains to x86 hosts, and does not cover supported CrOS/ARM
chromebooks. For ARM targets, you should refer to u-boot documentation.
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.
Kernel Mode Setting
===================
Your BSD system *must* support Kernel Mode Setting for your graphics
device (most of them do nowadays). The reasons will become apparent, as
you read this article.
Boot BSD, using SeaBIOS
=======================
On x86 platforms, Libreboot provides the choice of GRUB and/or
SeaBIOS payload. GRUB can technically boot BSD kernels, but the code is
poorly maintained and unreliable for this use-case scenario; on BIOS systems,
GRUB can chainload BSD bootloaders, but on bare metal (as coreboot payload),
GRUB can only chainload other coreboot payloads or boot Linux/BSD kernels
directly (but direct booting is only really reliable for Linux, in GRUB).
It is recommended that you boot in text mode, with SeaBIOS. You can literally
just follow the official installation guides for your BSD system, whether it
be FreeBSD, OpenBSD or others.
If you don't plan to set up Xorg/Wayland, then that's all you really need to
do. For example, you might want to run a headless server, in which case you
probably don't mind running in text mode all the time.
OpenBSD and corebootfb
----------------------
It's still recommended to use SeaBIOS in text mode, but OpenBSD specifically
can work with SeaBIOS booting in a coreboot framebuffer, with SeaVGABIOS. In
Libreboot ROM images, this would be SeaBIOS images with `corebootfb` in the
file name.
Make sure to select MBR-style partitioning on the installer, and it will
Just Work.
If you're using the GRUB payload but SeaBIOS is available in the boot menu,
you can just select SeaBIOS at said menu, and OpenBSD will work fine.
FreeBSD and corebootfb
----------------------
Assumed broken, so please ensure that you boot with SeaBIOS payload in text
mode (lbmk ROM images with `txtmode` in the file name, not `corebootfb`).
Warnings for X11 users
----------------------
One important peculiarity of most libreboot and libreboot systems is: VGA mode
support exists, if booting with corebootfb (coreboot's own framebuffer) and
the SeaVGABIOS option ROM used in the SeaBIOS payload; however, the ability
to switch modes is not present, which means you can't switch to text mode
either.
Coreboot can start in framebuffer (corebootfb) or INT10H text mode, and it
stays in whatever mode was set, unless KMS is used to change the mode. It
should be noted that the coreboot framebuffer is not a VGA mode, but instead
coreboot implements minimal drivers for hardware that it supports, providing
a framebuffer directly in memory, which software (such as GRUB) can simply
use.
The BSD bootloaders on x86, in BIOS systems, typically expect text mode
startup. It is usually possible to set the console to higher VGA modes,
on most systems, but not on most coreboot systems with native video
initialisation used, due to the quirks already described. If you see any
documentation (in BSD land) pertaining to VESA modes, ignore it entirely;
unless you're using the proprietary VGA ROM for your device, it won't work,
and Libreboot doesn't distribute these (instead, coreboot's own video
initialisation is used where possible, or a headless SeaBIOS payload setup
is provided, where you would either run it headless or install a graphics
card).
Now, this would otherwise mean: no X11/Wayland. If you start in corebootfb
mode with SeaVGABIOS, you won't get a display in BSD bootloaders, and if you
boot in text mode, you can't set VESA modes from BSD. However, you're in luck:
At least OpenBSD and FreeBSD (possibly others) all have excellent KMS
support nowadays; short for `Kernel Mode Setting`. This avoids the inefficiency
of BIOS/UEFI methods, by having the kernel set modes directly. It is based on
KMS drivers that the BSD projects ported over from the Linux kernel. With this,
you can use X11/Wayland in FreeBSD (and just X11 in OpenBSD, for now).
For example: on FreeBSD, you can install `graphics/drm-kmod` as a package
or from ports, and (for Intel GPUs) do this:
sysrc kld_list+="i915kms"
This creates the following entry in `/etc/rc.conf`:
kld_list="i915kms"
On FreeBSD it is also recommended that you switch to KMS on the console/TTY;
add this to `/boot/loader.conf` so that you can still use the console after
terminating Xorg:
kern.vty=vt
You should not rely on the above instruction (for FreeBSD), because the exact
step might change, and it does not go into full detail either. Refer to the
documentation provided by your system, to know how KMS is configured.
ALWAYS READ THE MANUAL
----------------------
All of the BSDs have *excellent* documentation; it's one of the defining
characteristics, versus typical Linux distros.
Aside from this quirk in coreboot, regarding *BIOS* video modes, the BSDs
otherwise work in exactly the same way as you would expect, and you can
follow along to their official documentation without much fuss.
No specific or detailed guides will be provided here, because SeaBIOS is
fairly self-explanatory; you can otherwise refer to the SeaBIOS
documentation.
If you're flashing a ROM for a machine where `seabios_withgrub`
and `seabios_grubfirst` ROMs are available, choose `seabios_withgrub`.
DO NOT USE ROM IMAGES WITH `seabios_grubfirst` IN THE FILE NAME! These were
present in older Libreboot releases, and supported in previous revisions
of the build system, but they did not work for the intended purpose. More
info is written on the [Libreboot installation guide](../install/). ROM
images with `seabios_grubfirst` in the filename will NOT be included in
future Libreboot releases.
Dubious mention: Tianocore
--------------------------
Tianocore is extremely bloated, and unauditable, so it is not included
in Libreboot firmware, but it is the reference UEFI implementation by
Intel and contributors. It can boot most BSD systems very well.
More robust ways to provide UEFI services in Libreboot are to be investigated.
Tianocore integration will not be provided officially, in any current or future
releases of Libreboot.
Desktop users
-------------
Desktop users on Libreboot should just install a graphics card,
and again boot with SeaBIOS in text mode; however, when you do this,
SeaBIOS will execute the VGA option ROM on the card which will provide
early video initialisation instead of coreboot's initialisation, and that
VGA ROM will usually implement full INT10H modes, including the ability
to set modes in the BIOS (using interrupts), in which case you don't
need to worry about Kernel Mode Setting, but you should still use KMS
anyway.
The reason to use KMS is because it's more efficient. The INT10H service can
only be called in Real Mode or Virtual 8086 mode; v8086 is unavailable in
long mode (x86\_64) and switching into Real Mode just to set VGA modes is
extremely expensive computationally speaking. This is why modern kernels
(Linux and BSD one) do mode setting themselves.
You can learn more about INT10H text/VGA modes here:
<https://en.wikipedia.org/wiki/INT_10H>

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

@ -0,0 +1,284 @@
---
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
======
Python2 is unused by lbmk or anything that it pulls down as modules. You
should ensure that the `python` command runs python 3, on your system.
Make
========
libreboot Make includes a file called `Makefile`. You can still use
the `lbmk` build system directly, or you can use 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, Arch, etc) you can do this:
sudo make install-dependencies-ubuntu
One exists specifically for Debian:
sudo make install-dependencies-debian
Another exists for Arch:
sudo make install-dependencies-arch
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 boot roms x200_8mb
You can specify more than one argument:
./build boot 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 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:
sudo ./build dependencies ubuntu2004
Separate scripts also exist:
sudo ./build dependencies debian
sudo ./build dependencies arch
sudo ./build dependencies void
Technically, any 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 boot roms
or even just build specific ROM images, e.g.:
./build boot roms x60
If you wish to build payloads, you can also do that. For example:
./build payload grub
./build payload seabios
./build payload u-boot qemu_x86_12mb
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 boot 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
./download u-boot
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
Each board has its own U-Boot build configuration in `lbmk` under
`resources/u-boot`. To build U-Boot payloads, you need to specify the
target board and maybe a cross compiler for its CPU architecture. These
are handled automatically when building ROM images, but for example:
./build payload u-boot qemu_x86_12mb # on x86 hosts
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
The build-payload command is is a prerequsite for building ROM images.
Fifth, build the ROMs!
----------------------
Run this command:
./build boot 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 boot 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/

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

@ -0,0 +1,284 @@
---
title: Побудова з джерельного коду
x-toc-enable: true
...
Система побудови libreboot, називається `lbmk`, скорочення від `Libreboot Make`, і цей
документ описує те, як використовувати її. З цим керівництвом ви можете узнати те, як побудувати
libreboot з доступного джерельного коду.
Ця версія, якщо розміщена наживо на libreboot.org, передбачає, що ви використовуєте
сховище git `lbmk`, яке
ви можете завантажити, використовуючи інструкції на [сторінці огляду коду](../../git.uk.md).
Якщо ви використовуєте архів випуску libreboot, будь ласка, зверніться до
документації, включеної до *того* випуску. Випуски libreboot розраховані тільки,
як *знімки*, не для розробки. Для належної розробки ви маєте завжди
працювати безпосередньо в сховищі git libreboot.
Наступний документ описує те, як працює `lbmk`, і як ви можете робити зміни
до нього: [керівництво обслуговування libreboot](../maintain/)
Git
===
Система побудови Libreboot використовує Git, обширно. Ви маєте виконати кроки
знизу, *навіть, якщо ви використовуєте архів випуску*.
Перед тим, як вам використовувати систему побудови, будь ласка, знайте: система побудови, сама по собі,
використовує Git обширно, коли завантажує програмне забезпечення, таке як coreboot, та проводить застосування виправлень.
Ви маєте переконатись в тому, щоб ініціалізувати ваш Git належним чином, перед тим, як почати, або інакше
система побудови не буде працювати належно. Зробіть це:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Змініть ім'я та адресу електронної пошти на будь-яку, що забажаєте, коли робите це.
Ви також можете захотіти прослідувати більшій кількості етапів тут:
<https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup>
Python
======
Python2 не використовується lbmk або будь-чим, що завантажується в якості модулів. Ви
маєте переконатись, що команда `python` виконує python 3 на вашій системі.
Make
========
libreboot Make включає файл, який названо `Makefile`. Ви досі можете
використовувати систему побудови `lbmk` безпосередньо, або ви можете використовувати Make. `Makefile`
просто виконує команди `lbmk`. Однак, використання `lbmk` безпосередньо запропонує вам
набагато більше гнучкості; наприклад, Makefile наразі не може побудувати один
образ ROM (він лише будує всі з них, для всіх плат).
Ви мусите переконатись, що всі залежності побудови встановлено. Якщо ви використовуєте
Ubuntu або подібний дистрибутив (Debian, Arch і тому подібні), можете виконати це:
sudo make install-dependencies-ubuntu
Існує конкретно для Debian:
sudo make install-dependencies-debian
Інша існує для Arch:
sudo make install-dependencies-arch
Тепер, просто побудуйте образи coreboot подібним чином:
make
Ця єдина команда побудує образи ROM для *кожної* плати, інтегрованої до
libreboot. Якщо ви тільки хочете побудувати обмежену вибірку, можете використовувати `lbmk` безпосередньо:
./build boot roms x200_8mb
Ви можете вказати більше одного аргумента:
./build boot roms x200_8mb x60
Образи ROM з'явяться під щойно створеною директорією `bin/` в системі побудови.
Для інших команд просто прочитайте `Makefile` в своєму улюбленому текстовому редакторі.
`Makefile` є простим, тому що він виконує виключно команди `lbmk`, таким чином дуже
просто знати те, які команди є в доступності, просто читаючи його.
Стандартна команда `clean` доступна (чистить всі модулі, окрім `crossgcc`):
make clean
Щоб почистити ваші побудови `crossgcc`:
make crossgcc-clean
Для побудови архівів випуску:
make release
Побудова без використання Make
============================
`Makefile` включено лише для *сумісності*, щоб якщо хтось
інстиктивно пише `make`, то було отримано результат.
Фактична розробка/тестування завжди виконується безпосередньо за допомогою `lbmk`, і це також
стосується збирання з джерельного коду. Ось кілька інструкцій, щоб
почати:
Спочатку встановіть залежності побудови
---------------------------------
libreboot включає сценарій, який автоматично встановлює apt-get залежності
в Ubuntu 20.04:
sudo ./build dependencies ubuntu2004
Окремі сценарії також існують:
sudo ./build dependencies debian
sudo ./build dependencies arch
sudo ./build dependencies void
Технічно, будь-який дистрибутив Linux може бути використано для побудови libreboot.
Однак, вам потрібно буде написано свій власний сценарій для встановлення залежностей
побудови.
libreboot Make (lbmk) автоматично виконує всі необхідні команди; наприклад,
`./build payload grub` автоматично виконає `./build module grub`,
якщо затребувані утиліти для GRUB не збудовано, для виготовлення корисних навантажень.
В якості результату, ви тепер можете (після встановлення правильних залежностей побудови) виконати
лише одну команду, з свіжого Git clone, для побудови образів ROM:
./build boot roms
або навіть побудувати конкретні образи ROM, такі як:
./build boot roms x60
Якщо ви бажаєте побудувати корисні навантаження, можете зробити це. Наприклад:
./build payload grub
./build payload seabios
./build payload u-boot qemu_x86_12mb
Попередні кроки буде виконано автоматично. Однак, ви можете *досі* виконати
окремі частини системи побудови власноруч, якщо виберете. Це може бути
вигідно, коли ви робите зміни, та бажаєте протестувати конкретну частину
lbmk.
Отже, якщо ви лише хочете побудувати образи ROM, просто зробіть наведене вище. В іншому випадку,
будь ласка, продовжіть читати!
Друге, завантажити всі програмні компоненти, які вимагаються
--------------------------------------------------------
Якщо ви не виконали просто `./build boot roms` (з або без надлишкових
аргументів), ви все одно можете виконати залишок процесу побудови власноруч. Читайте
далі! Ви можете прочитати про всі доступні сценарії в `lbmk`, читаючи
[керівництво обслуговування libreboot](../maintain/); lbmk розроблено бути модулярним,
що означає те, що кожен сценарій *може* бути використано самостійно (якщо це не є правдою, для
будь-якого сценарія, це є помилкою, яка має бути виправлена).
Це настільки просто, як це:
./download all
Вищезазначена команда завантажує всі модулі, які означено в системі побудови libreboot.
Однак, ви можете завантажити модулі індивідуально.
Ця команда показує вам список доступних модулів:
./download list
Приклад завантаження індивідуального модуля:
./download coreboot
./download seabios
./download grub
./download flashrom
./download u-boot
Третє, побудова кожного з модулів:
--------------------------------
Побудова модуля означає, що він має вже бути завантаженим.
В цей момент, система побудови не виконує автоматично кроки передумови,
такі як цей, тому ви мусите перевірити це власноруч.
Знову, дуже просто:
./build module all
Це будує кожен модуль, означений в системі побудови libreboot, але ви можете
будувати модулі індивідуально.
Наступна команда перелічує доступні модулі:
./build module list
Приклад побудови конкретних модулів:
./build module grub
./build module seabios
./build module flashrom
Команди доступні для *очищення* модуля, які, по суті, виконують make-clean.
Ви можете перелічити ці команди:
./build clean list
Видаліть всі модулі таким чином:
./build clean all
Приклад видалення конкретних модулів:
./build clean grub
./build clean cbutils
Четверте, побудуйте всі корисні навантаження:
---------------------------------
Дуже просто:
./build payload all
Ви можете перелічити доступні корисні навантаження таким чином:
./build payload list
Приклад побудови конкретних корисних навантажень:
./build payload grub
./build payload seabios
Кожна плата має свою власну конфігурацію побудови U-Boot в `lbmk` під
`resources/u-boot`. Для побудови корисних навантажень U-Boot, вам потрібно вказати
цільову плату і мабуть крос-компілятор для її архітектури ЦП. Вони
керуються автоматично під час побудови образів ROM, але для прикладу:
./build payload u-boot qemu_x86_12mb # на хостах x86
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
Команда build-payload є попередньою умовою для побудови образів ROM.
П'яте, побудуйте ROM!
----------------------
Виконайте цю команду:
./build boot roms
Кожна плата має свою власну конфігурацію в `lbmk` під `resources/coreboot/`,
яка вказує, які корисні навантаження підтримуються.
За замовчуванням, всі образи ROM будуються, для всіх плат. Якщо ви бажаєте побудувати лише
конкретну плату, ви можете вказати назву плати, засновану на імені директорії
для неї під `resources/coreboot/`. Наприклад:
./build boot roms x60
Імена плат, як вище, такі самі, як імена директорій для кожної плати,
під `resources/coreboot/` в системі побудови.
Ось так!
Якщо все пройшло добре, образи ROM мають бути доступними вам під bin/

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 already has excellent
documentation, but there are aspects of libreboot that deserve special
treatment. libreboot provides the option to boot GRUB directly, running on
bare metal (instead of using BIOS or UEFI services).
[The Linux section](../linux/) also has libreboot-specific guides for
dealing with Linux distributions when using 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 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)

21
site/docs/hardware/acer_g43t-am3.md Normal file
View File

@ -0,0 +1,21 @@
---
title: Acer G43T-AM3 notes
x-toc-enable: true
...
This is similar to Gigabyte GA-G41M-ES2L but uses an Intel NIC rather than
Realtek. Some problems with Linux on this NIC, on this board, with Libreboot,
were observed; see:
<https://notabug.org/libreboot/lbmk/issues/125>
That page (on notabug) has some notes about workarounds. It links to this:
<https://superuser.com/questions/1104537/how-to-repair-the-checksum-of-the-non-volatile-memory-nvm-of-intel-ethernet-co/1106641#1106641>
This page has some guidance on how to either correct the checksum (in GbE
config) or skip checksum validation in Linux, to get the onboard NIC working.
Although it's talking about different hardware, the steps should be the same.
TODO: factory BIOS on this board works fine with the onboard NIC. study what
that is doing

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

@ -0,0 +1,9 @@
---
title: ASUS Chromebook C201
x-toc-enable: true
...
This page is absolete. Refer to these pages instead:
* [C201 flashing instructions](../install/c201.md)
* [Chromebook flashing instructions](../install/chromebooks.md)

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

@ -0,0 +1,61 @@
---
title: Intel D510MO and D410PT desktop boards
...
<div class="specs">
<center>
![Intel D510MO]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Intel |
| **Name** | D510MO/D410PT |
| **Released** | 2010 |
| **Chipset** | Intel NM10 Express (Mount Olive) |
| **CPU** | Intel Atom |
| **Graphics** | Integrated |
| **Display** | None. |
| **Memory** | Up to 4GB |
| **Architecture** | x86_64 |
| **Original boot firmware** | Intel BIOS |
| **Intel ME/AMD PSP** | Not present. |
| **Flash chip** | ? |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | - |
| **Audio** | W+ |
| **RAM Init** | P+ |
| **External output** | P+ |
| **Display brightness** | - |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad 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 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)

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

@ -0,0 +1,124 @@
---
title: Intel D945GCLF desktop board
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="D945GCLF" class="p" src="https://av.libreboot.org/d945gclf/d945gclf.jpg" /><span class="f"><img src="https://av.libreboot.org/d945gclf/d945gclf.jpg" /></span>
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Intel |
| **Name** | D945GCLF/D945GCLF2D |
| **Released** | 2008 |
| **Chipset** | Intel Calistoga 945GC |
| **CPU** | Intel Atom |
| **Graphics** | ? |
| **Display** | None. |
| **Memory** | Up to 2GB |
| **Architecture** | x86_64 |
| **Original boot firmware** | Intel BIOS |
| **Intel ME/AMD PSP** | Not present. |
| **Flash chip** | SOIC-8 512KiB |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | | Notes |
|----------------|---------------------------------------|-------|
| **Internal flashing with original boot firmware** | N | |
| **Display** | - | |
| **Audio** | W+ | |
| **RAM Init** | W+ | |
| **External output** | W+ | |
| **Display brightness** | - | |
| ***Payloads supported*** | |
|---------------------------|--------------|
| **GRUB** | Doesn't work |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Doesn't work |
</div>
If you just want flashing instructions, go to
[../install/d945gclf.md](../install/d945gclf.md)
D945GCLF2D also reported working by a user.
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 completely 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.

116
site/docs/hardware/e6400.md Normal file
View File

@ -0,0 +1,116 @@
---
title: Dell Latitude E6400
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="Dell Latitude E6400" class="p" src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400-seabios.jpg" /></span> <img tabindex=1 alt="Dell Latitude E6400 XFR" class="p" style="max-width:24em" src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /><span class="f"><img src="https://av.libreboot.org/e6400/e6400xfr-seabios.jpg" /></span>
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Dell |
| **Name** | Latitude E6400 |
| **Variants** | E6400, E6400 XFR and E6400 ATG are supported |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45(Intel GPU) |
| **CPU** | Intel Core 2 Duo (Penryn family). A Quad-core
mod exists, replacing the Core 2 Duo with a Core Quad |
| **Graphics** | Intel GMA 4500MHD |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | 2 or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
| **EC** | SMSC MEC5035 with proprietary firmware |
| **Original boot firmware** | Dell BIOS |
| **Intel ME/AMD PSP** | Present. Can be completely disabled. |
| **Flash chip** | SOIC-8 4MiB or 2MiB+4MiB |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|---------------------------------------------------|----|
| **Internal flashing with original boot firmware** | W+ |
| **Display (Intel GPU)** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Introduction
============
Known supported variants: E6400, E6400 XFR and E6400 ATG.
ONLY the Intel GPU variants are supported, at present. The Nvidia ones are
not compatible, with this censored version of Libreboot.
**To install Libreboot, see: [E6400 installation
instructions](../install/e6400.md)**
ROM images for Dell Latitude E6400 are available for flashing in Libreboot
releases, or you can compile a ROM image for installation via
lbmk, see: [build instructions](../build/)
There are two possible flash chip sizes for the E6400: 4MiB (32Mbit) or 2+4MiB
(16Mbit+32MBit). Libreboot presently supports the 4MiB version, and provides
8MiB images for those who upgrade their flash to 8MiB or 16MiB. There appears
to be several possible mainboard PCBs for the E6400, which we believe mostly
affects the GPU configuration and the number of available SPI flash footprints:
- LA-3801P: iGPU, possibly dual SPI (however only one may be populated)
- LA-3803P: dGPU, dual SPI (however only one may be populated)
- LA-3805P: iGPU, single SPI flash (4MiB)
- LA-3806P: dGPU, unknown SPI configuration (likely at least 4MiB)
These PCB numbers can be found either under the black plastic in the RAM slots
on the bottom (CPU side) of the board, the top left corner near the VGA port
(top side, under the keyboard and palmrest), or near the CPU backplate (only
requires removal of the keyboard).
We believe that all boards will have at least a single 4MiB flash chip,
regardless of the number of SPI footprints. This is likely the most common
configuration on most available systems. The 2+4MiB configuration likely
would have only been used on systems with full Intel ME firmware with AMT
functionality, though this configuration has not yet been encountered.
Most people will want to use the 4MiB images.
Intel GPU: Blob-free setup (no-ME possible)
---------------
This is a GM45/PM45 platform, so completely libre initialisation in
coreboot is possible, provided by default in Libreboot.
Intel GPU variants are GM45, and Nvidia ones are PM45.
Management Engine (ME) firmware removed
-------------------------
This port in Libreboot makes use of `ich9gen` from ich9utils, which
you can read about in the [ich9utils manual](../install/ich9utils.md) - this
creates a no-ME setup. The Intel Management Engine firmware (ME) is completely
removed, and the ME disabled, just like on ThinkPad X200, T400 and so on.
*The E6400 laptops may come with the ME (and sometimes AMT in addition) before
flashing libreboot. Dell also sold configurations with the ME completely
disabled, identifiable by a yellow sticker reading "3 ME Disabled" inside the
bottom panel. This config sets the MeDisable bit in the IFD and sets the ME
region almost entirely to 1's, with the occasional 32-bit value (likely not
executable). libreboot disables and removes it by using a modified descriptor:
see [../install/ich9utils.md](../install/ich9utils.md)*
(contains notes, plus instructions)

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

@ -0,0 +1,104 @@
---
title: Gigabyte GA-G41M-ES2L desktop board
...
<div class="specs">
<center>
![GA-G41M-ES2L]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Gigabyte |
| **Name** | GA-G41M-ES2L |
| **Released** | 2009 |
| **Chipset** | Intel G41 |
| **CPU** | Intel Core 2 Extreme/Quad/Duo,
Pentium Extreme/D/4 Extreme/4/Celeron |
| **Graphics** | Integrated |
| **Display** | None. |
| **Memory** | Up to 16GB |
| **Architecture** | x86_64 |
| **Original boot firmware** | AWARD BIOS |
| **Intel ME/AMD PSP** | Present. Can be disabled |
| **Flash chip** | 2x8Mbit |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | W+ |
| **Display** | - |
| **Audio** | W+ |
| **RAM Init** | P+ |
| **External output** | P+ |
| **Display brightness** | - |
| ***Payloads supported*** | |
|---------------------------|-------|
| **GRUB** | Slow! |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
This is a desktop board using intel hardware (circa \~2009, ICH7
southbridge, similar performance-wise to the ThinkPad X200. It can make
for quite a nifty desktop. Powered by libreboot.
In recent Libreboot releases, only SeaBIOS payload is provided in ROMs
for this board. According to user reports, they work quite well. GRUB was
always buggy on this board, so it was removed from lbmk.
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, but it's IDE emulation. The
emulation is slow in DMA mode sia SeaBIOS, so SeaBIOS is configured to use PIO
mode on this board. This SeaBIOS configuration does not affect the Linux kernel.
You need to set a custom MAC address in 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/)
RAM
---
**This board is very picky with RAM. If it doesn't boot, try an EHCI debug
dongle, serial usb adapter and null modem cable, or spkmodem, to get a
coreboot log to see if it passed raminit.**
Kingston 8 GiB Kit KVR800D2N6/8G with Elpida Chips E2108ABSE-8G-E
this is a 2x4GB setup and these work quite well, according to a user on IRC.
Nanya NT2GT64U8HD0BY-AD with 2 GiB of NT5TU128M8DE-AD chips works too.
Many other modules will probably work just fine, but raminit is very picky on
this board. Your mileage *will* fluctuate, wildly.

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

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

@ -0,0 +1,54 @@
---
title: Apple iMac 5,2
...
<div class="specs">
<center>
![iMac5,2]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Apple |
| **Name** | iMac 17-inch "Core 2 Duo" 1.83 |
| **Released** | 2006 |
| **Chipset** | Intel Calistoga 945GM |
| **CPU** | Intel Core 2 Duo T5600 |
| **Graphics** | Intel GMA 950 |
| **Display** | 1440x900 TFT |
| **Memory** | 512MB, 1GB (upgradable to 2GB) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | Apple EFI |
| **Intel ME/AMD PSP** | Not present. |
| **Flash chip** | SOIC-8 2MiB (Probably upgradable to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | U |
| **Display** | U |
| **Audio** | U |
| **RAM Init** | U |
| **External output** | U |
| **Display brightness** | U |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Information to be written soon, but this board is merged in libreboot.
This board is very similar to the [MacBook2,1](./macbook21.md).
Just refer back to the [hardware section](./) and [install guides](../install/)

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

@ -0,0 +1,115 @@
---
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 currently supports the following systems in this release:
### Servers (AMD, Intel, x86)
- [ASUS KGPE-D16 motherboard](kgpe-d16.md)
- [ASUS KFSN4-DRE motherboard](kfsn4-dre.md)
### Desktops (AMD, Intel, x86)
- [ASUS KCMA-D8 motherboard](kcma-d8.md)
- [Gigabyte GA-G41M-ES2L motherboard](ga-g41m-es2l.md)
- [Acer G43T-AM3](acer_g43t-am3.md)
- [Intel D510MO and D410PT motherboards](d510mo.md)
- [Apple iMac 5,2](imac52.md)
### Laptops (Intel, x86)
- **[Dell Latitute E6400, E6400 XFR and E6400 ATG, all with Nvidia or Intel
GPU](e6400.md) (easy to flash, no disassembly, similar
hardware to X200/T400)**
- ThinkPad X60 / X60S / X60 Tablet
- ThinkPad T60 (with Intel GPU)
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](x200.md)
- Lenovo ThinkPad X301
- [Lenovo ThinkPad R400](r400.md)
- [Lenovo ThinkPad T400 / T400S](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)
### Laptops (ARM, with U-Boot payload)
- [ASUS Chromebook Flip C101 (gru-bob)](../install/chromebooks.md)
- [Samsung Chromebook Plus (v1) (gru-kevin)](../install/chromebooks.md)
### Emulation
- [Qemu x86](../misc/emulation.md)
- [Qemu arm64](../misc/emulation.md)
## Removed boards
These boards were in Libreboot, but have been removed with the intention of
re-adding them at a later date. They were removed due to issues. List:
- [ASUS Chromebook C201PA (veyron-speedy)](../install/c201.md)
- [Intel D945GCLF](d945gclf.md) (removed from lbmk, TODO: re-add support)
TODO: More hardware is supported. See `resources/coreboot/` in lbmk. Update
the above list!
'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, X301, 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 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
Alternatively, if `dmidecode` is available, run the following command (as `root`) to
find the currently flashed BIOS version:
dmidecode -s bios-version
On a T400 running the latest BIOS this would give `7UET94WW (3.24 )` as result.

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

@ -0,0 +1,199 @@
---
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 or coreboot, by default
it is possible to re-flash using software running in 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.
This was inherited by libreboot, when the Libreboot project was forked.
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
- Opteron 4300 series: Compatible
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 boot from that, 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.

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

@ -0,0 +1,152 @@
---
title: ASUS KFSN4-DRE server/workstation board
x-toc-enable: true
...
<div class="specs">
<center>
![ASUS KFSN4-DRE]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | ASUS |
| **Name** | KFSN4-DRE |
| **Released** | ? |
| **Chipset** | nVIDIA nForce Professional 2200 |
| **CPU** | AMD Opteron 2000 series (Barcelona Family) |
| **Graphics** | XGI Z9s VGA Controller |
| **Display** | None. |
| **Memory** | 512MB, 1GB, 2GB, 4GB |
| **Architecture** | x86_64 |
| **Original boot firmware** | AMIBIOS |
| **Intel ME/AMD PSP** | Not present. |
| **Flash chip** | PLCC 1MiB (Upgradable to 2MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | W+ |
| **Display** | - |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | - |
| ***Payloads supported*** | |
|---------------------------|-----------------|
| **GRUB** | Partially works |
| **SeaBIOS** | Partially works |
| **SeaBIOS with GRUB** | Partially works |
</div>
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/)
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)

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

@ -0,0 +1,212 @@
---
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, 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 Linux on the
KGPE-D16, without using external hardware.
CPU compatibility
=================
Opteron 62xx and 63xx CPUs work just fine.
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 boot from that, 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.
- AMD Opteron 6300 series (Fam15h, with full IOMMU support in
libreboot.
- 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

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

@ -0,0 +1,108 @@
---
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)
If *all* you want to do is change the MAC address, you might try `nvmutil`
instead. See notes below:
Also see [nvmutil documentation](../install/nvmutil.md)
The nvmutil utility is yet another utility provided by Libreboot, for
changing your MAC address. It is a standalone utility, that operates
only on pre-assembled GbE files.

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

@ -0,0 +1,343 @@
---
title: MacBook2,1 and MacBook1,1
x-toc-enable: true
...
<div class="specs">
<center>
![MacBook2,1]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Apple |
| **Name** | Late 2006/Mid 2007 MacBook "Core 2 Duo" / Early
2006 MacBook "Core Duo" |
| **Released** | 2006/2007 |
| **Chipset** | Intel Calistoga 945GM |
| **CPU** | Intel Core 2 Duo or Intel Core Duo on
original MacBooks |
| **Graphics** | Intel GMA 950 |
| **Display** | 1280x800 TFT |
| **Memory** | 512MB, 1GB (upgradable to 4GB with 3GB usable) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | Apple EFI |
| **Intel ME/AMD PSP** | Not present. |
| **Flash chip** | SOIC-8 2MiB (Upgradable to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | W+ |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
The MacBook1,1 and MacBook2,1 are very similar to the
ThinkPad X60. It shares some hardware with the X60 such as the chipset.
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 the MacBook1,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 the MacBook2,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 *(tested - working)*
* MB062LL/A / A1181 (EMC 2139) / Intel Core 2 Duo T7400 *(tested -
working)*
It's believed that all MacBook2,1 and MacBook1,1 models work fine with
Libreboot. If there's a model not in the list or not confirmed working
here and you happen to have that model and that model works with Libreboot
then don't forget to [send a patch](../../git.md), confirming that it
actually works!
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
The MacBook1,1 can't be flashed internally if running the Apple EFI firmware.
You must flash externally.
External flashing
=================
MacBook1,1 requires external flashing, if running the default Apple firmware.
MacBook2,1 can be flashed internally, regardless.
If running coreboot 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)
The chip is located under the 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)
OSes using Linux on Apple EFI firmware
======================================
You have 2 choices for booting up OSes using Linux as their kernel
on the MacBook:
* Boot via USB ;
* Boot via a CD or DVD.
Boot via a CD or DVD
--------------------
The Apple EFI firmware contains a PC BIOS emulation layer for booting
Microsoft Windows on CDs and DVDs. That emulation layer **only** works
if booting from a CD/DVD or from the hard drive. The MacBook will **not**
boot MBR bootloaders from USB, which is why booting from a CD or DVD is
easier than booting from a USB.
* First, burn your ISO to a CD or DVD ;
* Reboot and while rebooting, hold down the Alt/Control key, a boot menu
should pop up, requesting you to choose which device to boot from ;
* Select the CD/DVD icon with 'Windows' as the label (the Apple EFI firmware
elways recognises CDs/DVDs using MBR as 'Windows', because the emulation
layer was made specifically for booting Microsoft Windows as part of
BootCamp, a tool which allowed dual-booting Windows and OS X) ;
* Install it like you normally would (If there's an OS X installation then
it's highly recommended to save all your data and wipe it. Libreboot isn't
able and will never be able to boot OS X) ;
* While rebooting, hold Alt/Control once again, and select the hard disk
icon with the 'Windows' label, after each subsequent boot, the Apple EFI
should boot up properly automatically.
*If you installed your OS alongside OS X then you won't be able to boot
to it using GRUB, despite the fact that it does sometimes show up. You
also won't be able to boot it up when using Libreboot.*
Boot via USB
------------
This method is harder than booting from a CD/DVD and may soft-brick your
MacBook but it's the only way to boot up successfully from a USB.
The PC BIOS emulation layer found in the Apple EFI firmware doesn't work
when booting up from a USB stick. Despite the fact that the
MacBook2,1 does use a 64-Bit processor, the firmware only supports booting
32-Bit EFI devices, meaning you're stuck with 32-Bit OSes and rare
64-Bit OSes which have ISOs that still support booting from 32-Bit EFI.
Meanwhile, GRUB fully supports booting up 64-Bit OSes on 32-Bit EFI.
* First, search for an ISO that supports 32-Bit EFI while being 64-Bit or
a normal 32-Bit ISO and put it in your USB stick ;
* Reboot and while rebooting, hold down the Alt/Control key, a boot menu
should pop up, requesting you to choose which device to boot from ;
* Select the USB icon ;
* Install it like you normally would (If there's an OS X installation then
it's highly recommended to save all your data and wipe it. Libreboot isn't
able and will never be able to boot OS X) ;
* Reboot. It should boot up to your newly-installed system if you wiped OS X,
else, hold Alt/Control and select the correct boot device ;
* Flash Libreboot. DO NOT REBOOT AGAIN BEFORE FLASHING. Sometimes the
firmware can get confused, because Apple never intended to boot other
EFI OSes other than OS X, as such there's a chance that your MacBook can
become [soft-bricked](https://apple.stackexchange.com/questions/408104/late-2006-macbook-doesnt-turn-on-fan-spinning-but-no-chime/409754).
If that is the case then dissassemble it and remove
the CMOS/PRAM battery, wait a few minutes, and put it back in.
*If you want to install Libreboot with the SeaBIOS payload then be sure
to reconfigure GRUB2 correctly, else your system won't boot.*
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. 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.*
Make it overheat less
---------------------
NOTE: on newer libreboot revisions, this section is less relevant, because C3
states are supported now. However, this section may still be useful, so it will
be retained.
The MacBook2,1 overheats a lot with libreboot, we still don't know why but a simple workaround is to install macfanctld.
Macfanctld is available on the default repos of many distributions.
For example, to install macfanctld on an Arch-based distro, you would run as root
pacman -S macfanctld
and don't forget to enable it by using `systemctl` or by a script that will run macfanctld if using runit.
Then, you want to install powertop and tlp.
And then, run the following on battery
sudo tlp start && sudo powertop --calibrate
Then, after quitting powertop, run :
sudo powertop --auto-tune
Now, configure tlp, edit the `/etc/tlp.conf` and uncomment/add/modify the following:
```
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
PLATFORM_PROFILE_ON_AC=performance
PLATFORM_PROFILE_ON_BAT=low-power
```
The MacBook will still overheat, just less.
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 Debian 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 Arch-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.
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
```

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

@ -0,0 +1,105 @@
---
title: ThinkPad R400
x-toc-enable: true
...
<div class="specs">
<center>
![ThinkPad R400]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Lenovo |
| **Name** | ThinkPad R400 |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45 |
| **CPU** | Intel Core 2 Duo (Penryn/Merom family) or
Celeron M (Merom L family) |
| **Graphics** | Intel GMA 4500MHD (and ATI Mobility Radeon HD
3470 or nVIDIA
GeForce 9300M on some models) |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | Up to 8GB |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | LenovoBIOS |
| **Intel ME/AMD PSP** | Present. Can be completly disabled. |
| **Flash chip** | SOIC-8/SOIC-16 4MiB/8MiB (Upgradable to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Dell Latitude E6400
===================
**If you haven't bought an R400 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
============
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.
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.

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

@ -0,0 +1,81 @@
---
title: ThinkPad R500
x-toc-enable: true
...
<div class="specs">
<center>
![ThinkPad R500]()
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Lenovo |
| **Name** | ThinkPad R500 |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45 |
| **CPU** | Intel Core 2 Duo (Penryn/Merom family) or
Celeron M (Merom L family) |
| **Graphics** | Intel GMA 4500MHD (or ATI Mobility Radeon HD
3470 on some models) |
| **Display** | 1280x800/1680x1050 TFT |
| **Memory** | 512MB, 2GB or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | LenovoBIOS |
| **Intel ME/AMD PSP** | Present. Can be completly disabled. |
| **Flash chip** | SOIC-8/SOIC-16/WSON-8 4MiB/8MiB (Upgradable
to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Dell Latitude E6400
===================
**If you haven't bought an R500 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
============
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.

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

@ -0,0 +1,101 @@
---
title: ThinkPad T400
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad T400" class="p" src="https://av.libreboot.org/t400/boot1.jpg" /><span class="f"><img src="https://av.libreboot.org/t400/boot1.jpg" /></span>
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Lenovo |
| **Name** | ThinkPad T400 |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45 |
| **CPU** | Intel Core 2 Duo (Penryn family). A Quad-core
mod exists, replacing the Core 2 Duo with a Core Quad |
| **Graphics** | Intel GMA 4500MHD (and ATI Mobility Radeon HD
3650 on some models) |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | 2 or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | LenovoBIOS |
| **Intel ME/AMD PSP** | Present. Can be completly disabled. |
| **Flash chip** | SOIC-8/SOIC-16/WSON-8 4MiB/8MiB (Upgradable
to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Dell Latitude E6400
===================
**If you haven't bought an T400 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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.
The T400 is almost identical to the X200, code-wise. See
[x200.md](x200.md).

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

@ -0,0 +1,103 @@
---
title: ThinkPad T500
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad T500" class="p" src="https://av.libreboot.org/t500/0062.jpg" /><span class="f"><img src="https://av.libreboot.org/t500/0062.jpg" /></span>
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Lenovo |
| **Name** | ThinkPad T500 |
| **Released** | 2009 |
| **Chipset** | Intel Cantiga GM45 |
| **CPU** | Intel Core 2 Duo (Penryn family). A Quad-core
mod exists, replacing the Core 2 Duo with a Core Quad |
| **Graphics** | Intel GMA 4500MHD (and ATI Mobility Radeon HD
3650 on some models) |
| **Display** | 1280x800/1680x1050/1920x1200 TFT |
| **Memory** | 2 or 4GB (Upgradable to 8GB) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | LenovoBIOS |
| **Intel ME/AMD PSP** | Present. Can be completly disabled. |
| **Flash chip** | SOIC-8/SOIC-16/WSON-8 4MiB/8MiB (Upgradable
to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Dell Latitude E6400
===================
**If you haven't bought an T500 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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.
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.

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

@ -0,0 +1,192 @@
---
title: ThinkPad X200
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://av.libreboot.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://av.libreboot.org/x200/disassembly/0019.jpg" /></span>
</center>
| ***Specifications*** | |
|----------------------------|------------------------------------------------|
| **Manufacturer** | Lenovo |
| **Name** | ThinkPad X200/X200S/X200 Tablet |
| **Released** | July/September 2009 |
| **Chipset** | Intel Cantiga GM45 |
| **CPU** | Intel Core 2 Duo (Penryn family) |
| **Graphics** | Intel GMA X4500MHD |
| **Display** | 1280x800/1440x900 TFT |
| **Memory** | 1,2,3 or 4GB (Upgradable to 8GB, unofficially) |
| **Architecture** | x86_64 |
| **EC** | Proprietary |
| **Original boot firmware** | LenovoBIOS |
| **Intel ME/AMD PSP** | Present. Can be completly disabled. |
| **Flash chip** | SOIC-8/SOIC-16/WSON-8 4MiB/8MiB (Upgradable
to 16MiB) |
```
W+: Works without blobs;
N: Doesn't work;
W*: Works with blobs;
U: Untested;
P+: Partially works;
P*: Partially works with blobs
```
| ***Features*** | |
|----------------|---------------------------------------|
| **Internal flashing with original boot firmware** | N |
| **Display** | W+ |
| **Audio** | W+ |
| **RAM Init** | W+ |
| **External output** | W+ |
| **Display brightness** | P+ |
| ***Payloads supported*** | |
|---------------------------|-----------|
| **GRUB** | Works |
| **SeaBIOS** | Works |
| **SeaBIOS with GRUB** | Works |
</div>
Dell Latitude E6400
===================
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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/)
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.
### 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/)

185
site/docs/hardware/x200.uk.md Normal file
View File

@ -0,0 +1,185 @@
---
title: ThinkPad X200
x-toc-enable: true
...
<div class="specs">
<center>
<img tabindex=1 alt="ThinkPad X200" class="p" src="https://av.libreboot.org/x200/disassembly/0019.jpg" /><span class="f"><img src="https://av.libreboot.org/x200/disassembly/0019.jpg" /></span>
</center>
| ***Характеристики*** | |
|----------------------------|------------------------------------------------|
| **Виробник** | Lenovo |
| **Назва** | ThinkPad X200/X200S/X200 Tablet |
| **Випущено** | Липень/Вересень 2009 року |
| **Чіпсет** | Intel Cantiga GM45 |
| **ЦП** | Intel Core 2 Duo (сімейство Penryn) |
| **Графіка** | Intel GMA X4500MHD |
| **Дісплей** | 1280x800/1440x900 TFT |
| **Пам'ять** | 1,2,3 or 4GB (оновлюється до 8GB, неофіційно) |
| **Архітектура** | x86_64 |
| **EC** | Пропрієтарний |
| **Оригінальна прошивка** | LenovoBIOS |
| **Intel ME/AMD PSP** | Наявний. Можна повністю вимкнути. |
| **Флеш-чіп** | SOIC-8/SOIC-16/WSON-8 4MiB/8MiB (Оновлюється
до 16MБ) |
```
W+: Працює без бінарних компонентів;
N: Не працює;
W*: Працює з бінарними компонентами;
U: Не перевірялось;
P+: Частково працює;
P*: Частково працює з бінарними компонентами
```
| ***Функції*** | |
|----------------|---------------------------------------|
| **Внутрішня прошивка з оригінальною прошивкою** | N |
| **Дісплей** | W+ |
| **Аудіо** | W+ |
| **Ініціалізація ПДД** | W+ |
| **Зовнішній вивід** | W+ |
| **Яскравість дісплею** | P+ |
| ***Корисні навантаження*** | |
|-----------------------------|-----------|
| **GRUB** | Працює |
| **SeaBIOS** | Працює |
| **SeaBIOS з GRUB** | Працює |
</div>
Вступ
============
Вважається що всі ноутбуки X200 сумісні. X200S та X200
Tablet також працюватимуть, [залежно від конфігурації](#x200s).
Можливо, можна розмістити материнську плату X200 у шасі X201, хоча це
наразі не перевірено проектом libreboot. Те ж саме може стосуватися
X200S та X201S; знову ж таки, це неперевірено. *Швидше за все, це правда.*
Є два можливих розміра флеш-чіпа для X200: 4MБ (32 Мбіт) або
8МБ (64 Мбіт). Це можна визначити за типом флеш-чіпа під
упором для рук: 4МБ це SOIC-8, 8МБ це SOIC-16.
*Ноутбуки X200 постачаються з ME (та іноді AMT додатково)
перед перепрошивкою libreboot. libreboot вимикає та видаляє його за допомогою
модифікованого дескриптора: дивіться [../install/ich9utils.md](../install/ich9utils.md)*
(містить примітки та інструкції)
Інструкції з перепрошивки можна знайти за адресою
[../install/\#flashrom](../install/#flashrom)
Оновлення EC {#ecupdate}
=========
Рекомендується оновити мікропрограму EC до останньої версії.
[Прошивка EC](../../faq.md#ec-embedded-controller-firmware) є окремою від
libreboot, тому ми її фактично не надаємо, але якщо у вас все ще є
Lenovo BIOS, ви можете просто запустити утиліту оновлення BIOS Lenovo, яка
оновить як BIOS, так і версію EC. Дивіться:
- [../install/#flashrom](../install/#flashrom)
- <http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk>
- [Оновлення BIOS X200, X200s, X200i](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x200/downloads/ds015007)
- [Оновлення BIOS X200t](http://pcsupport.lenovo.com/au/en/products/laptops-and-netbooks/thinkpad-x-series-tablet-laptops/thinkpad-x200-tablet/downloads/ds018814)
ПРИМІТКА: це можна зробити, лише якщо ви використовуєте Lenovo BIOS. Як
оновити мікропрограму EC, користуючись libreboot, невідомо. libreboot
тільки замінює прошивку BIOS, не EC.
Оновлена мікропрограма EC має декілька переваг, напр. краще поводження
з акумулятором.
Відкликання батареї {#batteryrecall}
==============
[21 квітня 2015 року, Lenovo розширила відкликання акумуляторів Lenovo, які були встановлені в деяких моделях Thinkpad, зокрема X200 та X200S.](https://pcsupport.lenovo.com/cr/en/solutions/hf004122)
Щоб дізнатися, чи вас це стосується, використовуйте [цей інструмент Lenovo.](https://lenovobattery2014.orderz.com/)
Lenovo радить власникам відкликаних моделей "вимкнути систему, вийняти батарею,
та живити ThinkPad лише шляхом підключення адаптера змінного струму та шнура живлення."
Після перевірки батареї, Lenovo безкоштовно замінить відкликані батареї.
Інструкції щодо заміни батареї для X200/X200s [можна знайти на цій сторінці.](https://pcsupport.lenovo.com/cr/en/parts/pd003507/)
Список сумісності LCD {#lcd_supported_list}
----------------------
Список РК-панелей (там перераховані панелі X200):
<http://www.thinkwiki.org/wiki/TFT_display>
Відомо, що всі РК-панелі для X200, X200S та X200 Tablet працюють.
### AFFS/IPS панелі {#ips}
#### X200
Адаптовано з
<https://github.com/bibanon/Coreboot-ThinkPads/wiki/ThinkPad-X200>
Подивіться у Вікіпедії різницю між панелями TN та IPS. IPS мають
набагато кращий колір/контраст, ніж звичайний TN, і зазвичай мають
хороші кути огляду.
Це, здається, з X200 tablet. Вам потрібно знайти таку
без скляного захисту сенсорного екрана (проте її можна зняти).
На ньому також не повинно бути дигітайзера (знову ж таки, можна
просто видалити дигітайзер).
- BOE-Hydis HV121WX4-120, HV121WX4-110 або HV121WX4-100 - дешево,
може бути тяжко знайти
- Samsung LTN121AP02-001 - звичайно знайти, недорого
*Якщо ваш X200 має панель зі світлодіодним підсвічуванням, вам також потрібно придбати
інвертор і кабель, сумісний з панелями CCFL.
Щоб дізнатися, який у вас тип панелі, перегляньте
[\#led\_howtotell](#led_howtotell). Якщо вам потрібен інвертор/кабель, ось
номери деталей: 44C9909 для кабелю CCFL LVDS із підключенням bluetooth і камери,
та 42W8009 або 42W8010 для інвертора.*
Існують глянцеві та матові варіанти. Матовий означає антивідблиск,,
чого ви і хочете (на думку авторів).
Зверніться до HMM (посібник з обслуговування обладнання), щоб дізнатися, як
замінити екран.
Джерела:
- [Форуми ThinkPad - матова панель AFFS на
X200](http://forum.thinkpads.com/viewtopic.php?f=2&t=84941)
- [Форуми ThinkPad - Частини для мода 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> пояснює, що
екрани/блоки X200S тонші. Вам потрібно замінити всю кришку на одну від
звичайного X200/X201.
Як визначити, чи у нього LED, чи CCFL? {#led_howtotell}
-------------------------------------
Деякі X200 мають підсвічування CCFL, а деякі - світлодіодне підсвічування на РК-панелі.
Це також означає, що інвертори відрізнятимуться, тому ви повинні бути обережними,
коли замінюєте панель та/або інвертор. (інвертор CCFL має
високу напругу і зруйнює світлодіодну панель із підсвічуванням).
CCFL містять меркурій. На X200 з CCFL підсвіткою (якщо його не було замінено на світлодіодне з правильним
інвертором. Зверніться до свого постачальника!) буде написано
наступне: *"Цей продукт містить літій-іонну батарею, літієву батарею та лампу,
яка містить ртуть; утилізуйте відповідно до місцевих, державних або федеральних
законів"* (на тому, що має світлодіодне підсвічування, буде написано щось інше).
Дампи апаратного регістру {#regdumps}
-----------------------
Вікі coreboot
[показує](http://www.coreboot.org/Motherboard_Porting_Guide) як
збирати різноманітні логи, корисні для портування на нові плати. Нижче наведено
вихідні дані X200:
- BIOS 3.15, EC 1.06
- [hwdumps/x200/](hwdumps/x200/)

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

@ -0,0 +1,36 @@
---
title: Documentation
...
Always check [libreboot.org](https://libreboot.org/) for the latest updates to
libreboot. News, including release announcements, can be found in
the [main news section](../news/).
[Answers to Frequently Asked Questions about libreboot](../faq.md).
Installing libreboot
====================
- [What systems can I use libreboot on?](hardware/)
- [How to install libreboot](install/)
Documentation related to operating systems
============================
- [How to install BSD on an x86 host system](bsd/)
- [Linux Guides](linux/)
Information for developers
==========================
- [How to compile the libreboot source code](build/)
- [Build system developer documentation](maintain/)
- [GRUB payload](grub/)
- [U-Boot payload](uboot/)
Other information
=================
- [Miscellaneous](misc/)
- [List of codenames](misc/codenames.md)

36
site/docs/index.uk.md Normal file
View File

@ -0,0 +1,36 @@
---
title: Документація
...
Завжди перевіряйте [libreboot.org](https://libreboot.org/index.uk.html) для останніх оновлень
libreboot. Новини, включаючи оголошення про випуски, може бути знайдено
в [основній секції новин](../news/).
[Відповіді на поширені запитання про libreboot](../faq.md).
Встановлення libreboot
====================
- [На яких системах я можу встановлювати libreboot?](hardware/)
- [Як встановити libreboot](install/)
Документація, яка має відношення до операційних систем
============================
- [Як встановити BSD на x86 хостову систему](bsd/)
- [Керівництва Linux](linux/)
Інформація для розробників
==========================
- [Як зібрати джерельний код libreboot](build/)
- [Документація розробника системи побудови](maintain/)
- [Корисне навантаження GRUB](grub/)
- [Корисне навантаження U-Boot](uboot/)
Інша інформація
=================
- [Різне](misc/)
- [Список кодових назв](misc/codenames.md)

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

@ -0,0 +1,102 @@
---
title: ASUS Chromebook C201 installation guide
x-toc-enable: true
...
WARNING: This board is known to have non-functioning video init at the time
of writing, 19 February 2023. It is as yet unsolved.
See: <https://notabug.org/libreboot/lbmk/issues/136>
Introduction
===========
This page contains information about assembly and disassembly, for flashing
the ASUS Chromebook C201 externally. It will also link to internal flashing
instructions, and information about U-Boot.
Flashrom
--------
A special fork of flashrom, maintained by Google, is required for flashing.
More information about this is present in the generic [chromebook flashing
instructions](chromebooks.md).
Depthcharge payload (obsolete)
------------------------------
This board was also supported in Libreboot 20160907, with the Depthcharge
payload. Support was dropped in later releases, and then re-added in the
December 2022 release but with *u-boot* payload (not *depthcharge*).
Refer to older versions of this page, in `lbwww.git`, if you wish to see
instructions pertaining to Depthcharge:
* <https://notabug.org/libreboot/lbwww/src/4be2eed23e11b1071cd500a329abf654ab25f942/site/docs/install/c201.md>
* <https://notabug.org/libreboot/lbwww/src/4be2eed23e11b1071cd500a329abf654ab25f942/site/docs/hardware/c201.md>
U-boot payload
==============
U-Boot was ported to coreboot CrOS devices, courtesy of Alper Nebi
Yasak (`alpernebbi` on Libreboot IRC).
Read the section pertaining to U-boot payload:
[u-boot payload documentation for Libreboot](../uboot/)
Internal flashing
=================
External flashing is possible, but only necessary in the event of a *brick*.
If you're flashing good firmware, and the machine boots properly, you can
do it in software, from the host CPU.
In the past, C201 was the only CrOS device so this page contained information
about internal flashing. Libreboot now supports many more CrOS devices, so
the information has moved.
See: [chromebook flashing instructions](chromebooks.md)
Write-protect screw
-------------------
The chromebook flashing instructions, linked above, refer to a *screw* that
can be turned, to disable flash protection. This is necessary, for internally
flashing the C201. This section will tell you how to access that screw.
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. Refer to the following
photos:
[![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.
External flashing
=================
If the machine is no longer booting, due to bad firmware, you can unbrick
it externally. Refer to [external flash instructions](spi.md).
[![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)
You do not need to correct the `WP#` pin because it is held high via pull-up
resistor to 3.3v, when the write-protect screw is loosened (when tightened,
the screw grounds this pin; the pull-up resistor is to prevent a dead short).
You must remove the battery, prior to flashing. The connector is shown in
the 2nd photo, above (the big black connector, with the black, green, yellow,
white and red wires going into it). Simply unplug that.

201
site/docs/install/chromebooks.md Normal file
View File

@ -0,0 +1,201 @@
---
title: Chromebook flashing instructions
x-toc-enable: true
...
NOTE: daisy, peach and veyron boards were temporarily removed from
lbmk. They should be re-added to Libreboot at a later date. The reasons
are written on the hardware compatibility page. For now, Libreboot only
officially supports the `gru` chromebooks.
This page attempts to give a brief, general overview of how to flash
custom firmware on ChromeOS devices. This guide usually refers to all of
them as "Chromebook"s since it's the most common form factor.
Flashrom
========
A special fork of flashrom, maintained by Google, is required for flashing
these Chromebook devices. See:
<https://chromium.googlesource.com/chromiumos/third_party/flashrom/>
You must then compile this from source, and run it.
Enable ChromeOS "Developer Mode"
================================
Chromebooks are locked-down by default to only run ChromeOS. Most things
you will want to do on these require you unlock it by enabling their
[Developer Mode](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md).
On most devices, you would press the `Escape + Refresh + Power` key
combination to restart into the Recovery Mode, then press `Ctrl + D` and
finally confirm enabling Developer Mode with `Enter`.
On your next boot, it will show you an "OS Verification is disabled"
screen. Waiting for 30 seconds or pressing `Ctrl + D` on this screen will
proceed to boot into ChromeOS, which then erases all data on the device
and reboots again into a clean ChromeOS installation.
With Developer Mode enabled, you can launch a terminal emulator inside
ChromeOS by pressing the `Ctrl + Alt + T` key combination. Run `shell`
inside the resulting `crosh` prompt to actually get to a `bash` session
where you can run programs. Most of the root file system is read-only,
except for `/usr/local` and any mounted drives under `/media/removable`.
Identify your device
====================
It's more common to refer to ChromeOS boards by their codenames, and
many compatible devices can share a single codename. Libreboot ROM
images also use these, you should only use the one corresponding to your
device's. There are a number of ways to find it, some are:
- Check the "Model" on the Recovery Mode or Developer Mode screens
- Visit `chrome://version` in ChromeOS and check the "Firmware Version"
- Run `crossystem hwid` or `crossystem fwid` in a terminal
Back up stock firmware
======================
The stock firmware on your device comes with some irreplaceable data
that is unique to your device. This can include the serial number and
hardware ID of the device, network MAC address, HDCP keys, maybe more.
The stock firmware is also the only one that will properly boot and run
ChromeOS.
Make sure you back up the original firmware before trying to replace it.
The version of flashrom in ChromeOS understands `host` as a programmer
to flash firmware internally. To back up stock firmware you can run:
sudo flashrom -p host -r depthcharge.rom
sudo flashrom -p host -v depthcharge.rom
Keep the resulting `depthcharge.rom` file safe and properly backed up on
another device.
If you can already boot a conventional Linux distro on your Chromebook,
you may be able to use `flashrom -p linux_mtd` on that system instead.
Check external flashability
===========================
If a ROM image you flash is broken, you may need to restore the stock
firmware to fix the board to get internal flashing working. Refer to the
[external flashing guide](spi.md), and check that the result of
`flashrom -r` matches what you get when you run it from the device.
Chromebooks may have 1.8V as the supply voltage for the SPI NOR chip, be
extra careful about that.
On newer Chromebooks, there is a root-of-trust chip providing a
[Closed Case Debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md)
mechanism that lets you flash externally using a special USB debugging
cable. However, most boards that Libreboot supports do not have this.
Disable write protection
========================
Chromebooks have the SPI flash chip partially write-protected by
default, but thankfully this protection can be disabled by the device
owner. How to do so depends on the board, refer to the
[ChromiumOS documentation on Write Protection](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/write_protection.md)
for more info. You will usually need to do this only once for the
board's lifetime, unless you manually enable it again.
On most boards that Libreboot supports, write-protection is enforced by
a physical screw. When screwed in, it forms an electrical connection
that asserts the WP pin on the flash chip. The screw can be identified
by the fact that it bridges electrical contacts, but finding and
removing it might require you to disassemble most of the board.
Newer boards have a root-of-trust chip enforcing write-protection. The
[Closed Case Debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md)
mechanism should be used to disable hardware write-protection. Opening
the case and disconnecting the battery might also disable it.
Disabling the write-protect signal doesn't directly make the chip stop
protecting its data, it just allows you to disable its write-protection
in software. That also needs to be done in ChromeOS afterwards:
sudo flashrom -p host --wp-status
sudo flashrom -p host --wp-disable
sudo flashrom -p host --wp-range 0x0,0x0
The *--wp* arguments are only available on the
[ChromiumOS fork of flashrom](https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom).
If you are using another OS or an external flasher, you may need to
compile and use that flashrom fork to disable write-protection. There is
no `lbmk` support yet for automatically building it.
Prepare the ROM image
=====================
Libreboot ROM image layouts are currently incompatible with the regions
that should be carried over from the stock firmware. However, the
released images should still be somewhat usable, since the Chromebooks
supported so far don't require any non-redistributable blobs to be
injected by the end user.
Future Libreboot versions will likely require post-processing to
preserve irreplaceable data in the firmware image. For now, make sure to
keep backups of the original firmware.
TODO: Instructions to preserve vital data when FMAPs are compatible.
Flash the ROM image
===================
WARNING: Although none are supported yet, make sure not to flash ROM
images on x86 Chromebooks without injecting non-redistributable blobs
first (like Intel ME firmware). This is not yet documented here.
You can flash the ROM image both internally and externally. For the
latter, see the [external flashing guide](spi.md) and the ChromiumOS
[Closed Case Debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging_cr50.md)
documentation if your board supports it.
To flash the entire ROM image internally, run within ChromeOS:
sudo flashrom -p host -w libreboot.rom
sudo flashrom -p host -v libreboot.rom
If you can already boot a conventional Linux distro on your Chromebook,
you may be able to use `flashrom -p linux_mtd` on that system instead.
Install an operating system (experimental research)
===========================
In general, ARM-compatible distros targeting U-boot can be used. There are
three general methods for installing that vary depending on the distribution:
1. EFI - common u-boot methodology used by both arm64 and amd64 systems.
2. boot.scr - an older u-boot specific script used by some distributions.
3. extlinux.conf - a newer flat, bootloader-spec text file that typically lives
in /boot/extlinux/extlinux.conf
Successful installations:
-------------------------
* [ArchLinuxARM on RK3399-based Chromebooks](../uboot/uboot-archlinux.md).
* [Debian Bookworm on Samsung Chromebook Plus XE513C24](../uboot/uboot-debian-bookworm.md).
* [Debian on Asus Chromebook C201](https://wiki.debian.org/InstallingDebianOn/Asus/C201).
Unsuccessful installations:
---------------------------
* [OpenBSD on Samsung Chromebook Plus XE513C24](../uboot/uboot-openbsd.md).
Other promising ARM-compatible distros:
---------------------------------------
* [Armbian](https://www.armbian.com/uefi-arm64/).
See also
========
* [ChromiumOS Documentation](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/)
* [ChromiumOS Firmware Test Manual](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/firmware_test_manual.md)
* [ChromiumOS Flashrom Fork Information](https://www.chromium.org/chromium-os/packages/cros-flashrom/)
* [MrChromebox's Unbricking Guide](https://wiki.mrchromebox.tech/Unbricking)
* [MrChromebox's Write-Protection Notes](https://wiki.mrchromebox.tech/Firmware_Write_Protect)
* [Coreboot Tutorial as used in ChromeOS](https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6ViFC_1HlHOYQ/preview)

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

@ -0,0 +1,20 @@
---
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.

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

@ -0,0 +1,23 @@
---
title: Intel D945GCLF flashing tutorial
...
NOTE: On newer Libreboot revisions, boot issues were reported so this board
was temporarily removed. It will be re-added at a later date, after testing
has been done.
This guide is for those who want libreboot on their Intel D945GCLF
motherboard while they still have the original BIOS present.
D945GCLF2D also reported working by a user.
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)

163
site/docs/install/e6400.md Normal file
View File

@ -0,0 +1,163 @@
---
title: Flashing the Dell Latitude E6400
x-toc-enable: true
...
Introduction
============
Initial flashing instructions for the E6400. DO NOT flash the Nvidia GPU
variant. This page pertains only to the Intel GPU variant.
This guide is for those who want libreboot on their Latitude E6400 while
they still have the original Dell BIOS present. This guide can also be
followed (adapted) if you brick your E6400, and you want to recover it.
This board can boot entirely blob-free in the flash. The hardware is similar
to that of ThinkPad X200, T400 etc where no-ME setup is possible.
A note about GPUs
-----------------
Models with Intel graphics are GM45, and fully supported in Libreboot
with native initialisation; ROM images are available since.
**The Intel video initialisation is libre, implemented with publicly available
source code via libgfxinit, from the coreboot project.**
Flash chip size {#flashchips}
===============
Use this to find out:
flashrom -p internal
We believe most/all are 4MB (32Mb) flash sizes, but larger ROM images are
provided for people who wish to upgrade.
MAC address {#macaddress}
===========
The MAC address is part of the ROM image that you're flashing. You can change
it at any time, before or after you've flashed Libreboot; you can also change
it in the *Dell* BIOS, if you really want to. This is for the onboard gigabit
ethernet device.
Refer to [mac\_address.md](../hardware/mac_address.md).
It is recommended that you run *nvmutil*. See:
[nvmutil usage manual](nvmutil.md)
The `nvmutil` software is specifically designed for changing MAC addresses,
and it implements a few more safeguards (e.g. prevents multicast/all-zero
MAC addresses) and features (MAC address randomisation, ability to correct or
intententionally corrupt(disable) GbE sections if you wish, swap GbE parts,
etc). You can *also* run ich9gen, if you wish:
[ich9gen usage manual](ich9utils.md)
Intel GPU: libre video initialisation available
===============================================
Libreboot uses coreboot's native `libgfxinit` on this platform, for
variants with Intel graphics.
How to flash internally (no diassembly)
=======================================
Warning for BSD users
---------------------
BSD *boots* and works properly on these machines, but take note:
Nicholas's [e6400-flash-unlock](https://browse.libreboot.org/lbmk.git/plain/util/e6400-flash-unlock/e6400_flash_unlock.c)
utility has not yet been ported to BSD systems. The `flashrom` software is
available on BSD systems. Libreboot's build system has not yet been ported to
the BSDs.
BSD users could run Linux from USB to run `flashrom` and `e6400-flash-unlock`.
Virtualisation is available in BSDs, where it should be feasible to run the
Libreboot build system, in Linux, under virtualisation.
Flashing from Linux
-------------------
MAKE SURE you boot with this Linux kernel parameter: `iomem=relaxed` - this
disables memory protections, permitting `/dev/mem` access needed by flashrom.
The flash is memory mapped and flashrom accesses it via `/dev/mem`.
You can flash Libreboot directly from the vendor (Dell) BIOS, without taking
the machine apart. It can be done entirely from Linux. It will probably also
work on BSD systems, but it has only been testing on Linux thus far.
Check `util/e6400-flash-unlock` in the `lbmk.git` repository, or releases.
Go in there:
cd util/e6400-flash-unlock
make
With this program, you can unlock the flash in such a way where everything
is writeable. Information about how to use it is in the `README.md` file which
is included in that program's directory, or you can read it online here:
<https://browse.libreboot.org/lbmk.git/plain/util/e6400-flash-unlock/README.md>
Literally just run that program, and do what it says. You run it once, and shut
down, and when you do, the system brings itself back up automatically. Then
you run it and flash it unlocked. Then you run it again. The source code is
intuitive enough that you can easily get the gist of it; it's writing some EC
commands and changing some chipset config bits. The EC on this machine is
hooked up to the `GPIO33` signal, sometimes called `HDA_DOCK_EN`, which sets
the flash descriptor override thus disabling any flash protection by the IFD.
It also bypasses the SMM BIOS lock protection by disabling SMIs, and Dell's
BIOS doesn't set any other type of protection either such as writing to
Protected Range registers.
When you flash it, you can use this command:
flashrom -p internal -w libreboot.rom
Where `libreboot.rom` is your E6400 ROM. *Make sure* it's the right one.
If flashrom complains about multiple flash chips detected, just pick one of
them (doesn't matter which one). On *most* Dell machines, the most correct
would probably be this option in flashrom: `-c MX25L3205D/MX25L3208D`.
So:
flashrom -p internal -w libreboot.rom -c MX25L3205D/MX25L3208D
When you see flashrom say `VERIFIED` at the end, that means the flash was
successful. If you don't see that, or you're unsure, please [contact the
Libreboot project via IRC](../../contact.md).
BACK UP THE FACTORY BIOS
========================
The `-w` option flashes `libreboot.rom`. You may consider *backing up* the
original Dell BIOS first, using the -r option:
flashrom -p internal -r backup.rom -c MX25L3205D/MX25L3208D
Do this while in a flashable state, after the 2nd run of `e6400-flash-unlock`.
Make sure the `backup.rom` file gets backed up to an external storage media,
not the E6400 itself.
With this method, you can probably flash it within 5 minutes. Again, zero
disassembly required!
How to flash externally
=========================
Refer to [spi.md](spi.md) as a guide for external re-flashing.
The SPI flash chip shares a voltage rail with the ICH9 southbridge, which is
not isolated using a diode. As a result, powering the flash chip externally
causes the ICH9 to partially power up and attempt to drive the SPI clock pin
low, which can interfere with programmers such as the Raspberry Pi. See
[RPi Drive Strength](spi.md#rpi-drive-strength) for a workaround.
Have a look online for videos showing how to disassemble, if you wish to
externally re-flash.

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

@ -0,0 +1,70 @@
---
title: GA-G41M-ES2L flashing tutorial
x-toc-enable: true
...
This guide is for those who want libreboot on their Intel GA-G41M-ES2L
motherboard while they still have the original BIOS present.
MAC ADDRESS
===========
NOTE: due to a bug in the hardware, the MAC address is hardcoded in
coreboot. Therefore, you must set your own MAC address in your
operating system.
Use [macchanger](http://www.gnu.org/software/macchanger) in your
distro, to set a valid MAC address. By doing this, your NIC should
work nicely.
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
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.

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

@ -0,0 +1,554 @@
---
title: ich9utils
x-toc-enable: true
...
If all you want to do is change the MAC address, you might use `nvmutil`
instead. See: [nvmutil documentation](../install/nvmutil.md).
Introduction
============
The `ich9utils` utility from 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 may also find it in the source code tar archives, on 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.

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

@ -0,0 +1,609 @@
---
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.
PRECAUTIONS
===========
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 announcements via the news page](/news/) and decide for yourself.
About ROM image file names
==========================
Init types and display mode
---------------------------
NOTE: regardless of init type, on desktops, an external/add-on GPU can always
be used. On laptop hardware in libreboot, libgfxinit will always be used. On
desktop/server hardware, if available, libgfxinit will also always be used by
default (but in that setup, SeaBIOS can be used if you want to use an add-on
graphics card, e.g. on KCMA-D8, KGPE-D16, GA-G41M-ES2L)
**This means that on desktop hardware such as KCMA-D8, KGPE-D16, G43T-AM3,
GA-G41M-ES2L and others, you can use either the internal GPU or an add-on
PCI-E graphics card. Simply use a ROM image that starts with SeaBIOS, and you
can use both. On desktop/server hardware, libgfxinit simply means that you
CAN use the internal graphics chip, but you don't have to; external add-on
GPUs will also still work! However, if libgfxinit is enabled, that disables
coreboot from loading/executing PCI option ROMs which means you MUST use SeaBIOS
if you wish to use the add-on cards!**
### libgfxinit
In this setup, on supported systems, coreboot's own native video initialization
code is used. This is referred to generically as libgfxinit, which is coreboot's
library in `3rdparty/libgfxinit` but not all boards with native video
initialization use libgfxinit; some of them are using coreboot's older style
of video initialization method, written purely in C.
#### corebootfb (libgfxinit)
high resolution coreboot framebuffer used on startup
#### txtmode (libgfxinit)
int10h text mode is used on startup.
### vgarom
NOTE: no configs in libreboot are currently available that use this method.
With this method, coreboot is finding, loading and executing a VGA option ROM
for your graphics hardware. This would not be done on laptops, because that
implies supplying non-free binary blobs in libreboot, so this setup would only
ever be provided on desktop hardware where no GPU exists or where it is
desirable for you to use an external/add-on graphics card
#### vesafb (vgarom)
high resolution VESA framebuffer used on startup. This is equivalent
to `corebootfb` (high resolution framebuffer), but for setups where a VGA
Option ROM is used.
#### txtmode (vgarom)
int10h text mode is used on startup
### normal
int10h text mode startup is implied here. The `vesafb` mode is unavailable here.
For `vesafb` mode, please use init type `vgarom`; most useful for GRUB payloads
or perhaps Tianocore.
In this setup, coreboot is neither implementing libgfxinit / native graphics
initialization nor is it finding/loading/executing VGA option ROMs. In this
setup, SeaBIOS would most likely be used for that.
The `normal` setup is supported in the libreboot build system, but not
currently used. It is there for desktop hardware that will be added in the
future, where those desktop boards do not have an onboard GPU and therefore an
add-on GPU is always used..
Payload names
-------------
### grub
ROM images with just `grub` in the file name will start first with the GRUB
payload. They may or may not also provide other payloads in the menu, such as
memtest86+, SeaBIOS, Tianacore and so on.
### seabios
ROM images with just `seabios` in the file name will start first with the
SeaBIOS payload. They will only contain SeaBIOS, but may also contain memtest as
an option in the boot menu.
### seabios\_withgrub
ROM images that have `seabios_withgrub` in the file name start with SeaBIOS
first, but also have GRUB available in the boot menu when you press ESC.
### seabios\_grubfirst (DEFUNCT)
**DEFUNCT**
This build option is obsolete, and should not be used. It was deleted
in lbmk revision `e1bbdadc9584291cf062660d67128e9f17ab788e`.
It was believed, in earlier theory, that VGA ROM initialisation could
be used in SeaBIOS and then SeaBIOS boots into a GRUB payload (built
for coreboot), where the initialisation would continue to be used, but
it didn't work that way.
It's best to use PC GRUB (normal BIOS GRUB), but compile it into a floppy
image to insert inside CBFS, to then be executed by SeaBIOS. This is referred
to as SeaGRUB by the Libreboot project, and it would be quite useful
for desktop users, but it's largely irrelevant on laptops where
coreboot's own `libgfxinit` is usually available (or the option ROM is
easy to extract from vendor firmware and insert).
Where direct bare metal GRUB is desired, but you use a desktop system with
an add-on graphics card, you must extract the VGA ROM for your card and
insert it into the coreboot ROM, for coreboot itself to execute. This will
require custom configuration on your part, and it is thus beyond the scope
of the Libreboot project, in context of lbmk (automated build system).
Some older Libreboot releases included ROM images built using this option,
and those specific ROM images (`seabios_grubfirst` ones) should not be
used; you should only use `seabios_grubfirst` or `seabios`, in most
scenarios, if SeaBIOS is required.
For most desktop users, if running an external graphics card, it's easier
to simply boot in text mode with a SeaBIOS payload and use only that. This
will Just Work with almost all graphics cards, allowing you to use an
operating system with a full display and (drivers permitting) full 2D/3D
acceleration.
Which systems are supported?
============================
[Refer to the hardware compatibility page](../hardware/)
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 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
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 you are re-flashing a GM45+ICH9M laptop (e.g. ThinkPad X200/X200S/X200T,
T400, T500, R400, W500 etc - but not R500), you should run the ich9gen utility
to preserve your mac address.
Please read the ich9utils documentation:
[/docs/install/ich9utils.html](/docs/install/ich9utils.html)
NOTE: `force_I_want_a_brick` is not scary. Do not be scared! This merely disables
the safety checks in flashrom. Flashrom and coreboot change a lot, over the years,
and sometimes it's necessary to use this option. If you're scared, then just
follow the above instructions, but remove that option. So, just use `-p internal`.
If that doesn't work, next try `-p internal:boardmismatch=force`. If that doesn't
work, try `-p internal:boardmismatch=force,laptop=force_I_want_a_brick`. So long
as you *ensure* you're using the correct ROM for your machine, it will be safe
to run flashrom. These extra options just disable the safetyl checks in flashrom.
There is nothing to worry about.
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)
#### DELL Latitute E6400 laptop (easy to flash, similar to X200/T400)
See: [Dell Latitute E6400 Libreboot Installation Guide](e6400.md)
#### ThinkPad X200/T400/T500/W500/R400/R500 vendor 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 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
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}
NOTE: If BIOS password auth is enabled, you can clear it by shorting pins on
an EEPROM and then resetting the password in Lenovo BIOS, prior to flashing
Libreboot. For T60, see:
<https://ounapuu.ee/posts/2022/10/13/recovering-password-locked-thinkpad-t60/>
(TODO: link something here for X60)
X60 BIOS password (Lenovo): you might find info here:
<https://bios-pw.org/>
You can just get bucts from the libreboot project, same thing for the patched
flashrom. In the Libreboot 20160907 release, there is a *utility* archive, which
has statically compiled executables. They still work just fine on modern
systems, and they can be used for this purpose.
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; *Screen* can connect to the serial console
and you will run it at 115200 baud rate. agetty/fgetty in 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.
The 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.
**WARNING: if flashrom complains about `/dev/mem` access, please
run `sudo ./bucts 0`. If flashrom is complaining about `/dev/mem`, it means
that you have `CONFIG_STRICT_DEVMEM` enabled in your kernel. Reboot with the
following kernel parameter added in your bootloader: `iomem=relaxed` and try
again with the above instructions. DO NOT continue until the above works, and
you see the expected flashrom output as indicated above.**
If you *did* run flashrom and it failed to flash, but you set bucts to 1 and
shut down, don't worry. Just remove the yellow coin-cell battery (it's underneath
the keyboard, connected to the mainboard), wait a minute or two, reconnect the
coin-cell and try again from scratch. In this instance, if flashrom didn't do
anything, and didn't flash anything, it means you still have Lenovo BIOS but
if bucts is set to 1, you can flush it and set it back to 0. BUC.TS is stored in
volatile memory, powered by that CR2032 coin-cell battery.
Assuming that everything went well:
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)
DELL Latitude E6400 laptop (easy to flash, similar to X200/T400)
-------------------------
See: [Dell Latitute E6400 Libreboot Installation Instructions](e6400.md)
ASUS KFSN4-DRE
--------------
The KFSN4-DRE has an LPC chip. Most people have been flashing these
internally, hot-swapping the chip out after boot, preserving the original chip,
and using flashrom on a new chip as described above.
TODO: Document PLCC32 (LPC) flashing.
The [FlexyICE](https://www.coreboot.org/FlexyICE) has been used to flash these
chips, but it is hard to find now. A custom flasher may be made such as
[flashrom serprog stm32](https://github.com/wosk/stm32-vserprog-lpc) or
[teensy flasher](https://www.flashrom.org/Teensy_3.1_SPI_%2B_LPC/FWH_Flasher)
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)

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

@ -0,0 +1,32 @@
---
title: KGPE-D16 external flashing instructions
x-toc-enable: true
...
These will be re-added to Libreboot at a later date, once proper testing
has been done.
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.

520
site/docs/install/nvmutil.md Normal file
View File

@ -0,0 +1,520 @@
---
title: nvmutil manual
x-toc-enable: true
...
With this software, you can change the MAC address inside GbE regions
on any system that uses an Intel Flash Descriptor.
You can use the documentation below, if you wish to use `nvmutil` manually.
Continue reading...
Introduction
============
This is the manual for `nvmutil`, included in the Libreboot,
build system (lbmk) under `util/nvmutil/`. This program lets you modify
the MAC address, correct/verify/invalidate checksums,
swap/copy and dump regions on Intel PHY NVM images,
which are small binary configuration files that go
in flash, for Gigabit (ethernet) Intel NICs.
This software is largely targeted at coreboot users,
but it can be used on most modern Intel systems, or
most systems from about 2008/2009 onwards.
NOTE: Libreboot X200/X200T/X200S/T400/T400S/T500/W500/R400
users should know that this software does *not*
replace `ich9gen`, because that program generates entire
ICH9M IFD+GbE regions, in addition to letting you set the
MAC address. *This* program, `nvmutil`, can *also* set
the MAC address on those machines, but it operates on a
single GbE dump that is already created.
This program is operated on dumps of the GbE NVM image,
which normally goes in the boot flash (alongside BIOS/UEFI
or coreboot, IFD and other regions in the flash). The first
half of this README is dedicated to precisely this, telling
you how to dump or otherwise acquire that file; the second
half of this README then tells you how to operate on it,
using `nvmutil`.
How to download newer versions
==============================
Simply pull down the latest changes in `lbmk.git`. The `nvmutil`
software is now part of lbmk, since 17 November 2022.
More info about git:
* <https://git-scm.com/>
Context
=======
On many Intel systems with an IFD (Intel Flash Descriptor), the
Intel PHY (Gigabit Ethernet) stores its configuration, binary
encoded, into a special region of the main boot flash, alongside
other flash regions such as: IFD, ME, BIOS.
This includes many configurations, such as your MAC address.
The purpose of nvmutil project, is precisely to allow you to change your
MAC address. Many other useful features are also provided.
Intel defines this as the *Gigabit Ethernet Non-Volative Memory* or
just *NVM* for short. It is a 128-byte section, consisting of 64
words that are 2 bytes, stored in little-endian byte order.
Newer Intel PHYs define an *extended* area, which starts
immediately after the main one, but the `nvmutil` program
does not modify or manipulate these in any way.
The final word in the NVM section is the *checksum*; all words
must add up, truncated, to the value `0xBABA`. The hardware
itself does not calculate or validate this, and will in
fact work nicely, but software such as Linux will check
that this is correct. If the checksum is invalid, your
kernel will refuse to make use of the NIC.
This NVM section is the first 128 bytes of a 4KB region in flash.
This 4KB region is then repeated, to make an 8KB region in
flash, known as the *GbE region*. In `nvmutil`, the first part
is referred to as *part 0* and the second part as *part 1*.
Known compatible PHYs
---------------------
TODO: write a full list her ofe what actual PHYs are known to work.
It's probably all of them, but some newer ones might have
changed the standard by which they are configured. This
program actively avoids working on files that have
invalid checksums, on most commands, precisely so that
the user does not inadvertently use it on incompatible
files; it is assumed that intel would later change the
file size and/or checksum value and/or checksum location.
How to obtain the GbE file
==========================
The chip containing your BIOS/UEFI firmware (or coreboot) has
it, if you have an Intel PHY for gigabit ethernet.
The sections below will teach you how to obtain the GbE file,
containing your NIC's configuration. This is the part that
many people will struggle with, so we will dedicated an
entire next section to it:
Use flashrom
------------
If you wish to operate on the GbE section that's already
flashed, you should *dump* the current full ROM image.
If you already have a ROM image, you do not need to dump
it, so you can skip this section.
Download flashrom here:
* <https://flashrom.org/>
Using recent flashrom versions, you can extract this region. If
your regions are unlocked, you can run flashrom on the target
system, like so:
flashrom -p internal -r rom.bin
If your system has two flash chips, the GbE region is usually
stored on SPI1 (not SPI2). Otherwise, it may be that you have
a single-flash setup. In that case, it's recommended to dump
both chips, as `spi1.rom` and `spi2.rom`; you can then cat
them together:
cat spi1.rom spi2.rom > rom.bin
If your GbE region is locked (per IFD settings), you can dump
and flash it using external flashing equipment. The Libreboot
project has a handy guide for this; it can be used for reading
from and writing to the chip. See:
* <https://libreboot.org/docs/install/spi.html>
If you're using an external programmer, the `-p internal`
option should be changed accordingly. Read flashrom
documentation, and make sure you have everything
properly configured.
Use ifdtool
-----------
NOTE: This has only been tested on systems that use IFDv1
(Intel Flash Descriptor, version 1). This distinction, between
v1 and v2, is made in the `ifdtool` source code, which you
should read if you're interested. Intel`s v2 specification
has more regions in it, whereas v1 systems usually
defined: IFD, GbE, PD, ME and BIOS regions.
The `ifdtool` program is a powerful tool, allowing you to
manipulate Intel Flash Descriptors. It's part of coreboot,
available in the `coreboot.git` repository
under `util/ifdtool/`. Just go in there and build it
with `make`, to get an ifdtool binary.
To make internal flashing possible later on, you might do:
ifdtool --unlock rom.bin
Running this command will create a modified image,
named `rom.bin.new`. This file will have all regions set
to read-write, per configuration in the Intel Flash Descriptor.
In addition to unlocked regions, you may wish to *neuter* the
Intel Management Engine, removing all the nasty spying features
from it, using `me_cleaner`. See:
* <https://github.com/corna/me_cleaner>
* Also available in `coreboot.git`, undir `util/`
The `me_cleaner` program is outside the scope of this
article, so you should read their documentation.
Now run this:
ifdtool -x rom.bin
Several files will be created, and the one you need to
operate on is named `flashregion_3_gbe.bin` so please
ensure that you have this file.
Read the notes below about how to use the `nvmutil` program,
operating on this file. When you're done, you can insert the
modified GbE file back into your ROM image, like so:
ifdtool -i gbe:flashregion_3_gbe.bin rom.bin
This will create the file `rom.bin.new`, which contains
your modified GbE section with the NVM images inside; this
includes your MAC address.
Refer to flashrom documentation. You may flash the new ROM
like so, if running on the same system and the regions are
read-write:
flashrom -p internal -w rom.bin.new
Newer versions of flashrom support flashing just the specified
region, like so:
flashrom -p internal --ifd -i gbe -w rom.bin.new
If you're running flashrom from host CPU on the target
system, and it's dual flash, you can just flash the
concatenated image, which you created earlier by running
the `cat` program; dual-IC flash configurations appear to
your operating system as one large flash area, as though
it were a single chip.
If you're using an external programmer, you should change
the `-p internal` parameter to something else. In this
situation, you should re-split the file accordingly, if
you have a dual-IC flash set, like so:
dd if=rom.bin.new of=spi2.rom bs=1M skip=8
dd if=rom.bin.new of=spi1.rom bs=1M count=8
These files would then be flashed externally, separately,
using an external programmer.
The *above* example (using `dd`) is for setups with 12MB
flash, where you have 8MB as SPI1 and 4MB as SPI2. SPI1
would contain the IFD, and SPI2 is the upper flash area
containing your bootblock; GbE is probably located in
SPI1. You should adjust the above parameters, according
to your configuration.
How to compile source code
==========================
The nvmutil source code is located under `util/nvmutil/` in the
lbmk repository. A makefile is included there, for you to build an
executable.
The nvmutil programs will work just fine, on any modern BSD Unix operating
system, or unix-like system such as Linux.
You must be sure to have toolchains installed, for
building; a normal libc, C compiler and linker should be enough.
GCC and LLVM have all these things included, so use whichever one
you want.
If the code is compiled on OpenBSD,
[pledge(2)](https://man.openbsd.org/pledge.2) is used.
This is done with an `ifdef` rule, so that the code still compiles
on other systems. When the `dump` command is specified, pledge
will use these promises: `stdio rpath`. When any other command
is used, these pledge promises will be used: `stdio wpath`.
The `nvmutil` software has been build-tested on `Clang`, `GCC`
and `tcc`. Only standard library functions (plus `err.h`) are
used, so you don't need any extra libraries.
How to compile it
-----------------
First, ensure that the current working directory is your
copy of the nvmutil source code!
You may run this in your terminal:
make
This will result in a binary being created named `nvm`.
Install this to wherever you want, such as `/usr/bin` (or
whatever is in your `$PATH` for userspace programs).
TODO: Add `make install` to the Makefile, portably.
How to use nvmutil
==================
You run it, passing as argument the path to a file, and you run
commands on that file. This section will tell you how to
perform various tasks, by using these commands.
In these examples, it is assumed that you have installed
the `nvm` binary to somewhere in your `$PATH`. If you haven't
done that, you could still run it in cwd for instance:
./nvm bla bla bla
Exit status
-----------
The `nvmutil` program uses `errno` extensively. The best error
handling is done this way, the Unix way. Error handling is extremely
strict, in nvmutil; on program exit, the errno message is printed (if not
zero) and the value of errno is returned (upon exit from `int main`).
The `main` function always returns `errno`, no matter what. This style
of programming (set errno and return) is a very old fashioned way of
doing things, and in many cases it is the most *correct* way.
This is why we say `zero status` and `non-zero status` in Unix
programs, when we talk about exit status. Zero is success, and
anything above zero is fail; errno is zero by default, unless
set, and it will always be set to a value above zero (if set).
All commands (except `dump`) require read and write access. The `dump`
command only requires read access on files. Where sufficient permission
is not given (read and/or write), nvmutil will exit with non-zero status.
Non-zero status will also be returned, if the target file is *not*
of size *8KB*.
Additional rules regarding exit status shall apply, depending on
what command you use. Commands are documented in the following sections:
Change MAC address
------------------
The `nvm` program lets you change the MAC address. It sets
a valid checksum, after changing the MAC address. This program
operates on *both* NVM parts, but it will only modify a given
part if the existing checksum is correct. It will exit with zero
status if at least one part is modified; otherwise, it will
exit with non-zero status.
The following rules are enforced in code:
* User cannot specify multicast addresses
* User cannot specify `00:00:00:00:00:00`
* When generating random addresses, if the right
most nibble of the left-most byte is `?` (random),
nvmutil will (in code) force the generated MAC
address to be local (not global), and will prevent
a multicast address from being generated.
A multicast address is invalid because it represents
multiple devices; you must specify a unicast address.
A global address is one uniquely assigned by the vendor,
and a local address is an overridden one. You *can* set
global MAC addresses in nvmutil, for example if you are
simply copying what was officially assigned to your NIC,
you can do that. For example, if your MAC address
was `00:de:ad:be:ef:69` as assigned by the manufacturer,
which is a global unicast MAC address, you would type:
nvm gbe.bin setmac 00:de:ad:be:ef:69
How to use (the MAC address in just an example):
nvm gbe.bin setmac 00:de:ad:be:ef:00
You can also set random MAC addresses:
nvm gbe.bin setmac ??:??:??:??:??:??
In this example, every character is random. However, you
can mix and match random characters with static ones. For
example:
nvm gbe.bin setmac 00:1f:16:??:??:??
You can also pass it without a MAC address:
nvm gbe.bin setmac
If you only type `setmac` without specifying a MAC address,
it will do the same thing as `setmac ??:??:??:??:??:??`.
This will set the last three bytes randomly, while the
MAC address would begin with `00:1f:16`.
The *reason* nvmutil doesn't alter a part with an existing
invalid checksum, is precisely so that if the algorithm
changes in future Intel PHYs, nvmutil will just fail and
not modify your file. This is because the checksum would
then be invalid, at all times. However, correct NVM parts
with otherwise invalid checksums do exist, and can be
corrected if you use the `setchecksum` command
in `nvmutil`. It is common for vendor gbe files to contain
one valid part and one invalid part, per checksum rules.
Verify checksums (and show MAC addresses)
-----------------------------------------
This command *only* requires *read* access on files.
The `nvm` program can show a hexdump of both NVM parts, and
tell you whether each one is valid (as per checksum calculation).
It also prints the MAC address from each part.
How to use:
nvm gbe.bin dump
NOTE: This will exit with zero status if at least one part
contains a valid checksum. If both parts are invalid, nvmutil
will exit with non-zero status.
Copy part
---------
This command requires read *and* write access on files.
The `nvm` program can copy one NVM part to another. It copies
the *entire* 4KB part, within the 8KB file.
Overwrite part 0 with the contents of part 1:
nvm gbe.bin copy 1
Overwrite part 1 with the contents of part 0:
nvm gbe.bin copy 0
NOTE: If the part to be copied has a bad checksum, no operation
will be performed, and nvmutil will exit with non-zero status.
Otherwise, it will (if all other conditions are met) exit with
zero status.
Swap parts
----------
This command requires read *and* write access on files.
The `nvm` program can swap both 4KB parts in the GbE
file. It does this, via simple XOR swaps.
How to use:
nvm gbe.bin swap
NOTE: This operation will be aborted if BOTH checksums
are invalid. This is to guard against accidentally
using `nvmutil` on the wrong file.
If *at least one* part is valid, nvmutil will return
with zero exit status. If both parts are invalid, it will
return non-zero.
Set valid checksum
------------------
This command requires read *and* write access on files.
The `nvm` program can calculate and sets a valid checksum, on
the desired NVM part. Usage:
Fix part 0:
nvm gbe.bin setchecksum 0
Fix part 1:
nvm gbe.bin setchecksum 1
*WARNING: NO validity checks are performed. This will simply
set the checksum. There is no feasible way to guard against
use on the wrong file, unlike with the other commands. Please
make SURE you're running this on the correct file!*
Set invalid checksum
--------------------
This command requires read *and* write access on files.
The `nvm` program can intentionally set an invalid checksum, on
the desired NVM part. Usage:
Invalidate part 0:
nvm gbe.bin brick 0
Invalidate part 1:
nvm gbe.bin brick 1
NOTE: If the part already has an invalid checksum, no operation
will be performed, and nvmutil will exit with non-zero status.
This is to guard against `nvmutil` being used on the wrong file.
This may be desirable, if you've made modifications to both
parts but you want to guarantee that only one of them is
used. Also, the `setmac` command will only operate on
parts that already have a valid checksum, so you could
run `brick` before running `setmac` (or run it afterwards).
The Linux kernel's `e1000` driver will refuse to initialise
Intel gigabit NICs that don't have a valid checksum. This
is software-defined, and not enforced by the hardware.
LICENSE
=======
This page is released under different copyright terms than most other pages
on this website.
The `nvmutil` software and documentation are released under the following
terms:
Copyright 2022 Leah Rowe
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

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

@ -0,0 +1,210 @@
---
title: Flashing the ThinkPad R400
x-toc-enable: true
...
**If you haven't bought an R400 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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)
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 Linux](../linux/).

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

@ -0,0 +1,953 @@
---
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)
* Libre Computer 'Le Potato'
Many other SPI programmers exist. More of them will be documented on this page,
at a date in the future. You can otherwise figure it out on your own; certain
parts of this page are still useful, even if you're using a programmer that
Libreboot does not yet document.
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 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 or 1.8V 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.
**Not covered on that eevblog page: the WP/HOLD pins (pins 3 and 7) must be
held high via pull-up resistors, but on CH341A dongles, they are directly
connected to 3.3V DC (continuity with pin 8). It is advisable to cut these
two connections, to the WP and HOLD pins, and jump the cuts using pull-up
resistors instead. A value between 1k to 10k (ohms) should be fine.**
**In the event of a surge, like for example you connect the clip wrongly and
cause a short circuit between two pins, lack of pull-up resistors on WP/HOLD
could cause a direct short between VCC/ground, which would cause a lot of heat
build up and possibly fire (and definitely damaged circuitry). On SOIC8, pin 3
is WP and 4 is GND, so a direct 3.3v connection there is quite hazardous for
that reason; all the more reason to use a pull-up resistor.**
The mainboard that you want to flash (if using e.g. pomona clip) will probably
have pull-up resistors on it already for WP/HOLD, so simply cutting WP/HOLD
on the CH341A would also be acceptable. The pull-up resistors that you
place (in such a mod) on the CH341A are only useful if you also want to flash
chips in the ZIF socket. If pull-up resistors exist both on e.g. the laptop
mainboard and on the CH341A, it just means the equivalent series resistance
will be of the two resistors (on each line) in parallel. If we assume that
a laptop is likely to have a resistor size of ~3.3k for pull-ups, then a value
of ~5.6k ohms on the CH341A side seems reasonable.
Alternatively, you might work around the voltage issue by using an adapter with
logic-level converter, making sure to have matching vcc going into the flash.
Use of a logic level converter would be quite flexible, in this scenario, and
you could use it to set many voltages such as 1.8v or 3.3v.
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.
These photos show both modifications (3.3v logic and WP/HOLD pull-up
resistors) performed, on the black CH341A:\
<img tabindex=1 src="https://av.libreboot.org/ch341a/0000_th.jpg" /><span class="f"><img src="https://av.libreboot.org/ch341a/0000.jpg" /></span>
<img tabindex=1 src="https://av.libreboot.org/ch341a/0001_th.jpg" /><span class="f"><img src="https://av.libreboot.org/ch341a/0001.jpg" /></span>
The green version (not shown above) may come with 3.3v logic already wired, but
still needs to have pull-up resistors placed for WP/HOLD.
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)
Supply Voltage
--------------
Historically, all boards that Libreboot supports happened to have SPI NOR chips
which work at 3.3V DC. With the recent addition of Chromebooks whose chips are
rated for 1.8V DC, this can no longer be assumed.
Inspect the chip on your board for a part number, look up the datasheet for it.
Find out and make note of the power supply voltage it needs. If it doesn't
match the voltage output by your external flashing hardware, you should only
connect it to the chip through an adapter or logic level converter, never
directly.
Software configuration
======================
General/Le potato
-----------------
The [generic guide](spi_generic.md) is intended to help those looking to use an
SBC which is not listed in this guide.
The guide will, however, use the libre computer 'Le Potato' as a reference board.
If you have that board, you should refer to the [generic guide.](spi_generic.md)
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.
TODO: document other SPI flashers
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`
RPi Drive Strength
------------------
Flashrom on the RPi may not be able to detect the SPI flash chip on some
systems, even if your wiring and clip are set up perfectly. This may be due to
the drive strength of the Raspberry Pi GPIOs, which is 8mA by default. Drive
strength is essentially the maximum current the pin can output while also
maintaining the minimum high-level voltage. In the case of the Pi, this voltage
is 3.0V.
Similarly, the SPI flash chip has a minimum voltage it will accept as a high
logic value. This is commonly 0.7\*VCC for SPI flash, which is 2.31V for 3.3V
chips. If the drive strength is too low, the voltage at the pins of the flash
chip may fall below this minimum voltage, causing it to register as a low logic
value instead of the high value that was sent.
On many systems, the VCC pin of the SPI flash is shared with other chips on the
system, causing them to be powered through the voltage supplied through your
programming clip. In this case, parts of the chipset may power up, and it may
attempt to set the SPI lines high or low, interfering with the data the Pi is
trying to send. If the Pi and chipset are trying to set a pin to different
values, the side with a greater drive strength will be able to "pull" the
voltage toward the level it wants to set.
Fortunately, the drive strength of the Raspberry Pi can be increased up to
16mA. There are a few tools that can set this, such as the pigs utility from
the pigpio project. On the Raspberry Pi OS, the following commands should
install pigpio and set the drive strength to 16mA:
Install pigpio:
sudo apt install pigpio
Start the pigpiod daemon, which the pigs utility communicates with to interact
with the gpios:
sudo pigpiod
Set the drive strength of GPIO group 0, which contains the spi0 pins, to 16mA:
pigs pads 0 16
Note that the drive strength hardware works in multiples of 2mA, and pigs will
round odd values up to the next multiple of 2. You can check the current drive
strength using
pigs padg 0
WARNING: If the chipset is very strongly trying to drive a pin to a value
opposite that of the Pi, more than 16mA pass through the Pi's GPIO pins, which
may damage them as they are only designed for 16mA. The drive strength is NOT a
current limit. That said, this is a risk to the Pi regardless of the drive
strength. Resistors between the chipset and the flash should protect against
this, though not all boards have these.
See
<https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#gpio-pads-control>
for more information about the drive strength control on the Pi.
Caution about RPi
-----------------
Basically, the Raspbian project, now called Raspberry Pi OS, put in their repo
an update that added a new "trusted" repository, which just so happened to be
a Microsoft software repository. They seem to have done this for VS Code, but
the problem here is that it gave Microsoft free reign to define whatever
dependencies they liked (as per apt-get rules), and every time you updated,
you would be pinging Microsoft servers. Do you think that is strange?
Microsoft shouldn't have *any* access to your Linux system! This was the
commit that Raspbian added to their distro, which added this what should rightly
be called a security vulnerability, intentionally:
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/655cad5aee6457b94fc2336b1ff3c1104ccb4351>
They then removed it, after a public backlash, via the following commits:
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/ed96790e6de281bc393b575c38aa8071ce39b555>
* <https://github.com/RPi-Distro/raspberrypi-sys-mods/commit/4d1afece91008f3787495b520ac03b53fef754c6>
Libre firmware on RPi
---------------------
The boot firmware on older Raspberry Pi models can be replaced, with entirely
libre firmware. This may be a useful additional step, for some users. See:
<https://github.com/librerpi/>
Website:
<https://librerpi.github.io/>
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://codeberg.org/libreboot/lbmk):
cd lbmk
sudo ./build dependencies ubuntu2004
NOTE: debian, arch or void can be written instead of ubuntu2004. the debian
script is also applicable to newer ubuntu versions
./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 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 (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 the power source until your chip is otherwise properly
wired. For instance, do not connect a test clip that has power attached.
Do not *disconnect* your chip from the flasher until you've disconnected or
turned off the power source.
BE CAREFUL that you are indeed supplying the appropriate supply voltage to the
chip. SPI flashes on most of the currently supported libreboot hardware run on
3.3V DC and logic at that level too. Some of them (at least Chromebooks) can
have chips that run on 1.8V DC. You should make sure to check the part number
and datasheet of the SPI flash chip for the supply voltage it requires. If your
external flashing hardware doesn't match it, use an adapter or logic level
converter to flash.
It is important to CHECK that you are running on the correct voltage, when you
do anything with these chips. Lower than the rated supply voltage won't damage
anything, but higher will fry your chip (on most 3.3V 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 VCC 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 a chip expecting 3.3V VCC is usually around 2.7V
to 3.6V DC, and the drop may cause the voltage to fall outside that. 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* power source going through the diode.
The reason is simple: on most systems, the flash shares a common power 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 power 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 the appropriate supply
voltage (2.7V to 3.6V for a 3.3V chip) 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) 40 Pin
--------------------------------------
This diagram shows the pinout for most modern Pi's and Pi derivatives.
The diagram shows the pins of an RPi on the left and the two SOIC clips
on the left.
![](https://av.libreboot.org/rpi/wiring.webp)
GPIO pins on Raspberry Pi (RPi) 26 Pin
-------------------------------
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 VCC 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 VCC 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 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 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 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. 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)
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 5250 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. 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 5252 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.
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.
Some of these resources originate from the *old* Libreboot git repository,
before Libreboot split into separate repositories that include its `lbmk`
repository.
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 (from libreboot).

103
site/docs/install/spi_generic.md Normal file
View File

@ -0,0 +1,103 @@
---
title: Generic SPI Flashing Guide
x-toc-enable: true
...
There are a plethora of single board computers with which you can flash libreboot to a SOIC chip.
Some users might be daunted by the price of a raspberry pi.
This guide is intended to help users looking to use a programmer which is not listed in the [main guide.](spi.md)
As an example, this guide will use the [libre computer 'le potato.'](https://libre.computer/products/aml-s905x-cc/)
You should note however, that this guide is intended to demonstrate how to set up any SBC with SPI programming capabilities for flashing libreboot.
If you are wondering about which SBC to buy, keep these things in mind:
+ The board *must* support SPI (look at the specs/pinout to find out if it does)
+ It is easier to use a board that supports raspbian/raspberry pi OS
+ Boards often require their own kernel patches which rarely get upstreamed
All of this means that you should try to find a board that is *known* to support SPI on an OS for which there are available images.
It is *not* enough to know that the board itself supports SPI.
Selecting an Operating System
=============================
In theory, any linux based operating system will do.
In practice, many distros are highly limited when it comes to single-board-computers.
SBCs often require specialized kernel patches which are rarely upstreamed.
Additionally, armhf boards (like the le potato) are not supported in most modern distros.
In light of the above facts, it is a good general rule to use a distro aimed at supporting SBCs.
[Armbian](https://www.armbian.com/) is one such distro you might use.
Note that not all armbian images support SPI.
If your SBC supports [Raspbian](https://www.raspberrypi.com/software/) then using it will make your work much easier.
As a bonus, you may refer to the [main guide](spi.md) if the SBC you have supports raspbian, should you get confused with this guide.
Connecting to your Programmer
=============================
Many SBC operating systems enable ssh by default.
If the OS you chose does not enable ssh on first boot, try checking the distro documentation and looking for terms such as 'headless install.'
You will need the IP address of your programmer to continue.
Connecting via ethernet is generally easier than doing so with WiFi.
Check your distro's docs if you wish to connect with WiFi only.
To determine the IP address of your programmer, log in to your AP/Router web interface.
If you're not sure the IP address of your AP, it is likely `192.168.1.1.`
You can determine the correct IP address with `ip r` on a linux machine.
You should see your programmer somewhere on the homepage, depending on your router firmware.
This author recommends using [https://openwrt.org/](https://openwrt.org/) for your router firmware.
SSH to your programmer using the default credentials as specified in your distro's docs.
The IP address is the one determined in the earlier step.
For example:
`ssh root@192.168.0.167`
Finding GPIO Pins
=================
If you have determined that a board supports SPI then the only step left is to
determine the correct location of the SPI pins.
The board will have the pinout in its documentation.
The Le potato board has the same pinout as the raspberry pi so you can refer to the [main SPIC documentation.](spi.md#gpio-pins-on-raspberry-pi-rpi-40-pin)
If your board is not raspberry pi compatible, refer to the [wiring table.](spi.html#soic8dip8wson8-wiring-diagram)
Match each of the categories in the 'signal' column with those in the 'pin' column.
Using this method, you can theoretically use any single board computer with SPI support.
Enabling SPI
============
The modules needed and methods to enable SPI vary based on the SBC you choose.
You should always make sure there is a well documented method for enabling SPI on your SBC before purchasing.
In the case of the *le potato,* SPI is enabled by activating the correct overlays as such (raspbian):
```
sudo ldto enable spicc spicc-spidev
sudo ldto merge spicc spicc-spidev
```
Using Flashrom
==============
Most linux distros will provide flashrom in their default repositories.
You can also download flashrom in binary form with [libreboot utils.](https://libreboot.org/download.html#https)
Here is an example using raspbian:
```
sudo apt update
sudo apt install flashrom
```
Reading/writing from SPI works respectively as such:
```
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r /path/to/read.bin
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/libreboot.rom
```
Note that `spispeed` varies based on the board in question.
A standard lower limit is *512.*
For example, to read on a board with a lower SPI speed, you may try:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -r /path/to/read.bin

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

@ -0,0 +1,235 @@
---
title: Flashing the ThinkPad T400 externally
x-toc-enable: true
...
Dell Latitude E6400
===================
**If you haven't bought an T400 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Introduction
============
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 Linux](../linux/).

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

@ -0,0 +1,266 @@
---
title: ThinkPad T500 external flashing
x-toc-enable: true
...
**If you haven't bought a T500 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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.
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)
This video from FrostKiwi (Libera IRC) does a nice illustration and explains
everything nicely:
<https://yewtu.be/watch?v=Fs4GjDiOie8>
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).
Clip wiring
===========
Refer to [spi.md](spi.md) as a guide for external re-flashing.
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)
Now flash Libreboot.
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 Linux](../linux/).

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)

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

@ -0,0 +1,161 @@
---
title: First-time ThinkPad X200 flashing
x-toc-enable: true
...
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
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 Linux](../linux/).
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 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)

155
site/docs/install/x200_external.uk.md Normal file
View File

@ -0,0 +1,155 @@
---
title: Прошивка ThinkPad X200 вперше
x-toc-enable: true
...
**If you haven't bought an X200 yet: the [Dell Latitude
E6400](../../news/e6400.md) is much easier to flash; no disassembly required,
it can be flashed entirely in software from Dell BIOS to Libreboot. It is the
same hardware generation (GM45), with same CPUs, video processor, etc.**
Цей посібник призначений для тих, хто бажає libreboot на своєму ThinkPad X200,
поки у нього все ще є оригінальний Lenovo BIOS в наявності. Цього керівництва також можна
дотримуватися (адаптувати), якщо ви перетворили ваш X200 на цеглину, щоб знати, як його відновити.
Якщо у вас виконується оригінальна мікропрограма Lenovo, вам потрібно буде зняти
клавіатуру та підставку для рук, щоб мати доступ до мікросхеми флеш-пам'яті, яка знаходиться прямо
під підставкою для рук. Потім ви підключите зовнішній програматор SPI, щоб
повторно прошити мікросхему зовні, коли вона вимкнена та акумулятор висунуто.
ПРИМІТКА: Цей посібник стосується лише звичайного X200. Для перепрошивки X200S та X200 Tablet,
будь-ласка прочитайте інші посібники, доступні на libreboot.org.
Розмір флеш-чіпа
===============
Виконайте цю команду на x200, щоб дізнатися модель флеш-чіпа та його розмір:
flashrom -p internal
MAC адреса
===========
Зверніться до [mac\_address.md](../hardware/mac_address.md).
Процедура
-------------
Цей розділ стосується X200. Цей не стосується X200S або X200
Tablet (для цих систем потрібно повністю видалити материнську плату,
оскільки мікросхема флеш-пам'яті знаходиться з іншого боку плати).
Викрутіть ці гвинти:\
![](https://av.libreboot.org/x200/disassembly/0003.jpg)
Обережно притисніть клавіатуру до екрана, потім підніміть її та за бажанням
від'єднайте від плати:\
![](https://av.libreboot.org/x200/disassembly/0004.jpg)
![](https://av.libreboot.org/x200/disassembly/0005.jpg)
Від'єднайте кабель пристрою для зчитування відбитків пальців, а потім потягніть упор для рук,
піднявши його ліву та праву сторону:\
![](https://av.libreboot.org/x200/disassembly/0006.1.jpg)
![](https://av.libreboot.org/x200/disassembly/0006.jpg)
Тут показано розташування мікросхеми флеш-пам'яті, для обох SOIC-8 та SOIC-16:\
![](https://av.libreboot.org/x200/x200_soic16.jpg)
![](https://av.libreboot.org/x200/x200_soic8.jpg)
Підніміть стрічку, яка закриває частину флеш-пам'яті, а потім
приєднайте затискач:\
![](https://av.libreboot.org/x200/disassembly/0008.jpg)
Тепер ви повинні бути готові до встановлення libreboot.
Зверніться до [інструкцій програмування SPI](spi.md).
Закінчивши, знову зберіть систему. Якщо вона не завантажується, спробуйте інші
модулі оперативної пам'яті, тому що raminit дуже ненадійний на цій платформі (в coreboot).
Пам'ять
======
У машинах DDR3 з Cantiga (GM45/GS45/PM45), північний міст потребує стіків,
які працюватимуть як PC3-8500 (швидші стіки PC3/PC3L можуть працювати як PC3-8500).
Пари, що не збігаються, можуть не працювати. Один модуль (тобто один із слотів
буде порожнім) наразі працюватиме лише в слоті 0.
ПРИМІТКА: згідно зі звітами користувачів, у деяких випадках невідповідні пари ( 1+2 ГБ) можуть
працювати в деяких випадках.
Переконайтесь, що оперативна пам'ять, яку ви купуєте, має конфігурацію 2Rx8, купуючи стіки по 4 ГБ
(Іншими словами: максимально 2 ГБ на ранг, 2 ранга на картку).
На цьому фото встановлено 8 ГБ оперативної пам'яті (2x4ГБ):
![](https://av.libreboot.org/x200/disassembly/0018.jpg)
Завантажуйтесь!
--------
Ви маєте побачити щось подібне цьому:
![](https://av.libreboot.org/x200/disassembly/0019.jpg)
Тепер [встановлюйте Linux](../linux/).
Користувачі X200S та X200 Tablet: трюк GPIO33 не спрацює.
--------------------------------------------------------
sgsit дізнався про контакт під назвою GPIO33, який можна заземлити,
щоб вимкнути захист прошивки за допомогою дескриптора та зупинити ME від
запуску (який сам по собі перешкоджає спробам прошивки). Теорія була
доведена правильною; однак на практиці це все одно марно.
Подивіться трохи вище 7 у TP37 (це GPIO33):
![](https://av.libreboot.org/x200/gpio33_location.jpg)
Це замовчуванням ми побачимо це в lenovobios, під час спроби 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.
Коли GPIO33 було заземлено під час завантаження, це вимкнуло захист флеш-пам'яті,
встановлений дескриптором, і зупинило запуск ME. Результат змінився
на:
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.
Частина, виділена жирним шрифтом, - це те, що нас дістало. Це все ж спостерігалось:
PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.
Насправді ці засоби захисту можна відключити. Lenovobios робить це,
під час оновлення BIOS (пропрієтарного). Одним із можливих способів вирішити цю проблему
було б відлагодити утиліту оновлення BIOS від Lenovo, для віднаходження,
як вона вимикає ці засоби захисту. Додаткові дослідження доступні
тут:
<http://www.coreboot.org/Board:lenovo/x200/internal_flashing_research>
Звичайно, ймовірно, що Lenovo BIOS перевіряє якийсь біт в пам'яті,
який говорить йому не вимикати перепрошивку, а потім він не встановлює регістри PRx. Принцип
роботи програми оновлення BIOS Lenovo полягає в тому, що вона спочатку виконується в Windows,
а потім відбувається перезавантаження, ініціюючи перепрошивку під час раннього завантаження. Ймовірно,
це встановлює щось у пам'яті та завантажує ROM, плюс програму корисного навантаження,
яка виконує перепрошивання; тоді Lenovo BIOS, ймовірно, бачить це та запускає це замість
встановлення PRx і переходу до нормального завантаження. Теоретично можливо, що ми
зможемо дізнатися, як це працює, налагодивши утиліту оновлення BIOS Lenovo (у
Windows), а потім відтворивши її дії за допомогою якогось інструменту для Linux,
а потім завантаживши двійковий файл flashrom в пам'ять та ROM для прошивки (для BIOS
регіона). Ви б зробили це з заземленням GPIO33, і програма корисного навантаження
фактично прошиє весь чіп, лише звичайним образом libreboot.
Це можливо. Ймовірно, це єдиний спосіб роботи програми оновлення BIOS Lenovo.
Отже, якщо ми дізнаємося, як саме це зробити, тоді ви можете просто підключити кілька
контактів pogo для заземлення GPIO33, потім завантажитися, запустити програмне забезпечення
(яке потрібно було б написати), яке виконує вищезазначене.
У зв'язку з цим у libreboot є утиліта, яка може допомогти
розслідувати це:
[ich9utils.md#demefactory](ich9utils.md#demefactory)

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

@ -0,0 +1,214 @@
---
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.
When you're finished flashing, 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

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

@ -0,0 +1,122 @@
---
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.
Reverse the steps to re-assemble your system, after you've flashed the chip.

102
site/docs/linux/encryption.md Normal file
View File

@ -0,0 +1,102 @@
# Fully Encrypted Boot and Root Partitions with Libreboot
The following guide will explain how to create:
+ A boot partition (/dev/sda1 in this example) that GRUB can decrypt with 'passphrase1'
+ A root partition (/dev/sda2) with stronger encryption using 'passphrase2'
This guide assumes you are working from a live disk of your preffered distro.
# Creating Encrypted Boot Partition
Grub2 currently (Oct 2021) supports luks2 encryption, which is great, but only the (not very strong) PBKDF2 algorithm.
Start by creating a boot partition of around 1GB, you don't have to format it to anything as LUKS will overwrite it anyway.
**Step 1:**
Create a LUKS2 formatted device with the PBKDF2 algorithm.
You can play around with the iteration count.
A higher iteration is more secure but will take GRUB a **very** long time to decrypt.
The [debian encrypted boot guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) recommends a count of 500,000 which will still take GRUB a very long time (around 25 seconds) but is faster than the default 1000,000.
Use whatever count makes you feel comfortable.
I'll use and arbitrarily low count.
You'll also want to use a different password than you intend to use for your root partition.
We don't want someone to be able to get our root key by brute-forcing our less secure boot key.
`sudo cryptsetup luksFormat /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
**Step 2:**
Format and mount the new LUKS2 device.
```
sudo cryptsetup luksOpen /dev/sda1 boot
sudo mkfs.ext4 -L boot /dev/mapper/boot
sudo mount /dev/mapper/boot /boot
```
**Note:**
If you wish to change the passphrase for the boot partition in the future then you'll need to pass the same arguments to cryptsetup as when you created it.
If you don't pass any special arguments, the key will be changed to the distro's default encryption and grub won't be able to decrypt it.
The command to use is:
`cryptsetup luksChangeKey /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
# Root Partition
Setting up the root partion is generally simple.
Use the same command without the given parametres used to make the device decryptable by GRUB.
`cryptsetup luksFormat /dev/sda2 root`
# Set Up Grub and Install
You will need to pass the correct kernel parametres to your kernel on boot to allow you to use your encryption passphrase to decrypt the root partition.
These parametres can be passed via a grub config in the boot partition by editing `/etc/default/grub.`
Add the necessary parametres to the line `GRUB_CMDLINE_LINUX_DEFAULT` as follows:
`GRUB_CMDLINE_LINUX_DEFAULT="loglevel=4 rd.auto=1 cryptdevice=/dev/sda2:root"`
*rd.auto=1* tells linux that you want to decrypt all disks.
*cryptdevice* tells linux the block device and mapped name you want to use for the root partition.
Note that the mapped name **must** match what you have it `/etc/fstab.`
From here, you can generally follow the install guide from your distro's docs.
Make sure that the generated `/boot/grub/grub.cfg` file indeed contains the necessary kernel parametres and that the `/etc/default/grub` file on the disk has the same modifications described above.
# Set up Fstab
> The device holding the kernel (and the initramfs image) is unlocked by GRUB, but the root device needs to be unlocked again at initramfs stage, regardless whether it’s the same device. This is because GRUB boots with the given vmlinuz and initramfs images, but there is currently no way to securely pass cryptographic material (or Device Mapper information) to the kernel. Hence the Device Mapper table is initially empty at initramfs stage; in other words, all devices are locked, and the root device needs to be unlocked again.
>
> \- [Debian Guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html)
**Step 1:**
Here, we're not trying to store the root key as we don't want to jeopardize the integrity of our root device.
Instead, we want to store the key for the boot device on the root partition.
```
sudo mkdir -m0700 /etc/keys
su -c '( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/boot.key conv=excl,fsync )'
sudo cryptsetup luksAddKey /dev/sda1 /etc/keys/boot.key
```
**Step 2:**
Add your boot device to your crypttab.
You'll need to have the device's UUID.
You can obtain the UUID from `blkid` or simply use the linux block device name `/dev/sda1,` acknowleding it may lead to another device if your disk configuration changes.
```bash
lsblk -o 'PATH,LABEL,UUID' # to get UUID
sudo vim /etc/crypttab
> boot_crypt UUID=YOUR_UUID /etc/keys/boot.key luks,key-slot=1
```
**Step 3:**
Add the crypt device to your fstab.
Use 'mount -a' to test your fstab configuration.
NOTE: you will not be able to mount the device until it has been unlocked and mapped, rebooting with your new crypttab should do this automatically.
```
sudo vim /etc/fstab
> /dev/mapper/boot_crypt /boot ext4 defaults 0 1
sudo mount -a
```

183
site/docs/linux/grub_boot_installer.md Normal file
View File

@ -0,0 +1,183 @@
---
title: Installing Linux
x-toc-enable: true
...
# Introduction
This guide assumes that you are using the 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 Linux distributions. For this guide, you
will only need a USB flash drive and the `dd` utility (it's installed into all
Linux distributions, by default).
These instructions are intended to be generic, applicable to just about any
Linux distribution.
## Prepare the USB Drive in Linux
If you downloaded your ISO while on an existing Linux system, here is how
to create the bootable 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* 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 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 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 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=linux.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-linux](#prepare-the-usb-drive-in-linux).
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 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 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/linux/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 GRUB bootloader as your default
payload. In this configuration, 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 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 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 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.

275
site/docs/linux/grub_hardening.md Normal file
View File

@ -0,0 +1,275 @@
---
title: Hardening GRUB
x-toc-enable: true
...
This article only applies to those people who use the GRUB bootloader as
their default payload (options besides GRUB are also available in
libreboot). Whenever this article refers to GRUB, or configuration files
used in GRUB, it is referring exclusively to those files hosted in CBFS
(coreboot file system) in the libreboot ROM image. In this configuration,
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 GRUB
configuration, for security purposes. These steps are optional, but *strongly*
recommended by the libreboot project.
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
=========================
GRUB contains code, based on [GPG](https://gnupg.org/), that can verify
PGP signatures on *any* type of file, on any storage medium supported by
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 project striving towards this goal; see:
<https://wiki.debian.org/ReproducibleBuilds>
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 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 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
GRUB terminal for executing commands). This behaviour protects your system
from an attacker simply booting a live USB key (e.g. live 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.*
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 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.

93
site/docs/linux/index.md Normal file
View File

@ -0,0 +1,93 @@
---
title: Linux guides
x-toc-enable: true
...
NOTE: This guide pertains to x86 hosts, and does not cover supported CrOS/ARM
chromebooks. For ARM targets, you should refer to u-boot documentation.
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>
Linux is generally assumed, especially for Libreboot development, but Libreboot
also works quite nicely with [BSD systems](../bsd/).
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)
* [How to Harden Your GRUB Configuration, for Security](grub_hardening.md)
Encrypted (LUKS/dm-crypt) installations
=======================================
A better solution for encryption would be a Linux payload in flash, handling the
encryption, at least if you want to use Linux, because then it'll have
perfect LUKS support.
GRUB otherwise has good filesystem support, so if you have a valid `grub.cfg`
in `/boot/grub` on your installed system, Libreboot's GRUB configuration has
logic in it that will try to automatically use whatever you have installed,
by switching to it. In this way, most installations Just Work, so long as
the `/boot` partition is accessible.
Full encryption for basic LUKS2 is supported in libreboot.
See [the guide](encryption.md) for more detail.
Rebooting system in case of freeze
===================================
Linux kernel has a feature to do actions to the system any time, even
with it freezes, this is called a
[Magic SysRq keys](https://en.wikipedia.org/wiki/Reisub). You can do these
actions with Alt + Sysrq + Command. These are the actions:
* Alt + SysRq + B: Reboot the system
* Alt + SysRq + I: Send SIGKILL to every process except PID 1
* Alt + SysRq + O: Shut off the system
If some of them don't work, you have to enable it in the kernel
command line paramter. So append `sysrq_always_enabled=1` to your
`GRUB_CMDLINE_LINUX_DEFAULT` in `/etc/default/grub`
You can also run `# sysctl kernel.sysrq=1` to enable them.
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
-------------
Libreboot's default GRUB config sources fedora's grub config
`grub.cfg` (in `/boot/grub2/grub.cfg`), fedora by default makes use of the
`linux16` command, where 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

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

File diff suppressed because it is too large Load Diff

89
site/docs/maintain/testing.md Normal file
View File

@ -0,0 +1,89 @@
---
title: Apply to become board maintainer/tester for Libreboot
x-toc-enable: true
...
This page is very new, and these guidelines/procedures will be revised over
time. We are, as of April 2023, formalising our testing / release engineering
procedures somewhat. The Libreboot project is *expanding* to support a lot
more hardware these days.
Libreboot strives to make Coreboot accessible for as many users as possible.
To accomplish this goal, we must add as many boards as possible.
As the total number of supported boards increases it becomes more and more difficult
for our main contributors to test every single release for every single supported board.
We therefore need the help of the community in testing releases before they are
distributed to users.
You do *not* need to be a developer in order to be a board maintainer.
All you need to do in order to become a board maintainer is:
+ Be contactable via email when new testing binaries are available
+ Have the correct equipment ready to externally flash your board
+ Have the board you wish to maintain
Once you become a board maintainer, your real name and screen name can
be added to the public list on the Libreboot contributors page.
You can, of course, choose to forego the public listing (we will ask for
permission, before publishing your name).
To apply for such a posting, ping `leah` or `shmalebx9` on
[irc,](../../contact.html#irc-chatroom) or email
Leah Rowe via [leah@libreboot.org](mailto:leah@libreboot.org)
Do not be afraid to apply to maintain a board with another listed
maintainer or multiple maintainers; more is better.
Please read the following sections to understand the specifics of
maintaining a board.
NOTE: If there are already testers for a given mainboard, *you* can still
provide testing for the same mainboard if that's what you have. The more the
merrier!
Be Contactable
==============
You should monitor whatever email you provide in your application.
There is no specific time-frame for how long it should take after
you receive the email until you report the status of your board.
You should make best efforts to respond within a few days.
If you are the *only* maintainer for your board then please take
into consideration that your input is especially vital.
Have External Flashing Equipment
================================
The roms you test will of course be untested.
To avoid having a bricked machine, you need to have external flashing
equipment available for your board to recover from a broken rom.
In most cases you can refer to the [SPI guide.](../install/spi.html)
In rarer cases -such as some ARM chromebooks- your board might be flashed in a different way.
Refer to [Coreboot's documentation](https://doc.coreboot.org/)
or ask on IRC if you are unsure.
Testing Procedure
=================
You will receive an email when roms are ready for testing.
The email will link to an open issue on our [current git hosting platform.](/git.html#lbmk-libreboot-make)
Whether you receive an email from a libreboot.org email
domain or one of our developer's email you should verify (for
your own security)
that the downloaded roms are signed with the [official key.](/download.html#gpg-signing-key)
When your testing is complete, comment on the issue linked in
the dispatch email as follows:
board: `your board`
status: `pass/fail`
note: [insert any notes if relevant]
For example, a board status comment might look like this:
board: x200_8mb
status: fail
note: GRUB throws error 'something_is_b0rked'

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