mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2026-01-09 17:11:42 +00:00
94ff216f32
When recovery is required, it will be because there's either a hardware pin pulled somewhere, or because the recovery_reason is set in NVRAM. Coreboot and U-Boot can see both of those, so the EC shouldn't make up a new reason. If it does, it changes the original cause. BUG=chrome-os-partner:9706 TEST=manual Reset the EC using ESC+Power (Refresh+Power on EVT). At a root shell, run crossystem recovery_request=11 reboot When you see the Recovery screen, press TAB. It should say recovery_reason: 0x0b We have no idea what this means Prior to this fix, you'd see recovery_reason 2 instead, which is wrong. Change-Id: Ie54185471927e7e829962d30bba9d142d593088f Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/24152 Reviewed-by: Randall Spangler <rspangler@chromium.org>
- EC Lib
This wraps Blizzard driverlib and implements the EC chip interface defined
by Google. See below diagram for architecture.
+--------------------+
| Host BIOS/OS |
+--------------------+
---- host interface ----
+--------------------+
| Google EC features |
+--------------------+
---- chip interface ---- The interface is defined in
src/platform/ec/chip_interface/*.
+--------------------+ But the real implementation is in EC Lib.
| EC Lib |
+--------------------+
| Blizzard low level |
| driver, the |
| driverlib. |
+--------------------+