code:
% How to replace the default GRUB configuration file on a libreboot system

Libreboot on x86 uses the GRUB
[payload](http://www.coreboot.org/Payloads#GRUB_2) by default, which
means that the GRUB configuration file (where your GRUB menu comes from)
is stored directly alongside libreboot and its GRUB payload executable,
inside the flash chip. In context, this means that installing
distributions and managing them is handled slightly differently compared
to traditional BIOS systems.

A libreboot (or coreboot) ROM image is not simply "flat"; there is an
actual filesystem inside called CBFS (coreboot filesystem). A utility
called 'cbfstool' allows you to change the contents of the ROM image.
In this case, libreboot is configured such that the 'grub.cfg' and
'grubtest.cfg' files exist directly inside CBFS instead of inside the
GRUB payload 'memdisk' (which is itself stored in CBFS).

You can either modify the GRUB configuration stored in the flash chip,
or you can modify a GRUB configuration file on the main storage which
the libreboot GRUB payload will automatically search for.

Here is an excellent writeup about CBFS (coreboot filesystem):
<http://lennartb.home.xs4all.nl/coreboot/col5.html>.

**This guide is \*only\* for the GRUB payload. If you use the
depthcharge payload, ignore this section entirely.**

Table of Contents
=================

-   [Introduction](#introduction)
-   [1st option: don't re-flash](#option1_dont_reflash)
-   [2nd option: re-flash](#option2_reflash)
    -   [Acquire the necessary utilities](#tools)
    -   [Acquiring the correct ROM image](#rom)
    -   [Extract grubtest from the ROM image](#extract_testconfig)
    -   [Re-insert the modified grubtest.cfg into the ROM
        image](#reinsert_modified_testconfig)
    -   [Testing](#testing)
    -   [Final steps](#final_steps)

Introduction
------------

Download the latest release from <http://libreboot.org/>\
**If you downloaded from git, refer to
[../git/\#build\_meta](../git/#build_meta) before continuing.**

There are several advantages to modifying the GRUB configuration stored
in CBFS, but this also means that you have to flash a new libreboot ROM
image on your system (some users feel intimidated by this, to say the
least). Doing so can be risky if not handled correctly, because it can
result in a bricked system (recovery is easy if you have the
[equipment](../install/bbb_setup.html) for it, but most people don't).
If you aren't up to that then don't worry; it is possible to use a
custom GRUB menu without flashing a new image, by loading a GRUB
configuration from a partition on the main storage instead.

1st option: don't re-flash {#option1_dont_reflash}
---------------------------

By default, GRUB in libreboot is configured to scan all partitions on
the main storage for /boot/grub/libreboot\_grub.cfg or
/grub/libreboot\_grub.cfg(for systems where /boot is on a dedicated
partition), and then use it automatically.

Simply create your custom GRUB configuration and save it to
**/boot/grub/libreboot\_grub.cfg** on the running system. The next time
you boot, GRUB (in libreboot) will automatically switch to this
configuration file. **This means that you do not have to re-flash,
recompile or otherwise modify libreboot at all!**

Ideally, your distribution should automatically generate a
libreboot\_grub.cfg file that is written specifically under the
assumption that it will be read and used on a libreboot system that uses
GRUB as a payload. If your distribution does not do this, then you can
try to add that feature yourself or politely ask someone involved with
or otherwise knowledgeable about the distribution to do it for you. The
libreboot\_grub.cfg could either contain the full configuration, or it
could chainload another GRUB ELF executable (built to be used as a
coreboot payload) that is located in a partition on the main storage.

If you want to adapt a copy of the existing *libreboot* GRUB
configuration and use that for the libreboot\_grub.cfg file, then follow
[\#tools](#tools), [\#rom](#rom) and
[\#extract\_testconfig](#extract_testconfig) to get the
***grubtest.cfg***. Rename ***grubtest.cfg*** to
***libreboot\_grub.cfg*** and save it to ***/boot/grub/*** on the
running system where it is intended to be used. Modify the file at that
location however you see fit, and then stop reading this guide (the rest
of this page is irrelevant to you); **in libreboot\_grub.cfg on disk, if
you are adapting it based on grub.cfg from CBFS then remove the check
for libreboot\_grub.cfg otherwise it will loop.**.

2nd option: re-flash {#option2_reflash}
--------------------

You can modify what is stored inside the flash chip quite easily. Read
on to find out how.

Acquire the necessary utilities {#tools}
-------------------------------

Use ***cbfstool*** and ***flashrom***. There are available in the
*libreboot\_util* release archive, or they can be compiled (see
[../git/\#build\_flashrom](../git/#build_flashrom)). Flashrom is also
available from the repositories:
    # pacman -S flashrom

Acquiring the correct ROM image {#rom}
-------------------------------

You can either work directly with one of the ROM images already included
in the libreboot ROM archives, or re-use the ROM that you have currently
flashed. For the purpose of this tutorial it is assumed that your ROM
image file is named *libreboot.rom*, so please make sure to adapt.

ROM images are included pre-compiled in libreboot. You can also dump
your current firmware, using flashrom:
    $ sudo flashrom -p internal -r libreboot.rom
    # flashrom -p internal -r libreboot.rom
If you are told to specify the chip, add the option **-c {your chip}**
to the command, for example:

    # flashrom -c MX25L6405 -p internal -r libreboot.rom

Extract grubtest.cfg from the ROM image {#extract_testconfig}
---------------------------------------

You can check the contents of the ROM image, inside CBFS:

    $ cd \.../libreboot\_util/cbfstool** $ ./cbfstool libreboot.rom
print**

The files *grub.cfg* and *grubtest.cfg* should be present. grub.cfg is
loaded by default, with a menuentry for switching to grubtest.cfg. In
this tutorial, you will first modify and test *grubtest.cfg*. This is to
reduce the possibility of bricking your device, so DO NOT SKIP THIS!

Extract grubtest.cfg from the ROM image:

    $ ./cbfstool libreboot.rom extract -n grubtest.cfg -f grubtest.cfg

Modify the grubtest.cfg accordingly.

Re-insert the modified grubtest.cfg into the ROM image {#reinsert_modified_testconfig}
------------------------------------------------------

Once your grubtest.cfg is modified and saved, delete the unmodified
config from the ROM image:

    $ ./cbfstool libreboot.rom remove -n grubtest.cfg

Next, insert the modified version:\
**\$ ./cbfstool libreboot.rom add -n grubtest.cfg -f grubtest.cfg -t
raw**

Testing
-------

**Now you have a modified ROM. Refer back to
[../install/\#flashrom](../install/#flashrom) for information on how to
flash it.
    $ cd /libreboot\_util** \# **./flash update libreboot.rom\
Ocassionally, coreboot changes the name of a given board. If flashrom
complains about a board mismatch, but you are sure that you chose the
correct ROM image, then run this alternative command:
    # ./flash forceupdate libreboot.rom
You should see **"Verifying flash\... VERIFIED."** written at the end
of the flashrom output. Once you have done that, shut down and then boot
up with your new test configuration.**

Choose (in GRUB) the menu entry that switches to grubtest.cfg. If it
works, then your config is safe and you can continue below.

**If it does not work like you want it to, if you are unsure or
sceptical in any way, then re-do the steps above until you get it right!
Do \*not\* proceed past this point unless you are 100% sure that your
new configuration is safe (or desirable) to use.**

Final steps {#final_steps}
-----------

When you are satisfied booting from grubtest.cfg, you can create a copy
of grubtest.cfg, called grub.cfg. This is the same except for one
difference: the menuentry 'Switch to grub.cfg' will be changed to
'Switch to grubtest.cfg' and inside it, all instances of grub.cfg to
grubtest.cfg. This is so that the main config still links (in the menu)
to grubtest.cfg, so that you don't have to manually switch to it, in
case you ever want to follow this guide again in the future (modifying
the already modified config). From /libreboot\_util/cbfstool, do:\
\$ **sed -e 's:(cbfsdisk)/grub.cfg:(cbfsdisk)/grubtest.cfg:g' -e
's:Switch to grub.cfg:Switch to grubtest.cfg:g' < grubtest.cfg >
grub.cfg**\

Delete the grub.cfg that remained inside the ROM:

    $ ./cbfstool libreboot.rom remove -n grub.cfg

Add the modified version that you just made:

    $ ./cbfstool libreboot.rom add -n grub.cfg -f grub.cfg -t raw

**Now you have a modified ROM. Again, refer back to
[../install/\#flashrom](../install/#flashrom) for information on how to
flash it. It's the same method as you used before. Shut down and then
boot up with your new configuration.**

Copyright © 2014, 2015 Leah Rowe <info@minifree.org>\
Copyright © 2015 Jeroen Quint <jezza@diplomail.ch>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% GRUB hardening

This guide deals with various ways in which you can harden your GRUB
configuration, for security purposes. These steps are optional, but
highly recommended by the Libreboot project.

GRUB secure boot with GPG
=========================

This uses the free implementation of the GPG standard for encryption and
signing/verifying data. We will be using this for checking the signature
of a Linux kernel at boot time. More information about GPG can be found
on the [GPG project website](https://www.gnu.org/software/gnupg/). GRUB
has some GPG support built in, for checking signatures.

This tutorial assumes you have a libreboot image (rom) that you wish to
modify, to which we shall henceforth refer to as "my.rom". This
tutorial modifies grubtest.cfg, this means 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 setup, you should transfer the new settings to
grub.cfg to make your machine actually 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

Helpful links:

-   [GRUB manual
    \#security](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 until proven
    otherwise.](https://libreboot.org/faq/#firmware-hddssd)
-   [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 good in that it allows you to occasionally boot unsigned liveCDs
and such. You may think of supplying signatures on an usb key, but the
signature checking code currently looks for
</path/to/filename>.sig when verifying </path/to/filename>
and as such it is not possible to supply signatures in an alternate
location.

Note that this is not your LUKS password, but it's a password that you
have to enter in order to use "restricted" functionality (such as
console). This protects your system from an attacker simply booting a
live USB and re-flashing your firmware. **This should be different than
your LUKS passphrase and user password.**

Use of the *diceware method* is recommended, for generating secure
passphrases (as opposed to passwords). Diceware method involves using
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*).

-->
The GRUB password can be entered in two ways:

-   plaintext
-   protected with [PBKDF2](https://en.wikipedia.org/wiki/Pbkdf2)

We will (obviously) use the later. 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:
    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 got for
the password that you entered. Meaning, not the hash that you see above!

As enabling password protection as above means that you have to input it
on every single boot, we will make one menu entry work without it.
Remember that we will have GPG signing active, thus a potential attacker
will not be able to boot an arbitrary operating system. We do this by
adding option **--unrestricted** to a menuentry definition:

    menuentry 'Load Operating System (incl. fully encrypted disks)  [o]' --hotkey='o' --unrestricted {
    ...

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
    }

Why? We allowed booting normally without entering a password above. When
we unset superusers and then load a signed GRUB configuration file, we
can easily use the command line as password protection will be
completely disabled. Disabling signature checking and booting whatever
an attacker wants is then just a few GRUB commands away.

As far as basic password setup is concerned we are done and we can now
move on to signing.

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

    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 have to sign:

-   a kernel
-   (if we have one) an initramfs
-   (if we wish to transfer control to it) an on-disk grub.cfg
-   grubtest.cfg (this is so one 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 sign them by issuing 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 have 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 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

\... and flashing it.

Copyright © 2017 Fedja Beader <fedja@protonmail.ch>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)

repo_name: ctag/libreboot

license: mit


code:
% GRUB

-   [How to install GNU+Linux on a libreboot system](grub_boot_installer.html)
-   [How to replace the default GRUB configuration file on a libreboot
    system](grub_cbfs.html)
-   [How to harden your GRUB configuration, for security](grub_hardening.html)
-   [Changing the background image in GRUB](#grub_background)
-   [Setting font in GRUB](#grub_font)
-   [GRUB keyboard layouts](#grub_keyboard)
    -   [Custom keyboard layout in GRUB](#grub_custom_keyboard)
    -   [UK Dvorak keyboard layout in GRUB](#grub_ukdvorak_keyboard)

Changing the background image in GRUB {#grub_background}
=====================================

Use cbfstool from libreboot\_util, or
libreboot\_src/coreboot/util/cbfstool/ if you want to build from source.

./cbfstool yourrom.rom remove background.png -n background.png\
./cbfstool yourrom.rom add -f background.png -n background.png -t raw

When you've done this, re-flash your ROM and you should have a new
background at boot time.

Setting font in GRUB (for reference) {#grub_font}
====================================

You don't need to do this unless you would like to change the default
font yourself. (this is just for reference. It has already been done for
you)

The old font used was Unifont, and this had some missing characters: for
instance, the border showed ??? characters instead of lines.

I tried DeJavu Sans Mono from this website:
[dejavu-fonts.org](http://dejavu-fonts.org/wiki/Download)

Specifically, the version that I chose was the latest at the time of
writing (Saturday 21 June 2014): [this
one](http://sourceforge.net/projects/dejavu/files/dejavu/2.34/dejavu-fonts-ttf-2.34.tar.bz2)

This is a free font that is also contained in GNU+Linux distributions
like Debian, Devuan or Parabola.

    $ cd libreboot\_src/grub
compile grub (the build scripts info on how to do this)\
come back out into libreboot\_src/resources/grub:

    $ cd ../libreboot\_src/resources/grub/font

I took Dejavu Sans Mono from dejavu (included in this version of
libreboot) and did:\
**\$ ../../../grub/grub-mkfont -o dejavusansmono.pf2
dejavu-fonts-ttf-2.34/ttf/DejaVuSansMono.ttf**

I then added the instructions to 'gen.sh' script in grub-assemble to
include resources/grub/dejavusansmono.pf2 in all of the ROM images, at
the root of the GRUB memdisk.\
I then added that instructions to the grub.cfg files (to load the
font):\
**loadfont (memdisk)/dejavusansmono.pf2**

GRUB keyboard layouts (for reference) {#grub_keyboard}
=====================================

Custom keyboard layout in GRUB (for reference) {#grub_custom_keyboard}
----------------------------------------------

Keymaps are stored in resources/utilities/grub-assemble/keymap/.

Example (French Azerty):

    $ ckbcomp fr > frazerty
\
Go in grub directory:\
**cat frazerty | ./grub/grub-mklayout -o frazerty.gkb**

You must make sure that the files are named keymap and keymap.gkb (where
'keymap' can be whatever you want).

Then from the above example, you would put **frazerty** in
**resources/utilities/grub-assemble/keymap/original/** and the
**frazerty.gkb** file goes under
**resources/utilities/grub-assemble/keymap/**

The build scripts will automatically see this, and automatically build
ROM images with your custom layout (given the name) and include them
under bin. Example: **libreboot\_frazerty.rom**.

UK Dvorak keyboard layout in GRUB (for reference) {#grub_ukdvorak_keyboard}
-------------------------------------------------

ukdvorak had to be created manually, based on usdvorak. diff them (under
resources/utilities/grub-assemble/keymap/original) to see how ukdvorak
file was created

    $ cat ukdvorak | ./grub/grub-mklayout -o ukdvorak.gkb

Copyright © 2014, 2015 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% ASUS Chromebook C201

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

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

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

Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)

-   [Google's intent with CrOS devices](#googlesintent)
-   [Considerations about ChromeOS and free operating systems](#os)
-   [Caution: Video acceleration requires a non-free blob, software
    rendering can be used instead.](#videoblobs)
-   [Caution: WiFi requires a non-free blob, a USB dongle can be used
    instead.](#wifiblobs)
-   [EC firmware is free software!](#ec)
-   [No microcode!](#microcode)
-   [Depthcharge payload](#depthcharge)
-   [Flash chip write protection: the screw](#thescrew)

Google's intent with CrOS devices {#googlesintent}
==================================

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

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

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

Considerations about ChromeOS and free operating systems {#os}
========================================================

This laptop comes preinstalled (from the factory) with Google ChromeOS.
This is a GNU+Linux distribution, but it's not general purpose and it
comes with proprietary software. It's designed for SaaSS. Libreboot
recommends that users of this laptop replace it with another
distribution.

Debian GNU+Linux
----------------

<https://wiki.debian.org/InstallingDebianOn/Asus/C201> shows how to
install Debian.

TODO: instructions for Devuan

Caution: Video acceleration requires a non-free blob, software rendering can be used instead. {#videoblobs}
=============================================================================================

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

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

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

Caution: WiFi requires a non-free blob, a USB dongle can be used instead. {#wifiblobs}
=========================================================================

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

The libreboot project recommends using an external USB wifi dongle that
works with free software. See
[\#recommended\_wifi](./#recommended_wifi).

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

-   [ThinkPenguin sells
    them](https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb)
    (company based in USA)
-   [Tehnoetic sells
    them](https://tehnoetic.com/tehnoetic-wireless-adapter-gnu-linux-libre-tet-n150)
    (company based in Europe)

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

EC firmware is free software! {#ec}
=============================

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

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

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

No microcode! {#microcode}
=============

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

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

Depthcharge payload {#depthcharge}
===================

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

Flash chip write protection: the screw {#thescrew}
======================================

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

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

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

Copyright © 2015 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)
% ASUS Chromebook C201 installation guide

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

**If you are using libreboot\_src or git, then make sure that you built
the sources first (see [../git/\#build](../git/#build)).**

Look at the [list of ROM images](#rom) to see which image is compatible
with your device.

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

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

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

-   [Gaining root privileges on ChromeOS](#root_chromeos)
-   [Preparing the device for the installation](#preparing_device)
    -   [Configuring verified boot
        parameters](#configuring_verified_boot_parameters)
    -   [Removing the write protect
        screw](#removing_write_protect_screw)
-   [Installing Libreboot to the SPI flash]()
    -   [Installing Libreboot internally, from the
        device](#installing_libreboot_internally)
    -   [Installing Libreboot externally, with a SPI flash
        programmer](#installing_libreboot_externally)
-   [Debian GNU+Linux is recommended for this device](#debian)

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

Instructions to access the [recovery mode
screen](../depthcharge/#recovery_mode_screen) and [enabling developer
mode](../depthcharge/#enabling_developer_mode) are available on the page
dedicated to [depthcharge](../depthcharge/).

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

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

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

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

Configuring verified boot parameters {#configuring_verified_boot_parameters}
------------------------------------

It is recommended to have access to the [developer mode
screen](../depthcharge/#developer_mode_screen) and to [configure the
following verified boot
parameters](../depthcharge/#configuring_verified_boot_parameters):

-   Kernels signature verification: *disabled*
-   External media boot: *enabled*

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

Removing the write protect screw {#removing_write_protect_screw}
--------------------------------

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

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

[![Screws](images/c201/screws.jpg)](images/c201/screws.jpg) [![WP
screw](images/c201/wp-screw.jpg)](images/c201/wp-screw.jpg)

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

Installing Libreboot to the SPI flash {#installing_libreboot_spi_flash}
=====================================

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

Installing Libreboot internally, from the device {#installing_libreboot_internally}
------------------------------------------------

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

All the files from the **veyron\_speedy** release (or build) have to be
transferred to the device.

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

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

Then, the **cros-flash-replace** script has to be executed as such:

    # ./cros-flash-replace flash.img coreboot ro-frid
If any error is shown, it is definitely a bad idea to go further than
this point.

The resulting flash image can then be flashed back:

    # flashrom -p host -w flash.img

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

Shut down. The device will now boot to Libreboot.

Installing Libreboot externally, with a SPI flash programmer {#installing_libreboot_externally}
------------------------------------------------------------

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

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

[![SPI flash
layout](images/c201/spi-flash-layout.jpg)](images/c201/spi-flash-layout.jpg)
[![Battery
connector](images/c201/battery-connector.jpg)](images/c201/battery-connector.jpg)

All the files from the **veyron\_speedy** release (or build) have to be
transferred to the host.

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

    # chmod a+x cros-flash-replace

The SPI flash has to be read first (using the right spi programmer):

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

Then, the **cros-flash-replace** script has to be executed as such:

    # ./cros-flash-replace flash.img coreboot ro-frid
If any error is shown, it is definitely a bad idea to go further than
this point.

The resulting flash image can then be flashed back (using the right spi
programmer):

    # flashrom -p *programmer* -w flash.img

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

The device will now boot to Libreboot.

Installing Debian
---------------------
Debian is recommended for this device (which is on that list.

See <https://wiki.debian.org/InstallingDebianOn/Asus/C201>.

Copyright © 2015 Paul Kocialkowski <contact@paulk.fr>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% Intel D510MO desktop board

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

NOTE: This board has a working framebuffer in Grub, but in GNU+Linux in
native resolution the display is unusable due to some raminit issues.
This board can however be used for building a headless server.

Flashing instructions can be found at
[../install/d510mo.html](../install/d510mo.html)

Copyright © 2016 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)
% D510MO flashing tutorial

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

Flash chip size {#flashchips}
===============

Use this to find out:
    # flashrom -p internal -V

Flashing instructions {#clip}
=====================

Refer to [bbb\_setup.html](bbb_setup.html) for how to set up the BBB for
flashing.

This is an image of the flash chip, for reference:\
![](../images/d510mo/d510mo.jpg)

Copyright © 2016 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% Intel D945GCLF desktop board

[Back to previous index](https://libreboot.org/docs/hcl/)

If you just want flashing instructions, go to
[../install/d945gclf.html](https://libreboot.org/docs/install/d945gclf.html)

This board is a mini-itx desktop board for 2008. It uses an atom 230,
which is a singe core CPU but it is hyperthreaded so it appears to have
2 thread to the OS. The flash chip is very small, 512KiB, so grub2 does
not fit, which is why libreboot has to use seabios on this target. Full
disk encryption like on other supported targets will not be possible, so
plan accordingly.

This board has a 945gc chipset which is the desktop equivalent of 945gm
which can be found in the Lenovo x60/t60 or macbook2,1. This chipset
features an ICH7 southbridge. It has 1 DIMM slot that can accommodate up
to 2G of DDR2 RAM.

Connectivity-wise it has 1 PCI slot, a 10/100 ethernet port, 4 usb slot
and 4 usb ports, with one internal header and 2 SATA ports.

The D945GCLF2 is an upgraded version of this board. The differences are:
1 more USB header, 10/100/1000 ethernet and a dual core cpu (also
hyperthreaded). Since the board is almost identical (and coreboot code
seem to indicate that it works, since MAX\_CPU=4 is set), it is believed
that it should also work but this is untested.

Remarks about vendor bios:
--------------------------

-   Without coreboot/libreboot this board is utery useless, since the
    vendor bios is very bad. It cannot boot from any HDD wether 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:\
![](../images/d945gclf/d945gclf.jpg)\
Here is an image of the D945GCLF2 board:\
![](../images/d945gclf/20160923_141521.jpg){width="80%" height="80%"}\
And SPI SOIC8 flash chip\
![](../images/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\
![](../images/d945gclf/20160923_141620.jpg){width="50%" height="50%"}
![](../images/d945gclf/20160923_141614.jpg){width="50%" height="50%"}\
Make sure that new one has same wiring\
![](../images/d945gclf/20160923_142618.jpg){width="50%" height="50%"}\
This is a new one, with bearing and maintenable\
![](../images/d945gclf/20160923_141738.jpg){width="50%" height="50%"}
![](../images/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)\
![](../images/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)\
![](../images/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)\
![](../images/d945gclf/20160923_141659.jpg){width="50%" height="50%"}\
After that, assemble your new fan into CPU cooler\
![](../images/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.

Copyright © 2016 Arthur Heymans <arthur@aheymans.xyz>\
Copyright © 2016 Vitaly Castaño Solana <vita\_cell@hotmail.com>\
Permission is granted to copy, distribute and/or modify this document
under the terms of the Creative Commons Attribution-ShareAlike 4.0
International license or any later version published by Creative
Commons; A copy of the license can be found at
[../cc-by-sa-4.0.txt](https://libreboot.org/docs/cc-by-sa-4.0.txt)

Updated versions of the license (when available) can be found at
<https://creativecommons.org/licenses/by-sa/4.0/legalcode>

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

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

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

% Intel D945GCLF flashing tutorial

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

For information about this board, go to
[../hcl/d945gclf.html](../hcl/d945gclf.html)

Flashing instructions {#clip}
=====================

Refer to [bbb\_setup.html](bbb_setup.html) for how to set up the BBB for
external flashing.

Here is an image of the flash chip:\
![](../images/d945gclf/d945gclf_spi.jpg)

Copyright © 2016 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% Gigabyte GA-G41M-ES2L desktop board

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

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

You need to set a custom MAC address in GNU+Linux for the NIC to work.
In /etc/network/interfaces on debian-based systems like Debian or
Devuan, this would be in the entry for your NIC:\
hwaddress ether macaddressgoeshere

Flashing instructions can be found at
[../install/\#flashrom](../install/#flashrom)

Copyright © 2016 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)
% GA-G41M-ES2L flashing tutorial

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

Flash chip size {#flashchips}
===============

Use this to find out:
    # flashrom -p internal -V

Flashing instructions {#clip}
=====================

Refer to [bbb\_setup.html](bbb_setup.html) for how to set up the BBB 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 2 test
clips (you also need to connect GND on the chip that you're
disabling).**

Here is an image of the flash chip:\
![](../images/ga-g41m-es2l/ga-g41m-es2l.jpg)

Internal flashing is possible. Boot with the proprietary BIOS and
GNU+Linux. There are 2 flash chips (one is backup).

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

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

NOTE: you can still boot the system with just the main flash chip
connected, after desoldering the backup chip. This has been tested while
libreboot was already installed onto the main chip.

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

NOTE: due to a bug in the hardware, the MAC address is hardcoded in
coreboot-libre. Therefore, you must set your own MAC address in your
operating system.

Copyright © 2016 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
% GM45 chipsets: remove the ME (manageability engine)

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

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

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

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

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

ICH9 gen utility {#ich9gen}
================

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

ich9gen executables can be found under ./ich9deblob/ statically compiled
in libreboot\_util. If you are using src or git, build ich9gen from
source with:
    $ ./oldbuild module ich9deblob

The executable will appear under resources/utilities/ich9deblob/

Run:
    $ ./ich9gen

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

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

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

On GM45 laptops that use flash descriptors, the MAC address or the
onboard ethernet chipset is flashed (inside the ROM image). You should
generate a descriptor+gbe image with your own MAC address inside (with
the Gbe checksum updated to match). Run:

    $ ./ich9gen --macaddress XX:XX:XX:XX:XX:XX
(replace the XX chars with the hexadecimal chars in the MAC address that
you want)

Two new files will be created:

-   **ich9fdgbe\_4m.bin**: this is for GM45 laptops with the 4MB flash
    chip.
-   **ich9fdgbe\_8m.bin**: this is for GM45 laptops with the 8MB flash
    chip.
-   **ich9fdgbe\_16m.bin**: this is for GM45 laptops with the 16MB flash
    chip.

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

Your libreboot.rom image is now ready to be flashed on the system. Refer
back to [../install/\#flashrom](../install/#flashrom) for how to flash
it.

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

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

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

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

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

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

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

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

For external flashing guides, refer to [../install/](../install/).

ICH9 deblob utility {#ich9deblob}
===================

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

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

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

If you are working with libreboot\_src (or git), you can find the source
under resources/utilities/ich9deblob/ and will already be compiled if
you ran **./oldbuild module all** or **./oldbuild module ich9deblob**
from the main directory (./), otherwise you can build it like so:

    $ ./oldbuild module ich9deblob
An executable file named **ich9deblob** will now appear under
resources/utilities/ich9deblob/

If you are working with libreboot\_util release archive, you can find
the utility included, statically compiled (for i686 and x86\_64 on
GNU+Linux) under ./ich9deblob/.

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

    $ ./ich9deblob

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

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

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

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

The utility will also generate 4 additional files:

-   mkdescriptor.c
-   mkdescriptor.h
-   mkgbe.c
-   mkgbe.h

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

You should now have a **libreboot.rom** image containing the correct 4K
descriptor and 8K gbe regions, which will then be safe to flash. Refer
back to [../install/\#flashrom](../install/#flashrom) for how to flash
it.

demefactory utility {#demefactory}
===================

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

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

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

    $ ./demefactory

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

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

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

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

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

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

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)**
    [images/x200/gpio33\_location.jpg](images/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}
-----------

-   Schematics for X200 laptop:
    <http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006075.pdf>
    **~~- Page 20 and page 9 refer to SDA\_HDO or SDA\_HDOUT~~** only on
    series 6 or higher chipsets. ICH9-M (X200) does it with a strap
    connected to GPIO33 pin (see IRC notes below)

    - According to page 29, the X200 can have any of the following flash
    chips:
    -   ATMEL AT26DF321-SU 72.26321.A01 - this is a 32Mb (4MiB) chip
    -   MXIC (Macronix?) MX25L3205DM2I-12G 72.25325.A01 - another 32Mb
        (4MiB) chip
    -   MXIC (Macronix?) MX25L6405DMI-12G 41R0820AA - this is a 64Mb
        (8MiB) chip
    -   Winbond W25X64VSFIG 41R0820BA - another 64Mb (8MiB) chip

    sgsit says that the X200s with the 64Mb flash chips are (probably)
    the ones with AMT (alongside the ME), whereas the 32Mb chips contain
    only the ME.
-   Schematics for X200s laptop:
    <http://pdf.datasheetarchive.com/indexerfiles/Datasheets-USER/DSAUPLD00006104.pdf>.

Early development notes {#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://communities.intel.com/community/wired/blog/2010/10/14/how-to-basic-eeprom-checksums>

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

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

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

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

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

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

Flash descriptor region {#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.

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.

Copyright © 2014, 2015 Leah Rowe <info@minifree.org>\
This page is available under the [CC BY SA 4.0](../cc-by-sa-4.0.txt)


code:
# 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


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


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


code:
# 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


code: bash: ectool: command not found


code:
========================================================================
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.