summaryrefslogtreecommitdiff
path: root/src/mainboard/google/gru
AgeCommit message (Collapse)Author
2019-04-23src: Use include <console/console.h> when appropriateElyes HAOUAS
Change-Id: Iddba5b03fc554a6edc4b26458d834e47958a6b08 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32214 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: David Guckian
2019-04-11chromeos: clean up "recovery" and "write protect" GPIOsJoel Kitching
The "write protect" GPIO's cached value is never actually read after entering depthcharge. Ensure the value from get_write_protect_state() is being transferred accurately, so that we may read this GPIO value in depthcharge without resampling. The cached value of the "recovery" GPIO is read only on certain boards which have a physical recovery switch. Correct some of the values sent to boards which presumably never read the previously incorrect value. Most of these inaccuracies are from non-inverted values on ACTIVE_LOW GPIOs. BUG=b:124141368, b:124192753, chromium:950273 TEST=make clean && make test-abuild BRANCH=none Change-Id: Ic17a98768703d7098480a9233b752fe5b201bd51 Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32233 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-04-01assert: Make dead_code() work at link-time instead of compile-timeJulius Werner
The dead_code() macro can be used to ensure that a certain code path is compile-time eliminated (e.g. if you want to make sure it's never executed for certain Kconfig combinations). Unfortunately, the current implementation via __attribute__((error)) hits only at the GCC level. This can catch code that can be compile-time eliminated based on state within the same file, but it cannot be used in cases where a certain library function is built but then garbage collected at link time. This patch improves the macro by relying solely on the linker finding an undefined reference. Unfortunately this makes the error message a little less expressive (can no longer pass a custom string), but it is still readable and one can add code comments next to the assertion to elaborate further if necessary Change-Id: I63399dc484e2150d8c027bc0256d9285e471f7cc Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/32113 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-08coreboot: Replace all IS_ENABLED(CONFIG_XXX) with CONFIG(XXX)Julius Werner
This patch is a raw application of find src/ -type f | xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g' Change-Id: I6262d6d5c23cabe23c242b4f38d446b74fe16b88 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-05mainboard: Enable PRESERVE flag in all vboot/chromeos FMD filesHung-Te Lin
For Chrome OS (or vboot), The PRESERVE flags should be applied on following sections: RO_PRESERVE, RO_VPD, RW_PRESERVE, RW_ELOG, RW_NVRAM, RW_SMMSTORE, RW_VPD, RO_FSG (b:116326638), SI_GBE (chromium:936768), SI_PDR (chromium:936768) With the new PRESERVE flag, we don't need RO_PRESERVE and RW_PRESERVE in the future. But it's still no harm to use it if there are multiple sections all needing to be preserved. BUG=chromium:936768 TEST=Builds google/eve and google/kukui inside Chrome OS source tree. Also boots successfully on eve and kukui devices. Change-Id: I6664ae3d955001ed14374e2788d400ba5fb9b7f8 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31709 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-03-04device/mmio.h: Add include file for MMIO opsKyösti Mälkki
MMIO operations are arch-agnostic so the include path should not be arch/. Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31691 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-03-04arch/io.h: Drop unnecessary includeKyösti Mälkki
Change-Id: I91158452680586ac676ea11c8589062880a31f91 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31692 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-22symbols.h: Add macro to define memlayout region symbolsJulius Werner
When <symbols.h> was first introduced, it only declared a handful of regions and we didn't expect that too many architectures and platforms would need to add their own later. However, our amount of platforms has greatly expanded since, and with them the need for more special memory regions. The amount of code duplication is starting to get unsightly, and platforms keep defining their own <soc/symbols.h> files that need this as well. This patch adds another macro to cut down the definition boilerplate. Unfortunately, macros cannot define other macros when they're called, so referring to region sizes as _name_size doesn't work anymore. This patch replaces the scheme with REGION_SIZE(name). Not touching the regions in the x86-specific <arch/symbols.h> yet since they don't follow the standard _region/_eregion naming scheme. They can be converted later if desired. Change-Id: I44727d77d1de75882c72a94f29bd7e2c27741dd8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/31539 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-11-21(console,drivers/uart)/Kconfig: Fix dependenciesNico Huber
The dependencies of CONSOLE_SERIAL and DRIVERS_UART were somehow backwards. Fix that. Now, CONSOLE_SERIAL depends on DRIVERS_UART, because it's using its interface. The individual UART drivers select DRIVERS_UART, because they implement the interface and depend on the common UART code. Some guards had to be fixed (using CONSOLE_SERIAL now instead of DRIVERS_UART). Some other guards that were only about compilation of units were removed. We want to build test as much as possible, right? Change-Id: I0ea73a8909f07202b23c88db93df74cf9dc8abf9 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/29572 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-11-16mb/*/*/Kconfig: Don't specify devicetree path if default val usedPeter Lemenkov
Change-Id: I3d77a625c5ece7b7ea5476fe0bd42829d1fc72c4 Signed-off-by: Peter Lemenkov <lemenkov@gmail.com> Reviewed-on: https://review.coreboot.org/29625 Reviewed-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-23src: Remove unneeded whitespaceElyes HAOUAS
Change-Id: I6c77f4289b46646872731ef9c20dc115f0cf876d Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/29161 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-10-22soc/rockchip/rk3399: Convert to `board_reset()`Nico Huber
Change-Id: Id07e1c7fbd35393ffafda53fc7a15ec0e157d075 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/29049 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-08-17arm64: Factor out common parts of romstage execution flowJulius Werner
The romstage main() entry point on arm64 boards is usually in mainboard code, but there are a handful of lines that are always needed in there and not really mainboard specific (or chipset specific). We keep arguing every once in a while that this isn't ideal, so rather than arguing any longer let's just fix it. This patch moves the main() function into arch code with callbacks that the platform can hook into. (This approach can probably be expanded onto other architectures, so when that happens this file should move into src/lib.) Tested on Cheza and Kevin. I think the approach is straight-forward enough that we can take this without testing every board. (Note that in a few cases, this delays some platform-specific calls until after console_init() and exception_init()... since these functions don't really take that long, especially if there is no serial console configured, I don't expect this to cause any issues.) Change-Id: I7503acafebabed00dfeedb00b1354a26c536f0fe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/28199 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-06-04security/tpm: Unify the coreboot TPM software stackPhilipp Deppenwiese
* Remove 2nd software stack in pc80 drivers directory. * Create TSPI interface for common usage. * Refactor TSS / TIS code base. * Add vendor tss (Cr50) directory. * Change kconfig options for TPM to TPM1. * Add user / board configuration with: * MAINBOARD_HAS_*_TPM # * BUS driver * MAINBOARD_HAS_TPM1 or MAINBOARD_HAS_TPM2 * Add kconfig TPM user selection (e.g. pluggable TPMs) * Fix existing headers and function calls. * Fix vboot for interface usage and antirollback mode. Change-Id: I7ec277e82a3c20c62a0548a1a2b013e6ce8f5b3f Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/24903 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-22rk3399: Enable bootblock compressionJulius Werner
This patch enables the new bootblock compression feature on RK3399, which requires moving MMU initialization into the decompressor stage and linking the decompressor (rather than the bootblock) into the entry point jumped to by the masked ROM. RK3399's masked ROM seems to be using a bitbang SPI driver to load us (very long pauses between clocking in each byte), with an effective data rate of about 1Mbit. Bootblock loading time (as measured on a SPI analyzer) is reduced by almost 100ms (about a third), while the decompression time is trivial (under 1ms). Change-Id: I48967ca5bb51cc4481d69dbacb4ca3c6b96cccea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26341 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-08mb/google: Get rid of device_tElyes HAOUAS
Use of device_t has been abandoned in ramstage. Change-Id: I8e549e4222ae2ed6b9c46f81c5b5253e8b227ee8 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26086 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-04mainboard/google: Comment variant names in KconfigMartin Roth
It's very confusing trying to find the google platform names, because they seem all unsorted in Kconfig. They're actually sorted according to the variant name, but previously, that was impossible to tell. - Add a comment to the top of variants in Kconfig.name - Inset each variant name. If you start a prompt with whitespace, it gets ignored, so after trying various ways to indent, the arrow was the option I thought looked the best. It now looks like this: *** Beltino *** -> Mccloud (Acer Chromebox CXI) -> Monroe (LG Chromebase 22CV241 & 22CB25S) -> Panther (ASUS Chromebox CN60) -> Tricky (Dell Chromebox 3010) -> Zako (HP Chromebox G1) Butterfly (HP Pavilion Chromebook 14) Chell (HP Chromebook 13 G1) Cheza *** Cyan *** Change-Id: I35cb16b040651cd1bd0c4aef98494368ef5ca512 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/26020 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-04-17cbfs: Add cbfs_boot_load_file()T Michael Turney
Generalize cbfs_boot_load_struct() by passing in CBFS type Change-Id: I6e5f845cb4ce5b00f01a39619919f85e39028f19 Signed-off-by: T Michael Turney <mturney@codeaurora.org> Reviewed-on: https://review.coreboot.org/25648 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-03-08google/scarlet: Adjust K&D power sequence from softwareBrian Norris
Hardware updates have suggested we need to configure the K&D panel's power sequence in software, not in hardware. Without this change, K&D panels will no longer power on correctly and will instead display a black screen. Per K&D's suggestion, we tweak these two commands. From the little HW docs I have, this looks like it's: (Address 0xB7, Value 0x02) -> set BC_CTRL=bit(1) (Back light control) to 1 (Address 0xF1, Value 0x22) -> change GPO2_SEL=bits(0:3) from MIPI_TE(0001b) to BC_CTRL (0010b) BRANCH=scarlet BUG=b:73133861 TEST=KD display with and without HW fix on Scarlet Change-Id: Ia076a378b10417dd9891746f9bc1086360a0f6e6 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://review.coreboot.org/25023 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-02-16google/gru: Fix GPIO_WP pull and polarity for ScarletJulius Werner
Turns out the write-protect GPIO polarity for Scarlet is different than for Kevin/Gru, and nobody ever told us. Also, it must not be configured with an internal pull-up or we'll not read the correct value. This patch fixes both issues. BRANCH=scarlet BUG=b:73356326 TEST=Booted Scarlet, confirmed that crossystem wpsw_boot returns the right value in all cases. Change-Id: Idd348ecdf9da8fff7201b83e869ba097b8570f32 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/23767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-02-06google/gru: Add another 512KB to the COREBOOT FMAP regionJulius Werner
With the new extra detachable UI elements, we're running out of space in Scarlet's RO CBFS. Thankfully, the GBB is still massively overdimensioned, so we can steal another half MB from there. This patch changes the FMAP for some boards that have already had production firmware releases. However, all the new changes are to the RO parts of the FMAP, so there shouldn't be a way this could cause a problem for updates. Change-Id: Iec182de3e894e56fec2a64b034c0ca65d78a5522 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/23595 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-02-02google/gru: Use newer version of Innolux P097PFG panel init codeLin Huang
There is a line artifact in the lower third of the display with the current initialization code. So update it with code provided by Innolux to fix this issue. BUG=b:69689064, b:72191820 TEST=boot on dru with an Innolux panel and artifact line disappear. Change-Id: I9679c4f7f706fd6cd2e1dba7ec79e772fe3f227a Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-01-29google/scarlet: Add initialization sequence for Innolux P097PFG panelLin Huang
Innolux didn't deliver a working init sequence yet for devices without OTP programming. The sequence in this change has been derived from a register dump of a mostly working panel with OTP. It is not meant to be final, but to make devices with unprogrammed OTP work, while Innolux is figuring out a proper sequence. There is a known issue with an artifact line in the lower third of the display. Change-Id: I7096506208e4cb29c5f31a7ac502231a6c23ac92 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23311 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-01-29rockchip/rk3399: Support LONG_WRITE type in MIPI DSILin Huang
Some panels need to transfer initial code, and some of them will be over 3 bytes, so support LONG_WRITE type in driver. Refactor mipi dsi transfer function to support it. Change-Id: I212c14165e074c40a4a1a25140d9e8dfdfba465f Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/23299 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-01-18security/tpm: Change TPM naming for different layers.Philipp Deppenwiese
* Rename tlcl* to tss* as tpm software stack layer. * Fix inconsistent naming. Change-Id: I206dd6a32dbd303a6d4d987e424407ebf5c518fa Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/22104 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-18security/tpm: Move tpm TSS and TSPI layer to security sectionPhilipp Deppenwiese
* Move code from src/lib and src/include into src/security/tpm * Split TPM TSS 1.2 and 2.0 * Fix header includes * Add a new directory structure with kconfig and makefile includes Change-Id: Id15a9aa6bd367560318dfcfd450bf5626ea0ec2b Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org> Reviewed-on: https://review.coreboot.org/22103 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2018-01-08google/gru: switch to spi2 for all scarlet based boardsEge Mihmanli
Rainier, a scarlet derived board, was configured to use spi0 for tpm driver by default. This patch switches it to spi2 to reflect recent changes in scarlet-derived boards. Change-Id: Ib67109786512c068bb957890f456bccff7addc86 Signed-off-by: Ege Mihmanli <egemih@google.com> Reviewed-on: https://review.coreboot.org/23129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-12-20google/gru: Adjust to incorrect strapping resistors on KevinJulius Werner
It seems that RAM code 0 has been strapped with an incorrect resistor on Kevin. The resulting voltage divide still puts it well within the ADC value bucket reserved for that slot, but a little closer to the edge than necessary. While this doesn't seem to cause any immediate problems on its own, it still doesn't hurt to fix it (if only for the documentation value). On other boards (at least on my Scarlet) the strapping seems to be correct. Change-Id: Ic5199834fbeaf734e725ff45b04f45eefe149855 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22891 Reviewed-by: David Schneider <dnschneid@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-12-20google/gru: Prettify strapping ID ADC tableJulius Werner
This patch shifts some comments around to make it easier to replace values in the ADC strapping bucket table with compile-time conditionals. Change-Id: Ic51917d3961a51d4e725ff824fb59aeefe149855 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22890 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-12-12google/scarlet: support INNOLUX P097PFG panelLin Huang
Add INNOLUX P097PFG panel timing. According to Scalet schematic, if GPIO3_D4 get low status, it will use INNOLUX P097PFG panel; if GPIO3_D4 get high status, it will use KD097d04 panel. Change-Id: I43fa5d859a9a529a84c58a953b37d03953ce648a Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22780 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-12-11google/gru: Stop mucking with unused I2S0 pins in codec configJulius Werner
Due to a schematic error, our code was written to configure more I2S0 pins than are actually used. We're also pinmuxing the whole bank of pins over to the I2S controller even though we don't need them all. Restrict the GPIO initialization and pinmuxing to the pins we really need so the other ones can be correctly used as SKU ID pins on Scarlet. Also, move the "audio" IO voltage domain selection to the other such selections in the bootblock, since that covers two whole banks of GPIOs and there's no guarantee that they're all used for audio (and thus not needed before ramstage). BUG=b:69373077 TEST=Booted Scarlet, confirmed correct SKU ID (7) was detected on rev2. Change-Id: I9314617e725fe83d254984529f269d4442e736f1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22791 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-12-11google/gru: Change Scarlet SKU ID pins to pull-upsJulius Werner
These pins need to be pull-ups. I forgot. BUG=b:69373077 Change-Id: I9314617e01d35898254984529f269d4442e736f1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22775 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-07google/scarlet: update Kingdisplay kd097d04 timingLin Huang
With the old timing, the hblank time isn't large enough, it may cause display artifacts. So fix it. BUG=b:70160653 TEST=panel work on Scarlet rev2 board Change-Id: Ib061f5e215611d20f59e3f24cfe3c7fbc507ebed Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22746 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-12-07google/gru: Add SKU ID for ScarletJulius Werner
Scarlet has SKU detection strapping pins now. This patch adds the code to read them. BUG=b:69373077 Change-Id: I8d889a845950923bc7b5be9b79792cf3c8b6b8ad Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22697 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-07boardid: Switch from Kconfig to weak functionsJulius Werner
This patch switches the board_id and ram_code helper framework to use weak functions rather than Kconfigs to determine whether the board supplies these IDs. This cuts down on the amount of boilerplate Kconfigs many boards have to set and also gives them more flexibility, such as being able to determine at runtime whether a given ID is present. Change-Id: I97d6d1103ebb2a2a7cf1ecfc45709c7e8c1a5cb0 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22695 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-07boardid: Minor clean up and standardizationJulius Werner
Merge the different coreboot table strapping ID structures into one because they're really just all the same, and I want to add more. Make the signature of the board_id() function return a uint32_t because that's also what goes in the coreboot table. Add a printk to the generic code handling strapping IDs in ramstage so that not every individual mainboard implementation needs its own print. (In turn, remove one such print from fsp1_1 code because it's in the way of my next patch.) Change-Id: Ib9563edf07b623a586a4dc168fe357564c5e68b5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22741 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-12-05google/gru: update RAMID tableLin Huang
There is some confusion with old RAMID table, make it clear, and let's no longer tangle it in future. Change-Id: I44215b4a6668074575a5df691ac1ff8fa3d15492 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22663 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28google/scarlet: support kd097d04 panelLin Huang
Support kd097d04 dual mipi panel on Scarlet. Change-Id: Ie8bc0cbb79840f1924a8cc111f2511292203731f Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22472 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28google/gru: correct backlight gpioLin Huang
it uses backlight enable pin as backlight gpio currently, correct it and define the right backlight gpio. Change-Id: I7c5abfd5bbbae015b899f3edc8892ea32bf82463 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22529 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-28rockchip/rk3399: support dual mipi dsiLin Huang
Refactor the mipi driver, so we can support dual mipi panel. And pass the panel data from mainboard.c, that we can support different panel with different board. Change-Id: Id1286c0ccbe50c89514c8daee66439116d3f1ca4 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/22471 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-22google/gru: Add support for rainierEge Mihmanli
Rainier is a scarlet-derived board but uses eDP as opposed to MIPI. Using GRU_BASEBOARD_SCARLET is enough, except for display related logic. In those cases, use board specific logic instead of baseboard. Change-Id: I596f7ca6bc26312ecaeb261c96cebd46974c2cdf Signed-off-by: Ege Mihmanli <egemih@google.com> Reviewed-on: https://review.coreboot.org/22542 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-20google/gru: Add config for scarlet-derived boardsEge Mihmanli
There is merit in having new boards use the pinouts and controls in scarlet. This adds a config so new scarlet-derived boards can easily use scarlet structure without going through every file and adding new logic. TEST=Run "emerge-scarlet coreboot" Signed-off-by: egemih@chromium.org Change-Id: I5808f93f4563033ce93050e1eedb6eac2b52c3b3 Reviewed-on: https://review.coreboot.org/22517 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-11-17mb/google: Add Chromebook marketing namesJonathan Neuschäfer
It's sometimes hard to find the code name of a Chromebook. Add the marketing names to Kconfig, since they are easily available. Information (mostly) taken from: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Unknown boards (unreleased, etc.): * Fizz * Foster * Nasher, Coral * Purin * Rotor * Rowan * Scarlet, Nefario * Soraka * Urara * Veyron_Rialto Baseboards: * Glados * Gru * Jecht * Kahlee * Nyan * Oak * Poppy * Rambi * Zoombini White label boards: * Enguarde * Heli * Relm, Wizpig TODO: How does this interact with the board_status code? Change-Id: I20a36e23bd3eea8c526a0b3b53cd676cebf9cd86 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/22404 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2017-11-06gru: Fix and export SPK_PA_EN GPIO for ScarletJulius Werner
On older Grus, GPIO0_A2 was an audio voltage rail enable line. On Scarlet, we instead moved the audio codec enable (previously on GPIO1_A2) there. Unfortunately the code still had some hardcoded leftovers that were overlooked in the initial port and make our speakers smell weird. This patch fixes the incorrect GPIO settings and adds the speaker enable pin to the GPIOs passed through the coreboot table, so that depthcharge doesn't have to keep its own definition of the pin which may go out of sync. Change-Id: I1ac70ee47ebf04b8b92ff17a46cbf5d839421a61 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/22323 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-10-02google/gru: Fix pmu1833_volsel handlingJulius Werner
RK3399 has a pin that can decide whether GPIO port 1 is driven with 1.8V or 3.0V. We thought this mechanism was disabled by default, but it turns out it wasn't. We want to use that pin as an output GPIO on Scarlet so we need to reconfigure the respective SoC controls before we do that. It seems that we also need to explicitly pinmux the pin away from that special function (to normal GPIO) or weird things happen on some boards. BUG=b:66534913 TEST=Sprinkled several long udelays, poked test points with a multi-meter on Scarlet. Change-Id: Ia02cbb4f3b2f14b0d958b84adcddb0c5f4259efa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/21727 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-09-06google/gru: Re-enable 3V rail GPIO on ScarletJulius Werner
We've decided to move control for the 3.0V rail (technically 3.3V on Scarlet, but who cares about millivolts) back to a GPIO on the AP for Scarlet rev2. This patch adds the necessary code to enable it and make ARM TF aware of its existence. Since the pin had previously not been connected to anything, we shouldn't really need to guard this by board ID... older Scarlets will just be twiddling an empty pin. Change-Id: I6037aa486b50119f2c7b859b966cadc3686e3459 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/21328 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-08-31google/gru: Support Nefario rev0Philip Chen
Do not assert GPIO1_B3 otherwise BT would be disabled on Nefario. Also, remove DVS support for CENTERLOGIC. BUG=b:64702054, b:63537905 TEST=build coreboot Change-Id: I350db2c080f2e41ae56413f5f895557978ef0ba8 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/21176 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-08-18include/device: Split i2c.h into threeNico Huber
Split `i2c.h` into three pieces to ease reuse of the generic defi- nitions. No code is changed. * `i2c.h` - keeps the generic definitions * `i2c_simple.h` - holds the current, limited to one controller driver per board, devicetree independent I2C interface * `i2c_bus.h` - will become the devicetree compatible interface for native I2C (e.g. non-SMBus) controllers Change-Id: I382d45c70f9314588663e1284f264f877469c74d Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/20845 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-08-06rockchip: gpio: add gpio_pull argument in gpio_input_irq() functionLin Huang
some gpio irq need to set input pull initialization status to guarantee to get the right irq trigger. let's add this argument in gpio_input_irq() function BRANCH=None BUG=None TEST=boot from bob Change-Id: I9b8e6497f07146dafdb447a6ea10d039a2a2fa33 Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/20866 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-08-01google/gru: Correct Scarlet pwm regulator minimum value and maximum valueLin Huang
In Scarlet pwm regulatoror minimum value and maximum value differs from other board variants, Correct it so we can get the right voltage. Change-Id: I1f722eabb697b3438d9f4aa29c205b0161eb442a Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/20831 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-08-01google/gru: Correct the Sdcard control gpio setting for ScarletLin Huang
in Scarlet the Sdcard control gpio differs from other board variants, So set the GPIO to high on Scarlet. Change-Id: I5fa19b212a716213462eea58b6242392d32a2c5c Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/20803 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-08-01google/gru: Use 1.8V powerdomain for gpio4cd on ScarletLin Huang
Scarlet gpio4cd use 1.8V powerdomain, let's make a correct register setting, otherwise even the uart does not work. Change-Id: Ib5a8b2a4d92502fb829688d0a3e1b645d53cd7fc Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/20802 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-07-19google/gru: Add support for Scarlet rev1Julius Werner
This patch adds the necessary changes to support Scarlet revision 1. Since the differences to revision 0 are so deep, we have decided not to continue support for it in the same image. Therefore, this patch will break Scarlet rev0. All the deviations from other Gru boards are currently guarded by CONFIG_BOARD_GOOGLE_SCARLET. This should be changed later if we introduce more variants based on the newer Scarlet board design. Change-Id: I7a7cc11d9387ac1d856663326e35cfa5371e0af2 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/20587 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: David Schneider <dnschneid@chromium.org>
2017-07-19rockchip/rk3399: Adjust gpio_t format to match ARM TFJulius Werner
Our structure packing for Rockchip's gpio_t was chosen arbitrarily. ARM Trusted Firmware has since become a thing and chosen a slightly different way to represent GPIOs in a 32-bit word. Let's align our format to them so we don't need to remember to convert the values every time we pass them through. CQ-DEPEND=CL:572228 Change-Id: I9ce33da28ee8a34d2d944bee010d8bfc06fe879b Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/20586 Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2017-07-12google/gru: Add NefarioPhilip Chen
There will be more follow-up changes. BUG=b:63537905 BRANCH=None TEST=emerge-nefario coreboot libpayload Change-Id: I6bb80723ea2573df617026a4a5740adb89331892 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/20522 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-06-19rockchip/rk3399: fix DRAM gate training issueLin Huang
The differential signal of DQS needs to keep low level before gate training. RPULL will connect 4Kn from PADP to VSS and a 4Kn from PADN to VDDQ to ensure it. But if it has PHY side ODT connected at this time, it will change the DQS signal level. So it needs to disable PHY side ODT when doing gate training. BRANCH=None BUG=None TEST=boot from bob Change-Id: I56ace8375067aa0bb54d558bc28172b431b92ca5 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Original-Commit-Id: cb024042c7297a6b17c41cf650990cd342b1376f Original-Change-Id: I33cf743c3793a2765a21e5121ce7351410b9e19d Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/448278 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org> Reviewed-on: https://review.coreboot.org/18582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-06-15google/gru: drive the stronger pull-up for touchpadCaesar Wang
As the hardware designed on gru, the AP_I2C_TP_PU_EN (gpio3_b4) controlled the SCL/SDA status to avoid leakage. And the gpio3_b4 of rk3399 pull resistor is 26k~71k and 3.3v for supply power, and gpio3_b4 pin connected 2.2k resistor to i2c of TP device. The default of this gpio status is pulled up during the start to bootup, it's very weak drive for the TP device that maybe cause to trigger the recovery process of elan's firmware. Also, the Elan updated its firmware(102.0.5.0) to delay checking the i2c of touchpad is greater than 1 second. So we have to drive the stronger pull-up within 1 second of powering up the touchpad to prevent its firmware from falling into recovery. Change-Id: I9a67d1c041afafde24ed9f00716ba41a9b41a8da Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-on: https://review.coreboot.org/19863 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-06-13Consolidate reset API, add generic reset_prepare mechanismJulius Werner
There are many good reasons why we may want to run some sort of generic callback before we're executing a reset. Unfortunateley, that is really hard right now: code that wants to reset simply calls the hard_reset() function (or one of its ill-differentiated cousins) which is directly implemented by a myriad of different mainboards, northbridges, SoCs, etc. More recent x86 SoCs have tried to solve the problem in their own little corner of soc/intel/common, but it's really something that would benefit all of coreboot. This patch expands the concept onto all boards: hard_reset() and friends get implemented in a generic location where they can run hooks before calling the platform-specific implementation that is now called do_hard_reset(). The existing Intel reset_prepare() gets generalized as soc_reset_prepare() (and other hooks for arch, mainboard, etc. can now easily be added later if necessary). We will also use this central point to ensure all platforms flush their cache before reset, which is generally useful for all cases where we're trying to persist information in RAM across reboots (like the new persistent CBMEM console does). Also remove cpu_reset() completely since it's not used anywhere and doesn't seem very useful compared to the others. Change-Id: I41b89ce4a923102f0748922496e1dd9bce8a610f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19789 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-06-08device/Kconfig: Introduce MAINBOARD_FORCE_NATIVE_VGA_INITNico Huber
MAINBOARD_FORCE_NATIVE_VGA_INIT is to be selected instead of the user option MAINBOARD_DO_NATIVE_VGA_INIT. The distinction is necessary to use the latter in a choice. Change-Id: I689aa5cadea9e1091180fd38b1dc093c6938d69c Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/19813 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-05-18google/scarlet: Enable innolux,p079zca MIPI panelNickey Yang
TEST=Boot from scarlet, and mipi panel works Change-Id: I52f8f8f966034f5273d7c2e673e5ebdd9dccf748 Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Reviewed-on: https://review.coreboot.org/19700 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-11google/gru: support 800M/928M frequency for bobCaesar Wang
The coreboot had no supported the different frequency for gru yet. e.g: we can't support the bob to run ddr 800M for rev3 board and run 928M for rev4 board. So, in order to support the 800M and 928M ddr frequency for bob different boards. We will use the ram_id and board_id to select the board on bob. Change-Id: I613050292a09ff56f4636d7af285075e32259ef4 Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-on: https://review.coreboot.org/19558 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-11rockchip/rk3399: enable DPLL SSC for DDR EMI test on bobCaesar Wang
Spread Spectrum Modulator (SSMOD) is a fully-digital circuit used to modulate the frequency of the Silicon Creations’ Fractional PLL in order to reduce EMI. We need to turn the DPLL spread spectrum feature on to reduce the EMI noise for DDR on bob. Change-Id: I75461d4235bcf55324e6664a1220754e770b4786 Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-on: https://review.coreboot.org/19557 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-05Revert "google/scarlet: Enable innolux,p079zca MIPI panel"Martin Roth
This reverts commit 39b633b26d6d4cf185fbbdd5a256d0665409bd5b. Commit was accidentally pushed too early and broke the tree. I'll repush the original. Change-Id: Iaca6d43cc8fc0959565d5d151a330c0c7ba38309 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/19596 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-05google/scarlet: Enable innolux,p079zca MIPI panelNickey Yang
TEST=Boot from scarlet, and mipi panel work Change-Id: Id5f81867ea50f72cc0bc13074627134e0dc198ba Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Reviewed-on: https://review.coreboot.org/19476 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-03google/gru: skip usbphy1 setup for Scarletphilipchen
Board Scarlet doesn't use usbphy1. BUG=b:37685249 TEST=boot Scarlet, check the firmware log, and confirm no errors about USB1 Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/19489 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-04-28google/gru: tpm on bob: cr50: add irq clear/irq status for tpm irqJeffy Chen
BUG=b:35647967 TEST=boot from bob Change-Id: I756513f02ac13e159d5b8b1ac2346fa42cf3c219 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cf18ed7b8fdf11594f812e5c48a2bd0fde5cb820 Original-Change-Id: I50c053ab7a6f6c14daee4fb2ab1cdcaeee2d67da Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/452286 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19434 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2017-04-25google/gru: change the sd power sequenceCaesar Wang
In the safety considerations, we should make sure the slot of SD is enabled first, since we want to the power switch of corresponding is powered up. The different boards have the different power switch for sdmmc. Some power switch IC need turn on delay for long time. let's move the slot power of SD to romstage and avoid explicit delays or per-board. BRANCH=none BUG=b:35813418, b:35573103 TEST=check the signal for children of gru, and boot up from sd card. Change-Id: Id164e4c4c900c6b1ca0251fc27db4cd36c56f6ff Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ea1b01cc13628033b85251dbb44407f075efdc85 Original-Change-Id: I48ab543143d3de9be46608fc12d78e09decf8d79 Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/447076 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19430 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-04-24Kconfig: provide MAINBOARD_HAS_TPM_CR50 optionAaron Durbin
The CR50 TPM can do both SPI and I2C communication. However, there's situations where policy needs to be applied for CR50 generically regardless of the I/O transport. Therefore add MAINBOARD_HAS_TPM_CR50 to encompass that. Additionally, once the mainboard has selected CR50 TPM automatically select MAINBOARD_HAS_TPM2 since CR50 TPM is TPM 2.0. Change-Id: I878f9b9dc99cfb0252d6fef7fc020fa3d391fcec Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/19370 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2017-04-19google/gru: change kevin boot-time center logic voltage to 925mVDouglas Anderson
Kevin's center logic isn't super clean so it needs 925 mV for center logic. All newer gru variants only need 900 mV. BRANCH=gru BUG=b:37429075 TEST=Reboot tests Change-Id: I8c3bd6c245700b23c27cd5758c35c9993f801cb4 Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/479463 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19357 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-04-19google/gru: change center logic voltage to 900mVDerek Basehore
It seems that we should only ever run at 900mV on center logic. Changing it to 950mV before might have just masked over problems that are now fixed. BRANCH=none BUG=chrome-os-partner:56940 TEST=on kevin, run stressapptest -M 1536 -s 1000 Change-Id: I5a09b1b403df800396bb2f2e8c76d14a4519d44a Signed-off-by: Derek Basehore <dbasehore@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/391032 Reviewed-by: Douglas Anderson <dianders@chromium.org> Commit-Queue: Lin Huang <hl@rock-chips.com> Tested-by: Lin Huang <hl@rock-chips.com> Reviewed-on: https://review.coreboot.org/19356 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2017-04-11scarlet/gru: skip display because mipi driver not readyShunqian Zheng
Scarlet don't have eDP and MIPI driver is not ready, skipping display for now or else Scarlet would be stuck in reading eDP HPD because there even not power for it. TEST=boot to kernel on Scarlet Change-Id: I02ab4ef21bf77b98414f537aca57b46c11922348 Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-on: https://review.coreboot.org/19237 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-04-06gru: Initialize I2C bus for ARC2C0608Philip Chen
BUG=b:35583511 TEST=check i2c bus 0 initializes from ap console log Change-Id: Ibb6709159f5ed28ad0b62397d2ddb504dec55167 Signed-off-by: Philip Chen <philipchen@google.com> Reviewed-on: https://review.coreboot.org/19105 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-03-28vboot: Move remaining features out of vendorcode/google/chromeosJulius Werner
This patch attempts to finish the separation between CONFIG_VBOOT and CONFIG_CHROMEOS by moving the remaining options and code (including image generation code for things like FWID and GBB flags, which are intrinsic to vboot itself) from src/vendorcode/google/chromeos to src/vboot. Also taking this opportunity to namespace all VBOOT Kconfig options, and clean up menuconfig visibility for them (i.e. some options were visible even though they were tied to the hardware while others were invisible even though it might make sense to change them). CQ-DEPEND=CL:459088 Change-Id: I3e2e31150ebf5a96b6fe507ebeb53a41ecf88122 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18984 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-28vboot: Assume EC_SOFTWARE_SYNC and VIRTUAL_DEV_SWITCH by defaultJulius Werner
The virtualized developer switch was invented five years ago and has been used on every vboot system ever since. We shouldn't need to specify it again and again for every new board. This patch flips the Kconfig logic around and replaces CONFIG_VIRTUAL_DEV_SWITCH with CONFIG_PHYSICAL_DEV_SWITCH, so that only a few ancient boards need to set it and it fits better with CONFIG_PHYSICAL_REC_SWITCH. (Also set the latter for Lumpy which seems to have been omitted incorrectly, and hide it from menuconfig since it's a hardware parameter that shouldn't be configurable.) Since almost all our developer switches are virtual, it doesn't make sense for every board to pass a non-existent or non-functional developer mode switch in the coreboot tables, so let's get rid of that. It's also dangerously confusing for many boards to define a get_developer_mode() function that reads an actual pin (often from a debug header) which will not be honored by coreboot because CONFIG_PHYSICAL_DEV_SWITCH isn't set. Therefore, this patch removes all those non-functional instances of that function. In the future, either the board has a physical dev switch and must define it, or it doesn't and must not. In a similar sense (and since I'm touching so many board configs anyway), it's annoying that we have to keep selecting EC_SOFTWARE_SYNC. Instead, it should just be assumed by default whenever a Chrome EC is present in the system. This way, it can also still be overridden by menuconfig. CQ-DEPEND=CL:459701 Change-Id: If9cbaa7df530580a97f00ef238e3d9a8a86a4a7f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18980 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-09drivers/spi/tpm: provide Kconfig to indicate CR50 usageAaron Durbin
Going forward it's important to note when a CR50 is expected to be present in the system. Additionally, this Kconfig addition provides symmetry with the equivalent i2c Kconfig option. BUG=b:35775104 Change-Id: Ifbd42b8a22f407534b23459713558c77cde6935d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/18680 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2017-03-07google/gru: add MAX_SDRAM_FREQ config to choose max ddr freqShunqian Zheng
Gru/Kevin use 933 MHz (actually 928 MHz for better jitter) as max sdram frequency, while bob uses 800 MHz. It's normal some variants can't meet 928 MHz SI requirement and hence have to use a lower freq as spec. BUG=chrome-os-partner:61001 BRANCH=gru TEST=check dpll is 800 MHz on bob Change-Id: I6d19a351f25d1f48547715ce57c3a87d9505f6f1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8176bfea52422c713f144ffec419752aeca66db2 Original-Change-Id: I46afba8d091f1489feeb20cafc44decaa81601fc Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/420208 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Shasha Zhao <Sarah_Zhao@asus.com> Original-Tested-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-(cherry picked from commit eba5dff79eeedae5ff608d2d8d297ccf9c13cb55) Original-Reviewed-on: https://chromium-review.googlesource.com/448277 Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org> Reviewed-on: https://review.coreboot.org/18581 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-23google/gru: whitespace fixPatrick Georgi
Follow up to https://review.coreboot.org/#/c/18460/ Change-Id: Ic3aada2acf3051622698e10d2e764050e16480d5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/18475 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-23google/gru: Tuning USB 2.0 PHY0 and PHY1 squelch detection thresholdWilliam wu
According to USB 2.0 Spec Table 7-7, the High-speed squelch detection threshold Min 100mV and Max 150mV, and we set USB 2.0 PHY0 and PHY1 squelch detection threshold to 150mV by default, so if the amplitude of differential voltage envelope is < 150 mV, the USB 2.0 PHYs envelope detector will indicate it as squelch. On Kevin board, if we connect usb device with Samsung U2 cable, we can see that the impedance of U2 cable is too big according to the eye-diagram test report, and this cause serious signal attenuation at the end of receiver, the amplitude of differential voltage falls below 150mV. This patch aims to reduce the PHY0 and PHY1 otg-ports squelch detection threshold to 125mV (host-ports still use 150mV by default), this is helpful to increase USB 2.0 PHY compatibility. BRANCH=gru BUG=chrome-os-partner:62320 TEST=Plug Samsung U2 cable + SEC P3 HDD 500GB/Galaxy S3 into Type-C port, check if the USB device can be detected. Change-Id: Ia0a2d354781c2ac757938409490f7c4eecdffe61 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7d74311c25762668386061234df0562f84b7203e Original-Change-Id: Ib20772f8fc2484d34c69f5938818aaa81ded7ed8 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/431015 Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18462 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2017-02-23google/gru: update the pwm regulatorCaesar Wang
As David commented the "Bob and other follow-ons match Gru, Kevin should be the special case here", and update the calculations value for gru/bob board. From the actual tests, some regulator voltage than the actual set of less than 20mv on bob board. (e.g: little-cpus and Center-logic) Update the {min, max} regulator voltage for Bob board. Make sure we get the accurate voltage. BUG=chrome-os-partner:61497 BRANCH=none TEST=boot up Bob, measure the voltage for little cpu and C-logic. Change-Id: Iad881b41d67708776bfb681487cf8cec8518064e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 25e133815f49018e7496c75077b8559c207350a4 Original-Change-Id: I3098c742c7ec355c88f45bd1d93f878a7976a6b4 Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/424523 Original-Reviewed-by: David Schneider <dnschneid@chromium.org> Original-Reviewed-by: Brian Norris <briannorris@chromium.org> Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/430403 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18460 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-23google/gru: improve eye diagram for passing the testCaesar Wang
The children of Gru should share the benefits. In the real world, Bob can't pass the eye diagram tests. BUG=chrome-os-partner:62714 BRANCH=firmware-gru-8785.B TEST=build coreboot Change-Id: I2470bbc81acdaf2458d660dca5dc307cc3038f83 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d0cb3e718a7571f602a00c08a42019851634e7fd Original-Change-Id: I0ccb48bb52eb770ccc9c8c265b07df46b0308dd3 Original-Signed-off-by: Caesar Wang <wxt@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/440745 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/441468 Reviewed-on: https://review.coreboot.org/18461 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-22google/gru: Fix whitespacePatrick Georgi
Change-Id: I538c28fb1bc412947ef9df947fa3f6a3312aeb4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/18322 Tested-by: build bot (Jenkins) Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-11google/gru: add scarlet variantphilipchen
There will be more follow-up changes. BUG=chrome-os-partner:62377 BRANCH=None TEST=emerge-scarlet coreboot libpayload Change-Id: I9ca45598ff0ab12bf8063d16a86be564cf509390 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a020a9ba1228b15599e202972df0096f58b1b31c Original-Change-Id: I4804239483f8b35bc3703aa62c2a8fd642e0234a Original-Signed-off-by: philipchen <philipchen@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/433039 Original-Commit-Ready: Philip Chen <philipchen@chromium.org> Original-Tested-by: Philip Chen <philipchen@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18296 Tested-by: build bot (Jenkins) Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
2017-01-22gru: kevin: define GPIOs used on both platformsVadim Bendebury
The same GPIOs are used on both platforms, definitions are added an a new .h to make it easier to re-use them across the code. BRANCH=none BUG=chrome-os-partner:51537 TEST=panel backlight still enabled on Gru as before. The rest of the GPIOs are used in the upcoming patches. Change-Id: I54ef3e8dd79670bdb037baeec91430113d11bcc1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c58788026f28af52c650da0159b93d97269ca4a9 Original-Change-Id: I1a6c5b5beb82ffcc5fea397e8e9ec2f183f4a7e0 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/346219 Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-on: https://review.coreboot.org/18176 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-13gru: Tuning USB 2.0 PHY0 and PHY1 host-portWilliam wu
The commit 0ba3b2593b0c ("gru: Tuning USB 2.0 PHY to increase compatibility") bypass ODT to set the max driver strength for the Type-C otg-port, it works well on otg-port when connected with USB2.0 devices. Unfortunately, because the Type-C otg-port and host-port are consisted in one USB2 PHY, so bypass ODT will have an effect on both host-port and otg-port. I have tested the host-port eye-diagram, the result shows that if we bypass ODT, the host- port eye-diagram height will become to high, more than 500mv, this may cause USB 2.0 high-speed enumeration failure. This patch bypass ODT for host-port separately, and then we can reduce the host-port driver strength without affecting the otg-port driver strength. BRANCH=gru BUG=chrome-os-partner:60727 TEST=Boot system, run 'lsusb' command and check if the usb camera and usb bluetooth are on usb 2.0 hub or usb 1.1 hub. If they are on usb 1.1 hub, the issue happens. If not, try to run camera app and then close camera app, repeat until find that the usb camera is on the usb 1.1 hub. Change-Id: Ib693e2a6f2113c06692a7bfee22d85b67ee3b165 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5ea7660b7b05080b76fc5ca5af3fa18552a03491 Original-Change-Id: Ia1f12182929673c5726df9f77f0903469b5c957a Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/425739 Original-Commit-Ready: Douglas Anderson <dianders@chromium.org> Original-Tested-by: Douglas Anderson <dianders@chromium.org> Original-Tested-by: Inno Park <ih.yoo.park@samsung.com> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/18126 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06Bob: Update the memory ramid of bobShasha Zhao
Update the memory ramid. Move to one CA training pattern. BUG=chrome-os-partner:59454 BRANCH=firmware-gru-8785.B TEST=Build firmware passed Change-Id: Ic05cbc1700a13e372f63d5202459add0e984f9d8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1030a78af3d489d13508f17a79df1e65bd5afa3b Original-Change-Id: Ibe8acb5b698cec1adcdddbb13d35a5e20a5b8c0d Original-Reviewed-on: https://chromium-review.googlesource.com/414664 Original-Commit-Ready: Shasha Zhao <Sarah_Zhao@asus.com> Original-Tested-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Change-Id: I0ae46e496cd18492a2b6c7167081798c2f2479b1 Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/411645 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17679 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06Bob: add bob in corebootShasha Zhao
Add bob in coreboot and update as necessary. 1. Add bob HWID 2. Add supported memory source BUG=chrome-os-partner:59454 BRANCH=firmware-gru-8785.B TEST=Build firmware passed Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Change-Id: Iad03a293bdbbb89450f0fea0822e34a4be7064bf Original-Commit-Id: bff788c71a43403bff2c23b38e69cc27fb869559 Original-Change-Id: I0dcf47eb911337b176f73759a2c70a9dbf4dc68b Original-Signed-off-by: Shasha Zhao <Sarah_Zhao@asus.com> Original-Reviewed-on: https://chromium-review.googlesource.com/411083 Original-Reviewed-by: Philip Chen <philipchen@chromium.org> Original-(cherry picked from commit c5925dfcf59ac755a26182744b2bde59e41a37cf) Original-Reviewed-on: https://chromium-review.googlesource.com/413744 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17678 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06rockchip/rk3399: sdram: use register to calculate sdram sizesLin Huang
We may support different sdram sizes on one board in future, so we need to calculate sdram sizes from sdram drvier. BRANCH=None BUG=None TEST=boot kevin Change-Id: I43e8f164ecdb768c051464b4dbc7d890df8055d0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3c4d8b3cb647b2f9cebc416c298817c16d49330e Original-Change-Id: I95d5ef34de9d79ebca3600dc7a4b9e14449606ff Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/411600 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17629 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-06google/gru: Power-cycle USB ports in developer/recovery modesJulius Werner
Gru only uses USB 2.0 in firmware to avoid all the madness associated with Type-C port orientation and USB 3.0 tuning. We do this by isolating the SuperSpeed lines in the Type-C PHY so it looks like they aren't connected to the device. Unfortunately, some devices seem to already get "locked" into SuperSpeed mode as soon as they detect Rx terminations once, and can never snap out again on their own. Since the terminations are already connected during power-on reset we cannot disable them fast enough to prevent this, and the only solution we found to date is to power-cycle the whole USB port. Now, Gru's USB port power is controlled by the EC, and unfortunately we have no direct host command to control it. We do however have a command to force a certain USB PD "role", and forcing our host into "sink" mode makes it stop sourcing power to the port. So for lack of a saner solution we'll use this to work around our problem. BRANCH=gru BUG=chrome-os-partner:59346 TEST=Booted Kevin in recovery mode, confirmed that my "problem stick" gets detected immediately (whereas previously I had to unplug/replug it). Booted Kevin to OS in both developer and normal mode and confirmed that USB still seems to work. Change-Id: Ib3cceba9baa170b13f01bd5c01bd413be5b441ba Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: cd695eda33299e50362f1096c46f2f5260c49036 Original-Change-Id: I2db3d6d3710d18a8b8030e94eb1ac2e931f22638 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/413031 Reviewed-on: https://review.coreboot.org/17628 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-01lib: put romstage_handoff implementation in own compilation unitAaron Durbin
Instead of putting all the functions inline just put the current implementation into a C file. That way all the implementation innards are not exposed. Lastly, fix up the fallout of compilation units not including the headers they actually use. Change-Id: I01fd25d158c0d5016405b73a4d4df3721c281b04 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17648 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-11-29google/gru: Tune USB 2.0 PHY to increase compatibilityWilliam wu
When testing USB 2.0 compatibility with different kinds of USB 2.0 devices on Kevin board, we find that some USB HDDs (e.g. seagate SRD00F1 1TB HDD) and some smart phones (e.g. galaxy A5 smart phone) can't be detected. And according to the error log, this issue is related to USB 2.0 PHY signal problem. For the USB HDD, error log is: [ 592.557724] usb 5-1: new high-speed USB device number 2 using xhci-hcd [ 592.847735] usb 5-1: new high-speed USB device number 3 using xhci-hcd [ 593.473720] usb 5-1: new high-speed USB device number 6 using xhci-hcd [ 594.187717] usb 5-1: new high-speed USB device number 9 using xhci-hcd [ 595.020717] usb 5-1: new high-speed USB device number 13 using xhci-hcd [ 595.284730] usb 5-1: new high-speed USB device number 14 using xhci-hcd [ 595.574816] usb 5-1: new high-speed USB device number 15 using xhci-hcd The log shows that HDD failed to high-speed handshake. For the smart phone, error log is: [ 1145.661625] usb 5-1: new high-speed USB device number 2 using xhci-hcd [ 1145.771674] usb 5-1: device descriptor read/64, error -71 [ 1145.979752] usb 5-1: device descriptor read/64, error -71 [ 1146.187721] usb 5-1: new high-speed USB device number 3 using xhci-hcd [ 1146.301754] usb 5-1: device descriptor read/64, error -71 [ 1146.509750] usb 5-1: device descriptor read/64, error -71 [ 1146.717722] usb 5-1: new high-speed USB device number 4 using xhci-hcd [ 1146.724393] usb 5-1: Device not responding to setup address. [ 1146.930795] usb 5-1: Device not responding to setup address. [ 1147.137720] usb 5-1: device not accepting address 4, error -71 [ 1147.246644] usb 5-1: new high-speed USB device number 5 using xhci-hcd [ 1147.253336] usb 5-1: Device not responding to setup address. [ 1147.459786] usb 5-1: Device not responding to setup address. [ 1147.665712] usb 5-1: device not accepting address 5, error -71 [ 1147.671789] usb usb5-port1: unable to enumerate USB device The log shows that smart phone failed to read device descriptor, error -71 may be caused by PHY signal problem. This patch aims to tune USB 2.0 PHY with the following parameters to support USB HDD, smart phone and some other potential USB 2.0 devices. 1. Disable the pre-emphasize in chirp state to avoid high-speed handshake failure. 2. Bypass ODT auto compensation to enable set max driver strength manually. (Bit[42] of usbphy_ctrl register is 1'b1 for bypass, and Bit[41:37] of usbphy_ctrl register is 5'b10000 for max driver strength). 3. Bypass ODT auto refresh, and set the max bias current tuning reference. (Bit[57] of usbphy_ctrl register is 1'b1 for bypass, and Bit[52:50] of usbphy_ctrl register is 3b'100 for max bias current tuning reference). We have done the USB 2.0 compliance test and compatibility test with this patch, it works well. BRANCH=gru BUG=chrome-os-partner:59623 TEST=plug/unplug USB HDD or smart phone in Type-C port, check if they can be detected successfully. Change-Id: I275c2236b8e469bfd04e9184d007eb095657225e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 7735c514d4136978133c2299f2f58da8320bb89f Original-Change-Id: I4e6c10faa1c03af9880a89afe4731a7065eb1e4e Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/409856 Original-Commit-Ready: Eddie Cai <eddie.cai.rk@gmail.com> Original-Tested-by: Cindy Han <cindy.han@samsung.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17566 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-18google/chromeec: Add common infrastructure for boot-mode switchesFurquan Shaikh
Instead of defining the same functions for reading/clearing boot-mode switches from EC in every mainboard, add a common infrastructure to enable common functions for handling boot-mode switches if GOOGLE_CHROMEEC is being used. Only boards that were not moved to this new infrastructure are those that do not use GOOGLE_CHROMEEC or which rely on some mainboard specific mechanism for reading boot-mode switches. BUG=None BRANCH=None TEST=abuild compiles all boards successfully with and without ChromeOS option. Change-Id: I267aadea9e616464563df04b51a668b877f0d578 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17449 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2016-11-17google/gru: Move to one CA training patternDerek Basehore
This changes memory to only do CA training with one pattern, 0xfffff/0x00000 and to also make sure CA training waits for all of the captures during training. BRANCH=none BUG=chrome-os-partner:56940 TEST=boot kevin and run stressapptest -M 1500 -s 1000 Change-Id: I0982674b4f4415f4d7865923ced93fa09bdd877e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 75cdd911cea9c4e5744fd04505b260fa5755513c Original-Change-Id: I3b86e6d4662c6fbbf9ddef274fce191a367904e5 Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/410320 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/17383 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-17google/gru: Add new CA training patternDerek Basehore
This adds a new CA training pattern for all of the supported frequencies. This pattern increases the hold time on CA. BRANCH=none BUG=chrome-os-partner:57845 TEST=boot kevin and run: while true; do sleep 0.1; memtester 500K 1 > /dev/null; done for several hours Change-Id: Ie5958cf67c16247ef90ee261da9faef4ffa5b339 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8babeafe75bffcb2dab17eb007b4f5bb0eb42606 Original-Change-Id: I7f7652f88e43dc9b2f6069e60514931bf7582ed1 Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/403547 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/17382 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-02rockchip/rk3399: display: Do not allocate framebuffer in corebootLin Huang
framebuffer address is dynamically chosen by libpayload now, so there's no need to configure it in coreboot. CQ-DEPEND=CL:401402 BUG=chrome-os-partner:58675 BRANCH=none TEST=Boot from kevin, dev screen is visible Change-Id: I9f1e581d5c63b3579b26be22ce5c8d1e71679f6f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: b3b6675420592c30e1e0abc8f8e9dd6ed5abd04c Original-Change-Id: I7e3162f24a4dc426fe4e10d74865cf0042c80db5 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/401401 Original-Commit-Ready: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17109 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-02rockchip/rk3399: sdram: also prepare the index1 configurationLin Huang
To enable DDR Dynamic Voltage and Frequency Scaling (DVFS) we need to train alternative configurations first, so do the training and store the values. BUG=None BRANCH=None TEST=Boot from kevin Change-Id: I944a4b297a4ed6966893aa09553da88171307a42 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 94533ff3ba21bcb0ace00bedcf0cebb89a341be2 Original-Change-Id: I4a98bc0db5553d154fedb657e35b926a92aa80c7 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/386596 Original-Commit-Ready: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17104 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-25rockchip/rk3399: gru/kevin: drop unused sdram configsLin Huang
There are some sdram configurations that are no longer used. Drop them. BUG=None BRANCH=None TEST=None Change-Id: Ib6d2d58c3071147a3095bc1ed7fa7b02c748e1a5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 111d375005ec6a3b91e47acdd676e8f1644c931c Original-Change-Id: I5f9278093f02e785b2894faa8e8cf09ecec20325 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/399122 Original-Commit-Ready: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17103 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-25rockchip/rk3399: reset system if DDR init failsLin Huang
We found sdram may fail in pctl_cfg(), so we check the status in this function. If it exceeds 100ms still in this function, we will restart the system. We also found there are rare chances DDR training fails, so also restart system in that case. BUG=chrome-os-partner:57988 BRANCH=None TEST=coreboot resets on failure and eventually the system comes up Change-Id: Icc0688da028a8f4f81eafe36bbaa79fdf2bcea74 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 89e45f8352f62e19a203316330aba14ccc5c8b11 Original-Change-Id: If4e78983abcfdfe1e0e26847448d86169e598700 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/397439 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/17045 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-08google/gru: Add USB 2.0 PHY tuning for Kevin PHY0 and PHY1William wu
We found that Kevin board PHY0 and PHY1 eye-diagram margin is not enough to make compliance test pass, and the PHY0 USB SI is worse than PHY1, because of the higher PCB impedance. For PHY0, we can't improve the eye-diagram by SW PHY tuning, so we need to reduce the RBIAS resistance from 133 ohm to 115 ohm, it can help to increase the eye-height. For PHY1, we can improve the eye-diagram by setting the max pre-emphasis level. And after the above change, the USB2 signal amplitude will become larger at the test point near to SOC USB2 PHY, in order to avoid mis-trigger the disconnect detection (650mV), we need to disable pre-emphasize in eop state. BRANCH=None BUG=chrome-os-partner:53863 TEST=do USB 2.0 compliance test for Kevin C0 and C1 port. Change-Id: I95c0acd79623aeca9a0ae077b1dd3836d91fe561 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: de3cdef128966d76e7d8e2ebd641763b911c3ad5 Original-Change-Id: I00cb325b9938e4276cc77b5d6f5faa7023379608 Original-Signed-off-by: William wu <wulf@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/390615 Original-Commit-Ready: Julius Werner <jwerner@chromium.org> Original-Tested-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16911 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: drive WLAN_MODULE_RST# low as early as possibleBrian Norris
GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also "pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time during early boot. This leaves the signal floating somewhere in the middle. This has two potential issues: (1) we're leaking some power for some (hopefully) short period of time (2) we are possibly screwing with the Wifi power sequence; we aren't supposed to deassert PDn (i.e., MODULE_RST#) until all the rails have fully ramped for some period of time Neither of the above issues are likely to be significant, but it is nice to fix, I expect. BRANCH=gru BUG=chrome-os-partner:54026 TEST=measure WLAN_MODULE_RST# on scope at boot time Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d Original-Signed-off-by: Brian Norris <briannorris@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/388009 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16882 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: set W2W_DIFFCS_DLY to 5Lin Huang
PHY_PER_CS_TRAINING is being enabled when DDR frequency >= 666. For per cs training, the controller should consider the PHY delay line switch time and there should be more cycles to switch the delay line, so update the W2W_DIFFCS_DLY_ value from 0x1 to 0x5. BRANCH=none BUG=chrome-os-partner:56940 TEST=do memtester on kevin board, and pass Change-Id: I00df2d4724b0b77f3e7565809fb35bbd2ff01ea5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c135ea3e33d810ed322d947eb8d512d1ac119cfc Original-Change-Id: I81b99cbc085769b7028e770509d79bd8d550820b Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/387506 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16721 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>