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

use tabs for command lines

hslick-master
Leah Rowe 2023-01-08 01:22:04 +00:00
parent 8cd02cdd01
commit ff260b4f1c
36 changed files with 596 additions and 547 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
site/docs/bsd/index.md
View File

@ -97,17 +97,17 @@ you can use X11/Wayland in FreeBSD (and just X11 in OpenBSD, for now).
For example: on FreeBSD, you can install `graphics/drm-kmod` as a package
or from ports, and (for Intel GPUs) do this:
sysrc kld_list+="i915kms"
sysrc kld_list+="i915kms"
This creates the following entry in `/etc/rc.conf`:
kld_list="i915kms"
kld_list="i915kms"
On FreeBSD it is also recommended that you switch to KMS on the console/TTY;
add this to `/boot/loader.conf` so that you can still use the console after
terminating Xorg:
kern.vty=vt
kern.vty=vt
You should not rely on the above instruction (for FreeBSD), because the exact
step might change, and it does not go into full detail either. Refer to the

96
site/docs/build/index.md vendored
View File

@ -30,8 +30,8 @@ Git extensively, when downloading software like coreboot and patching it.
You should make sure to initialize your Git properly, before you begin or else
the build system will not work properly. Do this:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Change the name and email address to whatever you want, when doing this.
@ -56,28 +56,28 @@ ROM images (it just builds all of them, for all boards).
You must ensure that all build dependencies are installed. If you're running
Ubuntu or similar distribution (Debian, Trisquel, etc) you can do this:
sudo make install-dependencies-ubuntu
sudo make install-dependencies-ubuntu
One exists specifically for Debian:
sudo make install-dependencies-debian
sudo make install-dependencies-debian
Another exists for Arch:
sudo make install-dependencies-arch
sudo make install-dependencies-arch
Now, simply build the coreboot images like so:
make
make
This single command will build ROM images for *every* board integrated in
libreboot. If you only wish to build a limited set, you can use `lbmk` directly:
./build boot roms x200_8mb
./build boot roms x200_8mb
You can specify more than one argument:
./build boot roms x200_8mb x60
./build boot roms x200_8mb x60
ROM images appear under the newly created `bin/` directory in the build system.
@ -87,15 +87,15 @@ easy to know what commands are available by simply reading it.
Standard `clean` command available (cleans all modules except `crossgcc`):
make clean
make clean
To clean your `crossgcc` builds:
make crossgcc-clean
make crossgcc-clean
To build release archives:
make release
make release
Build without using GNU Make
============================
@ -114,40 +114,40 @@ libreboot includes a script that automatically installs apt-get dependencies
in Ubuntu 20.04. It works well in other apt-get distros (such as Trisquel and
Debian):
sudo ./build dependencies ubuntu2004
sudo ./build dependencies ubuntu2004
Separate scripts also exist:
sudo ./build dependencies debian
sudo ./build dependencies debian
sudo ./build dependencies arch
sudo ./build dependencies arch
sudo ./build dependencies void
sudo ./build dependencies void
Technically, any GNU+Linux distribution can be used to build libreboot.
However, you will have to write your own script for installing build
dependencies.
libreboot Make (lbmk) automatically runs all necessary commands; for example
`./build payload grub` will automatically run `./build module grub` if the
required utilities for GRUB are not built, to produce payloads.
libreboot Make (lbmk) automatically runs all necessary commands; for
example, `./build payload grub` will automatically run `./build module grub`
if the required utilities for GRUB are not built, to produce payloads.
As a result, you can now (after installing the correct build dependencies) run
just a single command, from a fresh Git clone, to build the ROM images:
./build boot roms
./build boot roms
or even just build specific ROM images, e.g.:
./build boot roms x60
./build boot roms x60
If you wish to build payloads, you can also do that. For example:
./build payload grub
./build payload grub
./build payload seabios
./build payload seabios
./build payload u-boot qemu_x86_12mb
./build payload u-boot qemu_x86_12mb
Previous steps will be performed automatically. However, you can *still* run
individual parts of the build system manually, if you choose. This may be
@ -185,26 +185,26 @@ any script, it's a bug that should be fixed).
It's as simple as that:
./download all
./download all
The above command downloads all modules defined in the libreboot build system.
However, you can download modules individually.
This command shows you the list of available modules:
./download list
./download list
Example of downloading an individual module:
./download coreboot
./download coreboot
./download seabios
./download seabios
./download grub
./download grub
./download flashrom
./download flashrom
./download u-boot
./download u-boot
Third, build all of the modules:
--------------------------------
@ -215,65 +215,65 @@ such as this, so you must verify this yourself.
Again, very simple:
./build module all
./build module all
This builds every module defined in the libreboot build system, but you can
build modules individually.
The following command lists available modules:
./build module list
./build module list
Example of building specific modules:
./build module grub
./build module grub
./build module seabios
./build module seabios
./build module flashrom
./build module flashrom
Commands are available to *clean* a module, which basically runs make-clean.
You can list these commands:
./build clean list
./build clean list
Clean all modules like so:
./build clean all
./build clean all
Example of cleaning specific modules:
./build clean grub
./build clean grub
./build clean cbutils
./build clean cbutils
Fourth, build all of the payloads:
---------------------------------
Very straight forward:
./build payload all
./build payload all
You can list available payloads like so:
./build payload list
./build payload list
Example of building specific payloads:
./build payload grub
./build payload grub
./build payload seabios
./build payload seabios
Each board has its own U-Boot build configuration in `lbmk` under
`resources/u-boot`. To build U-Boot payloads, you need to specify the
target board and maybe a cross compiler for its CPU architecture. These
are handled automatically when building ROM images, but for example:
./build payload u-boot qemu_x86_12mb # on x86 hosts
./build payload u-boot qemu_x86_12mb # on x86 hosts
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=aarch64-linux-gnu- ./build payload u-boot gru_kevin
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
CROSS_COMPILE=arm-linux-gnueabi- ./build payload u-boot veyron_speedy
The build-payload command is is a prerequsite for building ROM images.
@ -282,7 +282,7 @@ Fifth, build the ROMs!
Run this command:
./build boot roms
./build boot roms
Each board has its own configuration in `lbmk` under `resources/coreboot/`
which specifies which payloads are supported.
@ -291,7 +291,7 @@ By default, all ROM images are built, for all boards. If you wish to build just
a specific board, you can specify the board name based on the directory name
for it under `resources/coreboot/`. For example:
./build boot roms x60
./build boot roms x60
Board names, like above, are the same as the directory names for each board,
under `resources/coreboot/` in the build system.

50
site/docs/gnulinux/grub_boot_installer.md
View File

