Seems like our transferred bytes calculation for OUT transfers that span
more than one packet had been wrong, and we just got lucky that we never
noticed it before. The HCTSIZ.xfersize register field we're reading only
counts bytes transferred by the last packet we sent.
OUT endpoints cannot have short transfers -- every transfer should
either finish all bytes we wanted to send or end in a proper error
condition. Therefore, in the absence of an error we can just conclude
that all input bytes have been transferred.
BRANCH=veyron
BUG=chrome-os-partner:35525
TEST=SMSC95xx netboot on Jerry now works.
Change-Id: Id0a127e6919f5786ba05218277705dda1067b8c3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294169
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
only modify the MR3 value, there will always be some mickey not working properly.
After enable ODT, we use many mickey do tests, now functioning properly.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Change-Id: Ieb2b8a56054f91b6be81260e4c574425fb72fed3
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/293324
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
Trybot-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from commit 5397c2f32f5851b9f514b0bd2ae68999a77cabbf)
Reviewed-on: https://chromium-review.googlesource.com/294270
If an HDMI display is detected (EDID can be read), set the
display mode to 480p. If for some reason 480p is not supported
then we'll fall back to the automatically detected display mode.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=dev mode screen shows up on Mickey at 480p resolution
Change-Id: I90dea37daa2d78628230d7d47f7ef0e917cbd7bb
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/290554
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293883
Due to HDMI need to set dclk_rate to 27Mhz, and we can't
caclu a suitable config paramters for this rate, so we
need to multiple rate unless the vco larger then VCO_MAX.
When NPLL rate multiple to 54MHz, pll_para_config could
caclu a right paramters, and I have verify the clock jitter
is okay to HDMI output.
Jitter Reports:
Dclk Rate NPLL Rate nr/no/nf jitter Margin
27MHz 54MHz 2/10/45 449.0ps +51.0%
Note for cherry-picking: Fixed writel()/write32() conflicts.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, show right recovery picture on TV,
and 480p clock jitter test passed
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Change-Id: Iab274b41f163d2d61332df13e5091f0b605cb65c
Reviewed-on: https://chromium-review.googlesource.com/288416
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293882
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Assume that HDMI implies usage of an external display, and that we
want to try bringing up display if we can read an EDID.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none; need a display with corrupt EDID to test with
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9e22984a98b1a5f8cd9645b92dc9b87e8d968f01
Reviewed-on: https://chromium-review.googlesource.com/293608
This ensures the output buffer is initialized before exiting
decode_edid() so that if the return value is ignored in higher-level
logic (like when dealing with external displays) we don't leave
the struct filled with garbage.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none
Change-Id: I697436fffadc7dd3af239436061975165a97ec8c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293607
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293606
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
Notes for cherry-picking: Reverted ToT's changes to
src/soc/nvidia/tegra132/dp.c. Most of that file wasn't implemented
in the firmware-veyron branch, so pretty much the whole file showed
up as a diff. For src/soc/rockchip/rk3288/hdmi.c, there were some
simple conflicts caused by the writel/write32 transition.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289964
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293605
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
Note for cherry-picking: There seem to be some formatting patches for
edid.c that never made it into the firmware branch, so for this patch
conflicts were resolved by just taking the newer (more correct)
version that was tested in ToT.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Reviewed-on: https://chromium-review.googlesource.com/290333
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293604
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Struct edid defien pvsync & phsync as an character,
like '+' or '-', so we need to check sync polarity
by comparing with characters '+' and '-' instead of
treating as boolean.
BRANCH=None
BUG=chrome-os-partner:42946
TEST=Mickey board, light monitor normally
Change-Id: I14c72aa8994227092a1059d2b25c1dd2249b9db1
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/289963
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293603
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Check device connect status while waiting for usb transfer complete
Avoid coreboot get stuck when usb device unplugged
BUG=chrome-os-partner:35525
TEST=None
BRANCH=None
Change-Id: Id103501aa0d8b31b0b81bef773679c0fad79f689
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/292630
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
(cherry picked from commit 2870609ceb56ccf81cda24f4cc2e10013f19adf7)
Reviewed-on: https://chromium-review.googlesource.com/293300
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This avoids any ambiguity or breakage in case the vop_modes get
shuffled around or changed in some future patch or copy+paste job.
Brain and Rialto need some more work done so their devicetree.cb
files will be updated in follow-up patches.
BUG=none
BRANCH=none
TEST=compiled only (for danger, jerry, mickey, romy, speedy)
Change-Id: I4fd549c82c8a5c31525c4e485fa8df73f33f2049
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd88973b53949058331613c7582650fbd4ea48db
Original-Change-Id: I47da45c5fd9648544392de8d76f86af812de9093
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282610
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10776
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://chromium-review.googlesource.com/293008
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The value of 0x4 (60 Ohm) apperas to be causing lots of problems.
Since 0x1 (34.3 Ohm) was _almost_ right, let's try 0x2 (40 Ohm) and
hope it's the sweet spot.
BRANCH=None
BUG=chrome-os-partner:43626
TEST=My mickey now boots up
Change-Id: If8b7d51d058ae000c0af189a648c62fa38a872ac
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/291121
Reviewed-by: Julius Werner <jwerner@chromium.org>
If short packet detected, stop this transfer and return the actual
transferred size
BUG=chrome-os-partner:42817
TEST=Netboot could run well
BRANCH=None
Change-Id: Icb4317f48aa04ac15bb1886b81d2e3c472d123d0
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/288215
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
(cherry picked from commit d372343b4e3d664ce2d76dbf55a5061b5d496bba)
Reviewed-on: https://chromium-review.googlesource.com/291253
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Modify MR3_I/O Configuration, Change 34.3 ohms to 60 ohms. This
resolves an issue that was observed on some Mickey boards with
the Samsung 2GB LPDDR3 and is believed to be caused by inferior
routing on the small PCB. (Elpida 2GB LPDDR3 seems unaffected.)
BUG=chrome-os-partner:41905
TEST=Boot from mickey
BRANCH=None
Change-Id: I5517e07fc5716ed4cd58e5502f13ccd61ffb5357
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286333
(cherry picked from commit 1305010aee6818910ad1dec26d9d948505ca281e)
Reviewed-on: https://chromium-review.googlesource.com/287415
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
some jerry panel need more delay time between the vcc_led and bl_en,
so we extend the delay time.
BUG=chrome-os-partner:42997
TEST=Boot from jerry, and do not flicker again
BRANCH=none
Change-Id: I74999601b41ccac22493cc9cd0bf52cd4dbb8c26
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/287373
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 0b00b6bd108f0aae461085d00819eca08ec892b3)
Reviewed-on: https://chromium-review.googlesource.com/287677
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Now that we have functioning display code for all platforms,
we can just get rid of this ugly hack used on non-Chromebook
veyrons.
BUG=none
BRANCH=none
TEST=built for Brain, Rialto, Mickey, Romy
Change-Id: I946eddb4e8ce1dbaa20212a2bb417e71a31b2ba3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282049
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285935
With split transaction, dwc2 host controller can handle full- and
low-speed devices on hub in high-speed mode. This commit adds support
for split control and interrupt transfers
(For cherry-picking, register definitions added to dw2c_registers.h
in the master branch were moved to dwc2_private.h)
BUG=None
TEST=Connect usb keyboard through hub, usb keyboard can work
BRANCH=None
Change-Id: I07e64064c6182d33905ae4efb13712645de7cf93
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/283282
Tested-by: Lin Huang <hl@rock-chips.com>
Commit-Queue: Lin Huang <hl@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285837
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:41416
BRANCH=none
TEST=builds and boots on mickey, though we crash if a HID device is
actually plugged in (storage device works fine though)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ib8d80648ce3717c16710b397b7093f4813315886
Reviewed-on: https://chromium-review.googlesource.com/285920
Reviewed-by: Julius Werner <jwerner@chromium.org>
This enables the config option for USB HID device support for
non-laptop Veyrons so the user can use a keyboard at the developer
and recovery mode screens.
(Note: This was applied to libpayload's files/ subdir on master)
BUG=chrome-os-partner:41416
BRANCH=none
TEST=tested on Mickey, can now use keyboard at dev mode screen
Change-Id: I35d47c4d887fcd771104e40b6458e3215007da76
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285838
Reviewed-by: Julius Werner <jwerner@chromium.org>
dwc2 host core do not have a periodic schedule list, so try to send
an interrupt packet in poll_intr_queue() function and use frame
number read from usb core register to calculate time and schedule
transfers.
(Note: For cherry-picking, hfnum_t was added back into dwc2_private.h
and lines 40, 108-109, and 111 in dwc.c needed to be modified)
BUG=None
TEST=Tested on RK3288 with two USB keyboards(connect to SoC without
USB hub), both work correctly.
BRANCH=None
Change-Id: Ie54699162ef799f4d3d2a0abf850dbeb62417777
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/280750
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284327
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit 22a470 in ToT ("switch mainboards over to use BOARD_ID_AUTO")
renamed BOARD_ID_SUPPORT to BOARD_ID_AUTO. When Mickey and Romy were
added they used the new name which was then carried over to the firmware
branch.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey in FW branch, and now the correct
kernel devicetree is used.
Change-Id: I752a9bad8d03ff4e190c0c74134126a54355ee56
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284951
Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
BUG=chrome-os-partner:42220
BRANCH=veyron
TEST=Used physical recovery button to enter dev mode on mickey
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/283546
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8d8dc0c0b98bbd194095d47047c8c5199ce17769
Reviewed-on: https://chromium-review.googlesource.com/284100
Danger has a physical developer mode switch, it was just never
set up. This patch defines it, sets it up in fill_lb_gpios(),
and disables VIRTUAL_DEV_SWITCH.
Note: For now at least, dev mode is a bit wonky on Danger. It's
connected to both a DIP switch and a button. The button is normally
open, pulling dev mode high (defaulting to ON). The switch's "ON"
position will pull the value low, so we invert the value in coreboot
to see the expected behavior. Dev mode is enabled by holding the
button down during boot or by setting switch 2 in the DIP bank to
the ON position.
BUG=none
BRANCH=none
TEST=toggled dev switch on Danger and saw dev screen show up (or
not) as expected
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/280852
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I737f165d7704e2f73375099367f012b365e3e77d
Reviewed-on: https://chromium-review.googlesource.com/284099
This adds a configure_hdmi() function that drives the HDMI
enable output high and configures the iomux. Calls to PMIC
functions to enable HDMI power are moved here as well.
(write32() --> writel() for cherry-pick)
BUG=none
BRANCH=none
TEST=with follow-up patches, we now get a dev screen on Brain.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282046
Change-Id: I0c6e9f8fc5e06f53a1a160d8ab2e32447168139e
Reviewed-on: https://chromium-review.googlesource.com/284097
We currently select either HDMI or EDP (default). This patch
allows us to use HDMI as a fallback for devices that may have
a display connected on either interface. It also renames the
enums to sound a little more sensible in other contexts (more
on that in the follow-up patches).
VOP_MODE_AUTO is added to the mode enum which will make it explicit
that a board can support either. In AUTO_MODE we will try EDP first
and then fallback to HDMI. Other modes can be set to force a certain
behavior such as HDMI-only on Mickey where it doesn't make sense to
try EDP.
A follow-up patch will add logic for when we explicitly don't want
to probe for any display (headless devices).
BUG=none
BRANCH=none
TEST=On veyron_danger, connected EDP and HDMI displays and saw dev
mode screen appear on EDP display. Unplugged EDP and then dev mode
screen showed up on HDMI.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/281076
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I352dcde16f7f3ebbf5796852b685685e541eb794
Reviewed-on: https://chromium-review.googlesource.com/284096
CRU request (24MHz * nf) / nr > 440MHz, but now ddr 300MHz
setting can't meet this request, so modify it
BRANCH=None
BUG=None
TEST=Set ddr frequency to 300MHz and boot from mickey
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/282445
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I885704542293ed55e429a0b4b30135af7978990f
Reviewed-on: https://chromium-review.googlesource.com/284095
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
EDP-related hardware modifications for v2:
- BL_EN moved from GPIO7_A3 to GPIO7_A2
- EDP_HPD added to GPIO7_B3
(write32() --> writel() for cherry-pick)
BUG=none
BRANCH=none
TEST=built and booted Danger v2 with EDP panel attached, saw dev
mode screen come up
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/280855
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id271cdcfcde6fa84c1bb707b9842bddd77a7121b
Reviewed-on: https://chromium-review.googlesource.com/284094
This re-factors SDMMC power on/off to make corrections and take
differences between board versions into account. To avoid similar-
but-different case switch statements in romstage.c and mainboard.c,
power on/off functions for SDMMC are split into their own .c file.
BUG=none
BRANCH=none
TEST=built and booted of micro-SD card on Danger v2
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/280853
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id86ae7f40687e843ffc4e7769309d4678ad54f49
Reviewed-on: https://chromium-review.googlesource.com/284093
This adds a configure_hdmi() function that drives the HDMI
enable output high and configures the iomux.
We'll add EDP/HDMI auto-detection in an upcoming patch.
(write32() --> writel() for cherry-pick)
BUG=none
BRANCH=none
TEST=set vop_mode to 1 in Danger's devicetree.cb and saw
dev mode screen output to HDMI display.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/280849
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I139d39749963d4121aaeec0c3da37d825ffa94ac
Reviewed-on: https://chromium-review.googlesource.com/284092
BOARD_ID functionality is not what requires the GPIO lib,
but it is the mainboard specific implementations that do.
The option essentially says whether the SoC provides
<soc/gpio.h> (with the interface required by the common
GPIO code). Right now, x86 and Samsung's Exynos SOCs
don't have support for this interface.
So this should be selected by the SOC, not by
BOARD_ID_SUPPORT.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=none
BRANCH=none
TEST=emerge-storm coreboot still successfully compiled an image
Reviewed-on: https://chromium-review.googlesource.com/262743
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d
Reviewed-on: https://chromium-review.googlesource.com/284084
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Brain doesn't have HOST1_PWR_EN (GPIO0_B3) and 5V_DRV (GPIO7_C5).
The only USB power enable pin connected to the AP is USB2_PWR_EN
(GPIO0_B4) which controls power for both the physical type-A ports.
BUG=none
BRANCH=none
TEST=built and booted on Brain, both USB host mode ports work
Reviewed-on: https://chromium-review.googlesource.com/271309
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ibbb4b9b424156eb3db1ccfdd948050c1c067ad3c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284083
On current Danger boards, VCC_LCD is gated by BL_EN. Thus we
need to enable BL_EN in order to power on the display so that
we can read the EDID and set things up.
Later board revisions may change this ordering, but for now it
doesn't seem to be causing a significant issues (no noticable
"snow" or other corruption using Pepto display).
BUG=none
BRANCH=none
TEST=booted on Danger, saw dev mode screen come up
Reviewed-on: https://chromium-review.googlesource.com/266913
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iaf17cc4682bd3c46f62cba789e3ecf8d5a474362
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284082
Danger has EDP, the original code was copied from Brain which
didn't.
BUG=none
BRANCH=none
TEST=built and booted on danger
Reviewed-on: https://chromium-review.googlesource.com/245161
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ic8b3f685e08bb96125c57d42db6a10e348a1a096
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284081
This applies the differences between Brain and Danger:
- Danger has an SDMMC slot
- Danger has a USB hub (TODO)
- Danger has LVDS (TODO)
- Add workaround for incorrect RAM_ID strapping
BUG=none
BRANCH=none
TEST=emerge-veyron_danger coreboot works
Reviewed-on: https://chromium-review.googlesource.com/241712
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Iae3f85d4f41e04465a5046f2334c693337d006a4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284080
Mickey:
- Does not have power key
- Does not have an audio codec(all audio goes thru HDMI)
- VCC18_LCD moved to VLDO8 and needs to be turned on (was
connected to VSWOUT2 earlier)
(write32() --> writel() for cherry-pick)
BUG=none
BRANCH=none
TEST=Boot from mickey board, and hdmi work normal
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/274876
Change-Id: I3d98203185f52ed751a5d3045a0ee8f9b4dfbc71
Reviewed-on: https://chromium-review.googlesource.com/284090
this is an brief hdmi driver which config with simple
display parameter, const encoder input & output color
format and 8bit color depth, and only 48KHz audio support.
what's more to prevent TV have not show an right things
before coreboot switch to kernel space, we have to add
an terrible 2s delay to driver (2s come from test many
times), cause we have to wait TV to respond (we got no
flag to check whether it is ready).
(for cherry-picking, manually changed write32()/read32() to
writel() and readl())
BUG=chrome-os-partner:40337
TEST=Booted Veyron Jerry and display normal
BRANCH=None
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/272565
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Lin Huang <hl@rock-chips.com>
Tested-by: Lin Huang <hl@rock-chips.com>
Change-Id: Iedc87c011c5b62ce5f16a296dd9c3e0c2eaba59b
Reviewed-on: https://chromium-review.googlesource.com/284089
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=Boot from mickey board
(note: for cherry-pick, resolved a merge conflict by omitting
a #define from the "rk3288: Add software I2C support" patch)
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/276290
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I438527ee0870044f48b23a6842986e7cf166e191
Reviewed-on: https://chromium-review.googlesource.com/284088
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This simply copies veyron_brain to veyron_mickey and makes the
minimal set of changes (s/brain/mickey) to make it compile. The
follow-up patch will take into account board differences.
(write32() --> writel() for cherry-picking)
BUG=none
BRANCH=none
TEST="emerge-veyron_mickey coreboot" doesn't fail
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271360
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I03a2b80eb441384f363910467180479521765431
Reviewed-on: https://chromium-review.googlesource.com/284087
This simply copies veyron_brain to veyron_romy and makes the
minimal set of changes (s/brain/romy) to make it compile. The
follow-up patch will take into account board differences.
(write32() --> writel() for cherry-picking)
BUG=none
BRANCH=none
TEST="emerge-veyron_romy coreboot" doesn't fail
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/271345
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0516ce94fd3c6a38170fae221a070f503ccfaf0f
Reviewed-on: https://chromium-review.googlesource.com/284086
When commit c65b9f4 ("veyron_{brain,danger,rialto}: Enable
eventlogging") was originally cherry-picked into the firmware
branch, Danger did not exist in the firmware branch. So the hunk
which applied to Danger got lost.
BUG=none
BRANCH=firmware-veyron
TEST=emerge-veyron_danger works
Change-Id: I17cc2ebce6c0b05987c7e54b601a7ce1ad16da75
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284107
This adds a directory with files copied over from Brain along with
build-related changes so that emerge-veyron_danger works. The next
patch will account for other differences.
BUG=none
BRANCH=none
TEST=emerge-veyron_danger coreboot works
Reviewed-on: https://chromium-review.googlesource.com/241711
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id265a7715f07a647a449f00097bf40f7c9b4c068
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/283999
This patch initializes the GPIO for the Chrome EC interrupt line on
Veyron boards and passes its description through the coreboot table, so
that payloads with keyboard support can use it to detect pending key
presses.
BRANCH=none
BUG=chrome-os-partner:39514
TEST=Booted Jerry, confirmed that it could still detect keypresses.
Confirmed that EC log does not show a huge amount of MKBP polls.
Change-Id: I8b426621af088460929cfff0a4b46618e2a86725
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267344
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 8ad95d667ef3af3fb217e3c370468dc1d6ec36c9)
jwerner: Added Gus, Jaq, Minnie, Nicky and Thea.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/282560
nicky and thea are the same as jaq, copy from jaq
BUG=chrome-os-partner:38537
TEST=emerge coreboot
BRANCH=firmware-veyron-6588.B
Change-Id: I317c635674a78765a75e1bad3a2098b179dbe0b9
Reviewed-on: https://chromium-review.googlesource.com/264906
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Chris Zhong <zyw@rock-chips.com>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Nicky and Thea are exactly the same as Jaq, copy configs
from Jaq
BUG=chrome-os-partner:38537
TEST=emerge libpayload
BRANCH=firmware-veyron-6588.B
Change-Id: Ib15c735583732b50fdb9dae0297be9093eb666db
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/264905
Reviewed-by: Julius Werner <jwerner@chromium.org>
Upstream coreboot regularly runs Coverity over the code base. Turns out
that's a good idea since it's really easy to screw yourself over with a
missing parenthesis and some unfortunately deceptive line breaking.
This patch fixes a bug in LPDDR3 initialization due to an incorrect
operator precedence assumption ( ?: does not bind stronger than | ). In
effect, instead of setting MR11[1:0] to 0b11 or 0b00 based on ODT, we're
unconditionally setting MR0[1:0] to 0b11. Thankfully, MR0[1:0] seems to
contain read-only bits so this might have not been a problem when ODT is
off (which is currently true for all LPDDR boards).
Also adding a redundant LPDDR_OP() around the 0 to make the intent
clearer and changing 3 and 0 to 0x3 and 0x0 to make it more obvious that
these are bit masks (right?).
BRANCH=veyron
BUG=None
TEST=Running reboot loop on a Minnie, looks good so far...
Change-Id: I701ce059472078b5de09a45dd31f54b65a51e641
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264135
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Jinkun Hong <jinkun.hong@rock-chips.com>
Tested-by: Jinkun Hong <jinkun.hong@rock-chips.com>
(cherry picked from commit 5bd9eba39fb7b0f940fead963bbc1878b031b2cb)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264308
