This commit fixes an incorrect variable name in the page table setup
for 1 GiB pages.
The label PDE_table was used when it should have been PDPT, as it
represents a "Page Directory Pointer Table (PDPT)", not a "Page
Directory Table (PDT) or PDE_Table".
This change ensures correct nomenclature and consistency in the code.
PML4 -> PDPT --------> 1GB Physical Page
As per x86-64 specification, 1GB pages bypass the Page Directory Table
(PDT) level of the page table hierarchy, mapping directly from the
Page Directory Pointer (PDPT) Table to the physical page.
Change-Id: I1e1064653a265215054f31f0e4e46bf8200ca471
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83100
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This patch flips the polarity of CONFIG_USE_1G_PAGES_TLB into
CONFIG_NEED_SMALL_2MB_PAGE_TABLES which is off by default, meaning
CPUs added in the future will automatically build the smaller 1GB pages.
We can expect support for this feature to be available on all future CPU
generations (with the possible exception of embedded edge cases), so
this default setting should make mistakes less likely and keep
maintenance effort lower. (Besides, enabling the support where it
doesn't work fails fast, whereas keeping it disabled where it could work
is an inefficiency that can easily go overlooked for a long time.)
While this is technically a CPU feature, not a northbridge feature, we
support a lot more individual CPUs than northbridges in the pre-SoC era,
and they tend to be closely coupled anyway. So select the option at the
northbridge level for older CPUs to keep things simpler.
Change-Id: I2cf1237a7fb63b8904c2a3d57fead162c66bacde
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82792
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Code dealing with PAE can be used outside of memset_pae(). This change
extracts creation of identity mapped pagetables to init_pae_pagetables()
and mapping of single 2 MiB map to pae_map_2M_page(). Both functions are
exported in include/cpu/x86/pae.h to allow use outside of pgtbl.c.
MEMSET_PAE_* macros were renamed to PAE_* since they no longer apply
only to memset_pae().
Change-Id: I8aa80eb246ff0e77e1f51d71933d3d00ab75aaeb
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82249
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<stdio.h> header is used for input/output operations (such as printf,
scanf, fopen, etc.). Although some input/output functions can manipulate
strings, they do not need to directly include <string.h> because they
are declared independently.
Change-Id: Ibe2a4ff6f68843a6d99cfdfe182cf2dd922802aa
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82665
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function had roughly the same use (except PAT) as part of
memset_pae(), however the latter is able to make use of PAE and map
physical memory located above 4 GB. Remove paging_identity_map_addr()
to avoid semi-duplicated code.
The function has been unused since CB:26745.
Change-Id: I7a4ebd84a6f5d222c3b2c6c6e3d26d6464cf01b8
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82248
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This function isn't used anywhere. It probably wouldn't work with
current coreboot anyway, as it identity mapped lower 2GB of RAM, while
ramstage is run from CBMEM, which is usually just below top of memory.
It was last used in K8 code that is long gone.
Change-Id: I97e2830f381181d7f21ab5f6d4c544066c15b08c
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Allow to set board specific CPU voltage regulator settings.
The VR12 compatible voltage regulator for the CPU can be configured
by two MSRs. Currently a default value is applied, which mimics the
Intel reference code and is what the BWG suggest. However most board
vendors fill in the actual VR parameters to support OC or ULV board
variants.
When the mainboard design is too different from the Intel reference
design, not updating the VR settings might result in:
- unstable system behaviour
- limited turbo performance
- excessive battery drain
- no over-clocking capability
This patch adds support to set the board specific current limit for
Icc and Igfx.
It also allows to adjust PSI1, PSI2 and PSI3, which are powerstates
used by the VR, that consume less energy when the system is idle.
Test on Lenovo X220 with full CPU load after 1 minute, compared to
previous code with default settings:
- Limiting PP0 max current below Iccmax results in less CPU performance.
RAPL readings show that less power is drawn over time.
- Limiting PP0 max current to Iccmax results in equal CPU performance.
RAPL readings show that the same power is drawn over time.
- Setting the PP0 max current to a value >> Iccmax results in equal CPU
performance. RAPL readings show that the same power is drawn over
time.
- Updating the MSR at runtime has no effect.
Change-Id: I59edab47fc4fbe0240e1dd7d25647f7549b4def2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Core 2 platforms have issues with HPET. Enable support to use the LAPIC
driver so those machines actually boot and don't hang.
The LAPIC is actually closer to the CPU than the HPET (on the PCH),
which reduces access latency, leading to higher resolution of the timer.
Tested on a Lenovo X200 with a Core 2 Duo.
Change-Id: I33144d6c1c120e7faa47b99e8262b0997c45c9b9
Signed-off-by: Jean Lucas <jean@4ray.co>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82000
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
<string.h> is supposed to provide <stdarg.h> and <stdio.h>
Change-Id: I021ba535ba5ec683021c4dfc41ac18d9cebbcfd2
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81853
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
<device/device.h> is supposed to provide <device/{path,resource}.h>
Change-Id: I2ef82c8fe30b1c1399a9f85c1734ce8ba16a1f88
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
This removes the runtime SMI call to set up the communication buffer
for SMMSTORE in favor of setting this buffer up during the installation
of the smihandler.
The reason is that it's less code in the handler and a time costly SMI
is also avoided in ramstage.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I94dce77711f37f87033530f5ae48cb850a39341b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79738
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Currently the SRAT table only exposes one proximity group as
it uses the LAPIC node_id, which is always initialized to 0.
Use CPUID leaf 0x1f or 0xb to gather the node ID and fill it
to make sure that at least one proximity group for every socket
is advertised.
For now the SNC config isn't taken into account.
Change-Id: Ia3ed1e5923aa18ca7619b32cde491fdb4da0fa0d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
With SMM holding page tables itself, we can consider SMM support stable
and safe enough for general use.
Also update the respective documentation.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ifcf0a1a5097a2d7c064bb709ec0b09ebee13a47d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
When switching back and forth between 32 to 64 bit mode, for example to
call a 32-bits FSP or to call the payload, new page tables in the
respective stage will be linked.
The advantages of this approach are:
- No need to determine a good place for page tables in CBFS that does
not overlap.
- Works with non memory mapped flash (however all coreboot targets
currently do support this)
- If later stages can use their own page tables which fits better with
the vboot RO/RW flow
A disadvantage is that it increases the stage size. This could be
improved upon by using 1G pages and generating the pages at runtime.
Note: qemu cannot have the page tables in the RO boot medium and needs
to relocate them at runtime. This is why keeping the existing code with
page tables in CBFS is done for now.
TEST: Booted to payload on google/vilbox and qemu/q35
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This data is used by smm_region_overlaps_handler(). Callers use this
helper to determine if it's safe to read/write to memory buffers taken
from untrusted input.
coreboot SMI handlers must not be confused into writing over any SMRAM
subregion, which includes the TSEG_STAGE_CACHE and chipset-specific area
(sometimes, IED), not just the handlers.
If stage cache writes were permitted, this could compromise the
integrity of the S3 resume path.
The consequences to overwriting the chipset-specific area are undefined.
Change-Id: Ibd9ed34fcfd77a4236b5cf122747a6718ce9c91f
Signed-off-by: Benjamin Doron <benjamin.doron@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80703
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The commit below uses USE_1G_PAGETABLES config flag instead of
the correct USE_1G_PAGES_TLB.
"commit ecbc243a45
("cpu/x86: Add 1GiB pages for memory access up to 512GiB")"
Signed-off-by: Bora Guvendik <bora.guvendik@intel.com>
Change-Id: Ic19812bc1f90cbe7d3739c42a0314b3650e0501d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Improves user experience by highlighting a possibility of runtime
hangs caused by unsupported WB caching during NEM.
Recently we have encountered an issue on Intel platform and came to
know about the NEM logical limitation where due to cache sets are not
in power_on_two running into a runtime hang upon enabling WB caching.
BUG=b:306677879
BRANCH=firmware-rex-15709.B
TEST=Verified boot on google/ovis and google/rex (including Ovis with
non-power-of-two cache configuration).
Change-Id: Ic4fbef1fcc018856420428139683897634c9f85d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81336
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Relying on page tables being in RO flash is not safe in every setup,
therefore set up some page tables in SMRAM that the permanent smihandler
can use.
Tested on QEMU.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Icb3086abd577b9abb9966dd910a264a873ace4ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80336
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To allow for more flexibility like generating page tables at runtime or
page tables that are part of the ramstage, add a parameter to
sipi_vector.S and smm_stub.S so that APs use the same page tables as the
BSP during their initialization.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I1250ea6f63c65228178ee66e06d988dadfcc2a37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80335
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
No rmodule was using heap.
Change-Id: I0bc049a5231dabbec1c962a99ef875eddcc4ac6e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80733
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This makes it easier to reuse, e.g. if you want to do it twice in one
assembly file.
Change-Id: Ida861338004187e4e714be41e17c8447fa4cf935
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Although entry64.inc does guard against ENV_X86_64, it's more aesthetic
to have it with the other 64bit code below a guard just like other
platforms.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: If3ef19dd6654cd2fa0be3c68dee4a472e7a7935d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Current pagetable implementation allows memory access up to 4GiB using
2MiB pages. If user wants to access more than 4GiB with a 2MiB page it
will require more pagetable entries. By using a 1GiB page table, users
can access more than 4GiB of memory while reducing the number of
pagetable entries. This patch enables memory access up to 512GiB through
1GiB pages by selecting USE_1G_PAGES_TLB in Kconfig.
TEST: Verified in 64bit mode boot and access above 4GiB
Change-Id: Id569ae5b50abf5b72e4db33b5e4cd802399e76ec
Signed-off-by: Ashish Kumar Mishra <ashish.k.mishra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80088
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When a device with no resource is passed it will keep overwriting
the current slot. Remove the conditional and allow a PCI device
to not have any resources.
This is particular useful for the next commits that makes use
of the PCI resource store to pass UBOX devices to SMM that allow
to lock-down SMM from within an SMI handler. Those devices do
not have any resources and cannot be hardcoded in SMM as their
PCI segment group and bus number varies depending on socket
count, CPU discovery and configuration.
Change-Id: I1a1b5944c97da5be6b9794c653b5159683f492e5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80246
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Allow SMM to verify the list of provided PCI devices by comparing
the device and vendor ID for each PCI device.
Change-Id: I7086fa450fcb117ef8767c199c30462c1ab1e1b6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80245
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I552d487978906f5ea74c3d0d85373fe5b2de3f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80068
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
This reverts commit acbc491237.
Reason for revert: CB:79525 fixes the issue that led to the revert
by not maintaining the heap in the SMM-stored copy of ramstage at all.
Change-Id: I3c8ef785486d275c9341859d34fce12253bd2bb9
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80023
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Always use the high-level API region_offset() and region_sz()
functions. This excludes the internal `region.c` code as well
as unit tests. FIT payload support was also skipped, as it
seems it never tried to use the API and would need a bigger
overhaul.
Change-Id: Iaae116a1ab2da3b2ea2a5ebcd0c300b238582834
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79904
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Use call_smm instead of writing the command number directly to the APMC
SMI command IO port.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iefbdb3d17932d6db6a17b5771436ede220c714fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79828
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though the return value from apm_control isn't checked at any of
its call sites, using the cb_err enum instead of an integer as return
type makes it clearer what the returned value means.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I07ced74cae915df52a9d439835b84237d51fdd11
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79835
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Instead of hard-coding the APMC SMI command IO port in the FADT, call
pm_acpi_smi_cmd_port() to get the APMC SMI command IO port. Also update
the comment in apm_get_apmc to match what it's doing.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0f36b8a0e93a82b8c6d23c5c5d8fbebb1bc6b0bc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Add a protected mode wrapper function that takes three arguments.
This is already supported by the called assembly code.
Change-Id: Ia8c91eebae17e4ca27e391454c2d130a71c4c9f3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79756
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Enable x86_64 support for MRC.bin:
- Add a wrapper function for console printing that calls into
long mode to call native do_putchar
- Remove Kconfig guard for x86_64 when MRC is being used
Tested: Booted Lenovo X220 using mrc.bin under x86_64 and
MRC is able to print to the console.
Change-Id: I21ffcb5f5d4bf155593e8111531bdf0ed7071dfc
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Add another mode_switch assembly function to call x86_64 code from
x86_32 code. This is particullary useful for BLOBs like mrc.bin or
FSP that calls back into coreboot.
The user must first wrap all functions that are to be called from
x86_32 using the macro prot2lm_wrapper. Instead of using the original
function the wrapped functions must be passed to the x86_32 BLOBs.
The assembly code assume that 0-3 32bit arguments are passed to
the wrapped function.
Tested:
- Called x86_64 code from x86_32 code in qemu.
- Booted Lenovo X220 using x86_32 MRC using x86_64 console.
Change-Id: Ib625233e5f673eae9f3dcb2d03004c06bb07b149
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Drop the first argument specifying the number of arguments pushed
to the stack. Instead always push the 3 arguments to stack and use
the first one as function pointer to call while in protected mode.
While on it add more comments and simplify register restore code.
Tested:
- On qemu can call x86_32 function and pass argument and return
value.
- Booted Lenovo X220 in x86_64 mode using x86_32 MRC.
Change-Id: I30809453a1800ba3c0df60acd7eca778841c520f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79752
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use existing macro instead of open coding magic numbers.
No functionality change.
Change-Id: If45f7f3f2b4226cedde6ff91b9848b9875f45f9f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79148
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of using MSR IA32_PLATFORM_ID read the SystemAgent device id
to figure out the PC type. This follows the BWG which suggest to not
use MSR IA32_PLATFORM_ID for system identification.
Tested: Lenovo X220 still boots.
Change-Id: Ibddf6c75d15ca7a99758c377ed956d483abe7ec1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78826
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Now that those registers are only written once set the lock bit to
protect it from runtime changes.
TEST: Lenovo X220 still boots.
Change-Id: I4c56a3cb322a0e75eb3dd366808068093928e10c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
