Age | Commit message (Collapse) | Author |
|
STM_RSC_MEM_DESC defines rws_attributes as 3 bits, which can't be
greater than 7.
Found-by: Coverity Scan #1430578
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I1efd007e96abd6d5d36f314752abfadffb0024d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
|
|
Change-Id: Id35a0a589128ea2dfb2f0e5873d4fa087b0886a9
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Change-Id: I0d2a9c30d332b16efd548433a54f974067bd281e
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the commonlib, console, northbridge, security, and
southbridge directories that don't already have an SPDX license line
at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I02804a10d0b0355e41271a035613d9f3dfb122f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Use C99 flexible arrays instead of older style of one-element or
zero-length arrays.
It allows the compiler to generate errors when the flexible array does
not occur at the end in the structure.
Change-Id: I3ab3538b276fee5ed135bb4e88d9ef2cd6a00bb9
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76843
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Id57a9c689d5fa35cf1b4df9c37b12dd95cb9ef23
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Change-Id: Ibd41382d0e0ef58498ac925dc9e10b54a76a798a
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69800
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I3def65c016015d8213824e6b8561d8a67b6d5cf0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
The do_smm struct element in the mp_state struct was an int even though
it only had two possible states, so change it to bool to make this more
obvious. Also change the return type of is_smm_enabled from int to bool.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I8d2d95f0497649d67565243d14a5ab9c9cdda412
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Some processor families allow for SMM setup to be done in parallel.
On processors that have this feature, the BIOS resource list becomes
unusable for some processors during STM startup.
This patch covers two cases: (1) The BIOS resource list becomes twice
as long because the smm_relocation function is called twice - this is
resolved by recreating the list on each invocation. (2) Not all
processors receive the correct resource list pointer - this is resolved
by having every processor execute the pointer calculation code, which is
a lot faster then forcing all processors to spin lock waiting for this
value to be calculated.
This patch has been tested on a Purism L1UM-1X8C and Purism 15v4.
Signed-off-by: Eugene Myers <cedarhouse@comcast.net>
Change-Id: I7619038edc78f306bd7eb95844bd1598766f8b37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61689
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
|
|
Commit ea3376c (SMM module loader version 2) changedhow the
SMBASE is calculated.
This patch modifies setup_smm_descriptor to properly acquire the
SMBASE.
This patch has been tested on a Purism L1UM-1X8C and a Purism 15v4.
Signed-off-by: Eugene Myers <cedarhouse@comcast.net>
Change-Id: I1d62a36cdcbc20a19c42266164e612fb96f91953
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61688
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ie34003a9fdfe9f3b1b8ec0789aeca8b9435c9c79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58081
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Because the STM build doesn't use the coreboot toolchain it's not
reproducible. Make sure that's displayed during the build.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I3f0101400dc221eca09c928705f30d30492f171f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
In both the Kconfig and Makefile in this directory,
"STM_TTYS0_BASE" is used. Therefore, fix the typo.
Change-Id: Ie83ec31c7bb0f6805c0225ee7405e137a666a5d3
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51206
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Use the existing `MMCONF_BUS_NUMBER` and `MMCONF_LENGTH` symbols.
Change-Id: I88dcc0d5845198f668c6604c45fd869617168231
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Change-Id: I45adc4622f2d3358c703259931bafc4511395a5a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
This patch adds options that support building the STM as a
part of the coreboot build. The option defaults assume that
these configuration options are set as follows:
IED_REGION_SIZE = 0x400000
SMM_RESERVED_SIZE = 0x200000
SMM_TSEG_SIZE = 0x800000
Change-Id: I80ed7cbcb93468c5ff93d089d77742ce7b671a37
Signed-off-by: Eugene Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
|
|
This sort-of reverts commit 075df92298fe3bb0ef04233395effe668c4a5550 and
fixes the underlying issue. The printf format string type/length
specifier for a size_t type is z.
Change-Id: I897380060f7ea09700f77beb81d52c18a45326ad
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Size_t seems to have a compiler dependency. When building on the
Purism librem 15v4, size_t is 'unsigned long'. In this instance,
the compiler is the coreboot configured cross-compiler. In another
instance, size_t is defined as 'unsigned short'. To get around
the formatting conflict caused by this, The variable of type
size_t was cast as 'unsigned int' in the format.
Change-Id: Id51730c883d8fb9e87183121deb49f5fdda0114e
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
|
|
Change-Id: Icb6057ac73fcc038981ef95a648420ac00b3c106
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Jenkins does not build `config.stm` because the file name lacks the
mainboard name. So, the code was not being build-tested, and it does not
build because several files lacked the definition for `bool`.
Add the missing #include directives. Renaming the config file so that
Jenkins build-tests it is done in a follow-up.
Change-Id: Idf012b7ace0648027ef6e901d821ca6682cee198
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43622
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Found using:
diff <(git grep -l '#include <cpu/x86/msr.h>' -- src/) <(git grep -l 'IA32_EFER\|EFER_\|TSC_MSR\|IA32_\|FEATURE_CONTROL_LOCK_BIT\|FEATURE_ENABLE_VMX\|SMRR_ENABLE\|CPUID_\|SGX_GLOBAL_ENABLE\|PLATFORM_INFO_SET_TDP\|SMBASE_RO_MSR\|MCG_CTL_P\|MCA_BANKS_MASK\|FAST_STRINGS_ENABLE_BIT\|SPEED_STEP_ENABLE_BIT\|ENERGY_POLICY_\|SMRR_PHYSMASK_\|MCA_STATUS_\|VMX_BASIC_HI_DUAL_MONITOR\|MC0_ADDR\|MC0_MISC\|MC0_CTL_MASK\|msr_struct\|msrinit_struct\|soc_msr_read\|soc_msr_write\|rdmsr\|wrmsr\|mca_valid\|mca_over\|mca_uc\|mca_en\|mca_miscv\|mca_addrv\|mca_pcc\|mca_idv\|mca_cecc\|mca_uecc\|mca_defd\|mca_poison\|mca_sublink\|mca_err_code\|mca_err_extcode\|MCA_ERRCODE_\|MCA_BANK_\|MCA_ERRTYPE_\|mca_err_type\|msr_set_bit\|msr_t\|msrinit_t' -- src/) |grep '<'
Change-Id: I45a41e77e5269969280e9f95cfc0effe7f117a40
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41969
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Iad5540e791075270453a136a058823c28647f93a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
|
|
Unused includes found using following commande:
diff <(git grep -l '#include <stddef.h>' -- src/) <(git grep -l
'size_t\|ssize_t\|wchar_t\|wint_t\|NULL\|DEVTREE_EARLY\|DEVTREE_CONST\
|MAYBE_STATIC_NONZERO\|MAYBE_STATIC_BSS\|zeroptr' -- src/)|grep '<'
|grep -v vendor |grep -vF '.h'
Change-Id: Ic54b1db995fe7c61b416fa5e1c4022238e4a6ad5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41150
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ia3de79c7d71049da00ed108829eac6cb49ff3ed6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41205
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Suggested by Nico Huber in CB:38766
Change-Id: Ib8a340f17a12951bc6bc67e3093046575e7b0e46
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40438
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Suggested by Nico Huber in CB:38765.
This placement makes the address calculation simpler and
makes its location indepedent of the number of CPUs.
As part of the change in the BIOS resource list address
calculation, the `size` variable was factored out of the
conditional in line 361, thus eliminating the else.
Change-Id: I9ee2747474df02b0306530048bdec75e95413b5d
Signed-off-by: Eugene D Myers <cedarhouse@comcast.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40437
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The `USE_BLOBS` config only exists for idealistic reasons. If we would
allow us to use blobs by default, we wouldn't need that option and could
just always do it. It's generally debatable for the project as a whole,
but not per board/subject.
Change-Id: I8591862699aef02e5a4ede32655fc82c44c97555
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The STM is a part of the core VTx and using ENABLE_VMX will make the
STM option available for any configuration that has an Intel
processor that supports VTx.
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Change-Id: I57ff82754e6c692c8722d41f812e35940346888a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38852
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Check to ensure that dual monitor mode is supported on the
current processor. Dual monitor mode is normally supported on
any Intel x86 processor that has VTx support. The STM is
a hypervisor that executes in SMM dual monitor mode. This
check should fail only in the rare case were dual monitor mode
is disabled. If the check fails, then the STM will not
be initialized by coreboot.
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Change-Id: I518bb2aa1bdec94b5b6d5e991d7575257f3dc6e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Selecting STM on an arbitrary platform would likely result in a brick,
so let's hide the prompt by default.
Change-Id: I50f2106ac05c3efb7f92fccb1e6edfbf961b68b8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: <cedarhouse1@comcast.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This update is a combination of all four of the patches so that the
commit can be done without breaking parts of coreboot. This possible
breakage is because of the cross-dependencies between the original
separate patches would cause failure because of data structure changes.
security/intel/stm
This directory contains the functions that check and move the STM to the
MSEG, create its page tables, and create the BIOS resource list.
The STM page tables is a six page region located in the MSEG and are
pointed to by the CR3 Offset field in the MSEG header. The initial
page tables will identity map all memory between 0-4G. The STM starts
in IA32e mode, which requires page tables to exist at startup.
The BIOS resource list defines the resources that the SMI Handler is
allowed to access. This includes the SMM memory area where the SMI
handler resides and other resources such as I/O devices. The STM uses
the BIOS resource list to restrict the SMI handler's accesses.
The BIOS resource list is currently located in the same area as the
SMI handler. This location is shown in the comment section before
smm_load_module in smm_module_loader.c
Note: The files within security/intel/stm come directly from their
Tianocore counterparts. Unnecessary code has been removed and the
remaining code has been converted to meet coreboot coding requirements.
For more information see:
SMI Transfer Monitor (STM) User Guide, Intel Corp.,
August 2015, Rev 1.0, can be found at firmware.intel.com
include/cpu/x86:
Addtions to include/cpu/x86 for STM support.
cpu/x86:
STM Set up - The STM needs to be loaded into the MSEG during BIOS
initialization and the SMM Monitor Control MSR be set to indicate
that an STM is in the system.
cpu/x86/smm:
SMI module loader modifications needed to set up the
SMM descriptors used by the STM during its initialization
Change-Id: If4adcd92c341162630ce1ec357ffcf8a135785ec
Signed-off-by: Eugene D. Myers <edmyers@tycho.nsa.gov>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: ron minnich <rminnich@gmail.com>
|