Temporary MTRR setup usually covers the memory mapped flash. On recent
Intel hardware the mapping is not coherent. It uses an external window
for parts of the BIOS region that exceed 16M.
This now allows up to 10 temporary memory ranges.
TESTED: Qemu with multiple MTRR temporary MTRR ranges sets up a valid
and optimized temporary MTRR solution.
Change-Id: I23442bd2ab7602e4c5cbd37d187a31413cf27ecc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63555
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This code was hard to read as it did too much and had a lot of state
to keep track of.
It also looks like the staggered entry points were first copied and
only later the parameters of the first stub were filled in. This
means that only the BSP stub is actually jumping to the permanent
smihandler. On the APs the stub would jump to wherever c_handler
happens to point to, which is likely 0. This effectively means that on
APs it's likely easy to have arbitrary code execution in SMM which is a
security problem.
Change-Id: I42ef9d6a30f3039f25e2cde975086a1365ca4182
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
We don't want to keep track of the real smm size all the time.
As a bonus now ss_start is now really the start of the save state
instead of top - MAX(stub_size, save state size).
Change-Id: I0981022e6c0df110d4a342ff06b1a3332911e2b7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
This code is much easier to read if one does not have to keep track of
mutable variables.
This also fixes the alignment code on the TSEG smihandler setup code.
It was aligning the code upwards instead of downwards which would cause
it to encroach a part of the save state.
Change-Id: I310a232ced2ab15064bff99a39a26f745239f6b9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
Currently no smihandler uses heap.
coreboot's heap manager also is quite limited in what it will
free (only the latest alloc). This makes it a bad idea to use it inside
the smihandler, as depending on the alloc usage the heap might actually
be full at some point, breaking the smihandler.
This also reduces the ramstage by 448 bytes on google/vilboz.
Change-Id: I70cd822be17c1efe13c94a9dbd2e1038808b9c56
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Setting up postcar MTRRs is done when invd is already called so there
is no reason to do this in assembly anymore.
This also drops the custom code for Quark to set up MTRRs.
TESTED on foxconn/g41m and hermes/prodrive that MTRR are properly set
in postcar & ramstage.
Change-Id: I5ec10e84118197a04de0a5194336ef8bb049bba4
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54299
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MTRR is a core level register which means 2 threads in one core share
same MTRR. There is a race condition could happen that AP overrides
BSP MTRR unintentionally.
In order to prevent such race condition between BSP and APs, this
patch provides a function to let BSP assign tasks to all APs and wait
them to complete the assigned tasks.
BUG=b:225766934
Change-Id: I8d1d49bca410c821a3ad0347548afc42eb860594
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63566
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The lowest bound for L2 cache size on Socket P is 512 KiB.
This allows the use of cbfs mcache on all platforms.
This fixes building when some debug options are enabled.
Change-Id: I0d6f7f9151ecd4c9fbbba4ed033dfda8724b6772
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52942
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This removes the need for a tool to generate simple identity pages.
Future patches will link this page table directly into the stages on
some platforms so having an assembly file makes a lot of sense.
This also optimizes the size of the page of each 4K page by placing
the PDPE_table below the PDE.
Change-Id: Ia1e31b701a2584268c85d327bf139953213899e3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The printed address ranges in the tree (resource allocator and even
some MTRR code) usually shows the range inclusive (meaning from start
address to the real end address of the range). Though there is still
some code in the MTRR context which prints the ranges with an exclusive
end. This patch aligns the printing of ranges in the MTRR code to be
consistent among the tree so that the shown end addresses are now
inclusive.
Change-Id: I0ca292f9cf272564cb5ef1c4ea38f5c483605c94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
This patch calls into need_restore_mtrr() from the mtrr_use_temp_range
function to set `put_back_original_solution` to discard any temporary
MTRR range prior to boot to payload.
BUG=b:225766934
TEST=Able to build and boot google/brya to verify that
`remove_temp_solution()` is able to discard any temporary MTRR range
before booting to payload.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2e00ec593847e1eb173d5ac77b15b50342860f89
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
`put_back_original_solution` variable in mtrr.c is static, but there is
a need to set put_back_original_solution outside of mtrr.c in order to
let `remove_temp_solution` to drop any temporary MTRRs being set
outside `mtrr_use_temp_range()`, for example: `set_var_mtrr()` function
is used to set MTRRs for the ROM caching.
BUG=b:225766934
TEST=Able to build and boot google/redrix.
Change-Id: Ic6b5683b2aa7398a5e141f710394ab772e9775e7
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The sinkhole exploit exists in placing the lapic base such that it
messes with GDT. This can be mitigated by checking the lapic MSR
against the current program counter.
Change-Id: I49927c4f4218552b732bac8aae551d845ad7f079
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch delays removing `temporary` MTRR snapshots to avoid conflicts
with other operations attached with same `BS_PAYLOAD_BOOT/BS_ON_EXIT`
boot state.
BUG=b:225766934
TEST=Having variable MTRR snapshot using display_mtrrs() is able to
list only the permanent MTRRs and all temporary MTRRs are removed
prior to boot to payload.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I602dca989745159d013d6573191861b296f5d3ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This patch migrates a few useful MTRR functions as below from
`earlymtrr.c` file to newly created common stage file `mtrrlib.c`.
1. get_free_var_mtrr
2. set_var_mtrr
3. clear_all_var_mtrr
These functions can be used to perform the MTRR programming from IA
common code SPI driver as `fast_spi.c` without requiring two separate
implementations for early boot stage (till romstage) and for ramstage
onwards.
BUG=b:225766934
TEST=Able to build and boot google/redrix board to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I2c62a04a36d3169545c3128b4231992ad9b3699d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63218
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
When rebuilding coreboot the empty fit table added to added to CBFS
stays the same so the build process sees no reason to update the file.
In the meantime ifittool did update that file for instance to add
microcode update entries. So each time coreboot is rebuilt the entries
are appended to the FIT table which runs out of space at some point.
One way to deal with this is to clear the fit table when setting the
pointer inside the bootblock.
TESTED: Now running 'make' again on prodrive/hermes does not report an
error with a filled FIT table.
Change-Id: Ia20a489dc90a4ae704e9ee6d532766899f83ffcc
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63036
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change provides hooks for the SoC so it can perform any
initialization and cleanup in the SMM handler.
For example, if we have a UART enabled firmware with DEBUG_SMI, the UART
controller could have been powered off by the OS. In this case we need
to power on the UART when entering SMM, and then power it off before we
exit. If the OS had the UART enabled when entering SMM, we should
snapshot the UART register state, and restore it on exit. Otherwise we
risk clearing some interrupt enable bits.
BUG=b:221231786, b:217968734
TEST=Build test guybrush
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I946619cd62a974a98c575a92943b43ea639fc329
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change will allow the SMI handler to write to the cbmem console
buffer. Normally SMIs can only be debugged using some kind of serial
port (UART). By storing the SMI logs into cbmem we can debug SMIs using
`cbmem -1`. Now that these logs are available to the OS we could also
verify there were no errors in the SMI handler.
Since SMM can write to all of DRAM, we can't trust any pointers
provided by cbmem after the OS has booted. For this reason we store the
cbmem console pointer as part of the SMM runtime parameters. The cbmem
console is implemented as a circular buffer so it will never write
outside of this area.
BUG=b:221231786
TEST=Boot non-serial FW with DEBUG_SMI and verified SMI messages are
visible when running `cbmem -1`. Perform a suspend/resume cycle and
verify new SMI events are written to the cbmem console log.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia1e310a12ca2f54210ccfaee58807cb808cfff79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This patch aims to make timestamps more consistent in naming,
to follow one pattern. Until now there were many naming patterns:
- TS_START_*/TS_END_*
- TS_BEFORE_*/TS_AFTER_*
- TS_*_START/TS_*_END
This change also aims to indicate, that these timestamps can be used
to create time-ranges, e.g. from TS_BOOTBLOCK_START to TS_BOOTBLOCK_END.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I533e32392224d9b67c37e6a67987b09bf1cf51c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Correct some Quickpath initialisation steps according to findings from
two different Intel reference code binaries as well as MCHBAR register
dump comparisons between vendor firmware and coreboot.
The MSR_TURBO_POWER_CURRENT_LIMIT information comes from EDK2 sources.
Tested on Apple iMac 10,1 (Clarkdale, aka desktop Ironlake), QPI init
now completes successfully instead of causing hangs before raminit.
Also tested on HP ProBook 6550b (Arrandale, aka mobile Ironlake), still
reaches payload (e.g. TianoCore).
Change-Id: Icd0139aa588dc8d948c03132b5c86866d90f3231
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Fix regression after commit 9ec7227c9b
cpu/x86/lapic: Move LAPIC configuration to MP init
The call to disable_lapic() got removed and with asus/p2b
SeaBIOS payload was unable to load kernel.
The combination of entering SeaBIOS payload with an
enabled lapic but not having programmed LAPIC_LVT0
for DELIVERY_MODE_EXTINT apparently disconnects i8259
PIC interrupt delivery pin.
Change-Id: If51e5d65153a02ac7af191e7897c04bd4e298006
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This reverts commit ceaf959678.
The AMD Picasso SoC doesn't support x2APIC and neither advertises the
presence of its support via bit 21 in EAX of CPUID leaf 1 nor has the
bit 10 in the APIC base address MSR 0x1b set, but it does have 0xd CPUID
leaves, so just checking for the presence of that CPUID leaf isn't
sufficient to be sure that EDX of the CPUID leaf 0xb will contain a
valid APIC ID.
In the case of Picasso EDX of the CPUID leaf 0xb returns 0 for all cores
which causes coreboot to get stuck somewhere at the end of MP init.
I'm not 100% sure if we should additionally check bit 21 in EAX of CPUID
function 1 is set instead of adding back the is_x2apic_mode check.
TEST=Mandolin with a Picasso SoC boots again.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If1e3c55ce2d048b14c08e06bb79810179a87993d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Implementation for setup_lapic() did two things -- call
enable_lapic() and virtual_wire_mode_init().
In PARALLEL_MP case enable_lapic() was redundant as it
was already executed prior to initialize_cpu() call.
For the !PARALLEL_MP case enable_lapic() is added to
AP CPUs.
Change-Id: I5caf94315776a499e9cf8f007251b61f51292dc5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
