(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:
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):==
==CLs:==
https://chromium-review.googlesource.com/#/c/306774/
