Skip to content

Latest commit

 

History

History
233 lines (161 loc) · 10.1 KB

setting_gbb_flags.md

File metadata and controls

233 lines (161 loc) · 10.1 KB

Why?

screw

setting gbb flags will keep your device in developer mode with option to boot from usb at any time even if your battery runs dry

these flags are usually protected by hardware write protection so you will need to disable it first

But before

in order to set gbb flags you need to enable developer mode on your device

Disabling hardware write protection

hardware write protection can be dissabled in a few ways

Removing a screw or shorting a circut (older chromebooks)

Warning. opening your chromebook will likely void your warranty and may result in your device being bricked even if you think you know what you are doing

Note. only on some chromebooks, if you don't see your device below it either doesn't have this or you will have to look it up urself

below is a list of known write protection screws/circuts

lenovo 10e

the circut is located on the motherboard screw described in Hardware Maintanance Manual

Tip. you can look for hardware maintanace manual for ur device urself, these are sometimes mentioned there

Note. if you find one yourself PR is welcome

Disconnecting battery

Warning. opening your chromebook will likely void your warranty and may result in your device being bricked even if you think you know what you are doing

Note. this might not work on all chromebooks, for example ideapad duet

  1. this option like the one above requires you to open up your device
  2. disconnect the battery from the mainboard and connect
  3. connect the device to a charger Note. there are minimal voltage requirements for device to turn on, you device doesn't turn on, it's likely your power source is too weak
  4. turn on your device

as long as the battery is disconnected the write protection should be dissabled on most devices

Using suzyqable (recommended, modern chromebooks)

in order to perform this you will need suzyqcable to, buy or make one

enter tty and check if CCD (Closed Case Debugging) is opened

gsctool -a -I

if it is opened you can skip opening it

but if it isn't run

gsctool -a -o

Note. it will require you to press PP button (a fancy word for "person presence" button which usually is the power button of the device) shortly (to not power off the device) a few times, if you screen turns off after pressing that button just press it twice in a row quicklu

after last press the device will shutdonw and you will have to enable developer mode again

now running

gsctool -a -I

should show that ccd is open

now plugin suzyqcable to your chromebook or diffrent pc

Note. if you do this from diffrent pc, you run commands below on that pc, also this is linux only

Note. it will only work plugged into one of chromebooks ports and in one orientation

now check if it works

ls /dev/ttyU*

output

ttyUSB0 ttyUSB1 ttyUSB2

Note. this may not appear on some chromebooks with non chromeos (due to a partially broken usb-stack in mainline linux for them), in such a case you can connect the other end diffrent linux pc

Note. you can connect the device to itself if it has 2 ports

you can disable hardware writeprotection on any linux/chromeos (as long as device gets detected) with

echo "wp false" > /dev/ttyUSB0
echo "wp false atboot" > /dev/ttyUSB0

Note. on debian devices that detect the ttyUSB0 you can use minicom -D /dev/ttyUSB0 (sudo apt install minicom) to see whats going on behind the sceen and type the same commands as below but without "echo" and "/dev/ttyUSB0" part

after doing it enable it back just to be safe

echo "wp true" > /dev/ttyUSB0
echo "wp true atboot" > /dev/ttyUSB0

The Open state is lost if Cr50 reboots, the device loses power (e.g., battery runs out and AC is not plugged in), or the battery is removed. Note that Cr50 does not reboot when the system reboots; it only reboots if it is updated, the devices loses power, the battery runs out, or it crashes. If you plan on flashing the AP firmware or flashing the EC firmware, it is recommended you modify the capability settings or set a CCD password, so you can reopen the device in the case that you accidentally brick it with bad firmware. The simplest way to do this is to reset to factory settings and enable testlab mode. more

Note. This isn't required and will require you to press pp button a few times, so it might be easier to do it using minicom

echo "ccd reset factory" > /dev/ttyUSB0
echo "ccd testlab enable" > /dev/ttyUSB0

sources :

Setting gbb flags

