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
Unfortunately, firmware for some Veyron boards was finalized before we
realized that we're clocking our SPI flash far lower than we need to.
Nothing we can do about that in RO now. We can, however, reinitialize
SPI in RW with a higher frequency to at least gain some speed back for
ramstage and payload load times on those boards.
BRANCH=veyron
BUG=chrome-os-partner:38352
TEST=Resigned a Jerry 6588.40.0 MP image with my own 4K keys, dd'ed the
last 2MB of an image with this patch onto it, confirmed 1.33s boot time.
Change-Id: I999aff125891e64123fdd7dc21f04640ac411583
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263112
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch increases the SPI clock for the ROM to 24.75MHz on all Rk3288
(veyron) boards. This increases flash read speeds (and thereby decreases
boot time) significantly, but we don't seem to get any more increases by
going even higher. We have also seen occasional read failures at higher
speeds in certain configurations, so this frequency seems to be the best
option.
BRANCH=veyron
BUG=chrome-os-partner:38352
TEST=Booted on Jerry with Servo attached.
Change-Id: If3fd96c8cb5648d12fc4ee56fb6b6d5f3a0bf720
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262645
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a1d07da4266f2922b076dfae8396c24c6a84252b)
jwerner: Added Gus, Jaq and Minnie, removed Danger and Rialto.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262806
The code to calculate the RK3288 SPI controller's internal clock divisor
is wrong: it assumes that the divisor register was an "n-1" divisor when
it actually isn't (due to some misleading kernel code that was copied in
here). This means that all SPI clocks are currently running lower than
expected.
This patch fixes the calculation and changes all callers such that the
effective speeds stay the same.
BRANCH=veyron
BUG=chrome-os-partner:38352
TEST=Booted Jerry with and without the patch, dumping the divisor for
flash and EC clocks. Made sure it stays the same.
Change-Id: I094d57a5933c8b849f5c66194e6cc2952ab68b90
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262269
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 1fd5b990f937019a9bee7bd693c91d6e2fca1adb)
jwerner: Added Gus, Jaq and Minnie, removed Danger and Rialto. Replaced
write32() with writel().
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262805
BRANCH=None
TEST=Boot from veyron
BUG=None
Change-Id: I725cfb04ff46f7e6493e0e12a464c45b1362bc1a
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/261083
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 0ddd03f8757b5122f6ca87baffdf95c46e356e53)
jwerner: added Jaq, Gus and Minnie, removed Danger
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261580
The old parameters are wrong. K4B8G1646Q: rank = 2, row = 15 is right.
BUG=None
TEST=Boot from veyron
BRANCH=None
Change-Id: I5bc6798890b3ba0f5134d048ae6bbf2bfd696676
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/260483
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Paul Ma <magf@bitland.com.cn>
(cherry picked from commit 601ba06c636ff0f0779e6ef9357b53060a1ec19b)
jwerner: added Jaq, Gus and Minnie, removed Danger and Rialto
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260892
This applies the same hack to Danger and Brain as on Rialto which
allows us to remove the EC-related sections from their respective
flashmaps.
BUG=none
BRANCH=veyron
CQ-DEPEND=CL:260871
TEST=built and booted on Brain w/ depthcharge and mosys changes,
was able to read vbnv data from userspace
Change-Id: I6c2041e8c17ab157599255a505aaef5e2447a241
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255780
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 4de4273be9ac80ca77a34bc076d1f265fbb94e9f)
jwerner: removed Danger
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260891
in depthcharge we will use "backlight" gpio which in lb_gpio table
to control backlight, we use lcd_bl before, but it will not meet
the backlight power sequence, so we change it to bl_en.
BUG=chrome-os-partner:37348
TEST=Boot from speedy, and backlight work well
BRANCH=None
Change-Id: Ib0dac7c48bce7d0b28ec287b32d8c5bad575893f
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/259900
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit cb594ce612e1cedeabced4531fbd954f3698da98)
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/259901
Tested-by: Jiazi Yang <Tomato_Yang@asus.com>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
This add hynix-2GB SDRAM(H5TC4G63AFR-PBA), whose timing is the same as
H5TC4G63CFR-PBA, to veyron boards.
BUG=None
BRANCH=veyron
TEST=build on mighty and jaq and boot on jaq board with ram-id reworked
Change-Id: If17fb002f2816990e1706833b37ac6be345e540b
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/256795
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
This patch adds all SDRAM configurations currently in use for any Veyron
board to all boards. In the future we might decide that we want to reuse
known good memory from one board on another, and having all of these in
there already might help us avoid a firmware rev. We can still
differentiate them later if the need ever arises.
Not touching Rialto since it already decided to go its own way and
replace an existing RAM code with it's own 1GB configuration. Also
adjusting the names of the recently added DDR3 4GB configs to fit the
existing scheme.
Includes changes from "veyron: The ODT function is disabled LPDDR3".
BRANCH=veyron
BUG=None
TEST=Compiled all Veyron boards, booted on Jerry.
Change-Id: I4d037967dcb5cbd6b2b82f347f6b19541559b61a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255665
(cherry picked from commit 36d3fe138b154a16700e3c7adbb33834ff1c5284)
jwerner: Removed Danger, added Jaq, Gus and Minnie
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255978
We found that we should better keep ODT off for LPDDR3 on our boards.
BRANCH=veyron
BUG=chrome-os-partner:37346
TEST=Boot veyron_speedy normal
Change-Id: Iebb8e74706756508dd56b85ad87baad48893c619
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/255381
(cherry picked from commit 0d85725a6faedb5bdbe8731991c225c31f138599)
jwerner: Removed Danger and Rialto, added Jaq, Gus and Minnie
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255977
if DCDC_UV_ACT_REG setted, when the buck voltage drop to 85%,
rk808 will reset this buck, but now when the current consumption large,
rk808 may miscarriage of justice this status, so we must disable this function
BUG=chrome-os-partner:34834
TEST=Boot from jerry, and do RUNIN test sucess
BRANCH=None
Change-Id: I46ebe332c576eebd3386b5042b146a8b57a5c194
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/254496
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 858c8abc11a824fc3d991a39a49710243f4b1473)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255976
The wrong offsets were being used for the GRF_SOC_CON2 register. This also
configures odt based on the value of odt in the sdram_params for lpddr systems.
BUG=chrome-os-partner:37346
TEST=boot veyron_speedy and veyron_jerry
BRANCH=None
Change-Id: Ic0c18cc7ccf861ef8749e6c950fab9a2802e5f26
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255584
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 403ab13de17290dc3766bd6f1a03b6effbe58b41)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255975
add the K4B8G1646Q-4GB and H5TC8G63XXX-4GB ddr3 inf file,
and use ram_id 1110 correspond to K4B8G1646Q-4GB ddr3
use ram_id 1111 correspond to H5TC8G63XXX-4GB ddr3
BUG=None
TEST=Boot veyron_jerry normal
BRANCH=None
Change-Id: I90250cb84eb140f93c4fc655fb3b90584dd515c0
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/255010
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit b8dfc455bb93c2daf567e3b6e39c0a715e44311c)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255974
When using single-channel ddr, DMC channel 1 need to reset dll,
otherwise it will lead to pmdomain idle request fails.
BUG=chrome-os-partner:35654
BRANCH=veyron
TEST=boot rialto
Change-Id: I8be1567040ddb5f2a2b0d06568e517d794ead87a
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/250060
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 927e8426104f8869e139c3f60a04cd49bf726e61)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255973
Gold Linker does not support properly customized ld script.
BRANCH=none?? Is this correct? I am not sure of this.
BUG=chromium:461220
TEST=build coreboot under rush_ryu
Signed-off-by: Han Shen <shenhan@google.com>
Change-Id: Ic2f5a8000d764ff7374aa1aaa00895dafb75f307
Reviewed-on: https://chromium-review.googlesource.com/252870
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Han Shen <shenhan@chromium.org>
Tested-by: Han Shen <shenhan@chromium.org>
(cherry picked from commit 319365c7b11a5e48d8ecc5141b4b954c5533c85d)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255972
This patch adds a few retries to NVRAM read/write transactions with the
EC. Failing to read the NVRAM is not fatal to the boot, but it's still
pretty bad... especially since a single initial read failure will cause
vboot to blindly reinitialize the whole NVRAM with zeroes, destroying
important configuration bits like dev_boot_usb. The current EC
transaction timeout is one second, so the three retries added here can
potentially increase boot time by three seconds per transaction... but
this shouldn't happen in any normal case anyway, and if there are errors
a little extra wait is probably preferrable to nuking your NVRAM.
(Also, added a missing newline to an error message in the EC code.)
BRANCH=veyron
BUG=chrome-os-partner:36924
TEST=Booted a Jerry with the power button bug with a 2 second press,
noticed that the first two transactions failed but the third one
succeeded.
Change-Id: I6267cdda2be2bad34541b687404c2434d3be345b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 894a8a0b4a9805e92544b5e3dfa90baf6d36649a)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251813
This brings brain, danger, and rialto up to parity with other
veyron platforms as far as eventlog functionality is concerned.
BUG=chrome-os-partner:34436
BRANCH=none
TEST="mosys eventlog list" shows events (tested on Brain)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ief09299965f6f21bc5a40cef31cde61344025c2a
Reviewed-on: https://chromium-review.googlesource.com/239979
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 1764bc53147718031231a6d125a4a1a96c4c6a8f)
jwerner: removed danger and rialto
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247157
This applies a previous patch ("chromeos: Provide common watchdog
reboot support") to some veyron platforms that were missing it.
BUG=none
BRANCH=none
TEST=built and booted on Brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I2861939655a995d309847f64cecd974a740fae37
Reviewed-on: https://chromium-review.googlesource.com/245633
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit b0c87dd4217917a35817c719efe43dd4ec442df0)
jwerner: removed danger and rialto
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247156
we use the delay 200ms to meet the edp power timing request before,
it waste time, so we use the HPD function to detect the edp panel now.
In previous version, the hardware may not support the edp HPD function,
so in the code it will spend 200ms to detect hpd single, if it don't get
the hpd single, it will contiue the edp initialization process, to compatible
all of the hardware version.
BUG=chrome-os-partner:35623
TEST=Boot from Mighty, and display normal
BRANCH=None
Change-Id: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242792
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
(cherry picked from commit 7a5343eb9af12cae9a15284217762a91ae24bac6)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247155
we use Kconfig define sdram size before, but there may use
different sdram size in the same overlay, so we must detect
sdram size at runtime now. If we use 4G byte sdram, we can
use[0x00000000:0xff000000], since the [0xff000000:0xffffffff]
is the register space.
BUG=chrome-os-partner:35521
TEST=Boot from mighty
BRANCH=None
Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/243139
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ad4f27dd08c467888eee87e3d9c4ab3077751898)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247154
backlight timing: LED_VCC->LED_PWM->LED_EN, we modify the
code to meet the timing.
BUG=chrome-os-partner:36201
TEST=Boot from jerry, and scope the backlight timing
BRANCH=None
Change-Id: I6c53a822410ad706383c6d9fa2b5f0437775f710
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/244639
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 52ac0b2944cea7dc860bfea12fe44851436bb7f7)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247153
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:245530
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245119
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245496
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:245531
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244591
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit eb8142f69cea34e11f9081caafcaae7a15cc3801)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245495
we will use dvs to adjust the voltage in kernel, if device reset
by watchdog in kernel, the dvs gpio may not reset, and we use the
i2c to adjust rk808 voltage in coreboot, so it may failure. so we
move the reboot_from_watchdog() before the rk808 setting.
BUG=None
TEST=Boot from speedy
BRANCH=None
Change-Id: I92b5c6413bbffe30566178de89df1f9683790982
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/244289
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 76efb4b0196eecc84664a4c5dce2221152a39c0a)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245494
Our <arch/io.h> headers are a mess and not in any way as
arch-independent as their pathname makes it sound. CL:242404 made this
blow up, but it's really just surprising that this didn't happen
earlier already.
This patch is just a quick fix to make MIPS ChromeOS boards buildable
again while we deal with the real issue of aligning the interfaces.
BRANCH=none
BUG=chromium:451270,chromium:451388
TEST=Booted Jerry, built Falco and Urara.
Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242504
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243127
Our use of the bucks may exceed their default maximum inductor current.
Just set it to the highest possible value for every buck we configure to
avoid problems... the kernel can later fine-tune the values further if
needed. (Also some slight grammar updates while I'm in there.)
BRANCH=veyron
TEST=Build and Boot on Jerry
BUG=None
Change-Id: I3801cabeb93d7bf7ecc02db0e69d4932c9394db9
Signed-off-by: huang lin <hl@rock-chips.com>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242785
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from commit 065a163bb902b8c96d05bfef6ed4885aa20f31cc)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243126
tMRD request 10nCK in LPDDR3, we set the DDR_PCTL_TMRD BIT0~BIT2 to generate
this single, but the max value we can set is 7, can not meet the standard.So,
now we send the Mode Register Set command manual,and we can add the delay
manual.
BUG=chrome-os-partner:34608
TEST=loop reboot
BRANCH=veyron
Change-Id: I0d29ea9cd82ef018e835ae53090a47d0299ef61d
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242176
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit b60a4de6ff3ad3720c2c06ed7de03ed942360e6c)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243125
the reset single request 200us, we set the DDR_PUBL_PTR2 BIT0~BIT16 to
generate this single, when DDR run the 666Mhz, we calculate the value 0x20850,
exceed 0x1ffff(max value support by 17bit), so only 0x850 work, it only
generate 3.5us reset single, whitch don't meet the standard. So, now we set to maximun
when the value overflow, the reset single is 196us when ddr run the 666MHz.
BUG=chrome-os-partner:34875
TEST=loop reboot
BRANCH=veyron
Change-Id: I9b410e1605c87f12a5ca96ead12f8527ca4f417f
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242175
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 767a4a3cb8dff47cb15064d335b78ffa5815914d)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243124
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit fffc484bb89f5129d62739dcb44d08d7f5b30b33)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243123
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242630
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243122
