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>
In preparation for bringing in paging early always provide the
paging pae module to all stages. Since we cull unused symbols this
is a no-op. Compilation testing will happen all the time since the module
currently doesn't compile without <arch/cpu.h> include. The current
file is completely guarded with ENV_RAMSTAGE because it's using
cpu_index() which is a ramstage-only construct.
BUG=b:72728953
Change-Id: Ib4310b8206e5247fa220b42203bcd18d522d51ea
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25712
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
The term MTRR has been misspelled in a few places.
Change-Id: I3e3c11f80de331fa45ae89779f2b8a74a0097c74
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The missing space resulted in the following broken output:
> ERROR: Not enough MTRRs available! MTRR indexis 10 with 10 MTTRs in
total.
Put the string on one line to make it obvious where the spaces should be
and to help users of grep.
Change-Id: Ib9e8109d88c1bf38e7dda3dbf1c8d47fb0d23265
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25567
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that calc_var_mtrrs_with_hole() always chooses the optimal
allocation, there is no need for calc_var_mtrrs_without_hole()
any more. Drop it and all the logic to decide which one to call.
Tests performed compared to "upstream" (before "cpu/x86/mtrr:
Optimize hole carving strategy") on a Lenovo/X200s with 48MiB
GFX stolen memory.
2GiB total RAM: 3 MTRRs saved
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x000000007ac00000 size 0x7ab40000 type 6
0x000000007ac00000 - 0x00000000d0000000 size 0x55400000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
upstream:
MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/8 > 6.
MTRR: default type WB/UC MTRR counts: 4/7.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007ac00000 mask 0x0000000fffc00000 type 0
MTRR: 1 base 0x000000007b000000 mask 0x0000000fff000000 type 0
MTRR: 2 base 0x000000007c000000 mask 0x0000000ffc000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0
patched:
MTRR: default type WB/UC MTRR counts: 7/5.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6
MTRR: 1 base 0x000000007ac00000 mask 0x0000000fffc00000 type 0
MTRR: 2 base 0x000000007b000000 mask 0x0000000fff000000 type 0
MTRR: 3 base 0x000000007c000000 mask 0x0000000ffc000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1
4GiB total RAM: no MTRRs saved but slightly more accurate alignment
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x000000007cc00000 size 0x7cb40000 type 6
0x000000007cc00000 - 0x00000000d0000000 size 0x53400000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000017c000000 size 0x7c000000 type 6
upstream:
MTRR: default type WB/UC MTRR counts: 7/6.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6
MTRR: 1 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0
MTRR: 2 base 0x000000007d000000 mask 0x0000000fff000000 type 0
MTRR: 3 base 0x000000007e000000 mask 0x0000000ffe000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1
MTRR: 5 base 0x0000000100000000 mask 0x0000000f00000000 type 6
patched:
MTRR: default type WB/UC MTRR counts: 7/6.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000000f80000000 type 6
MTRR: 1 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0
MTRR: 2 base 0x000000007d000000 mask 0x0000000fff000000 type 0
MTRR: 3 base 0x000000007e000000 mask 0x0000000ffe000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1
MTRR: 5 base 0x0000000100000000 mask 0x0000000f80000000 type 6
8GiB total RAM: possible savings but WB still beats UC
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x000000007cc00000 size 0x7cb40000 type 6
0x000000007cc00000 - 0x00000000d0000000 size 0x53400000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000027c000000 size 0x17c000000 type 6
upstream:
MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/11 > 6.
MTRR: default type WB/UC MTRR counts: 4/10.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0
MTRR: 1 base 0x000000007d000000 mask 0x0000000fff000000 type 0
MTRR: 2 base 0x000000007e000000 mask 0x0000000ffe000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0
patched:
MTRR: Removing WRCOMB type. WB/UC MTRR counts: 7/7 > 6.
MTRR: default type WB/UC MTRR counts: 4/6.
MTRR: WB selected as default type.
MTRR: 0 base 0x000000007cc00000 mask 0x0000000fffc00000 type 0
MTRR: 1 base 0x000000007d000000 mask 0x0000000fff000000 type 0
MTRR: 2 base 0x000000007e000000 mask 0x0000000ffe000000 type 0
MTRR: 3 base 0x0000000080000000 mask 0x0000000f80000000 type 0
Change-Id: Iedf7dfad61d6baac91973062e2688ad866f05afd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/21916
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For WB ranges with unaligned end, we try to align the range up and
carve a hole out of it which might reduce MTRR usage. Instead of
trying an arbitrary alignment, we try all and choose an optimal
one.
Also, restructure the cases when we try to find a hole. Which leads
us to the following three:
1. WB range is last in address space:
Aligning up, up to the next power of 2, may gain us something.
2. The next range is of type UC:
We may align up, up to the _end_ of the next range. If there
is a gap between the current and the next range, it would
have been covered by the default type UC anyway.
3. The next range is not of type UC:
We may align up, up to the _base_ of the next range. This is
the end of the gap, if there is one.
Change-Id: Iefb064ce8c4f293490a19dd46054b966c63bde44
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/21915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change f43adf0 (intel/common/block/cpu: Change post_cpus_init after
BS_DEV RESOURCES) moved post_cpus_init to BS_OS_RESUME for S3
path. This results in BSP timing out waiting for APs to be
parked. This change increases the time out value for APs to be parked
to 250ms. This value was chosen after running suspend-resume stress
test and capturing the maximum time taken for APs to be parked for
100 iterations. Typical values observed were ~150ms. Maximum value
observed was 152ms.
BUG=b:76442753
TEST=Verified for 100 iterations that suspend-resume does not run into
any AP park time out.
Change-Id: Id3e59db4fe7a5a2fb60357b05565bba89be1e00e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/25422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Since the timeout in bsp_do_flight_plan is bumped up to 1 second, this
change adds a print to indicate the amount of time it takes for all the
APs to check-in.
TEST=Verified on Nami that it prints:
"bsp_do_flight_plan done after 395 msecs."
Change-Id: I4c8380e94305ed58453ed18b341b3b923949d7a8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/25044
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, the AP check-in time-out in bsp_do_flight_plan is set to
100ms. However, as the number of APs increases, contention could
increase especially for resource like UART. This led to MP record
time-out issues on KBL platform with 7 APs and serial-console enabled
BIOS image.
This change increases the time-out value to 1 second to be on the safer
side and let APs check-in before continuing boot.
BUG=b:74085891
TEST=Verified that MP record time-out is not observed anymore on Nami.
Change-Id: I979c11a10e6888aef0f71b5632ea803a67bbb0ff
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/24965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
If GENERIC_UDELAY is selected don't try to use UDELAY_IO as there
will be a udelay() conflict at link time.
BUG=b:72378235,b:72170796
Change-Id: I9e01c9daddd0629ecc38a809889b39a505c0e203
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All boards and chips that are still using LATE_CBMEM_INIT are being
removed as previously discussed.
If these boards and chips are updated to not use LATE_CBMEM_INIT, they
can be restored to the active codebase from the 4.7 branch.
chips:
soc/intel/sch
Mainboards:
mainboard/iwave/iWRainbowG6
Change-Id: Ida0570988a23fd0d13c6fcbe54f94ab0668c9eae
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/22027
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Not all SMM save state sizes equate to having enough stack in the
permanent SMM handler. Therefore, ensure 1KiB of stack is available for
each cpu's stack. Intel's save state size is 1KiB, but AMD's save state
size is only 512. Therefore, decouple save state size from the per
cpu stack size.
BUG=b:70027919
Change-Id: I54b9e6f3cc0ad6ca3d7b60b2b422b5dc5a78a552
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
coreboot has a lapicid() function, so use it.
Change-Id: I7f536c229f271674c34d722b5db96ce665b720f1
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/22192
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code used to split up ranges >64MiB into 64MiB-aligned and
unaligned parts. However in its current state the next step,
calc_var_mtrr_range(), results in the same allocation, no mat-
ter if we split the range up before. So just drop the split-up.
Change-Id: I5481fbf3168cdf789879064077b63bbfcaf122c9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/21914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Ensure the stack is properly aligned in the SIPI handler. This
avoids an exception when an aligned instruction is performed on
stack data.
BUG=b:66003093
TEST=boot kahlee built with gcc 6.3
Change-Id: Ibdd8242494c6a2bc0c6ead7ac98be55149219d7c
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/21768
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>
It's arch specific, so no need to pollute non-x86 with it.
Change-Id: I99ec76d591789db186e8a33774565e5a04fc4e47
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/21392
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The addr32 prefix is required by binutils, because even when
given an explicit address which is greater than 64KiB, it will
throw a warning about truncation, and stupidly emit the opcode
with a 16-bit addressing mode and the wrong address.
However, in the case of LLVM, this doesn't happen, and is happy
to just use 32-bit addressing whenever it may require it. This
means that LLVM never really needs an explicit addr32 prefix to
use 32-bit addressing in 16-bit mode.
Change-Id: Ia160d3f7da6653ea24c8229dc26f265e5f15aabb
Also-by: Damien Zammit <damien@zamaudio.com>
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/21219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
LLVM AS doesn't support as much GNU junk extensions, data16/32
is almost never needed in truth if we just use the correct op
suffix. So do that here, fixes clang/llvm builds with the
integrated-as toggled on.
Change-Id: I6095d03d0289b418a49a10f135de5eb0e117cae0
Also-by: Damien Zammit <damien@zamaudio.com>
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/21218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fail at build-time if one of the following happens:
Platform includes SMI handler setup function smm_init()
in the build when configuration has HAVE_SMI_HANDLER=n.
Platform does not implement smm_init_completion() when
HAVE_SMI_HANDLER=y.
Change-Id: I7d61c155d2b7c2d71987980db4c25d520452dabf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/21097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This chipset was just added and had a few places that needed to be
fixed.
Change-Id: Ief048c4876c5a2cb538c9cb4b295aba46a4fff62
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20684
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
At a process _start, the stack is expected to be aligned to a
16-byte boundary. Upon entry to any function the stack frame
must have the end of any arguments also aligned. In other words
the value of %esp+4 or %rsp+8 is always a multiple of 16 (1).
Align the stack down inside _secondary_start and preserve proper
alignment for the call to secondary_cpu_init.
Although 4-byte alignment is the minimum requirement for i386,
some AMD platforms use SSE instructions which expect 16-byte.
1) http://wiki.osdev.org/System_V_ABI
See "Initial Stack and Register State" and "The Stack Frame"
in the supplements.
BUG=chrome-os-partner:62841664
Change-Id: I72b7a474013e5caf67aedfabeb8d8d2553499b73
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/20537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some of these can be changed from #if to if(), but that will happen
in a follow-on commmit.
Change-Id: I4e5e585c3f98a129d89ef38b26d828d3bfeac7cf
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Fixes report found by undefined behavior sanitizer. Dereferencing a
pointer that's not aligned to the size of access is undefined behavior.
Remove unnecessary memset().
Change-Id: I1362a3eb8c97f5c7e848d75f8d1a219968a7ef9e
Signed-off-by: Ryan Salsamendi <rsalsamendi@hotmail.com>
Reviewed-on: https://review.coreboot.org/20452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
If SSE instructions are enabled in the build assume the SMM
modules are compiled with SSE instructions. As such enable
the SSE instructions in SMM mode by setting up the cr4 register.
In addition, provide a place to save and restore the SSE state
in both the relocation handler and permanent handler.
Change-Id: Ifa16876b57544919fde88fba5b8f18e4ca286841
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20244
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With the do while loop, it can be avoided do use an infinite loop with a
break condition inside.
Change-Id: I030f6782ad618b55112a2f0bac8dda08b497a9f1
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/20269
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 the existing macros for CR0 to set the flags in the
SIPI vector code.
Change-Id: Iad231b7611b613512fd000a7013175e91542ac10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20243
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use the existing macros for CR0 to set the flags in the
SMM stub.
Change-Id: I0f02fd6b0c14cee35ec33be2cac51057d18b82c0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20242
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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>
The previous implementation was using a for loop. By it's
very definition the last statement in the for loop declaration
is done at the end of the loop. Therefore, if the conditional for
breaking out of the for loop because of a timeout would always
see a value of 0 for the number of APs accepted. Correct this
by changing to a while loop with an explicit timeout condition
at the end of the loop.
Change-Id: I503953c46c2a65f7e264ed49c94c0a46d6c41c57
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20225
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If an MTRR solution exceeds the number of available MTRRs
don't attempt to commit the result. It will just GP fault
with the MSR write to an invalid MSR address.
Change-Id: I5c4912d5244526544c299c3953bca1bf884b34d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/20163
Reviewed-by: Youness Alaoui <snifikino@gmail.com>
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>
This patch adds a simple function that can be used to check if
CAR_GLOBALs are currently being read from CAR or from DRAM.
Change-Id: Ib7ad0896a691ef6e89e622b985417fedc43579c1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/19787
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>
When a platform is using postcar stage it's by definition not
tearing down cache-as-ram from within romstage prior to loading
ramstage. Because of this property there's no need to migrate
CAR_GLOBAL variables to cbmem.
Change-Id: I7c683e1937c3397cbbba15f0f5d4be9e624ac27f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19215
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@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 error and warnings detected by checkpatch.pl:
ERROR: trailing statements should be on next line
WARNING: storage class should be at the beginning of the declaration
WARNING: type 'long unsigned int' should be specified in [[un]signed] [short|int|long|long long] order
TEST=Build and run on Galileo Gen2
Change-Id: I9cfe42cf1836cfd40ffcf67237c818543f508feb
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18845
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
