| Age | Commit message (Collapse) | Author |
|---|
|
This change adds some MSRs that are needed in a subsequent change to add
support for Continuous Performance Control.
Change-Id: Id4ecff1bc5eedaa90b41de526b9a2e61992ac296
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/28067
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@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>
|
|
This is how these MSR's are referenced in Intel® 64 and IA-32 Architectures
Software Developer’s Manual.
The purpose is to differentiate with MSR_SMRR_PHYSx.
Change-Id: I54875f3a6d98a28004d5bd3197923862af8f7377
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/27584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
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>
|
|
Change-Id: Ifb8aa43b6545482bc7fc136a90c4bbaa18d46089
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/22957
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move #includes to the top and remove unnecessary guards. Hopefully this
prevents future surprises.
Change-Id: Id4571c46a0c05a080b2b1cfec64b4eda07d793bb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
|
|
barrier_wait_timeout() was not used anywhere in the code. The
remaining two functions, barrier_wait() and release_barrier(), are
not used anywhere but the mp code.
Change-Id: If09991f95306becc68b6008ae6448695fb4a2dca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26021
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
|
Even though most x86 systems don't run with paging on, it's
helpful to always print it out for the ones that do without
making a more complicated handler. New dump will look like
the following:
Unexpected Exception: 6 @ 10:7ab84be2 - Halting
Code: 0 eflags: 00010006 cr2: 00000000
eax: 7abb80ec ebx: deadbeef ecx: 00000000 edx: 00000002
edi: 7abb3000 esi: 00000004 ebp: 7abb2fd8 esp: 7abb2fb0
7ab84ba0: 00 01 00 83 ec 0c 6a 39
7ab84ba8: e8 8a 02 01 00 e8 e1 08
7ab84bb0: 00 00 e8 4e 3d 00 00 59
7ab84bb8: 5b 52 50 e8 f5 3c 00 00
7ab84bc0: c7 04 24 0a 00 00 00 e8
7ab84bc8: 3c 3d 00 00 c7 04 24 80
7ab84bd0: 00 00 00 e8 5f 02 01 00
7ab84bd8: e8 1e 38 01 00 e8 7e 50
7ab84be0: 01 00 0f 0b bb 98 ec ba
7ab84be8: 7a 83 c4 10 8b 03 85 c0
7ab84bf0: 0f 84 be 00 00 00 83 78
7ab84bf8: 04 00 8d 50 08 75 0c 56
7ab84c00: 56 ff 30 52 e8 f8 fe ff
7ab84c08: ff eb 0a 51 51 ff 30 52
7ab84c10: e8 2e ff ff ff 83 c4 10
7ab84c18: 83 c3 04 eb cf 89 d8 e8
BUG=b:72728953
Change-Id: I0e87bbe776f77623ad8297f5d80167998daec6ed
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25762
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
|
|
Register CR3 holds the physical address of paging-structure hierarchy.
Add functions to enable read/write of this register.
Change-Id: Icfd8f8e32833d2c80cefc8f930d6eedbfeb5e3ee
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/25478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@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>
|
|
Change-Id: I74c5cc22f02302314ba010bc599051c1495a13cb
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/22848
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>
|
|
In amd64_smm_state_save_area_t break out fields in reserved4 to allow access.
BUG=b:65485690
Change-Id: I592fbf18c166dc1890010dde29f76900a6849016
Signed-off-by: John E. Kabat Jr <john.kabat@scarletltd.com>
Reviewed-on: https://review.coreboot.org/22092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Create an SMM_AMD64_SAVE_STATE_OFFSET #define similar to others in the
same file.
Change-Id: I0a051066b142cccae3d2c7df33be11994bafaae0
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
Change-Id: I2d6fdfd0465fe5f558daa04c6f980f7226596b55
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21087
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I2d7d4e0b25f2cf3eef2040f89d5ebc711909cdd7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20734
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: I2fbe6376a1cf98d328464556917638a5679641d2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Also unify __attribute__ ((..)) to __attribute__((..)) and
handle ((__packed__)) like ((packed))
Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/15921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
For sizes and dimensions use size_t. For pointer casts
use uintptr_t. Also, use the ALIGN_UP macro instead of
open coding the operation.
Change-Id: Id28968e60e51f46662c37249277454998afd5c0d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20241
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Use define for SSA base address.
Move EM64T area to 0x7c00 and add reserved area of size 0x100,
as there's no indication that the address 0x7d00 exists on any
platform.
No functional change.
Change-Id: I38c405c8977f5dd571e0da3a44fcad4738b696b2
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/20146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Like the previous commit allow the declarations of functions to
be exposed to all stages unless ROMCC is employed.
Change-Id: Ie4dfc32f38890938b90ef8e4bc35652d1c44deb5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20114
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
set_var_mtrr() and get_free_var_mtrr() don't need to be guarded
against various stages. It just complicates code which lives
in a compilation unit that is compiled for multiple stages by
needing to reflect the same guarding. Instead, just drop the
declaration guard. earlymtrr.c is still just compiled for earlier
stages, but if needed it's easy to move to a mtrr_util.c that
is compiled for all stages.
Change-Id: Id6be6f613771380d5ce803eacf1a0c8b230790b6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20018
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
|
|
In case something goes wrong on one of the
cpus, add the ability to use a barrier with
timeout so that other cpus don't wait forever.
Remove static from barrier wait and release.
BUG=chrome-os-partner:59875
BRANCH=reef
TEST=None
Change-Id: Iab6bd30ddf7632c7a5785b338798960c26016b24
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-on: https://review.coreboot.org/18107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
Changed a few comments to reduce line length. File
src/include/cpu/amd/vr.h was skipped.
TEST=Build and run on Galileo Gen2
Change-Id: Ie3c07111acc1f89923fb31135684a6d28a505b61
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18687
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: need consistent spacing around '-' (ctx:WxV)
TEST=Build and run on Galileo Gen2
Change-Id: Ib4c2c0c19dee842b7cd4da11a47215dc2f124374
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18686
Tested-by: build bot (Jenkins)
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: spaces required around that ':' (ctx:ExV)
TEST=Build and run on Galileo Gen2
Change-Id: Idb2ea29a6c7277b319e6600e8a9d7cb8285ae5df
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18684
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: switch and case should be at the same indent
TEST=Build and run on Galileo Gen2
Change-Id: I92f00254c7fcb79a5ecd4ba5e19a757cfe5c11fa
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18683
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: storage class should be at the beginning of the declaration
The following storage class attribute is not detected by checkpatch.py:
static cbmem_init_hook_t init_fn_ ## _ptr_ __attribute__((used,
\
section(".rodata.cbmem_init_hooks"))) = init_fn_;
The following lines generates a false positive:
(pound)define STATIC static
src/include/cpu/amd/common/cbtypes.h:60: WARNING: storage class should
be at the beginning of the declaration
typedef asmlinkage void (*smm_handler_t)(void *);
src/include/cpu/x86/smm.h:514: WARNING: storage class should be at the
beginning of the declaration
(pound)define MAYBE_STATIC static
src/include/stddef.h:34: WARNING: storage class should be at the
beginning of the declaration
TEST=Build and run on Galileo Gen2
Change-Id: Ie087d38e6171b549b90e0b831050ac44746a1e14
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18657
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: space prohibited between function name and open parenthesis '('
TEST=Build and run on Galileo Gen2
Change-Id: I0ac30b32bab895ca72f91720eeae5a5067327247
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18656
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following errors detected by checkpatch.pl:
ERROR: "foo * bar" should be "foo *bar"
ERROR: "foo* bar" should be "foo *bar"
ERROR: "foo*bar" should be "foo *bar"
TEST=Build and run on Galileo Gen2
Change-Id: I5a3ff8b92e3ceecb4ddf45d8840454d5310fc6b3
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18655
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
Fix the following errors and warning detected by checkpatch.pl:
ERROR: open brace '{' following enum go on the same line
ERROR: open brace '{' following struct go on the same line
ERROR: that open brace { should be on the previous line
WARNING: missing space after struct definition
TEST=Build and run on Galileo Gen2
Change-Id: I856235d0cc3a3e59376df52561b17b872b3416b2
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18653
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: please, no space before tabs
TEST=Build and run on Galileo Gen2
Change-Id: If60a58021d595289722d1d6064bea37b0b0bc039
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18652
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error messages found by checkpatch.pl:
ERROR: space prohibited after that open parenthesis '('
ERROR: space prohibited before that close parenthesis ')'
TEST=Build and run on Galileo Gen2
Change-Id: I2a9a0df640c51ff3efa83dde852dd6ff37ac3c06
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18651
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: space required after that ',' (ctx:VxV)
TEST=Build and run on Galileo Gen2
Change-Id: I297bfc3d03dc95b471d3bb4b13803e81963841b5
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18647
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error and warning detected by checkpatch.pl:
ERROR: code indent should use tabs where possible
WARNING: please, no spaces at the start of a line
TEST=Build and run on Galileo Gen2
Change-Id: I487771b8f4d7e104457116b772cd32df5cd721a6
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18646
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix warning detected by checkpatch.pl:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
BRANCH=none
BUG=None
TEST=Build and run on Galileo Gen2
Change-Id: I23d9b4b715aa74acc387db8fb8d3c73bd5cabfaa
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18607
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The value for _size was not evaluated correctly if ramstage
is relocated, make the calculation runtime.
While touching it, move symbol declarations to header file.
Change-Id: I4402315945771acf1c86a81cac6d43f1fe99a2a2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17784
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
There are circumstances where the APs need to run a piece of
code later in the boot flow. The current MP init just parks
the APs after MP init is completed so there's not an opportunity
to target running a piece of code on all the APs at a later time.
Therefore, provide an option, PARALLEL_MP_AP_WORK, that allows
the APs to perform callbacks.
BUG=chrome-os-partner:60657
BRANCH=reef
Change-Id: I849ecfdd6641dd9424943e246317cd1996ef1ba6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17745
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
|
|
Change-Id: I3d1a456f17073c99c9502da26e09cfde65380746
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17586
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ieb5f1668a715ceadd5fe5ba0d121c865f1886038
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17572
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Certain platforms have a poorly performing SPI prefetcher so even if
accessing MMIO BIOS once the fetch time can be impacted. Payload
loading is one example where it can be impacted. Therefore, add the
ability for a platform to reconfigure the currently running CPU's
variable MTRR settings for the duration of coreboot's execution.
The function mtrr_use_temp_range() is added which uses the previous
MTRR solution as a basis along with a new range and type to use.
A new solution is calculated with the updated settings and the
original solution is put back prior to exiting coreboot into the OS
or payload.
Using this patch on apollolake reduced depthcharge payload loading
by 75 ms.
BUG=chrome-os-partner:56656,chrome-os-partner:59682
Change-Id: If87ee6f88e0ab0a463eafa35f89a5f7a7ad0fb85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17371
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: I0ee4c443b6861018f05cfc32135d632fd4996029
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16614
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Move the funtion to find most significant bit set(fms)
and function to find least significant bit set(fls) to a common
place. And remove the duplicates.
Change-Id: Ia821038b622d93e7f719c18e5ee3e8112de66a53
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16525
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: Ic8ffd26e61c0c3f27872699bb6aa9c39204155b7
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16390
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I9b3a2cce6c6bb85791d5cde076d5de95ef0e8790
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/16278
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
|
|
Change-Id: Id40c1bf868820c77ea20146d19c6d552c2f970c4
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15942
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
With all users converted to using the mp_ops callbacks there's
no need to expose that surface area. Therefore, keep it all
within the mp_init compilation unit.
Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14598
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
In order to reduce code duplication provide a common flow
through callback functions that performs the multiprocessor
and optionally SMM initialization. The existing MP flight
records are utilized but a common flow is provided such
that the chipset/cpu only needs to provide a mp_ops
structure which has callbacks to gather info and provide
hooks at certain points in the sequence.
All current users of the MP code can be switched over to
this flow since there haven't been any flight records that
are overly complicated and long. After the conversion
has taken place most of the surface area of the MP
API can be hidden away within the compilation unit proper.
Change-Id: I6f70969631012982126f0d0d76e5fac6880c24f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14557
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The SMM module loader code was guarded by CONFIG_SMM_TSEG,
however that's not necessary. It's up to the chipset to take
advantage of the SMM module loading. It'll get optimized out
if the code isn't used anyway so just expose the declarations.
Change-Id: I6ba1b91d0c84febd4f1a92737b3d7303ab61b343
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14560
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The BSP and AP callback declarations both had an optional argument
that could be passed. In practice that functionality was never used
so drop it.
Change-Id: I47fa814a593b6c2ee164c88d255178d3fb71e8ce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14556
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Instead of hard-coding var mtrr numbers in code, use this function to
identify the first available variable mtrr. If no such mtrr is
available, the function will return -1.
Change-Id: I2a1e02cdb45c0ab7e30609641977471eaa2431fd
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14115
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
The current MTRR API doesn't allow one to detect variable MTRRs
along with handling fixed MTRRs in one function call. Therefore,
add x86_setup_mtrrs_with_detect() to perform the same actions
as x86_setup_mtrrs() but always do the dynamic detection.
Change-Id: I443909691afa28ce11882e2beab12e836e5bcb3d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13935
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
This just updates existing guard name comments on the header files
to match the actual #define name.
As a side effect, if there was no newline at the end of these files,
one was added.
Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12900
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We use UNDERSCORE_CASE. For the MTRR macros that refer to an MSR,
we also remove the _MSR suffix, as they are, by definition, MSRs.
Change-Id: Id4483a75d62cf1b478a9105ee98a8f55140ce0ef
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11761
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For hex and int type kconfig symbols, IS_ENABLED() doesn't work. Instead
check to make sure they're defined and not zero. In some cases, zero
might be a valid value, but it didn't look like zero was valid in these
cases.
Change-Id: Ib51fb31b3babffbf25ed3ae4ed11a2dc9a4be709
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10886
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BRANCH=none
BUG=None
TEST=Build and run on strago
Change-Id: Ia3740353eb16f2a2192cad8c45645f845bf39475
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10588
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I782007fe9754ec3ae0b5dc31e7865f7e46cfbc74
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10576
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I8e694f37c8709efd702208aa005096ebf1f3abb5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10356
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
SMM_TSEG now implies SMM_MODULES and SMM_MODULES can't be used without SMM_TSEG
Remove some newly dead code while on it.
Change-Id: I2e1818245170b1e0abbd853bedf856cec83b92f2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10355
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Change-Id: I534f992ed479c7cdc049bd598259b1f1cf2953b9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10354
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Most Baytrail based devices MMIO registers are reported in ACPI
space and the device's PCI config space is disabled. The PCI config
space is required for many "legacy" OSs that don't have the ACPI
driver loading mechanism. Depthcharge signals the legacy boot
path via the SMI 0xCC and the coreboot SMI handler can switch the
device specific registers to re-enable PCI config space.
BUG=chrome-os-partner:30836
BRANCH=None
TEST=Build and boot Rambi SeaBIOS.
Change-Id: I87248936e2a7e026f38c147bdf0df378e605e370
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: dbb9205ee22ffce44e965be51ae0bc62d4ca5dd4
Original-Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219801
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Original-Tested-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/9459
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I682617cd2f4310d3e2e2ab6ffec51def28a4779c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7961
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Because we had no stack on romcc boards, we had a separate, not as
powerful clone of printk: print_*. Back in the day, like more than
half a decade ago, we migrated a lot of boards to printk, but we never
cleaned up the existing code to be consistent. instead, we worked around
the problem with a very messy console.h (nowadays the mess is hidden in
romstage_console.c and early_print.h)
This patch cleans up the cpu code to use printk() on all non-ROMCC
boards.
Change-Id: I233c53300f9a74bce4b828fc4074501a77f7b593
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8114
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
|
|
Cherry-pick from chromium and adjusted for added boards
and changed directory layout for arch/arm.
Timestamp implementation for ARMv7
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Original-Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Original-Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Original-Reviewed-on: https://gerrit.chromium.org/gerrit/63793
(cherry-picked from commit cc1a75e059020a39146e25b9198b0d58aa03924c)
Change-Id: Ic51fb78ddd05ba81906d9c3b35043fa14fbbed75
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8020
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
We relocate GDT to CBMEM, this can be done late in ramstage.
Note: We currently do this for BSP CPU only.
Change-Id: I626faaf22f846433f25ca2253d6a2a5230f50b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7858
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Change-Id: I8486e70615f4c404a342cb86963b5357a934c41d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7606
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Placement of romstage stack in RAM was vulnerable for getting corrupted
by decompressed ramstage.
Change-Id: Ic032bd3e69f4ab8dab8e5932df39fab70aa3e769
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7096
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Add the CPU files required to support the Steppe Eagle and Mullins
models of Family 16h SoC processors from AMD. This CPU is based on
the Jaguar core and is similar to Kabini.
Change-Id: Ib48a3f03128f99a1242fe8c157e0e98feb53b1ea
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6679
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
|
|
Continuing on from the rational given in:
a173a62 Remove guarding #includes by CONFIG_FOO combinations
Change-Id: I35c636ee7c0b106323b3e4b90629f7262750f8bd
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6114
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
It was never well-defined what value this function should return.
Change-Id: If84aff86e0b556591d7ad557842910a2dfcd3b46
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6166
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Start using the rmodtool for generating rmodules.
rmodule_link() has been changed to create 2 rules:
one for the passed in <name>, the other for creating
<name>.rmod which is an ELF file in the format of
an rmodule.
Since the header is not compiled and linked together
with an rmodule there needs to be a way of marking
which symbol is the entry point. __rmodule_entry is
the symbol used for knowing the entry point. There
was a little churn in SMM modules to ensure an
rmodule entry point symbol takes a single argument.
Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5379
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: If92b50ab3888518228d2d3b76f5c50c4aef968dd
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/4561
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
With the recent improvement 3d6ffe76f8a505c2dff5d5c6146da3d63dad6e82,
speedup by CACHE_ROM is reduced a lot.
On the other hand this makes coreboot run out of MTRRs depending on
system configuration, hence screwing up I/O access and cache
coherency in worst cases.
CACHE_ROM requires the user to sanity check their boot output because
the feature is brittle. The working configuration is dependent on I/O
hole size, ram size, and chipset. Because of this the current
implementation can leave a system configured in an inconsistent state
leading to unexpected results such as poor performance and/or
inconsistent cache-coherency
Remove this as a buggy feature until we figure out how to do it properly
if necessary.
Change-Id: I858d78a907bf042fcc21fdf7a2bf899e9f6b591d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5146
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Certain CPUs require the default SMM region to be backed up
on resume after a suspend. The reason is that in order to
relocate the SMM region the default SMM region has to be used.
As coreboot is unaware of how that memory is used it needs to
be backed up. Therefore provide a common method for doing this.
Change-Id: I65fe1317dc0b2203cb29118564fdba995770ffea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
We should not have x86 specific includes in lib/.
Change-Id: I18fa9c8017d65c166ffd465038d71f35b30d6f3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5156
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
In order for the cpu code to start SMM relocation 2 new
functions are added to be shared:
- void smm_initiate_relocation_parallel()
- void smm_initiate_relocation()
The both initiate an SMI on the currently running cpu.
The 2 variants allow for parallel relocation or serialized
relocation.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted rambi using these functions.
Change-Id: I325777bac27e9a0efc3f54f7223c38310604c5a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173982
Reviewed-on: http://review.coreboot.org/4891
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The Bay Trail SMM save state revision is 0x0100.
Add support for this save state area using the
type named em64t100_smm_state_save_area_t.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted using this structure with forthcoming CLs.
Change-Id: Iddd9498ab9fffcd865dae062526bda2ffcdccbce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173981
Reviewed-on: http://review.coreboot.org/4890
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
Provide a common entry point for bringing up the APs
in parallel. This work is based off of the Haswell one
which can be moved over to this in the future. The APs
are brought up and have the BSP's MTRRs duplicated in
their own MTRRs. Additionally, Microcode is loaded before
enabling caching. However, the current microcode loading
support assumes Intel's mechanism.
The infrastructure provides a notion of a flight plan
for the BSP and APs. This allows for flexibility in the
order of operations for a given architecture/chip without
providing any specific policy. Therefore, the chipset
caller can provide the order that is required.
BUG=chrome-os-partner:22862
BRANCH=None
TEST=Built and booted on rambi with baytrail specific patches.
Change-Id: I0539047a1b24c13ef278695737cdba3b9344c820
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173703
Reviewed-on: http://review.coreboot.org/4888
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
|
|
The access to control registers were scattered about.
Provide a single header file to provide the correct
access function and definitions.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and booted using this infrastructure. Also objdump'd the
assembly to ensure consistency (objdump -d -r -S | grep xmm).
Change-Id: Iff7a043e4e5ba930a6a77f968f1fcc14784214e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172641
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4873
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Romstage and ramstage can use 2 different values for the
amount of ROM to cache just under 4GiB in the address
space. Don't assume a cpu's romstage caching policy
for the ROM.
Change-Id: I689fdf4d1f78e9556b0bc258e05c7b9bb99c48e1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4846
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The tsc header is using u32 w/o including the file
with defines it.
Change-Id: I9fcad882d25e93b4c0032b32abd2432b0169a068
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4843
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
GRUB2-as-payload doesn't use them. Libpayload can live with just coreboot tables
if loaded as payload. memtest86+ can use them but is buggy with them. Solaris
needs a huge boot archive not supported by coreboot and too big to fit in
flash (dozens of megabytes). All-in-all looks like no users are left for this.
Change-Id: Id92f73be5a397db80f5b0132ee57c37ee6eeb563
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4628
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
