doc/ccd: rename doc from _cr50 to _gsc suffix

Add a redirect link from original _cr50 to _gsc page to catch any
external links that point to the old location until they are
all updated.

BUG=b:275544927
TEST=none

Change-Id: Ic77ed3600464ed3cc28f31ac19e3630668ac2a32
Signed-off-by: Jett Rink <jettrink@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4470848
Commit-Queue: Jett Rink <jettrink@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Tested-by: Jett Rink <jettrink@chromium.org>

7 files changed, 776 insertions, 772 deletions

diff --git a/docs/case_closed_debugging.md b/docs/case_closed_debugging.md
index 693d1082e1..5fc9708512 100644
--- a/docs/case_closed_debugging.md
+++ b/docs/case_closed_debugging.md
@@ -221,6 +221,6 @@ See the [`SERVO_PID_DEFAULTS`] in the servo code for all values.
 [`servo_v4`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md
 [`servo_v2`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v2.md
 [`servo_micro`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_micro.md
-[Cr50 CCD]: ./case_closed_debugging_cr50.md
+[Cr50 CCD]: ./case_closed_debugging_gsc.md
 [Suzy-Q]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/ccd.md#suzyq-suzyqable
 [`SERVO_PID_DEFAULTS`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/ff8e96686ef3d9ad2e26125ca8268cb7f7666f6c/servo/interface/ftdi_common.py#28
diff --git a/docs/case_closed_debugging_cr50.md b/docs/case_closed_debugging_cr50.md
index 22f40209b8..231bfc6979 100644
--- a/docs/case_closed_debugging_cr50.md
+++ b/docs/case_closed_debugging_cr50.md
@@ -1,760 +1,4 @@
-# Google Security Chip (GSC) Case Closed Debugging (CCD)
+This page has [moved](./case_closed_debugging_gsc.md).
 
-Cr50 or Ti50 is the firmware that runs on the Google Security Chip (GSC), which
-has support for [Case Closed Debugging](CCD).
-
-This document explains how to setup CCD, so you can access all of the necessary
-features to develop firmware on your Chrome OS device, access
-[debug consoles][consoles], and [disable hardware write protect][hw-wp].
-
-[TOC]
-
-## Overview
-
-GSC CCD was designed to restrict CCD access to device owners and is implemented
-through **CCD privilege levels** ([`Open`], [`Unlocked`], [`Locked`]) that can
-be used to enable access to different **[CCD capabilities][cap]**. Capability
-settings can be modified to require certain privilege levels to access each
-capability. Device owners can use these settings to customize CCD so that it is
-as open or restricted as they want.
-
-GSC CCD exposes [3 debug consoles][consoles]: AP, EC, and GSC as well as control
-over [Hardware Write Protect][hw-wp]. GSC CCD also allows
-[flashing the AP firmware] or [flashing the EC firmware].
-
-### Capability and Privilege Levels {#cap-priv}
-
-Privilege Levels |
----------------- |
-`Open`           |
-`Unlocked`       |
-`Locked`         |
-
-Capability Setting | Definition
------------------- | ----------
-`IfOpened`         | Specified capability is allowed if GSC Privilege Level is `Open`.
-`UnlessLocked`     | Specified capability is allowed unless GSC Privilege Level is `Locked`.
-`Always`           | Specified capability is always allowed, regardless of GSC Privilege Level.
-
-Capability Setting | Privilege Level Required
------------------- | ----------------------------------------
-`IfOpened`         | `Open`
-`UnlessLocked`     | `Open` or `Unlocked`
-`Always`           | `Open`, `Unlocked`, `Locked` (any state)
-
-## CCD Capabilities {#cap}
-
-The default GSC privilege level is [`Locked`] with the following capability
-settings:
-
-Capability        | Default    | Function
------------------ | ---------- | --------
-`UartGscRxAPTx`   | `Always`   | AP console read access
-`UartGscTxAPRx`   | `Always`   | AP console write access
-`UartGscRxECTx`   | `Always`   | EC console read access
-`UartGscTxECRx`   | `IfOpened` | EC console write access
-[`FlashAP`]       | `IfOpened` | Allows flashing the AP
-[`FlashEC`]       | `IfOpened` | Allows flashing the EC
-[`OverrideWP`]    | `IfOpened` | Override hardware write protect
-`RebootECAP`      | `IfOpened` | Allow rebooting the EC/AP from the GSC console
-`GscFullConsole`  | `IfOpened` | Allow access to restricted GSC console commands
-`UnlockNoReboot`  | `Always`   | Allow unlocking GSC without rebooting the AP
-`UnlockNoShortPP` | `Always`   | Allow unlocking GSC without physical presence
-`OpenNoTPMWipe`   | `IfOpened` | Allow opening GSC without wiping the TPM
-`OpenNoLongPP`    | `IfOpened` | Allow opening GSC without physical presence
-`BatteryBypassPP` | `Always`   | Allow opening GSC without physical presence and developer mode if the battery is removed
-`Unused`          | `Always`   | Doesn't do anything
-`I2C`             | `IfOpened` | Allow access to the I2C controller (used for measuring power)
-`FlashRead`       | `Always`   | Allow dumping a hash of the AP or EC flash
-`OpenNoDevMode`   | `IfOpened` | Allow opening GSC without developer mode
-`OpenFromUSB`     | `IfOpened` | Allow opening GSC from USB
-
-## Consoles {#consoles}
-
-GSC presents 3 consoles through CCD: AP, EC, and GSC, each of which show up on
-your host machine as a `/dev/ttyUSBX` device when a debug cable ([Suzy-Q] or
-[Type-C Servo v4]) is plugged in to the DUT.
-
-Console | Default access                              | Capability Name
-------- | ------------------------------------------- | ---------------
-GSC     | always read/write, but commands are limited | `GscFullConsole` enables the full set of GSC console commands
-AP      | read/write                                  | `UartGscRxAPTx` / `UartGscTxAPRx`
-EC      | read-only                                   | `UartGscRxECTx` / `UartGscTxECRx`
-
-### Connecting to a Console
-
-When a debug cable ([Suzy-Q] or [Type-C Servo v4]) is plugged in to the DUT, the
-3 consoles will show up as `/dev/ttyUSBX` devices. You can connect to them with
-your favorite terminal program (e.g., `minicom`, `screen`, etc). You can also
-use the [`usb_console`] command to connect to Cr50 (`18d1:5014`) or Ti50
-(`18d1:504a`) and specify the interface to choose between the consoles.
-
-```bash
-# Install `usb_console`
-(chroot) sudo emerge ec-devutils
-```
-
-```bash
-# Connect to Cr50 (GSC) console
-(chroot) $ sudo usb_console -d 18d1:5014
-# Connect to Ti50 (GSC) console
-(chroot) $ sudo usb_console -d 18d1:504a
-```
-
-```bash
-# Connect to AP console (on Cr50-based device)
-(chroot) $ sudo usb_console -d 18d1:5014 -i 1
-# Connect to AP console (on Ti50-based device)
-(chroot) $ sudo usb_console -d 18d1:504a -i 1
-```
-
-```bash
-# Connect to EC console (on Cr50-based device)
-(chroot) $ sudo usb_console -d 18d1:5014 -i 2
-# Connect to EC console (on Ti50-based device)
-(chroot) $ sudo usb_console -d 18d1:504a -i 2
-```
-
-#### Using "servod" to access the console
-
-[`servod`] can be used to create alternative console devices when combined with
-a [Servo].
-
-First, make sure your [servo firmware is updated][update servo v4].
-
-Next, start [`servod`]:
-
-```bash
-(chroot) $ sudo servod -b $BOARD
-```
-
-Then use `dut-control` to display the console devices:
-
-```bash
-(chroot) $ dut-control gsc_uart_pty ec_uart_pty cpu_uart_pty
-```
-
-Connect to the console devices with your favorite terminal program (e.g.,
-`minicom`, `screen`, etc.).
-
-## CCD Open {#ccd-open}
-
-Some basic CCD functionality is accessible by default: read-only access to the
-EC console, read-write access to the AP console, and a few basic GSC console
-commands. Note that while GSC has read-write access to the AP console by
-default, the AP console itself is disabled for production devices.
-
-In order to access all CCD functionality or to modify capability settings, GSC
-CCD needs to be [`Open`].
-
-1.  Connect to the GSC console by connecting a [Suzy-Q] or [Type-C Servo v4] to
-    the DUT and running one of the following commands:
-
-    ```bash
-    # Connect to Cr50 (GSC) console
-    (chroot) $ sudo usb_console -d 18d1:5014
-    # Connect to Ti50 (GSC) console
-    (chroot) $ sudo usb_console -d 18d1:504a
-    ```
-
-    *** note
-    **NOTE**: If another program is already connected to the GSC console,
-    you'll see `tx [Errno 16] Resource Busy`. For example, this will happen if
-    [`servod`] is running.
-    ***
-
-1.  At the GSC console, use the `version` command to make sure you have a recent
-    enough version to use CCD. The relevant version is either `RW_A` or `RW_B`,
-    whichever has the asterisk next to it:
-
-    ```
-    cr50 > version
-
-    Chip:    g cr50 B2-C
-    Board:   0
-    RO_A:  * 0.0.10/29d77172
-    RO_B:    0.0.10/c2a3f8f9
-    RW_A:  * 0.3.23/cr50_v1.9308_87_mp.320-aa1dd98  <---- This is the version
-    RW_B:    0.3.18/cr50_v1.9308_87_mp.236-8052858
-    BID A:   00000000:00000000:00000000 Yes
-    BID B:   00000000:00000000:00000000 Yes
-    Build:   0.3.23/cr50_v1.9308_87_mp.320-aa1dd98
-             tpm2:v1.9308_26_0.36-d1631ea
-             cryptoc:v1.9308_26_0.2-a4a45f5
-             2019-10-14 19:18:05 @chromeos-ci-legacy-us-central2
-    ```
-
-1.  Production (`MP`) versions of Cr50 firmware use a [minor version][semver] of
-    `3`: `0.3.x`. Production firmware versions `0.3.9` or newer support CCD.
-
-    Production (`MP`) versions of Ti50 firmware use a [minor version][semver] of
-    `23`: `0.23.x`.
-
-    Development (`PrePVT`) versions of Cr50 firmware use a minor version of `4`:
-    `0.4.x`. Development firmware versions `0.4.9` or newer support CCD.
-
-    Development (`PrePVT`) versions of Ti50 firmware use a minor version of
-    `24`: `0.24.x`.
-
-    Your device likely supports CCD if it was manufactured in the last few
-    years. If you have an older version, follow the [Updating Cr50] instructions
-    before continuing.
-
-1.  Put the device into [Recovery Mode] and enable [Developer Mode].
-
-    *** note
-    **NOTE**: Developer Mode has to be enabled as described. Using GBB flags to
-    force Developer Mode will not work.
-    ***
-
-    If you can't put your device into [Developer Mode] because it doesn't boot,
-    follow the [CCD Open Without Booting the Device] instructions.
-
-1.  Verify GSC knows the device is in [Developer Mode] by finding `TPM:
-    dev_mode` in the GSC console `ccd` command output:
-
-    ```
-    (gsc) > ccd
-          ...
-          TPM: dev_mode                     <==== This is the important part
-          ...
-    ```
-
-1.  Start the CCD open process from the AP.
-
-    ```bash
-    (dut) $ gsctool -a -o
-    ```
-
-1.  Over the next 5 minutes you will be prompted to press the power button
-    multiple times. After the last power button press the device will reboot.
-
-    *** note
-    **WARNING**: Opening CCD causes GSC to forget that it is in
-    [Developer Mode], so when the device reboots, it will either say that
-    the OS image is invalid or it will enter a bootloop. Use the key
-    combinations to enter [Recovery Mode] and re-enable [Developer Mode].
-    See [this bug] for details.
-    ***
-
-1.  Use the `ccd` command on the GSC console to verify the state is [`Open`]:
-
-    ```
-    (gsc) > ccd
-
-    State: Opened
-    ...
-    ```
-
-1.  **The [`Open`] state is lost if GSC reboots, the device loses power (e.g.,
-    battery runs out and AC is not plugged in), or the battery is removed. Note
-    that GSC 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:
-
-    ```
-    (gsc) > ccd reset factory
-    ```
-
-    ```
-    (gsc) > ccd testlab enable
-    ```
-
-    For full details, see the section on [CCD Open Without Booting the Device].
-
-## Configuring CCD Capability Settings
-
-CCD capabilities allow you to configure CCD to restrict or open the device as
-much as you want. You can use the `ccd` command on the GSC console to check and
-modify the capabilities, but CCD has to be [`Open`] to change the capabilities.
-
-Setting capabilities you want to use to [`Always`] will make them accessible
-even if CCD loses the [`Open`] state, which happens when GSC reboots or the
-device loses power.
-
-Basic CCD functionality is covered by `UartGscTxECRx`, `UartGscRxECTx`,
-`UartGscTxAPRx`, `UartGscRxAPTx`, [`FlashAP`], [`FlashEC`], [`OverrideWP`], and
-`GscFullConsole`.
-
-```
-(gsc) > ccd set $CAPABILITY $REQUIREMENT
-```
-
-### Examples
-
-#### EC Console
-
-If the EC console needs to be read-write even when CCD is [`Locked`] set the
-capability to [`Always`]:
-
-```
-(gsc) > ccd set UartGscTxECRx Always
-```
-
-#### Restrict Consoles
-
-If you want to restrict capabilities more than [`Always`], you can set them to
-[`IfOpened`], which will make it so that it is only accessible when CCD is
-[`Open`]ed, not [`Lock`]ed:
-
-##### Restrict EC
-
-```
-(gsc) > ccd set UartGscTxECRx IfOpened
-(gsc) > ccd set UartGscRxECTx IfOpened
-```
-
-##### Restrict AP
-
-```
-(gsc) > ccd set UartGscTxAPRx IfOpened
-(gsc) > ccd set UartGscRxAPTx IfOpened
-```
-
-#### Most Accessible
-
-If you want things as accessible as possible and want all capabilities to be
-[`Always`], you can run
-
-```
-(gsc) > ccd reset factory
-```
-
-This will also permanently disable write protect. To reset write protect run
-
-```
-(gsc) > wp follow_batt_pres atboot
-```
-
-To reset capabilities to Default run
-
-```
-(gsc) > ccd reset
-```
-
-## Flashing EC {#flashec}
-
-Flashing the EC is restricted by the `FlashEC` capability.
-
-The steps to flash the EC differ based on the board being used, but the
-[`flash_ec`] script will handle this for you.
-
-```bash
-(chroot) $ sudo servod -b $BOARD
-(chroot) $ ~/trunk/src/platform/ec/util/flash_ec --image $IMAGE --board $BOARD
-```
-
-## Flashing the AP {#flashap}
-
-*** note
-**WARNING**: Before attempting to flash the AP firmware, start with the
-[CCD Open] steps; if you flash broken firmware before opening CCD, you may make
-it impossible to restore your device to a working state.
-***
-
-Flashing the AP is restricted by the `FlashAP` capability.
-
-```bash
-(chroot) $ sudo flashrom -p raiden_debug_spi:target=AP -w $IMAGE
-```
-
-This default flashing command takes a very long time to complete, there are ways
-to [speed up the flashing process] by cutting some corners.
-
-If you have many CCD devices connected, you may want to use the GSC serial
-number:
-
-```bash
-# For Cr50-based device
-(chroot) $ lsusb -vd 18d1:5014 | grep iSerial
-# For Tir50-based device
-(chroot) $ lsusb -vd 18d1:504a | grep iSerial
-```
-
-You can then add the serial number to the [`flashrom`] command:
-
-```bash
-(chroot) $ sudo flashrom -p raiden_debug_spi:target=AP,serial=$SERIAL -w $IMAGE
-```
-
-**If you don't see GSC print any messages when you're running the [`flashrom`]
-command and you have more than one GSC device connected to your workstation, you
-probably need to use the serial number.**
-
-### Special Cases {#flashap-special-cases}
-
-GSC puts the device in reset to flash the AP. Due to hardware limitations GSC
-may not be able to disable hardware write protect while the device is in reset.
-If you want to reflash the AP RO firmware using CCD and your board has issues
-disabling hardware write protect, you may need to also disable software write
-protect.
-
-To determine if the board you are using has this issue:
-
-1.  Disable write protect using the GSC console command:
-
-    ```
-    (gsc) > wp disable
-    ```
-
-1.  Check if hardware write protect disabled when the AP is off:
-
-    ```bash
-    (chroot) $ sudo flashrom -p raiden_debug_spi:target=AP --wp-status
-    ```
-
-1.  If the last command shows that hardware write protect is still enabled when
-    the AP is off, then you need to disable software write protect:
-
-    ```bash
-    (chroot) $ flashrom -p host --wp-disable
-    ```
-
-## Control Hardware Write Protect {#hw-wp}
-
-Control of hardware write protect is restricted by the `OverrideWP` capability.
-When the capability is allowed, the hardware write protect setting can be
-controlled with the `wp` command in the GSC console. Otherwise, the hardware
-write protect is determined based on the presence of the battery.
-
-Hardware Write Protect Setting | Battery State                  | Hardware Write Protect State
------------------------------- | ------------------------------ | ----------------------------
-`follow_batt_pres`             | Connected                      | Enabled
-`follow_batt_pres`             | Disconnected                   | Disabled
-`follow_batt_pres`             | N/A (Chromebox has no battery) | Write Protect Screw means Enabled
-`enabled`                      | Any                            | Enabled
-`disabled`                     | Any                            | Disabled
-
-### Write Protect Commands
-
-```
-(gsc) > wp [enable|disable|follow_batt_pres]
-```
-
-There are two write protect settings: the current setting and the `atboot`
-setting.
-
-The `wp` command adjusts the current write protect setting that will last until
-GSC reboots or loses power. Note that GSC does not reboot when the rest of the
-system reboots. It will only reboot in the cases where the firmware is being
-updated, it crashes, the battery completely drains, the battery is removed, or
-power is otherwise lost.
-
-The `atboot` setting is the state of the write protect when GSC boots; it
-defaults to `follow_batt_pres`.
-
-To change the `atboot` setting, add the `atboot` arg to the end of the `wp`
-command:
-
-```
-(gsc) > wp [enable|disable|follow_batt_pres] atboot
-```
-
-You can query the write protect state with `gsctool`:
-
-```bash
-(dut) $ gsctool -a -w
-
-...
-Flash WP: forced disabled  <-- Current hardware write protect state
- at boot: forced disabled  <-- "atboot" hardware write protect state
-
-```
-
-`gsctool -a -w` Status | Hardware Write Protect State
----------------------- | ------------------------------------
-`forced disabled`      | Disabled
-`forced enabled`       | Enabled
-`enabled`              | Enabled, following battery presence
-`disabled`             | Disabled, following battery presence
-
-### Special Case Devices
-
-Bob devices have a write protect screw in addition to battery presence. The
-write protect screw will force enable write protect until it's removed. If GSC
-is set to `follow_batt_pres`, you need to remove the write protect screw and
-disconnect the battery to disable write protect. If you run `wp disable`, you
-will also need to remove the screw.
-
-If you are attempting to flash the AP, see the [Flashing the AP Special Cases]
-section for additional steps you may have to take to disable write protection.
-
-## UART Rescue mode
-
-### Overview
-
-UART Rescue Mode is a feature of the GSC RO firmware that supports programming
-the RW firmware using only the UART interface. This is used to recover a bad RW
-firmware update (which should be rare).
-
-This is also useful when bringing up new designs, as this allows to update GSC
-image even before USB CCD or TPM interfaces are operational.
-
-UART rescue works on all existing devices, all it requires is that GSC console
-is mapped to a `/dev/xxx` device on the workstation (the same device used to
-attach a terminal to the console).
-
-Rescue works as follows: when the RO starts, after printing the regular banner
-on the console it prints a magic string to the console and momentarily waits for
-the host to send a sync symbol, to indicate that an alternative RW will have to
-be loaded over UART. The RO also enters this mode if there is no valid RW to
-run.
-
-When rescue mode is triggered, the RO is expecting the host to transfer a single
-RW image in hex format.
-
-Follow the [brescue](./gsc_without_servod.md#gsc-rescue) procedure to perform a
-GSC rescue.
-
-## CCD Open Without Booting the Device {#ccd-open-no-boot}
-
-If you can’t boot your device, you won’t be able to enable [Developer Mode] to
-send the open command from the AP. If you have enabled CCD on the device before,
-GSC may be configured in a way that you can still open GSC.
-
-### Option 1: Remove the battery
-
-If you can remove the battery, you can bypass the [Developer Mode] requirements.
-`ccd open` is allowed from the GSC console if the Chrome OS Firmware Management
-Parameters (`FWMP`) do not disable CCD and the battery is disconnected. This is
-the most universal method and will work even if you haven’t enabled CCD before.
-
-1.  Disconnect the battery
-
-1.  Send `ccd open` from the GSC console.
-
-### Option 2: "OpenNoDevMode" and "OpenFromUSB" are set to Always
-
-If "OpenNoDevMode" and "OpenFromUSB" are set to Always, you will be able to open
-GSC from the GSC console without enabling [Developer Mode]:
-
-```
-(gsc) > ccd open
-```
-
-You will still need physical presence (i.e., press the power button) unless
-`testlab` mode is also enabled:
-
-```
-(gsc) > ccd testlab
-       CCD test lab mode enabled
-```
-
-#### Enabling
-
-If CCD is [`Open`], you can enable these settings with:
-
-```
-(gsc) > ccd set OpenFromUSB Always
-(gsc) > ccd set OpenNoDevMode Always
-```
-
-### Option 3: CCD Password is Set
-
-If the CCD password is set, you can open from the GSC console without
-[Developer Mode].
-
-```
-(gsc) > ccd open $PASSWORD
-(gsc) > ccd unlock $PASSWORD
-```
-
-Alternatively, you can use `gsctool`, entering the password when prompted:
-
-```
-(dut) $ gsctool -a -o
-(dut) $ gsctool -a -u
-```
-
-#### Enabling
-
-When CCD is [`Open`], run the `gsctool` command and enter the password when
-prompted.
-
-```bash
-(chroot) $ gsctool -a -P
-```
-
-You can use the CCD command on the GSC console to check if the password is set.
-
-```
-(gsc) > ccd
-       ...
-       Password: [none|set]
-       ...
-```
-
-#### Disabling
-
-When CCD is [`Open`], you can use `gsctool` to clear the password:
-
-```bash
-(dut) $ gsctool -a -P clear:$PASSWORD
-```
-
-Alternatively, you can use the GSC console to clear the password and reset CCD
-capabilities to their default values:
-
-```
-(gsc) > ccd reset
-```
-
-## Troubleshooting
-
-### rddkeepalive
-
-GSC only enables CCD when it detects a debug accessory is connected (e.g.,
-[Suzy-Q] or [Type-C Servo v4]). It detects the cable based on the voltages on
-the CC lines. If you are flashing the EC and AP or working with unstable
-hardware, these CC voltages may become unreliable for detecting a debug
-accessory.
-
-To work around this, you can force GSC to always assume that a debug cable is
-detected:
-
-```
-(gsc) > rddkeepalive enable
-```
-
-*** note
-**NOTE**: Enabling `rddkeepalive` does increase power consumption.
-***
-
-To disable:
-
-```
-(gsc) > rddkeepalive disable
-```
-
-### Updating GSC {#updating-cr50}
-
-Production (`MP`) versions of Cr50 firmware use a [minor version][semver] of
-`3`: `0.3.x`. Production firmware versions `0.3.9` or newer support CCD.
-
-Production (`MP`) versions of Ti50 firmware use a [minor version][semver] of
-`23`: `0.23.x`.
-
-Development (`PrePVT`) versions of Cr50 firmware use a minor version of `4`:
-`0.4.x`. Development firmware versions `0.4.9` or newer support CCD.
-
-Development (`PrePVT`) versions of Ti50 firmware use a minor version of `24`:
-`0.24.x`.
-
-There aren't many differences between the MP and PrePVT versions of images, but
-it is a little easier to CCD [`Open`] PrePVT images. You can't run PrePVT images
-on MP devices, so if you're trying to update to PrePVT and it fails try using
-the MP image.
-
-1.  Flash a test image newer than M66.
-
-1.  Enable [Developer Mode] and connect a debug cable ([`Suzy-Q`] or [`Type-C
-    Servo v4`]).
-
-1.  Check the running GSC version with `gsctool`:
-
-```bash
-(dut) $ sudo gsctool -a -f
-
-...
-RW 0.4.26  <-- The "RW" version is the one to check
-```
-
-1.  Update GSC using the firmware in the OS image:
-
-*Production (MP) image*:
-
-```bash
-(dut) $ sudo gsctool -a /opt/google/cr50/firmware/cr50.bin.prod
-(dut) $ sudo gsctool -a /opt/google/ti50/firmware/ti50.bin.prod
-```
-
-*Development (PrePVT) image*:
-
-```bash
-(dut) $ sudo gsctool -a /opt/google/cr50/firmware/cr50.bin.prepvt
-(dut) $ sudo gsctool -a /opt/google/ti50/firmware/ti50.bin.prepvt
-```
-
-1.  Check the GSC version again to make sure it's either `0.3.X` or `0.4.X`, or
-    check the Ti50 version again to make sure it's either `0.23.X` or `0.24.X`.
-
-### Speed up Flashing the AP {#speed-up-ap-flash}
-
-In the [default AP flashing steps][flashap] [`flashrom`] reads the entire flash
-contents and only erases and programs the pages that have to be modified.
-However, when GSC controls the SPI bus, it can only run at 1.5 MHz, versus the
-50 MHz that the AP normally runs it at.
-
-We can take advantage of the fact that Chrome OS device AP firmware is split
-into sections, only a few of which are essential for maintaining the device
-identity and for booting the device in recovery mode to program faster by only
-reading and writing sections we care about:
-
-```bash
-# This will save device flash map and VPD sections in
-# /tmp/bios.essentials.bin. VPD sections contain information like device
-# firmware ID, WiFi calibration, enrollment status, etc. Use the below command
-# only if you need to preserve the DUT's identity, no need to run it in case
-# the DUT flash is not programmed at all, or you do not care about preserving
-# the device identity.
-sudo flashrom -p raiden_debug_spi:target=AP -i FMAP -i RO_VPD -i RW_VPD -r /tmp/bios.essentials.bin
-
-# This command will erase the entire flash chip in one shot, the fastest
-# possible way to erase.
-sudo flashrom -p raiden_debug_spi:target=AP -E
-
-# This command will program essential flash sections necessary for the
-# Chrome OS device to boot in recovery mode. Note that the SI_ALL section is
-# not always present in the flash image, do not include it if it is not in
-# dump_fmap output.
-sudo flashrom -p raiden_debug_spi:target=AP -w image-atlas.bin -i FMAP -i WP_RO [-i SI_ALL] --noverify
-
-# This command will restore the previously preserved VPD sections of the
-# flash, provided it was saved in the first step above.
-sudo flashrom -p raiden_debug_spi:target=AP -w /tmp/bios.essentials.bin -i RO_VPD -i RW_VPD --noverify
-```
-
-Once flash is programmed, the device can be booted in recovery mode and start
-Chrome OS from external storage, following the usual recovery procedure. Once
-Chrome OS is installed, AP flash can be updated to include the rest of the image
-by running [`flashrom`] or `futility` from the device bash prompt.
-
-[Case Closed Debugging]: ./case_closed_debugging.md
-[chromeos-cr50 ebuild]: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/chromeos-base/chromeos-cr50/chromeos-cr50-0.0.1.ebuild
-[chromeos-ti50 ebuild]: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/chromeos-base/chromeos-ti50/chromeos-ti50-0.0.1.ebuild
-[Developer Mode]: https://chromium.googlesource.com/chromiumos/docs/+/main/developer_mode.md#dev-mode
-[Recovery Mode]: https://chromium.googlesource.com/chromiumos/docs/+/main/debug_buttons.md
-[Servo]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo.md
-[`servod`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo.md
-[Type-C Servo v4]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md
-[update servo v4]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md#updating-firmware
-[Suzy-Q]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/ccd.md#SuzyQ-SuzyQable
-[`hdctools`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/refs/heads/main/README.md
-[`FlashAP`]: #flashap
-[flashing the AP firmware]: #flashap
-[flashap]: #flashap
-[Flashing the AP Special Cases]: #flashap-special-cases
-[`FlashEC`]: #flashec
-[flashing the EC firmware]: #flashec
-[`OverrideWP`]: #hw-wp
-[`Always`]: #cap-priv
-[`IfOpened`]: #cap-priv
-[`Open`]: #cap-priv
-[`Locked`]: #cap-priv
-[`Unlocked`]: #cap-priv
-[Updating Cr50]: #updating-cr50
-[CCD Open Without Booting the Device]: #ccd-open-no-boot
-[cap]: #cap
-[consoles]: #consoles
-[hw-wp]: #hw-wp
-[`flash_ec`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/main/util/flash_ec
-[CCD Open]: #ccd-open
-[`flashrom`]: https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/main/README.chromiumos
-[speed up the flashing process]: #speed-up-ap-flash
-[this bug]: https://issuetracker.google.com/149420712
-[semver]: https://semver.org/
-[`usb_console`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/main/extra/usb_serial/console.py
+# Remove this page when there are no reference to this page location in
+# code search
diff --git a/docs/case_closed_debugging_gsc.md b/docs/case_closed_debugging_gsc.md
new file mode 100644
index 0000000000..234b92289e
--- /dev/null
+++ b/docs/case_closed_debugging_gsc.md
@@ -0,0 +1,760 @@
+# Google Security Chip (GSC) Case Closed Debugging (CCD)
+
+Cr50 or Ti50 is the firmware that runs on the Google Security Chip (GSC), which
+has support for [Case Closed Debugging](CCD).
+
+This document explains how to setup CCD, so you can access all of the necessary
+features to develop firmware on your Chrome OS device, access
+[debug consoles][consoles], and [disable hardware write protect][hw-wp].
+
+[TOC]
+
+## Overview
+
+GSC CCD was designed to restrict CCD access to device owners and is implemented
+through **CCD privilege levels** ([`Open`], [`Unlocked`], [`Locked`]) that can
+be used to enable access to different **[CCD capabilities][cap]**. Capability
+settings can be modified to require certain privilege levels to access each
+capability. Device owners can use these settings to customize CCD so that it is
+as open or restricted as they want.
+
+GSC CCD exposes [3 debug consoles][consoles]: AP, EC, and GSC as well as control
+over [Hardware Write Protect][hw-wp]. GSC CCD also allows
+[flashing the AP firmware] or [flashing the EC firmware].
+
+### Capability and Privilege Levels {#cap-priv}
+
+Privilege Levels |
+---------------- |
+`Open`           |
+`Unlocked`       |
+`Locked`         |
+
+Capability Setting | Definition
+------------------ | ----------
+`IfOpened`         | Specified capability is allowed if GSC Privilege Level is `Open`.
+`UnlessLocked`     | Specified capability is allowed unless GSC Privilege Level is `Locked`.
+`Always`           | Specified capability is always allowed, regardless of GSC Privilege Level.
+
+Capability Setting | Privilege Level Required
+------------------ | ----------------------------------------
+`IfOpened`         | `Open`
+`UnlessLocked`     | `Open` or `Unlocked`
+`Always`           | `Open`, `Unlocked`, `Locked` (any state)
+
+## CCD Capabilities {#cap}
+
+The default GSC privilege level is [`Locked`] with the following capability
+settings:
+
+Capability        | Default    | Function
+----------------- | ---------- | --------
+`UartGscRxAPTx`   | `Always`   | AP console read access
+`UartGscTxAPRx`   | `Always`   | AP console write access
+`UartGscRxECTx`   | `Always`   | EC console read access
+`UartGscTxECRx`   | `IfOpened` | EC console write access
+[`FlashAP`]       | `IfOpened` | Allows flashing the AP
+[`FlashEC`]       | `IfOpened` | Allows flashing the EC
+[`OverrideWP`]    | `IfOpened` | Override hardware write protect
+`RebootECAP`      | `IfOpened` | Allow rebooting the EC/AP from the GSC console
+`GscFullConsole`  | `IfOpened` | Allow access to restricted GSC console commands
+`UnlockNoReboot`  | `Always`   | Allow unlocking GSC without rebooting the AP
+`UnlockNoShortPP` | `Always`   | Allow unlocking GSC without physical presence
+`OpenNoTPMWipe`   | `IfOpened` | Allow opening GSC without wiping the TPM
+`OpenNoLongPP`    | `IfOpened` | Allow opening GSC without physical presence
+`BatteryBypassPP` | `Always`   | Allow opening GSC without physical presence and developer mode if the battery is removed
+`Unused`          | `Always`   | Doesn't do anything
+`I2C`             | `IfOpened` | Allow access to the I2C controller (used for measuring power)
+`FlashRead`       | `Always`   | Allow dumping a hash of the AP or EC flash
+`OpenNoDevMode`   | `IfOpened` | Allow opening GSC without developer mode
+`OpenFromUSB`     | `IfOpened` | Allow opening GSC from USB
+
+## Consoles {#consoles}
+
+GSC presents 3 consoles through CCD: AP, EC, and GSC, each of which show up on
+your host machine as a `/dev/ttyUSBX` device when a debug cable ([Suzy-Q] or
+[Type-C Servo v4]) is plugged in to the DUT.
+
+Console | Default access                              | Capability Name
+------- | ------------------------------------------- | ---------------
+GSC     | always read/write, but commands are limited | `GscFullConsole` enables the full set of GSC console commands
+AP      | read/write                                  | `UartGscRxAPTx` / `UartGscTxAPRx`
+EC      | read-only                                   | `UartGscRxECTx` / `UartGscTxECRx`
+
+### Connecting to a Console
+
+When a debug cable ([Suzy-Q] or [Type-C Servo v4]) is plugged in to the DUT, the
+3 consoles will show up as `/dev/ttyUSBX` devices. You can connect to them with
+your favorite terminal program (e.g., `minicom`, `screen`, etc). You can also
+use the [`usb_console`] command to connect to Cr50 (`18d1:5014`) or Ti50
+(`18d1:504a`) and specify the interface to choose between the consoles.
+
+```bash
+# Install `usb_console`
+(chroot) sudo emerge ec-devutils
+```
+
+```bash
+# Connect to Cr50 (GSC) console
+(chroot) $ sudo usb_console -d 18d1:5014
+# Connect to Ti50 (GSC) console
+(chroot) $ sudo usb_console -d 18d1:504a
+```
+
+```bash
+# Connect to AP console (on Cr50-based device)
+(chroot) $ sudo usb_console -d 18d1:5014 -i 1
+# Connect to AP console (on Ti50-based device)
+(chroot) $ sudo usb_console -d 18d1:504a -i 1
+```
+
+```bash
+# Connect to EC console (on Cr50-based device)
+(chroot) $ sudo usb_console -d 18d1:5014 -i 2
+# Connect to EC console (on Ti50-based device)
+(chroot) $ sudo usb_console -d 18d1:504a -i 2
+```
+
+#### Using "servod" to access the console
+
+[`servod`] can be used to create alternative console devices when combined with
+a [Servo].
+
+First, make sure your [servo firmware is updated][update servo v4].
+
+Next, start [`servod`]:
+
+```bash
+(chroot) $ sudo servod -b $BOARD
+```
+
+Then use `dut-control` to display the console devices:
+
+```bash
+(chroot) $ dut-control gsc_uart_pty ec_uart_pty cpu_uart_pty
+```
+
+Connect to the console devices with your favorite terminal program (e.g.,
+`minicom`, `screen`, etc.).
+
+## CCD Open {#ccd-open}
+
+Some basic CCD functionality is accessible by default: read-only access to the
+EC console, read-write access to the AP console, and a few basic GSC console
+commands. Note that while GSC has read-write access to the AP console by
+default, the AP console itself is disabled for production devices.
+
+In order to access all CCD functionality or to modify capability settings, GSC
+CCD needs to be [`Open`].
+
+1.  Connect to the GSC console by connecting a [Suzy-Q] or [Type-C Servo v4] to
+    the DUT and running one of the following commands:
+
+    ```bash
+    # Connect to Cr50 (GSC) console
+    (chroot) $ sudo usb_console -d 18d1:5014
+    # Connect to Ti50 (GSC) console
+    (chroot) $ sudo usb_console -d 18d1:504a
+    ```
+
+    *** note
+    **NOTE**: If another program is already connected to the GSC console,
+    you'll see `tx [Errno 16] Resource Busy`. For example, this will happen if
+    [`servod`] is running.
+    ***
+
+1.  At the GSC console, use the `version` command to make sure you have a recent
+    enough version to use CCD. The relevant version is either `RW_A` or `RW_B`,
+    whichever has the asterisk next to it:
+
+    ```
+    cr50 > version
+
+    Chip:    g cr50 B2-C
+    Board:   0
+    RO_A:  * 0.0.10/29d77172
+    RO_B:    0.0.10/c2a3f8f9
+    RW_A:  * 0.3.23/cr50_v1.9308_87_mp.320-aa1dd98  <---- This is the version
+    RW_B:    0.3.18/cr50_v1.9308_87_mp.236-8052858
+    BID A:   00000000:00000000:00000000 Yes
+    BID B:   00000000:00000000:00000000 Yes
+    Build:   0.3.23/cr50_v1.9308_87_mp.320-aa1dd98
+             tpm2:v1.9308_26_0.36-d1631ea
+             cryptoc:v1.9308_26_0.2-a4a45f5
+             2019-10-14 19:18:05 @chromeos-ci-legacy-us-central2
+    ```
+
+1.  Production (`MP`) versions of Cr50 firmware use a [minor version][semver] of
+    `3`: `0.3.x`. Production firmware versions `0.3.9` or newer support CCD.
+
+    Production (`MP`) versions of Ti50 firmware use a [minor version][semver] of
+    `23`: `0.23.x`.
+
+    Development (`PrePVT`) versions of Cr50 firmware use a minor version of `4`:
+    `0.4.x`. Development firmware versions `0.4.9` or newer support CCD.
+
+    Development (`PrePVT`) versions of Ti50 firmware use a minor version of
+    `24`: `0.24.x`.
+
+    Your device likely supports CCD if it was manufactured in the last few
+    years. If you have an older version, follow the [Updating Cr50] instructions
+    before continuing.
+
+1.  Put the device into [Recovery Mode] and enable [Developer Mode].
+
+    *** note
+    **NOTE**: Developer Mode has to be enabled as described. Using GBB flags to
+    force Developer Mode will not work.
+    ***
+
+    If you can't put your device into [Developer Mode] because it doesn't boot,
+    follow the [CCD Open Without Booting the Device] instructions.
+
+1.  Verify GSC knows the device is in [Developer Mode] by finding `TPM:
+    dev_mode` in the GSC console `ccd` command output:
+
+    ```
+    (gsc) > ccd
+          ...
+          TPM: dev_mode                     <==== This is the important part
+          ...
+    ```
+
+1.  Start the CCD open process from the AP.
+
+    ```bash
+    (dut) $ gsctool -a -o
+    ```
+
+1.  Over the next 5 minutes you will be prompted to press the power button
+    multiple times. After the last power button press the device will reboot.
+
+    *** note
+    **WARNING**: Opening CCD causes GSC to forget that it is in
+    [Developer Mode], so when the device reboots, it will either say that
+    the OS image is invalid or it will enter a bootloop. Use the key
+    combinations to enter [Recovery Mode] and re-enable [Developer Mode].
+    See [this bug] for details.
+    ***
+
+1.  Use the `ccd` command on the GSC console to verify the state is [`Open`]:
+
+    ```
+    (gsc) > ccd
+
+    State: Opened
+    ...
+    ```
+
+1.  **The [`Open`] state is lost if GSC reboots, the device loses power (e.g.,
+    battery runs out and AC is not plugged in), or the battery is removed. Note
+    that GSC 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:
+
+    ```
+    (gsc) > ccd reset factory
+    ```
+
+    ```
+    (gsc) > ccd testlab enable
+    ```
+
+    For full details, see the section on [CCD Open Without Booting the Device].
+
+## Configuring CCD Capability Settings
+
+CCD capabilities allow you to configure CCD to restrict or open the device as
+much as you want. You can use the `ccd` command on the GSC console to check and
+modify the capabilities, but CCD has to be [`Open`] to change the capabilities.
+
+Setting capabilities you want to use to [`Always`] will make them accessible
+even if CCD loses the [`Open`] state, which happens when GSC reboots or the
+device loses power.
+
+Basic CCD functionality is covered by `UartGscTxECRx`, `UartGscRxECTx`,
+`UartGscTxAPRx`, `UartGscRxAPTx`, [`FlashAP`], [`FlashEC`], [`OverrideWP`], and
+`GscFullConsole`.
+
+```
+(gsc) > ccd set $CAPABILITY $REQUIREMENT
+```
+
+### Examples
+
+#### EC Console
+
+If the EC console needs to be read-write even when CCD is [`Locked`] set the
+capability to [`Always`]:
+
+```
+(gsc) > ccd set UartGscTxECRx Always
+```
+
+#### Restrict Consoles
+
+If you want to restrict capabilities more than [`Always`], you can set them to
+[`IfOpened`], which will make it so that it is only accessible when CCD is
+[`Open`]ed, not [`Lock`]ed:
+
+##### Restrict EC
+
+```
+(gsc) > ccd set UartGscTxECRx IfOpened
+(gsc) > ccd set UartGscRxECTx IfOpened
+```
+
+##### Restrict AP
+
+```
+(gsc) > ccd set UartGscTxAPRx IfOpened
+(gsc) > ccd set UartGscRxAPTx IfOpened
+```
+
+#### Most Accessible
+
+If you want things as accessible as possible and want all capabilities to be
+[`Always`], you can run
+
+```
+(gsc) > ccd reset factory
+```
+
+This will also permanently disable write protect. To reset write protect run
+
+```
+(gsc) > wp follow_batt_pres atboot
+```
+
+To reset capabilities to Default run
+
+```
+(gsc) > ccd reset
+```
+
+## Flashing EC {#flashec}
+
+Flashing the EC is restricted by the `FlashEC` capability.
+
+The steps to flash the EC differ based on the board being used, but the
+[`flash_ec`] script will handle this for you.
+
+```bash
+(chroot) $ sudo servod -b $BOARD
+(chroot) $ ~/trunk/src/platform/ec/util/flash_ec -i $IMAGE -b $BOARD
+```
+
+## Flashing the AP {#flashap}
+
+*** note
+**WARNING**: Before attempting to flash the AP firmware, start with the
+[CCD Open] steps; if you flash broken firmware before opening CCD, you may make
+it impossible to restore your device to a working state.
+***
+
+Flashing the AP is restricted by the `FlashAP` capability.
+
+```bash
+(chroot) $ sudo flashrom -p raiden_debug_spi:target=AP -w $IMAGE
+```
+
+This default flashing command takes a very long time to complete, there are ways
+to [speed up the flashing process] by cutting some corners.
+
+If you have many CCD devices connected, you may want to use the GSC serial
+number:
+
+```bash
+# For Cr50-based device
+(chroot) $ lsusb -vd 18d1:5014 | grep iSerial
+# For Tir50-based device
+(chroot) $ lsusb -vd 18d1:504a | grep iSerial
+```
+
+You can then add the serial number to the [`flashrom`] command:
+
+```bash
+(chroot) $ sudo flashrom -p raiden_debug_spi:target=AP,serial=$SERIAL -w $IMAGE
+```
+
+**If you don't see GSC print any messages when you're running the [`flashrom`]
+command and you have more than one GSC device connected to your workstation, you
+probably need to use the serial number.**
+
+### Special Cases {#flashap-special-cases}
+
+GSC puts the device in reset to flash the AP. Due to hardware limitations GSC
+may not be able to disable hardware write protect while the device is in reset.
+If you want to reflash the AP RO firmware using CCD and your board has issues
+disabling hardware write protect, you may need to also disable software write
+protect.
+
+To determine if the board you are using has this issue:
+
+1.  Disable write protect using the GSC console command:
+
+    ```
+    (gsc) > wp disable
+    ```
+
+1.  Check if hardware write protect disabled when the AP is off:
+
+    ```bash
+    (chroot) $ sudo flashrom -p raiden_debug_spi:target=AP --wp-status
+    ```
+
+1.  If the last command shows that hardware write protect is still enabled when
+    the AP is off, then you need to disable software write protect:
+
+    ```bash
+    (chroot) $ flashrom -p host --wp-disable
+    ```
+
+## Control Hardware Write Protect {#hw-wp}
+
+Control of hardware write protect is restricted by the `OverrideWP` capability.
+When the capability is allowed, the hardware write protect setting can be
+controlled with the `wp` command in the GSC console. Otherwise, the hardware
+write protect is determined based on the presence of the battery.
+
+Hardware Write Protect Setting | Battery State                  | Hardware Write Protect State
+------------------------------ | ------------------------------ | ----------------------------
+`follow_batt_pres`             | Connected                      | Enabled
+`follow_batt_pres`             | Disconnected                   | Disabled
+`follow_batt_pres`             | N/A (Chromebox has no battery) | Write Protect Screw means Enabled
+`enabled`                      | Any                            | Enabled
+`disabled`                     | Any                            | Disabled
+
+### Write Protect Commands
+
+```
+(gsc) > wp [enable|disable|follow_batt_pres]
+```
+
+There are two write protect settings: the current setting and the `atboot`
+setting.
+
+The `wp` command adjusts the current write protect setting that will last until
+GSC reboots or loses power. Note that GSC does not reboot when the rest of the
+system reboots. It will only reboot in the cases where the firmware is being
+updated, it crashes, the battery completely drains, the battery is removed, or
+power is otherwise lost.
+
+The `atboot` setting is the state of the write protect when GSC boots; it
+defaults to `follow_batt_pres`.
+
+To change the `atboot` setting, add the `atboot` arg to the end of the `wp`
+command:
+
+```
+(gsc) > wp [enable|disable|follow_batt_pres] atboot
+```
+
+You can query the write protect state with `gsctool`:
+
+```bash
+(dut) $ gsctool -a -w
+
+...
+Flash WP: forced disabled  <-- Current hardware write protect state
+ at boot: forced disabled  <-- "atboot" hardware write protect state
+
+```
+
+`gsctool -a -w` Status | Hardware Write Protect State
+---------------------- | ------------------------------------
+`forced disabled`      | Disabled
+`forced enabled`       | Enabled
+`enabled`              | Enabled, following battery presence
+`disabled`             | Disabled, following battery presence
+
+### Special Case Devices
+
+Bob devices have a write protect screw in addition to battery presence. The
+write protect screw will force enable write protect until it's removed. If GSC
+is set to `follow_batt_pres`, you need to remove the write protect screw and
+disconnect the battery to disable write protect. If you run `wp disable`, you
+will also need to remove the screw.
+
+If you are attempting to flash the AP, see the [Flashing the AP Special Cases]
+section for additional steps you may have to take to disable write protection.
+
+## UART Rescue mode
+
+### Overview
+
+UART Rescue Mode is a feature of the GSC RO firmware that supports programming
+the RW firmware using only the UART interface. This is used to recover a bad RW
+firmware update (which should be rare).
+
+This is also useful when bringing up new designs, as this allows to update GSC
+image even before USB CCD or TPM interfaces are operational.
+
+UART rescue works on all existing devices, all it requires is that GSC console
+is mapped to a `/dev/xxx` device on the workstation (the same device used to
+attach a terminal to the console).
+
+Rescue works as follows: when the RO starts, after printing the regular banner
+on the console it prints a magic string to the console and momentarily waits for
+the host to send a sync symbol, to indicate that an alternative RW will have to
+be loaded over UART. The RO also enters this mode if there is no valid RW to
+run.
+
+When rescue mode is triggered, the RO is expecting the host to transfer a single
+RW image in hex format.
+
+Follow the [brescue](./gsc_without_servod.md#gsc-rescue) procedure to perform a
+GSC rescue.
+
+## CCD Open Without Booting the Device {#ccd-open-no-boot}
+
+If you can’t boot your device, you won’t be able to enable [Developer Mode] to
+send the open command from the AP. If you have enabled CCD on the device before,
+GSC may be configured in a way that you can still open GSC.
+
+### Option 1: Remove the battery
+
+If you can remove the battery, you can bypass the [Developer Mode] requirements.
+`ccd open` is allowed from the GSC console if the Chrome OS Firmware Management
+Parameters (`FWMP`) do not disable CCD and the battery is disconnected. This is
+the most universal method and will work even if you haven’t enabled CCD before.
+
+1.  Disconnect the battery
+
+1.  Send `ccd open` from the GSC console.
+
+### Option 2: "OpenNoDevMode" and "OpenFromUSB" are set to Always
+
+If "OpenNoDevMode" and "OpenFromUSB" are set to Always, you will be able to open
+GSC from the GSC console without enabling [Developer Mode]:
+
+```
+(gsc) > ccd open
+```
+
+You will still need physical presence (i.e., press the power button) unless
+`testlab` mode is also enabled:
+
+```
+(gsc) > ccd testlab
+       CCD test lab mode enabled
+```
+
+#### Enabling
+
+If CCD is [`Open`], you can enable these settings with:
+
+```
+(gsc) > ccd set OpenFromUSB Always
+(gsc) > ccd set OpenNoDevMode Always
+```
+
+### Option 3: CCD Password is Set
+
+If the CCD password is set, you can open from the GSC console without
+[Developer Mode].
+
+```
+(gsc) > ccd open $PASSWORD
+(gsc) > ccd unlock $PASSWORD
+```
+
+Alternatively, you can use `gsctool`, entering the password when prompted:
+
+```
+(dut) $ gsctool -a -o
+(dut) $ gsctool -a -u
+```
+
+#### Enabling
+
+When CCD is [`Open`], run the `gsctool` command and enter the password when
+prompted.
+
+```bash
+(chroot) $ gsctool -a -P
+```
+
+You can use the CCD command on the GSC console to check if the password is set.
+
+```
+(gsc) > ccd
+       ...
+       Password: [none|set]
+       ...
+```
+
+#### Disabling
+
+When CCD is [`Open`], you can use `gsctool` to clear the password:
+
+```bash
+(dut) $ gsctool -a -P clear:$PASSWORD
+```
+
+Alternatively, you can use the GSC console to clear the password and reset CCD
+capabilities to their default values:
+
+```
+(gsc) > ccd reset
+```
+
+## Troubleshooting
+
+### rddkeepalive
+
+GSC only enables CCD when it detects a debug accessory is connected (e.g.,
+[Suzy-Q] or [Type-C Servo v4]). It detects the cable based on the voltages on
+the CC lines. If you are flashing the EC and AP or working with unstable
+hardware, these CC voltages may become unreliable for detecting a debug
+accessory.
+
+To work around this, you can force GSC to always assume that a debug cable is
+detected:
+
+```
+(gsc) > rddkeepalive enable
+```
+
+*** note
+**NOTE**: Enabling `rddkeepalive` does increase power consumption.
+***
+
+To disable:
+
+```
+(gsc) > rddkeepalive disable
+```
+
+### Updating GSC {#updating-cr50}
+
+Production (`MP`) versions of Cr50 firmware use a [minor version][semver] of
+`3`: `0.3.x`. Production firmware versions `0.3.9` or newer support CCD.
+
+Production (`MP`) versions of Ti50 firmware use a [minor version][semver] of
+`23`: `0.23.x`.
+
+Development (`PrePVT`) versions of Cr50 firmware use a minor version of `4`:
+`0.4.x`. Development firmware versions `0.4.9` or newer support CCD.
+
+Development (`PrePVT`) versions of Ti50 firmware use a minor version of `24`:
+`0.24.x`.
+
+There aren't many differences between the MP and PrePVT versions of images, but
+it is a little easier to CCD [`Open`] PrePVT images. You can't run PrePVT images
+on MP devices, so if you're trying to update to PrePVT and it fails try using
+the MP image.
+
+1.  Flash a test image newer than M66.
+
+1.  Enable [Developer Mode] and connect a debug cable ([`Suzy-Q`] or [`Type-C
+    Servo v4`]).
+
+1.  Check the running GSC version with `gsctool`:
+
+```bash
+(dut) $ sudo gsctool -a -f
+
+...
+RW 0.4.26  <-- The "RW" version is the one to check
+```
+
+1.  Update GSC using the firmware in the OS image:
+
+*Production (MP) image*:
+
+```bash
+(dut) $ sudo gsctool -a /opt/google/cr50/firmware/cr50.bin.prod
+(dut) $ sudo gsctool -a /opt/google/ti50/firmware/ti50.bin.prod
+```
+
+*Development (PrePVT) image*:
+
+```bash
+(dut) $ sudo gsctool -a /opt/google/cr50/firmware/cr50.bin.prepvt
+(dut) $ sudo gsctool -a /opt/google/ti50/firmware/ti50.bin.prepvt
+```
+
+1.  Check the GSC version again to make sure it's either `0.3.X` or `0.4.X`, or
+    check the Ti50 version again to make sure it's either `0.23.X` or `0.24.X`.
+
+### Speed up Flashing the AP {#speed-up-ap-flash}
+
+In the [default AP flashing steps][flashap] [`flashrom`] reads the entire flash
+contents and only erases and programs the pages that have to be modified.
+However, when GSC controls the SPI bus, it can only run at 1.5 MHz, versus the
+50 MHz that the AP normally runs it at.
+
+We can take advantage of the fact that Chrome OS device AP firmware is split
+into sections, only a few of which are essential for maintaining the device
+identity and for booting the device in recovery mode to program faster by only
+reading and writing sections we care about:
+
+```bash
+# This will save device flash map and VPD sections in
+# /tmp/bios.essentials.bin. VPD sections contain information like device
+# firmware ID, WiFi calibration, enrollment status, etc. Use the below command
+# only if you need to preserve the DUT's identity, no need to run it in case
+# the DUT flash is not programmed at all, or you do not care about preserving
+# the device identity.
+sudo flashrom -p raiden_debug_spi:target=AP -i FMAP -i RO_VPD -i RW_VPD -r /tmp/bios.essentials.bin
+
+# This command will erase the entire flash chip in one shot, the fastest
+# possible way to erase.
+sudo flashrom -p raiden_debug_spi:target=AP -E
+
+# This command will program essential flash sections necessary for the
+# Chrome OS device to boot in recovery mode. Note that the SI_ALL section is
+# not always present in the flash image, do not include it if it is not in
+# dump_fmap output.
+sudo flashrom -p raiden_debug_spi:target=AP -w image-atlas.bin -i FMAP -i WP_RO [-i SI_ALL] --noverify
+
+# This command will restore the previously preserved VPD sections of the
+# flash, provided it was saved in the first step above.
+sudo flashrom -p raiden_debug_spi:target=AP -w /tmp/bios.essential.bin -i RO_VPD -i RW_VPD --noverify
+```
+
+Once flash is programmed, the device can be booted in recovery mode and start
+Chrome OS from external storage, following the usual recovery procedure. Once
+Chrome OS is installed, AP flash can be updated to include the rest of the image
+by running [`flashrom`] or `futility` from the device bash prompt.
+
+[Case Closed Debugging]: ./case_closed_debugging.md
+[chromeos-cr50 ebuild]: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/chromeos-base/chromeos-cr50/chromeos-cr50-0.0.1.ebuild
+[chromeos-ti50 ebuild]: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/chromeos-base/chromeos-ti50/chromeos-ti50-0.0.1.ebuild
+[Developer Mode]: https://chromium.googlesource.com/chromiumos/docs/+/main/developer_mode.md#dev-mode
+[Recovery Mode]: https://chromium.googlesource.com/chromiumos/docs/+/main/debug_buttons.md
+[Servo]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo.md
+[`servod`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo.md
+[Type-C Servo v4]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md
+[update servo v4]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/servo_v4.md#updating-firmware
+[Suzy-Q]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/main/docs/ccd.md#SuzyQ-SuzyQable
+[`hdctools`]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/refs/heads/main/README.md
+[`FlashAP`]: #flashap
+[flashing the AP firmware]: #flashap
+[flashap]: #flashap
+[Flashing the AP Special Cases]: #flashap-special-cases
+[`FlashEC`]: #flashec
+[flashing the EC firmware]: #flashec
+[`OverrideWP`]: #hw-wp
+[`Always`]: #cap-priv
+[`IfOpened`]: #cap-priv
+[`Open`]: #cap-priv
+[`Locked`]: #cap-priv
+[`Unlocked`]: #cap-priv
+[Updating Cr50]: #updating-cr50
+[CCD Open Without Booting the Device]: #ccd-open-no-boot
+[cap]: #cap
+[consoles]: #consoles
+[hw-wp]: #hw-wp
+[`flash_ec`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/main/util/flash_ec
+[CCD Open]: #ccd-open
+[`flashrom`]: https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/main/README.chromiumos
+[speed up the flashing process]: #speed-up-ap-flash
+[this bug]: https://issuetracker.google.com/149420712
+[semver]: https://semver.org/
+[`usb_console`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/main/extra/usb_serial/console.py
diff --git a/docs/ccd_howtos.md b/docs/ccd_howtos.md
index 309a3b73b8..c7c8996561 100644
--- a/docs/ccd_howtos.md
+++ b/docs/ccd_howtos.md
@@ -3,7 +3,7 @@ This doc contains tutorials for using CCD. These tutorials only cover using GSC
 CCD. Some use cases will be very similar to using CCD from ryu, servo micro, or
 servo v4, but these guides are not guaranteed to work for them. More detailed
 instructions on how to use different parts of CCD are in the
-[GSC CCD doc](case_closed_debugging_cr50.md).
+[GSC CCD doc](case_closed_debugging_gsc.md).
 
 [TOC]
 
@@ -152,7 +152,7 @@ is not a clamshell, check out the [full dev mode instructions].
 9.  **Open CCD.** Here's the most generic way to open ccd. For the full open
     options see [Setup CCD].
 
-    *   **[Enter dev mode](case_closed_debugging_cr50.md#enter-dev-mode).**
+    *   **[Enter dev mode](case_closed_debugging_gsc.md#enter-dev-mode).**
         These are clamshell instructions for other types of chromeOS devices
         refer to the full setup doc.
 
@@ -313,7 +313,7 @@ It goes into a lot more detail.
 1.  **Open CCD.** Here's the most generic way to open ccd. For the full open
     options see [Setup CCD].
 
-    *   **[Enter dev mode](case_closed_debugging_cr50.md#enter-dev-mode).**
+    *   **[Enter dev mode](case_closed_debugging_gsc.md#enter-dev-mode).**
         These are clamshell instructions for other types of chromeOS devices
         refer to the full setup doc.
 
@@ -374,11 +374,11 @@ It goes into a lot more detail.
 
                 AP > flashrom -p host --wp-disable
 
-[Disable SW WP]: ./case_closed_debugging_cr50.md#AP-Off
-[enter dev mode]: ./case_closed_debugging_cr50.md#enter-dev-mode
+[Disable SW WP]: ./case_closed_debugging_gsc.md#AP-Off
+[enter dev mode]: ./case_closed_debugging_gsc.md#enter-dev-mode
 [sparkfun]: https://www.sparkfun.com/products/14746
-[Setup CCD]: ./case_closed_debugging_cr50.md#CCD-Setup
+[Setup CCD]: ./case_closed_debugging_gsc.md#CCD-Setup
 [SuzyQ]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/refs/heads/main/docs/ccd.md#suzyq-suzyqable
 [Type-C Servo V4]: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/refs/heads/main/docs/servo_v4.md
-[wp console command]: ./case_closed_debugging_cr50.md#WP-control
+[wp console command]: ./case_closed_debugging_gsc.md#WP-control
 
diff --git a/docs/cr50_vboot_troubleshooting.md b/docs/cr50_vboot_troubleshooting.md
index eba6974a61..23d0d7d615 100644
--- a/docs/cr50_vboot_troubleshooting.md
+++ b/docs/cr50_vboot_troubleshooting.md
@@ -22,7 +22,7 @@ is why any **problems communicating with the TPM during the boot up process**
 result in the Chrome OS device falling into **recovery mode**.
 
 Another important function of the H1 in the system is CCD ([closed case
-debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/fe6ca90e/docs/case_closed_debugging_cr50.md#))
+debugging](https://chromium.googlesource.com/chromiumos/platform/ec/+/fe6ca90e/docs/case_closed_debugging_gsc.md#))
 
 ## H1 power states and CCD
 
diff --git a/docs/sitemap.md b/docs/sitemap.md
index e975d7c7bf..2d3de163d0 100644
--- a/docs/sitemap.md
+++ b/docs/sitemap.md
@@ -10,7 +10,7 @@
 ## Case Closed Debugging (CCD)
 
 *   [Case Closed Debugging Overview](./case_closed_debugging.md)
-*   [Google Security Chip Case Closed Debugging](./case_closed_debugging_cr50.md)
+*   [Google Security Chip Case Closed Debugging](./case_closed_debugging_gsc.md)
 *   [Tutorials](./ccd_howtos.md)
 
 ## Updaters
diff --git a/docs/write_protection.md b/docs/write_protection.md
index 83a6490514..a05108d55a 100644
--- a/docs/write_protection.md
+++ b/docs/write_protection.md
@@ -298,9 +298,9 @@ The EC code command handlers (`command_flash_erase`, `command_flash_write`,
 etc.) return an error if `EC_FLASH_PROTECT_ALL_NOW` is set.
 
 [write_protect_gpio]: https://chromium.googlesource.com/chromiumos/platform/ec/+/aaba1d5efd51082d143ce2ac64e6caf9cb14d5e5/include/ec_commands.h#1599
-["CCD open"]: ./case_closed_debugging_cr50.md#Open-CCD
-[Cr50 console]: ./case_closed_debugging_cr50.md#Consoles
-[`OverrideWP`]: ./case_closed_debugging_cr50.md
+["CCD open"]: ./case_closed_debugging_gsc.md#Open-CCD
+[Cr50 console]: ./case_closed_debugging_gsc.md#Consoles
+[`OverrideWP`]: ./case_closed_debugging_gsc.md
 [wp_screw]: https://www.chromium.org/chromium-os/firmware-porting-guide/firmware-ec-write-protection
 [`system_is_locked()`]: https://chromium.googlesource.com/chromiumos/platform/ec/+/aaba1d5efd51082d143ce2ac64e6caf9cb14d5e5/common/system.c#195
 [Servo]: https://www.chromium.org/chromium-os/servo