Difference between revisions of "Unbricking"

From MrChromebox Wiki
Jump to: navigation, search
(Prepping to flash)
(Prepping to flash)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Unbricking ==
 
  
If you've found your way here, it's likely because you updated your firmware and, despite best efforts to minimize the possibility,something went wrong.  Thankfully, most Chromebooks can be easily unbricked using cheap, readily available hardware from Amazon/eBay/Alibaba (and many other sources).
 
  
=== Requirements ===
+
If you've found your way here, it's likely because you updated your firmware and, despite best efforts to minimize the possibility,something went wrong.  Thankfully, most Chromebooks can be easily unbricked using cheap, readily available hardware: older Chromebooks using a ch341a USB programmer from Amazon/eBay/Alibaba (and many other sources), and newer (2017+) Chromebooks using a USB-C debug cable (aka Suzy-Q cable).
 +
 
 +
=== Unbricking/FLashing with a CH341a USB programmer ===
 +
 
 +
==== Requirements ====
  
 
* A ChromeOS device with a SOIC-8 type SPI flash chip.  Most Chromebooks use this type of chip, but there are a few notable exceptions:  
 
* A ChromeOS device with a SOIC-8 type SPI flash chip.  Most Chromebooks use this type of chip, but there are a few notable exceptions:  
Line 9: Line 11:
 
*:- Google Chromebook Pixel 2015
 
*:- Google Chromebook Pixel 2015
 
*:- HP Chromebook 13 G1
 
*:- HP Chromebook 13 G1
*:- Google Pixelbook?
+
*:- Asus Chromebook C302SA
 +
 
 
: These devices all use a WSON-8 flash chip, which does not expose the pins of the chip, so they cannot easily be "clipped" like a SOIC-8 chip.  While it is usually possible to modify a SOIC-8 chip clip to attach to a WSON-8 chip, it's less than ideal.  Both Chromebook Pixels feature a Google debug header, which can connect to a debug servo with a special cable and be flashed that way, but not an option for most users (I however do have access to one, and can unbrick Chromebook Pixels for any users upon request).
 
: These devices all use a WSON-8 flash chip, which does not expose the pins of the chip, so they cannot easily be "clipped" like a SOIC-8 chip.  While it is usually possible to modify a SOIC-8 chip clip to attach to a WSON-8 chip, it's less than ideal.  Both Chromebook Pixels feature a Google debug header, which can connect to a debug servo with a special cable and be flashed that way, but not an option for most users (I however do have access to one, and can unbrick Chromebook Pixels for any users upon request).
 
* A device running Linux from which to run flashrom.  For this guide, I will use a Ubuntu 18.04 live USB.
 
* A device running Linux from which to run flashrom.  For this guide, I will use a Ubuntu 18.04 live USB.
 
