diff --git a/site/docs/bsd/index.md b/site/docs/bsd/index.md index 97ae24e..305b907 100644 --- a/site/docs/bsd/index.md +++ b/site/docs/bsd/index.md @@ -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 diff --git a/site/docs/build/index.md b/site/docs/build/index.md index 2837641..43d6969 100644 --- a/site/docs/build/index.md +++ b/site/docs/build/index.md @@ -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 ============================ @@ -113,41 +113,41 @@ First, install build dependencies libreboot includes a script that automatically installs apt-get dependencies in Ubuntu 20.04. It works well in other apt-get distros (such as Trisquel and Debian): - - sudo ./build dependencies ubuntu2004 + + 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. diff --git a/site/docs/gnulinux/grub_boot_installer.md b/site/docs/gnulinux/grub_boot_installer.md index 2c05ae5..3058870 100644 --- a/site/docs/gnulinux/grub_boot_installer.md +++ b/site/docs/gnulinux/grub_boot_installer.md @@ -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. diff --git a/site/docs/gnulinux/grub_cbfs.md b/site/docs/gnulinux/grub_cbfs.md index 1354ffc..9e85094 100644 --- a/site/docs/gnulinux/grub_cbfs.md +++ b/site/docs/gnulinux/grub_cbfs.md @@ -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. diff --git a/site/docs/gnulinux/grub_hardening.md b/site/docs/gnulinux/grub_hardening.md index 9eaf954..b89806c 100644 --- a/site/docs/gnulinux/grub_hardening.md +++ b/site/docs/gnulinux/grub_hardening.md @@ -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. diff --git a/site/docs/gnulinux/index.md b/site/docs/gnulinux/index.md index d5aece8..f08cc62 100644 --- a/site/docs/gnulinux/index.md +++ b/site/docs/gnulinux/index.md @@ -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 diff --git a/site/docs/grub/index.md b/site/docs/grub/index.md index 75cf8ed..0dc3a96 100644 --- a/site/docs/grub/index.md +++ b/site/docs/grub/index.md @@ -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 diff --git a/site/docs/hardware/ga-g41m-es2l.md b/site/docs/hardware/ga-g41m-es2l.md index f245e9a..410f0de 100644 --- a/site/docs/hardware/ga-g41m-es2l.md +++ b/site/docs/hardware/ga-g41m-es2l.md @@ -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/) diff --git a/site/docs/hardware/index.md b/site/docs/hardware/index.md index 3e997bd..f18129b 100644 --- a/site/docs/hardware/index.md +++ b/site/docs/hardware/index.md @@ -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 diff --git a/site/docs/hardware/mac_address.md b/site/docs/hardware/mac_address.md index feb3f04..8d8cbc9 100644 --- a/site/docs/hardware/mac_address.md +++ b/site/docs/hardware/mac_address.md @@ -71,16 +71,16 @@ There are three portable ways of doing so: 1. Using the new iproute2 package: - ip link set down + ip link set down - ip link set dev address 00:4c:69:62:72:65 + ip link set dev address 00:4c:69:62:72:65 - ip link set up + ip link set up 2. Using the old `ifconfig` command: - ifconfig hw ether 00:4c:69:62:72:65 + ifconfig hw ether 00:4c:69:62:72:65 3. Using the macchanger package. diff --git a/site/docs/hardware/macbook21.md b/site/docs/hardware/macbook21.md index 4ab9f09..8d44020 100644 --- a/site/docs/hardware/macbook21.md +++ b/site/docs/hardware/macbook21.md @@ -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 +``` diff --git a/site/docs/install/chromebooks.md b/site/docs/install/chromebooks.md index 04b68a2..acd8897 100644 --- a/site/docs/install/chromebooks.md +++ b/site/docs/install/chromebooks.md @@ -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/) diff --git a/site/docs/install/d510mo.md b/site/docs/install/d510mo.md index a0cb9f2..3c3f7de 100644 --- a/site/docs/install/d510mo.md +++ b/site/docs/install/d510mo.md @@ -12,7 +12,7 @@ Flash chip size {#flashchips} Use this to find out: - flashrom -p internal + flashrom -p internal Flashing instructions {#clip} ===================== diff --git a/site/docs/install/ga-g41m-es2l.md b/site/docs/install/ga-g41m-es2l.md index dee7f10..cb3716b 100644 --- a/site/docs/install/ga-g41m-es2l.md +++ b/site/docs/install/ga-g41m-es2l.md @@ -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 diff --git a/site/docs/install/ich9utils.md b/site/docs/install/ich9utils.md index b74de2d..8c170e7 100644 --- a/site/docs/install/ich9utils.md +++ b/site/docs/install/ich9utils.md @@ -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 diff --git a/site/docs/install/index.md b/site/docs/install/index.md index e054878..0f2516a 100644 --- a/site/docs/install/index.md +++ b/site/docs/install/index.md @@ -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 diff --git a/site/docs/install/ivy_has_common.md b/site/docs/install/ivy_has_common.md index 3d8a3f4..29fdda5 100644 --- a/site/docs/install/ivy_has_common.md +++ b/site/docs/install/ivy_has_common.md @@ -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. diff --git a/site/docs/install/nvmutil.md b/site/docs/install/nvmutil.md index bc8dba8..990ef19 100644 --- a/site/docs/install/nvmutil.md +++ b/site/docs/install/nvmutil.md @@ -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. diff --git a/site/docs/install/nvmutilimport.md b/site/docs/install/nvmutilimport.md index e676895..932a50c 100644 --- a/site/docs/install/nvmutilimport.md +++ b/site/docs/install/nvmutilimport.md @@ -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): diff --git a/site/docs/install/r400_external.md b/site/docs/install/r400_external.md index c15f7fb..430b99b 100644 --- a/site/docs/install/r400_external.md +++ b/site/docs/install/r400_external.md @@ -59,7 +59,7 @@ Flash chip size {#flashchips} Use this to find out: - flashrom -p internal + flashrom -p internal MAC address {#macaddress} =========== diff --git a/site/docs/install/spi.md b/site/docs/install/spi.md index 902ca69..018295d 100644 --- a/site/docs/install/spi.md +++ b/site/docs/install/spi.md @@ -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. diff --git a/site/docs/install/t400_external.md b/site/docs/install/t400_external.md index d7f786c..7a9890c 100644 --- a/site/docs/install/t400_external.md +++ b/site/docs/install/t400_external.md @@ -66,7 +66,7 @@ Flash chip size {#flashchips} Use this to find out: - flashrom -p internal + flashrom -p internal MAC address {#macaddress} =========== diff --git a/site/docs/install/t500_external.md b/site/docs/install/t500_external.md index 5f09190..b840ff7 100644 --- a/site/docs/install/t500_external.md +++ b/site/docs/install/t500_external.md @@ -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 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 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) ========================= diff --git a/site/docs/install/t60_unbrick.md b/site/docs/install/t60_unbrick.md index b54115d..ffd9b7d 100644 --- a/site/docs/install/t60_unbrick.md +++ b/site/docs/install/t60_unbrick.md @@ -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 diff --git a/site/docs/install/x200_external.md b/site/docs/install/x200_external.md index 483898f..ed1ac1e 100644 --- a/site/docs/install/x200_external.md +++ b/site/docs/install/x200_external.md @@ -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 diff --git a/site/docs/install/x60_unbrick.md b/site/docs/install/x60_unbrick.md index 5903b0b..70c7a15 100644 --- a/site/docs/install/x60_unbrick.md +++ b/site/docs/install/x60_unbrick.md @@ -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 diff --git a/site/docs/install/x60tablet_unbrick.md b/site/docs/install/x60tablet_unbrick.md index 1650c47..9a178f4 100644 --- a/site/docs/install/x60tablet_unbrick.md +++ b/site/docs/install/x60tablet_unbrick.md @@ -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 diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index f5a8a31..0cb9583 100644 --- a/site/docs/maintain/index.md +++ b/site/docs/maintain/index.md @@ -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': - - roms - roms_helper +```` +Available options for mode 'boot': + +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 diff --git a/site/docs/misc/emulation.md b/site/docs/misc/emulation.md index 0ff78ce..617b975 100644 --- a/site/docs/misc/emulation.md +++ b/site/docs/misc/emulation.md @@ -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 ``` diff --git a/site/docs/misc/index.md b/site/docs/misc/index.md index 1329492..ba04a4a 100644 --- a/site/docs/misc/index.md +++ b/site/docs/misc/index.md @@ -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 <your_ideal_value> + intel_reg write 0x00061254 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 <your_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 +[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 @@ -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). diff --git a/site/docs/uboot/index.md b/site/docs/uboot/index.md index 547a8af..89031eb 100644 --- a/site/docs/uboot/index.md +++ b/site/docs/uboot/index.md @@ -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. diff --git a/site/download.md b/site/download.md index 6ecf0e9..4d12966 100644 --- a/site/download.md +++ b/site/download.md @@ -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.** diff --git a/site/faq.md b/site/faq.md index 3bf8b97..e9701b3 100644 --- a/site/faq.md +++ b/site/faq.md @@ -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. diff --git a/site/git.md b/site/git.md index df40d6f..62956ca 100644 --- a/site/git.md +++ b/site/git.md @@ -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 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. diff --git a/site/news/libreboot20220710.md b/site/news/libreboot20220710.md index 88567dc..e67c868 100644 --- a/site/news/libreboot20220710.md +++ b/site/news/libreboot20220710.md @@ -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. diff --git a/site/news/translations.md b/site/news/translations.md index 8436b58..ffa2f4e 100644 --- a/site/news/translations.md +++ b/site/news/translations.md @@ -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