Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18008
-gerrit
commit 62bdfb6c28803475eaa456d63201de813341eea1
Author: Hung-Te Lin <hungte(a)chromium.org>
Date: Thu Dec 29 20:59:37 2016 +0800
vboot: Clear battery cutoff flags when vbnv_cmos loads backup VBNV.
When CONFIG_VBOOT_VBNV_CMOS_BACKUP_TO_FLASH is set, vbnv_cmos will try
to load VBNV from flash if the VBNV in CMOS is invalid. This is usually
correct, except the case of battery cut-off.
CMOS will always be invalid after battery cut-off if there is no RTC
battery (or if that is dead). However, in current implementation the
backup in flash is only updated in Coreboot, while the real battery
cutoff (and the clearing of cutoff flags in VBNV) is done in payload
(Depthcharge) stage. This will create an endless reboot loop that:
1. crossystem sets battery cutoff flag in VBNV_CMOS then reboot.
2. Coreboot backups VBNV_CMOS to VBNV_flash.
3. Depthcharge sees cutoff flag in VBNV_CMOS.
4. Depthcharge clears cutoff flag in VBNV_CMOS.
5. Depthcharge performs battery cutoff (CMOS data is lost).
6. (Plug AC adapter) Reboot.
7. Coreboot sees invalid VBNV_CMOS, load backup from VBNV_flash.
8. Jump to 3.
As a result, we should always clear battery cutoff flags when loading
backups from VBNV_flash.
BRANCH=glados,reef
BUG=chrome-os-partner:61365,chrome-os-partner:59615
TEST=emerge-reef coreboot bootimage;
Change-Id: I3250a3a179a7b0de9c6e401e4a94dcd23920e473
Signed-off-by: Hung-Te Lin <hungte(a)chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/423460
Reviewed-by: Duncan Laurie <dlaurie(a)google.com>
---
src/vboot/vbnv.c | 6 ++++++
src/vboot/vbnv.h | 1 +
src/vboot/vbnv_cmos.c | 17 +++++++++++++++++
src/vboot/vbnv_layout.h | 3 +++
4 files changed, 27 insertions(+)
diff --git a/src/vboot/vbnv.c b/src/vboot/vbnv.c
index ce64928..6537bf0 100644
--- a/src/vboot/vbnv.c
+++ b/src/vboot/vbnv.c
@@ -79,6 +79,12 @@ int verify_vbnv(uint8_t *vbnv_copy)
(crc8_vbnv(vbnv_copy, CRC_OFFSET) == vbnv_copy[CRC_OFFSET]);
}
+/* Re-generate VBNV checksum. */
+void regen_vbnv_crc(uint8_t *vbnv_copy)
+{
+ vbnv_copy[CRC_OFFSET] = crc8_vbnv(vbnv_copy, CRC_OFFSET);
+}
+
/*
* Read VBNV data from configured storage backend.
* If VBNV verification fails, reset the vbnv copy.
diff --git a/src/vboot/vbnv.h b/src/vboot/vbnv.h
index 78ca8f6..30da6a5 100644
--- a/src/vboot/vbnv.h
+++ b/src/vboot/vbnv.h
@@ -22,6 +22,7 @@
void read_vbnv(uint8_t *vbnv_copy);
void save_vbnv(const uint8_t *vbnv_copy);
int verify_vbnv(uint8_t *vbnv_copy);
+void regen_vbnv_crc(uint8_t *vbnv_copy);
int get_recovery_mode_from_vbnv(void);
void set_recovery_mode_into_vbnv(int recovery_reason);
int vboot_wants_oprom(void);
diff --git a/src/vboot/vbnv_cmos.c b/src/vboot/vbnv_cmos.c
index 5eda8e6..b7ef3e7 100644
--- a/src/vboot/vbnv_cmos.c
+++ b/src/vboot/vbnv_cmos.c
@@ -20,6 +20,22 @@
#include <vboot/vbnv.h>
#include <vboot/vbnv_layout.h>
+static void clear_vbnv_battery_cutoff_flag(uint8_t *vbnv_copy)
+{
+ /*
+ * Currently battery cutoff is done in payload stage, which does not
+ * update backup VBNV. And doing battery cutoff will invalidate CMOS.
+ * This means for every reboot after cutoff, read_vbnv_cmos will reload
+ * backup VBNV and try to cutoff again, causing endless reboot loop.
+ * So we should always clear battery cutoff flag from loaded backup.
+ */
+ if (vbnv_copy[MISC_FLAGS_OFFSET] & MISC_FLAGS_BATTERY_CUTOFF_MASK) {
+ printk(BIOS_INFO, "VBNV: Remove battery cut-off request.\n");
+ vbnv_copy[MISC_FLAGS_OFFSET] &= ~MISC_FLAGS_BATTERY_CUTOFF_MASK;
+ regen_vbnv_crc(vbnv_copy);
+ }
+}
+
void read_vbnv_cmos(uint8_t *vbnv_copy)
{
int i;
@@ -35,6 +51,7 @@ void read_vbnv_cmos(uint8_t *vbnv_copy)
read_vbnv_flash(vbnv_copy);
if (verify_vbnv(vbnv_copy)) {
+ clear_vbnv_battery_cutoff_flag(vbnv_copy);
save_vbnv_cmos(vbnv_copy);
printk(BIOS_INFO, "VBNV: Flash backup restored\n");
} else {
diff --git a/src/vboot/vbnv_layout.h b/src/vboot/vbnv_layout.h
index 59acd0c..1dc01c9 100644
--- a/src/vboot/vbnv_layout.h
+++ b/src/vboot/vbnv_layout.h
@@ -41,6 +41,9 @@
#define DEV_BOOT_USB_MASK 0x01
#define DEV_BOOT_SIGNED_ONLY_MASK 0x02
+#define MISC_FLAGS_OFFSET 8
+#define MISC_FLAGS_BATTERY_CUTOFF_MASK 0x08
+
#define KERNEL_FIELD_OFFSET 11
#define CRC_OFFSET 15
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18007
-gerrit
commit 02e37466ed490610d43dab529c1d9c7182ba6437
Author: Julius Werner <jwerner(a)chromium.org>
Date: Fri Dec 16 16:03:57 2016 -0800
rockchip/common: Loosen I2C frequency target requirements
I've recently added an assertion to ensure that the effective I2C
frequency on Rockchip SoCs is not too far off the 400KHz target due to
divisor rounding errors. A 10KHz margin worked fine for RK3399, but it
turns out that RK3288 actually only ever hit 387KHz since its I2C clocks
are based off the already pretty low 75MHz PCLKs. While we could
probably change the PCLKs to make this closer, that seems like a too
intrusive change for something that has already worked just fine for
years, so just loosen the restriction a little more instead.
BRANCH=None
BUG=chromium:675043
TEST=None
Change-Id: I7e96a1a75b38f8ad3971dd33046699cceb17b80d
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421095
Reviewed-by: Randall Spangler <rspangler(a)chromium.org>
---
src/soc/rockchip/common/i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/soc/rockchip/common/i2c.c b/src/soc/rockchip/common/i2c.c
index a00d538..032efda 100644
--- a/src/soc/rockchip/common/i2c.c
+++ b/src/soc/rockchip/common/i2c.c
@@ -286,6 +286,6 @@ void i2c_init(unsigned int bus, unsigned int hz)
i2c_clk = i2c_src_clk / (8 * (divl + 1 + divh + 1));
printk(BIOS_DEBUG, "I2C bus %u: %uHz (divh = %u, divl = %u)\n",
bus, i2c_clk, divh, divl);
- assert((divh < 65536) && (divl < 65536) && hz - i2c_clk < 10*KHz);
+ assert((divh < 65536) && (divl < 65536) && hz - i2c_clk < 15*KHz);
write32(®s->i2c_clkdiv, (divh << 16) | (divl << 0));
}
Patrick Georgi (pgeorgi(a)google.com) just uploaded a new patch set to gerrit, which you can find at https://review.coreboot.org/18006
-gerrit
commit 113317eafa9d8a42292b46623ef9285707503fe8
Author: Julius Werner <jwerner(a)chromium.org>
Date: Wed Nov 30 17:46:17 2016 -0800
i2c/tpm: Ignore 0xFF bytes for status and burstCount
We've found that the SLB9645 TPM sometimes seems to randomly start
returning 0xFF bytes for all requests. The exact cause is yet unknown,
but we should try to write our TIS code such that it avoids bad
interactions with this kind of response (e.g. any wait_for_status()
immediately succeeds because all "status bits" are set in the response).
At least for status and burstCount readings we can say for sure that the
value is nonsensical and we're already reading those in a loop until we
get valid results anyway, so let's add code to explicitly discount 0xFF
bytes.
BRANCH=oak
BUG=chrome-os-partner:55764
TEST=None
Change-Id: I934d42c36d6847a22a185795cea49d282fa113d9
Signed-off-by: Julius Werner <jwerner(a)chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420470
Reviewed-by: Nicolas Boichat <drinkcat(a)chromium.org>
---
src/drivers/i2c/tpm/tpm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/drivers/i2c/tpm/tpm.c b/src/drivers/i2c/tpm/tpm.c
index 55c25fe..972b17d 100644
--- a/src/drivers/i2c/tpm/tpm.c
+++ b/src/drivers/i2c/tpm/tpm.c
@@ -291,6 +291,8 @@ static uint8_t tpm_tis_i2c_status(struct tpm_chip *chip)
uint8_t buf;
if (iic_tpm_read(TPM_STS(chip->vendor.locality), &buf, 1) < 0)
return 0;
+ else if (buf == 0xff) /* Some TPMs sometimes randomly return 0xff. */
+ return 0;
else
return buf;
}
@@ -316,7 +318,7 @@ static ssize_t get_burstcount(struct tpm_chip *chip)
else
burstcnt = (buf[2] << 16) + (buf[1] << 8) + buf[0];
- if (burstcnt)
+ if (burstcnt && burstcnt != 0xffffff)
return burstcnt;
mdelay(TPM_TIMEOUT);
timeout--;