On older CPUs lacking ESRM (Enhanced Short Rep Mov) the rep stos
instructions are very slow. Since the MTRR that covers the SPI ROM
is disabled when setting up the NEM, the CPU will run with cache
disabled and is even slower.
The Sandy Bridge BWG and the Sandy Bridge UEFI reference code do not
disable the MTRR on the XiP, allowing the CPU to run at full speed
when setting up CAR. On UEFI the CAR is set up by touching each
cache-line once. It doesn't clear the CAR while doing so.
Do the same to speed up setting CAR:
- Invalidate the cache
- Enable the SPI ROM XiP MTRR
- Set CR0.CD=0
- Touch one spot in each cache-line
- Clear CAR after NEM has been set up
To ensure that the CAR MTRR area is 64-byte aligned add an ALIGN to
the linker script. All existing boards should use a 64-byte alignment
for CAR.
TEST=Booted on Lenovo X220 and measured with cbmem -t:
TODO: Test on platforms that have FSRM (Ivy Bridge and newer).
Before:
0:1st timestamp 1,083 (0)
11:start of bootblock 93,765 (92,681)
After:
0:1st timestamp 0
11:start of bootblock 24,027
Boots 69msec faster than before or about 4 times faster.
Change-Id: Ia8baef28fd736ef6bb02d8a100d752ac0392e1cf
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88792
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Cover the SPIROM with a temporary MTRR to speed up SPI flash accesses
after MPinit has removed the MTRR that was installed for postcar stage.
TEST=Booted on Lenovo X220 and measured using cbmem -t:
Before:
16:finished LZMA decompress (ignore for x86) 1,391,520 (366,351)
After:
16:finished LZMA decompress (ignore for x86) 1,218,418 (210,054)
Boots 156msec faster than before.
Change-Id: Ia3df06b5c2a09e05c76361f3e38be83475122ee7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88811
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The PCODE mailbox is primarily used by CPU code in ramstage. However,
it is also used as part of enabling DDR 2x refresh rate, which is now
implemented in coreboot as part of NRI (native RAM init).
The PCODE mailbox functions in CPU code were not exported at the time
NRI was being developed, so I chose to temporarily copy the functions
into NRI code to make it easier to rebase NRI patches since it avoids
potential merge conflicts. After a few years of rebasing patches, NRI
finally got submitted, so there's no reason to keep duplicate code in
the tree anymore.
Put the relevant PCODE functions into a new file, which gets compiled
for both ramstage (CPU init) and romstage (NRI). The BCLK calibration
function is only used in ramstage so there's no need to move it.
Change-Id: I340625fabc072139b8def254f1ce6b19f360adcd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Group entries by stage and sort groups by stage execution order.
Change-Id: I6e2a53d6555700b48fd3aececdfdb8983554a75a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
If the directory specified by CONFIG_CPU_INTEL_UCODE_SPLIT_BINARIES does
not contain any files, no build error will occur, and resulting coreboot
image will not include any microcode.
BUG=None
TEST="src/cpu/intel/microcode/Makefile.mk:16: *** "microcode-params is
empty. Ensure CONFIG_CPU_INTEL_UCODE_SPLIT_BINARIES is set correctly and
contains valid files.". Stop."
Change-Id: I095d9a24cb473b528d85bf8325c06fd3dc055b74
Signed-off-by: Simon Yang <simon1.yang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87636
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
The parameter CPU isn't used, thus drop it.
Change-Id: Ie7f6179f0545f905463752e94243b438143d8234
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87257
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
AMD64 spec refers to the field as MT (Message Type), but the IA64 spec
refers to it as DM (Delivery Mode). The problem is that there is another
field abbreviated as DM (Destination Mode) right next to it. So for
better readability, just stick to the AMD64 terminology.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I25cf69d555fe22526f128ff7ed41f82b71f2acf2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86683
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
haswell_is_ult() returns CONFIG(INTEL_LYNXPOINT_LP) which is a boolean,
so use boolean instead of int.
Change-Id: I3c98ee819fc937ed6da9ee1340c2af10cec19eb3
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84857
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
The x86 (AMD and Intel) spec defines it as Page-Map Level-4 Entry.
It is annoying when searching for the wrong abbreviation in the spec so
fix it everywhere it occurs.
source: Intel 64 spec April 2022 and AMD64 spec April 2024.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I730235beea69b3720f080bbade083c2eeed26587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86587
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Andy Ebrahiem <ahmet.ebrahiem@9elements.com>
Fix regression introduced in commit 0351872731
("arch/x86: Add breakpoint to stack canary").
romstage_main writes to the stack-canary, but since that's expected
temporarily disable the breakpoint. This only caused a warning on
platforms that do select IDT_IN_EVERY_STAGE, since those install the
stack canary breakpoint.
TEST: No more exceptions are printed in romstage when IDT_IN_EVERY_STAGE
is enabled.
Change-Id: I7ebf0a5e8eaad49af77ab4d5f6b58fc849013b14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As per commit 8651731537 ("sconfig: Move config_of_soc from device.h
to static.h") and commit 05a13e7ed9 ("sconfig: Move (WEAK_)DEV_PTR
from device.h to static.h"), sources that use code generated from the
devicetree should directly include static.h. This allows static.h to be
removed from device.h, eliminating many unnecessary dependencies on the
devicetree for objects that only need the device types and function
declarations.
Add static.h to the includes of all remaining files that require static
devicetree access through config_of_soc(), the sconfig generated names,
or DEV_PTR().
Change-Id: I1d35ff2ac22f9ff5e0aa38b7ad707619e50387f3
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84591
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Intel platform boot policy setting blob is linked into FIT table
as an FIT4 entry. It is required for server executing CBnT and/or
PFR without a PCH.
Please refer to chapter 4.6 of the document in below link:
https://www.intel.com/content/dam/www/public/us/en/documents/
guides/fit-bios-specification.pdf
Tool usage:
./util/cbfstool/ifittool -f <binary> -a -n <cbfs name> -t 4 \
-r COREBOOT -s <max table size>
Change-Id: I0f9fc61341430b1a35a44d50b108dcfaf31cd11c
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Signed-off-by: Li, Jincheng <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84305
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add socket types for LGA1700, LGA3647_1, LGA4189, LGA4677.
Select the socket type for different boards.
For the socket types which are not defined in SMBIOS type4,
CPU_INTEL_SOCKET_OTHER could be used.
Change-Id: Ida3315694f3ce397b9ad9d676d3195da5f096cb7
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83329
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>
Setting the clamp bit allows the CPU to operate below the highest
non-turbo frequency in order to obey the power limit.
Tested on ThinkPad T420 with the i7-3940XM.
Change-Id: Id0c0aedc29aca121d0fd1d8f8826089e13a026be
Signed-off-by: Anastasios Koutian <akoutian2@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
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 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>
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>
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>
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>
Write MSRs that are in scope package only once by checking for the BSP
bit. While this improves performance a bit it also has the benefit
that registers can be safely locked down without the need for
semaphores.
TEST: Lenovo X220 still boots.
Change-Id: I43f5d62d782466d2796c1df6015d43c0fbf9d031
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78607
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Report smbios_cpu_get_voltage() on Sandy Bridge as well.
Change-Id: I13ea930a58eaedc24d69fa3790f1f2a151558a80
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78432
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According the Intel Software Developer Manual,
CPUID.80000008H:EAX[15:8] reports the physical-address width supported
by the processor. Unfortunately, it does not necessarily reflect the
physical-address space the system can actulally use as some of those
bits can be reserved for internal hardware use.
It is critical for coreboot to know the actual physical address size.
Overestimating this size can lead to device resource overlaps due to
the hardware ignoring upper reserved bits. On rex for instance, it
creates some reboot hangs due to an overlap between thunderbolt and
Input Output Manager (IOM) address space.
As some SoCs, such as Meteor Lake, have physical address reserved bits
which cannot be probed at runtime, this commit introduces
`CPU_INTEL_COMMON_RESERVED_PHYS_ADDR_BITS' Kconfig to set the number
of physical address reserved bits at compilation time for those SoCs.
A runtime detection by hardware probing will be attempted if the value
is 0 (default).
BUG=b:288978352
Change-Id: I8748fa3e5bdfd339e973d562c5a201d5616f813e
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78451
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Having a CBFS cache scratchpad offers a generic way to decompress CBFS
files through the cbfs_map() function without having to reserve a
per-file specific memory region.
This commit introduces the x86 `PRERAM_CBFS_CACHE_SIZE' Kconfig to set
the pre-memory stages CBFS cache size. A cache size of zero disables
the CBFS cache feature. The default value is 16 KB which seems a
reasonable minimal value enough to satisfy basic needs such as the
decompression of a small configuration file. This setting can be
adjusted depending on the platform needs and capabilities.
We have set this size to zero for all the platforms without enough
space in Cache-As-RAM to accommodate the default size.
TEST=Decompression of vbt.bin in romstage on rex using cbfs_map()
Change-Id: Iee493f9947fddcc57576f04c3d6a2d58c7368e09
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77290
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When advertising C-state using the ACPI _CST object, make sure
to only advertise those that are supported by the CPU.
Downgrade if it's not and make sure to not advertise duplicate
states.
Add debug prints for the finally selected mapping of ACPI
C-state vs Intel CPU C-state.
Test: Tested on Lenovo X220.
All C-states are still advertised as all are supported.
Change-Id: Iaaee050e0ce3c29c12e97f5819a29f485a7946c2
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Make the code look like on newer platforms. This doesn't change
functionality.
Test: Lenovo X220 still boots and advertises all C-states as
before.
Change-Id: Ie7076d11720d55a4ac11318cbbdab9f75d08e15e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78193
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
According to the BWG C-states are processor specific
and BIOS must check if a C-state is supported at all.
Print the supported C-states in before ACPI _CNT generation.
Test: Tested on Lenovo X220 using Intel i5-2540M.
All C-states are reported as supported.
Change-Id: I713712a1a104714cbf3091782e564e7e784cf21d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78133
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes building lenovo/x200 with VBOOT.
All supported CPUs have enough L2 cache to support this.
Change-Id: Ifd6a16ce36c86349955cd7b7ddb3f74a19c17c4d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Since also some AMD CPUs have reserved physical address bits that can't
be used as normal address bits, introduce the
RESERVED_PHYSICAL_ADDRESS_BITS_SUPPORT Kconfig option which gets
selected by CPU_INTEL_COMMON, and use the new common option to configure
if the specific SoC/CPU code implements get_reserved_phys_addr_bits or
if the default of this returning 0 is used instead.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I0059e63a160e60ddee280635bba72d363deca7f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The number of physical address bits and reserved address bits shouldn't
ever be negative, so change the return type of cpu_phys_address_size,
get_reserved_phys_addr_bits, and get_tme_keyid_bits from int to unsigned
int.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9e67db6bf0c38f743b50e7273449cc028de13a8c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Varshit Pandya <pandyavarshit@gmail.com>
x86 pre-memory stages do not support the `.data` section and as a
result developers are required to include runtime initialization code
instead of relying on C global variable definition.
To illustrate the impact of this lack of `.data` section support, here
are two limitations I personally ran into:
1. The inclusion of libgfxinit in romstage for Raptor Lake has
required some changes in libgfxinit to ensure data is initialized at
runtime. In addition, we had to manually map some `.data` symbols in
the `_bss` region.
2. CBFS cache is currently not supported in pre-memory stages and
enabling it would require to add an initialization function and
find a generic spot to call it.
Other platforms do not have that limitation. Hence, resolving it would
help to align code and reduce compilation based restriction (cf. the
use of `ENV_HAS_DATA_SECTION` compilation flag in various places of
coreboot code).
We identified three cases to consider:
1. eXecute-In-Place pre-memory stages
- code is in SPINOR
- data is also stored in SPINOR but must be linked in Cache-As-RAM
and copied there at runtime
2. `bootblock` stage is a bit different as it uses Cache-As-Ram but
the memory mapping and its entry code different
3. pre-memory stages loaded in and executed from
Cache-As-RAM (cf. `CONFIG_NO_XIP_EARLY_STAGES`).
eXecute-In-Place pre-memory stages (#1) require the creation of a new
ELF segment as the code segment Virtual Memory Address and Load Memory
Address are identical but the data needs to be linked in
cache-As-RAM (VMA) but to be stored right after the code (LMA).
Here is the output `readelf --segments` on a `romstage.debug` ELF
binary.
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000080 0x02000000 0x02000000 0x21960 0x21960 R E 0x20
LOAD 0x0219e0 0xfefb1640 0x02021960 0x00018 0x00018 RW 0x4
Section to Segment mapping:
Segment Sections...
00 .text
01 .data
Segment 0 `VirtAddr` and `PhysAddr` are at the same address while they
are totally different for the Segment 1 holding the `.data`
section. Since we need the data section `VirtAddr` to be in the
Cache-As-Ram and its `PhysAddr` right after the `.text` section, the
use of a new segment is mandatory.
`bootblock` (#2) also uses this new segment to store the data right
after the code and load it to Cache-As-RAM at runtime. However, the
code involved is different.
Not eXecute-In-Place pre-memory stages (#3) do not really need any
special work other than enabling a data section as the code and data
VMA / LMA translation vector is the same.
TEST=#1 and #2 verified on rex and qemu 32 and 64 bits:
- The `bootblock.debug`, `romstage.debug` and
`verstage.debug` all have data stored at the end of the `.text`
section and code to copy the data content to the Cache-As-RAM.
- The CBFS stages included in the final image has not improperly
relocated any of the `.data` section symbol.
- Test purposes global data symbols we added in bootblock,
romstage and verstage are properly accessible at runtime
#3: for "Intel Apollolake DDR3 RVP1" board, we verified that the
generated romstage ELF includes a .data section similarly to a
regular memory enabled stage.
Change-Id: I030407fcc72776e59def476daa5b86ad0495debe
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
On Intel SoCs, if TME is supported, TME key ID bits are reserved and
should be subtracted from the maximum physical addresses available.
BUG=288978352
TEST=Verified that DMAR ACPI table `Host Address Width` field on rex
went from 45 to 41.
Signed-off-by: Cliff Huang <cliff.huang@intel.com>
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Change-Id: I9504a489782ab6ef8950a8631c269ed39c63f34d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
It makes the detection of this feature accessible without the
CONFIG_SOC_INTEL_COMMON_BLOCK_CPU dependency.
BUG=288978352
TEST=compilation
Change-Id: I005c4953648ac9a90af23818b251efbfd2c04043
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77697
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the cpu directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I3033f2a9eebc75220f7666325857b3ddd60c8f75
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68979
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The prefix POSTCODE makes it clear that the macro is a post code.
Hence, replace related macros starting with POST to POSTCODE and
also replace every instance the macros are invoked with the new
name.
The files was changed by running the following bash script from the
top level directory.
header="src/soc/amd/common/block/include/amdblocks/post_codes.h \
src/include/cpu/intel/post_codes.h \
src/soc/intel/common/block/include/intelblocks/post_codes.h"
array=`grep -r "#define POST_" $header | \
tr '\t' ' ' | cut -d ":" -f 2 | cut -d " " -f 2`
for str in $array; do
splitstr=`echo $str | cut -d '_' -f2-`
grep -r $str src | cut -d ':' -f 1 | \
xargs sed -i'' -e "s/$str/POSTCODE_$splitstr/g"
done
Change-Id: Id2ca654126fc5b96e6b40d222bb636bbf39ab7ad
Signed-off-by: Yuchen He <yuchenhe126@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76044
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
