summaryrefslogtreecommitdiff
path: root/src/mainboard/google/gru
AgeCommit message (Collapse)Author
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-12 00:03:41 +0000