diff options
author | Julius Werner <jwerner@chromium.org> | 2017-03-16 14:08:09 -0700 |
---|---|---|
committer | Patrick Georgi <pgeorgi@google.com> | 2017-03-17 11:38:22 +0100 |
commit | 2d99f3b15886ff984ae469b50d850b360e19911e (patch) | |
tree | d92e9c0412284e2695663a71a8c57fb88a30ac11 /src | |
parent | 336a34c81be7455ce2ec978b31fb04f5d4518ec0 (diff) |
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>
Diffstat (limited to 'src')
-rw-r--r-- | src/mainboard/google/veyron/Kconfig | 10 | ||||
-rw-r--r-- | src/mainboard/google/veyron/boardid.c | 5 |
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; |