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>
In order for recovery request to be cleared with software sync disabled
we need to implement this function in the mainboard.
BUG=chrome-os-partner:28234
BRANCH=samus
TEST=boot in recovery with software sync disabled, ensure that the next
boot will not boot in recovery again.
Change-Id: Ie9c845396dfc6ab65296b2f18a86e23590c833d6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 430f85608cc3b59a68a86dba64ffe428bfc216a9
Original-Change-Id: Iac15b6a1b23cc971231339439bceb013f4a031bd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241052
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9492
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With recent changes in the 3.14 kernel and the switch to not
using X the panel backlight is not geting turned on until
chrome is started which means the splash screen is not visible.
If we set the backlight PWM in coreboot then it will at least
turn on for the early boot process.
BUG=chrome-os-partner:31549
BRANCH=samus
TEST=boot on samus in normal mode and see the boot splash logo
Change-Id: I81e6b90617acb181b4de3365f8f56ec3b846b78b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f850fe3faff268a64f18e6bd176ec1126b921e3b
Original-Change-Id: I622bef8af9bb6b753fe228b33ecdc4aae76af131
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240853
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order for some panels to meet spec when the system is put
into S5 by way of power button during firmware (i.e. not by
the OS) then it needs to turn off the backlight and give it
time to turn off before going into S5.
If the OS properly sequences the panel down then the backlight
enable bit will not be set in this step and nothing will happen.
BUG=chrome-os-partner:33994
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: Ic86f388218f889b1fe690cc1bfc5c3e233e95115
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e3c9c131a87bae380e1fd3f96c9ad780441add56
Original-Change-Id: I43c5aee8e32768fc9e82790c9f7ceda0ed17ed13
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240852
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9490
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When disabling PCIe ports skip steps if no card is detected.
This prevents the loop from timing out on each empty slot.
BUG=chrome-os-partner:31424
BRANCH=broadwell
TEST=build and boot on samus, check that this code is
no longer timing out when disabling PCIe ports
Change-Id: I84ee0e0e325784b3af06abe70420c07cf6e13ed2
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d759e2350dd00ceb7df196ac7008729dc1e4cef
Original-Change-Id: Idd88f0f1191a5465a0d8dcca07b5c3a5c5ca8855
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240851
Original-Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9489
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The workarounds in ACPI methods for D0/D3 transition that are
used on haswell/LPT do not all apply to broadwell/WPT.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus, test USB functionality and wake
and ensure the device still does into D3 state
Change-Id: Ic3a75f5bf50e826ade7d942b48cfebb75cf976e6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1b54d105957ee80ca34048c42fb8f241731281cf
Original-Change-Id: I877afd51fc6c9b7906e923b893fc31bdf2cd1090
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240850
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9488
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This changes the broadwell graphics init path to only do the delay
before initializing graphics when running chromeos if we are also
going to execute the option rom.
BUG=chrome-os-partner:33671
BRANCH=samus
TEST=build and boot on samus
Change-Id: Idb7d39b22f7f6dc3be6dfbd2fa3cc2e33d78a397
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f7ed93504a74760f16acb8fb3c6c57ac514b7260
Original-Change-Id: I350f85738efe3d17152de4f025adbfd52ae15b95
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228882
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9474
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We'll need to find a real ACPI device ID for
the rt5677 SPI driver. "RT5677AA" is temporary.
BUG=chrome-os-partner:33495
BRANCH=samus
TEST=load firmware via SPI; hotword detection works
Change-Id: I6dc55c4641c27a38570debe841a6afeb048eb868
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f0d7013b62c78deb82db1a431f079c79eded5270
Original-Change-Id: Ifb4a1b12776669e21c0b7c4679246717d72981ad
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235902
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9486
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
HSIOPC/GPIO71 is used to control power to VCCHSIO, VCCUSB3PLL and
VCCSATA3PLL in S0. PCH will drive HSIOPC low when all the high
speed I/O controllers (xHCI, SATA, GbE and PCIe) are idle.
This patch added a few additional PCIe programming steps as required
in 535127 BIOS Writer Guide Rev 2.3.0 to enable this power saving mode.
BUG=none
BRANCH=none
TEST=tested on Paine watching GPIO71 toggling as expected
Change-Id: Ica6954c125ec3129e2659168f1f23dc861ce5708
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e38f9ef57c480ca5ee420020eb80a1adb3c381d3
Original-Change-Id: I88ef125c681c8631e8b887f7ccf017b90b8c0f10
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238580
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9482
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To support the ACPI device specific properties that conform to the
existing devicetree bindings for this codec (in upstream kernels)
add a _DSD object to the existing codec device.
BUG=chrome-os-partner:29649
BRANCH=samus
TEST=build and boot on samus
Change-Id: Ice808ba7bf2f0378ac5a38afd27dbf6c8cac0da5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: b3fc2d7e5a5878b1fff7627f803b883b38fea28d
Original-Change-Id: I344636171a3086a72087314503bfc99de5945b1f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238857
Original-Reviewed-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: http://review.coreboot.org/9483
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The registers that were used here are for CPT/PPT and not
for HSW/BDW chips.
Update this to update just the Gen3 TX Output Voltage Downscale
Amplitude Adjustment field in the SATA ECR T88.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I94b702dc4a3c98678ba048ff9cfa4a85cc5b1eed
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4c5816cc647b84266751e8a591eb85d7735fee12
Original-Change-Id: I98ec9678938a6675828721d5b57683077f555d21
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238800
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9484
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Added a few bits to set in finalize step from scrubbing BWG
and reference code.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I7b0c4dd3f14c06175c973561760ad1bdafd46fbb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3802aef908849fe6ea2bb0034d884064154ae9da
Original-Change-Id: Ia62055b32be039eef84a0f60f0ba307eb5dce6a1
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239958
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9485
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The original code uses L1EXIT_MASK to shift the bit for
PCIe L1 exit latency, the code should use L1EXIT_SHIFT
for bit shifting.
BUG=chrome-os-partner:34037
BRANCH=None
TEST=build and boot on candy, verify B0:D28:F0 + 4Ch [17:15]
set to 010b. Correspond WIFI device performance got improvement.
Signed-off-by: Kevin L Lee <kevin.l.lee@intel.com>
Change-Id: I3ac5b6319b726aa16cdb9678face89022d979517
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 381827e3d92c9e786cd8ebe412586968662fb4be
Original-Change-Id: I8171f80720830cfa76f26778ae31c7590a723b92
Original-Reviewed-on: https://chromium-review.googlesource.com/234673
Original-Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Reviewed-on: http://review.coreboot.org/9480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPM driver by default allocates a 4K transfer buffer on the stack,
which leads to lots of fun on boards with 2K or 3K stack sizes. On
RK3288 this ends up writing over random memory sections which dependent
on the memlayout of the day might contain timestamp data (no big deal)
or page tables (-> bad time).
This patch fixes the problem by reducing the buffer size to slightly
above 1K, which still seems to work as far as I can tell. There was
already some really odd code that #undef'ed this value and redefined it
with the lower number in one .c file (unfortunately not the one with the
buffer declaration), with no explanation whatsoever... I'm removing that
and just assume the smaller value will be fine for everything.
BRANCH=veyron
BUG=None
TEST=Booted Pinky and Falco.
Change-Id: I440a5662b41cbd8b7becab3113262e1140b7f763
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3d3288041b6629b7623b9d58816e782e72836b81
Original-Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236976
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using REG_PCI_POLL32 to check if the LINK is active with 50ms timeout.
BRANCH=none
BUG=chromium:431169
TEST=Test on Enguarde, compile ok and boot OS
Change-Id: If98ab4e31d17ec4e62d68b93edcec6d9aee87367
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: cf692ae9aebb43ab46cb07d36b62b300b16be1dc
Original-Change-Id: I490e6ffa40979628edf52a7444808b6d25a6e83d
Original-Signed-off-by: Kevin Hsieh <kevin.hsieh@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231777
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9478
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is being triggered because the base address is added, but
there is nothing that needs done with it in set_resources step
and the ERROR message is tripping suspend resume test scripts.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=boot on samus and check for ERROR strings,
successfully run suspend_stress_test without failures
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231603
(cherry picked from commit bb789492965d92e309a913dc7b9f09f7036c5480)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I565c8af954f1c5a406d2c65f01c274e9259e43ec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9062734d884f814dc880589ee615b4d7e1fdc61a
Original-Change-Id: I2b5f44795f1ee445d509b29bd56f498aea7b7fe3
Original-Reviewed-on: https://chromium-review.googlesource.com/231604
Original-Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9476
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some actions are needed and some are not on the way resume from S3.
BRANCH=master
BUG=chrome-os-partner:33025,chrome-os-partner:33796
TEST=Built the image and confimed the boot_mode is correctly
configured.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: If400df94f970a55f3921a5a2df24038d28beb489
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 40e719618ec101235cdb1755933e719abd873239
Original-Change-Id: Ia042ea8c63c2306e9d6a80d8efa66c4fc0722d85
Original-Reviewed-on: https://chromium-review.googlesource.com/229615
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-on: http://review.coreboot.org/9475
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This combines the board version reading and parsing to
a separate file that is compiled in both romstage (for
early serial output) and ramstage (for smbios tables).
It also adds a new board version that is wrapped back
to number zero as we are running out of available IDs.
BUG=chrome-os-partner:32895
BRANCH=samus
TEST=build and boot on samus EVT1 and EVT2 and check
for proper board versions reported in console and smbios.
Change-Id: I8c8f17708ced7167277a98529ff4597589f53095
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3ab8bba1021a8dd41dd2210ba73efd2231eb596c
Original-Change-Id: I2aa03e7486a9581f94dc4e12f6f29eb0c5b3bdbb
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229041
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9473
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a ramstage driver for the TPM and allows the interrupt
to be configured in devicetree.cb.
The interrupt vector is set like other PNP devices, and the
interrupt polarity is set with a register configuration variable.
These values are written into locality 0 TPM_INT_VECTOR and
TPM_INT_ENABLE and then all interrupts are disabled so they are
not used in firmware but can be enabled by the OS.
It also adds an ACPI device for the TPM which will configure the
reported interrupt based on what has been written into the TPM
during ramstage. The _STA method returns enabled if CONFIG_LPC_TPM
is enabled, and the _CRS method will only report an interrupt if one
has been set in the TPM itself.
The TPM memory address is added by the driver and declared in the
ACPI code. In order to access it in ACPI a Kconfig entry is added for
the default TPM TIS 1.2 base address. Note that IO address 0x2e is
required to be declared in ACPI for the kernel driver to probe correctly.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=manual testing on samus:
1) Add TPM device in devicetree.cb with configured interrupt and
ensure that it is functional in the OS.
2) Test with active high and active low, edge triggered and level
triggered setups.
3) Ensure that with no device added to devicetree.cb that the TPM
is still functional in polling mode.
Change-Id: Iee2a1832394dfe32f3ea3700753b8ecc443c7fbf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fc2c106caae939467fb07f3a0207adee71dda48e
Original-Change-Id: Id8a5a251f193c71ab2209f85fb470120a3b6a80d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226661
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9469
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Aaron Durbin