summaryrefslogtreecommitdiff
path: root/src/mainboard/google/gru
AgeCommit message (Collapse)Author
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>
2016-10-07google/gru: pass apio number to arm-trust-firmwareLin Huang
To save power when entering suspend, gpios 2 to 4 need to be set to input and 'pull none' mode. Pass the APIO configuration to ATF so it can do a proper job here. BRANCH=None BUG=chrome-os-partner:56423 TEST=run suspend_stress_test on kevin board Change-Id: Id57fe8f622ae3f9c2bc7e58be89518b2b846cd37 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9c42082d1ca9a6baa735821382d3e83c1f8dc9ad Original-Change-Id: Iaf441e8e34c5591ffe7c65f6533fcf0b733ff5ac Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/378475 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/16720 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-07google/gru: pass the gpio power supply enable pin to bl31Lin Huang
We need to disable some regulators when the device goes into suspend. This means that we need to pass some gpios to bl31, and disable these gpios when bl31 runs the suspend function. BRANCH=None BUG=chrome-os-partner:56423 TEST=enter suspend, measure suspend gpio go to low [pg: also update arm-trusted-firmware to match] Change-Id: Ia0835e16f7e65de6dd24a892241f0af542ec5b4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0f3332ef2136fd93f7faad579386ba5af003cf70 Original-Change-Id: I03d0407e0ef035823519a997534dcfea078a7ccd Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/374046 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/16719 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06rockchip: rk3399: improve write leveling flowJianqun Xu
To improve sdram 800MHz and 933MHz stability, we need to modify write leveling flow to get the proper write leveling value. BUG=chrome-os-partner:56940 BRANCH=none TEST=Boot from kevin on 933MHz, and do stressapptest Change-Id: I5b24c93d4a57917fb9af7e5e2a95d8423ccbaa7e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d84bf25b3e5de373c7913e6d534a810cb984b3fd Original-Change-Id: I87efddf628c3683fcb85d6875e029cf3cbc482be Original-Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com> Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/384292 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/16716 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06google/gru: Shrink RW_ELOG region to 4KBJulius Werner
Since there's currently a limitation in coreboot's code that prevents more than 4KB to be used by the eventlog anyway, this patch shrinks the available RW_ELOG area in the FMAP for Gru down to 4KB. This may prove prudent later if we ever resolve that limitation, so that tools can rely on the area in the FMAP being the same as the area actually used by the read-only firmware code on these boards. BRANCH=gru BUG=chrome-os-partner:55593 TEST=Booted Kevin, confirmed that eventlog got written normally. Ran a reboot loop to exhaust eventlog space, confirmed that the shrink code kicks in as expected before reaching 4KB. Change-Id: I3c55d836c72486665a19783fe98ce9e0df174b6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 05efb82ca00703fd92d925ebf717738e37295c18 Original-Change-Id: Ia2617681f9394e953f5beb4abf419fe8d97e6d3e Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/384585 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Simon Glass <sjg@google.com> Reviewed-on: https://review.coreboot.org/16715 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06rockchip: rk3399: improve sdram noc timingLin Huang
sdram noc timing will affect ddr latency, this patch improves rk3399 sdram noc timing so improve memory performance. BRANCH=gru BUG=chrome-os-partner:57248 TEST=Boot from kevin board Change-Id: I09e984490a7ad747ef8abfc6542d0e2c95ec19bc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 43dfe55d713d371e39d21312772fd353614b7642 Original-Change-Id: I393e74ecdeb72930ac38ae9bcf311e5654f65162 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/382725 Original-Reviewed-by: Sonny Rao <sonnyrao@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Tested-by: Sonny Rao <sonnyrao@chromium.org> Original-Commit-Queue: Sonny Rao <sonnyrao@chromium.org> Reviewed-on: https://review.coreboot.org/16713 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06rockchip/rk3399: lower kevin board sdram frequency to 800MHzLin Huang
We found some boards are not stable when sdram is run at 933Mhz. Before we can fix it, we need to lower the sdram frequency to 800MHz. In this patch we modify the DQS delay from 0x280 to 0x260 and extend the DQS window. BRANCH=None BUG=chrome-os-partner:56940 TEST=Booted Kevin. Change-Id: I68561c4aa4d9ab66acfa3515a42d696157aff759 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 877a7f6ad22a5bde9f9e458bcb65f133f2f001bd Original-Change-Id: I5eab6bbe96f0dae095c5353403292022e7a25421 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/382724 Original-Commit-Ready: Douglas Anderson <dianders@chromium.org> Original-Tested-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/16709 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06rockchip/rk3399: Move big CPU cluster initialization into ramstageJulius Werner
This patch moves the big CPU cluster initialization on the RK3399 from the clock init bootblock function into ramstage. We're only really doing this to put the cluster into a sane state for the OS, we're never actually taking it out of reset ourselves... so there's no reason to do this so early. Also cleaned up the interface for rkclk_configure_cpu() a bit to make it more readable. BRANCH=None BUG=chrome-os-partner:54906 TEST=Booted Kevin. Change-Id: I568b891da0abb404760d120cef847737c1f9e3ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: bd7aa7ec3e6d211b17ed61419f80a818cee78919 Original-Change-Id: Ic3d01a51531683b53e17addf1942441663a8ea40 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/377541 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/16698 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-04google/gru: Ensure correct pull resistors for special-function pinsJulius Werner
Several of the special function pins we're using in firmware have a pre-assigned pull-up or pull-down on power-on reset. We don't want those to interfere with any of the signaling we're trying to do on those pins, so this patch disables them. Also do some house-cleaning to group the bootblock code better, and change the setup code for all SPI and I2C buses to first initialize the controller and then mux the pins... I assume this might be a little safer (in case the controller peripheral has some pins in a weird state before it gets fully initialized, we don't want to mux it through too early). BRANCH=None BUG=chrome-os-partner:52526 TEST=Booted Kevin. Change-Id: I4d5bd3f7657b8113d90b65d9571583142ba10a27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f8f7fd56e945987eb0b1124b699f676bc68d0560 Original-Change-Id: I6bcf2b9a5dc686f2b6f82bd80fc9a1a245661c47 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/382532 Reviewed-on: https://review.coreboot.org/16711 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-04gru: Increase SPI speed to 33MHzSimon Glass
Increase the SPI bus speed to speed up boot time. The maximum supported speed at 1.8V is 37.5MHz, and 33MHz is the next lowest convenient speed, given the clock parents. BUG=chrome-os-partner:56556 BRANCH=none TEST=boot on gru and see that things still work correctly. Total time spent on reading from SPI reduces from 185ms to 141ms. Change-Id: I71436c9e343b18360fa63d528dea5cfcfbc831e6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d7576f6e53e407af61160be142c3d589e864a8cf Original-Change-Id: I55a19f523817862e081d23469e94fd795456dd67 Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/381313 Original-Commit-Ready: Julius Werner <jwerner@chromium.org> Original-Tested-by: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16708 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-10-04google/gru: Init the PWM pinmux after setting up the PWMDouglas Anderson
If we setup the PWM _after_ the pinmux then there's a period of time when we're driving the PWM incorrectly. Let's setup the regulator and _then_ configure the pinmux. This fixes no known bugs, but it is more correct and probably makes the signals look better at bootup. BRANCH=None BUG=None TEST=scope Change-Id: I311c0eded873b65e0489373e87b88bcdd8e4b806 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fcf4d0ba29d82cce779c0b25ead36de4a95d97a1 Original-Change-Id: I5124f48d04a18c07bbd2d54bc08ee001c9c7e8d1 Original-Signed-off-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/381592 Original-Reviewed-by: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16700 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-02Kconfig: Update default hex values to start with 0xMartin Roth
Kconfig hex values don't need to be in quotes, and should start with '0x'. If the default value isn't set this way, Kconfig will add the 0x to the start, and the entry can be added unnecessarily to the defconfig since it's "different" than what was set by the default. A check for this has been added to the Kconfig lint tool. Change-Id: I86f37340682771700011b6285e4b4af41b7e9968 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16834 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-09-20gru/kevin: Decrease voltage for little cpu 1.5G to 1.15vShunqian Zheng
In kernel side we set 1.1v for 1.5G, even for coreboot RO, a higher voltage could be safer, 1.2v now seems too high. BRANCH=none BUG=chrome-os-partner:56948 TEST=bootup Change-Id: I852e0d532369aad51b12770e2efb01aacf6662ce Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 000b5c099373be2a1f83c020ba23a0e79ea78fab Original-Change-Id: Iecc620deee553c61a330353ac160aa3a36f516df Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/380896 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16583 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-09-20google/gru: Fix up PWM regulator rangesJulius Werner
We did yet another small adjustment to the PWM regulator ranges for Kevin rev6... this patch reflects that in code. Also rewrite code and descriptions to indicate that these new ranges are not just for Kevin, but also planned to be used on Gru rev2 and any future Gru derivatives (which as I understand it is the plan, right?). BRANCH=None BUG=chrome-os-partner:54888 TEST=Booted my rev5, for whatever that's worth... Change-Id: Id78501453814d0257ee86a05f6dbd6118b719309 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 4e8be3f09ac16c1c9782dee634e5704e0bd6c7f9 Original-Change-Id: I723dc09b9711c7c6d2b3402d012198438309a8ff Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/379921 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/16580 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-09-20Gru: Increase bit-per-pixel to 32Daisuke Nojiri
This enhances gradation of some icons on vboot screens. BUG=chrome-os-partner:56056 BRANCH=none TEST=Booted kevin-tpm2 Change-Id: I2fc943f89386ccc6cd9293f5811182a5a51d99b0 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: bb1f0fb00d023c045305edc6c9fc655b764a4e8c Original-Change-Id: Ieb61830b9555da232936087cdcf7c61a1e55bab4 Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376883 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16579 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-09-20gru: Add watchdog reset supportJulius Werner
This patch adds support to reboot the whole board after a hardware watchdog reset, to avoid the usual TPM issues. Work 100% equivalent to Veyron. From my tests it looks like both SRAM and PMUSRAM get preserved across warm reboots. I'm putting the WATCHDOG_TOMBSTONE into PMUSRAM since that makes it easier to deal with in coreboot (PMUSRAM is currently not mapped as cached, so we don't need to worry about flushing the results back before reboot). BRANCH=None BUG=chrome-os-partner:56600 TEST='stop daisydog; cat > /dev/watchdog', press CTRL+D, wait 30 seconds. Confirm that system reboots correctly without entering recovery and we get a HW watchdog event in the eventlog. Change-Id: I317266df40bbb221910017d1a6bdec6a1660a511 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 3b8f3d064ad56d181191c1e1c98a73196cb8d098 Original-Change-Id: I17c5a801bef200d7592a315a955234bca11cf7a3 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/375562 Original-Commit-Queue: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://review.coreboot.org/16578 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-09-20gru: Add USB 2.0 PHY tuning for KevinJulius Werner
This patch sets some magic number in magic undocumented registers that are rumored to make USB 2.0 signal integrity better on Kevin. I don't see any difference (unfortunately it doesn't solve the problems with long cables on my board), but I guess it doesn't hurt either way. BRANCH=None BUG=chrome-os-partner:56108,chrome-os-partner:54788 TEST=Booted Kevin with USB connected through Servo. Seems to have roughly the same failure rate as before. Change-Id: If31fb49f1ed7218b50f24e251e54c9400db72720 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 0c5c8f0f80ea1ebb042bcb91506a6100833e7e84 Original-Change-Id: Ifbd47bf6adb63a2ca5371c0b05c5ec27a0fe3195 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/370900 Original-Reviewed-by: Guenter Roeck <groeck@chromium.org> Original-Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-on: https://review.coreboot.org/16265 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-31rockchip/rk3399: Add pwm_regulator.c for pwm then ramp boot up cpuEric Gao
Before, we calculate the pwm duties for cpu cores and centerlogic by hand, adding pwm_regulator.c to handle this. The default pwm design min/max voltage may be different between revs. With the pwm regulator, this patch changes the little cpu frequency from 600M to 1512M, and raises CPU voltage to 1.2V correspondingly. This also means we decide to drop the ES1 because it may fail to bootup with 1.5G ~ 1.2v. BRANCH=none BUG=chrome-os-partner:54376,chrome-os-partner:54862 TEST=Bootup on kevin board Change-Id: Id04c176bddfb9cdf3d25b65736e40249a85f6aa1 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: ee4365c787ec523b7ee1028ea100dcfbb331b3a9 Original-Change-Id: Ide75bbd92d1cbb14f934baeec0e38862bc08402b Original-Signed-off-by: Eric Gao <eric.gao@rock-chips.com> Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/364410 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16368 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-31rockchip/rk3399: Move romstage.c to mainboard/gruShunqian Zheng
The romstage.c is more board related than soc specific, like setting the pwm regulators, so moving it to mainboard/gru. BRANCH=none BUG=chrome-os-partner:54819 TEST=Bootup on kevin board Change-Id: I83c6cde9f451480e47e2b4b549cedf65b345134c Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 35feeb07131a6a9de4adde035236987391833474 Original-Change-Id: If2bf245302eb4fb20bb089c1b3ffa03909722443 Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/375398 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16367 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-27gru: Make SDRAM parameters individual struct files in CBFSJulius Werner
This patch changes Gru SDRAM parameters from structures that just get compiled into the romstage to individual CBFS files. This allows us to only load the parameter set we need for the board we're booting from flash, which reduces our boot time and the SRAM memory footprint required to hold the romstage. TEST=Booted Kevin. Change-Id: Ie88a515cbdb19a794ca0a230a56bcc82bed1e550 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16274 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-08-19rockchip/rk3399 & gru/kevin: support sdram 933MHz on kevinLin Huang
We should be running faster. Faster = better. BRANCH=None BUG=chrome-os-partner:54873 TEST=Boot; stressapptest -M 1028 -s 10000 Change-Id: I7f855960af3142efb71cf9c15edd1da66084e9d8 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 51bfd2abb1aba839bd0b5b85e9e918f3cc4fd94d Original-Change-Id: Iec9343763c1a5a5344959b6e8c4dee8079cf8a20 Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/362822 Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16241 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-08-18Kconfig: rename BOOT_MEDIA_SPI_BUS to BOOT_DEVICE_SPI_FLASH_BUSAaron Durbin
Provide a default value of 0 in drivers/spi as there weren't default values aside from specific mainboards and arch/x86. Remove any default 0 values while noting to keep the option's default to 0. BUG=chrome-os-partner:56151 Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16192 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-16Revert "rockchip: rk3399: enable sdhci clk for emmc"Shunqian Zheng
This reverts commit 462e1413 ("rockchip: rk3399: enable sdhci clk for emmc") Enabling this clock in coreboot is no longer needed as it's handled in the kernel driver now. BUG=chrome-os-partner:52873 TEST=boot from usb/sdcard and check there is /dev/mmcblk0 BRANCH=none Change-Id: I92cf51f175fe56a09ab9329b29a27c77ef4328e1 Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 5707d1269a253dabf825be120d1f9348ffaab6d0 Original-Change-Id: I8bca870c663d8ce8fac5daaaaf8225489f22ed13 Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/367421 Original-Commit-Ready: Brian Norris <briannorris@chromium.org> Original-Reviewed-by: Douglas Anderson <dianders@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16152 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 02:34:40 +0000