Add more definitions to be used for Machine Check Architecture
support, mainly for determining the type of error that is being
interpreted. MCA is described in detail in the BKDG.
BUG=b:65446699
TEST=inspect BERT region, and dmesg, on full patch stack. Use test
data plus a failing Grunt system.
Change-Id: I0682288aa58c69aee323fb43f74027f7a1905b68
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/28473
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Use the value discovered in the MCG_CAP[Count] for the number of MCA
status registers to clear. The generations should have the following
number of banks:
* Family 10h: 6 banks
* Family 12h: 6
* Family 14h: 6
* Family 15h: 7
* Family 16h: 6
Change-Id: I0fc6d127a200b10fd484e051d84353cc61b27a41
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/27923
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
According to the "Intel® 64 and IA-32 Architectures Software Developer’s Manual"
the SMRR MSR are at a different offset for model_6fx and model_1067x.
This still need SMRR enabled and lock bit set in MSR_FEATURE_CONTROL.
Change-Id: I8ee8292ab038e58deb8c24745ec1a9b5da8c31a9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27585
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Add 4 helper functions to get microcode info.
* get_current_microcode_rev
return the the version of the currently running microcode.
* get_microcode_rev
extract microcode revision from the given patch.
* get_microcode_size
extract microcode size from the given patch.
* get_microcode_checksum
extract checksum from the given patch.
The simpler thing would be to just move the struct microcode
to microcode.h so that the structure members can be dereferenced.
To encapsulate the structure details added the helper functions.
This information will be used in future to compare microcodes for update.
Change-Id: I67a08ba40b393874d8cc17363fefe21e2ea904f3
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/27365
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If CPU 0's stack grows to large, it will overflow into CPU 1's stack.
If CPU 0 is handling the interrupt then CPU 1 should be in an idle loop.
When the stack overflow occurs it will override the return pointer for
CPU 1, so when CPU 0 unlocks the SMI lock, CPU 1 will attempt to return
to a random address.
This method is not foolproof. If code allocates some stack variables
that overlap with the canary, and if the variables are never set, then
the canary will not be overwritten, but it will have been skipped. We
could mitigate this by adding a larger canary value if we wanted.
I chose to use the stack bottom pointer value as the canary value
because:
* It will change per CPU stack.
* Doesn't require hard coding a value that must be shared between the
.S and .c.
* Passing the expected canary value as a parameter felt like overkill.
We can explore adding other methods of signaling that a stack overflow
had occurred in a follow up. I limited die() to debug only because
otherwise it would be very hard to track down.
TEST=built on grunt with a small and large stack size. Then verified
that one causes a stack overflow and the other does not.
Stack overflow message:
canary 0x0 != 0xcdeafc00
SMM Handler caused a stack overflow
Change-Id: I0184de7e3bfb84e0f74e1fa6a307633541f55612
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27229
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The file cache_as_ram_ht.inc is used across a variety
of CPUs and northbridges. We need to split it anyway
for future C_ENVIRONMENT_BOOTBLOCK and verstage work.
Split and rename the files, remove code that is globally
implemented in POSTCAR_STAGE framework already.
Change-Id: I2ba67772328fce3d5d1ae34c36aea8dcdcc56b87
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Most, if not all, chipsets have MMIO between 0xfe000000 and 0xff000000.
So don't try to cache more than 16MiB of the ROM. It's also common that
at most 16MiB are memory mapped.
Change-Id: I5dfa2744190a34c56c86e108a8c50dca9d428268
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26567
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As far as I can see this Kconfig option was used wrong ever since it
was added. According to the commit message of 107f72e (Re-declare
CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR), it was only necessary
to prevent overlapping with CAR.
Let's handle the potential overlap in C macros instead and get rid
of that option. Currently, it was only used by most FSP1.0 boards,
and only because the `fsp1_0/Kconfig` set it to CBFS_SIZE (WTF?).
Change-Id: I4d0096f14a9d343c2e646e48175fe2127198a822
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch ensures that user can select a specific AP to run
a function.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: Iff2f34900ce2a96ef6ff0779b651f25ebfc739ad
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/26034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that user can pass a function with given argument
list to execute over APs.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: I668b36752f6b21cb99cd1416c385d53e96117213
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
There might be certain requirement in user function where user
might not want to pass any timeout value, in those cases
run_ap_work() should consider infinity as timeout and perform
all APs initialization as per specification.
Set expire_us <= 0 to specify an infinite timeout.
BRANCH=none
BUG=b:74436746
TEST=run_ap_work() is running successfully with 0 expire_us.
Change-Id: Iacd67768c8a120f6a01baaa6817468f6b9a3b764
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When employing PAGING_IN_CACHE_AS_RAM more areas need to be
mapped in at runtime. Therefore, paging_identity_map_addr() is
added to support adding identity mappings. Because there are a
fixed amount of pages in cache-as-ram paging only the existing
paging structures can be used. As such that's a limitation on
what regions and length one can map. Using util/x86/x86_page_tables.go
to generate page tables will always populate all the page directory
pages. Therefore, 2MiB mappings are easy to map in.
BUG=b:72728953
Change-Id: Ibe33aa12972ff678d2e9b80874529380b4ce9fd7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25718
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Processors, such as glk, need to have paging enabled while
in cache-as-ram mode because the front end is agressive about
fetching lines into the L1I cache. If the line is dirty and in
the L1D then it writes it back to "memory". However, in this case
there is no backing store so the cache-as-ram data that was written
back transforms to all 0xff's when read back in causing corruption.
In order to mitigate the failure add x86 architecture support for
enabling paging while in cache-as-ram mode. A Kconfig variable,
NUM_CAR_PAGE_TABLE_PAGES, determines the number of pages to carve
out for page tables within the cache-as-ram region. Additionally,
the page directory pointer table is also carved out of cache-as-ram.
Both areas are allocated from the persist-across-stages region
of cache-as-ram so all stages utilizing cache-as-ram don't corrupt
the page tables.
The two paging-related areas are loaded by calling
paging_enable_for_car() with the names of cbfs files to load the
initial paging structures from.
BUG=b:72728953
Change-Id: I7ea6e3e7be94a0ef9fd3205ce848e539bfbdcb6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Add paging_set_default_pat() which sets up the PAT MSR according
to util/x86/x86_page_tables.go. Using page attribute types require
a matching of the PAT values with the page table entries. This function
is just providing the default PAT MSR value to match against the
utility.
BUG=b:72728953
Change-Id: I7ed34a3565647ffc359ff102d3f6a59fbc93cc22
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Add the following functions for use outside of the paging module:
void paging_enable_pae_cr3(uintptr_t cr3);
void paging_enable_pae(void);
void paging_disable_pae(void);
The functions just enable and/or disable paging along with PAE.
Disassembly shows equivalent output for both versions.
BUG=b:72728953
Change-Id: I9665e7ec4795a5f52889791f73cf98a8f4def827
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
The EFER and PAT MSRs are x86 architecturally defined. Therefore,
move the macro defintions to msr.h. Add 'paging' prefix to the
PAT and NXE pae/paging functions to namespace things a little better.
BUG=b:72728953
Change-Id: I1ab2c4ff827e19d5ba4e3b6eaedb3fee6aaef14d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
AMD's fixed MTRRs have RdDram and WrDram bits that route memory
accesses to DRAM vs. MMIO. These are typically hidden for normal
operation by clearing SYS_CFG[19] (MtrrFixDramModEn). According to
BKDGs and AMD64 Programmer's Manual vol 2, this bit is clear at
reset, should be set for configuration during POST, then cleared for
normal operation.
Attempting to modify the RdDram and WrDram settings without unhiding
them causes a General Protection Fault. Add functions to enable and
disable MtrrFixDramModEn. Unhide/hide as necessary when copying or
writing the fixed MTRRs.
Finally, modify sipi_vector.S to enable the bits prior to writing
the fixed MTRRs and disable when complete.
This functionality is compiled out on non-AMD platforms.
BUG=b:68019051
TEST=Boot Kahlee, check steps with HDT
Change-Id: Ie195131ff752400eb886dfccc39b314b4fa6b3f3
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The x86 bsf and bsr instructions only allow for a memory
or register operand. The 'g' constraint includes immediate
operands which the compiler could choose to emit for the instruction.
However, the assembler will rightfully complain because the
instruction with an immediate operand is illegal. Fix the constraints
to bsf and bsr to only include memory or registers.
Change-Id: Idea7ae7df451eb69dd30208ebad7146ca01f6cba
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22291
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This file mostly mimics Porting.h and should be removed.
For now, move it and use it consistently with incorrect form
as #include "cbtypes.h".
Change-Id: Ifaee2694f9f33a4da6e780b03d41bdfab9e2813e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The original purpose of adjust_cpu_apic_entry() was to set
up an APIC map. That map was effectively only used for mapping
*default* APIC id to CPU number in the SMM handler. The normal
AP startup path didn't need this mapping because it was whoever
won the race got the next cpu number. Instead of statically
calculating (and wrong) just initialize the default APIC id
map when the APs come online. Once the APs are online the SMM
handler is loaded and the mapping is utilized.
Change-Id: Idff3b8cfc17aef0729d3193b4499116a013b7930
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
This patch adds the common acpi code.ACPI code is very similar
accross different intel chipsets.This patch is an effort to
move those code in common place so that it can be shared accross
different intel platforms instead of duplicating for each platform.
We are removing the common acpi files in src/soc/intel/common.
This removes the acpi.c file which was previously in
src/soc/common/acpi. The config for common acpi is
SOC_INTEL_COMMON_BLOCK_ACPI which can be defined in SOC's
Kconfig file in order to use the common ACPI code. This patch also
includes the changes in APL platform to use the common ACPI block.
TEST= Tested the patch as below:
1.Builds and system boots up with the patch.
2.Check all the ACPI tables are present in
/sys/firmware/acpi/tables
3.Check SCI's are properly working as we are
modifying the function to override madt.
4.Extract acpi tables like DSDT,APIC, FACP, FACS
and decompile the by iasl and compare with good
known tables.
5.Execute the extracted tables in aciexec to check
acpi methods are working properly.
Change-Id: Ib6eb6fd5366e6e28fd81bc22d050b0efa05a2e5d
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/20630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
