This was tested at the coreboot meeting in Berlin.
The uart programming may still not be right but when used with
the lowrisc bitstream for the board we were able to load
and start linux, although it does not yet get far due to
PTE version issues with lowrisc.
Change-Id: Ia1de1a92762631c9d7bb3d41b04f95296144caa3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17132
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This patch updates the _ART table with other external sensor
TSR0 for Fan speed control on Skylake-U based Kunimitsu and
Lars boards.
Also, updates the temperature values in DPTF policy for
better performance.
BUG=chrome-os-partner:51025
BRANCH=firmware-glados-7820.B
TEST=Built and booted on kunimitsu and lars EVT boards.
Verified this updated _ART table on these boards with
different workloads.
Change-Id: Ib195910c5eb00e004e8b9bd50e266ade3c175be2
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/332349
Reviewed-on: https://review.coreboot.org/17066
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In certain cases a board variant may need to override the NHLT
OEM strings in the main NHLT table. Therefore, provide that path.
BUG=chrome-os-partner:56918
Change-Id: I57cc4fd3665698e41ceebb1949180f86bb60b61f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17167
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Going forward GPIO_17 is used to determine the configuration of
the board w.r.t. the number of DMICs on the board.
BUG=chrome-os-partner:56918
Change-Id: I03edb880e0649977030c1b87219ebebac631a519
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17163
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
While using '3' is fine for the standard gpe0 for skylake, I want
to make sure anyone that copies this code doesn't tweak GPE0_REG_MAX
without the hard coded index. If that does happen now things will
still work, but it may just not match the hardware proper.
BUG=chrome-os-partner:58666
Change-Id: I434b9a765a0a2f263490bb2b4ecb3635292d46c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17160
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add a GPIO macro that allows a pin to be routed to the APIC with
the input inverted. This allows a normal interrupt to get used as
a GPE during firmware and still be used as a perhiperal interrupt
in the kernel.
BUG=chrome-os-partner:58666
TEST=boot en eve and use TPM IRQ in firmware and OS
Change-Id: I77f727f749fdd5281ff595a9237fe1e634daba96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17176
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In RS485 mode RTS line acts as a transceiver direction control.
The datasheet is not very clear about the polarity but register setting
here is tested to drive nRTS line high when transmitting.
Also note revision of B of the super-IO has errata and 8N1 setting does
not work properly, you would need revision C of the chip assembled to
fix this.
Change-Id: I705fe0c5a5f8369b0a9358a64c74500238b5c4ba
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14998
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In anticipation of getting fixed material remove the disabling of
periodic training for MT53B512M32D2NP and MT53B256M32D1NP.
BUG=chrome-os-partner:59003
Change-Id: Iaadaa979d85cab78dda527db7480420af02fd832
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17130
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Explain the reasoning for the part_num strings used in the
memory SKU table explaining the necessity of keeping mosys
in sync with the strings used. It's possible that actual part
numbers could change as the higher speed material gets cheaper,
for example.
BUG=chrome-os-partner:58966
Change-Id: If895e52791dc56e283261b3438106116b8b2ea05
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17129
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add the necessary infrastructure to support eSPI SMI events,
and a mainboard handler to pass control to the EC.
BUG=chrome-os-partner:58666
TEST=tested on eve board with eSPI enabled, verified that lid
close event from the EC during firmware will result in an SMI
and shut down the system.
Change-Id: I6367e233e070a8fca053a7bdd2534c0578d15d12
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17134
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Export the pmc_gpe_init() function from pmc.c to pmutil.c
so it can be used in bootblock, and then call it from there
to initialize any GPEs for use in firmware.
BUG=chrome-os-partner:58666
TEST=test working GPE as TPM interrupt on skylake board
Change-Id: I6b4f7d0aa689db42dc455075f84ab5694e8c9661
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17135
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the SOC definition for acpi_get_gpe() so it can be used
by the I2C TPM driver. Also add the I2C support code to
verstage so it can get used by vboot.
BUG=chrome-os-partner:58666
TEST=boot with I2C TPM on skylake board
Change-Id: I553f00a6ec25955ecc18a7616d9c3e1e7cbbb8ca
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17136
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Deep S3 state will lose a lot of register contents that we
used to rely on for determining wake source.
In order to make use of this override the enable bit for wake
sources that are enabled for Deep S3 in devicetree.cb.
BUG=chrome-os-partner:58666
TEST=check for _SWS reporting wake source on S3 resume on skylake
Change-Id: If5113d6890f6cbecc32f92af67a29952266fe0ac
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17137
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Remove the FADT from the individual mainboards and select and
use COMMON_FADT in the SOC instead. Set the ACPI revision to 5.
Change-Id: Ieb87c467c71bc125f80c7d941486c2fbc9cd4020
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17138
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Those registers are only used on more recent Intel platforms featuring a
PCH. The DP registers on G4X hardware are at a different offset.
Change-Id: I4660e547426ccec0b2095d897e4a8c86e0acf41e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17111
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Those registers are only used on more recent Intel platforms featuring a
PCH. The DP registers on G4X hardware are at a different offset.
Change-Id: Ib49e54d4e7d6595dc09fb1be35ac8178b80c7f71
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17110
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Also drop an odd comment about the resource allocator which seems to
work fine, with the right id.
Change-Id: I9099211fe946c28f90dd7730345b81a3f7f6f545
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/17095
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Three things are required to enable wake-on-usb:
1. 5V to USB ports should be enabled in S3.
2. ASL file needs to have appropriate wake bit set.
3. XHCI controller should have the wake on attach/detach bit set for the
corresponding port in PORTSCN register.
Only part missing was #3.
This CL adds support to allow mainboard to define a bitmap in
devicetree corresponding to the ports that it wants to enable
wake-on-usb feature. Based on the bitmap, wake on attach/detach bits in
PORTSCN would be set by xhci.asl for the appropriate ports.
BUG=chrome-os-partner:58734
BRANCH=None
TEST=Verified that with port 5 enabled, chell wakes up from S3 on usb
attach/detach.
Change-Id: I40a22a450e52f74a0ab93ebb8170555d834ebdaf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17056
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use intel common infrastructure to enable support for write-protecting
SPI flash range. Also, enable this protection for RW_MRC_CACHE.
BUG=chrome-os-partner:58896
TEST=Verified that write to RW_MRC_CACHE fails in OS using
"flashrom -p host -i RW_MRC_CACHE -w /tmp/test.bin"
Change-Id: I35df12bc295d141e314ec2cb092d904842432394
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17117
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Write-protect SPI flash range provided by caller by using a free Flash
Protected Range (FPR) register. This expects SoC to define a callback
for providing information about the first FPR register address and
maximum number of FPRs supported.
BUG=chrome-os-partner:58896
Change-Id: I4e34ede8784e5587a5e08ffa10e20d2d14e20add
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17115
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
According to: "Intel ® 4 Series Chipset Family datasheet"
the IGD only has 1 IRQ pin.
Change-Id: I974f002f5a213056f4593a1eab10772527bb241d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17098
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This fixes an instability on 945gc where the IGD completely locks
up the system, when for instance tasked to do something with
compositing (like GNOME or GDM).
TESTED on ga-945gcm-s2l and d945gclf
TEST: launch GDM (gnome display manager)
Change-Id: Iec49bccf3e3164df9dc1e0b54460a616fe92e04d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17094
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
Add support for Kaby Lake RVP3.
Use kunimitsu at commit 028200f as base.
Kabylake RVP3 is based on Kabylake-Y with onboard Dual Channel
LPDDR3 DIMM.
* Update board name to kblrvp
* Remove fsp 1.1 specific code( As Kabylake uses fsp2.0)
* Remove board id function.
* Remove unused spd & add rvp3 spd file.
This is an initial commit does not have full support to boot.
Will add more CLs to boot Chrome OS with depthcharge.
Change-Id: Id8e32c5b93fc32ba84278c5c5da8f8e30c201bea
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17032
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
CQ-DEPEND=CL:379684
BUG=chrome-os-partner:58064
TEST=verified on hana rev0
Change-Id: Icd076dcaf07a97f3b83b428b9619e8a4dafe744d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7c483951a0dcd419735fffb79e6187f9ca3b08a8
Original-Change-Id: I9d886abf15931496ac61e8fd38d7fd306f2a1bf7
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/379504
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Philip Chen <philipchen@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There are some sdram configurations that are no longer used. Drop them.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ib6d2d58c3071147a3095bc1ed7fa7b02c748e1a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 111d375005ec6a3b91e47acdd676e8f1644c931c
Original-Change-Id: I5f9278093f02e785b2894faa8e8cf09ecec20325
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/399122
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17103
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We found sdram may fail in pctl_cfg(), so we check the status in this
function. If it exceeds 100ms still in this function, we will restart
the system. We also found there are rare chances DDR training fails,
so also restart system in that case.
BUG=chrome-os-partner:57988
BRANCH=None
TEST=coreboot resets on failure and eventually the system comes up
Change-Id: Icc0688da028a8f4f81eafe36bbaa79fdf2bcea74
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 89e45f8352f62e19a203316330aba14ccc5c8b11
Original-Change-Id: If4e78983abcfdfe1e0e26847448d86169e598700
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/397439
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17045
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It's a better default than QEMU-armv7, which is currently the default
board when coreboot is configured for the first time, because most
coreboot development targets x86.
With this patch, the minimal steps to coreboot+SeaBIOS booting in QEMU
become:
git clone https://review.coreboot.org/coreboot.git && cd coreboot
make crossgcc-x86
make olddefconfig && make
qemu-system-x86_64 -bios build/coreboot.rom
Change-Id: Ie44a5d95547a55df93f29082c3b5a86fb83aa1e7
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16987
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently, the only supported DSM type is I2C
HID(3CDFF6F7-4267-4555-AD05-B30A3D8938DE). This provides the required
callbacks for generating ACPI AML codes for different function
identifiers for I2C HID.
BUG=chrome-os-partner:57846
Change-Id: Ia403e11f7ce4824956e3c879547ec927478db7b1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add acpigen_write_dsm that generates ACPI AML code for _DSM
method. Caller should provide set of callbacks with callback[i]
corresponding to function index i of DSM method. Local0 and Local1
should not be used in any of the callbacks.
BUG=chrome-os-partner:57846
Change-Id: Ie18cba080424488fe00cc626ea50aa92c1dbb199
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17090
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Export i2c_generic_fill_ssdt to allow other device-specific i2c
drivers to share and re-use the same code for generating AML code for
SSDT. In order to achieve this, following changes are required:
a. Add macro I2C_GENERIC_CONFIG that defines a structure with all
generic i2c device-tree properties. This macro should be placed by the
using driver at the start of its config structure.
b. Accept a callback function to add any device specific information to
SSDT. If generic driver is used directly by a device, callback would be
NULL. Other devices using a separate i2c driver can provide a callback
to add any properties to SSDT.
2. Allow device to provide _CID.
BUG=chrome-os-partner:57846
Change-Id: I3a0054e22b81f9d6d407bef417eae5e9edc04ee4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17089
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Define reset_gpio and enable_gpio for touchscreen device so that when
kernel puts this device into D3, we put the device into
reset. PowerResource _ON and _OFF routines are used to put the device
into D0 and D3 states.
BUG=chrome-os-partner:55988
Change-Id: Ia905f9eb630cd96767b639aec74131dbd7952d0e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17083
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Implement GPIO ACPI AML generating functions that can be called by
coreboot drivers to generate GPIO manipulation code in AML. Following
functions are implemented:
1. acpigen_soc_read_rx_gpio
2. acpigen_soc_get_tx_gpio
3. acpigen_soc_set_tx_gpio
4. acpigen_soc_clear_tx_gpio
BUG=chrome-os-partner:55988
Change-Id: I3d8695d73a1c43555032de90f14ee47ccee45559
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17082
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add support to allow a device to define PowerResource in its SSDT AML
code. PowerResouce ACPI generation expects SoC to define the
callbacks for generating AML code for GPIO manipulation.
Device requiring PowerResource needs to define following parameters:
1. Reset GPIO - Optional, GPIO to put device into reset or take it out
of reset.
2. Reset delay - Delay after reset GPIO is de-asserted (default 0).
3. Enable GPIO - Optional, GPIO to enabled device.
4. Enable delay - Delay after enable GPIO is asserted (default 0).
BUG=chrome-os-partner:55988
Change-Id: Ieb2dd95fc1f555f5de66f3dda425172ac5b75dad
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17081
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
This version of coreboot successfully starts a Harvey (Plan 9) kernel as a payload,
entering main() with no supporting assembly code for startup. The Harvey port
is not complete so it just panics but ... it gets started.
We provide a standard payload function that takes a pointer argument
and makes the jump from machine to supervisor mode;
the days of kernels running in machine mode are over.
We do some small tweaks to the virtual memory code. We temporarily
disable two functions that won't work on some targets as register
numbers changed between 1.7 and 1.9. Once lowrisc catches up
we'll reenable them.
We add the PAGETABLES to the memlayout.ld and use _pagetables in the virtual
memory setup code.
We now use the _stack and _estack from memlayout so we know where things are.
As time goes on maybe we can kill all the magic numbers.
Change-Id: I6caadfa9627fa35e31580492be01d4af908d31d9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17058
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Since reading/toggling of GPIOs is platform-dependent task, provide an
interface with common functions to generate ACPI AML code for
manipulating GPIOs:
1. acpigen_soc_read_rx_gpio
2. acpigen_soc_get_tx_gpio
3. acpigen_soc_set_tx_gpio
4. acpigen_soc_clear_tx_gpio
Provide weak implementations of above functions. These functions are
expected to be implemented by every SoC that uses ACPI. This allows
drivers to easily generate ACPI AML code to interact GPIOs.
BUG=chrome-os-partner:55988
Change-Id: I3564f15a1cb50e6ca6132638447529648589aa0e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17080
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add functions to support generation of following AML operations:
1. PowerResource
2. Store
3. Or
4. And
5. Not
6. Debug
7. If
8. Else
9. Serialized method
BUG=chrome-os-partner:55988
Change-Id: I606736b38e6a55ffdc3e814b6ae0fa367ef7595b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17079
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Instead of using hard-coded values for emitting op codes and prefix
codes, define and use enum constants. With this change, it becomes
easier to read the code as well.
BUG=chrome-os-partner:55988
Change-Id: I6671b84c2769a8d9b1f210642f3f8fd3d902cca2
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17078
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This patch adds a Makefile rule for mvmap2315 to install a BDB and
bootblock code in the BOOTBLOCK region. The resulting BDB has a
header and data both signed by a RSA-4096 key.
BUG=chrome-os-partner:57889
BRANCH=none
TEST=emerge-rotor coreboot and examined the output binary. Booted
coreboot.rom.
Change-Id: I1e20a09b12f8f8ed4d095aa588e3eb930f359fc5
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/16747
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
While we stub out free(), tools like coverity scan have no idea, and it
might change in the future. So free it.
Change-Id: I1d93a6f45b64445662daa95b51128140ad0a87e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1260716
Reviewed-on: https://review.coreboot.org/17055
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The cross clocking of 800MHz FSB CPU with 667MHz RAM was incorrect.
The result is that 800MHz FSB CPUs now properly work with 667MHz RAM.
Value taken from vendor bios on ga-945gcm-s2l and suggested by Haouas
Elyes.
Change-Id: I56c12af50c75a735af0150a4e7bce4faacc93648
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17038
Tested-by: build bot (Jenkins)
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Previously the 945gc raminit only worked for 533MHz FSB CPUs.
This extends the tRD_Mclks in drt0_table for other FSB speeds. The values are
taken from the vendor bios of Gigabyte ga-945gcm-s2l.
The result is that 1067MHz FSB CPUs now boot without problems.
800MHz FSB cpus still don't get past romstage.
Change-Id: I13a6b97d2e580512155edf66c48405a153121957
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17034
Tested-by: build bot (Jenkins)
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This removes writes to FDI related registers since there is no FDI
link on these targets. This is likely a remainder from copying code from
later targets.
TESTED on Thinkpad x200 (gm45)
Change-Id: Id67fdc999185fa184a9ff0e5c3fc9bced04131ad
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16993
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
This issue was found by Coverity Scan, CID 1364118.
Change-Id: Iba3c0f4f952729d9e0987d928b63ef8b8fe8841e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16992
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
According to: "Intel ® 965 Express Chipset Family and Intel ® G35 Express
Chipset Graphics Controller PR" the p2 divisor needs to be 10 when the
dotclock is below 225MHz and 5 when its above 225MHz.
Change-Id: I363039b6fd92051c4be4fdc88788f27527645944
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16991
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
MAINBOARD_HAS_NATIVE_VGA_INIT_TEXTMODECFG should only occur together with
MAINBOARD_HAS_NATIVE_VGA_INIT. It seems to be used to just have to have
the option to be able to select SEABIOS_VGA_COREBOOT.
This patch makes these boards use MAINBOARD_DO_NATIVE_VGA_INIT and
MAINBOARD_HAS_NATIVE_VGA_INIT to have it select SEABIOS_VGA_COREBOOT
by default when SeaBIOS is chosen.
Change-Id: If0a36af1883a3d62b16a61483733be981a85e5e2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16981
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
This refactoring was already carried into RK3288 with commit 6911219
(edid: Add helper function to calculate bits-per-pixel dependent values)
but it seems that the code for RK3399 was copy&pasted from it too early
to pick this up. Fix that so that future Rockchip SoCs can copy&paste
the right thing.
Change-Id: I5050c58d18db38fffabc7666e67a622d4a828590
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17050
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The stack pointer (SP) is already printed in print_trap_information.
Don't print it again in handle_misaligned_{load,store}.
Change-Id: I156cf5734a16605decc2280e54e6db3089e094a2
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16996
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Skip FSP initiated core/MP init as it is implemented and initiated
in coreboot.
Add soc core init to set up the following feature MSRs:
1. C-states
2. IO/Mwait redirection
BUG=chrome-os-partner:56922
BRANCH=None
TEST= Check C-state functioning using 'powertop'. Check 0xE2 and
0xE4 MSR to verify IO/Mwait redirection.
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Change-Id: I97c3d82f654be30a0d2d88cb68c8212af3d6f767
Reviewed-on: https://review.coreboot.org/16587
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reef is using APL SoC SKU's with 6W TDP max. We've done
experiments and found the energy calculation is wrong with
the current VR solution. Experiments show that SoC TDP max
(6W) can be reached when RAPL PL1 is set to 12W. Therefore,
we've inserted 12W override after reading the fused value (6W)
so that the system can reach the right performance level.
BUG=chrome-os-partner:56922
TEST=webGL performance(fps) not impacted before and after S3.
Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Change-Id: I21c278e82b82d805f6925f4d9c82187825fd0aa0
Reviewed-on: https://review.coreboot.org/17029
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch sets the package power limit (PL1) value in RAPL MSR
and disables MMIO register. Added configurable PL1 override
parameter to leverage full TDP capacity.
BUG=chrome-os-partner:56922
TEST=webGL performance(fps) not impacted before and after S3.
Change-Id: I34208048a6d4a127e9b1267d2df043cb2c46cf77
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-on: https://review.coreboot.org/16884
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In FSP1.1 all the platform resets including global was handled
on its own without any intervention from coreboot.
In FSP2.0, any reset required will be notified to coreboot
and it is expected that coreboot will perform platform reset.
Hence, implement platform global reset hooks in coreboot. If Intel
ME is in non ERROR state then MEI message will able to perform
global reset else force global reset by writing 0x6 or 0xE to
0xCF9 port with PCH ETR3 register bit [20] set.
BUG=none
BRANCH=none
TEST=Verified platform global reset is working with MEI
message or writing to PCH ETR3.
Change-Id: I57e55caa6d20b15644bac686be8734d9652f21e5
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16903
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As per ME BWG, there are two mechanism to generate a Global
Reset (resets both host and Intel ME), one is through CF9h
IO write of 6h or Eh with "CF9h Global Reset" (CF9GR) bit set,
PMC PCI offset ACh[20]. Another is to issue the Global Reset
MEI message. Because any attempts to cause global reset without
synchronizing the two sides might cause unwanted side effects,
such as unwritten flash data that will get destroyed if the
host were to cause a global reset without informing Intel ME
firmware, the recommended method is to send a Global Reset MEI
message when the following conditions are met:
The PCH chipset firmware just needs to complete the Intel ME
Interface #1 initialization and check the Intel ME HFSTS state
if Intel ME is not in ERROR state and is accepting MEI commands
then firmware should be able to use Global Reset MEI message to
trigger global reset.
Furthermore, if Intel ME is in ERROR state, BIOS can use I/O 0xCF9
write of 0x06 or 0x0E command with PCH ETR3 register bit [20]
to perform the global reset.
BUG=none
BRANCH=none
TEST=Verified Global Reset MEI message is able to perform platform
global issue in ME good state.
Change-Id: If326a137eeadaa695668b76b84c510e12c546024
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16902
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch programs and enables BAR for ME (bus:0/
device:0x16/function:0) device to have early ME communication.
BUG=none
BRANCH=none
TEST=Verified Global Reset MEI message can able to perform platform
global reset during romstage.
Change-Id: I99ce0ccd42610112a361a48ba31168c9feaa0332
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/17016
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
VBOOT_EC_SLOW_UPDATE should be selected if EC_GOOGLE_CHROMEEC is used as
building coreboot with Chrome OS support & without Chrome EC gives a
build error in coreboot.
Change-Id: I77eed0e1bdc1ba49381b72e21b0e18f573cadff0
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17020
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The clearing of the PMC registers was not being called resulting
in state persisting across reboots. This state is queried and
events are added to the eventlog like 'RTC reset' events. However,
the RTC reset event is a one time thing so it should only be logged
once. Without the clearing of the state the event was logged on
every boot.
BUG=chrome-os-partner:58496
Change-Id: I60aa7102977c2b1775ab8c54d1c147737d2af5e2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17027
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
According to "G45: Volume 3: Display Register Intel ® 965G Express
Chipset Family and Intel ® G35 Express Chipset Graphics Controller" the
VSYNC end should start at bit 16. This is also how Linux (at least 4.4)
sets this register, which can be seen with intel-gpu-tools.
TESTED on Lenovo thinkpad X60 (it does not change anything).
Change-Id: Ie222ac13211a91c4fbc580e2bf9de0d973ea9a3a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17015
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
The pointers printed on unaligned memory accesses are now aligned to
those printed at the end of print_trap_information.
Change-Id: Ifec1cb639036ce61b81fe8d0a9b14c00d5b2781a
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16983
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On other architectures, the serial ports aren't mapped at 0x3f8.
WIP: I'm not sure how exactly the dependency should be encoded in
Kconfig.
Change-Id: Ia1de545325a53607f62d08e76b2f61b25edbe6ef
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16982
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
TEST=Compiled for and ran on spike; it booted as before.
Change-Id: Id173643a3571962406f9191db248b206235dca35
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16995
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
spike_util.h:
- (LOG_)REGBYTES and STORE are already defined in
arch/riscv/include/bits.h.
- TOHOST_CMD, FROMHOST_* are helper macros for the deprecated
Host-Target Interface (HTIF).
qemu_util.c:
- mcall_query_memory now uses mprv_write_ulong instead of first
translating the address and then accessing it normally. Thus,
translate_address isn't used anymore.
- Several functions used the deprecated HTIF CSRs mtohost/mfromhost.
They have mostly been replaced by stub implementations.
- htif_interrupt and testPrint were unused and have been deleted.
spike_util.c:
- translate_address and testPrint were unused and have been deleted.
After this commit, spike_util.c and qemu_util.c are exactly the same and
can be moved to a common location.
Change-Id: I1789bad8bbab964c3f2f0480de8d97588c68ceaf
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16985
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is no code which uses the backup space in TPM created for vboot
nvram.
All chromebooks currently supported at the trunk store vboot nvram
in flash directly or as a backup.
BUG=chrome-os-partner:47915
BRANCH=none
TEST=emerge-samus coreboot
Change-Id: I9445dfd822826d668b3bfed8ca50dc9386f2b2b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5cee2d54c96ad7952af2a2c1f773ba09c5248f41
Original-Change-Id: Ied0cec0ed489df3b39f6b9afd3941f804557944f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/395507
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://review.coreboot.org/16997
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Regardless of the payload chosen a file etc/ps2-keyboard-spinup
is added to cbfs. With this fix this file is only added to cbfs when
seabios is choses as a payload.
Change-Id: I37cf4c998856db2d297356776752643dba46a8f8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16146
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Some devices have no LVDS output but if no VGA is connected or
no EDID can be found, it will try to init LVDS.
This patch detects the presence of an LVDS panel and makes sure that
LVDS is not initialized when it is absent.
Change-Id: Ie15631514535bab6c881c1f52e9edbfb8aaa5db7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16513
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
The CPU_MICROCODE_BLOB_CBFS_LOC should only be specified for COREBOOT CBFS,
not for other CBFS.
BUG=none
BRANCH=none
TEST=Built and boot kunimitsu
Change-Id: I58bb289e6c9add2647876ef817b7920f6e7b427a
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16932
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This reuses linux code (at least 4.1) to compute the graphic clock
divisors for LVDS displays on the gm45 northbridge.
The divisors m1, m2, n, p1, p2 need to be such that
"BASE_FREQUECY * (5 * (m1 + 2) + (m2 + 2)) / (n + 2)
/ (p1 * p2)" is as close as possible to the target_frequency.
On g4x hardware the BASE_FREQUENCY is 96000kHz.
This potentially increases LVDS display compatibility.
Change-Id: I2323af5756431e89769f95059790f5a922af14b4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16741
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Requesting low power acpi cpu c-states has two software interfaces:
Using P_LVLx I/O reads or using equivalent MWAIT requests.
This change makes it more consistent with newer targets that use MWAIT
requests.
There also exists extended intel acpi c-states which can be enabled
in two ways:
- using a substate hint to the mwait request (defined in bios);
- setting a model specific register (msr)
Currently this is done by setting the right msr bits but with this
change one can experiment by adding substate hints.
Change-Id: I9eeb5b008e2ddc2193725667f2c13582a4877e3c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/14801
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
MHCBAR(CLKCFG) was previously incorrectly written by the
sdram_program_memory_frequency function which required falsely
limiting the max dram frequency for 945GC.
TESTED on Intel d945gclf (memclock 667 and fsb 533) and
Gigabyte ga-945gcm-s2l (memclock 667 and fsb 1067)
Change-Id: I520efd69fa09fc9fde87c5301fd81121fde6a700
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16940
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
An epic battle to fix Nehalem finally ended when we found an odd mask
set in SMRR. This was caused by a wrong calculation of TSEG size. It
was assumed that TSEG spans the whole space between TSEG base
and GTT. This is wrong as TSEG base might have been aligned down.
TEST: On X201, copied 1GiB from usb key to sd-card and verified.
Change-Id: Id8c8a656446f092629fe2517f043e3c6d0f1b6b7
Found-by: Alexander Couzens, Nico Huber
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch adds MAINBOARD_HAS_NATIVE_VGA_INIT_TEXTMODECFG to the
gigabyte/ga-g41m-es2l Kconfig to allow selecting between textmode and
vesamode in menuconfig.
Change-Id: I84b61118fa0419d49d2498b66029711cdce97576
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16501
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This patch implements native resolution, VESA mode, on the VGA output of
x4x.
It relies on EDID to modeset, but has a fallback-mode (640 x 480 @
60Hz) if this is no EDID could be found. This fallback mode only works
in textmode since in VESA mode some payloads (grub2) rely on VBE info,
which is being generated from an EDID.
Change-Id: I247ea7171ba3c5dc3b209d00e4dcb2d2069abd75
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16498
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Maxim98357a speaker amp requires BCLK & SFRM to be active
and stable before it is unmuted. If there is a BLCK and no
SFRM, it results in a pop sound.
sdmode_delay property already exists which facilitates this
configuration. This patch updates "sdmode_delay" to avoid
pop sound.
BUG=chrome-os-partner:58356
BRANCH=None
TEST=while audio playback via headset, remove headset.
Audio will be switched playback to speaker. Observe if
pop sound comes from speaker.
Change-Id: I7ad68caa88d7b3ff52ac1379fe6564de27d97777
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/16933
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The datasheets "Intel® Core™ Duo Processor and Intel® Core™ Solo
Processor on 65 nm Process" mentions cpu C-states substates which can
either be attained by adding a substate hint to the MWAIT/P_LVLx request
or automatically by setting some msr bits correctly.
This just sets the same msr bits as model_6fx to enable
dynamic L2 cache, C2E and C4E acpi cpu states.
The result is that when limiting a thinkpad x60 with a yonah T2400
cpu to the acpi cpu C2 state, the idle power usage drops from 18W to
14W. When the lowest C-state is set to C4 the idle power usage seems
to remain similar.
Change-Id: I6c422656ace04659f32082a5944617eda6c79ec3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16901
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When timestamp is enabled, the system hangs because the timestamp data
is not yet available. Add a temporary work around that starts the
timestamp after the FspInit() making this data available.
Verified on Intel Camelback Mountain CRB and ensured that system can
boot to payload with timpstamp feature enabled.
Change-Id: I59c4bb83ae7e166cceca34988d5a392e5a831afa
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The enforced FSP 1.0 APIs call was used to work around an fsp1.0 driver
issue. As the issue has been addressed in fsp1.0 driver (Change 9780),
remove the enforced workaround. Otherwise will see error message
'FSP API NotifyPhase failed' in serial log.
Verified on Intel Camelback Mountain CRB and confirmed that the serial
log error message regarding the 'FSP API NotifyPhase failed' is gone.
Change-Id: Iafa1d22e2476769fd841a3ebaa1ab4f9713c6c39
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16892
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When compiling a non-x86 platform with DRIVERS_INTEL_WIFI enabled,
we get the build error:
src/drivers/intel/wifi/wifi.c:17:30: fatal error:
arch/acpi_device.h: No such file or directory
acpi_device.h only exists in the x86 architecture directory.
Change-Id: Id0e29558336bf44e638cfcb97c22f31683ea4ec7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16906
Tested-by: build bot (Jenkins)
Reviewed-by: Antonello Dettori <dev@dettori.io>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Some PVT units encountered DRAM calibration failure during
power on/off tests. The failure is caused by higher impedance
of the DRAM on those units. So increase the driving strength
for 4GB DRAMs.
BUG=chrome-os-partner:57392
TEST=run cold reboot 100 times on PVT units which have DRAM
calibration issue.
Change-Id: I8a329093db3f1def566e4b7afec3c4f4bfe44c6a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cf1aa5ade856af433fa056f51a20d18553ae241d
Original-Change-Id: I0d1776cd1a5892d1f82e9bf414620d1ef6d29132
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/394451
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Pin-Huan Hsu <ph.hsu@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/16917
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We found that Kevin board PHY0 and PHY1 eye-diagram margin
is not enough to make compliance test pass, and the PHY0 USB
SI is worse than PHY1, because of the higher PCB impedance.
For PHY0, we can't improve the eye-diagram by SW PHY tuning,
so we need to reduce the RBIAS resistance from 133 ohm to 115
ohm, it can help to increase the eye-height.
For PHY1, we can improve the eye-diagram by setting the max
pre-emphasis level.
And after the above change, the USB2 signal amplitude will
become larger at the test point near to SOC USB2 PHY, in order
to avoid mis-trigger the disconnect detection (650mV), we need
to disable pre-emphasize in eop state.
BRANCH=None
BUG=chrome-os-partner:53863
TEST=do USB 2.0 compliance test for Kevin C0 and C1 port.
Change-Id: I95c0acd79623aeca9a0ae077b1dd3836d91fe561
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: de3cdef128966d76e7d8e2ebd641763b911c3ad5
Original-Change-Id: I00cb325b9938e4276cc77b5d6f5faa7023379608
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/390615
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16911
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Though we don't use Type-C PHY to support USB3 in firmware,
we still need to initialize the Type-C PHY, and make sure
the power state of pipe is always fixed to U2/P2. After
this, we can force USB3 controller to work in USB2 only
mode.
BRANCH=none
BUG=chrome-os-partner:56425
TEST=Go to recovery mode, plug a Type-C USB drive containing
chrome OS image into both ports in all orientations, check if
system can boot from USB.
Change-Id: I95bb96ff27d4fecafb7b2b9e9dc2839b5c132654
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ec98507845276119d8a9d5626934dedcb35f2dd
Original-Change-Id: Ie3654cd1c1cb76b62aa9b247879b60cbecee0155
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/391412
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16910
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Converged Security Engine (CSE) has a secure variable storage feature.
However, this storage is expected to be reset during S3 resume flow.
Since coreboot does not use secure storage feature, disable HECI2 reset
request. This saves appr. 130ms of resume time.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=powerd_dbus_suspend; resume; check time with cbmem -t. Note
FspMemoryInit time is not significantly different from normal boot
time case.
Change-Id: I485a980369c6bd97c43b9e554d65ee89e84d8233
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/16870
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These header files contain a few new UPDs. The EnableS3Heci2
UPD will be used to save ~100ms from the S3 resume time on
Apollolake chrome platforms.
BUG=chrome-os-partner:58121
BRANCH=none
TEST=built coreboot for reef and verified no regressions
Change-Id: I1f324d00237c7150697800258a2f7b7eed856417
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16869
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
commit 028200f7 - x86/acpi_device: Add support for GPIO output polarity
updated ACPI_GPIO_OUTPUT to ACPI_GPIO_OUTPUT_ACTIVE_HIGH for the other
boards that needed it, but pyro wasn't in the tree when it was initially
pushed. Now that pyro is in the tree, it needs to be updated as well.
Change-Id: I617999b06ee584e0543d7ae3232bb2be2ff7429c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This patch enables stage cache to save ~40ms during S3 resume.
It saves ramstage in the stage cache and restores it on resume
so that ramstage does not have to reinitialize during the
resume flow. Stage cache functionality is added to postcar stage
since ramstage is called from postcar.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for Reef and tested ramstage being cached
Change-Id: I1551fd0faca536bd8c8656f0a8ec7f900aae1f72
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16833
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Only acpi_dp of type DP_TYPE_TABLE is allowed to be an array. This
DP_TYPE_TABLE does not have a value which is written. Thus,
acpi_dp_write_array needs to start counting from the next element type
in the array. Fix this by updating the initialization in for loop for
writing array elements.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that the correct number of elements are passed for
add_gpio in maxim sdmode-gpio.
Change-Id: I8e1e540d66086971de2edf0bb83494d3b1dbd176
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Some Chrome OS ECs require a small amount of time after a SPI
transaction to reset their controllers before they can service the next
CS assertion. The kernel and depthcharge have always enforced a 200us
minimum delay for this... coreboot should've done the same.
BRANCH=gru
BUG=chrome-os-partner:58046
TEST=Booted Kevin in recovery mode, confirmed that recovery events got
logged with correct timestamps in eventlog.
Change-Id: I32ec343f3293ac93729d3e6e2f43d7605a396cdb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b9e4696533d4318ae7c8715b71ab963d8897c16c
Original-Change-Id: I6a7baf7859d5d50e299495d118e7890dcaa2c1b0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/392206
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://review.coreboot.org/16885
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also
"pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time
during early boot. This leaves the signal floating somewhere in the
middle.
This has two potential issues:
(1) we're leaking some power for some (hopefully) short period of time
(2) we are possibly screwing with the Wifi power sequence; we aren't
supposed to deassert PDn (i.e., MODULE_RST#) until all the rails
have fully ramped for some period of time
Neither of the above issues are likely to be significant, but it is nice
to fix, I expect.
BRANCH=gru
BUG=chrome-os-partner:54026
TEST=measure WLAN_MODULE_RST# on scope at boot time
Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab
Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d
Original-Signed-off-by: Brian Norris <briannorris@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/388009
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16882
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This reverts commit 28821dbb22.
(https://review.coreboot.org/16649)
This change causes the kernel to boot really slow. Maybe there is an
interrupt storm that prevents the kernel from making any
progress. Reverting until the proper kernel dependency is met.
BUG=chrome-os-partner:57364
BRANCH=None
TEST=Kernels boots to prompt fine on DVT.
Change-Id: I1c9913b4476a08303f9dd887b8631601c847dcf7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7014ee1bb88df7a2d7f6b3dced797fef75b252d
Original-Change-Id: I061c0b03b43b516a190b370c04888e73a410fcf1
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/391233
Original-Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/16881
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
CL:377541 was supposed to remove the big CPU cluster initialization from
rkclk_init() in the bootblock and move it to a more suitable place in
ramstage. Except that next to all the code cleanup I did in that patch,
I seem to have forgotten to actually remove that old code.
Big thanks to Nico for spotting that in the upstream coreboot review.
BRANCH=gru
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I09fe948b4587536802b42329b813177439e0804f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 77f9eaf0446b22adfca79d0adf8a0ecfd93c0040
Original-Change-Id: I13dab208225b7e43ad864f2f3cf51b3c104acd4b
Original-Reported-by: Nico Huber <nico.h@gmx.de>
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/389236
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16769
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This selects the rank to train before training is triggered. This is
to prevent any race conditions with the hardware.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=stressapptest -M 1536 -s 1000
Change-Id: I892bace414cf4495619d41bdaea0c4e91c1e29b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8f2dd6f52978a9e54ddd2688eb68fd237aabfe2d
Original-Change-Id: I4e7118d8509b59e391d0a254477b5390dfdd43a5
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/387907
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: 云平 汤 <typ@rock-chips.com>
Reviewed-on: https://review.coreboot.org/16768
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
UX Doc = go/gale-hw-ui
This color wasn't changed earlier as the change wasn't done in
the OS also. However, since we cannot change this later in FW
(but OS can change anytime), I am making this change after discussing
with the UX team.
BUG=b:31501528, b:31633562
TEST=Change the device state to 'recovery mode' to observe the new
color.
BRANCH=none
Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70
Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388206
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16767
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There are two modifications in the driver:
1. Correctly set speeds based on DDR frequency.
Control the speeds in the predriver circuits to reduce power.
SPEED[1:0]
2'b00:less than 800Mbps(400MHz)
2b01 : 800Mbps(400MHz) to 1600Mbps(800MHz)
2b10 : 1600Mbsp(800MHz) to 2400Mbps(1200MHz)
2b11 : 3200Mbps and greater
2. Configure the number of cycles for the phy clock pll wait time after
locking, based on the DDR config file.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=do memtester on kevin board, and pass
Change-Id: Iaf6da59c6c5c290867e0922a2a99de272f4c7bde
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 125cf8afac3a682d33896fe74a20ba1d498a3bd2
Original-Change-Id: Iabc17df37a701c4f052540c3c259f209a1db3c59
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387428
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16722
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
PHY_PER_CS_TRAINING is being enabled when DDR frequency >= 666.
For per cs training, the controller should consider the PHY
delay line switch time and there should be more cycles to
switch the delay line, so update the W2W_DIFFCS_DLY_ value
from 0x1 to 0x5.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=do memtester on kevin board, and pass
Change-Id: I00df2d4724b0b77f3e7565809fb35bbd2ff01ea5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c135ea3e33d810ed322d947eb8d512d1ac119cfc
Original-Change-Id: I81b99cbc085769b7028e770509d79bd8d550820b
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387506
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16721
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To save power when entering suspend, gpios 2 to 4 need to be set
to input and 'pull none' mode.
Pass the APIO configuration to ATF so it can do a proper job here.
BRANCH=None
BUG=chrome-os-partner:56423
TEST=run suspend_stress_test on kevin board
Change-Id: Id57fe8f622ae3f9c2bc7e58be89518b2b846cd37
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c42082d1ca9a6baa735821382d3e83c1f8dc9ad
Original-Change-Id: Iaf441e8e34c5591ffe7c65f6533fcf0b733ff5ac
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/378475
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16720
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We need to disable some regulators when the device goes into suspend.
This means that we need to pass some gpios to bl31, and disable these
gpios when bl31 runs the suspend function.
BRANCH=None
BUG=chrome-os-partner:56423
TEST=enter suspend, measure suspend gpio go to low
[pg: also update arm-trusted-firmware to match]
Change-Id: Ia0835e16f7e65de6dd24a892241f0af542ec5b4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f3332ef2136fd93f7faad579386ba5af003cf70
Original-Change-Id: I03d0407e0ef035823519a997534dcfea078a7ccd
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/374046
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16719
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Create the initial Pyro variant which refers to the Reef.
Pyro is APL Chrome board that deviate from reference board Reef.
BRANCH=master
BUG=None
TEST=Build
Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com>
Change-Id: I9beed1f6895e8891d3d51b563edfe172f566718b
Reviewed-on: https://review.coreboot.org/16855
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Colors and patterns as defined by the UX team
BUG=b:31501528
TEST=Move the device to different states in FW using rec and dev
button and verify the colors
BRANCH=None
Change-Id: I66d41a54590cd3ce4e5202c7cfa890f462fe195e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 703559d5dddaeeb7d435d6cadbb2009a1b7a76c8
Original-Change-Id: I95ab1fa59b483396ff1498a28f1ee98ac08d02d7
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387258
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16718
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In USB2 only mode, the Type-C PHY will be held in reset and
only the USB2 logic of the USB3 OTG controller and PHY will be
used over the USB2 pins on the Type-C connector to support Low,
Full and High-speed USB operation.
BRANCH=none
BUG=chrome-os-partner:56425
TEST=Go to recovery mode, plug a Type-C USB drive containing
chrome OS image into both ports in all orientations, check if
system can boot from USB.
Change-Id: Ic265c0c91c24f63b2f9c3106eb2bb277a589233b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a37ccc5b6019967483eac6b5a360d67bc3326e93
Original-Change-Id: I582f04f84eef447ff0ba691ce60e9461ed31cfad
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/385837
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16717
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To improve sdram 800MHz and 933MHz stability, we
need to modify write leveling flow to get the
proper write leveling value.
BUG=chrome-os-partner:56940
BRANCH=none
TEST=Boot from kevin on 933MHz, and do stressapptest
Change-Id: I5b24c93d4a57917fb9af7e5e2a95d8423ccbaa7e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d84bf25b3e5de373c7913e6d534a810cb984b3fd
Original-Change-Id: I87efddf628c3683fcb85d6875e029cf3cbc482be
Original-Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/384292
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Since there's currently a limitation in coreboot's code that prevents
more than 4KB to be used by the eventlog anyway, this patch shrinks the
available RW_ELOG area in the FMAP for Gru down to 4KB. This may prove
prudent later if we ever resolve that limitation, so that tools can rely
on the area in the FMAP being the same as the area actually used by the
read-only firmware code on these boards.
BRANCH=gru
BUG=chrome-os-partner:55593
TEST=Booted Kevin, confirmed that eventlog got written normally. Ran a
reboot loop to exhaust eventlog space, confirmed that the shrink code
kicks in as expected before reaching 4KB.
Change-Id: I3c55d836c72486665a19783fe98ce9e0df174b6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 05efb82ca00703fd92d925ebf717738e37295c18
Original-Change-Id: Ia2617681f9394e953f5beb4abf419fe8d97e6d3e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/384585
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16715
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We found that we may want to load some components of BL31 on the RK3399
into SRAM. As usual, these components may not overlap any coreboot
regions still in use at that time, as is already statically checked by
the check-ramstage-overlaps rule in Makefile.inc.
On RK3399, the only such regions are TTB and STACK. This patch moves the
TTB region back to the end of SRAM (right before STACK), so that a large
contiguous region of SRAM before that remains usable for BL31.
BRANCH=gru
BUG=None
TEST=Booted Kevin.
Change-Id: I1689d0280d79bad805fea5fc3759c2ae3ba24915
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1d4c6c6f6cc0efe97d6962a81e309a1c040d1def
Original-Change-Id: I37c94f2460ef63aec4526caabe58f35ae851bab0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/384635
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16714
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
With a SPI clock above about 24MHz the APB cannot keep up when doing
individual byte transfers. Adjust the driver to use 16-bit reads when
it can, to remove this bottleneck.
Any transaction which involves writing bytes still uses 8-bit transfers,
to simplify the code. These are the transfers that are not time-critical
since they tend to be small. The case that really matters is reading from
SPI flash.
In general we can use 16-bit reads anytime we are transferring an even
number of bytes. If the code detects an odd number of bytes, it tries to
perform the operation in two steps: once in 16-bit mode with an even
number of bytes, and once in 8-bit mode for the final byte. This allow
us to use 16-bit reads even if asked to transfer (for example) 0xf423
bytes.
The limit on in_now and out_now is adjusted to 0xfffe to avoid an extra
transfer when transferring ~>=64KB.
CQ-DEPEND=CL:383232
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. I tested (with
extra debugging) that the 16-bit case is being picked when it should be.
Change-Id: If5effae9a84e4de06537fd594bedf7f01d6a9c88
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ec250b4931c7d99cc014e32ab597fca948299d08
Original-Change-Id: Idc5b7e5d82cdbdc1e8fe8b2d6da819edf2d5570c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381312
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16712
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
We found some boards are not stable when sdram is run at 933Mhz.
Before we can fix it, we need to lower the sdram frequency to 800MHz.
In this patch we modify the DQS delay from 0x280 to 0x260 and extend
the DQS window.
BRANCH=None
BUG=chrome-os-partner:56940
TEST=Booted Kevin.
Change-Id: I68561c4aa4d9ab66acfa3515a42d696157aff759
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 877a7f6ad22a5bde9f9e458bcb65f133f2f001bd
Original-Change-Id: I5eab6bbe96f0dae095c5353403292022e7a25421
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/382724
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16709
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some of the asserts for valid clock divisor ranges were off by one. This
patch corrects them and writes them all in a consistent way.
BRANCH=None
BUG=None
TEST=Booted Kevin.
Change-Id: I81749408a40822100797f1734f3b88987d12d8d5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e09cdfde26700496aaa1fc41489f63a355e8a89d
Original-Change-Id: I429edb99e2d5ff2302d9750e6569b3d21f5686fa
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381574
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16704
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
SPI read speed directly impacts boot time and we do quite a lot of
reading.
Add a way to easily find out the speed of SPI flash reads within
coreboot.
Write speed is less important since there are very few writes and they
are small.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=run on gru with SPI_SPEED_DEBUG set to 1. See the output messages:
read SPI 627d4 7d73: 18455 us, 1740 KB/s, 13.920 Mbps
Change-Id: Id3814bd2b7bd045cdfcc67eb1fabc861bf9ed3b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 82cb93f6be47efce3b0a3843bab89d2381baef89
Original-Change-Id: Iec66f5b8e3ad62f14d836a538dc7801e4ca669e7
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376944
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16701
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add lpddr3-K4E6E304EB-2GB-1CH memory configuration for rialto.
BUG=chrome-os-partner:56759
BRANCH=none
TEST=Build
Change-Id: I698fe450d48b64a06232aa44ecf91d688d9dc17a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d3edecdb135939c3264ab1b831e7821d3a3e0149
Original-Change-Id: I7dae9fd822abeff5b08de0ab9262e1817ac58531
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/380443
Original-Commit-Ready: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: Jonathan Dixon <joth@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch moves the big CPU cluster initialization on the RK3399 from
the clock init bootblock function into ramstage. We're only really doing
this to put the cluster into a sane state for the OS, we're never
actually taking it out of reset ourselves... so there's no reason to do
this so early.
Also cleaned up the interface for rkclk_configure_cpu() a bit to make it
more readable.
BRANCH=None
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I568b891da0abb404760d120cef847737c1f9e3ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd7aa7ec3e6d211b17ed61419f80a818cee78919
Original-Change-Id: Ic3d01a51531683b53e17addf1942441663a8ea40
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/377541
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16698
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Gale EVT3 has only one LED controller (earlier we had 2).
Remove the support for the second controller and also the
corresponding microcode. The color values used are the same
as onHub (Arkham to be specific).
BUG=b:30890905
TEST=Move the device to different states manually by appropriate
actions (like dev mode, rec mode etc) and observe the different
colors.
BRANCH=None
Change-Id: I853035610ea7ea7c8d29c30d2de13c9e2e786b2b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 593905d2d69daa7482318aa5f5c5cd7cf984043e
Original-Change-Id: If8f22abd605faac6f6215ef600041740ce15ea0c
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/370821
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16697
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the setup of the IRQ status handler so it will be set up properly
before the early probe happens.
BUG=chrome-os-partner:53336
Change-Id: I4380af1233d2a252899459635a3cb69ca196088d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16861
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Due to different LCD panel requirements the delay between LVDS becomes
active and the backlight is switched on needs to be increased to 500 ms.
Change-Id: I09029624469aef412141c7b46224d48557ba4af1
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16875
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
At higher SPI bus speeds the SPI RX value is not available in time for
sampling at the normal time. Add a delay to ensure that we read the
correct data.
The value of 40ns is chosen arbitrarily. In my testing I can use a sample
delay of 1 even at 24MHz. But since it is not necessary, I have left that
case alone. It kicks in at 25MHz and up.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see no change at current speed
Change-Id: I3ef335d9a532eaef1e76034bd02e185acf11176a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9b620c47fc3e39211487507fadb8657afdebee7
Original-Change-Id: I65d66d752cbbbee4d02f475de23a52069a0e9782
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381311
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16707
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Several of the special function pins we're using in firmware have a
pre-assigned pull-up or pull-down on power-on reset. We don't want those
to interfere with any of the signaling we're trying to do on those pins,
so this patch disables them.
Also do some house-cleaning to group the bootblock code better, and
change the setup code for all SPI and I2C buses to first initialize the
controller and then mux the pins... I assume this might be a little
safer (in case the controller peripheral has some pins in a weird state
before it gets fully initialized, we don't want to mux it through too
early).
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I4d5bd3f7657b8113d90b65d9571583142ba10a27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f8f7fd56e945987eb0b1124b699f676bc68d0560
Original-Change-Id: I6bcf2b9a5dc686f2b6f82bd80fc9a1a245661c47
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/382532
Reviewed-on: https://review.coreboot.org/16711
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch fixes a typo in the clock initialization code that caused the
PERILP1_PCLK_HZ constant to be ignored and the clock to always run at
the same speed as its parent (PERILP1_HCLK_HZ). Since we've done all our
previous tests and validation with this bug, we should probably increase
the value of the constant (that had not actually been used) to the value
that we had been incorrectly using instead (which also makes effective
SPI read times faster).
BRANCH=None
BUG=chrome-os-partner:56556
TEST=Booted Kevin.
Change-Id: Ibeb08f5fe5e984a74e3f57e60c62d4bfb644b6ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06e605a5fcb9bdf13a3d301112380633b892fd4e
Original-Change-Id: Icb5e079f53eb22b0dbf0ea4d1c2ff08688e3fa8e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381031
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16703
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Increase the SPI bus speed to speed up boot time. The maximum supported
speed at 1.8V is 37.5MHz, and 33MHz is the next lowest convenient speed,
given the clock parents.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. Total time
spent on reading from SPI reduces from 185ms to 141ms.
Change-Id: I71436c9e343b18360fa63d528dea5cfcfbc831e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7576f6e53e407af61160be142c3d589e864a8cf
Original-Change-Id: I55a19f523817862e081d23469e94fd795456dd67
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381313
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16708
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Output GPIOs should never have a pull-up or pull-down resistor attached
since they're actively driven. Since some GPIOs get initialized with a
pull at power-on reset, we should explicitly overwrite that setting.
Most other platforms do this on gpio_output, but Rockchip hadn't yet.
Also, shuffle some code around to make things cleaner and allow for
easier code reuse.
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I1425d074ea1e90f4484e1e84a8002b057192c5f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: df5b236bfd58b172435043c1cb792b917a4ec4ab
Original-Change-Id: I044266d71ef8bd0518316ff72d829d1ca1e30f35
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/382531
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16710
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If we setup the PWM _after_ the pinmux then there's a period of time
when we're driving the PWM incorrectly. Let's setup the regulator and
_then_ configure the pinmux.
This fixes no known bugs, but it is more correct and probably makes the
signals look better at bootup.
BRANCH=None
BUG=None
TEST=scope
Change-Id: I311c0eded873b65e0489373e87b88bcdd8e4b806
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcf4d0ba29d82cce779c0b25ead36de4a95d97a1
Original-Change-Id: I5124f48d04a18c07bbd2d54bc08ee001c9c7e8d1
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381592
Original-Reviewed-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16700
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As far as I know, the Cortex-A53 cores in RK3399 are of a newer revision
that is not affected by ARM erratum 843419. If it was, the workaround
would also need to be enabled in libpayload and Chrome OS userspace,
which it currently isn't. I assume this was just incorrectly copied over
from another SoC and we can safely remove it.
BRANCH=None
BUG=chrome-os-partner:56700
TEST=Booted Kevin.
Change-Id: I5b1534c954a6d985499b481738723cabbdc07253
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4891cc866583532ee3dcb1a5ad5b81670eb0743d
Original-Change-Id: Iadb57428f8727ce0e563204723644e2c79e3007c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376363
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16702
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The datasheets on gm45: "Mobile Intel® 4 Series Express Chipset Family"
mention the possibility of having 352M ram preallocated for the
integrated graphic device. This only worked fine if the amount of ram in
the system was 3GB or less. When 4G or more is installed, memory is
remapped to create a 1GB large pci mmio hole which is not enough and
creates conflicts when 352M vram is used.
This patch increases the pci mmio hole size on Lenovo x200 to allow
352M vram to work.
TEST: build and flash on target with 4GB ram or more, use nvramtool to
set gfx_uma_size to 352M and reboot.
Change-Id: I5ab066252339ac7d85149d91b09a9eaaaab3b5b6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16831
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Kconfig symbols of type bool are ALWAYS defined, so this code was
always being included and run, which isn't what the author wanted.
Change to use IS_ENABLED(), and a regular if() instead of an #ifdef.
Change-Id: I72623fa27e47980c602135f4b73f371c7f50139b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Everybody knows WHAT they're supposed to do with options, so the text
"Pick this" or "Select to" are redundant.
Change-Id: I327c5be755373e99ca0738593bd78e1084d4d492
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16838
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The AGESA_BINARY_PI_LOCATION Kconfig symbol was declared as a string.
Change it to a hex value.
Change-Id: Ifd87b6c8dfcdf950aea9b15a6fea45bb72e8b4e9
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16835
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
On resume, TPM2_Starup(STATE) command needs to be sent to the TPM. This
ensures that TPM restores the state saved at last Shutdown(STATE).
Since tlcl_resume and tlcl_startup both use the same sequence for
sending startup command with different arguments, add a common function
that can be used by both.
BUG=chrome-os-partner:58043
BRANCH=None
TEST=Verified that on resume coreboot no longer complains about index
read for 0x1007. Return value is 0 as expected.
Change-Id: Ib8640acc9cc9cdb3ba5d40e0ccee5ca7d67fa645
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16832
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Elyes HAOUAS