LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I38bf99e38822fd0883fd4d0bd9a1b01143545a95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f3149efbc3aa9a03ab3fd5be99d17d9c5e1c87
Original-Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228292
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-on: http://review.coreboot.org/9547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The veyron_jerry board code was just copied over from veyron_pinky
1-to-1. The Jerry board IDs start at 1, but there has never been a Jerry
rev0 so we can remove the code for board ID 0 from it.
BRANCH=none
BUG=None
TEST=Booted Jerry image on a Pinky rev2, worked fine.
Change-Id: I0f2ffdc577934c1695e8d2dcf71512696ac1d5a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aa36da69ac584b845e15282dae100eec27fc7f12
Original-Change-Id: I45a18b288c8d8b1399ceedf582addcce1c7e857d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228254
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9546
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The eMMC enable pin is in a 3.3V IO domain. Unfortunately the eMMC
expects this pin to be 1.8V. The way we were driving this pin would
cause the eMMC to pull power through this pin and that was causing
current leaks.
In future revisions of hardware we should move this pin somewhere more
legit. However, in the current hardware we can get things working
pretty well by using a pullup to "drive" this pin. This will work in
conjunction with the external 100K pullup to give a somewhat
reasonable voltage. The eMMC will also not be able to pull much
current through this pin, so it can't leak too badly.
BRANCH=none
BUG=chrome-os-partner:33319
TEST=Boot a kernel that doesn't touch the mux/pulls and see no leak:
dut-control --port=${SERVO} vcc_flash_ma -t 5
Change-Id: Ibc25cd090d826c8215be24a0b5c11d97b5281700
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 26e7a9d7e067ed4dd859387ee63bf654ab9dc529
Original-Change-Id: Iadfc1477cd478773cc9d159e3fbc22b66b8f0f78
Original-Signed-off-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226039
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9545
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is essentially a copy of veyron_pinky for now.
BUG=chrome-os-partner:33269
TEST=build and boot
Change-Id: I151c82f54ece4620953d0db5aedf027a3293926f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 267611f2354be4384de3f05d2459a4e421ee6b4f
Original-Change-Id: I0d473361e0850ee3b11da5a809f8396826ccdad6
Original-Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225301
Reviewed-on: http://review.coreboot.org/9544
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Invoke the function which copies WiFi calibration data in a CBMEM
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that the WIFI entry is added to CBMEM when the
calibration data is present in the VPD.
Change-Id: Icab0a2343e88e1d44575eeb608fdf6588aff255b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 68b96f158633cb3a1f157b5a19da39fa7e78f975
Original-Change-Id: I5fa77da98e37b88da01fb7884e713535fc178006
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225272
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9543
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CPU on/off functions are the method for the Kernel to support CPU
hot-plug function in PSCI. To support this, we still need flow controller
support to capture the WFI from the CPU and inform PMC to power gate the
CPU core. On the other path, we turn on the CPU by toggling the PMC and
use flow controller to let go when the power is steady.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=built the kernel with PSCI enabled,
check both of the CPUs are coming up,
test the CPU hot-plug is working on Ryu
Change-Id: If2c529b6719c5747d5aea95fb5049b2d7353ff17
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f078e89daad1c4d8b342a395f36b3e922af66f5
Original-Change-Id: Ie49940adb2966dcc9967d2fcc9b1e0dcd6d98743
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231267
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9542
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With support for initializing registers based on values saved by primary CPU, we
no longer need to invalidate secondary CPU stack cache lines. Before jumping to
C environment, we enable caching and update the required registers.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu.
Change-Id: Ifee36302b5de25b909b4570a30ada8ecd742ab82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0a0403d06b89dae30b7520747501b0521d16a6db
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I738250f948e912725264cba3e389602af7510e3e
Original-Reviewed-on: https://chromium-review.googlesource.com/231563
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9541
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Change-Id: Ia4ca0e7d35c0738dbbaa926cce4268143c6f9de3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f5e78469313ddd144ad7cf5abc3e07cb712183a
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Original-Reviewed-on: https://chromium-review.googlesource.com/231561
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some registers are available only at EL3. Add conditional read/write functions
that perform operations only if currently we are in EL3.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: Ic95838d10e18f58867b6b77aee937bdacae50597
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 62a0e324a00248dba92cb3e2ac2f4072d0e4e2a7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: Ia170d94adb9ecc141ff86e4a3041ddbf9045bc89
Original-Reviewed-on: https://chromium-review.googlesource.com/231549
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9538
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I96312e62a67f482f4233c524ea4e22cbbb60941a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ae71f87143f899383d8311a4ef908908116340d7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Original-Reviewed-on: https://chromium-review.googlesource.com/231548
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9537
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update non-vboot2 memlayout:
1) Add timestamp region
2) Increase ramstage size
3) Change name from memlayout_vboot.ld to memlayout.ld so that any non-vboot
upstream board can also use this layout.
BUG=None
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu with vboot selected instead of
vboot2.
Change-Id: Idced98f9df7cdbab5f62cd1e382c6046ade1d867
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20fffa282b20fb32ce2ff687f4479be630f90fcf
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I91accd54efc53ab563a2063b9c6e9390f5dd527f
Original-Reviewed-on: https://chromium-review.googlesource.com/231547
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9536
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of having unified CBFS_CACHE and limiting the POSTRAM Cache size, split
them into PRERAM and POSTRAM CBFS_CACHE.
BUG=None
BRANCH=None
TEST=Compiles successfully for both rush and ryu. Boots to kernel prompt on ryu.
Change-Id: I2a70df22fe5bae23e05cdf1b8a300369c7ccf87d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b93bc06de76cab0a1ec9a56e12c9a6942a430893
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: Iab21ff5c7ca880b6bd18846e5d8d71c26dff56cf
Original-Reviewed-on: https://chromium-review.googlesource.com/231546
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9535
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A couple of regs need to be poked to allow audio output
from this part on Ryu P0/P1. It will be replaced by two
non-configurable amps on P3.
BUG=none
BRANCH=none
TEST=Build/flashed on Ryu P1, dumped AD4567 (I2C6 dev 0x34)
regs and confirmed settings.
Change-Id: Ie602b056fb1488546ab233f8f81cfacb96624ebb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75dabe378b561e939381e2ef5113a2b28bfcedf8
Original-Change-Id: I8999843646927dbd07a179ede973ba5f1eb97167
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231384
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9532
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to start CPUs while in secmon/psci one needs to
set up the proper SoC state. Therefore, refactor the current
CPU startup API to allow for this by adding cpu_prepare_startup()
and start_cpu_silent().
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted kernel.
Change-Id: I1424500f6c9398f7d44350949c25bb3d4832cec7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f9cf67085b345b529b41dd6554e37d38a5b350
Original-Change-Id: I842a391d3e27ddbfcdef1a2d60e3c66e60f99c77
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231936
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9531
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
psci_soc_init() was added to allow SoC PSCI initialization.
However, actually calling said function was omitted accidentally.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and noted correct on entry point was used.
Change-Id: I84a397e2dabf149fe8f252ef69d0a7362fa1f194
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a0e6ad41f049bbab483423231db59390894e9b2
Original-Change-Id: I1a4e25fde64ecdc98fa9231f7d9cafc21119630d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231935
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Based on TPS65913, the max LDO turn on time is 500us. Since it is requested
the default delay of 500us when calling function pmic_write_reg(), it is
safe to remove this 100ms delay.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I2cfda38728db223c26f9122b70d37e828921459a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 271b7e95f66f4b8611a0d408e59f428c315074f3
Original-Change-Id: I53aecc273484edfa502231b44f6bcd7f5d8f9331
Original-Reviewed-on: https://chromium-review.googlesource.com/231170
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: http://review.coreboot.org/9529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The bootblock on Rush had bumped up into the verstage
allocation, causing the build to break. Reduced verstage from
60K to 58K and increased bootblock from 20K to 22K. Rush and
Ryu both build fine now.
BUG=none
BRANCH=none
TEST=Built both Rush and Ryu OK. Verifed verstage size
using cbfstool and it's around 55K, so plenty of room.
Change-Id: Iaa3a5838c5235ec78c740a977bc032d8b5e270ef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 928a4d2d1efabe1e1d6a7fadc22ee0ac4269190e
Original-Change-Id: I7018f027d72d5e8aeb894857a5ac6a0bdc1de388
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/230824
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9528
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Secondary CPUs were intermittently not coming online as expected.
Upon investigation it was found that a cache line needed to be
invalidated that corresponded to the top of the stack for the
failing CPU.
Currently the secondary CPUs come online with caching disabled.
However, the code paths are using C and thus the stack it is assigned.
The MMU is enabled in C after it's pushed its return path onto the
stack that went directly to ram. When the cache line corresponding
to its stack is valid in the cache it will hit once the MMU is enabled.
That hit will have invalid data w.r.t. the return addresses pushed
directly into ram.
This is not the best solution as the only way to guarantee we don't
hit such a situation is to tightly manage resource usage up until
the point of MMU enablement. That can be done in a followup patch.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=On ryu where secondary CPUs weren't coming online consistently,
they now come up.
Change-Id: I03237656da180d1f74df3a8e00029ba8d778bca8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06ab6afc996cf92c45d4cd6850e31167c2946a95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: I32de749ea48c19e23442e6dc5678c5369ac3b2b6
Original-Reviewed-on: https://chromium-review.googlesource.com/231219
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9527
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial MP code assumed all CPUs would come online. That's not
very defensive, and it is a bad assumption. Provide a timeout
mechanism for bring CPUs online.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Multiple times with CPUs working and not working. Boot to kernel.
Change-Id: Ib0aef31f5c732816d65c2e4b3c6a89e159974fdc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9cf5bc2844c8f4ad987cfcb69ef33c73551f0083
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: Ifb3b72e3f122b79e9def554c037c9b3d6049a151
Original-Reviewed-on: https://chromium-review.googlesource.com/231070
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9526
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The kernel does not correctly function without PLLD being enabled.
Additionally, PLLD can be the source for other clocks in the system.
Therefore, initialize PLLD to 300MHz unconditionally at BS_DEV_INIT
time in ramstage.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted ryu with display coming up both in dev mode as
well as normal mode.
Change-Id: Ib2a60bb9aafc03dc23aa932a480184d87f677c65
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c49f964b55c3c33d03b95363277b262b679e740
Original-Change-Id: Ic5905e25051a042cea5010b8c6d61b1fb89a0a81
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230774
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://review.coreboot.org/9525
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide an explicit name for configuring PLLD. The new name,
clock_configure_plld(), provides an explicit semantic to
what it is doing. Also, provide the printk() about actual
frequency vs requested frequency as most of the callers
were doing this themselves.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I1880f0f305e69674922b070d282aac3acdc86aad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c51d5b0864d8bd0db5927380803cec46ccd74d48
Original-Change-Id: If744332b466d9486f83b08d0ab4e9006fadfecdd
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230773
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://review.coreboot.org/9524
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Ryu RT5677 audio codec uses EXTPERIPH1 clock (12MHz)
for MCLK1, I2S1 for input. AHUB needs all of its child
peripherals taken out of reset and enabled, too.
This just sets up the audio clocks. More work still to
be done in the codec driver, and some kind of stub needs
to be created/hacked to set up the AD4567 speaker amp
regs for mono output on P1.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=Dumped clock regs and saw correct values
Change-Id: Ifb6551f1e09b38f440f3bb7c759b5e6c0b9e4e44
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48f989a0291044f5fb4340cc89546325d819d82f
Original-Change-Id: I6c9e760ac39def92a6054d673f781facdbfd70a2
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229993
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9523
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When displaying a 800x600 bitmap on 2560x1800 panel, the image
is shown very small. So, set the fb to 1280x800 (based on tegra
dsi driver default mode setting), a 800x600 image can be shown
relatively proportional to panel size.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I1e360aeaec97b9df5d86e46951ab1326610260d2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 67c2a381322721a24b1b7f9ac366073b7e3c490c
Original-Change-Id: I62cbe9de1d1002293df20f8b1d752905c6ef33aa
Original-Reviewed-on: https://chromium-review.googlesource.com/229912
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9521
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Framebuffer line size and number of lines can have different
values than panel's resolution.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: I228f1dd7fafc6577a8e8a987ff31ba73f7a655ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a4929dc5831076f2f2a5dd2e13f24b3477e197b
Original-Change-Id: Iedeef796f02286bb03920413420f8952cf34334a
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229915
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9520
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
panel spec such as resoultion, bits per pixel are
needed to pass to depthcharge/payload for displaying
bitmap onto panel.
Enable display code only if mainboard selects
MAINBOARD_DO_NATIVE_VGA_INIT. Otherwise build breaks for
boards that do not support display init yet.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=Compiles for both rush and ryu. Display comes up for ryu in both normal and
dev mode.
Change-Id: I81b4d289699e7b0c2758ea1a009cbabaf8a2ce28
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b9b42486f203d332f6068ccd6f4a1a982d327a6b
Original-Change-Id: I5c8fde17d57e953582a1c1dc814be4c08e349847
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Commit-Id: ce2883b21d3fbfd54eac3a355fb34ec70e9f31ad
Original-Change-Id: Ib4a3c32f1ebf5c6ed71c96a24893dcdee7488b16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/9519
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stack and Timestamp need lesser than 2K and since romstage is running out of
memory, adjust the overall memory assignment.
BUG=chrome-os-partner:33676
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I5076252ae87268bd4e964c282d1cc337e0ea4e70
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f2d5d29e6f0f5058a41ed30aae98f79574e31609
Original-Change-Id: I0134f25dd49f2940bb159d131aaee12f81e13ef7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229001
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Commit-Queue: Tom Warren <twarren@nvidia.com>
Reviewed-on: http://review.coreboot.org/9512
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Chrome OS support needs to be enabled on urara. This patch adds a
placeholder file to keep Chrome OS support code.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I0731469934f04bd68914f09db5d64758c5d01545
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 169c62c9443c3b9fcab23b312b5cb18ba79437f4
Original-Change-Id: I8ec328d4f965ff80d17847f2f8ce62b402c42a46
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226179
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9466
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
According to BYT platform design guide chap 14.2.2, the NC GPIOs
need to be configured to GPO.
BRANCH=none
BUG=none
TEST=Test on rambi, boot to OS, and make sure NC pins config to GPO
Change-Id: Ida5ea89ee66e39b4fddea242dc918b314756d94f
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 998493566f5cf7abd9375583e12fe631b226e591
Original-Change-Id: Ieaf346d1c7bf3ecb47a71a6ee4afaa805235cc37
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/249060
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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: I5d1cf29ac1c555ea2336ebb0b0e0a3f7cbb9c3fd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 894a8a0b4a9805e92544b5e3dfa90baf6d36649a
Original-Change-Id: I6267cdda2be2bad34541b687404c2434d3be345b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/251694
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Expand the boot block include file to allow for a file containing reset
routines to be added. Prevent breaking existing platforms by using a
Kconfig value to specify the path to this file, and have the code
include this file only if the Kconfig value is set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
Change-Id: I604f701057d7018f2ed9c3ba49a643c4bca13f00
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c109481d9503916e19ed300c1a3f085e0d2b5c51
Original-Change-Id: I3214399f8156b5ea2ef709ce77e3915cea1523a3
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/248300
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Looks like Intel has added two more USB 2.0 ports from LynxPoint to
Broadwell, which shifted the port offsets of the USB 3.0 ports behind
them. The USB 2.0 ports are now 0x480 to 0x520 and the 3.0 ones 0x530 to
0x560 (at least according to what my kernel seems to think). The offset
of the first USB 3.0 port is hardcoded and seems to have been copied
over without accounting for this, meaning when we try to operate on all
USB 3.0 ports we actually operate on the last two 2.0 and the first two
3.0 ports instead.
This patch should fix the bug for now. In the future, we might want to
consider dynamically detecting port locations through the Protocol
Capability structures at the end of the XHCI register set instead.
BRANCH=samus
BUG=chrome-os-partner:35320
TEST=TODO
Change-Id: Ifab6e484980fd4cd0daf80ceb292ddced2ab1aea
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 525f359c0b6b95b260add2b4617fd86119d69397
Original-Change-Id: Ic2becf2b043612270909ceef66e7d58efc8fcbe1
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/247351
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: http://review.coreboot.org/9502
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This changes the PCIe replay timeout value in the root ports
to be 0xD to fix correctable AER replay timer timeout errors.
BUG=chrome-os-partner:31551
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I3084cc633da6e9f9a783d923a3fe2c1097e711fd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a64897efc26731fa3896e6d9a413941807296a28
Original-Change-Id: I53d87ad38856fd7de7f3f06a805c9342373bc968
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245359
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9501
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is needed for audio playback after we disconnect PP1800_CODEC
from DACREF to avoid noise coupled on PP1800_CODEC, which makes
recording noisy.
For recording, DACREF comes from mic vref pump voltage.
For playback, DACREF comes from internal 1.8V.
BUG=chrome-os-partner:32953
BRANCH=samus
TEST=Set MICBIAS to 2.970V on Samus, playback/recording is clean
Change-Id: I65fb6dbfab54c7c4de6496fd4a0d666baead28ec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3e62a61f6cf6042f6d653a827698b55ac86e2d2b
Original-Change-Id: I27430691e469dd7f4056d99438ce080062b58b9a
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241179
Reviewed-on: http://review.coreboot.org/9500
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The default micbias1 voltage is 1.476V (1.8V * 0.82) which does
not match what's specified on the schematic. This patch sets
the voltage to 2.970V (3.3V * 0.90) according to the schematic.
BUG=chrome-os-partner:32953
BRANCH=samus
TEST=Set MICBIAS to 2.970V on Samus and verified with a scope
Change-Id: I1ced834a5afe2de3fccf4bcff8ec9c8e5718f60a
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 176f9272801a3de5ed6fc05ade06042e2a2c0a5c
Original-Change-Id: Icdbc1b5f65fe28591d54544372bdc2dacb50e9c1
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241178
Reviewed-on: http://review.coreboot.org/9499
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this code change provides a way to enable 2x refresh rate
in RW image
In baytrail, it enables 2x refresh rate by default
BUG=chrome-os-partner:35210
BRANCH=none
TEST=check the register is set properly on rambi
Change-Id: I2a935b570c564986898b6c2064fc7ad43506dcba
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c740d403708862514be9fa24f56b2764328979eb
Original-Change-Id: I84f33d75ea7ebfea180b304e8ff683884f0dbe8a
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241754
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9498
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add some configuration options that allow tuning the VR for C-state
settings that may be able to reduce noise.
- Add option to enable slow VR ramp rate for C-state exit
- Add variable to configure the minimum C6/C7 voltage
BUG=chrome-os-partner:34771
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I01445d62fbfcf200b787b924d8d72685819a4715
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: ed8f355e60292c82791817ae31bff58ac2390a72
Original-Change-Id: I8af75b69c8b55d3e210170ee96f8e22c2fd76374
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241950
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9497
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reduce the SATA Gen3 TX voltage amplitude by 210mV based
on the provided test results to help with SATA validation.
BUG=chrome-os-partner:34121
BRANCH=samus
TEST=build and boot on samus and ensure SATA is still working,
firmware image will be provided for full validation.
Change-Id: I574d2f457b7b6831a339602a4165e959a0e2ee7d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9500ec152d8f9c90513811b1a92d1a8c155f514a
Original-Change-Id: I233fa1a9a7f2877a97ef6834304680f82b958e82
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241800
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9496
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To ensure that boot flags (legacy, usb, signed-only) are
properly restored from CMOS and used in the first boot after
a battery removal or RTC reset then the VbNv region needs to
be preserved around the cmos_init call.
When using vboot firmware selection and VbNv is stored in CMOS
then that region of CMOS will have been re-initialized by the
time we call cmos_init and reset CMOS if the chipset flag was
set indicating a problem.
BUG=chrome-os-partner:35240
BRANCH=broadwell
TEST=manual testing on samus:
1) boot in dev mode, enable dev_boot_legacy and ensure it works
2) on EC console pulse PCH_RTCRST_L low for a second
3) ensure first boot after RTC reset will still boot legacy mode
4) remove battery for a time
5) ensure first boot after battery is re-inserted will still
boot legacy mode
Change-Id: Ica256bbdcba6d4616957ff38e63914dd15f645c6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 881c7841c95dec392a66eef38a7112c1f385fdfa
Original-Change-Id: I4c33f183ba4b301d68ae31c41fc6663f3be857b0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241529
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9495
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function will use the next available/free protected range
register to cover the specified region of flash and write
protect it until the next reset.
This will be used by the common MRC cache code to protect the
RW_MRC_CACHE region after it is updated.
In order to communicate to the common NVM code that this function
is defined also enable CONFIG_MRC_SETTINGS_PROTECT variable.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I710c6a69f725479411ed978cc615e1bb78fb42b8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 25365433be0f190e10a96d9946b8ea90c883b78a
Original-Change-Id: I4a4cd27f9f4a94b9134dcba623f33b114299818f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241129
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9493
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Julius Werner