The developer mode gpio switch on rialto is always hardcoded (through a
resistor) as developer mode. We need to ignore it to allow transitions to
verified mode with the virtual developer mode stuff.
This was not needed in master due to CL:261588, but this is a more semantic
way to do it.
BRANCH=veyron
BUG=chrome-os-partner:46150, chrome-os-partner:43022
TEST=We can now exit dev mode on rialto
Change-Id: If11d752d58a5f26fc270ef01b529dad18b4cce46
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/325546
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a follow-up to CL:320623 to make veyron DRAM configs
uniform (except for Rialto).
As discussed in chrome-os-partner:43626, the mr[3] value and ODT
are set diffently for Mickey, thus the .inc files for other boards
have mr[3] = 1 and ODT disabled.
For cherry-picking, the change was applied for all Chromebook
platforms individually rather than just src/mainboard/veyron/.
BUG=none
BRANCH=veyron
TEST=compile tested for veyron
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iacf821645a2dcceaed1c1c42e3e1b1c312b31eab
Reviewed-on: https://chromium-review.googlesource.com/322487
Updating Hynix memory configuration for mickey so that it can boot on Hynix board.
BUG=chrome-os-partner:48637
BRANCH=master
TEST=Boot on mickey hynix board
Change-Id: Id63d74cac36b9fd84bdb88969291982e14fa7d01
Signed-off-by: Lang Zhang <kingsley_zhang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/320623
Commit-Ready: lang zhang <kingsley_zhang@asus.com>
Tested-by: lang zhang <kingsley_zhang@asus.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322633
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This makes the same changes to the LPDDR3 configuration that
were made for Samsung modules:
- Enable ODT function
- Change DS to 40 Ω from 34.3 Ω
BUG=chrome-os-partner:47416
BRANCH=firmware-veyron-6588.B
TEST=Boot on mickey elpida board
Change-Id: I2d54d3087ecd3536469866f30e4eb2d8b1acd5c1
Signed-off-by: jiazi Yang <Tomato_Yang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/311153
Reviewed-by: Julius Werner <jwerner@chromium.org>
Right now our EDID logic isn't very smart. It always just picks the
first detailed mode and ignores the rest. It's possible that this
detailed mode might be too fast for us, so let's allow some filtering.
We'll use this filtering to filter out modes > 165 MHz on the rk3288
HDMI port.
We choose 165 MHz for HDMI because this is the fasest you can go over
single link DVI. We could try to be smart and allow faster speeds if we
detect that we're on HDMI, but this is unlikely to work anyway because >
165 MHz we start getting really jittery without a lot more work on HDMI
clocks.
This happens to make the HP ZR30w show the BIOS dev screen now.
BRANCH=none
BUG=chrome-os-partner:47008
TEST=HP ZR30w works
Change-Id: I1d20090b8ad84717ecc56a27ffe4ab0ee312628a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309568
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When booting, you see:
EDID version: %hd.%hd
Let's fix it to print the actual version.
BRANCH=none
BUG=none
TEST=No longer see wrong printout
Change-Id: Id954856538938961678027d5fdc881d9ea270e26
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309599
The detailed_cvt_descriptor() function takes a parameter "out" for no
good reason. Remove it.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Build and boot
Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309598
The EDID parsing code continued to update _some_ fields of the output
edid but not others if "did_detailed_timing" was already set. It also
then went on to print out this halfway mix of modes each time, despite
the fact that it didn't really update everything.
Let's fix that. We'll reduce code changes by using a temporary copy of
data in detailed_block() and then we'll copy it back if we decide we
should update.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=No more bogus printouts
Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309541
The set to say that a standard timing was supported was not properly in
the "if" test. That meant that even when standard timings weren't
supported, we thought that they were. That had the side effect of never
using the detailed mode.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Adafruit panel works now
Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309521
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid
clock to use, but is quite hard to make a non-jittery clock from PLLs.
It's much easier to make 25.200 MHz, so let's do that.
The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems
better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia monitor works, so do others
Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309540
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Previously if we tried to read the HDMI EDID several times and failed
each time then we're return from hdmi_read_edid() with no error. Then
we'd interpret whatever happened to be in memory at the time as an
EDID--not so great.
Let's actually look at the error.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Monitor that can't read EDID not shows that in the log
Change-Id: I9089755b75118499bec37bdb96d1635f66252e65
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309316
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
HDMI soft reset happens when you write 0, not 1. ...not that I've ever
seen the soft reset do something, but if we're going to try it we should
probably try to do it correctly.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Doesn't break anything
Change-Id: I0f4ab869b1e1a2d4a38f0eacfd01b01760069f58
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309317
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307946
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit d9679b02f6d21ed903bb02e107badb0fbf7da46c)
Reviewed-on: https://chromium-review.googlesource.com/309247
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
On one particular TV the TV was holding SDA low when it came up. It
would release the SDA when the SCL went low the first time.
Unfortunately the HDMI i2c port wouldn't transmit until the SDA was
released.
Let's detect this case and insert a bogus clock pulse to try to get the
other side to release SDA.
It's unclear why the kernel doesn't have this problem.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia TV works now
Change-Id: I4b6361877e0576cc4ea2f643f073f1aab660e434
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/309258
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/309275
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
'edid->hdmi_monitor_detected' would indicate whether the monitor
interface is HDMI or DVI.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=Previously, my LG monitor couldn't show dev screen. But now I can see
dev screen have been posted normally.
Change-Id: I157861d327926b834e1e8606b0b676f413491c70
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/309370
Reviewed-by: Agnes Cheng <agnescheng@google.com>
Commit-Queue: Agnes Cheng <agnescheng@google.com>
Trybot-Ready: Agnes Cheng <agnescheng@google.com>
Tested-by: Agnes Cheng <agnescheng@google.com>
BUG=none
BRANCH=none
TEST=built libpayload on veyron_rialto
Change-Id: I858c5433ecabf14e060a69119748ea9830d3a51d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304109
Reviewed-by: Alexandru Stan <amstan@chromium.org>
This patch does a few things:
- write32() -> writel()
- Adds config files for Rialto
- No program_loading.h in FW branch
- No run_ramstage in FW branch, use older stage_exit() instead
- Kconfig stuff:
CONSOLE_SERIAL_UART -> DRIVERS_UART
BOARD_ID_SUPPORT -> BOARD_ID_AUTO
MAINBOARD_HAS_CHROMEOS -> MAINBOARD_HAS_BOOTBLOCK_INIT
Added RETURN_FROM_VERSTAGE - selected with rk3288 in toT
Added ELOG - selected along with CHROMEOS in ToT
Set VBOOT_*_INDEX - Set in .config files in ToT
Except for the actual board differences, this should look a lot
like other non-laptop veyrons in the firmware branch.
BUG=chrome-os-partner:46150
BRANCH=firmware-veyron
TEST=built and booted on Rialto
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I446bde4f074ffe943a78ddcb0e979c0ffa5a1036
Reviewed-on: https://chromium-review.googlesource.com/304108
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This is a straight copy of src/mainboard/google/veyron_rialto from
ToT. The next patch in the series will show differences necessary
to get it to build in the firmware branch.
The reason for doing it this way is because a lot of changes from ToT
have already been applied to other non-laptop Veyron boards. So it
doesn't make a whole lot of sense to re-apply them individually just
for Rialto. And since Rialto has been in the tree for a long
time and has accumulated a lot of history, things would be quite
broken up until the later patches if we tried.
Coreboot for Rialto will not compile with this. The follow-up patch
must be applied for it to build successfully.
CQ-DEPEND=CL:304108
BUG=chrome-os-partner:46150
BRANCH=firmware-veyron
TEST=built and booted on Rialto w/ follow-up patch
Change-Id: I90eb9af3b4f31b656ecdded20e0a556fef2609d0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304107
Reviewed-by: Alexandru Stan <amstan@chromium.org>
If recovery mode is detected, throttle down APLL frequency to 600MHz
and VDD_ARM to 900mV. This is intended to mitigate the possibility
of thermal shutdown if the system is left at the recovery screen for
a long period of time.
Experimentally, going lower than 600MHz didn't help decrease
temperature significantly and added a few seconds to recovery
boot time.
BUG=chrome-os-partner:41201
BRANCH=firmware-veyron
TEST=built and booted on mickey, normal mode boot time was normal (~1.8s)
and RK808 temperature remained steady at recovery screen for ~14 hours.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I82cbc1f591cbfae5ccf4e99e468f2b053c835639
Reviewed-on: https://chromium-review.googlesource.com/299718
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:41201
BRANCH=firmware-veyron
TEST=tested with subsequent patch on mickey
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3ce0f7b2772c8c652b7f461749d01cc7b669b6cf
Reviewed-on: https://chromium-review.googlesource.com/300786
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This changes the API to rkclk_configure_cpu() such that we can pass
in the desired APLL frequency in each veyron board's bootblock.c.
Devices with a constrainted form facter (rialto and possibly mickey)
will use this to run firmware at a slower speed to mitigate risk
of thermal issues (due to the RK808, not the RK3288).
BUG=chrome-os-partner:42054
BRANCH=firmware-veyron
TEST=amstan says rialto is noticably cooler (and slower)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297190
Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: I960cb6ff512c058e72032aa2cbadedde97510631
Reviewed-on: https://chromium-review.googlesource.com/299714
When disconnect detected in dwc2_split_transfear() split configure
registers should be cleared before return
BRANCH=None
BUG=chrome-os-partner:44534
TEST=tested on Jerry, usb hot plug could be supported in coreboot
Change-Id: Ie1eecec067305874513c6ceb95df4240dc393cd6
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/295625
Reviewed-by: David Hendricks <dhendrix@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 d543e14cdc73bd549dd553c8d1d07672a1307981)
Reviewed-on: https://chromium-review.googlesource.com/299100
If the device has already been disconnected then we shouldn't enable
host channel to start any transfer, otherwise this channel goes into
an odd state the channel is enabled but can not be disabled by set
hcchar.chdis=1. So we need check the device connect status before
enable channel.
BRANCH=None
BUG=chrome-os-partner:44534
TEST=None
Change-Id: Ib3ecf486649ca11b302144f9c00a5e88424e90fa
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/298402
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 ea96f947b5304fdde2e0991d23febaeba209dde1)
Reviewed-on: https://chromium-review.googlesource.com/298992
Reviewed-by: David Hendricks <dhendrix@chromium.org>
I don't quite remember when we decided to add Danger to the firmware
branch in the first place, but it looks like we did and we didn't bring
all of its SDRAM configs with us from ToT. This patch syncs them back to
where Jerry is, since they should be 100% identical.
Also, this whole copy&pasting when cherry-picking SDRAM CLs makes me
anxious... one line too few or too many removed could have very ugly
consequences. Let's add another assertion to try to catch that should it
ever happen.
BRANCH=veyron
BUG=None
TEST=None
Change-Id: I7c142b7d329733e3e5af7aac1e623437224a315e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295443
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BRANCH=None
TEST=Boot from veyron
BUG=None
Change-Id: I68b105aa4bc3e82ef6a2421b127391e319c34d6e
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/294660
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit c115d9a3ea2ca1cb62b2a1ee75996d8adb991d5d)
jwerner: Added Minnie
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/294763
(cherry picked from commit 6fe83821013954f0f2069598fd90a2d49de81101)
jwerner: Removed Danger and Shark, added Gus, Jaq, Nicky and Thea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295442
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>
