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
This patch adds a new "backlight" output GPIO to the coreboot table in
order to avoid redundantly defining that GPIO in the payload.
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Tested together with corresponding depthcharge CL.
Change-Id: I69b3c7ac6be4b9723b6a0dfecef5e1c4ea681aff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242400
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 04ce4c23573cf926aeef3d817d3ab00835f897c7)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243121
The first platform that used flash-backed VBNV data has a physical
recovery switch, get_recovery_mode_from_vbnv() was never implemented.
This patch adds get_recovery_mode_from_vbnv() similarly to how it's
implemented for other vbnv storage in other places.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9
Reviewed-on: https://chromium-review.googlesource.com/239978
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 09f1bf96089bf9d159e4220c1f4d99388d709545)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243120
BRANCH=None
TEST=Build speedy, pinky, mighty
BUG=None
Change-Id: I7c97d54f3a4c94f7e23d3e85b808cd64b1cacec7
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/241939
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e6be62b4e64b13e285eb0480fdc65d814c6dadc0)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243099
I always had that TODO comment in there but I had already forgotten what
I even meant by it. It's really just a simple cleanup... this function
is (currently) veyron-specific and doesn't belong in common code.
BRANCH=veyron
BUG=None
TEST=Booted Jerry.
Change-Id: I6ce701a15a6542a615d3d81f70aa71662567d4fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241190
(cherry picked from commit d188398704575ad2fedc2a715e609521da2332b0)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243098
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:243110
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240819
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243097
K4B4G1646Q-HYK0 is different form K4B4G1646D-BYK0 with chip physical
package and they have the same config parameters.
BRANCH=none
BUG=chrome-os-partner:34940
TEST=boot on Jerry board with K4B4G1646Q-HYK0
Change-Id: I31bcb348a45ff76e8e08127063bd0d04443ccb79
Signed-off-by: Paul Ma <magf@bitland.com.cn>
Reviewed-on: https://chromium-review.googlesource.com/241787
Reviewed-by: Julius Werner <jwerner@chromium.org>
Trybot-Ready: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e925d784e1ebe444f5a5bcab47c8a661b0c6c527)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243096
We've decided that it is generally okay for coreboot to expect unaligned
accesses to work. Trying to find all instances of unaligned access
opportunities and working around them in software would be an
unsustainable whack-a-mole contest. Instead, architectures and boards
need to make sure they conform to this, which on ARM and ARM64 requires
setting up paging early in the bootblock.
Other architectures (x86, ARM64, MIPS) already generate code in this
manner. ARM still had an -mno-unaligned-access flag hanging around that
has been copied so many times its initial origin was lost in time
(probably U-Boot). Let's remove it for consistency between architectures
and to improve code generation.
BRANCH=veyron
BUG=None
TEST=Booted Jerry and Blaze. Looked at the disassembly for
timestamp_sync() and confirmed that it only gives you half as much eye
cancer as before (GCC still somehow insists on byte accesses when
zeroing fields which is very odd, but at least that terrible AND/OR mess
is gone). Measured a boot time increase of about 11ms on Jerry (mostly
faster timestamp and CBFS accesses). Could not test Storm because
despite our claimed abundance of test devices, every time I get one of
them it magically disappears again in less than a week.
Change-Id: I1d046e05bb11822b86e467eafb6aa92e8fbce774
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241732
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242162
Toolchain variables (CFLAGS, INCLUDES, etc.) defined by
create_class_compiler can be updated in toolchain.inc only after call
to create_class_compiler is performed. Here, CFLAGS_nonx86 was added
to CFLAGS_arm64 before create_class_compiler and hence the flags did
not show up during compilation.
BUG=None
BRANCH=None
TEST=Checked that dummy unused function does not show up in
ramstage.elf for ryu.
Change-Id: Ia152aaeef6d68f31eddda88506ee6630749f9dbb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/239245
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242161
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
LDO4 and LDO5 are not turned on with the boot0 and boot1 RK808
strappings that we use on Brain.
BUG=none
BRANCH=none
TEST=built and booted on brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I846ef9d67a780cc07414d545524b9ec0b8490cf1
Reviewed-on: https://chromium-review.googlesource.com/241734
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242160
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
decode_edid() parses the whole edid buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent edid parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/240643
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242159
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This adds a 10us delay in between (re-)configuring and reading
GPIOs in gpio_base2_value() to give the values stored some time
to update.
As far as I know this hasn't bitten us since the function was
added, but adding a short delay here seems like the right thing
to do.
BUG=none
BRANCH=none
TEST=built and booted on Brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I79616a09d8d2ce4e416ffc94e35798dd25a6250d
Reviewed-on: https://chromium-review.googlesource.com/240854
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242158
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Even though coreboot always hardcodes the FMAP offset, the same is not
possible for all other tools that manipulate ROM images. Some need to
manually find the FMAP by searching for it's magic number (ASCII
"__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__",
...) in coreboot code, it has the unfortunate side effect that the
compiler will output that very same magic number as a constant in the
.rodata section to compare against. Other tools may mistake this for the
"real" FMAP location and get confused.
This patch reverses the constant defined in coreboot and changes the
only use of it correspondingly. It is not impossible but extremely
unlikely (at the current state of the art) that any compiler would be
clever enough to understand this pattern and optimize it back to a
straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the
problem at least for another few years/decades.
BRANCH=veyron
BUG=chromium:447051
TEST=Made sure the new binaries actually contain "__PAMF__" in their
.rodata. Booted Pinky. Independently corrupted both the first and the
last byte of the FMAP signature with a hex editor and confirmed that
signature check fails in both cases.
Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240723
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242157
Total FIFO length is split into many 512 byte blocks,
because the max packet size in coreboot is 512 byte,
then allot these blocks to GRXFSIZ and GNPTXFSZ evenly.
This method avoids the hardcoding and make the FIFO size
value work for dwc2 controller that has different FIFO ram size.
BUG=chrome-os-partner:32634
BRANCH=None
TEST=Boot kernel from USB
Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233119
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242156
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
BUG=chrome-os-partner:34436
BRANCH=none
TEST=Built and booted on pinky w/ depthcharge fmap patch,
used mosys to verify that eventlog entries get populated:
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I19cb884be5c3e00975599e96e0223e33d32e7c0d
Reviewed-on: https://chromium-review.googlesource.com/238830
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242155
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Reviewed-on: https://chromium-review.googlesource.com/238525
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242154
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242153
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
The current vbnv flash code mistakenly uses the offset into the NVRAM
area as the absolute offset into the SPI NOR. This causes overwrites
RO section of the flash (when it is not protected) and causes failures
to retrieve the NVRAM contents by the user space apps.
This patch makes sure that the correct offset is used when accessing
NVRAM area in the SPI flash.
BRANCH=storm
BUG=chrome-os-partner:35316
TEST=run the update code on storm.
- no more RO section corruption observed
- running 'crossystem recovery_request=1' at Linux prompt causes the
next boot happen in recovery mode
Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240143
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242152
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Some common VBNV variable offsets were defined in multiple vbnv_*
source files. This moves them to a header so that we can avoid
duplicating them in the future.
BUG=none
BRANCH=none
TEST=compiled for nyan_blaze and rambi
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b
Reviewed-on: https://chromium-review.googlesource.com/239977
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242151
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
