summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2017-03-16 14:08:09 -0700
committerPatrick Georgi <pgeorgi@google.com>2017-03-17 11:38:22 +0100
commit2d99f3b15886ff984ae469b50d850b360e19911e (patch)
treed92e9c0412284e2695663a71a8c57fb88a30ac11
parent336a34c81be7455ce2ec978b31fb04f5d4518ec0 (diff)
downloadcoreboot-2d99f3b15886ff984ae469b50d850b360e19911e.tar.xz
google/veyron: Work around RAM code strapping error
With a recent patch (google/veyron_*: Add new Micron and Hynix modules) we switched RAM codes for Veyron boards to tri-state since we were running out of binary numbers. Unfortunately we only tested that change on Minnie and Speedy, and it turns out that it broke Jaq, Jerry and Mighty. The "high" RAM code pins on those boards were incorrectly strapped with 100Kohm resistors (as opposed to 1Kohm on Minnie and Speedy), which is too high to overpower the SoC-internal pull-down we use to differentiate "high" from "tri-state". Since we already used tri-state codes on some Minnie and Speedy SKUs we have to hack up the code to work differently on these two groups of boards to keep everything working. BRANCH=veyron BUG=b:36279493 TEST=Compiled, confirmed ram_code called the right function depending on board. Change-Id: I253b213ef7ca621ce47a7a55a5119a167d944078 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18859 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
-rw-r--r--src/mainboard/google/veyron/Kconfig10
-rw-r--r--src/mainboard/google/veyron/boardid.c5
2 files changed, 14 insertions, 1 deletions
diff --git a/src/mainboard/google/veyron/Kconfig b/src/mainboard/google/veyron/Kconfig
index 0bd1e2ef7b..2a16ff9d46 100644
--- a/src/mainboard/google/veyron/Kconfig
+++ b/src/mainboard/google/veyron/Kconfig
@@ -18,6 +18,16 @@ config BOARD_GOOGLE_VEYRON # dummy option to be selected by variant boards
if BOARD_GOOGLE_VEYRON
+# Some Veyron boards incorrectly had their RAM code strapped with 100Kohm
+# resistors. These get overpowered by the SoC's internal pull-downs, so we
+# cannot read those pins as tri-state. They're restricted to binary RAM codes.
+config VEYRON_FORCE_BINARY_RAM_CODE
+ bool
+ default y if BOARD_GOOGLE_VEYRON_JAQ
+ default y if BOARD_GOOGLE_VEYRON_JERRY
+ default y if BOARD_GOOGLE_VEYRON_MIGHTY
+ default n
+
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select BOARD_ID_AUTO
diff --git a/src/mainboard/google/veyron/boardid.c b/src/mainboard/google/veyron/boardid.c
index 47e946e635..8bd1d7665b 100644
--- a/src/mainboard/google/veyron/boardid.c
+++ b/src/mainboard/google/veyron/boardid.c
@@ -38,7 +38,10 @@ uint32_t ram_code(void)
gpio_t pins[] = {[3] = GPIO(8, A, 3), [2] = GPIO(8, A, 2),
[1] = GPIO(8, A, 1), [0] = GPIO(8, A, 0)}; /* GPIO8_A0 is LSB */
- code = gpio_binary_first_base3_value(pins, ARRAY_SIZE(pins));
+ if (IS_ENABLED(CONFIG_VEYRON_FORCE_BINARY_RAM_CODE))
+ code = gpio_base2_value(pins, ARRAY_SIZE(pins));
+ else
+ code = gpio_binary_first_base3_value(pins, ARRAY_SIZE(pins));
printk(BIOS_SPEW, "RAM Config: %u.\n", code);
return code;