@ -24,18 +24,18 @@ to create the bootable GNU+Linux USB drive:
Connect the USB drive. Check `lsblk`, to confirm its device name
(e.g., **/dev/sdX**):
lsblk
lsblk
For this example, let's assume that our drive's name is `sdb`. Make sure that
it's not mounted:
sudo umount /dev/sdb
sudo umount /dev/sdb
Overwrite the drive, writing your distro ISO to it with `dd`. For example, if
we are installing *Foobarbaz* GNU+Linux, and it's located in our Downloads
folder, this is the command we would run:
sudo dd if=~/Downloads/foobarbaz.iso of=/dev/sdb bs=8M; sync
sudo dd if=~/Downloads/foobarbaz.iso of=/dev/sdb bs=8M; sync
That's it! You should now be able to boot the installer from your USB drive
(the instructions for doing so will be given later).
@ -58,22 +58,22 @@ create the bootable GNU+Linux USB drive:
Connect the USB drive. Run `lsblk` to determine which drive it is:
lsblk
lsblk
To confirm that you have the correct drive, use `disklabel`. For example,
if you thought the correct drive were **sd3**, run this command:
disklabel sd3
disklabel sd3
Make sure that the device isn't mounted, with `doas`; if it is, this command
will unmount it:
doas umount /dev/sd3i
doas umount /dev/sd3i
The `lsblk` command told you what device it is. Overwrite the drive, writing
the OpenBSD installer to it with `dd`. Here's an example:
doas dd if=gnulinux.iso of=/dev/rsdXc bs=1M; sync
doas dd if=gnulinux.iso of=/dev/rsdXc bs=1M; sync
That's it! You should now be able to boot the installer from your USB drive
(the instructions for doing so will be given later).
@ -89,18 +89,18 @@ Secondly, create a bootable USB drive using the commands in
Thirdly, boot the USB and enter these commands in the GRUB terminal
(for 64-bit Intel or AMD):
set root='usb0'
linux /install.amd/vmlinuz
initrd /install.amd/initrd.gz
boot
set root='usb0'
linux /install.amd/vmlinuz
initrd /install.amd/initrd.gz
boot
If you are on a 32-bit system (e.g. some Thinkpad X60's) then you will need to
use these commands (this is also true for 32-bit running on 64-bit machines):
set root='usb0'
linux /install.386/vmlinuz
initrd /install.386/initrd.gz
boot
set root='usb0'
linux /install.386/vmlinuz
initrd /install.386/initrd.gz
boot
## Booting ISOLINUX Images (Automatic Method)
Boot it in GRUB using the `Parse ISOLINUX config (USB)` option. A new menu
@ -115,17 +115,17 @@ distribution it is that you are trying to install.
If the `ISOLINUX parser` or `Search for GRUB configuration` options won't work,
then press `C` in GRUB to access the command line, then run the `ls` command:
ls
ls
Get the device name from the above output (e.g., `usb0`). Here's an example:
cat (usb0)/isolinux/isolinux.cfg
cat (usb0)/isolinux/isolinux.cfg
Either the output of this command will be the ISOLINUX menuentries for that
ISO, or link to other `.cfg` files (e.g, **/isolinux/foo.cfg**). For example,
if the file found were **foo.cfg**, you would use this command:
cat (usb0)/isolinux/foo.cg`
cat (usb0)/isolinux/foo.cg`
And so on, until you find the correct menuentries for ISOLINUX.
@ -141,14 +141,16 @@ based on Debian 8.x may also have the same issue.**
Now, look at the ISOLINUX menuentry; it'll look like this:
kernel /path/to/kernel append PARAMETERS initrd=/path/to/initrd ...
kernel /path/to/kernel append PARAMETERS initrd=/path/to/initrd ...
GRUB works similarly; here are some example GRUB commands:
set root='usb0'
linux /path/to/kernel PARAMETERS MAYBE_MORE_PARAMETERS
initrd /path/to/initrd
boot
```
set root='usb0'
linux /path/to/kernel PARAMETERS MAYBE_MORE_PARAMETERS
initrd /path/to/initrd
boot
```
Note: `usb0` may be incorrect. Check the output of the `ls` command (in GRUB),
to see a list of USB devices/partitions. Of course, this will vary from distro
@ -171,7 +173,7 @@ installer results in graphical corruption, because it is trying to switch to a
framebuffer while no mode switching support is present. Use this kernel
parameter on the `linux` line, when booting it:
fb=false
fb=false
This forces debian-installer to start in `text-mode`, instead of trying to
switch to a framebuffer.

22
site/docs/gnulinux/grub_cbfs.md
View File

@ -56,15 +56,15 @@ Install the build dependencies. For Ubuntu 20.04 and similar, you can run
the following command in the libreboot build system, from the root directory
of the libreboot Git repository.
./build dependencies ubuntu2004
./build dependencies ubuntu2004
Then, download coreboot:
./download coreboot
./download coreboot
Finally, compile the `cbutils` module:
./build module cbutils
./build module cbutils
Among other things, this will produce a `cbfstool` executable under any of the
subdirectories in `coreboot/` under `util/cbfstool/cbfstool
@ -79,7 +79,7 @@ You will also want to build `flashrom` which libreboot recommends for reading
from and/or writing to the boot flash. In the libreboot build system, you can
build it by running this command:
./build module flashrom
./build module flashrom
An executable will be available at `flashrom/flashrom` after you have done
this.
@ -93,7 +93,7 @@ your computer, you can use `flashrom` to acquire it.
Simply run the following, after using libreboot's build system to compile
flashrom:
sudo ./flashrom/flashrom -p internal -r dump.bin
sudo ./flashrom/flashrom -p internal -r dump.bin
If flashrom complains about multiple flash chip definitions, do what it says to
rectify your command and run it again.
@ -135,11 +135,11 @@ acquired).
Show the contents of CBFS, in your ROM:
cbfstool dump.bin print
cbfstool dump.bin print
Extract `grub.cfg` (substitude with `grubtest.cfg` as desired):
cbfstool dump.bin extract -n grub.cfg -f grub.cfg
cbfstool dump.bin extract -n grub.cfg -f grub.cfg
You will now have a file named `grub.cfg`.
@ -151,11 +151,11 @@ Insert new grub.cfg
Remove the old `grub.cfg` (substitute with `grubtest.cfg` as desired):
cbfstool dump.bin remove -n grub.cfg
cbfstool dump.bin remove -n grub.cfg
Add your modified `grub.cfg` (substitute with `grubtest.cfg` as desired):
cbfstool dump.bin add -f grub.cfg -n grub.cfg -t raw
cbfstool dump.bin add -f grub.cfg -n grub.cfg -t raw
Flash the modified ROM image
============================
@ -163,7 +163,7 @@ Flash the modified ROM image
Your modified `dump.bin` or other modified libreboot ROM can then be re-flashed
using:
sudo ./flashrom -p internal -w dump.bin
sudo ./flashrom -p internal -w dump.bin
If a `-c` option is required, use it and specify a flash chip name. This is
only useful when `flashrom` complains about multiple flash chips being
@ -173,7 +173,7 @@ If flashrom complains about wrong chip/board, make sure that your ROM is for
the correct system. If you're sure, you can disable the safety checks by running
this instead:
sudo ./flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w dump.bin
sudo ./flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w dump.bin
If you need to use external flashing equipment, see the link above to the
Raspberry Pi page.

82
site/docs/gnulinux/grub_hardening.md
View File

@ -75,21 +75,21 @@ machine truly secure.
First, extract the old grubtest.cfg and remove it from the libreboot
image:
cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
cbfstool my.rom remove -n grubtest.cfg
cbfstool my.rom extract -n grubtest.cfg -f my.grubtest.cfg
cbfstool my.rom remove -n grubtest.cfg
You can build `cbfstool` in the libreboot build system. Run this command:
./build module cbutils
./build module cbutils
This assumes that you already downloaded coreboot:
./download coreboot
./download coreboot
This, in turn, assumes that you have installed the build dependencies for
libreboot. On Ubuntu 20.04 and other apt-get distros, you can do this:
./build dependencies ubuntu2004
./build dependencies ubuntu2004
The `cbfstool` executables will be under each coreboot directory, under
each `coreboot/boardname/` directory for each board. Just pick one, presumably
@ -109,7 +109,7 @@ 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
set check_signatures=no
This is useful because it allows you to occasionally boot unsigned live CD/USB
media and such. You might consider supplying signatures on a USB stick, but the
@ -156,24 +156,24 @@ GRUB using the libreboot build system. Run the following commands (assuming
you have the correct build dependencies installed) to build GNU GRUB, from the
libreboot Git repository:
./download grub
./download grub
./build module grub
./build module grub
The following executable will then be available under the `grub/` directory:
grub-mkpasswd-pbkdf2
grub-mkpasswd-pbkdf2
Its output will be a string of the following form:
grub.pbkdf2.sha512.10000.HEXDIGITS.MOREHEXDIGITS
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
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.711F186347156BC105CD83A2ED7AF1EB971AA2B1EB2640172F34B0DEFFC97E654AF48E5F0C3B7622502B76458DA494270CC0EA6504411D676E6752FD1651E749.8DD11178EB8D1F633308FD8FCC64D0B243F949B9B99CCEADE2ECA11657A757D22025986B0FA116F1D5191E0A22677674C994EDBFADE62240E9D161688266A711
Obviously, replace it with the correct hash that you actually obtained for the
password you entered. In other words, *do not use the hash that you see above!*
@ -194,17 +194,19 @@ 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
}
```
function try_user_config {
set root="${1}"
for dir in boot grub grub2 boot/grub boot/grub2; do
for name in '' autoboot_ libreboot_ coreboot_; do
if [ -f /"${dir}"/"${name}"grub.cfg ]; then
#unset superusers
configfile /"${dir}"/"${name}"grub.cfg
fi
done
done
}
```
The `unset superusers` command disables password authentication, which will
allow the attacker to boot an arbitrary operating system, regardless of
@ -225,10 +227,12 @@ is ok.
WARNING: GRUB does not read ASCII armored keys. When attempting to
trust ... a key filename it will print `error: bad signature` on the screen.
mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key
```
mkdir --mode 0700 keys
gpg --homedir keys --gen-key
gpg --homedir keys --export-secret-keys --armor > boot.secret.key # backup
gpg --homedir keys --export > boot.key
```
Now that we have a key, we can sign some files with it. We must sign:
@ -243,23 +247,29 @@ Suppose that we have a pair of `my.kernel` and `my.initramfs` and an
on-disk `libreboot_grub.cfg`. We will sign them by running the following
commands:
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign libreboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
```
gpg --homedir keys --detach-sign my.initramfs
gpg --homedir keys --detach-sign my.kernel
gpg --homedir keys --detach-sign libreboot_grub.cfg
gpg --homedir keys --detach-sign my.grubtest.cfg
```
Of course, some further modifications to my.grubtest.cfg will be required. We
need to *trust* the key and enable signature enforcement (put this before menu
entries):
trust (cbfsdisk)/boot.key
set check_signatures=enforce
```
trust (cbfsdisk)/boot.key
set check_signatures=enforce
```
What remains now is to include the modifications into the libreboot image
(ROM):
cbfstool my.rom add -n boot.key -f boot.key -t raw
cbfstool my.rom add -n grubtest.cfg -f my.grubtest.cfg -t raw
cbfstool my.rom add -n grubtest.cfg.sig -f my.grubtest.cfg.sig -t raw
```
cbfstool my.rom add -n boot.key -f boot.key -t raw
cbfstool my.rom add -n grubtest.cfg -f my.grubtest.cfg -t raw
cbfstool my.rom add -n grubtest.cfg.sig -f my.grubtest.cfg.sig -t raw
```
Now, flash it. If it works, copy it over to `grub.cfg` in CBFS.

16
site/docs/gnulinux/index.md
View File

@ -47,10 +47,12 @@ If you do want encrypted /boot in your distro, please ensure that you have
downgraded to LUKSv1, and generic advice for booting is this (press C to
access a GRUB terminal, when you're in the GRUB payload):
set root=`lvm/bla-bla`
linux /vmlinuz root=/dev/mapper/bla-bla cryptdevice=/dev/mapper/bla-bla:root
initrd /initrd.img
boot
```
set root=`lvm/bla-bla`
linux /vmlinuz root=/dev/mapper/bla-bla cryptdevice=/dev/mapper/bla-bla:root
initrd /initrd.img
boot
```
Adapt according to your configuration.
@ -91,7 +93,7 @@ Open `/etc/grub.d/10_linux`
Set the `sixteenbit` variable to an empty string, then run:
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg
BLS issue
---------
@ -101,8 +103,8 @@ scripts from grub package default to generating [BLS](https://www.freedesktop.or
instead of `grub.cfg`. To change that behaviour add following line
to `/etc/default/grub` (or modify existing one if it already exists):
GRUB_ENABLE_BLSCFG=false
GRUB_ENABLE_BLSCFG=false
Then generate `grub.cfg` with:
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-mkconfig -o /boot/grub2/grub.cfg

4
site/docs/grub/index.md
View File

@ -28,7 +28,7 @@ Keymaps are stored in `resources/grub/keymap/`
You can use the `ckbcomp` program to generate a keymap, based on Xorg keymap
files:
ckbcomp fr > frazerty
ckbcomp fr > frazerty
When you build GRUB from source, you can use the `grub-mklayout` program to
create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
@ -36,7 +36,7 @@ create a special keymap file for GRUB. [Learn how to build GRUB](../build/)
When you've built GRUB, using `lbmk` (libreboot build system), take your kepmap
file (generated by ckbcomp) and run it through `grub-mklayout` like so:
cat frazerty | ./grub/grub-mklayout -o frazerty.gkb
cat frazerty | ./grub/grub-mklayout -o frazerty.gkb
Place the newly created `.gkb` file under `resources/grub/keymap` in lbmk. When
you build libreboot, a ROM image with GRUB payload and your newly created

8
site/docs/hardware/ga-g41m-es2l.md
View File

@ -68,19 +68,19 @@ hwaddress ether macaddressgoeshere
Alternatively:
cbfstool libreboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
cbfstool libreboot.rom extract -n rt8168-macaddress -f rt8168-macaddress
Modify the MAC address in the file `rt8168-macaddress` and then:
cbfstool libreboot.rom remove -n rt8168-macaddress
cbfstool libreboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
cbfstool libreboot.rom remove -n rt8168-macaddress
cbfstool libreboot.rom add -f rt8168-macaddress -n rt8168-macaddress -t raw
Now you have a different MAC address hardcoded. In the above example, the ROM
image is named `libreboot.rom` for your board. You can find cbfstool
under `coreboot/default/util/cbfstool/` after running the following command
in the build system:
./build module cbutils
./build module cbutils
You can learn more about using the build system, lbmk, here:\
[libreboot build instructions](../build/)

4
site/docs/hardware/index.md
View File

@ -110,11 +110,11 @@ How to find what EC version you have (i945/GM45)
In GNU+Linux, you can try this:
grep 'at EC' /proc/asound/cards
grep 'at EC' /proc/asound/cards
Sample output:
ThinkPad Console Audio Control at EC reg 0x30, fw 7WHT19WW-3.6
ThinkPad Console Audio Control at EC reg 0x30, fw 7WHT19WW-3.6
7WHT19WW is the version in different notation, use search engine to find
out regular version - in this case it's a 1.06 for x200 tablet

8
site/docs/hardware/mac_address.md
View File

@ -71,16 +71,16 @@ There are three portable ways of doing so:
1. Using the new iproute2 package:
ip link set <interface> down
ip link set <interface> down
ip link set dev <interface> address 00:4c:69:62:72:65
ip link set dev <interface> address 00:4c:69:62:72:65
ip link set <interface> up
ip link set <interface> up
2. Using the old `ifconfig` command:
ifconfig <interface> hw ether 00:4c:69:62:72:65
ifconfig <interface> hw ether 00:4c:69:62:72:65
3. Using the macchanger package.

109
site/docs/hardware/macbook21.md
View File

@ -103,7 +103,7 @@ Internal flashing
MacBook2,1 can always be flashed internally, even if running Apple firmware:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w your.rom
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w your.rom
The MacBook1,1 can't be flashed internally if running the Apple EFI firmware.
You must flash externally.
@ -239,29 +239,31 @@ Macfanctld is available on the default repos of many distributions.
For example, to install macfanctld on an Arch-based distro (Parabola, ...), you would run as root
pacman -S macfanctld
pacman -S macfanctld
and don't forget to enable it by using `systemctl` or by a script that will run macfanctld if using runit.
Then, you want to install powertop and tlp.
And then, run the following on battery
sudo tlp start && sudo powertop --calibrate
sudo tlp start && sudo powertop --calibrate
Then, after quitting powertop, run :
sudo powertop --auto-tune
sudo powertop --auto-tune
Now, configure tlp, edit the `/etc/tlp.conf` and uncomment/add/modify the following:
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
```
CPU_BOOST_ON_AC=1
CPU_BOOST_ON_BAT=0
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
PLATFORM_PROFILE_ON_AC=performance
PLATFORM_PROFILE_ON_BAT=low-power
PLATFORM_PROFILE_ON_AC=performance
PLATFORM_PROFILE_ON_BAT=low-power
```
The MacBook will still overheat, just less.
@ -275,7 +277,7 @@ right is the keypad enter. We can make it act as an AltGr.
If your operating system is Trisquel or other dpkg-based distribution,
there is an easy solution. Under root (or sudo) run
dpkg-reconfigure keyboard-configuration
dpkg-reconfigure keyboard-configuration
and select the option "apple laptop", leave other settings as their
defaults until you are given the option "Use Keypad Enter as
@ -286,7 +288,7 @@ everywhere.
For Parabola or other systemd-based distributions you can enable AltGr
manually. Simply add the line
KEYMAP_TOGGLE=lv3:enter_switch
KEYMAP_TOGGLE=lv3:enter_switch
to the file /etc/vconsole.conf and then restart the computer.
@ -297,44 +299,45 @@ Linux kernels of version 3.15 or lower might make the touchpad
extremely sluggish. A user reported that they could get better
response from the touchpad with the following in their xorg.conf:
Section "InputClass"
Identifier "Synaptics Touchpad"
Driver "synaptics"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "synaptics"
The next two values determine how much pressure one needs
for tapping, moving the cursor and other events.
Option "FingerLow" "10"
Option "FingerHigh" "15"
Do not emulate mouse buttons in the touchpad corners.
Option "RTCornerButton" "0"
Option "RBCornerButton" "0"
Option "LTCornerButton" "0"
Option "LBCornerButton" "0"
One finger tap = left-click
Option "TapButton1" "1"
Two fingers tap = right-click
Option "TapButton2" "3"
Three fingers tap = middle-mouse
Option "TapButton3" "2"
Try to not count the palm of the hand landing on the touchpad
as a tap. Not sure if helps.
Option "PalmDetect" "1"
The following modifies how long and how fast scrolling continues
after lifting the finger when scrolling
Option "CoastingSpeed" "20"
Option "CoastingFriction" "200"
Smaller number means that the finger has to travel less distance
for it to count as cursor movement. Larger number prevents cursor
shaking.
Option "HorizHysteresis" "10"
Option "VertHysteresis" "10"
Prevent two-finger scrolling. Very jerky movement
Option "HorizTwoFingerScroll" "0"
Option "VertTwoFingerScroll" "0"
Use edge scrolling
Option "HorizEdgeScroll" "1"
Option "VertEdgeScroll" "1"
EndSection
```
Section "InputClass"
Identifier "Synaptics Touchpad"
Driver "synaptics"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "synaptics"
The next two values determine how much pressure one needs
for tapping, moving the cursor and other events.
Option "FingerLow" "10"
Option "FingerHigh" "15"
Do not emulate mouse buttons in the touchpad corners.
Option "RTCornerButton" "0"
Option "RBCornerButton" "0"
Option "LTCornerButton" "0"
Option "LBCornerButton" "0"
One finger tap = left-click
Option "TapButton1" "1"
Two fingers tap = right-click
Option "TapButton2" "3"
Three fingers tap = middle-mouse
Option "TapButton3" "2"
Try to not count the palm of the hand landing on the touchpad
as a tap. Not sure if helps.
Option "PalmDetect" "1"
The following modifies how long and how fast scrolling continues
after lifting the finger when scrolling
Option "CoastingSpeed" "20"
Option "CoastingFriction" "200"
Smaller number means that the finger has to travel less distance
for it to count as cursor movement. Larger number prevents cursor
shaking.
Option "HorizHysteresis" "10"
Option "VertHysteresis" "10"
Prevent two-finger scrolling. Very jerky movement
Option "HorizTwoFingerScroll" "0"
Option "VertTwoFingerScroll" "0"
Use edge scrolling
Option "HorizEdgeScroll" "1"
Option "VertEdgeScroll" "1"
EndSection
```

15
site/docs/install/chromebooks.md
View File

@ -53,8 +53,8 @@ Make sure you back up the original firmware before trying to replace it.
The version of flashrom in ChromeOS understands `host` as a programmer
to flash firmware internally. To back up stock firmware you can run:
sudo flashrom -p host -r depthcharge.rom
sudo flashrom -p host -v depthcharge.rom
sudo flashrom -p host -r depthcharge.rom
sudo flashrom -p host -v depthcharge.rom
Keep the resulting `depthcharge.rom` file safe and properly backed up on
another device.
@ -102,9 +102,9 @@ Disabling the write-protect signal doesn't directly make the chip stop
protecting its data, it just allows you to disable its write-protection
in software. That also needs to be done in ChromeOS afterwards:
sudo flashrom -p host --wp-status
sudo flashrom -p host --wp-disable
sudo flashrom -p host --wp-range 0x0,0x0
sudo flashrom -p host --wp-status
sudo flashrom -p host --wp-disable
sudo flashrom -p host --wp-range 0x0,0x0
The *--wp* arguments are only available on the
[ChromiumOS fork of flashrom](https://sites.google.com/a/chromium.org/dev/chromium-os/packages/cros-flashrom).
@ -141,14 +141,15 @@ documentation if your board supports it.
To flash the entire ROM image internally, run within ChromeOS:
sudo flashrom -p host -w libreboot.rom
sudo flashrom -p host -v libreboot.rom
sudo flashrom -p host -w libreboot.rom
sudo flashrom -p host -v libreboot.rom
If you can already boot a conventional Linux distro on your Chromebook,
you may be able to use `flashrom -p linux_mtd` on that system instead.
See also
========
* [ChromiumOS Documentation](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/)
* [ChromiumOS Firmware Test Manual](https://chromium.googlesource.com/chromiumos/docs/+/HEAD/firmware_test_manual.md)
* [ChromiumOS Flashrom Fork Information](https://www.chromium.org/chromium-os/packages/cros-flashrom/)

2
site/docs/install/d510mo.md
View File

@ -12,7 +12,7 @@ Flash chip size {#flashchips}
Use this to find out:
flashrom -p internal
flashrom -p internal
Flashing instructions {#clip}
=====================

6
site/docs/install/ga-g41m-es2l.md
View File

@ -22,7 +22,7 @@ Flash chip size {#flashchips}
Use this to find out:
flashrom -p internal
flashrom -p internal
Flashing instructions {#clip}
=====================
@ -52,11 +52,11 @@ GNU+Linux. There are 2 flash chips (one is backup).
Flash the first chip:
./flashrom -p internal:dualbiosindex=0 -w libreboot.rom
./flashrom -p internal:dualbiosindex=0 -w libreboot.rom
Flash the second chip:
./flashrom -p internal:dualbiosindex=1 -w libreboot.rom
./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

156
site/docs/install/ich9utils.md
View File

@ -60,13 +60,13 @@ ich9utils
You can find `ich9utils` on the [Git page](../../git.md) or you can download
`lbmk` from the same page and run the following command in there:
./build module ich9utils
./build module ich9utils
You may also find it in the source code tar archives, on releases.
In `lbmk`, you can use the following command to generate descriptors:
./build descriptors ich9m
./build descriptors ich9m
The libreboot build system will use the descriptors under `descriptors/ich9m`
when building ROM images for these machines.
@ -89,7 +89,7 @@ When you simply run `ich9gen` without any arguments, it generates
descriptor+GbE images with a default MAC address in the GbE region. If you wish
to use a custom macaddress, you can supply an argument like so:
ich9gen --macaddress 00:1f:16:80:80:80
ich9gen --macaddress 00:1f:16:80:80:80
The above MAC address is just an example. It is recommended that you use the
MAC address officially assigned to your NIC.
@ -132,15 +132,15 @@ descriptor+gbe file into the ROM image.
For 16MiB flash chips:
dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_16m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 8MiB flash chips:
dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_8m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
For 4MiB flash chips:
dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
dd if=ich9fdgbe_4m.bin of=libreboot.rom bs=12k count=1 conv=notrunc
If you wish to have read-only flash (write protected flash), substitute the
above examples with descriptor+GbE images that have `ro` in the filename. RO
@ -203,7 +203,7 @@ The GbE region is largely unedited when using this utility.
Run it like so, with `factory.rom` in the same directory:
./ich9deblob
./ich9deblob
The `factory.rom` file is your dump of the vendor boot flash. Older versions
of this utility have this file name hardcoded, and for compatibility reasons
@ -212,7 +212,7 @@ name.
For example:
./ich9deblob lenovo.rom
./ich9deblob lenovo.rom
A 12kiB file named **deblobbed\_descriptor.bin** will now appear. **Keep
this and the factory.rom stored in a safe location!** The first 4KiB
@ -230,12 +230,12 @@ Assuming that your libreboot image is named **libreboot.rom**, copy the
**deblobbed\_descriptor.bin** file to where **libreboot.rom** is located
and then run:
dd if=deblobbed_descriptor.bin of=libreboot.rom bs=12k count=1 conv=notrunc
dd if=deblobbed_descriptor.bin of=libreboot.rom bs=12k count=1 conv=notrunc
Alternatively, if you got a the **deblobbed\_4kdescriptor.bin** file (no
GbE defined), do this:
dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=4k count=1 conv=notrunc
dd if=deblobbed_4kdescriptor.bin of=libreboot.rom bs=4k count=1 conv=notrunc
(it's very unlikely that you would ever see this. Descriptor without GbE is
very rare, probably non-existant, but theoretically possible and this functionality
@ -278,13 +278,13 @@ all of those restrictions.
Simply run (with `factory.rom` in the same directory):
./demefactory
./demefactory
It will generate a 4KiB descriptor file (only the descriptor, no GbE).
Insert that into a factory.rom image (NOTE: do this on a copy of it.
Keep the original factory.rom stored safely somewhere):
dd if=demefactory_4kdescriptor.bin of=factory_nome.rom bs=4k count=1 conv=notrunc
dd if=demefactory_4kdescriptor.bin of=factory_nome.rom bs=4k count=1 conv=notrunc
Use-case: a factory.rom image modified in this way would theoretically
have no flash protections whatsoever, making it easy to quickly switch
@ -339,63 +339,65 @@ Flash chips {#flashchips}
Early development notes {#early_development_notes}
-----------------------
Start (hex) End (hex) Length (hex) Area Name
----------- --------- ------------ ---------
00000000 003FFFFF 00400000 Flash Image
```
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
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
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
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
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
@ -415,17 +417,19 @@ documented in this public datasheet:
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
```
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

54
site/docs/install/index.md
View File

@ -230,7 +230,7 @@ read this section *carefully*.
Use this to find out:
flashrom -p internal
flashrom -p internal
In the output will be information pertaining to your boot flash.
@ -238,14 +238,14 @@ In the output will be information pertaining to your boot flash.
How to read the current chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -r dump.bin
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -r dump.bin
You should still make several dumps, even if you're flashing internally, to
ensure that you get the same checksums. Check each dump using `sha1sum`
How to erase and rewrite the chip contents:
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w libreboot.rom
sudo flashrom -p internal:laptop=force_I_want_a_brick,boardmismatch=force -w libreboot.rom
If you are re-flashing a GM45+ICH9M laptop (e.g. ThinkPad X200/X200S/X200T,
T400, T500, R400, W500 etc - but not R500), you should run the ich9gen utility
@ -395,7 +395,7 @@ run `make` in the bucts source directory).
Run the bucts tool:
sudo ./bucts 1
sudo ./bucts 1
Ensure that your CMOS battery is connected too. Now you must determine whether
you have Macronix or SST. An X60/T60 thinkpad will have either an SST or a
@ -405,35 +405,37 @@ Macronix chip.
Now run flashrom (for SST):
sudo ./flashrom_i945_sst -p internal -w coreboot.rom
sudo ./flashrom_i945_sst -p internal -w coreboot.rom
Or Macronix:
sudo ./flashrom_i945_mx -p internal -w coreboot.rom
sudo ./flashrom_i945_mx -p internal -w coreboot.rom
NOTE: you *can* just run both. One of them will succeed. It is perfectly
harmless to run both versions of flashrom. In fact, you should do so!
You'll see a lot of errors. This is normal. You should see something like:
Reading old flash chip contents... done.
Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
spi_block_erase_52 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
Transaction error!
spi_block_erase_d8 failed during command execution at address 0x1f0000
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_60 failed during command execution
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_c7 failed during command execution
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
```
Reading old flash chip contents... done.
Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
spi_block_erase_52 failed during command execution at address 0x0
Reading current flash chip contents... done. Looking for another erase function.
Transaction error!
spi_block_erase_d8 failed during command execution at address 0x1f0000
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_60 failed during command execution
Reading current flash chip contents... done. Looking for another erase function.
spi_chip_erase_c7 failed during command execution
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
```
If you see this, rejoice! It means that the flash was successful. Please do not
panic. Shut down now, and wait a few seconds, then turn back on again.
@ -458,11 +460,11 @@ Assuming that everything went well:
Flash the ROM for a second time. For this second flashing attempt, the upper
64KiB bootblock is now read-write. Use the *unpatched* flashrom binary:
sudo ./flashrom -p internal -w libreboot.rom
sudo ./flashrom -p internal -w libreboot.rom
To reset bucts, do this:
sudo ./bucts 0
sudo ./bucts 0
ONLY set bucts back to 0 if you're sure that the upper 64KiB bootblock is
flashed. It is flashed if flashrom said VERIFIED when running the above

4
site/docs/install/ivy_has_common.md
View File

@ -94,11 +94,11 @@ December 2022):**
Edit line 137 in `resources/scripts/blobs/inject`. The line in 20221214 says
this:
make -C cd coreboot/default/util/cbfstool || Fail 'could not build ifdtool'
make -C cd coreboot/default/util/cbfstool || Fail 'could not build ifdtool'
Modify it to say this:
make -C coreboot/default/util/cbfstool || Fail 'could not build cbfstool'
make -C coreboot/default/util/cbfstool || Fail 'could not build cbfstool'
Until this is edited accordingly, the inject script will *exit* with non-zero
status, and no blobs will be injected.

44
site/docs/install/nvmutil.md
View File

@ -127,7 +127,7 @@ Using recent flashrom versions, you can extract this region. If
your regions are unlocked, you can run flashrom on the target
system, like so:
flashrom -p internal -r rom.bin
flashrom -p internal -r rom.bin
If your system has two flash chips, the GbE region is usually
stored on SPI1 (not SPI2). Otherwise, it may be that you have
@ -135,7 +135,7 @@ a single-flash setup. In that case, it's recommended to dump
both chips, as `spi1.rom` and `spi2.rom`; you can then cat
them together:
cat spi1.rom spi2.rom > rom.bin
cat spi1.rom spi2.rom > rom.bin
If your GbE region is locked (per IFD settings), you can dump
and flash it using external flashing equipment. The Libreboot
@ -167,7 +167,7 @@ with `make`, to get an ifdtool binary.
To make internal flashing possible later on, you might do:
ifdtool --unlock rom.bin
ifdtool --unlock rom.bin
Running this command will create a modified image,
named `rom.bin.new`. This file will have all regions set
@ -185,7 +185,7 @@ article, so you should read their documentation.
Now run this:
ifdtool -x rom.bin
ifdtool -x rom.bin
Several files will be created, and the one you need to
operate on is named `flashregion_3_gbe.bin` so please
@ -195,7 +195,7 @@ Read the notes below about how to use the `nvmutil` program,
operating on this file. When you're done, you can insert the
modified GbE file back into your ROM image, like so:
ifdtool -i gbe:flashregion_3_gbe.bin rom.bin
ifdtool -i gbe:flashregion_3_gbe.bin rom.bin
This will create the file `rom.bin.new`, which contains
your modified GbE section with the NVM images inside; this
@ -205,12 +205,12 @@ Refer to flashrom documentation. You may flash the new ROM
like so, if running on the same system and the regions are
read-write:
flashrom -p internal -w rom.bin.new
flashrom -p internal -w rom.bin.new
Newer versions of flashrom support flashing just the specified
region, like so:
flashrom -p internal --ifd -i gbe -w rom.bin.new
flashrom -p internal --ifd -i gbe -w rom.bin.new
If you're running flashrom from host CPU on the target
system, and it's dual flash, you can just flash the
@ -270,7 +270,7 @@ copy of the nvmutil source code!
You may run this in your terminal:
make
make
This will result in a binary being created named `nvm`.
Install this to wherever you want, such as `/usr/bin` (or
@ -289,7 +289,7 @@ In these examples, it is assumed that you have installed
the `nvm` binary to somewhere in your `$PATH`. If you haven't
done that, you could still run it in cwd for instance:
./nvm bla bla bla
./nvm bla bla bla
Exit status
-----------
@ -348,25 +348,25 @@ you can do that. For example, if your MAC address
was `00:de:ad:be:ef:69` as assigned by the manufacturer,
which is a global unicast MAC address, you would type:
nvm gbe.bin setmac 00:de:ad:be:ef:69
nvm gbe.bin setmac 00:de:ad:be:ef:69
How to use (the MAC address in just an example):
nvm gbe.bin setmac 00:de:ad:be:ef:00
nvm gbe.bin setmac 00:de:ad:be:ef:00
You can also set random MAC addresses:
nvm gbe.bin setmac ??:??:??:??:??:??
nvm gbe.bin setmac ??:??:??:??:??:??
In this example, every character is random. However, you
can mix and match random characters with static ones. For
example:
nvm gbe.bin setmac 00:1f:16:??:??:??
nvm gbe.bin setmac 00:1f:16:??:??:??
You can also pass it without a MAC address:
nvm gbe.bin setmac
nvm gbe.bin setmac
If you only type `setmac` without specifying a MAC address,
it will do the same thing as `setmac ??:??:??:??:??:??`.
@ -395,7 +395,7 @@ It also prints the MAC address from each part.
How to use:
nvm gbe.bin dump
nvm gbe.bin dump
NOTE: This will exit with zero status if at least one part
contains a valid checksum. If both parts are invalid, nvmutil
@ -411,11 +411,11 @@ the *entire* 4KB part, within the 8KB file.
Overwrite part 0 with the contents of part 1:
nvm gbe.bin copy 1
nvm gbe.bin copy 1
Overwrite part 1 with the contents of part 0:
nvm gbe.bin copy 0
nvm gbe.bin copy 0
NOTE: If the part to be copied has a bad checksum, no operation
will be performed, and nvmutil will exit with non-zero status.
@ -432,7 +432,7 @@ file. It does this, via simple XOR swaps.
How to use:
nvm gbe.bin swap
nvm gbe.bin swap
NOTE: This operation will be aborted if BOTH checksums
are invalid. This is to guard against accidentally
@ -452,11 +452,11 @@ the desired NVM part. Usage:
Fix part 0:
nvm gbe.bin setchecksum 0
nvm gbe.bin setchecksum 0
Fix part 1:
nvm gbe.bin setchecksum 1
nvm gbe.bin setchecksum 1
*WARNING: NO validity checks are performed. This will simply
set the checksum. There is no feasible way to guard against
@ -473,11 +473,11 @@ the desired NVM part. Usage:
Invalidate part 0:
nvm gbe.bin brick 0
nvm gbe.bin brick 0
Invalidate part 1:
nvm gbe.bin brick 1
nvm gbe.bin brick 1
NOTE: If the part already has an invalid checksum, no operation
will be performed, and nvmutil will exit with non-zero status.

2
site/docs/install/nvmutilimport.md
View File

@ -182,7 +182,7 @@ My test setup is an x86\_64 machine with `tcc` used
as the compiler; the libc doesn't really matter, if
you use dynamic linking. Command:
make CC=tcc
make CC=tcc
Observations (dynamic linking with libc files):

2
site/docs/install/r400_external.md
View File

@ -59,7 +59,7 @@ Flash chip size {#flashchips}
Use this to find out:
flashrom -p internal
flashrom -p internal
MAC address {#macaddress}
===========

56
site/docs/install/spi.md
View File

@ -132,18 +132,20 @@ on the BBB)
Run the following commands as root to enable spidev:
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
```
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
```
Verify that the spidev devices now exist:
ls /dev/spidev*
ls /dev/spidev*
Output:
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1
Now the BBB is ready to be used for flashing. The following systemd service
file can optionally be enabled to make this persistent across reboots.
@ -166,16 +168,18 @@ WantedBy=multi-user.target
Now test flashrom:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
It is important to use `spispeed=512` or a lower number such as 256 or 128,
because otherwise the BBB will be quite unstable.
Example output:
Calibrating delay loop... OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
```
Calibrating delay loop... OK.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
```
This means that it's working (the clip isn't connected to any flash
chip, so the error is fine).
@ -204,7 +208,7 @@ This page has info:\
In your Raspberry Pi, which we assume you're running the latest Raspbian version
on, do this:
sudo raspi-config
sudo raspi-config
Under the Interface section, you can enable SPI.
@ -243,14 +247,14 @@ In the libreboot build system, from the Git repository, you can download and
install flashrom. Do this after downloading the
[lbmk Git repository](https://notabug.org/libreboot/lbmk):
cd lbmk
sudo ./build dependencies ubuntu2004
cd lbmk
sudo ./build dependencies ubuntu2004
NOTE: debian, arch or void can be written instead of ubuntu2004. the debian
script is also applicable to newer ubuntu versions
./download flashrom
./build module flashrom
./download flashrom
./build module flashrom
If the `ubuntu2004` script complains about missing dependencies, just modify
the script and remove those dependencies. The script is located
@ -295,11 +299,11 @@ current chip contents to a file.
Run this command to see if 25xx flash is detected, with your RPi properly
wired.
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768
For BBB, you must use a lower speed and a different device path:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
On BBB, never use a speed higher than `spispeed=512`. In some cases, you may
even need to go as low as `spispeed=128`. The BBB is highly unstable and
@ -317,15 +321,15 @@ or you can try flashing it with a new ROM.
Dump it like so (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r dump.bin
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -r dump.bin
For BBB, do this:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r dump.bin
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r dump.bin
It is advisable to take a *2nd* dump, e.g. `dump2.bin`, and then check sha1sum:
sha1sum dump*.bin
sha1sum dump*.bin
If the checksums match, it indicates that you have a good dump. If they do not,
check your wiring. Wires should be within 10cm length for best stability, and
@ -351,11 +355,11 @@ Writing
Next, run this command (RPi):
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/libreboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=32768 -w /path/to/libreboot.rom
If using BBB:
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/libreboot.rom
sudo ./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w /path/to/libreboot.rom
If using BBB, you may have to use a lower speed than 512. You may also have to
re-flash several times before it works fully.
@ -365,9 +369,11 @@ Again, use a lower `spispeed` value if you need to, for stability.
Once that command outputs the following, the flash has completed
successfully. If not, just flash again.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
```
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
```
If it says "VERIFIED" or says that the chip contents are identical to the
requested image, then the chip is properly flashed.

2
site/docs/install/t400_external.md
View File

@ -66,7 +66,7 @@ Flash chip size {#flashchips}
Use this to find out:
flashrom -p internal
flashrom -p internal
MAC address {#macaddress}
===========

102
site/docs/install/t500_external.md
View File

@ -68,7 +68,7 @@ Flash chip size {#flashchips}
Use this to find out:
flashrom -p internal
flashrom -p internal
MAC address {#macaddress}
===========
@ -83,31 +83,35 @@ Refer to [spi.md](spi.md) as a guide for external re-flashing.
The following shows how to connect clip to the BBB (on the P9 header),
for SOIC-16 (clip: Pomona 5252):
POMONA 5252 (correlate with the BBB guide)
=== ethernet jack and VGA port ====
NC - - 21
1 - - 17
NC - - NC
NC - - NC
NC - - NC
NC - - NC
18 - - 3.3V (PSU)
22 - - NC - this is pin 1 on the flash chip
=== SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
```
POMONA 5252 (correlate with the BBB guide)
=== ethernet jack and VGA port ====
NC - - 21
1 - - 17
NC - - NC
NC - - NC
NC - - NC
NC - - NC
18 - - 3.3V (PSU)
22 - - NC - this is pin 1 on the flash chip
=== SATA port ===
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
```
The following shows how to connect clip to the BBB (on the P9 header),
for SOIC-8 (clip: Pomona 5250):
POMONA 5250 (correlate with the BBB guide)
=== RAM slots ====
18 - - 1
22 - - NC
NC - - 21
3.3V (PSU) - - 17 - this is pin 1 on the flash chip
=== slot where the AC jack is connected ===
```
POMONA 5250 (correlate with the BBB guide)
=== RAM slots ====
18 - - 1
22 - - NC
NC - - 21
3.3V (PSU) - - 17 - this is pin 1 on the flash chip
=== slot where the AC jack is connected ===
```
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
This is how you will connect. Numbers refer to pin numbers on the BBB, on the plugs near the DC jack.
The procedure
-------------
@ -224,34 +228,36 @@ Log in as root on your BBB, using the instructions in
Test that flashrom works:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512
In this case, the output was:
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.
```
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6406E/MX25L6436E" (8192 kB, SPI) on linux_spi.
Found Macronix flash chip "MX25L6445E/MX25L6473E" (8192 kB, SPI) on linux_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405(D)", "MX25L6406E/MX25L6436E", "MX25L6445E/MX25L6473E"
Please specify which chip definition to use with the -c <chipname> option.
```
How to backup factory.rom (change the -c option as neeed, for your flash
chip):
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
```
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory1.rom
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -r factory2.rom
```
Note: the `-c` option is not required in libreboot's patched
flashrom, because the redundant flash chip definitions in *flashchips.c*
have been removed.\
Now compare the 3 images:
sha512sum factory\*.rom
sha512sum factory\*.rom
If the hashes match, then just copy one of them (the factory.rom) to a
safe place (on a drive connected to another system, not the BBB). This
@ -269,7 +275,7 @@ to change the MAC address inside the libreboot image.
Now flash it:
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V
./flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 -w path/to/libreboot/rom/image.rom -V
![](https://av.libreboot.org/x200/disassembly/0015.jpg)
@ -281,16 +287,18 @@ installation.
Example output from running the command (see above):
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.
```
flashrom v0.9.7-r1854 on Linux 3.8.13-bone47 (armv7l)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX25L6405(D)" (8192 kB, SPI) on linux_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00001000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0xd716
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
Erase/write done.
Verifying flash... VERIFIED.
```
Thermal paste (IMPORTANT)
=========================

8
site/docs/install/t60_unbrick.md
View File

@ -47,9 +47,9 @@ two:\
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
(doing this makes the ROM suitable for use when flashing a system that
still has Lenovo BIOS running, using those instructions:
@ -160,7 +160,7 @@ which all draw a lot of current, more than your flasher can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

22
site/docs/install/x200_external.md
View File

@ -20,7 +20,7 @@ Flash chip size
Run this command on x200 to find out flash chip model and its size:
flashrom -p internal
flashrom -p internal
MAC address
===========
@ -104,21 +104,27 @@ Look just above the 7 in TP37 (that's GPIO33):
By default we would see this in lenovobios, when trying flashrom -p
internal -w rom.rom:
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00001000-0x005f5fff) is locked.
```
FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG2: Warning: Management Engine region (0x00001000-0x005f5fff) is locked.
```
With GPIO33 grounded during boot, this disabled the flash protections as
set by descriptor, and stopped the ME from starting. The output changed
to:
The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.
```
The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.
```
The part in bold is what got us. This was still observed:
PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.
```
PR0: Warning: 0x007e0000-0x01ffffff is read-only.
PR4: Warning: 0x005f8000-0x005fffff is locked.
```
It is actually possible to disable these protections. Lenovobios does,
when updating the BIOS (proprietary one). One possible way to go about

8
site/docs/install/x60_unbrick.md
View File

@ -44,9 +44,9 @@ two:\
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
(doing this makes the ROM suitable for use when flashing a system that
still has Lenovo BIOS running, using those instructions:
@ -141,7 +141,7 @@ which all draw a lot of current, more than your programmer can provide.
Example RPi command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

8
site/docs/install/x60tablet_unbrick.md
View File

@ -44,9 +44,9 @@ two:\
images (the ROM images in libreboot binary archives already have this
applied!):
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
dd if=coreboot.rom of=top64k.bin bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x10000] count=64k
dd if=coreboot.rom bs=1 skip=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k | hexdump
dd if=top64k.bin of=coreboot.rom bs=1 seek=$[$(stat -c %s coreboot.rom) - 0x20000] count=64k conv=notrunc
(doing this makes the ROM suitable for use when flashing a system that
still has Lenovo BIOS running, using those instructions:
@ -121,7 +121,7 @@ which all draw a lot of current, more than most flashers can provide.
Example command:
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
sudo ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=4096 -w libreboot.rom -V
If flashrom complains about multiple flash chips detected, just pass the `-c`
option as it suggests, and pick any of the chips it lists. `spispeed=4096` or

62
site/docs/maintain/index.md
View File

@ -194,26 +194,28 @@ command `./build boot roms` will execute `resources/scripts/build/boot/roms`.
When running such commands, additional parameters can be given, which will
be passed along to the corresponding script. For example, try:
./build boot roms x60 x200_8mb w500_16mb
./build boot roms x60 x200_8mb w500_16mb
This will run:
./resources/scripts/build/boot/roms x60 x200_8mb w500_16mB
./resources/scripts/build/boot/roms x60 x200_8mb w500_16mB
The `list` function is very helpful. For example:
./build boot list
./build boot list
At the time of writing this section, this would have outputted:
At the time of writing this section, this would output something like:
Available options for mode 'boot':
````
Available options for mode 'boot':
roms
roms_helper
roms
roms_helper
```
Another use of `list` would be:
./build boot roms list
./build boot roms list
However, the `roms` script merely happens to implement a `list` command. For
example, `./build payload grub list` does nothing differently
@ -231,23 +233,23 @@ apply custom patches to GNU GRUB.
This runs scripts in `resources/scripts/download`. For example:
./download coreboot
./download coreboot
This would run:
./resources/scripts/download/coreboot
./resources/scripts/download/coreboot
Additional parameters can be given, for example:
./download coreboot default
./download coreboot default
This would run:
./resources/scripts/download/coreboot default
./resources/scripts/download/coreboot default
For a full list of all `download` commands, run:
./download help
./download help
modify
======
@ -255,19 +257,19 @@ modify
This can be used to modify SeaBIOS, coreboot and U-Boot configs. It calls
scripts in `resources/scripts/modify/`, for example:
./modify coreboot configs
./modify coreboot configs
This runs:
./resources/scripts/modify/coreboot/configs
./resources/scripts/modify/coreboot/configs
Additional parameters can be given, for example:
./modify coreboot configs x200_8mb x60
./modify coreboot configs x200_8mb x60
This would run:
./resources/scripts/modify/coreboot/configs x200_8mb x60
./resources/scripts/modify/coreboot/configs x200_8mb x60
projectname
===========
@ -711,12 +713,12 @@ Command: `./build boot roms`
Additional parameters can be provided. This lists all boards available:
./build boot roms list
./build boot roms list
Pass several board names if you wish to build only for specific targets. For
example:
./build boot roms x60 x200_8mb
./build boot roms x60 x200_8mb
resources/scripts/build/boot/roms\_helper
=========================================
@ -1022,11 +1024,7 @@ Command: `./download coreboot`
NOTE: This version of the script also performs the full git checkout in each
coreboot tree, like so:
git submodule update --init --checkout
The `lbmk` version only does this:
git submodule update --init
git submodule update --init --checkout
The coreboot project sets up its Git repository, in such a way where most blobs
are skipped if you omit `--checkout`. Since lbmk's policy is to *include*
@ -1090,7 +1088,7 @@ Loads coreboot configs into coreboot trees, and runs `make menuconfig`, so
that you can easily modify them in an ncurses interface. Additional parameters
are accepted, for example:
./modify coreboot configs x60 x200_8mb
./modify coreboot configs x60 x200_8mb
With no additional parameters given, it simply cycles through all configs
under `resources/coreboot/`.
@ -1111,7 +1109,7 @@ Loads U-Boot configs into U-Boot trees, and runs `make menuconfig`, so
that you can easily modify them in an ncurses interface. Additional parameters
are accepted, for example:
./modify u-boot configs gru_kevin gru_bob
./modify u-boot configs gru_kevin gru_bob
With no additional parameters given, it simply cycles through all configs
under `resources/u-boot/`.
@ -1125,7 +1123,7 @@ This runs `make oldconfig` on coreboot configs under `resources/coreboot/`.
It is most useful when updating a coreboot revision, per `board.cfg`. It allows
additional parameters, for example:
./update coreboot configs x60 x200_8mb
./update coreboot configs x60 x200_8mb
With no additional parameters given, it simply cycles through all configs
under `resources/coreboot/`.
@ -1147,7 +1145,7 @@ This runs `make oldconfig` on U-Boot configs under `resources/u-boot/`.
It is most useful when updating a U-Boot revision, per `board.cfg`. It allows
additional parameters, for example:
./update u-boot configs gru_kevin gru_bob
./update u-boot configs gru_kevin gru_bob
With no additional parameters given, it simply cycles through all configs
under `resources/u-boot/`.
@ -1182,17 +1180,17 @@ update
This can be used to update SeaBIOS, coreboot and U-Boot configs. It calls
scripts in `resources/scripts/update/`, for example:
./update coreboot configs
./update coreboot configs
This runs:
./resources/scripts/update/coreboot/configs
./resources/scripts/update/coreboot/configs
Additional parameters can be given, for example:
./update coreboot configs x200_8mb x60
./update coreboot configs x200_8mb x60
This would run:
./resources/scripts/update/coreboot/configs x200_8mb x60
./resources/scripts/update/coreboot/configs x200_8mb x60

11
site/docs/misc/emulation.md
View File

@ -29,10 +29,12 @@ For example:
There is basic support for an arm64 virtual machine as well, although the payloads are not as developed as the x86 one:
./build boot roms qemu_arm64_12mb
./build boot roms qemu_arm64_12mb
qemu-system-aarch64 -bios bin/qemu_arm64_12mb/uboot_payload_qemu_arm64_12mb_libgfxinit_corebootfb.rom \
-M virt,secure=on,virtualization=on,acpi=on -cpu cortex-a53 -m 768M -serial stdio -vga none -display none
```
qemu-system-aarch64 -bios bin/qemu_arm64_12mb/uboot_payload_qemu_arm64_12mb_libgfxinit_corebootfb.rom \
-M virt,secure=on,virtualization=on,acpi=on -cpu cortex-a53 -m 768M -serial stdio -vga none -display none
```
Use Cases
=========
@ -40,7 +42,8 @@ Use Cases
While development is the primary motivation for qemu support, the board makes it easy to test minor changes to release roms.
For example one can use *cbfstool* from coreboot to edit the background image in a libreboot rom as follows:
```cbfstool /path/to/rom remove -n background.png
```
cbfstool /path/to/rom remove -n background.png
cbfstool /path/to/rom add -f mynewbackground.png -n background.png -t raw
```

92
site/docs/misc/index.md
View File

@ -14,7 +14,7 @@ Included with libreboot is a script called 'powertop.debian'. Run this
as root and it will setup powertop to run with --auto-tune at boot
time. Load the file in your text editor to see how it does that.
sudo ./resources/scripts/misc/powertop.debian
sudo ./resources/scripts/misc/powertop.debian
Might want to run with --calibrate first
@ -40,31 +40,33 @@ GRUB. These consume power. Stop using them!
Be root
su -
su -
Installed powertop:
pacman -S powertop
pacman -S powertop
and added the following to /etc/systemd/system/powertop.service :
[Unit]
Description=Powertop tunings
```
[Unit]
Description=Powertop tunings
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/powertop --auto-tune
"powertop --auto-tune" still needs a terminal for some reason. Possibly a bug?
Environment="TERM=xterm"
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/powertop --auto-tune
"powertop --auto-tune" still needs a terminal for some reason. Possibly a bug?
Environment="TERM=xterm"
[Install]
WantedBy=multi-user.target
[Install]
WantedBy=multi-user.target
```
Finally, as root do that:
systemctl enable powertop
systemctl start powertop
systemctl enable powertop
systemctl start powertop
The next time you boot the system, the buzz will be gone.
@ -91,7 +93,7 @@ USB Serial adapter.
On the 2nd system, you can try this (using GNU Screen):
sudo screen /dev/ttyUSB0 115200
sudo screen /dev/ttyUSB0 115200
How to quit GNU Screen: Ctrl+A then release and press K, and then press
Y.
@ -124,11 +126,11 @@ needs to be set. See p94 of
for more information on this reg. The tool for setting registry values
on intel gpu's is included in intel-gpu-tools. Install intel-gpu-tools:
sudo apt-get install intel-gpu-tools
sudo apt-get install intel-gpu-tools
You can set values:
sudo intel_reg write 0x00061254 your_value_in_C_hex_format
sudo intel_reg write 0x00061254 your_value_in_C_hex_format
NOTE: on older versions of this utility, use `intel_reg_write` instead.
@ -164,25 +166,27 @@ highest good working value.
Next this value should be set at boot: either add
intel_reg write 0x00061254 &ltyour_ideal_value>
intel_reg write 0x00061254 <your_ideal_value>
NOTE: on older versions of this utility, use `intel_reg_write` instead.
before exit 0 in /etc/rc.local or create a systemd service file
/etc/systemd/system/backlight.service:
[Unit]
Description=Set BLC_PWM_CTL to a good value
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/intel_reg write 0x00061254 &ltyour_value>
[Install]
WantedBy=multi-user.target
```
[Unit]
Description=Set BLC_PWM_CTL to a good value
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/bin/intel_reg write 0x00061254 <your_value>
[Install]
WantedBy=multi-user.target
```
Now start and enable it:
sudo systemctl start backlight && sudo systemctl enable backlight
sudo systemctl start backlight && sudo systemctl enable backlight
Special note on i945:
@ -221,17 +225,17 @@ changes on the image with the following commands.
Disable or enable beeps when removing/adding the charger:
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Disable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Enable
sudo ./nvramtool -C libreboot.rom -w power_management_beeps=Disable
Disable or enable beeps when battery is low:
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Disable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Enable
sudo ./nvramtool -C libreboot.rom -w low_battery_beep=Disable
You can check that the parameters are set in the image with :
sudo ./nvramtool -C libreboot.rom -a
sudo ./nvramtool -C libreboot.rom -a
Finally, you need to flash the rom with this new image. See here
<https://libreboot.org/docs/gnulinux/grub_cbfs.html#with-re-flashing-the-rom>
@ -242,19 +246,17 @@ Get EDID: Find out the name (model) of your LCD panel
Get the panel name:
sudo get-edid | strings
sudo get-edid | strings
Or look in `/sys/class/drm/card0-LVDS-1/edid`
Alternatively you can use i2cdump. In Debian and Devuan, this is in the
package i2c-tools.
sudo modprobe i2c-dev
sudo i2cdump -y 5 0x50 (you might have to change the value for
sudo modprobe i2c-dev
sudo i2cdump -y 5 0x50 (you might have to change the value for -y)
-y)
sudo rmmod i2c-dev
sudo rmmod i2c-dev
You'll see the panel name in the output (from the EDID dump).
@ -268,7 +270,7 @@ e1000e driver trouble shooting (Intel NICs)
Example error, ¿may happen on weird and complex routing schemes(citation
needed for cause):
e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang
e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang
Possible workaround, tested by Nazara: Disable C-STATES.
@ -280,10 +282,12 @@ laptop. If power usage is a concern, then you should not use this.
To disable c-states, do this in GNU+Linux:
for i in /sys/devices/system/cpu/cpu/cpuidle/state/disable;
do
echo 1 > $i;
done
```
for i in /sys/devices/system/cpu/cpu/cpuidle/state/disable;
do
echo 1 > $i;
done
```
You can reproduce this issue more easily by sending lots of traffic
across subnets on the same interface (NIC).

2
site/docs/uboot/index.md
View File

@ -19,7 +19,7 @@ As of 14 December 2022, building of U-Boot images has been tested on
Debian. Make sure you have the latest `lbmk` from the Git repository,
and the build dependencies are installed like so, from `lbmk/` as root:
./build dependencies debian
./build dependencies debian
This installs everything needed for `./build boot roms`, and part of the
build process makes use of coreboot's own cross-compile toolchain.

8
site/download.md
View File

@ -35,8 +35,8 @@ Full key fingerprint: CDC9 CAE3 2CB4 B7FC 84FD C804 969A 9795 05E8 C5B2
The GPG key can also be downloaded with this exported dump of the
pubkey: [lbkeyold.asc](lbkeyold.asc).
sha512sum -c sha512sum.txt
gpg --verify sha512sum.txt.sig
sha512sum -c sha512sum.txt
gpg --verify sha512sum.txt.sig
Git repository
--------------
@ -89,11 +89,11 @@ libreboot.org.
Before you create the mirror, make a directory on your web server. For
example:
mkdir /var/www/html/libreboot/
mkdir /var/www/html/libreboot/
Now you can run rsync, for instance:
rsync -avz --delete-after rsync://rsync.libreboot.org/mirrormirror/ /var/www/html/libreboot/
rsync -avz --delete-after rsync://rsync.libreboot.org/mirrormirror/ /var/www/html/libreboot/
**It's extremely important to have the final forward slash (/) at the end of each path,
in the above rsync command. Otherwise, rsync will behave very strangely.**

48
site/faq.md
View File

@ -66,11 +66,11 @@ both on the original BIOS and in libreboot. It's a quirk in the
hardware. On debian systems, a workaround is to restart the networking
service when you connect the ethernet cable:
sudo service network-manager restart
sudo service network-manager restart
On Parabola, you can try:
sudo systemctl restart network-manager
sudo systemctl restart network-manager
(the service name might be different for you, depending on your
configuration)
@ -123,51 +123,51 @@ the target (`target$`):
1. Start a listener server on the target machine (netcat works well):
`target$ nc -u -l -p 6666`
`target$ nc -u -l -p 6666`
2. Mount configfs (only once per boot, you can check if it is already mounted
with `mount | grep /sys/kernel/config`. This will return no output
if it is not).
`source# modprobe configfs`
`source# modprobe configfs`
`source# mkdir -p /sys/kernel/config`
`source# mkdir -p /sys/kernel/config`
`source# mount none -t configfs /sys/kernel/config`
`source# mount none -t configfs /sys/kernel/config`
3. find source's ethernet interface name, it should be of the form `enp*` or
`eth*`, see `ip address` or `ifconfig` output.
`source# iface="enp0s29f8u1"` change this
`source# iface="enp0s29f8u1"` change this
Fill the target machine's IPv4 address here:
`source# tgtip="192.168.1.2"` change this
`source# tgtip="192.168.1.2"` change this
3. Create netconsole logging target on the source machine:
`source# modprobe netconsole`
`source# modprobe netconsole`
`source# cd /sys/kernel/config/netconsole`
`source# cd /sys/kernel/config/netconsole`
`source# mkdir target1; cd target1`
`source# mkdir target1; cd target1`
`source# srcip=$(ip -4 addr show dev "$iface" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')`
`source# srcip=$(ip -4 addr show dev "$iface" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')`
`source# echo "$srcip" > local_ip`
`source# echo "$srcip" > local_ip`
`source# echo "$tgtip" > remote_ip`
`source# echo "$tgtip" > remote_ip`
`source# echo "$iface" > dev_name`
`source# echo "$iface" > dev_name`
`source# arping -I "$iface" "$tgtip" -f | grep -o '..:..:..:..:..:..' > remote_mac`
`source# arping -I "$iface" "$tgtip" -f | grep -o '..:..:..:..:..:..' > remote_mac`
`source# echo 1 > enabled`
`source# echo 1 > enabled`
4. Change console loglevel to debugging:
`source# dmesg -n debug`
`source# dmesg -n debug`
5. Test if the logging works by e.g. inserting or removing an USB
device on the source. There should be a few lines appearing in the
@ -609,11 +609,11 @@ cases.
Default libreboot setups lock the CMOS table, to ensure consistent functionality
for all users. You can use:
nvramtool -C yourrom.rom -w somesetting=somevalue
nvramtool -C yourrom.rom -w somesetting=somevalue
To get a full list of available options, do this:
nvramtool -C yourrom.rom -a
nvramtool -C yourrom.rom -a
This will change the default inside that ROM image, and then you can
re-flash it.
@ -635,15 +635,15 @@ Required for ROMs where the ROM image is smaller than the flash chip
Create an empty (00 bytes) file with a size the difference between
the ROM and flash chip. The case above, for example:
truncate -s +14MiB pad.bin
truncate -s +14MiB pad.bin
For x86 descriptorless images you need to pad from the *beginning* of the ROM:
cat pad.bin yourrom.rom > yourrom.rom.new
cat pad.bin yourrom.rom > yourrom.rom.new
For ARM and x86 with intel flash descriptor, you need to pad after the image:
cat yourrom.rom pad.bin > yourrom.rom.new
cat yourrom.rom pad.bin > yourrom.rom.new
Flash the resulting file. Note that cbfstool will not be able to
operate on images padded this way so make sure to make all changes to
@ -654,7 +654,7 @@ simply use dd(1) to extract only the non-padded portion. Continuing with the
examples above, in order to extract a 2MiB x86 descriptorless ROM from a
padded 16MiB image do the following:
dd if=flashromread.rom of=yourrom.rom ibs=14MiB skip=1
dd if=flashromread.rom of=yourrom.rom ibs=14MiB skip=1
With padding removed cbfstool will be able to operate on the image as usual.

8
site/git.md
View File

@ -52,12 +52,12 @@ lbmk (libreboot-make)
This is the core build system in libreboot. You could say that `lbmk` *is*
libreboot! Download the Git repository:
git clone https://notabug.org/libreboot/lbmk
git clone https://notabug.org/libreboot/lbmk
The `git` command, seen above, will download the libreboot build system `lbmk`.
You can then go into it like so:
cd lbmk
cd lbmk
Make whatever changes you like, or simply build it. For instructions on how to
build `lbmk`, refer to the [build instructions](docs/build/).
@ -71,12 +71,12 @@ lbwww and lbwww-img
The *entire* libreboot website and documentation is hosted in a Git repository.
Download it like so:
git clone https://notabug.org/libreboot/lbwww
git clone https://notabug.org/libreboot/lbwww
Images are hosted on <https://av.libreboot.org/> and available in a separate
repository:
git clone https://notabug.org/libreboot/lbwww-img
git clone https://notabug.org/libreboot/lbwww-img
Make whatever changes you like. See notes below about how to send patches.

6
site/news/libreboot20220710.md
View File

@ -67,7 +67,7 @@ Work done since the 20211122 release:
condition when rebuilding SeaBIOS with a high CPU count, resulting in failure
with the error message (fix courtesy of John Doe):
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
* lbmk: Specifically call python3, when python3 is to be used instead of 2.
* lbmk: Preliminary fix for git credentials check. Set a placeholder name/email
@ -183,11 +183,11 @@ under current Libreboot policy.
Example, Libreboot-style, blobless:
FSDG= ./build boot roms all
FSDG= ./build boot roms all
Example, Osboot-style:
./build boot roms all
./build boot roms all
An option in `board.cfg` for each board would specify whether the given board
can actually be built and booted this way, per current Libreboot policy.

4
site/news/translations.md
View File

@ -46,8 +46,8 @@ goes live.
unless you actually want it to be publicly accessible. The `ufw` software is
quite nice:**
sudo apt-get install ufw
sudo ufw enable
sudo apt-get install ufw
sudo ufw enable
This will block all unsolicited incoming traffic. It's good practise anyway,
for workstations. You don't have to use ufw, but it's a nice frontend for