Difference between revisions of "Fallback mechanism"

From coreboot
Jump to: navigation, search
(Enabling the fallback switch: scripts + rewrite)
(some options moved to the `Chipset` menu)
 
(43 intermediate revisions by 3 users not shown)
Line 6: Line 6:
 
* One normal/ image: The image to be tested.
 
* One normal/ image: The image to be tested.
  
This feature is not widely tested on all boards. It also requires it to have a reboot_bits exported in the CMOS layout.
+
This feature is not widely tested on all boards. It also requires it to have a reboot_counter exported in the CMOS layout.
  
 
This also doesn't protect against human errors when using such feature, or bugs in the code responsible for switching between the two images.
 
This also doesn't protect against human errors when using such feature, or bugs in the code responsible for switching between the two images.
Line 15: Line 15:
 
* More compact testing setup: Since reflashing tools are not mandatory anymore, the tests can be done with less hardware, very useful when traveling.
 
* More compact testing setup: Since reflashing tools are not mandatory anymore, the tests can be done with less hardware, very useful when traveling.
  
== How it works (summary) ==
+
== How it works ==
Coreboot will switch to fallback/ if the boot count is higher than CONFIG_MAX_REBOOT_CNT (or if normal/ isn't present).
+
Coreboot increments a reboot count at each boot but never clears it. What runs after coreboot is responsible for that.
  
Coreboot increments the reboot count at each boot.
+
That way, the count can be cleared by the OS once it's fully booted.
  
Here, clearing the boot count is delegated to what is run after coreboot.
+
If a certain threshold<ref>Defined by CONFIG_MAX_REBOOT_CNT, typically 3</ref> is attained at boot, coreboot will boot the fallback image.
  
To get the maximum safety out of it, clearing the boot count after the last step of the boot is advised.
+
== Warnings ==
 +
Because we uses two images, it's easy to wrongly identify which image booted:
 +
* If the user mistakenly thinks the normal image is booting...
 +
* But the fallback image always boots...
 +
* And the normal image doesn't work...
 +
* And the user flashes the normal in fallback because she thinks it boots fine...
 +
* Then the user bricked her device and has to reflash it externally.
  
=== Example of use ===
+
== Fallback build  ==
For instance once the system is fully booted, a systemd unit can reset the boot count.
+
To configure it for fallback, do:
 +
$ make menuconfig
 +
Then in "General setup  --->", near the top use "fallback" in "CBFS prefix to use":
 +
(fallback) CBFS prefix to use
 +
Then near the bottom, make sure to have:
 +
[ ] Update existing coreboot.rom image
 +
And in the "Chipset  --->" menu at the bottom:
 +
Bootblock behaviour (Switch to normal if CMOS says so)  --->
 +
[*] Do not clear reboot count after successful boot
  
That way if the coreboot changes makes it impossible to boot a linux kernel or even if GNU/Linux can't fully boot, the boot count won't be reset.
+
You can then build the fallback image with the [[Fallback mechanism/fallback.sh|fallback.sh]] script.
  
Then the user will power off the computer, and at the next boot CONFIG_MAX_REBOOT_CNT will hopefully be reached.
+
== Normal build ==
Then coreboot will boot on the good known working image and the boot will complete.
+
To configure it for normal, do:
 +
$ make menuconfig
 +
Then in "General setup  --->", near the top use "normal" in "CBFS prefix to use":
 +
(normal) CBFS prefix to use
 +
Then near the bottom, make sure to have:
 +
[*] Update existing coreboot.rom image
 +
And in the "Chipset  --->" menu at the bottom:
 +
Bootblock behaviour (Switch to normal if CMOS says so)  --->
 +
[*] Do not clear reboot count after successful boot
  
At that point the user is expected to reflash a good image in order not to go in normal/ again at the next boot.
+
You can then build with the normal part with the [[Fallback mechanism/normal.sh|normal.sh]] script. It takes an existing coreboot image as argument.
  
== Current limitations ==
+
== OS configuration ==
* scripts exist only for the systemd init system, but they are easy to adapt to other init systems
+
 
* suspend/resume systemd scripts not written yet
+
=== The manual way ===
* some issues can arrise when the nvram layout is not the same between normal/ and fallback/
+
An approach is to run switch-to-normal.sh before trying an image.
* The number of failed boot is 3 by default (for all boards that don't set CONFIG_MAX_REBOOT_CNT)
+
It's however more error prone than the systemd approach because:
* In order to fully boot, some boards do reboot once during the boot procedure. The issue is that it reboot conditionally, and no code has been written yet to take that into account.
+
* you have to do it manually, each time, before testing an image.
* Payloads can have non-configurable default locations when loading things from cbfs:
+
* If you then want to use that new image, you have to flash it, again, to fallback.
** When using grub as a payload, grub.cfg is at etc/grub.cfg by default, so if you want to test grub as a payload, remember to change grub.cfg's path not to interfer with the fallback's grub configuration.
 
** Changing the path of what SeaBIOS loads from cbfs is probably configurable with SeaBIOS cbfs symlinks but not yet tested/documented with the use of the fallback mecanism
 
* Complexity for the user:
 
** Once the normal/ image has been tested, if the user wants to flash it to fallback/ he will have to make sure that the normal/ image was running when he tested it, and that it was not the fallback/ (that could happen due to an error of the user for instance), cbmem -c is a good way to do it.
 
** The user has to check if the coreboot image with fallback/ that he is adding normal/ to, had CONFIG_BOOTBLOCK_NORMAL enabled. Else it will probably keep booting on normal/
 
  
== Using it ==
+
==== switch-to-normal.sh ====
=== Prerequisites ===
+
#!/bin/sh
* Make sure that your fallback/ image has the [[Fallback_mechanism#Enabling_the_fallback_switch|fallback switch mecanism enabled]]
+
nvramtool -w boot_option=Normal
* Build the fallback image as you would build an image usually
+
nvramtool -w reboot_counter=0
== Building the coreboot.rom image ==
 
=== Building normal/ (normal.sh) ===
 
This scrpit takes an existing coreboot image path as argument.
 
  
 +
==== switch-to-fallback.sh ====
 
  #!/bin/sh
 
  #!/bin/sh
  # In the cases where this work is copyrightable, it falls under the GPLv2
+
  nvramtool -w boot_option=Fallback
# or later license that is available here:
+
  nvramtool -w reboot_counter=15
# https://www.gnu.org/licenses/gpl-2.0.txt
+
 
+
(Assuming that 15 is the maximum that can be stored in reboot_counter.)
image="$1"
 
  if [ $# -ne 1 ] ; then
 
echo "Usage $0 <image>"
 
exit 1
 
fi
 
 
die()
 
{
 
  echo "$1 Failed"
 
  exit 1
 
}
 
 
cbfs_add()
 
{
 
  name=$1
 
  file=$2
 
  cbfs_remove ${name}
 
  ./util/cbfstool/cbfstool ./build/coreboot.rom add -n ${name} -t raw -f ${file}
 
}
 
 
cbfs_remove()
 
{
 
  name=$1
 
  ./util/cbfstool/cbfstool ./build/coreboot.rom remove -n ${name}
 
}
 
 
cbfs_reuse_payload()
 
{
 
  ./util/cbfstool/cbfstool ./build/coreboot.rom extract -f ./build/payload.elf -n fallback/payload
 
  ./util/cbfstool/cbfstool ./build/coreboot.rom add -f ./build/payload.elf -n normal/payload -t payload
 
}
 
 
check_config()
 
{
 
  grep "^CONFIG_CBFS_PREFIX=\"normal\"$" .config > /dev/null || die "Not using normal cbfs prefix"
 
  grep "^CONFIG_UPDATE_IMAGE=y$" .config > /dev/null || die "Not using CONFIG_UPDATE_IMAGE"
 
  grep "^CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR=y" .config > /dev/null || die "Not using CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR"
 
}
 
 
check_config
 
make oldconfig || die "make oldconfig"
 
make clean || die "clean"
 
mkdir build/ || die "mkdir build"
 
 
cp ${image} ./build/coreboot.rom || die "cp"
 
 
cbfs_remove normal/romstage
 
cbfs_remove normal/ramstage
 
cbfs_remove normal/payload
 
cbfs_remove normal/dsdt.aml
 
cbfs_remove config
 
cbfs_remove revision
 
 
# it now adds it automatically
 
cbfs_remove etc/ps2-keyboard-spinup
 
 
 
make || die "make"
 
 
# uncomment if you want to reuse fallback's payload
 
# cbfs_reuse_payload
 
 
./util/cbfstool/cbfstool ./build/coreboot.rom print
 
  
=== OS configuration examples ===
+
=== Systemd ===
The configurations below assume that the user wants to keep booting on normal/ if the boot doesn't fail.
+
Here we use systemd to automatically reset the boot counter after each successful boot (or resume).
  
==== Example scripts ====
+
We are then supposed to use the normal image daily and only resort to fallback in case of issues.
The most simple way to do it is to run some nvramtool commands, they are described in the scripts below.
 
set-normal-0.sh has to be run:
 
* After the boot is completed and is declared a success.
 
* After the resuming is completed.
 
  
The way to make them run at boot and after suspend is not described here yet.
+
To install it, first install nvramtool (from coreboot sources):
 +
$ cd util/nvramtool
 +
$ make
 +
$ sudo make install
  
===== set-fallback-1.sh =====
+
Then add the following systemd units at their respective paths:
#!/bin/sh
+
* [[Fallback_mechanism/coreboot@boot.service|/etc/systemd/system/coreboot@boot.service]]
nvramtool -w boot_option=Fallback
+
* [[Fallback_mechanism/coreboot@resume.service|/etc/systemd/system/coreboot@resume.service]]
nvramtool -w last_boot=Fallback
 
nvramtool -w reboot_bits=1
 
===== set-normal-0.sh =====
 
#!/bin/sh
 
nvramtool -w boot_option=Normal
 
nvramtool -w last_boot=Normal
 
nvramtool -w reboot_bits=0
 
  
===== get-nvram.sh =====
+
Then enable them with:
  #!/bin/sh
+
$ sudo systemctl enable coreboot@boot.service
  nvramtool -a | grep -e boot_option -e last_boot -e reboot_bits
+
  $ sudo systemctl start coreboot@boot.service
 +
  $ sudo systemctl enable coreboot@resume.service
 +
$ sudo systemctl start coreboot@resume.service
  
==== With systemd ====
+
== Current limitations ==
===== Systemd setup =====
+
* '''Use of the same cmos.layout in fallback and normal !'''
Requirements:
+
* The user may wrongly identify which image booted, and because of that, end up reflashing a non-working image.
* nvramtool has to be in the path.
+
* Some issues can arrise when the nvram layout is not the same between normal/ and fallback/
 +
* The number of failed boot is fixed at compilation time.
 +
* In order to fully boot, some boards do reset conditionally during the boot process resulting in a non-predictable increment of the boot count.
 +
* Example script exist only for systemd. Still, they are trivial to adapt to other init systems.
 +
* Payloads sometime have fixed default locations when loading things from cbfs:
 +
** When using grub as a payload, grub.cfg is at etc/grub.cfg by default, so if you want to test grub as a payload, remember to change grub.cfg's path not to interfer with the fallback's grub configuration.
 +
** Changing the path of what SeaBIOS loads from cbfs is probably configurable with SeaBIOS cbfs symlinks but not yet tested/documented with the use of the fallback mecanism
 +
* Tested boards need to be listed somewhere.
  
Limitations:
+
== Issues ==
* This setup doesn't needs to run that systemd unit when resuming from suspend to ram, but it's not described yet here.
+
=== thinkpad_acpi ===
 +
This linux driver can have some bad interactions with the fallback/normal mecanism: when using it with the volume_control=1 option, volume_mode=1 is required, otherwise after shutting down the computer, it will always boot from fallback.
  
The unit file below has to be activated with:
+
This might be because as the default settings of volume_mode touches the nvram, it probably corrupts it at shutdown when saving the alsa state of the volume buttons "sound card" (called EC Mixer). Then at boot, coreboot will detects a corrupted nvram and restore its valid defaults.
systemctl enable coreboot-booted-ok
 
systemctl start coreboot-booted-ok
 
  
===== /etc/systemd/system/coreboot-booted-ok.service: =====
+
== references ==
#  This file is not part of systemd.
+
<references/>
#
 
#  this file is free software; you can redistribute it and/or modify it
 
#  under the terms of the GNU Lesser General Public License as published by
 
#  the Free Software Foundation; either version 2.1 of the License, or
 
#  (at your option) any later version.
 
 
[Unit]
 
Description=Tell coreboot that the computer booted fine.
 
DefaultDependencies=no
 
Wants=display-manager.service
 
After=display-manager.service
 
 
[Service]
 
Type=oneshot
 
RemainAfterExit=yes
 
ExecStart=/usr/local/sbin/nvramtool -w boot_option=Normal
 
ExecStart=/usr/local/sbin/nvramtool -w last_boot=Normal
 
ExecStart=/usr/local/sbin/nvramtool -w reboot_bits=0
 
 
[Install]
 
WantedBy=multi-user.target
 

Latest revision as of 20:59, 25 February 2018

Introduction

This mechanism permits to test and recover from certain non-booting coreboot images.

This works by having two coreboot images in the same flash chip:

  • One fallback/ image: The working image.
  • One normal/ image: The image to be tested.

This feature is not widely tested on all boards. It also requires it to have a reboot_counter exported in the CMOS layout.

This also doesn't protect against human errors when using such feature, or bugs in the code responsible for switching between the two images.

Uses cases

  • Test new images way faster: if the image doesn't boot it will fallback on the old known-working image and save a long reflashing procedure. Handy for bisecting faster.
  • Test new images more safely: Despite of the recommendations of having a way to externally reflash, many new user don't. Still, this method is not totally foolproof.
  • More compact testing setup: Since reflashing tools are not mandatory anymore, the tests can be done with less hardware, very useful when traveling.

How it works

Coreboot increments a reboot count at each boot but never clears it. What runs after coreboot is responsible for that.

That way, the count can be cleared by the OS once it's fully booted.

If a certain threshold[1] is attained at boot, coreboot will boot the fallback image.

Warnings

Because we uses two images, it's easy to wrongly identify which image booted:

  • If the user mistakenly thinks the normal image is booting...
  • But the fallback image always boots...
  • And the normal image doesn't work...
  • And the user flashes the normal in fallback because she thinks it boots fine...
  • Then the user bricked her device and has to reflash it externally.

Fallback build

To configure it for fallback, do:

$ make menuconfig

Then in "General setup --->", near the top use "fallback" in "CBFS prefix to use":

(fallback) CBFS prefix to use

Then near the bottom, make sure to have:

[ ] Update existing coreboot.rom image

And in the "Chipset --->" menu at the bottom:

Bootblock behaviour (Switch to normal if CMOS says so)  --->
[*] Do not clear reboot count after successful boot

You can then build the fallback image with the fallback.sh script.

Normal build

To configure it for normal, do:

$ make menuconfig

Then in "General setup --->", near the top use "normal" in "CBFS prefix to use":

(normal) CBFS prefix to use

Then near the bottom, make sure to have:

[*] Update existing coreboot.rom image

And in the "Chipset --->" menu at the bottom:

Bootblock behaviour (Switch to normal if CMOS says so)  --->
[*] Do not clear reboot count after successful boot

You can then build with the normal part with the normal.sh script. It takes an existing coreboot image as argument.

OS configuration

The manual way

An approach is to run switch-to-normal.sh before trying an image. It's however more error prone than the systemd approach because:

  • you have to do it manually, each time, before testing an image.
  • If you then want to use that new image, you have to flash it, again, to fallback.

switch-to-normal.sh

#!/bin/sh
nvramtool -w boot_option=Normal
nvramtool -w reboot_counter=0

switch-to-fallback.sh

#!/bin/sh
nvramtool -w boot_option=Fallback
nvramtool -w reboot_counter=15

(Assuming that 15 is the maximum that can be stored in reboot_counter.)

Systemd

Here we use systemd to automatically reset the boot counter after each successful boot (or resume).

We are then supposed to use the normal image daily and only resort to fallback in case of issues.

To install it, first install nvramtool (from coreboot sources):

$ cd util/nvramtool
$ make
$ sudo make install

Then add the following systemd units at their respective paths:

Then enable them with:

$ sudo systemctl enable coreboot@boot.service
$ sudo systemctl start coreboot@boot.service
$ sudo systemctl enable coreboot@resume.service
$ sudo systemctl start coreboot@resume.service

Current limitations

  • Use of the same cmos.layout in fallback and normal !
  • The user may wrongly identify which image booted, and because of that, end up reflashing a non-working image.
  • Some issues can arrise when the nvram layout is not the same between normal/ and fallback/
  • The number of failed boot is fixed at compilation time.
  • In order to fully boot, some boards do reset conditionally during the boot process resulting in a non-predictable increment of the boot count.
  • Example script exist only for systemd. Still, they are trivial to adapt to other init systems.
  • Payloads sometime have fixed default locations when loading things from cbfs:
    • When using grub as a payload, grub.cfg is at etc/grub.cfg by default, so if you want to test grub as a payload, remember to change grub.cfg's path not to interfer with the fallback's grub configuration.
    • Changing the path of what SeaBIOS loads from cbfs is probably configurable with SeaBIOS cbfs symlinks but not yet tested/documented with the use of the fallback mecanism
  • Tested boards need to be listed somewhere.

Issues

thinkpad_acpi

This linux driver can have some bad interactions with the fallback/normal mecanism: when using it with the volume_control=1 option, volume_mode=1 is required, otherwise after shutting down the computer, it will always boot from fallback.

This might be because as the default settings of volume_mode touches the nvram, it probably corrupts it at shutdown when saving the alsa state of the volume buttons "sound card" (called EC Mixer). Then at boot, coreboot will detects a corrupted nvram and restore its valid defaults.

references

  1. Defined by CONFIG_MAX_REBOOT_CNT, typically 3