After the mcache is copied into CBMEM, it has *just* the right size to
fit the final tag with no room to spare. That means the test to check if
we walked over the end must be `current + sizeof(tag) <= end`, not
`current + sizeof(tag) < end`.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I25a0d774fb3294bb4d15f31f432940bfccc84af0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48277
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch adds the first stage of the new CONFIG_CBFS_VERIFICATION
feature. It's not useful to end-users in this stage so it cannot be
selected in menuconfig (and should not be used other than for
development) yet. With this patch coreboot can verify the metadata hash
of the RO CBFS when it starts booting, but it does not verify individual
files yet. Likewise, verifying RW CBFSes with vboot is not yet
supported.
Verification is bootstrapped from a "metadata hash anchor" structure
that is embedded in the bootblock code and marked by a unique magic
number. This anchor contains both the CBFS metadata hash and a separate
hash for the FMAP which is required to find the primary CBFS. Both are
verified on first use in the bootblock (and halt the system on failure).
The CONFIG_TOCTOU_SAFETY option is also added for illustrative purposes
to show some paths that need to be different when full protection
against TOCTOU (time-of-check vs. time-of-use) attacks is desired. For
normal verification it is sufficient to check the FMAP and the CBFS
metadata hash only once in the bootblock -- for TOCTOU verification we
do the same, but we need to be extra careful that we do not re-read the
FMAP or any CBFS metadata in later stages. This is mostly achieved by
depending on the CBFS metadata cache and FMAP cache features, but we
allow for one edge case in case the RW CBFS metadata cache overflows
(which may happen during an RW update and could otherwise no longer be
fixed because mcache size is defined by RO code). This code is added to
demonstrate design intent but won't really matter until RW CBFS
verification can be supported.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I8930434de55eb938b042fdada9aa90218c0b5a34
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41120
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The initial bootblock assembly code on x86 is just put into the .text
section, which just happens to come before all the individual .text.*
function sections in the program.ld script. So it tends to be at the
start of the image, but if you inserted another linker script section
with contents before .text, it would cause a problem. (I'm not sure if
it's an architectural requirement for _start16bit to come at the start
of the image, but at least its 4K alignment requirement would waste a
lot of space if it didn't.)
This patch moves the section to .text._start which is the name other
architectures use for the code they want in the very front of the image
and which is listed first in program.ld.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia84e6e33ec29584d356e226e8fdcb8c9334d49af
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46834
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the upcoming introduction of CBFS verification, a lot more CBFS
files will have hashes. The current cbfstool default of always printing
hash attributes when they exist will make cbfstool print very messy.
Therefore, hide hash attribute output unless the user passed -v.
It would also be useful to be able to get file attributes like hashes in
machine parseable output. Unfortunately, our machine parseable format
(-k) doesn't really seem designed to be extensible. To avoid breaking
older parsers, this patch adds new attribute output behind -v (which
hopefully no current users pass since it doesn't change anything for -k
at the moment). With this patch cbfstool print -k -v may print an
arbitrary amount of extra tokens behind the predefined ones on a file
line. Tokens always begin with an identifying string (e.g. 'hash'),
followed by extra fields that should be separated by colons. Multiple
tokens are separated by the normal separator character (tab).
cbfstool print -k -v may also print additional information that applies
to the whole CBFS on separate lines. These lines will always begin with
a '[' (which hopefully nobody would use as a CBFS filename character
although we technically have no restrictions at the moment).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I9e16cda393fa0bc1d8734d4b699e30e2ae99a36d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41119
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This function name clashes with cbfs_walk() in the new commonlib CBFS
stack, so rename it to cbfs_legacy_walk(). While we could replace it
with the new commonlib implementation, it still has support for certain
features in the deprecated pre-FMAP CBFSes (such as non-standard header
alignment), which are needed to handle old files but probably not
something we'd want to burden the commonlib implementation with. So
until we decide to deprecate support for those files from cbfstool as
well, it seems easier to just keep the existing implementation here.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I37c7e7aa9a206372817d8d0b8f66d72bafb4f346
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41118
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IASL version 20180927 and greater, detects Unnecessary/redundant uses of
the Offset() operator within a Field Unit list.
It then sends a remark "^ Unnecessary/redundant use of Offset"
example:
OperationRegion (OPR1, SystemMemory, 0x100, 0x100)
Field (OPR1)
{
Offset (0), // Never needed
FLD1, 32,
Offset (4), // Redundant, offset is already 4 (bytes)
FLD2, 8,
Offset (64), // OK use of Offset.
FLD3, 16,
}
We will have those remarks:
dsdt.asl 14: Offset (0),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
dsdt.asl 16: Offset (4),
Remark 2158 - ^ Unnecessary/redundant use of Offset operator
Change-Id: I260a79ef77025b4befbccc21f5999f89d90c1154
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43283
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch reduces some code duplication in cbfstool by switching it to
use the CBFS data structure definitions in commonlib rather than its own
private copy. In addition, replace a few custom helpers related to hash
algorithms with the official vboot APIs of the same purpose.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
This patch introduces two new CBFS API functions which are equivalent to
cbfs_map() and cbfs_load(), respectively, with the difference that they
always operate on the read-only CBFS region ("COREBOOT" FMAP section).
Use it to replace some of the simple cases that needed to use
cbfs_locate_file_in_region().
Change-Id: I9c55b022b6502a333a9805ab0e4891dd7b97ef7f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39306
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like the option is generally not compatible with
garbage collections.
Nothing gets inlined, for example is_smp_boot() no longer
evaluates to constant false and thus the symbols from
secondary.S would need to be present for the build to pass
even if we set SMP=n.
Also the addresses of relocatable ramstage are currently
not normalised on the logs, so util/genprof would be unable
dress those.
Change-Id: I0b6f310e15e6f4992cd054d288903fea8390e5cf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add stubbed out GPIO configuration and perform GPIO initialization
during bootblock and ramstage.
BUG=b:174266035
TEST=Build Test
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ia658ab4b466242cf8658abb239f19a9c0a03849a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add entry point stubs of each stage for Brya. More functionalities will
be added later.
BUG=b:174266035
TEST=Build Test
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I44934c05ee32090b6e34648ee02f004c83e93d57
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48063
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:174266035
TEST=Build Test
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ia1ba8c997680c60ee1eabfae82459e127f664117
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48062
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current location for the sensor initialization procedure was chosen
by mistake. Move this into a separate function in nct7802y.c .
Change-Id: I093ae75db5f0051bff65375b0720c86642b9148a
Signed-off-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adapts cbfs_load() and cbfs_map() to use the new CBFS API
directly, rather than through cbfs_boot_locate(). For cbfs_load() this
means that attribute metadata does not need to be read twice.
Change-Id: I754cc34b1c1471129e15475aa0f1891e02439a02
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfs_boot_locate() is supposed to be deprecated eventually, after slowly
migrating all APIs to bypass it. That means common features (like
RO-fallback or measurement) need to be moved to the new
cbfs_boot_lookup().
Also export the function externally. Since it is a low-level API and
most code should use the higher-level loading or mapping functions
instead, put it into a new <cbfs_private.h> to raise the mental barrier
for using this API (this will make more sense once cbfs_boot_locate() is
removed from <cbfs.h>).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I4bc9b7cbc42a4211d806a3e3389abab7f589a25a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch flips the default of CONFIG_NO_CBFS_MCACHE so the feature is
enabled by default. Some older chipsets with insufficient SRAM/CAR space
still have it explicitly disabled. All others get the new section added
to their memlayout... 8K seems like a sane default to start with.
Change-Id: I0abd1c813aece6e78fb883f292ce6c9319545c44
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change drops the special check added for TGL/JSL platforms and
performs cse_fw_sync on BS_PRE_DEVICE entry. This was being done later
in the boot process to ensure that the memory training parameters are
written back to SPI flash before performing a reset for CSE RW
jump. With the recent changes in CB:44196 ("mrc_cache: Update
mrc_cache data in romstage"), MRC cache is updated right away in
romstage. So, CSE RW jump can be performed in BS_PRE_DEVICE phase.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I947a40cd9776342d2067c9d5a366358917466d58
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48130
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
At least a part or the remaining definitions in the soc-specific smi.h
files are also common, but those have to be verified more closely.
Change-Id: I5a3858e793331a8d2ec262371fa22abac044fd4a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48217
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
SMBHST_STAT_NOERROR was a redefinition of SMBHST_STAT_INTERRUPT that was
used in smbus_wait_until_done. Remove the misleading bit definition that
also didn't correspond with the register definitions and replace it with
the definition of the actual bit that gets checked. Also add a comment
that the code actually checks the IRQ status flag to see if the last
command is already completed.
Change-Id: I1a58fe0d58d3887dd2e83320e977a57e271685b3
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The patch also rewrites the bit definition using shifts to make them
easier to read.
The older non-SoC chips can probably also use the new header file, but
for this patch the scope is limited to soc/amd, since the older non-SoC
chips don't use the SMBUS controller code in soc/amd/common.
TEST=Timeless build for amd/mandolin and amd/gardenia doesn't change.
Change-Id: Ifd5e7e64a41f1cb20cdc4d6ad1e675d7f2de352b
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The code on Stoneyridge didn't set the FCH_AOAC_TARGET_DEVICE_STATE bits
to FCH_AOAC_D0_INITIALIZED like the code for Picasso does, but that is
the default value after reset for those bits on both platforms.
Change-Id: I7cae23257ae54da73b713fe88aca5edfa4656754
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The register locations and bit definitions are the same for Stoneyridge
and Picasso. Since not all devices are present on all SoCs, keep those
numbers in the SoC-specific code.
Change-Id: Ib882927e399031c376738e5a35793b3d7654b9cf
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48182
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The ability to set up a custom memory profile is useful if you don't
like the XMP memory profiles (if they exist) of your RAM sticks, or
want to try some overclocking. Read SPD data will be overriden by your
custom values. Tested on Crucial BLT8G3D1869DT1TX0 (1866MHz 9-9-9-27).
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I1238ff00ef0efd11ea807794827476c30ac98065
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Add XMP memory profiles support that has been tested on f15tn (A88XM-E)
and f16kb (AM1I-A) with two Crucial BLT8G3D1869DT1TX0, XMP 1 profile.
Added using the datasheets from https://github.com/mikebdp2/ddr3spd :
JEDEC_DDR3_SPD_4_01_02_11R24.pdf and Intel_XMP_Spec_Rev1.1.pdf
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I584416e3376afdf377a11783e55c5e9ff41e6b0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40488
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On x86_64 the cannary is 8 bytes in size, so write the additional
4 bytes to make SMM handler happy.
Tested on Intel Skylake in long mode. No longer dies in SMM.
Change-Id: Id805c65717ec22f413803c21928d070602522b2c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48215
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The previous code was crashing when jumping back to ramstage, now it
works. The GDT is now using the same values as the other ones in
coreboot.
Change-Id: Id00467d9d8a4138ddea73adbda4b39f12def583f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48214
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the fw_config entries for the newly added boot device fields.
These are added as separate fields since a board may have more
than one selected.
BUG=b:173129299
TEST=abuild google/volteer
Change-Id: I2af9ffcf0b90d4f4b7f2f31613ee110d8f350454
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The initial commit only focused on GL9755S and RTS5261, but there
were recently other cards added to the fw_config and those also
need to be added to the probe lists.
BUG=b:173207454
TEST=abuild google/volteer
Change-Id: Ic27074a016ffbd4c4dd86104a6d85437357c4b82
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48159
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Now that the initial version of the Picasso FSP binaries have finally
landed, we can set the default paths to point to them now.
Change-Id: Ib2241cc90c7113e0c3de4409e08b9ae1f4c2f51e
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42472
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add the newest SMU firmware and FSP blobs for the picasso project.
This supports Picasso, Dali, and Pollock devices.
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I75e6f3d2a59ed8b2e42afba3a6978574373ec4e5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48211
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The FSP-M/S/T related headers added are generated as per FSP v2341.
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I98f738402490b47efa1a346f81db47857e384e13
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47803
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Update Kconfig:
1. use FSP2.1 instead of 2.2
2. remove HECI_DISABLE_USING_SMM config
3. update CAR related stack & ram size
4. update FSP heap size
5. set IED region size = 0 as it is not used
6. update SMM TSEG size
7. update RP & I2C max device #s
8. update UART base address
Signed-off-by: Tan, Lean Sheng <lean.sheng.tan@intel.com>
Change-Id: I6a44d357d71be706f402a6b2a4f2d4e7c0eeb4a9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45078
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The extracted VBIOS Option ROM ships the same ID for several
generations, not matching the ID on the hardware resulting in a
mismatch, and coreboot does not run the Option ROM.
PCI ROM image, vendor ID 8086, device ID 0406,
ID mismatch: vendor ID 8086, device ID 5916
Add the appropriate mappings.
TEST=coreboot runs the ROM on the TUXEDO Book BU1406.
Change-Id: Ia167d91627a7ff1b329ea75f150b3ce95c0acccb
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43853
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Default VBT supports only integrated Display port. Drawman supports a
HDMI port and hence support a separate VBT for Drawman.
BUG=b:161190931
BRANCH=dedede
TEST=Build and boot to OS in Drawlat and Drawman.
Cq-Depend: TBD
Change-Id: I8895cc67d87428eddb31328f1e3a90c346b54533
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Add daughter-board ports bit field and mask in devicetree.
BUG=b:161190931
BRANCH=dedede
TEST=Build and boot to OS in drawlat & drawman.
Change-Id: Ibbd86fc8c3e44a7d1703b8ce75c48881226545c9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Config HID-I2C device to level trigger.
As per HID over I2C Protocol Specification[1] Version 1.00 Section 7.4,
the interrupt line used by the device is required to be level triggered.
Hence, this change updates the configuration of the HID over I2C devices
to be level triggered.
References:
[1] http://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx
BUG=b:171546871
TEST=emerge-dedede coreboot
Change-Id: If8be25f591715765a99920b79482c862b1cc7079
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Check that stages running in CAR have their start and end in CAR.
Change-Id: I292aacce564c23d9ae21aa46c5e2f8784fa6a609
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36623
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Older GCCs don't support _Static_assert without a message string as the
second argument. AFAICT _Static_assert with two arguments is in C11 but
omitting the message argument is an extension.
The tests appear to be built with the system gcc rather than our
crossgcc so that's probably why this was not cought by CI.
Change-Id: I41fd0ffc42ded8b6d145c3ec30cc7407a78b9a43
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In commit 09d50671e6 the AOAC code was
reworked for Picasso and this patch ports this back to Stoneyridge to
facilitate factoring out the functionality into common code.
Change-Id: I836b91dc647987d064170fff7c8ca6ef2ee49211
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The numbers in the array are unsigned, so use an unsigned type there.
Change-Id: I9a85594de0e4c53db965ab84239f19eb46432348
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The power_off_aoac_device function clears the FCH_AOAC_PWR_ON_DEV bit,
so the comment should be that it powers off the devices.
Change-Id: Ia5e5d80b1977c3f53fcd9cf6d48bdb59045dfc3c
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48155
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Julius Werner