summaryrefslogtreecommitdiff
path: root/src/mainboard/google/gru
AgeCommit message (Collapse)Author
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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-13 22:06:31 +0000