* A CH341a USB flash programmer ([https://www.amazon.com/gp/product/B01I1EU9LG/ Amazon link])
 
* A CH341a USB flash programmer ([https://www.amazon.com/gp/product/B01I1EU9LG/ Amazon link])
* A 1.8v adapter ([https://www.amazon.com/dp/B072KYK2DR/ Amazon link]) (needed for devices which use 1.8v flash chips.  Baytrail, Braswell, Skylake and most newer devices use a 1.8v flash chip)
+
* A 1.8v adapter ([https://www.amazon.com/dp/B072KYK2DR/ Amazon link]) (needed for devices which use 1.8v flash chips.  Some/Most Baytrail, Braswell, Skylake and many newer devices use a 1.8v flash chip)
 
* An SOIC-8 chip clip ([https://www.amazon.com/gp/product/B00V9QNAC4/ Amazon Link])
 
* An SOIC-8 chip clip ([https://www.amazon.com/gp/product/B00V9QNAC4/ Amazon Link])
  
These 3 components are often bundled together at a lower cost ([https://www.ebay.com/itm/132689381384 eBay link]), and if you're unsure if your device uses a 1.8v flash chip or a 3.3v one, it makes sense to have the adapter on hand if needed.
+
These 3 components are often bundled together at a lower cost ([https://www.amazon.com/dp/B07V2M5MVH Amazon link]), and if you're unsure if your device uses a 1.8v flash chip or a 3.3v one, it makes sense to have the adapter on hand if needed.
  
=== Hardware Disassembly ===
+
==== Hardware Disassembly ====
  
 
While this is somewhat device-specific, the main points are the same:  
 
While this is somewhat device-specific, the main points are the same:  
Line 33: Line 36:
 
Googling should locate a disassembly guide for most models. If you can't find one for your exact model, try to find one for another model of the same manufacturer as the bottom cover removal tends to be very similar.
 
Googling should locate a disassembly guide for most models. If you can't find one for your exact model, try to find one for another model of the same manufacturer as the bottom cover removal tends to be very similar.
  
=== Prepping to flash ===
+
==== Prepping to flash ====
  
 
Once you have your device disassembled and flash chip located, time to boot up the flashing environment.  Most any Linux setup should do as long as either flashrom is available from the distro's software repositories, or it's 64-bit x86 (in which case you can download a statically compiled build of flashrom from my site).  This guide will use a Ubuntu 18.04 live session booted from USB.  
 
Once you have your device disassembled and flash chip located, time to boot up the flashing environment.  Most any Linux setup should do as long as either flashrom is available from the distro's software repositories, or it's 64-bit x86 (in which case you can download a statically compiled build of flashrom from my site).  This guide will use a Ubuntu 18.04 live session booted from USB.  
Line 41: Line 44:
 
* Boot your Linux environment (Ubuntu live USB or otherwise)
 
* Boot your Linux environment (Ubuntu live USB or otherwise)
 
* Open a (non-root) terminal/shell window, change to home directory
 
* Open a (non-root) terminal/shell window, change to home directory
:: <nowiki>cd;</nowiki>
+
:: <pre>cd;</pre>
 
* Download flashrom (from my website) and extract:
 
* Download flashrom (from my website) and extract:
:: <nowiki>wget https://mrchromebox.tech/files/util/flashrom.0602.tar.gz && tar -zxf flashrom.0602.tar.gz</nowiki>
+
:: <pre>wget https://mrchromebox.tech/files/util/flashrom_20200918.tar.gz && tar -zxf flashrom_20200918.tar.gz</pre>
:'''NOTE:''' while some distros include flashrom already, most (as of the writing of this document) are using an older version (pre-1.0) which lacks some of the features used here, so I've provided a statically compiled updated version (1.0) which should run on any x86_64-based system.
+
:'''NOTE:''' while some distros include flashrom already, some are using an older version (pre-1.2) which lacks some of the features used here, so I've provided a statically compiled updated version (1.2) which should run on any x86_64-based system.
 
* Assemble CH341a programmer, 1.8v adapter (if needed), and chip clip/wiring. Ensure that pin 1 is correct and consistent.
 
* Assemble CH341a programmer, 1.8v adapter (if needed), and chip clip/wiring. Ensure that pin 1 is correct and consistent.
 
: [[File:Ch341a annotated.png|500px]]
 
: [[File:Ch341a annotated.png|500px]]
Line 50: Line 53:
 
: : [[File:SOIC-8 chip.jpg|500px]]
 
: : [[File:SOIC-8 chip.jpg|500px]]
 
* Test connectivity and ensure the flash chip is properly identified:
 
* Test connectivity and ensure the flash chip is properly identified:
:: <nowiki>sudo ./flashrom -p ch341a_spi</nowiki>
+
:: <pre>sudo ./flashrom -p ch341a_spi</pre>
 
: Flashrom will produce output identifying the flash chip. If it doesn't, double check your connections to the programmer and the chip clip and retry.
 
: Flashrom will produce output identifying the flash chip. If it doesn't, double check your connections to the programmer and the chip clip and retry.
 
: [[File:Flashrom chip detect.png|500px]]
 
: [[File:Flashrom chip detect.png|500px]]
Line 59: Line 62:
 
::- The custom UEFI firmware for the device
 
::- The custom UEFI firmware for the device
 
::: If you were flashing the UEFI firmware when things went sideways, then that's the easiest way to proceed.  You can download the UEFI firmware for your device by examining [https://github.com/MrChromebox/scripts/blob/master/sources.sh the sources.sh file from the Firmware Utility Script github repo].  Simply concatenate the device-specific filename to the Full ROM base path:
 
::: If you were flashing the UEFI firmware when things went sideways, then that's the easiest way to proceed.  You can download the UEFI firmware for your device by examining [https://github.com/MrChromebox/scripts/blob/master/sources.sh the sources.sh file from the Firmware Utility Script github repo].  Simply concatenate the device-specific filename to the Full ROM base path:
:::: <nowiki> wget <Full ROM base path><device specific filename></nowiki>
+
:::: <pre> wget <Full ROM base path><device specific filename></pre>
 
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR)
 
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR)
::::<nowiki>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom</nowiki>
+
::::<pre>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom</pre>
 
::: Don't forget to get the sha1 file for verification:
 
::: Don't forget to get the sha1 file for verification:
:::: <nowiki>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</nowiki>
+
:::: <pre>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</pre>
 
::: Then verify the download:
 
::: Then verify the download:
:::: <nowiki>sha1sum -c coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</nowiki>
+
:::: <pre>sha1sum -c coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</pre>
 
::- The shellball firmware for the device
 
::- The shellball firmware for the device
 
::: As with the UEFI firmware above, the shellball rom can be downloaded by concatenating the shellball base path with the device-specific filename:
 
::: As with the UEFI firmware above, the shellball rom can be downloaded by concatenating the shellball base path with the device-specific filename:
::::<nowiki>wget <shellball base path>/shellball.<device name>.bin</nowiki>
+
::::<pre>wget <shellball base path>/shellball.<device name>.bin</pre>
 
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR):
 
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR):
:::: <nowiki>wget https://mrchromebox.tech/files/firmware/shellball/shellball.edgar.bin</nowiki>
+
:::: <pre>wget https://mrchromebox.tech/files/firmware/shellball/shellball.edgar.bin</pre>
 +
 
 +
If you're not sure which file to use for your device / don't know your device's board name, you can reference:<br>
 +
https://mrchromebox.tech/#devices and/or http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
  
 
'''Special Note/Step for Chromeboxes'''
 
'''Special Note/Step for Chromeboxes'''
Line 81: Line 87:
 
For both the options below, we'll need to use the cbfstool (coreboot filesystem) binary, so let's download/extract that:
 
For both the options below, we'll need to use the cbfstool (coreboot filesystem) binary, so let's download/extract that:
  
: <nowiki>wget https://mrchromebox.tech/files/util/cbfstool.tar.gz && tar -zxf cbfstool.tar.gz</nowiki>
+
: <pre>wget https://mrchromebox.tech/files/util/cbfstool.tar.gz && tar -zxf cbfstool.tar.gz</pre>
  
 
Option 1a: extract VPD from Full ROM firmware on device (if bricked when flashing Full ROM firmware)
 
Option 1a: extract VPD from Full ROM firmware on device (if bricked when flashing Full ROM firmware)
: <nowiki>sudo ./flashrom -p ch341a_spi -r badflash.rom</nowiki>
+
: <pre>sudo ./flashrom -p ch341a_spi -r badflash.rom</pre>
: <nowiki>./cbfstool badflash.rom extract -n vpd.bin -f vpd.bin</nowiki>
+
: <pre>./cbfstool badflash.rom extract -n vpd.bin -f vpd.bin</pre>
  
 
Option 1b: extract VPD from stock firmware on device (if bricked when restoring stock firmware)
 
Option 1b: extract VPD from stock firmware on device (if bricked when restoring stock firmware)
: <nowiki>sudo ./flashrom -p ch341a_spi -r badflash.rom</nowiki>
+
: <pre>sudo ./flashrom -p ch341a_spi -r badflash.rom</pre>
: <nowiki>./cbfstool badflash.rom read -r RO_VPD -f vpd.bin</nowiki>
+
: <pre>./cbfstool badflash.rom read -r RO_VPD -f vpd.bin</pre>
  
 
Option 2: extract VPD from stock firmware backup created by Firmware Utility Script  
 
Option 2: extract VPD from stock firmware backup created by Firmware Utility Script  
 
(this assumes the file has been copied into working directory)
 
(this assumes the file has been copied into working directory)
: <nowiki>./cbfstool stock-firmware-<devicename>-<date>.rom read -r RO_VPD -f vpd.bin</nowiki>
+
: <pre>./cbfstool stock-firmware-<devicename>-<date>.rom read -r RO_VPD -f vpd.bin</pre>
  
 
Then we inject the VPD into the firmware image to be flashed.
 
Then we inject the VPD into the firmware image to be flashed.
 
If flashing a Full ROM firmware image:
 
If flashing a Full ROM firmware image:
: <nowiki>./cbfstool <Full ROM filename> add -n vpd.bin -f vpd.bin -t raw</nowiki>
+
: <pre>./cbfstool <Full ROM filename> add -n vpd.bin -f vpd.bin -t raw</pre>
 
If flashing a Shellball ROM firmware image:
 
If flashing a Shellball ROM firmware image:
: <nowiki>./cbfstool <Shellball ROM filename> write -r RO_VPD -f vpd.bin</nowiki>
+
: <pre>./cbfstool <Shellball ROM filename> write -r RO_VPD -f vpd.bin</pre>
  
 
Now the firmware image is ready to be flashed, and will maintain the device's unique LAN MAC address.
 
Now the firmware image is ready to be flashed, and will maintain the device's unique LAN MAC address.
  
=== Flashing Your Device ===
+
==== Flashing Your Device ====
  
 
Now that everything is prepped, time to flash the device. To be thorough, we'll perform a 2nd verification after flashing to ensure the integrity of the flashed firmware.
 
Now that everything is prepped, time to flash the device. To be thorough, we'll perform a 2nd verification after flashing to ensure the integrity of the flashed firmware.
Line 109: Line 115:
 
* Flash the firmware:
 
* Flash the firmware:
 
: If flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
 
: If flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
::<nowiki>sudo ./flashrom -p ch341a_spi --ifd -i bios -w <filename></nowiki>
+
::<pre>sudo ./flashrom -p ch341a_spi --ifd -i bios -w <filename></pre>
 
: otherwise use
 
: otherwise use
::<nowiki>sudo ./flashrom -p ch341a_spi -w <filename></nowiki>
+
::<pre>sudo ./flashrom -p ch341a_spi -w <filename></pre>
 
: Where <filename> is the name of your backup file, UEFI firmware file, or shellball firmware file.  This will usually take 30s-90s to complete; flashrom will first read the flash chip, determine which sectors differ, erase those sectors, write the new data, then verify the data written.
 
: Where <filename> is the name of your backup file, UEFI firmware file, or shellball firmware file.  This will usually take 30s-90s to complete; flashrom will first read the flash chip, determine which sectors differ, erase those sectors, write the new data, then verify the data written.
 
* Verify the firmware
 
* Verify the firmware
 
: Even though flashrom does this as part of the write process, verifying the entire flash chip is quick and an easy way to ensure everything went as it should:
 
: Even though flashrom does this as part of the write process, verifying the entire flash chip is quick and an easy way to ensure everything went as it should:
 
: As before, if flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
 
: As before, if flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
::<nowiki>sudo ./flashrom -p ch341a_spi --ifd -i bios -v <filename></nowiki>
+
::<pre>sudo ./flashrom -p ch341a_spi --ifd -i bios -v <filename></pre>
 
: otherwise use
 
: otherwise use
::<nowiki>sudo ./flashrom -p ch341a_spi -v <filename></nowiki>
+
::<pre>sudo ./flashrom -p ch341a_spi -v <filename></pre>
 
: using the same filename as before. If the verification passes, then disconnect the CH341a from the host machine, and then remove the chip clip.
 
: using the same filename as before. If the verification passes, then disconnect the CH341a from the host machine, and then remove the chip clip.
  
=== Clean Up ===
+
==== Clean Up ====
  
 
Reassembly is the reverse of disassembly. Reconnect the internal battery and replace the bottom cover. Flip over the device, connect external power, press the power button, and cross your fingers :)
 
Reassembly is the reverse of disassembly. Reconnect the internal battery and replace the bottom cover. Flip over the device, connect external power, press the power button, and cross your fingers :)
 +
 +
 +
 +
=== Unbricking/Flashing with a Suzy-Q cable ===
 +
 +
==== Requirements ====
 +
 +
* A ChromeOS device with CCD (closed-case debugging) enabled on one of the USB-C ports. If your device uses CR50 for the firmware write protection, then it has CCD capability.
 +
*: '''IMPORTANT''': These instructions do not apply to any device which is locked/managed -- enterprise/edu enrollment locks out CCD functionality completely
 +
* A USB-C debug cable ([https://www.sparkfun.com/products/14746 aka Suzy-Q cable])
 +
* The device must have the CCD flags factory reset (as per my instructions to disable firmware write protection), or the battery must be unplugged/disconnected from the mainboard.
 +
* Another device running Linux, preferably a current Debian/Ubuntu-based distro
 +
 +
==== Hardware Disassembly ====
 +
 +
As above, this is only needed if you failed to factory reset the CCD flags as part of disabling the device's firmware write-protection. While this is somewhat device-specific, the main points are the same:
 +
 +
* Disconnect all external power
 +
* Remove bottom cover (screws are often located under rubber feet or strips)
 +
* Disconnect the internal battery
 +
 +
==== Prepping to flash ====
 +
 +
Most any 64-bit Debian/Ubuntu based distro should work here, but this guide will use a Ubuntu 20.10 live session booted from USB.
 +
 +
Let's get to it:
 +
 +
* Boot your Linux environment (Ubuntu live USB or otherwise)
 +
* Open a (non-root) terminal/shell window, change to home directory
 +
:: <pre>cd;</pre>
 +
* Download Google's HCD tools repo: and extract:
 +
:: <pre>wget -O standalone-hdctools.tar.gz https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools/+archive/master.tar.gz</pre><pre>mkdir -p standalone-hdctools</pre><pre>tar -zxf standalone-hdctools.tar.gz -C standalone-hdctools</pre>
 +
:or clone via git (easier IMO):
 +
:: <pre>git clone https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools</pre>
 +
* change to the standalone-hdctools directory:
 +
::<pre>cd standalone-hdctools</pre>
 +
* Connect the USB-C end of the Suzy-Q cable to the CCD port on your ChromeOS device (usually left USB-C port) and the USB-A end to your Linux device
 +
* Verify the cable is properly connected:
 +
:: <pre>ls /dev/ttyUSB*</pre>
 +
:: This command should return 3 items: ttyUSB0, ttyUSB1, and ttyUSB2
 +
:: If not, then your cable is connected to the wrong port or is upside down; adjust and repeat comment until output is as expected
 +
* Set the CCD state to open:
 +
:: <pre>echo "ccd open" > /dev/ttyUSB0</pre>
 +
* Compile and build CrOS flashrom:
 +
:: <pre>./flashrom install</pre>
 +
* Determine file to be flashed
 +
: Depending on your desired use for the device, you have 3 options for flashing:
 +
::- The backup file of the stock firmware created by my Firmware Utility Script
 +
::: If using this, simply copy the file from USB into the home directory of the live USB user
 +
::- The custom UEFI firmware for the device
 +
::: If you were flashing the UEFI firmware when things went sideways, then that's the easiest way to proceed.  You can download the UEFI firmware for your device by examining [https://github.com/MrChromebox/scripts/blob/master/sources.sh the sources.sh file from the Firmware Utility Script github repo].  Simply concatenate the device-specific filename to the Full ROM base path:
 +
:::: <pre> wget <Full ROM base path><device specific filename></pre>
 +
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR)
 +
::::<pre>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom</pre>
 +
::: Don't forget to get the sha1 file for verification:
 +
:::: <pre>wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</pre>
 +
::: Then verify the download:
 +
:::: <pre>sha1sum -c coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1</pre>
 +
::- The shellball firmware for the device
 +
::: As with the UEFI firmware above, the shellball rom can be downloaded by concatenating the shellball base path with the device-specific filename:
 +
::::<pre>wget <shellball base path>/shellball.<device name>.bin</pre>
 +
::: eg for the Acer Chromebook 14 CB3-431 (EDGAR):
 +
:::: <pre>wget https://mrchromebox.tech/files/firmware/shellball/shellball.edgar.bin</pre>
 +
 +
If you're not sure which file to use for your device / don't know your device's board name, you can reference:<br>
 +
https://mrchromebox.tech/#devices and/or http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
 +
 +
'''Special Note/Step for Chromeboxes'''
 +
 +
Devices which have an Ethernet port usually store the LAN MAC address in the VPD (vital product data) section of the stock firmware. When flashing via the Firmware Utility Script, the script will automatically extract and repackage this in a way the UEFI firmware can use (in a file called vpd.bin), so the LAN MAC address of the device is maintained.  Without this, the device will use a default/generic LAN MAC address set by coreboot. While not ideal, this is only really an issue if two or more of the same device are on the same LAN segment (or you're statically assigning IP addresses based on MAC). But for completeness, if flashing the UEFI firmware or shellball ROM, we'll extract the VPD (either from the board itself or a backup made by the script) and inject it into the firmware to be flashed.
 +
 +
'''NOTE:''' you don't need to do this if flashing a stock firmware backup created by the Firmware Utility Script; that image already contains the VPD.
 +
 +
 +
For both the options below, we'll need to use the cbfstool (coreboot filesystem) binary, so let's download/extract that:
 +
 +
: <pre>wget https://mrchromebox.tech/files/util/cbfstool.tar.gz && tar -zxf cbfstool.tar.gz</pre>
 +
 +
Option 1a: extract VPD from Full ROM firmware on device (if bricked when flashing Full ROM firmware)
 +
: <pre>sudo ./flashrom -p raiden_debug_spi:target=AP -r badflash.rom</pre>
 +
: <pre>./cbfstool badflash.rom extract -n vpd.bin -f vpd.bin</pre>
 +
 +
Option 1b: extract VPD from stock firmware on device (if bricked when restoring stock firmware)
 +
: <pre>sudo ./flashrom -p raiden_debug_spi:target=AP -r badflash.rom</pre>
 +
: <pre>./cbfstool badflash.rom read -r RO_VPD -f vpd.bin</pre>
 +
 +
Option 2: extract VPD from stock firmware backup created by Firmware Utility Script
 +
(this assumes the file has been copied into working directory)
 +
: <pre>./cbfstool stock-firmware-<devicename>-<date>.rom read -r RO_VPD -f vpd.bin</pre>
 +
 +
Then we inject the VPD into the firmware image to be flashed.
 +
If flashing a Full ROM firmware image:
 +
: <pre>./cbfstool <Full ROM filename> add -n vpd.bin -f vpd.bin -t raw</pre>
 +
If flashing a Shellball ROM firmware image:
 +
: <pre>./cbfstool <Shellball ROM filename> write -r RO_VPD -f vpd.bin</pre>
 +
 +
Now the firmware image is ready to be flashed, and will maintain the device's unique LAN MAC address.
 +
 +
==== Flashing Your Device ====
 +
 +
Now that everything is prepped, time to flash the device.
 +
 +
* Flash the firmware:
 +
: If flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
 +
::<pre>sudo ./flashrom -p raiden_debug_spi:target=AP -i SI_BIOS -w <filename></pre>
 +
: otherwise use
 +
::<pre>sudo ./flashrom -p raiden_debug_spi:target=AP -w <filename></pre>
 +
: Where <filename> is the name of your backup file, UEFI firmware file, or shellball firmware file.  This will usually take 3-5 mins to complete; flashrom will first read the flash chip, determine which sectors differ, erase those sectors, write the new data, then verify the data written. The initial CCD setup make take a minute or so and not show any progress.
 +
 +
==== Clean Up ====
 +
 +
Once flashing is complete, disconnect the Suzy-Q cable. If the internal battery was not disconnected, the device will likely reboot as soon as flashing has completed. If the internal battery was disconnected, reconnect it and replace the bottom cover. Flip over the device, connect external power, press the power button, and cross your fingers :)

Latest revision as of 18:28, 13 October 2021


If you've found your way here, it's likely because you updated your firmware and, despite best efforts to minimize the possibility,something went wrong. Thankfully, most Chromebooks can be easily unbricked using cheap, readily available hardware: older Chromebooks using a ch341a USB programmer from Amazon/eBay/Alibaba (and many other sources), and newer (2017+) Chromebooks using a USB-C debug cable (aka Suzy-Q cable).

Unbricking/FLashing with a CH341a USB programmer

Requirements

  • A ChromeOS device with a SOIC-8 type SPI flash chip. Most Chromebooks use this type of chip, but there are a few notable exceptions:
    - Google Chromebook Pixel 2013
    - Google Chromebook Pixel 2015
    - HP Chromebook 13 G1
    - Asus Chromebook C302SA
These devices all use a WSON-8 flash chip, which does not expose the pins of the chip, so they cannot easily be "clipped" like a SOIC-8 chip. While it is usually possible to modify a SOIC-8 chip clip to attach to a WSON-8 chip, it's less than ideal. Both Chromebook Pixels feature a Google debug header, which can connect to a debug servo with a special cable and be flashed that way, but not an option for most users (I however do have access to one, and can unbrick Chromebook Pixels for any users upon request).
  • A device running Linux from which to run flashrom. For this guide, I will use a Ubuntu 18.04 live USB.
  • A CH341a USB flash programmer (Amazon link)
  • A 1.8v adapter (Amazon link) (needed for devices which use 1.8v flash chips. Some/Most Baytrail, Braswell, Skylake and many newer devices use a 1.8v flash chip)
  • An SOIC-8 chip clip (Amazon Link)

These 3 components are often bundled together at a lower cost (Amazon link), and if you're unsure if your device uses a 1.8v flash chip or a 3.3v one, it makes sense to have the adapter on hand if needed.

Hardware Disassembly

While this is somewhat device-specific, the main points are the same:

  • Disconnect all external power
  • Remove bottom cover (screws are often located under rubber feet or strips)
  • Disconnect the internal battery (for Chromeboxes, disconnect the small CMOS battery)
  • Locate the SPI flash chip
Most ChromeOS devices use a Winbond flash chip, though some use a compatible chip from another manufacturer, eg Gigadevices. It will be either an 8MB or 16MB chip, with the identifier W25Q64[xx] (8MB) or W25Q128[xx] (16MB) where [xx] is usually FV or DV. We do not want to touch the EC firmware chip, which is identified by W25X40[xx].
Unfortunately, many devices have the flash chip located on the top side of the main board, and require fully removing the main board in order to flash. This is true for most Baytrail and Braswell models.

Pin 1 of the flash chip will be notated by a dot/depression on the chip; be sure to align this with pin 1 on the chip clip wiring (a red strip on the example linked above).

Googling should locate a disassembly guide for most models. If you can't find one for your exact model, try to find one for another model of the same manufacturer as the bottom cover removal tends to be very similar.

Prepping to flash

Once you have your device disassembled and flash chip located, time to boot up the flashing environment. Most any Linux setup should do as long as either flashrom is available from the distro's software repositories, or it's 64-bit x86 (in which case you can download a statically compiled build of flashrom from my site). This guide will use a Ubuntu 18.04 live session booted from USB.

So let's get to it:

  • Boot your Linux environment (Ubuntu live USB or otherwise)
  • Open a (non-root) terminal/shell window, change to home directory
cd;
  • Download flashrom (from my website) and extract:
wget https://mrchromebox.tech/files/util/flashrom_20200918.tar.gz && tar -zxf flashrom_20200918.tar.gz
NOTE: while some distros include flashrom already, some are using an older version (pre-1.2) which lacks some of the features used here, so I've provided a statically compiled updated version (1.2) which should run on any x86_64-based system.
  • Assemble CH341a programmer, 1.8v adapter (if needed), and chip clip/wiring. Ensure that pin 1 is correct and consistent.
Ch341a annotated.png
  • Connect the chip clip to the SPI flash chip, then connect the CH341a to the Linux host machine. Note the dot/depression indicating pin 1.
 : SOIC-8 chip.jpg
  • Test connectivity and ensure the flash chip is properly identified:
sudo ./flashrom -p ch341a_spi
Flashrom will produce output identifying the flash chip. If it doesn't, double check your connections to the programmer and the chip clip and retry.
Flashrom chip detect.png
  • Determine file to be flashed
Depending on your desired use for the device, you have 3 options for flashing:
- The backup file of the stock firmware created by my Firmware Utility Script
If using this, simply copy the file from USB into the home directory of the live USB user
- The custom UEFI firmware for the device
If you were flashing the UEFI firmware when things went sideways, then that's the easiest way to proceed. You can download the UEFI firmware for your device by examining the sources.sh file from the Firmware Utility Script github repo. Simply concatenate the device-specific filename to the Full ROM base path:
 wget <Full ROM base path><device specific filename>
eg for the Acer Chromebook 14 CB3-431 (EDGAR)
wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom
Don't forget to get the sha1 file for verification:
wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1
Then verify the download:
sha1sum -c coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1
- The shellball firmware for the device
As with the UEFI firmware above, the shellball rom can be downloaded by concatenating the shellball base path with the device-specific filename:
wget <shellball base path>/shellball.<device name>.bin
eg for the Acer Chromebook 14 CB3-431 (EDGAR):
wget https://mrchromebox.tech/files/firmware/shellball/shellball.edgar.bin

If you're not sure which file to use for your device / don't know your device's board name, you can reference:
https://mrchromebox.tech/#devices and/or http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices

Special Note/Step for Chromeboxes

Devices which have an Ethernet port usually store the LAN MAC address in the VPD (vital product data) section of the stock firmware. When flashing via the Firmware Utility Script, the script will automatically extract and repackage this in a way the UEFI firmware can use (in a file called vpd.bin), so the LAN MAC address of the device is maintained. Without this, the device will use a default/generic LAN MAC address set by coreboot. While not ideal, this is only really an issue if two or more of the same device are on the same LAN segment (or you're statically assigning IP addresses based on MAC). But for completeness, if flashing the UEFI firmware or shellball ROM, we'll extract the VPD (either from the board itself or a backup made by the script) and inject it into the firmware to be flashed.

NOTE: you don't need to do this if flashing a stock firmware backup created by the Firmware Utility Script; that image already contains the VPD.


For both the options below, we'll need to use the cbfstool (coreboot filesystem) binary, so let's download/extract that:

wget https://mrchromebox.tech/files/util/cbfstool.tar.gz && tar -zxf cbfstool.tar.gz

Option 1a: extract VPD from Full ROM firmware on device (if bricked when flashing Full ROM firmware)

sudo ./flashrom -p ch341a_spi -r badflash.rom
./cbfstool badflash.rom extract -n vpd.bin -f vpd.bin

Option 1b: extract VPD from stock firmware on device (if bricked when restoring stock firmware)

sudo ./flashrom -p ch341a_spi -r badflash.rom
./cbfstool badflash.rom read -r RO_VPD -f vpd.bin

Option 2: extract VPD from stock firmware backup created by Firmware Utility Script (this assumes the file has been copied into working directory)

./cbfstool stock-firmware-<devicename>-<date>.rom read -r RO_VPD -f vpd.bin

Then we inject the VPD into the firmware image to be flashed. If flashing a Full ROM firmware image:

./cbfstool <Full ROM filename> add -n vpd.bin -f vpd.bin -t raw

If flashing a Shellball ROM firmware image:

./cbfstool <Shellball ROM filename> write -r RO_VPD -f vpd.bin

Now the firmware image is ready to be flashed, and will maintain the device's unique LAN MAC address.

Flashing Your Device

Now that everything is prepped, time to flash the device. To be thorough, we'll perform a 2nd verification after flashing to ensure the integrity of the flashed firmware.

  • Flash the firmware:
If flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
sudo ./flashrom -p ch341a_spi --ifd -i bios -w <filename>
otherwise use
sudo ./flashrom -p ch341a_spi -w <filename>
Where <filename> is the name of your backup file, UEFI firmware file, or shellball firmware file. This will usually take 30s-90s to complete; flashrom will first read the flash chip, determine which sectors differ, erase those sectors, write the new data, then verify the data written.
  • Verify the firmware
Even though flashrom does this as part of the write process, verifying the entire flash chip is quick and an easy way to ensure everything went as it should:
As before, if flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
sudo ./flashrom -p ch341a_spi --ifd -i bios -v <filename>
otherwise use
sudo ./flashrom -p ch341a_spi -v <filename>
using the same filename as before. If the verification passes, then disconnect the CH341a from the host machine, and then remove the chip clip.

Clean Up

Reassembly is the reverse of disassembly. Reconnect the internal battery and replace the bottom cover. Flip over the device, connect external power, press the power button, and cross your fingers :)


Unbricking/Flashing with a Suzy-Q cable

Requirements

  • A ChromeOS device with CCD (closed-case debugging) enabled on one of the USB-C ports. If your device uses CR50 for the firmware write protection, then it has CCD capability.
    IMPORTANT: These instructions do not apply to any device which is locked/managed -- enterprise/edu enrollment locks out CCD functionality completely
  • A USB-C debug cable (aka Suzy-Q cable)
  • The device must have the CCD flags factory reset (as per my instructions to disable firmware write protection), or the battery must be unplugged/disconnected from the mainboard.
  • Another device running Linux, preferably a current Debian/Ubuntu-based distro

Hardware Disassembly

As above, this is only needed if you failed to factory reset the CCD flags as part of disabling the device's firmware write-protection. While this is somewhat device-specific, the main points are the same:

  • Disconnect all external power
  • Remove bottom cover (screws are often located under rubber feet or strips)
  • Disconnect the internal battery

Prepping to flash

Most any 64-bit Debian/Ubuntu based distro should work here, but this guide will use a Ubuntu 20.10 live session booted from USB.

Let's get to it:

  • Boot your Linux environment (Ubuntu live USB or otherwise)
  • Open a (non-root) terminal/shell window, change to home directory
cd;
  • Download Google's HCD tools repo: and extract:
wget -O standalone-hdctools.tar.gz https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools/+archive/master.tar.gz
mkdir -p standalone-hdctools
tar -zxf standalone-hdctools.tar.gz -C standalone-hdctools
or clone via git (easier IMO):
git clone https://chromium.googlesource.com/chromiumos/platform/standalone-hdctools
  • change to the standalone-hdctools directory:
cd standalone-hdctools
  • Connect the USB-C end of the Suzy-Q cable to the CCD port on your ChromeOS device (usually left USB-C port) and the USB-A end to your Linux device
  • Verify the cable is properly connected:
ls /dev/ttyUSB*
This command should return 3 items: ttyUSB0, ttyUSB1, and ttyUSB2
If not, then your cable is connected to the wrong port or is upside down; adjust and repeat comment until output is as expected
  • Set the CCD state to open:
echo "ccd open" > /dev/ttyUSB0
  • Compile and build CrOS flashrom:
./flashrom install
  • Determine file to be flashed
Depending on your desired use for the device, you have 3 options for flashing:
- The backup file of the stock firmware created by my Firmware Utility Script
If using this, simply copy the file from USB into the home directory of the live USB user
- The custom UEFI firmware for the device
If you were flashing the UEFI firmware when things went sideways, then that's the easiest way to proceed. You can download the UEFI firmware for your device by examining the sources.sh file from the Firmware Utility Script github repo. Simply concatenate the device-specific filename to the Full ROM base path:
 wget <Full ROM base path><device specific filename>
eg for the Acer Chromebook 14 CB3-431 (EDGAR)
wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom
Don't forget to get the sha1 file for verification:
wget https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1
Then verify the download:
sha1sum -c coreboot_tiano-edgar-mrchromebox_20180827.rom.sha1
- The shellball firmware for the device
As with the UEFI firmware above, the shellball rom can be downloaded by concatenating the shellball base path with the device-specific filename:
wget <shellball base path>/shellball.<device name>.bin
eg for the Acer Chromebook 14 CB3-431 (EDGAR):
wget https://mrchromebox.tech/files/firmware/shellball/shellball.edgar.bin

If you're not sure which file to use for your device / don't know your device's board name, you can reference:
https://mrchromebox.tech/#devices and/or http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices

Special Note/Step for Chromeboxes

Devices which have an Ethernet port usually store the LAN MAC address in the VPD (vital product data) section of the stock firmware. When flashing via the Firmware Utility Script, the script will automatically extract and repackage this in a way the UEFI firmware can use (in a file called vpd.bin), so the LAN MAC address of the device is maintained. Without this, the device will use a default/generic LAN MAC address set by coreboot. While not ideal, this is only really an issue if two or more of the same device are on the same LAN segment (or you're statically assigning IP addresses based on MAC). But for completeness, if flashing the UEFI firmware or shellball ROM, we'll extract the VPD (either from the board itself or a backup made by the script) and inject it into the firmware to be flashed.

NOTE: you don't need to do this if flashing a stock firmware backup created by the Firmware Utility Script; that image already contains the VPD.


For both the options below, we'll need to use the cbfstool (coreboot filesystem) binary, so let's download/extract that:

wget https://mrchromebox.tech/files/util/cbfstool.tar.gz && tar -zxf cbfstool.tar.gz

Option 1a: extract VPD from Full ROM firmware on device (if bricked when flashing Full ROM firmware)

sudo ./flashrom -p raiden_debug_spi:target=AP -r badflash.rom
./cbfstool badflash.rom extract -n vpd.bin -f vpd.bin

Option 1b: extract VPD from stock firmware on device (if bricked when restoring stock firmware)

sudo ./flashrom -p raiden_debug_spi:target=AP -r badflash.rom
./cbfstool badflash.rom read -r RO_VPD -f vpd.bin

Option 2: extract VPD from stock firmware backup created by Firmware Utility Script (this assumes the file has been copied into working directory)

./cbfstool stock-firmware-<devicename>-<date>.rom read -r RO_VPD -f vpd.bin

Then we inject the VPD into the firmware image to be flashed. If flashing a Full ROM firmware image:

./cbfstool <Full ROM filename> add -n vpd.bin -f vpd.bin -t raw

If flashing a Shellball ROM firmware image:

./cbfstool <Shellball ROM filename> write -r RO_VPD -f vpd.bin

Now the firmware image is ready to be flashed, and will maintain the device's unique LAN MAC address.

Flashing Your Device

Now that everything is prepped, time to flash the device.

  • Flash the firmware:
If flashing your own backup created by the Firmware Utility Script (or any backup made from a live system), use
sudo ./flashrom -p raiden_debug_spi:target=AP -i SI_BIOS -w <filename>
otherwise use
sudo ./flashrom -p raiden_debug_spi:target=AP -w <filename>
Where <filename> is the name of your backup file, UEFI firmware file, or shellball firmware file. This will usually take 3-5 mins to complete; flashrom will first read the flash chip, determine which sectors differ, erase those sectors, write the new data, then verify the data written. The initial CCD setup make take a minute or so and not show any progress.

Clean Up

Once flashing is complete, disconnect the Suzy-Q cable. If the internal battery was not disconnected, the device will likely reboot as soon as flashing has completed. If the internal battery was disconnected, reconnect it and replace the bottom cover. Flip over the device, connect external power, press the power button, and cross your fingers :)