JSL FSP support FSP 2.2. FSP 2.2 introduces Multiphase SI init
support through the FSP-S arch UPD. The FSP-S arch UPD structure
is added in edk2 stable 2020 branch. Switching the support for
JSL to edk2-stable202005 to intercept the FSP2.2 related support.
BUG=b:162184827
BRANCH=None
TEST=Build and boot JSLRVP
Cq-Depend: chrome-internal:3221772
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Change-Id: Ieed1b58e491d5a89043c418f0f44f2ee9af111f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44576
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move a size of DDR3 SPD memory (always 256 bytes) to a common define.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I80c89ff6e44526e1d75b0e933b21801ed17c98c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Introduce FSPT_ARCH_UPD and FSPS_ARCH_UPD to support debug events
and multi-phase silicon initialization.
For backward compatibility the original structures are kept and
new ARCH_UPD structures will be included only when UPD header
revision equal or greater than 2.
ref:
- https://bugzilla.tianocore.org/show_bug.cgi?id=2781
BUG=b:162184827
BRANCH=None
TEST=Build and boot JSLRVP
Cq-Depend: chrome-internal:3221772
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Change-Id: I728aff1df3d361e21e4617647c4ec0e2d345a8c2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Add charger input current throttling for drawcia system
BUG=None
BRANCH=None
TEST=Built and tested on drawcia system
Change-Id: I34fdc23fcd84b5c27c2bada769f7a9049c2a56a5
Signed-off-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This field eventually gets interpreted as MT/s by SMBIOS instead of MHz. Translate from Mhz to MT/s by multiplying by 2.
BUG=b:154654737
TEST=dmidecode -t 17 matches expected speed
Change-Id: I51b58cb0380f2a2bf000347395ac918ac0717060
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates the remaining
pointers that are not consumed by libpayload code, all of them
strings.
Also update the comment that `libsysinfo` only containts physical
addresses.
Change-Id: I9d095c826b00d621201c34b329fb9b5beb1ec794
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates all the references
to CBMEM entries that are not consumed inside libpayload code.
Change-Id: I3be64c8be8b46d00b457eafd7f80a8ed8e604030
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43580
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`. This updates all the references
to coreboot-table entries that are not consumed inside libpayload
code.
Change-Id: I95cb0af151e0707a1656deacddb8a5253ea38fc3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Our AArch64 code supports dynamic framebuffer allocation which
makes it necessary to change the framebuffer information during
runtime. Having a pointer inside `libsysinfo` made a mess of it
as the pointer would either refer to the original struct inside
the coreboot table or to a new struct inside payload space. The
latter would be unaffected by a relocation of the payload.
Instead of the pointer, we'll always keep a copy of the whole
struct, which can be altered on demand without affecting the
coreboot table. To align the `video/graphics` driver with the
console driver, we also replace `fbaddr` with a macro `FB` that
calls phys_to_virt().
Change-Id: I3edc09cdb502a71516c1ee71457c1f8dcd01c119
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43578
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`.
Change-Id: Icd30e95c6b8115d16dd793914fb01a1a9da1854f
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43577
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
In the presence of self-relocating payloads, it's safer to keep
physical addresses in `libsysinfo`.
Change-Id: I64a37bef263022edb504086c02a3fd22ce068ba4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Same as with other consoles and drivers that cache an address
outside the payload (e.g. video/corebootfb), we should store the
physical address, so we can derive the virtual address on demand.
This makes it save to use the address across relocations.
As a first step in migrating `libsysinfo` to `uintptr_t`, we
also switch to the physical address there.
Fixes the default build of FILO, tested with Qemu/i440FX and Qemu/Q35.
Change-Id: I4b8434af69e0526f78523ae61981a15abb1295b0
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add downgrade support for CSE RW firmware.
When CSE FW is downgraded, CSE may get into data compatibility issues.
To avoid such issues, coreboot sends DATA CLEAR HECI command to CSE to
clear CSE run time data on proactive basis during a downgrade and
when CSE indicates a data mismatch error through GET_BOOT_PARTITION_INFO.
BUG=b:144894771
TEST=Verified on hatch
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I0a3a3036e448e5a743398f6b27e8e62965dbff3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40561
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Closing stdout early seems to have a detrimental effect on kconfig on a
system under high load (e.g. when doing lots of builds in parallel).
Change-Id: I6987f1deac596124c7b397bf7bc5a78d691cc538
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix compilation under x86_64.
Tested on HP Z220:
* Still boots on x86_32.
Change-Id: I2a3ac3e44a77792eabb6843673fc6d2e14fda846
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The code can only be compiled as x86_32. Mark it as such to fix errors
in the x86_64 assembler. The caller has to make sure to call this code
in protected mode only.
Tested on HP Z220:
* Still boots on x86_32.
Change-Id: I4c0221fb3886b586c22fe05e36109fcdc20b7eed
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44674
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Enter long mode on secondary APs.
Tested on Lenovo T410 with additional x86_64 patches.
Tested on HP Z220 with additional x86_64 patches.
Still boots on x86_32.
Change-Id: I916dd8482d56c7509af9ad0d3b9c28bdc48fd0b1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The zork devices use the ACP (audio co-processor) and the I2S interface
for audio and not the HDA (HD audio) device and interface.
BUG=b:158535201,b:162302028
BRANCH=zork
TEST=Equivalent change on Mandolin disabled the non-GPU HDA device with
the corresponding FSP change applied.
Change-Id: I6c7de881cff8398fe416151fab219142d4fc904a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44681
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP has recently added support for a UPD switch to disable the non-GPU
HD Audio controller. This change adds the coreboot side of the feature.
To avoid having two HD Audio enable options, the value of the
hd_audio_enable UPD is determined by the enable state of the non-GPU HD
Audio controller in the platform devicetree.
BUG=b:158535201,b:162302028
BRANCH=zork
TEST=With the corresponding FSP change applied the non-GPU HD Audio
device is hidden when switched off in devicetree and remains present and
functional when switched on in devicetree.
Change-Id: Ib2965e0742f4148e42a44ddad8ee05f0c4c7237e
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44680
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 65605276a4.
This patch shouldn't have been merged yet, since the issues on the FSP
side aren't sorted out yet, so the FSP-side changes haven't landed yet.
This byte will be used for an audio-related setting instead to have the
audio settings grouped together.
BRANCH=zork
Change-Id: If79900f3a92fd949d7653001e1ca2faac7061e3c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44678
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since Puff uses CSE Lite SKU that supports in-field CSME
updates an additional reset is triggered when jmp from RO
to RW during boot. However this reset is not detected by
the cr50 running older firmware because the strapping
configuration for EFS2 uses PLT_RST_L to assert to cr50
that a AP reset occured. The older cr50 firmware
version of 0.0.22 only monitors AP resets via SYS_RESET_L
and hence never detects the reset.
To mitigate the issue above a modified reset sequence is
required to be performed to signal the reset occured and
hence a board-specific cse_board_reset() strong symbol is
provided to modify the flow accordingly.
V.2: Select CHROMEOS_CSE_BOARD_RESET_OVERRIDE common
implementation instead of a local variant in mainboard.c
BUG=b:162290856
BRANCH=puff
TEST=none
Change-Id: I27ab9711aedf92b5af7a58f3b5472ce79f78c8fa
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44454
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This will ensure that the cold reset is performed when CSE Lite jumps
from RO to RW.
BUG=b:162386991
TEST=Ensure that Drawcia board boots to OS. Ensure that global reset is
triggered when cr50 is running firmware versions newer than 0.0.22. On
cr50 versions 0.0.22 or older, EC triggers cold reset of AP.
Change-Id: I46a390c71e380328cd7fe70214df09553b2db75c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44645
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
When CSE Lite jumps from RO to RW, certain boards need to request
Embedded Controller (EC) to trigger cold reset of SoC. This change
introduces a helper to override the default global reset.
BUG=None
TEST=Ensure that Drawcia board boots to OS. Ensure that global reset is
triggered when cr50 is running firmware versions newer than 0.0.22. On
cr50 versions 0.0.22 or older, EC triggers cold reset of AP.
Change-Id: I8078e2436d1d58a650bf7b0cf38b5bb89a474187
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Introduce a helper to get the cached cr50 firmware version. This
information is in turn used to identify the strap configuration
supported by Cr50.
BUG=None
TEST=Ensure that Drawcia board boots to OS. Ensure that the version
cached cr50 firmware version is returned.
Change-Id: Id84b152993f253878a6c133cc433a0da2c990cf2
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44653
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make GPIO_4 and GPIO_5 PAD_NC in ezkinil/gpio.c. None of the Ezkinil SKUs
use internal stylus and hence pen pads are configured as NC.
BUG=b:164892883, b:165342107
TEST=Verified taht pen detect GPIO does not cause spurious wakes.
BRANCH=None
Signed-off-by: Josie Nordrum <josienordrum@google.com>
Change-Id: I7557575cf8b8e0f849e05bda1d69acf61e91a157
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44629
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the IT8728F datasheet it is possible to add an extra delay
between 3VSBSW# being set and PWRGD3 being set during resume from
Suspend-to-RAM. This is enabled in the special function selection
register, the default being 0.
This is also useful for the IT8720F although this chip does not have the
PWRGD3 output. On the corresponding pin it has PWROK2, which the setting
then seems to apply to.
The datasheet for the IT8720F marks the corresponding bit as reserved,
but the vendor BIOS of an Acer Aspire M3800 sets it anyway. Without
setting the bit, coreboot fails to resume from S3. Oscilloscope
measurements have shown that setting the bit increases the delay between
3VSBSW# being set and PWROK2 being set from around 1 us to 140 ms. The
actual use of PWROK2 on the board design is unclear - the only
destination it seems to reach is a pin header near the SuperIO marked as
"GPIO1".
Signed-off-by: Michael Büchler <michael.buechler@posteo.net>
Change-Id: I51cbf2470dc2b840a647a20090acb5a0cf4f4025
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The assumption was that the fmap cache would be initialized in
bootblock, otherwise an error is shown. This error is showing
up in psp_verstage when the fmap cache is initialized there, so
create a new ENV value for ENV_INITIAL_STAGE.
BUG=None
TEST=Boot, see that error message is gone from psp_verstage
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I142f2092ade7b4327780d423d121728bfbdab247
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43488
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When booting from the RO region of a VBOOT enabled ROM, there shouldn't
be a reliance on anything outside of the RO section. This includes the
APOB_NV region (similar to the MRC cache region). By skipping the
region when setting up the BIOS Directory table, the PSP won't try to
use the region when booting.
The APOB_NV region is still used for the VBOOT RW sections.
BUG=b:158363448
TEST=Build RO with no APOB_NV region. Dump the BDT and verify that
it's not in RO, but is in RW_A & RW_B. Boot into recovery.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I13c35ba8a2331492744d2acf257db15e4a53102a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
amdfwtool currently assumes that we MUST have an apob_nv area if we
have an aopb. This is not required, so if neither the apob_nv size or
base are specified, just move on.
BUG=b:158363448
TEST=Build an image with no APOB_NV region. Dump regions to show that
it's not there.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ibaeacd3dcdfd73f690df61c2a19d39bbb9dcc838
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44045
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Utilize the SOC_AMD_COMMON_BLOCK_GRAPHICS_ATIF option to provide
full range backlight settings to the kernel.
BUG=b:163583825
Change-Id: I3c337fad38e668488800f4d6bc583a82a93659d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The Linux kenerl driver for AMD gpu currently has a floor
value of 12 for brightness settings (AMDGPU_DM_DEFAULT_MIN_BACKLIGHT).
AMD indicates they did this because they were concerned with certain
panels flickering at lower backlight values. However, for unaffected
panels it's desirable to be able to have the panel "turn off" at
the lowest backlight setting. The only way to do that is to provide
ATIF bindings that indicate backlight range.
Option SOC_AMD_COMMON_BLOCK_GRAPHICS_ATIF is added to provide a full
range for the backlight setting. If needed, this path can be built upon
for fuller support, but for the time being this is the only thing
necessary to make the backlight be full range.
BUG=b:163583825
Change-Id: If76801a8daf6a5e56ba7d118956f3ebce74e567a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44642
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The GDT loading did work fine on x86_64 a few months ago, but today it
only works in QEMU, but not on real hardware or KVM-enabled QEMU. This
might be related to toolchain changes.
Use 64bit GDT loading on x86_64 and force the assembler to generate a
64bit address load on the GDT. This will make sure no 32bit (signed)
displacement op is being generated, which points to the wrong address
in longmode.
Verified using readelf and made sure no R_X86_64_32S relocation symbol
is emitted. Disassembled the romstage ELF and made sure the GDT address
is 64bit in size.
Tested on QEMU and KVM-enabled QEMU: Doesn't crash any more on KVM.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Change-Id: Ia824f90d9611e6e8db09bd62a05e6f990581f09a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43136
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Convert raw GPIOs to coreboot macros using newly-added support
for Cannon/Whiskey/Coffee/Cometlake SoCs to intelp2m
Test: build/boot Librem Mini, no smoke released.
Change-Id: I6ac747ad4e650c24d2b7e34228ff74140c51a0c1
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Ronak Kanabar