gbb flags set some default behaviour for a chromeook which canl result in it not forgetting being in developer mode and being able to boot from usb devices if the battery runs dry (especially for older chromebooks). as a result you won't lose access to your system in such a case

in order to set gbb flags you need to enable developermode and disable hardware write protection

Note. on new chromeos you might encounter command not found error

this is likely due to broken PATH variable to work around this you can run

find / -name <command> 2>/dev/null

your out put should be for example

/usr/bin/<command>

and you run

/usr/bin/<command> <arguments>

  1. start by booting chrome os and entering tty with [ctrl] [alt] [->] or [ctrl] [alt] [refresh] or [ctrl] [alt] [f2]

  2. login with username chronos (no password required)

  3. move to directory where touch testfile works (cd /tmp should be ok)

  4. check software write protection with flashrom --wp-status it will probaly be enabled, you can disable it with flashrom --wp-disable and check it again with flashrom --wp-status

Note. this will only work if the hardware write protection has been disabled beforehand

Note. the command might throw unknown WP error, you can proceed and only worry if GBB flags don't update in step 6.

Recommended step

read the firmware from the flash into a file bios.bin via the command flashrom -r bios.bin.

it is a good idea to copy this file to a safe place outside of the chromebook now (sd card, usb stick etc.) to have a copy of the original unmodified firmware around just in case ...

Note. in case the boot screen should be changed as well, look here it might be a good idea to do this first to avoid resetting the changed gbb settings again then

there are a few diffrent gbb flags 
  GBB_FLAG_DEV_SCREEN_SHORT_DELAY     0x00000001
  GBB_FLAG_LOAD_OPTION_ROMS           0x00000002
  GBB_FLAG_ENABLE_ALTERNATE_OS        0x00000004
  GBB_FLAG_FORCE_DEV_SWITCH_ON        0x00000008
  GBB_FLAG_FORCE_DEV_BOOT_USB         0x00000010
  GBB_FLAG_DISABLE_FW_ROLLBACK_CHECK  0x00000020
  GBB_FLAG_ENTER_TRIGGERS_TONORM      0x00000040
  GBB_FLAG_FORCE_DEV_BOOT_LEGACY      0x00000080
  GBB_FLAG_FAFT_KEY_OVERIDE           0x00000100
  GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC   0x00000200
  GBB_FLAG_DEFAULT_DEV_BOOT_LEGACY    0x00000400
  GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC   0x00000800
  likely more

Note. some values may be not supported by all systems

it's recommended to use 0x19 for gbb flags

which combines

  • GBB_FLAG_DEV_SCREEN_SHORT_DELAY 0x00000001 - initial boot screen only for 2 seconds instead of the default 30 seconds and no beep afterwards
  • GBB_FLAG_FORCE_DEV_SWITCH_ON 0x00000008 - keep developer mode enabled by default
  • GBB_FLAG_FORCE_DEV_BOOT_USB 0x00000010 - keep the possibility to boot from usb/sd card enabled by default

  1. set the desired gbb flags via the command /usr/share/vboot/bin/set_gbb_flags.sh 0x19, on newer chromeos versions (around 112+ or so) one should use futility gbb --set --flash --flags=0x19 instead

  2. check current flags via the command /usr/share/vboot/bin/get_gbb_flags.sh (newer version: futility gbb --get --flash --flags)

  3. re-enable the software write protection via flashrom --wp-enable

in case you get an error for that command speaking about --wp-range
  • (which seems to happen on newer chromeos versions), then please do the following, see this
    1. run the command fmap_decode bios.bin
    2. note down the range for WP_RO - usually it is 0x00000000 to 0x00200000 (or 0x00400000), but better double check
    3. then rerun the failed command as (with the range noted down above) - for example flashrom --wp-enable --wp-range 0x00000000 0x00200000
  1. re-check the software write protect via flashrom --wp-status - it should be enabled again now
  2. if everything looks good, you can shutdown your system now
  3. enable hardware write protection with screw or ccd or just leave it open if that is ok

sources :