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