Age | Commit message (Collapse) | Author |
|
Change-Id: Iec8b40bd89c25cd2193aff8af45d0a09b07ad6a3
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49797
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Kernel needs to access EC RFWU entry in order to retrieve from EC about
port and mux info and set EC operations like modes change. This change
provides EC RFWU path and update for Retimer driver usage.
BUG=b:162528867
TEST=Booted to kernel and verified EC RFWU path from ACPI SSDT table.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I3817d93cfdeedf15825dab6c537b151fd063338b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49257
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The RFWU byte is defined as Bits[3:0] for port number and Bits[7:4] for
operations. The supported operations are:
RETIMER_FW_UPDATE_PORT_INFO 0
RETIMER_FW_UPDATE_PD_SUSPEND 1
RETIMER_FW_UPDATE_PD_RESUME 2
RETIMER_FW_UPDATE_GET_MUX 3
RETIMER_FW_UPDATE_SET_USB 4
RETIMER_FW_UPDATE_SET_SAFE 5
RETIMER_FW_UPDATE_SET_TBT 6
RETIMER_FW_UPDATE_DISCONNECT 7
BUG=b:162528867
TEST=Booted to kernel and verified RFWU entry from ACPI DSDT ERAM field.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I1ba04c6357b6fd0cc33ffce33e7e430539bace79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49051
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In order to update the BB retimers for usb4/tbt they need to be turned
on and into TBT mode. Expand the current DSM to allow for the use of an
EC RAM byte RFWU to get the current state of each port and whether or
not it has a retimer. It also allows Kernel to issue state transitions
for the retimer to be put into TBT mode for firmware update.
BUG=b:162528867
TEST=Along with work in progress kernel and EC patches, the Retimer
firmware update is verified under device attached and no device attached
scenarios.
Change-Id: I768cfb56790049c231173b0ea0f8e08fe6b64b93
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
SMBIOS slot information in overrridetree is not overriden
if device already exist in devicetree.
Add support to handle this information from override.
BUG= N/A
TEST= Verify generated static.c on Intel Coffee Lake CRB
Change-Id: I532436aee1d71b79171463124f7b205c145d5b05
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49738
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The PMC doesn't response any more due to invalid CNVi GPIO
configuration. This caused a 30 second boot delay in FSP-S.
Use the same values as FSP-S does. Always disable external I2S BT
audio and use NF3 for pad GPP_D5 and GPP_D6.
Tested on Prodrive hermes:
No boot delay can be observed any more.
Change-Id: I6f4a954786ec21512b0dce908d333952e96de048
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49678
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Disable DRRS in VBT to solve panel flick issue
SKU ID
49/51 will use vbt_garfour.bin
50/52 will use vbt_garfour_hdmi.bin
BUG=b:177783330
BRANCH=octopus
TEST=emerge-octopus coreboot chromeos-bootimage
check /run/debug/i915_drrs_status shows DRRS supported NO.
Cq-Depend: chrome-internal:3534569
Change-Id: I5ebb66ec043a6b409dd5abbc31da417f50dbad5c
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49635
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add support LP_16G_2133 SPD for nightfury.
BUG=None
BRANCH=firmware-hatch-12672.B
TEST=emerge-hatch coreboot
Change-Id: I3709431d8ecb600e25909f456eb0c95db3a3cde2
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49735
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
This change adds a helper macro `BITS_PER_BYTE` so that it doesn't
have to be defined in multiple places.
Change-Id: Idc344047a5660791eaeb1ce8012910c11f6010ba
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
1. Add SOC_INTEL_ALDERLAKE_PCH_M option in Kconfig
2. Select number of I/O based on PCH
Signed-off-by: Varshit Pandya <varshit.b.pandya@intel.com>
Change-Id: I38783595e4b85abf5b3bec234ba01667bd9ba754
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49630
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add Alder Lake M specific CPU, System AGent, PCH (Alder Point aka
ADP),
IGD device IDs.
Document Number: 619501, 626817
Signed-off-by: Varshit Pandya <varshit.b.pandya@intel.com>
Change-Id: Ib13fe229f9e65eae8967aa20e28e29ac5c319265
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49629
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Update DPTF setting from thermal team.
BUG=b:177635236
BRANCH=volteer
TEST=emerge-volteer coreboot chromeos-bootimage, and verified by thermal team.
Change-Id: I87256b5c210ef12c09ef6dd948d80f406ae0500b
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
|
|
Some efuse settings would not be applied automatically, so we need
set the settings manually. The low power consumption would not be
optimal without correct efuse settings.
BUG=b:172636735
BRANCH=none
TEST=see 'pmic_efuse_setting: Set efuses in 11 msecs'
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Change-Id: Ideb862c3cb0f1fee183804aed74fcf141bf1f5df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49006
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
1. USB2 ports 3 and 8 assigned to Type-C connector
2. USB2 port 3 keep USB2_PORT_SHORT setting and add .type_c flag
BUG=b:177481076
TEST=tested on eldrid
Signed-off-by: Nick Chen <nick_xr_chen@wistron.corp-partner.google.com>
Change-Id: I42a39318a151bdf1f5aeb84bb1992be128cb4a4d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
For pq module size registers such as DISP_AAL_SIZE, the high bits
should be HSIZE, while low bits should be VSIZE. Fix the incorrect
settings for these registers where width and height are reversed.
According to MediaTek, there is no practical impact on mt8183 devices,
but it's still nice to get this fixed to avoid future confusion.
BUG=b:171167210
TEST=none
BRANCH=kukui
Change-Id: I4b6aedf9a3ca133fcbe9cb88b99a13d228233e24
Signed-off-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46626
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
TSEG is located below TOLUD. The size is configured in ESMRAMC but can
also be configured with "-global mch.extended-tseg-mbytes=5" command
line argument. Note that the size in ESMRAMC needs to be 'invalid' (3)
for this to take action.
coreboot will leave TSEG at the default 1MiB.
Note that even if TSEG does not end up being used, it is likely a good
idea to not put anything there as if SMM gets locked down by something
else it will suddenly be inaccessible.
Change-Id: I5fd82a42d6602f1369bb3c69556c46f537542705
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Broadwell code unconditionally enables timed MWAIT, but not all Haswell
steppings support it. In preparation for merging Haswell and Broadwell,
also enable timed MWAIT on Haswell code, but only if it is supported.
Change-Id: I1d11d62f1801d65ae4d5623994fd55fd35e8f34a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46916
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The old code was broken and register 0x90 didn't even exist any more in
the config space of the SMBus PCI device, so just always return the MMIO
base address of the SMBus controller. As far as I've seen, no board in
tree uses this functionality at the moment.
Change-Id: Ib80d5c928da6022427afb8ccc969fb2aac953c2d
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reported-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49121
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
IASL optimizes the code differently, which changes the binary.
However, the generated `build/dsdt.dsl` remains identical.
Change-Id: Ifcc8bf4022838056bf1fff853eb2027af684064e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45554
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I5c277a4b8536fd79bda040d4ada9b0c454399b09
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49356
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The katsu project will be using eMCP board design.
BUG=b:176271935
TEST=Boots on chromebook katsu successfully.
BRANCH=kukui
Signed-off-by: Sunway <lisunwei@huaqin.corp-partner.google.com>
Change-Id: I733a9a79e2ea6501e26bf79bfce2b1934a295342
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48893
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There seems to be a bug[1] in the GNU linker for the RISC-V architecture
triggered by symbols that are more than 2GB offset from the program
counter. My next patch is introducing symbols like that and stuck on
this problem. The code path that runs into the issue is only taken when
passing the --emit-relocs flag, which is really only needed for building
rmodules. Since RISC-V platforms don't use any rmodules at the moment,
let's disable the flag on RISC-V until the issue can be fixed in the
toolchain.
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27180
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I784a506034325c0ba937589416acaafbf80080e2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49449
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I97c73324900a0677165afa3f5b182a336d534968
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to a bootblock gpio table for the board as a
first step. Common UART pad config code then gets dropped in CB:48829.
Change-Id: Iad40b6315a29e7aea612a3e1a169372d296d1d6c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49443
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I357099f797be178543a9e6637335cd0a68633071
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49441
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early gpio table for the board as a
first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I8b30eb5d70c34ae3e2ed24ab52dd1357a54c5ae7
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49439
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I0b956427a9cec56d06b03f7f05138f75137b4ea3
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49437
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: Ibc727302109456eb1d86652c947ce85b3a64c5b2
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49436
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I80369ab70d5510cb4f388f3029119e7148361af4
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49435
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to a early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: Id6b55d7f3d3fbfc5b55497708f24006614760d03
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49434
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I130fd26944169430a84c3609432b1b5283581c99
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49432
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: Ie3878b47b8e20c51b928a38df9ccedf2d50d478e
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49431
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: Ib19a4f64eaf25bf2eb47ee60748a68538fc0729a
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49430
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I279956f30cbb6fb031cdfe6aaa09b644b6b7d3e7
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49427
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The LPC/eSPI pad configuration is already done at board-level. Thus,
drop redundant configuration by dropping the call to lpc_configure_pads.
Change-Id: Ib9e62bf19e6f1fbe32a340e4802c13504a0d6def
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49417
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do LPC/eSPI pad configuration at board-level to match other platforms by
adding an appropriate early gpio table in the bootblock.
The soc code gets dropped in CB:49410.
Change-Id: Ie1e53e72c65fdcfe4be2e01134873aa7858c28ff
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49416
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do LPC/eSPI pad configuration at board-level to match other platforms.
This is done by adding one missing pad to the early gpio table and
dropping the call to the soc function.
The soc code gets dropped in CB:49410.
Change-Id: I210633d4520fcfab59f68268bd7991557433ce38
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49415
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do LPC/eSPI pad configuration at board-level to match other platforms by
adding an appropriate early gpio table in the bootblock.
The soc code gets dropped in CB:49410.
Change-Id: If0693a4419c58dde3c4536698940f03c30304b9d
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49414
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do LPC/eSPI pad configuration at board-level to match other platforms.
This is done by adding missing pads to the bootblock gpio table.
The soc code gets dropped in CB:49410.
Change-Id: I95993b1bd4f1fd8b4ac7b21fb89ec4d196b0240a
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49412
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I62ffbe36bd7b7675aa0f41a8c6e9214d04ad4ae5
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49428
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early gpio table for the board as a
first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I6fedcebea3bb31d992bac1e3b21382fea93a8b82
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49429
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: Ieeb738afd54e77ee853ee109009f611411aa0d4a
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49426
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Also switch to `bootblock_mainboard_early_init` to configure the pads in
early bootblock before console initialization, to make the console work
as early as possible. The board does not do any other gpio configuration
in bootblock, so this should not influence behaviour in a negative way
(e.g. breaking overrides).
Change-Id: I5482f44b361925b7d2dbcbf1065c1be035c68b0b
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49424
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Do early pad configuration in early bootblock before console init, to
make the console work as early as possible. The board does not do any
other gpio configuration in bootblock, so this should not influence
behaviour in a negative way (e.g. breaking overrides).
Change-Id: I7dcf88d61c305f0598a0a79f8cfa46ef5009564b
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Do LPC/eSPI pad configuration at board-level to match other platforms by
adding an appropriate early gpio table in the bootblock.
The soc code gets dropped in CB:49410.
Change-Id: Ie33bae481f430a1c4410a0a4e2b2a34a3e78adaa
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49411
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The `mobile` suffix is misleading, since desktop CPUs share the same
CPUIDs. Remove unused stepping IDs and add the full CPUIDs instead.
Finally, add Broadwell CPUIDs in preparation for merging CPU code.
Note that steppings for Haswell in various comments are incorrect.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I19e56b8826b1514550ae95e6363b0df2d08e3cb7
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46915
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Backport Broadwell's s0ix support to Haswell in preparation to unify
both platforms' CPU code. Note that only ULT variants support s0ix.
This option is currently unused, but will be put to use in subsequent
commits, when switching Broadwell mainboards to use Haswell's CPU code.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I91c6f937c09c9254a6f698f3a6fb6366364e3b2b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46924
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The `clear` command for SMMSTORE version 1 does not require a parameter.
Change-Id: I992b7ce5962bf7ee62b7e1970ae7aa1b975ef42e
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49724
Reviewed-by: Jeremy Soller <jeremy@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Allow MRC training in SA GV.
BUG=b:177779469
BRANCH=firmware-volteer-13672.B
TEST=Built and booted into OS.
Signed-off-by: Kevin Chang <kevin.chang@lcfc.corp-partner.google.com>
Change-Id: Idc9f634135b489450f53f8cd28d80649309d0f70
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
BUG=b:175143925
TEST=builds; binary has correct layout
Signed-off-by: Mathew King <mathewk@chromium.org>
Change-Id: I4f3826c8ed0dfd7219eaa5f0cc285f1fe89a4e1d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Assigned USB2 port to type-c use.
BUG=b:177483060
BRANCH=firmware-volteer-13672.B
TEST=Built and booted into OS.
Signed-off-by: Kevin Chang <kevin.chang@lcfc.corp-partner.google.com>
Change-Id: I9bd820406124927d56296508be05033217c0d472
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49638
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On FSP1.1 platform cbmem_initiailze() is called in
chipset_teardown_car_main(). This causes double
call op cbmem_initialize().
Add call to cbmem_online() to avoid double CBMEM init.
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I449ddfc94f1099d7c0e9005e6a5cf509e1433bb1
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
|
|
prog_locate() will load FSP, before CBMEM is initialized.
The vboot workbuffer is used for loading, but
CBMEM_ID_VBOOT_WORKBUF is not available.
A NULL pointer is returned as workbuffer resulting in error
'Ramstage was not loaded!' at second boot.
Initialize CBMEM before calling prog_locate().
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I2f04a326a95840937b71f6ad65a7c011268ec6d6
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
[ 84s] /usr/lib/gcc/i586-suse-linux/10/../../../../i586-suse-linux/bin/ld: msrutils.o:(.bss+0x0): multiple definition of `PresentTypes'; msrtool.o:(.bss+0x14): first defined here
[ 84s] /usr/lib/gcc/i586-suse-linux/10/../../../../i586-suse-linux/bin/ld: msrutils.o:(.bss+0x4): multiple definition of `MsrTypes'; msrtool.o:(.bss+0x18): first defined here
There should be typedefs, not variable definitions.
Change-Id: I663a011e9f1fc169126570d5eac7abe82d204a90
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
For the time being every soc/intel selects ACPI_SOC_NVS
and pwrs is a required field for the common initialisation
implementation of followup work.
Change-Id: I4a0c7eb35f0646898e49fad15c6448607c398731
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49493
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
0 is converted to not used, so use a special value to allow using PCIe
root port #1.
Change-Id: I2d64afc9bb4627913492edad8f36566e7fb18166
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49172
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
This change updates pcie_rp.h to reflow the comment blocks to fit
within 80 columns to match the original style of the file. This
addresses comment received on
CB:49370 (https://review.coreboot.org/c/coreboot/+/49370/comment/0f3fe10d_4e218b5f/).
Change-Id: I565ad602e0e3a2ee09e8345479d82e2ce0a31fd0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
|
|
Increase DCACHE_RAM_SIZE to 32kB and remove "NO_CBFS_MCACHE".
It’s quite safe to increase DCACHE_RAM_SIZE. All LGA775 targets
should have at least 256K L2 cache. That is plenty for XIP RO cache of
bootblock + romstage and a 32K CAR.
Change-Id: I393b2727bd90a990c3108a4dbead62b17d7fc531
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49505
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Correct GPIO settings as below reason:
1. GPP_G7 not being used but set to NF.
2. GPP_C22 and GPP_C23 is set to NC but internal pull down to 20K
BUG=b:177283756
BRANCH=dedede
TEST=emerge-dedede coreboot chromeos-bootimage and boot into emmc
Change-Id: Idf25674efa2336bde98c5abaff278484fd71ea8b
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ben Kao <ben.kao@intel.com>
Reviewed-by: Henry Sun <henrysun@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Replace i2c driver for the SX9324 proximity detector device.
This is first draft settings, will modify it after fine tuning.
BUG=b:175932166
BRANCH=dedede
TEST=run "i2cdump -y -f 15 0x28" to confirm registers as except.
un-approach:
=> register address: 0x01 value: 0x00
approach:
=> register address: 0x01 value: 0x02
Change-Id: I0c8b5948266a07092799c6db556383fa08b924e6
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49018
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Correct GPIO settings as below reason:
1. GPP_D19/GPP_D20/GPP_D21 not being used but set to NF.
2. GPP_B7 should configure as WWAN SAR detect ODL, but set to NC
BUG=b:175932166
BRANCH=dedede
TEST=emerge-dedede coreboot chromeos-bootimage and boot into emmc
Signed-off-by: Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com>
Change-Id: Id7780d5332551ed3fd20ef14f8b5d31164f16385
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This patch preserves MRC training data across FW update.
Change-Id: I6b7273471e4fc9dc25eac80904e012f86a981836
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49681
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
HAS_RECOVERY_MRC_CACHE is already part of CHROMEOS hence remove
redundant Kconfig.
Change-Id: Ia55b587d77ca5be2a8ae701a3ab95cfebe8627db
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Make IGD disable when mainboard user selects SOC_INTEL_DISABLE_IGD.
TEST=Able to get depthcharge pre-OS splash screen with AMD Radeon RX
5700 PCI-E DGPU when mainboard user selects SOC_INTEL_DISABLE_IGD.
Change-Id: Ibbe9c8c4d77018de83815d7d203284b1fbc0da58
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This SOC_INTEL_DISABLE_IGD Kconfig will allow to skip IGD
initialization using FSP GOP and eventually disable the IGD.
TEST=Able to get depthcharge pre-OS splash screen when mainboard
user selects SOC_INTEL_DISABLE_IGD with below HW/FW/SW
configuration:
HW: ADLRVP + AMD Radeon RX 5700 PCI-E DGPU
FW: coreboot with depthcharge as payload for ADLRVP and OpRom for
AMD PCI-E DGPU
SW: Chrome OS RC10 release
Change-Id: I465541cb45c9022d53a5beb3fff1f80660c357c9
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This adds interrupt handlers that end up calling x86_exception().
Change-Id: I3dce539b6f1ef300cf16f20224744a75100f60b8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Picasso doesn't have any EHCI controllers, so it can't support EHCI
debug, so there is no need to specify a MMIO address for the early EHCI
BAR configuration.
Change-Id: I5e904c160c68805a8606a8b2d1ab4fb6172066e7
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49729
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Picasso doesn't have any EHCI controllers, so it can't support EHCI
debug.
Change-Id: I2dae22c0db294f5334d9796d90f432d6c8d304df
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49685
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Change-Id: I28be6091097f713472d5ca3b8b0921ee71238cf0
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
UART pad configuration should not be done in common code, because that
may cause short circuits, when the user sets a wrong UART index. Thus,
add the corresponding pads to the early UART gpio table for the board as
a first step. Common UART pad config code then gets dropped in CB:48829.
Change-Id: I5b99a66fb64683f3647ebff3ab01ceb52058f79c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49440
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The code for setting the LPC generic memory range uses an array of fixed
address ranges not needing explicit decoding, to decide if the address
needs to be written to the LGMR register. Most platforms only mistakenly
add the PCH reserved mmio range, that is not decoded generally,
effectively breaking the mechanism. Only APL uses the array correctly.
That code, in it's current state, does not work (except for APL) and
currently, there is not a single user. Thus, drop it before people start
using it.
Change-Id: I723415fedd1b1d95c502badf7b0510a1338b11ac
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49588
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Do early pad configuration in early bootblock before console init, to
make the console work as early as possible. The board does not do any
other gpio configuration in bootblock, so this should not influence
behaviour in a negative way (e.g. breaking overrides).
Change-Id: I795b8da3c5e1efb51c8fe4673f025839a1c630bc
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Do early pad configuration in early bootblock before console init, to
make the console work as early as possible. The board does not do any
other gpio configuration in bootblock, so this should not influence
behaviour in a negative way (e.g. breaking overrides).
Change-Id: I2f484d232a46214ff98168f41f96d56b047892e2
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Do early pad configuration in early bootblock before console init, to
make the console work as early as possible. The board does not do any
other gpio configuration in bootblock, so this should not influence
behaviour in a negative way (e.g. breaking overrides).
Change-Id: I67bdd9a96928b77a9a178afea7dab03dc370312c
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Do early pad configuration in early bootblock before console init, to
make the console work as early as possible. The board does not do any
other gpio configuration in bootblock, so this should not influence
behaviour in a negative way (e.g. breaking overrides).
Change-Id: I342b9217af0288a3b525e629aac791eb0f880442
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Change-Id: Ied235972d24276d7c88a2f50f192d69d24ae6e05
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45816
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
We need to write some special values to key protection registers before
applying init_setting table and lp_setting table to PMIC. Otherwise,
those settings won't take effect.
After applying init_setting table and lp_setting table, we lock the
settings by writing zero to key protection registers.
Reference datasheet: MT6359_PMIC_Data_Sheet_V1.5.docx, RH-D-2018-0205.
BUG=b:172636735
BRANCH=none
TEST=boot asurada correctly
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Change-Id: I593d4e02bf0b62ac297957caf4ae1c1837f1f38d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48954
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Add scp voltage initialization.
BUG=none
BRANCH=none
TEST=boot asurada correctly
Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
Change-Id: I68302715ae804fed11bb54f4dfc4e90cde5224df
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
Until now some FSP-S parameters were configured for Siemens APL
mainboards via the Binary Configuration Tool (BCT). For simplification,
the original APL FSP binary should now be used. For this purpose, the
corresponding FSP-S parameters are set via devicetree, respectively via
mainboard_silicon_init_params accordingly.
The following parameters are affected:
- Disable CPU power states (C-states)
- Set lowest Max Pkg Cstate - PkgC0C1
- Disable PCIe Hot Plug for all enabled RPs
- Disable PCIe Transmitter Half Swing for all RPs
- Disable PCIe Active State Power Management (ASPM) for all RPs
- Disable PCIe L1 Substates for all RPs
TEST:
- Compare old with new coreboot log on mc_apl5, found no differences
- Boot Linux v4.4 and check output of 'lspci'
Change-Id: I5af627defd6426140cc9a74bb18db400a8971d72
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49462
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: Iaa05c1162b2533957091c719ea43ffb8d004c5eb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49275
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Functionality depends of CMAP and CMBP references inside board
specific ASL implementation. Only roda/rk9 and roda/rk886ex has
that.
Change-Id: I4da8292375cb589d67dc68496b1e81971bc2a61f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49274
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
APIC was not referenced anywhere in ASL.
MPEN has references under boards:
getac/p470, roda/rk9, roda/rk886ex.
MPEN has reference also in Intel SpeedStep ASL.
Replace static MPEN with detection of multiple CPUs
installed.
Change-Id: Ib5f06416b23196b7227ccd5814162925c31c084b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Only amd/picasso and amd/stoneyridge have reference to
PCNT and that could be replaced with acpigen.
Remove the PCNT name from GNVS OperationRegion elsewhere.
Change-Id: I7dd45a840b3585fd24c31fd923b991c34ab4d783
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The BACKLIGHT_ENABLE pin on this board unfortunately defaults to a
pull-up on power on, meaning the backlight is immediately enabled. Best
we can do about that is to turn it off again early and wait until it is
actually correct in the panel power sequence to turn it back on.
Some panels want an explicit 80ms delay after training the eDP
connection before the backlight is turned on (this is probably just to
avoid temporary display artifacts, but whatever). We don't want to
busy-wait that extra time, so instead just delegate turning on that GPIO
to the payload (which is also in charge of the backlight PWM already).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id8dafbdcb40175fbc9205276eee698583b971873
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
|
|
Fixed resources should not overlap.
Change-Id: I166e0095ac0cc0dd8271a693bb452f505a1a9413
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000.
Change-Id: Ia6c2ee29e37040ea9b11505e9888c7f6f8da78bc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This memory is used for option roms and BIOS. This matches the ACPI
code.
Change-Id: I53dd4b967569889108352ca70086a12ce252e8e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49624
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000-0xbffff.
Change-Id: I626989fa6625e0b3613a11e709c614d40a788b0e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This pulls in the following changes:
* Drop geode_lx
* cpu/amd/model_fxx: Drop unused microcode
* cpu/amd/model_10xx: Drop unused microcode
* soc/mediatek/mt8192: Add dram.elf for DRAM full calibration
* soc/mediatek/mt8192: Add dpm binary
* soc/mediatek/mt8192: Add 4266Mbps flag for dpm & dram blob
* soc/mediatek/mt8192: add SPM firmware
* soc/mediatek/mt8192: Support 26M clock off in SPM
* soc/mediatek/mt8192: Add SSPM firmware
* soc/mediatek/mt8192: Add MCUPM firmware
* soc/mediatek/mt8192: Update MCUPM firmware
* soc/mediatek/mt8192: Support discrete DRAM modules
* mb/amd/majolica: Add APCB configuration files
Change-Id: I5c18349307421707fac71f392b785f3e2bef3acb
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49675
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
Fixed resources should not overlap.
Change-Id: I7a70f5475c1d701db2cb8cbea659bacf6d0c52ae
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This cosmetic change does 2 things:
- change bitwise shifting to division
- Make the division by / KiB explicit for fixed legacy ranges like
0xa0000-0xbffff.
Change-Id: If4e05f496abc05e06a944b244824376f3937a57b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Chrome EC dropped strago support, so we need to disable it here
before updating our Chrome EC submodule.
Change-Id: Ied8905e995fd040b981ce18e95e225ade496d23c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48216
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ia27bc256376c61a7330196a5b4a331dd79386fb6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49472
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I673f038b4ce3c4141db128a65be71e7a242dfd28
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48856
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Struct will be synced with picasso with followups.
Change-Id: I5f460cc3849bf1fad1f6da61169893488ccb2b40
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48855
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In order to use the function smbios_mainboard_version()
to query the board revision from the EC.
we need to select GOOGLE_SMBIOS_MAINBOARD_VERSION.
BUG=b:177818769
TEST=1. emerge-volteer coreboot chromeos-bootimage
2. flash the image to the device and check board rev
by using command `dmidecode -t 1 | grep Version`
Change-Id: I2474ee03845356d0775f6da25274f696ad33f935
Signed-off-by: Zhuohao Lee <zhuohao@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49644
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The SoC code has in implicit dependency on this option, so select it in
the SoC code instead of the mainboard code.
Change-Id: Iea908c142f4a94a107cf74a31d9f5e29668d4b5b
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Create the sasukette variant of the waddledee reference board by
copying the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:175848514
BRANCH=None
TEST=util/abuild/abuild -p none -t google/dedede -x -a
make sure the build includes GOOGLE_SASUKETTE
Signed-off-by: Tao Xia <xiatao5@huaqin.corp-partner.google.com>
Change-Id: I0a554efe0919dc2f5880f0f7817a37bd4be88ed9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
This change enables LTE modem for sasuke.
- Add LTE modem device into devicetree
- Add GPIO control for LTE modem power on and off
BUG=177177967
TEST=Built and verified modem device existence with lsusb
Change-Id: I34ba8ab00b73f24d1786ab014e9981b172a63a27
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49163
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
BUG=None
BRANCH=dedede
TEST=enable CHROMEOS_WIFI_SAR in config of coreboot,
emerge-dedede coreboot-private-files-baseboard-dedede coreboot chromeos-bootimage.
Cq-Depend: chrome-internal:3531583
Change-Id: If69258db257353c9b859a27e2a4c088f74b00ab9
Signed-off-by: Seunghwan Kim <sh_.kim@samsung.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49466
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|