summaryrefslogtreecommitdiff
path: root/src/cpu/x86
AgeCommit message (Collapse)Author
2018-04-09cpu/x86/mtrr: Use single code path with/without holesNico Huber
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>
2018-04-09cpu/x86/mtrr: Optimize hole carving strategyNico Huber
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>
2018-04-01x86: Increase time out for parking APs to 250msFurquan Shaikh
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>
2018-03-09cpu/x86/mp_init: Print amount of time it takes in bsp_do_flight_planFurquan Shaikh
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>
2018-03-05cpu/x86/mp_init: Increase AP check-in time-out to 1secondFurquan Shaikh
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>
2018-02-16x86/mtrr: Enable Rd/WrDram mod in AMD fixed MTRRsMarshall Dawson
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>
2018-02-15cpu/x86/16bit/entry16.inc: Fix typo in commentPaul Menzel
Add the missing *r* of the possessive pronoun *your*. Change-Id: I2b520f398a904eb8e4412835d90bde1ee0b504b7 Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-on: https://review.coreboot.org/23758 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
2018-01-25cpu/x86: don't utilize UDELAY_IO if GENERIC_UDELAYAaron Durbin
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>
2018-01-15Intel sch board & chip: Remove - using LATE_CBMEM_INITMartin Roth
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>
2017-12-20cpu/x86: set permanent SMM handler stack to 1KiBAaron Durbin
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>
2017-12-11intel: Use MSR_EBC_FREQUENCY_ID instead of 0x2cElyes HAOUAS
Change-Id: Ib1b761fc417f1bb000f408d3bed5e8666963f51d Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/22603 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-10-31x86/lapic: Use the existing lapicid() functionMarc Jones
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>
2017-10-16cpu/x86/mtrr: Remove var-MTRR alignment optimizationNico Huber
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>
2017-10-02cpu/x86: Align stack in SIPI handlerMarshall Dawson
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>
2017-09-17cpu/x86/sipi_vector.S: Use correct op suffixDamien Zammit
clang wont compile `cmp` asm opcode because it's ambiguous, use the correct op suffix `cmpl` Change-Id: I82da5a9065b382e182dc7d502c7dca2fc717543b Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: https://review.coreboot.org/21359 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-09-11cpu/x86/mp_init: remove adjust_cpu_apic_entry()Aaron Durbin
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>
2017-09-05Move ADDR32() hack to arch/x86Patrick Georgi
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>
2017-09-02cpu/x86/smm: Fix explicit 'addr32' usage in clang buildsEdward O'Callaghan
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>
2017-08-31AGESA: Remove separate f15rlKyösti Mälkki
Change-Id: I18c62ad034249c5ad14e5d5e708b4f0d4bcbf400 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/20774 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-08-31cpu/x86 asm: Just use the correct op suffixEdward O'Callaghan
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>
2017-08-19arch/x86: Sanity checking on HAVE_SMI_HANDLERKyösti Mälkki
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>
2017-08-19i82801dx/gx/ix/jx: Add low-memory backup for S3 pathKyösti Mälkki
SMM relocation code overwrite low memory owned by OS. Change-Id: Ifa3d28bed3d3db65b0707bde62ae2b424a231f1a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/19405 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-08-19arch/x86: Clean up CONFIG_SMP and MAX_CPUS testKyösti Mälkki
Change-Id: I7c138758707f87c0d7a827b6887c7752d3714cde Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/21088 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-08-19arch/x86: Fix ugly NEED_LAPIC useKyösti Mälkki
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>
2017-07-21I82801JX: Add IS_ENABLED around config optionsMartin Roth
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>
2017-07-21sb/intel/i82801jx: Add correct PCI ids and change namesArthur Heymans
Change-Id: Ic9226098dafa2465aa5fccc72c442de2b94e44c7 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/19249 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
2017-07-20x86/lapic/secondary.S: Align stack for _secondary_startMarshall Dawson
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>
2017-07-13src/cpu: add IS_ENABLED() around Kconfig symbol referencesMartin Roth
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>
2017-07-13Rename __attribute__((packed)) --> __packedStefan Reinauer
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>
2017-07-03cpu/x86/name: Fix undefined behaviorRyan Salsamendi
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>
2017-06-27cpu/x86/smm: allow SSE instructions in SMM modulesAaron Durbin
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>
2017-06-22cpu/x86: Use do while loopPaul Menzel
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>
2017-06-22cpu/x86/sipi_vector: use macros for CR0 flagsAaron Durbin
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>
2017-06-22cpu/x86/smm: use macros for CR0 flagsAaron Durbin
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>
2017-06-22cpu/x86/smm: fix up types in module loaderAaron Durbin
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>
2017-06-19cpu/x86/smm/smihandler: Apply cosmetic changesPatrick Rudolph
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>
2017-06-16cpu/x86/mp_init: report correct count of AP acceptanceAaron Durbin
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>
2017-06-13cpu/x86/mtrr: fail early if solution exceeds available MTRRsAaron Durbin
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>
2017-06-12cpu/x86: fix spelling mistakeMartin Roth
Change-Id: Id88455f2c7c28e0b298675b9af2a39361759a34a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/19120 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2017-05-30arch/x86: Add function to determine if we're currently running from CARJulius Werner
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>
2017-04-08arch/x86: remove CAR global migration when postcar stage is usedAaron Durbin
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>
2017-03-19cpu/x86: add a barrier with timeoutBora Guvendik
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>
2017-03-16cpu/x86: Fix misc. remaining issues detected by checkpatchLee Leahy
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>
2017-03-16cpu/x86: Wrap lines at 80 columnsLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: line over 80 characters TEST=Build and run on Galileo Gen2 Change-Id: I56ea28826963403dc0719f40c13782c56dc97feb Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18844 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Add int to unsignedLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' TEST=Build and run on Galileo Gen2 Change-Id: I97bbe8ba19680bdb99fa38daa5e18b440c338576 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18843 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Remove braces and else if unnecessaryLee Leahy
Fix the following warnings detected by checkpatch.pl WARNING: braces {} are not necessary for single statement blocks WARNING: braces {} are not necessary for any arm of this statement WARNING: else is not generally useful after a break or return TEST=Build and run on Galileo Gen2 Change-Id: I2d6b22c66d52f5f2d24b15270ad4b52894adebc2 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18842 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Use tabs for indentLee Leahy
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: Ie6e4dd4c3eb0d2c44ecd008740dfc348d496fe78 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18841 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16cpu/x86: Fix various issues detected by checkpatch.plLee Leahy
Fix the following errors and warning detected by checkpatch.pl: ERROR: spaces required around that '=' (ctx:VxV) ERROR: space prohibited after that open parenthesis '(' ERROR: need consistent spacing around '|' (ctx:WxV) ERROR: need consistent spacing around '|' (ctx:VxW) ERROR: spaces required around that '=' (ctx:VxV) ERROR: spaces required around that '==' (ctx:VxV) ERROR: spaces required around that ':' (ctx:ExV) WARNING: space prohibited between function name and open parenthesis '(' TEST=Build and run on Galileo Gen2 Change-Id: I61d08055b207c607d5b7d72b0094ad8e24fbd106 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18840 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-16src/cpu/x86: Remove space between * and variable nameLee Leahy
Fix the following error detected by checkpatch.pl: ERROR: "foo * bar" should be "foo *bar" TEST=Build and run on Galileo Gen2 Change-Id: I8b5342df3f42dbb4576aecf5b0a59f195ae8511e Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18839 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
2017-02-22src/cpu/x86: Update/Add license headers to all filesMartin Roth
Change-Id: I436bf0e7db008ea78e29eaeef10bea101e6c8922 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18405 Tested-by: build bot (Jenkins) Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2016-12-16Set the fsb timer correctly for Netburst CPUsArthur Heymans
On Netburst (Pentium 4) the fsb cannot be read from MSR_FSB_FREQ (msr 0xcd). One has to use msr 0x2c instead. Change-Id: I0beccba2e4a8ec5cd23537b2207f9c49a040fd73 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/17832 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2016-12-11x86 SMM: Fix use with RELOCATABLE_RAMSTAGEKyösti Mälkki
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>
2016-12-08cpu/x86: allow AP callbacks after MP initAaron Durbin
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>
2016-12-08buildsystem: Drop explicit (k)config.h includesKyösti Mälkki
We have kconfig.h auto-included and it pulls config.h too. Change-Id: I665a0a168b0d4d3b8f3a27203827b542769988da Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17655 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-11-12cpu/x86/mtrr: allow temporary MTRR range during corebootAaron Durbin
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>
2016-10-07src/cpu: Remove unnecessary whitespaceElyes HAOUAS
Change-Id: I0903b7ca9eada4beacfcdbcacddec23c3515651e Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16850 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-09-12cpu/x86: Move fls() and fms() to mtrr.hRizwan Qureshi
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>
2016-09-04src/cpu: Improve code formattingElyes HAOUAS
Change-Id: I17d5efe382da5301a9f5d595186d0fb7576725ca Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16391 Tested-by: build bot (Jenkins) Reviewed-by: Andrew Wu <arw@dmp.com.tw> Reviewed-by: Antonello Dettori <dev@dettori.io>
2016-08-28src/cpu: Add required space before opening parenthesis '('Elyes HAOUAS
Change-Id: I7fb9bfcaeec0b9dfd0695d2b2d398fd01091f6bc Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16286 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Omar Pakker
2016-08-23src/cpu: Capitalize CPU, APIC and IOAPIC typo fixElyes HAOUAS
Change-Id: I82e0736dc6b44cfcc57cdfdc786c85c4b6882260 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16276 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker
2016-08-18Kconfig: rename BOOT_MEDIA_SPI_BUS to BOOT_DEVICE_SPI_FLASH_BUSAaron Durbin
Provide a default value of 0 in drivers/spi as there weren't default values aside from specific mainboards and arch/x86. Remove any default 0 values while noting to keep the option's default to 0. BUG=chrome-os-partner:56151 Change-Id: If9ef585e011a46b5cd152a03e41d545b36355a61 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16192 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-31src/cpu: Capitalize CPUElyes HAOUAS
Change-Id: I58d5c16de796a91fa14d8db78722024266c09a94 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15934 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-07-31src/cpu: Capitalize ROM and RAMElyes HAOUAS
Change-Id: I103167a0c39627bcd2ca1d0d4288eb5df02a6cd2 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/15935 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-07-27cpu/x86: Support CPUs without rdmsr/wrmsr instructionsLee Leahy
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>
2016-07-22cpu/x86/mtrr: correct variable MTRR calculation around 1MiB boundaryAaron Durbin
The fixed MTRRs cover the range [0:1MiB). While calculating the variable MTRR usage the 1MiB boundary is checked such that an excessive number of MTRRs aren't used because of unnatural alignment at the low end of the physical address space. Howevever, those checks weren't inclusive of the 1MiB boundary. As such a variable MTRR could be used for a range which is actually covered by the fixed MTRRs when the end address is equal to 1MiB. Likewise, if the starting address of the range lands on the 1MiB boundary then more variable MTRRs are calculated in order to meet natural alignment requirements. Before: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0 0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6 0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0 0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1 0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0 0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6 CPU physical address size: 39 bits MTRR: default type WB/UC MTRR counts: 7/17. MTRR: WB selected as default type. MTRR: 0 base 0x0000000000000000 mask 0x0000007ffff00000 type 0 MTRR: 1 base 0x000000007b800000 mask 0x0000007fff800000 type 0 MTRR: 2 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 MTRR: 3 base 0x0000000080000000 mask 0x0000007fe0000000 type 0 MTRR: 4 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0 MTRR: 5 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1 MTRR: 6 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 After: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x0000000000100000 size 0x00060000 type 0 0x0000000000100000 - 0x000000007b800000 size 0x7b700000 type 6 0x000000007b800000 - 0x00000000b0000000 size 0x34800000 type 0 0x00000000b0000000 - 0x00000000c0000000 size 0x10000000 type 1 0x00000000c0000000 - 0x0000000100000000 size 0x40000000 type 0 0x0000000100000000 - 0x0000000180000000 size 0x80000000 type 6 CPU physical address size: 39 bits MTRR: default type WB/UC MTRR counts: 6/8. MTRR: WB selected as default type. MTRR: 0 base 0x000000007b800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x000000007c000000 mask 0x0000007ffc000000 type 0 MTRR: 2 base 0x0000000080000000 mask 0x0000007fe0000000 type 0 MTRR: 3 base 0x00000000a0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000b0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000c0000000 mask 0x0000007fc0000000 type 0 BUG=chrome-os-partner:55504 Change-Id: I7feab38dfe135f5e596c9e67520378a406aa6866 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/15780 Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-06-22ACPI S3: Move SMP trampoline recoveryKyösti Mälkki
No need to make low memory backup unless we are on S3 resume path. Hide those details from ACPI. Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15241 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-17intel/sch: Merge northbridge and southbridge in src/socStefan Reinauer
Change-Id: I6ea9b9d2353c0d767c837e6d629b45f23b306f6e Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/14599 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2016-05-06cpu/x86: don't treat all chipsets the same regarding XIP_ROM_SIZEAaron Durbin
Previously, the XIP_ROM_SIZE Kconfig variable is used globally on x86 platforms with the assumption that all chipsets utilize this value. For the chipsets which do not use the variable it can lead to unnecessary alignment constraints in cbfs for romstage. Therefore, allow those chipsets a path to not be burdened by not passing '-P $(XIP_ROM_SIZE)' to cbfstool when adding romstage. Change-Id: Id8692df5ecec116a72b8e5886d86648ca959c78b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14625 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-05-06cpu/x86/mp_init: reduce exposure of internal implementationAaron Durbin
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>
2016-05-04cpu/x86: combine multiprocessor and SMM initializationAaron Durbin
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>
2016-05-04cpu/x86: remove BACKUP_DEFAULT_SMM_REGION optionAaron Durbin
Unconditionally provide the backup default SMM area API. There's no reason to guard the symbols behind anything since linker garbage collection is implemented. A board or chipset is free to use the code or not without needing to select an option. Change-Id: I14cf1318136a17f48ba5ae119507918190e25387 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14561 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-04cpu/x86/smm_module_loader: always build with SMM module supportAaron Durbin
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>
2016-05-02cpu/x86/mp_init: remove unused callback argumentsAaron Durbin
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>
2016-04-28soc/intel/apollolake: Add cache for BIOS ROMAndrey Petrov
Enable caching of BIOS region with variable MTRR. This is most useful if enabled early such as in bootblock. Change-Id: I39f33ca43f06fce26d1d48e706c97f097e3c10f1 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14480 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-04-11cpu/x86/tsc: Compile TSC timer for postcar as wellAndrey Petrov
Change-Id: I8fd79d438756aae03649e320d4d640cee284d88a Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14298 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-04-11cpu/x86/tsc: remove conditional compilationAaron Durbin
The delay_tsc.c compilation unit used the C preprocessor to conditionally compile different code paths. Instead of guarding large blocks of code allow the compiler to optimize out unreachable code. Change-Id: I660c21d6f4099b0d7aefa84b14f1e68d6fd732c3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14302 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-04-11cpu/x86/tsc: compile same code for all stagesAaron Durbin
The delay_tsc.c code took different paths depending __PRE_RAM__ being defined or not. Also, timer_monotonic_get() was only compiled in a !__PRE_RAM__ environment. Clean up the code paths by employing CAR_GLOBAL for the global state which allows the same code to be used in all stages. Lastly, handle apollolake fallout now that init_timer() is not needed in placeholders.c. Change-Id: Ia769fa71e2c9d8b11201a3896d117097f2cb7c56 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14301 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-04-11cpu/x86/tsc: prepare for CAR_GLOBAL in delay_tsc.cAaron Durbin
The current code in delay_tsc.c uses globals and is heavily guarded by a lot of preprocessor macros. In order to remove __PRE_RAM__ constraints one needs to use CAR_GLOBAL for the global variables. Therefore, abstract away direct access to the globals such that CAR_GLOBAL can be easily employed. Change-Id: I3350d1a762120476926c8d9f5f5a7aba138daf5f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14300 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-04-11src/cpu/x86: remove TSC_CALIBRATE_WITH_IOAaron Durbin
It's not selected by any path so it's a dead option with associated dead code. Remove the config option as well as the code paths that were never used any longer. Change-Id: Ie536eee54e5c63bd90192f413c69e0dd2fea9171 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14299 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Myles Watson <mylesgw@gmail.com>
2016-03-23arch/x86: introduce postcar stage/phaseAaron Durbin
Certain chipsets don't have a memory-mapped boot media so their code execution for stages prior to DRAM initialization is backed by SRAM or cache-as-ram. The postcar stage/phase handles the cache-as-ram situation where in order to tear down cache-as-ram one needs to be executing out of a backing store that isn't transient. By current definition, cache-as-ram is volatile and tearing it down leads to its contents disappearing. Therefore provide a shim layer, postcar, that's loaded into memory and executed which does 2 things: 1. Tears down cache-as-ram with a chipset helper function. 2. Loads and runs ramstage. Because those 2 things are executed out of ram there's no issue of the code's backing store while executing the code that tears down cache-as-ram. The current implementation makes no assumption regarding cacheability of the DRAM itself. If the chipset code wishes to cache DRAM for loading of the postcar stage/phase then it's also up to the chipset to handle any coherency issues pertaining to cache-as-ram destruction. Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14140 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-18mtrr: Define a function for obtaining free var mtrrFurquan Shaikh
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>
2016-03-16cpu/x86: compile earlymtrr.c code for romstage as wellAndrey Petrov
In order to make this work earlymtrr.c needed to be removed from intel/truxton/romstage.c. It's not a ROMCC board so there's no reason to be including .c files. Change-Id: If4f5494a53773454b97b90fb856f7e52cadb3f44 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14094 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-16cpu/x86/mtrr: remove early_mtrr_* functionsAaron Durbin
I see no user of any of this code. Remove it. Change-Id: I776cd3d9ac6578ecb0fe6d98f15611e4463afb7a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14098 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-16cpu/x86/mtrr: move cache_ramstage() to its only userAaron Durbin
The Intel i3100 northbridge code is the only user of cache_ramstage(). Therefore, place it next to the sole consumer. Change-Id: If15fb8d84f98dce7f4de9e089ec33035622d8f74 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14097 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-08cpu/x86/mtrr: add helper function to detect variable MTRRsAaron Durbin
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)
2016-03-08cpu/x86: Sort some Kconfig optionsStefan Reinauer
Change-Id: I25ea327ed151e18ccb5d13626d44925d2a253d08 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/10012 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-03-05arch/x86: document CAR symbols and expose them in symbols.hAndrey Petrov
Attempt to better document the symbol usage in car.ld for cache-as-ram usage. Additionally, add _car_region_[start|end] that completely covers the entire cache-as-ram region. The _car_data_[start|end] symbols were renamed to _car_relocatable_data_[start|end] in the hopes of making it clearer that objects within there move. Lastly, all these symbols were added to arch/symbols.h. Change-Id: I1f1af4983804dc8521d0427f43381bde6d23a060 Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13804 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-04arch/x86: always use _start as entry symbol for all stagesAaron Durbin
Instead of keeping track of all the combinations of entry points depending on the stage and other options just use _start. That way, there's no need to update the arch/header.ld for complicated cases as _start is always the entry point for a stage. Change-Id: I7795a5ee1caba92ab533bdb8c3ad80294901a48b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13882 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-04arch/x86: rename reset_vector -> _startAaron Durbin
In order to align the entry points for the various stages on x86 to _start one needs to rename the reset_vector symbol. The section is the same; it's just a symbol change. Change-Id: I0e6bbf1da04a6e248781a9c222a146725c34268a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13881 Tested-by: build bot (Jenkins) Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-03-03cpu/x86/16bit: rename _start -> _start16bitAaron Durbin
In order to avoid collisions with other _start symbols while grepping and future ones be explicit about which _start this one is: the 16-bit one only used by the reset vector in the bootblock. Change-Id: I6d7580596c0e6602a87fb158633ce9d45910cec2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13880 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2016-03-03cpu/x86/16bit/reset16: mark reset vector executableAaron Durbin
It's helpful to see the reset vector in objdump output. Without it being marked executable it doesn't get displayed. Change-Id: I85cb72ea0727d3f3c2186ae20b9c5cfe5d23aeed Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13879 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2016-03-03cpu/x86/16bit/reset16: remove stale 32-bit jumpAaron Durbin
Patrick at least indicated this jump after the reset vector jump was a remnant from some construct used long ago in the project. It's not longer used (nor could I find where it was). Therefore, remove it. Change-Id: I31512c66a9144267739b08d5f9659c4fcde1b794 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13878 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2016-02-11cpu/x86/tsc: Compile delay_tsc.c for the bootblock as wellAlexandru Gagniuc
This is needed in a follow-on patch to enable udelay() handling on apollolake, which is a dependency for the console code. Change-Id: I7da6a060a91b83f3b32c5c5d269c102ce7ae3b8a Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/13302 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-02src: Fix various spelling and whitespace issues.Martin Roth
This fixes some spelling and whitespace issues that I came across while working on various things in the tree. There are no functional changes. Change-Id: I33bc77282f2f94a1fc5f1bc713e44f72db20c1ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13016 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-28Move object files to $(obj)/<class>/Nico Huber
Instead of tagging object files with .<class>, move them to a <class> directory below $(obj)/. This way we can keep a 1:1 mapping between source- and object-file names. The 1:1 mapping is a prerequisite for Ada, where the compiler refuses any other object-file name. Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: Idb7a8abec4ea0a37021d9fc24cc8583c4d3bf67c Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13181 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-01-28Makefile: Make full use of src-to-obj macroNico Huber
There were several spots in the tree where the path to a per class object file was hardcoded. To make use of the src-to-obj macro for this, it had to be moved before the inclusion of subdirs. Which is fine, as it doesn't have dependencies beside $(obj). Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13180 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-21*/Makefile.inc: Compile files needed by uart8250 in x86 bootblockAlexandru Gagniuc
These files provide symbols needed by console and uart drivers. This was not an issue in the past, as we were not setting up a C environment this early in the boot process. Change-Id: Ied5106ac30a68971c8330e8f8270ab060994a89d Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com> Reviewed-on: https://review.coreboot.org/12869 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-20cpu: Fix typo that spelled "allocate" as "allocte."Jacob Laska
The error informing the user that the CPU device cannot be allocated has a typo incorrectly spelling "allocate" as "allocte". TEST=Compiled Change-Id: I2a6bad56133e375e2fd6a670593791414bf0dc2c Signed-off-by: Jacob Laska <jlaska91@gmail.com> Reviewed-on: https://review.coreboot.org/13030 Tested-by: build bot (Jenkins) Reviewed-by: Ben Frisch <bfrisch@xes-inc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-12-02x86/smm: Initialize SMM on some CPUs one-by-oneDamien Zammit
We currently race in SMM init on Atom 230 (and potentially other CPUs). At least on the 230, this leads to a hang on RSM, likely because both hyperthreads mess around with SMBASE and other SMM state variables in parallel without coordination. The same behaviour occurs with Atom D5xx. Change it so first APs are spun up and sent to sleep, then BSP initializes SMM, then every CPU, one after another. Only do this when SERIALIZE_SMM_INITIALIZATION is set. Set the flag for Atom CPUs. Change-Id: I1ae864e37546298ea222e81349c27cf774ed251f Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: https://review.coreboot.org/6311 Tested-by: build bot (Jenkins) Tested-by: BSI firmware lab <coreboot-labor@bsi.bund.de> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-24FSP 1.0: Fix CAR issues - broken timestamps and consoleBen Gardner
FSP 1.0 has a fixed-size temporary cache size and address and the entire cache is migrated in the FSP FspInitEntry() function. Previous code expected the symbol _car_data_start to be the same as CONFIG_DCACHE_RAM_BASE and _car_data_end to be the same as _preram_cbmem_console. FSP 1.0 is the only one that migrates _preram_cbmem_console. Others leave that where it is and extract the early console data in cbmemc_reinit(). Special handling is needed to handle that. Commit dd6fa93d broke both assumptions and so broke the timestamp table and console. The fix is to use CONFIG_DCACHE_RAM_BASE when calculating the offset and to use _preram_cbmem_console instead of _car_data_end for the console check. Change-Id: I6db109269b3537f7cb1300357c483ff2a745ffa7 Signed-off-by: Ben Gardner <gardner.ben@gmail.com> Reviewed-on: http://review.coreboot.org/12511 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-27 21:45:57 +0000