USB-C / PD Low Power Boot
(Additional discussion on crbug.com/537269)
==Problem==:
Chrome OS devices may require more than 15W of power, even in firmware. For security reasons, our EC does not attempt to negotiate a PD power contract until it has jumped to RW, so we are limited to pulling 15W (3A @ 5V) from a USB-C / PD charger in RO. In addition, we have no knowledge of how much power a PD charger may be able to deliver while in EC RO. Therefore, in order to guarantee that a device is able to boot successfully into Chrome OS, the system must have a minimum battery level before booting, even when a PD charger is attached.
==Samus==:
The solution implemented on Samus is to wait for 1% battery charge level before allowing power-on. If a high-power PD charger is attached, we’ll negotiate a sufficient power contract once jumping to EC RW, and the system will be usable indefinitely. If a low-power charger is attached, the 1% battery level should be enough to allow us to boot Chrome OS, see a low-power shutdown message, and automatically power down cleanly.
Samus uses a flashing red lightbar to notify the user that the device is waiting for sufficient battery charge to allow boot. Future PD-powered devices may not have such a lightbar.
==Future Improvement==:
Ideally we’d like to handle the most common user case (high-powered charger attached) without needless delay. Here is a proposed method to do so:
-
If the system has enough battery charge (defined as >= 1% on Samus, but can be defined arbitrarily on other devices) then it will boot as normal, since any charger (or even no charger) will be sufficient to cleanly boot into Chrome OS and then cleanly shutdown.
-
If the system does not have enough battery charge and no charger is attached, the EC will disallow power on through inhibiting the power button. From the user POV, this is a “dead battery” case.
-
If a charger is attached, and the charger advertises < 15W through its CC pullup, the EC will disallow power on through inhibiting the power button. The charger isn’t likely to speak PD, and isn’t likely to be able to provide > 15W in any case.
-
If a charger is attached, and the charger advertises 15W through its CC pullup, the EC will set a limit power flag (“LP”) indicating that the system is in a low-battery + low-power charger state, and boot the AP.
-
If LP is set and the system is booting into recovery mode, the AP will power itself down. Recovery mode is never allowed to jump to EC RW.
-
If LP is set and the system is not booting into recovery mode, after SW sync and jump to EC RW, the AP will wait for some timeout period (3 sec) while polling LP. If the EC negotiates a sufficient PD power contract (perhaps >= 30W, but should be adjusted by platform) while in EC RW, it will clear the LP flag.
-
If LP is cleared within the timeout period, the AP will boot as normal.
-
If LP is not cleared within the timeout period, the AP will shut itself down.
This proposal can only be implemented if the device is able to power-on the AP through software sync completion while consuming < 15W. In order to meet this requirement, devices may have to limit power through various means, such as disabling USB ports, asserting PROCHOT, etc.
==Future Chromeboxes:==
Chromeboxes are a special case because they lack a battery. Such devices may never be able to boot a low-power charger. If we were to follow the method above, Chromeboxes would ==never== be able to boot into recovery mode. Thus, the following additional changes need to be made for batteryless devices:
- If a charger is attached and the system is booting into user-triggered (not “broken” recovery mode) recovery mode, the EC will attempt to negotiate a PD contract from RO EC FW. If a sufficient contract is negotiated, the system will boot to recovery as normal. If not, the LP flag will be set.
- If LP is set and the system is booting into recovery mode, the AP will notify the user of the broken condition by some method, such as blinking LEDs, or displaying the “broken” screen (power-allowing).
We will assume that the charger attached for user-triggered recovery is trustable, and will provide instructions to users that they should use the OEM charger (power-cycled beforehand for extra paranoia) while booting in recovery mode for maximum security.
==Other Idea Considered (but rejected):==
- EC-RO does RSA-3072 verification of EC-RW and jumps to it without involvement of the AP, in case the charger is not sufficient to boot the AP at all (< 15W). This idea was rejected, because a charger that advertises 2.5W - 7.5W isn’t likely to speak PD or be able to negotiate to provide > 15W.
- Display “low battery” firmware screen to notify the user that the battery isn’t sufficiently charged. This requires initializing the display, which may push system power usage above 15W. We can revisit this idea if we have power data that shows it is feasible.
- Allow Chromeboxes (and other battery-less devices) to jump to do SW sync and then jump to EC RW while in recovery mode. If we’re flashing an EC RW image via SW sync in recovery mode, it must come from RO FW, so it’s presumably no different than the EC RO image. Therefore, this idea is no different than allowing PD communication from EC RO in recovery mode.
- Have the AP determine LP status by checking the battery / charger state through various host commands, rather than relying upon a single memmap flag set by the EC. Though this would simplify implementation, it means that board-specific charge / power related constants (such as minimum power level sufficient to not set LP) would have to live somewhere in system FW.
==CLs:==
https://chromium-review.googlesource.com/#/c/306774/