Using cb_err as return type clarifies the meaning of the different
return values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I95f36ba628c7f3ce960a8f3bda730d1c720253cc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We now pre-populate cpu_info before jumping to the C handler. We no
longer need this parameter.
I moved the stack alignment closer to the actual invocation of the C
handler so it's easier to reason about.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS and verify all CPUs still function
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8997683b6613b7031784cabf7039a400f0efdea1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58147
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This will reduce the number of AP init paths we need to support.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS and see all CPUs initialized correctly
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I05beb591bd7b3a26b6c51c10d4ffd6f8621c12eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
There are two possible code sections where the cpu_info macros can be
included: .code32 and .code64
Doing a `push %eax` while in a .code64 section will result in a compiler
error. This macro manually pushes the 32-bit register onto the stack so
we can share the code between 32 and 64 bit builds.
We also can't implicitly dereference per_cpu_segment_selector because
it's a 32-bit address. Trying to do this results in the following:
E: Invalid reloc type: 11
E: Illegal use of 32bit sign extended addressing at offset 0x1b2
If we load the address first, then dereference it, we can work around
the limitation.
With these fixes, 64-bit builds can now use CPU_INFO_V2.
BUG=b:179699789
TEST=Boot qemu 64 bit build with CPU_INFO_V2 and 4 CPUs. See AP init
work as expected.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I4e72a808c9583bb2d0f697cbbd9cb9c0aa0ea2dc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
When CONFIG_X86_AMD_INIT_SIPI was set, the second/final SIPI that
afterwards checks if all APs have checked in was skipped and if it got
so far, start_aps returned CB_SUCCESS despite not having checked if all
APs had checked in after the SIPI. This patch makes start_aps skip the
first SIPI in the CONFIG_X86_AMD_INIT_SIPI case so we use the proper
timeouts and error handling for the final and this case only SIPI and
signal the caller an error when not all APs have checked in after the
SIPI.
A timeless build for lenovo/x230 which is a mainboard that doesn't
select X86_AMD_INIT_SIPI results in identical binary, so this doesn't
change the behavior of the !X86_AMD_INIT_SIPI case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I39438229497c5d9c44dc7e247c7b2c81252b4bdb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Using cb_err as return type clarifies the meaning of the different
return values.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Icb96f28b4d59b3d00638a43c927df80f5d1643f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58455
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since during AP startup it's not guaranteed that no AP console output
will be printed between consecutive printk calls in send_sipi_to_aps,
add a new line character to all printks to make sure to have the outputs
from the APs on separate lines. For consistency also add a final new
line character to the printk call in start_aps.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3983b8a0e6b272ba5fb2a90a108d17a0c480c8b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58454
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Apart from the SIPI number in the debug message the two instances of the
SIPI sending code in start_aps are identical, so factor it out into a
new send_sipi_to_aps function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I6a921b81fce77fbf58c7ae3b50efd8c3e6e5aef3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58453
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using types.h as include instead of stddef.h and stdint.h will also
provide commonlib/bsd/cb_err.h which will be used in follow-up patches.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I08a68dc827d60c6c9a27b3ec8b74b9c8a2c96d12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58452
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the `get_cst_entries()` function provide a read-only pointer. Also,
constify the actual data where applicable.
Change-Id: Ib22b3e37b086a95af770465a45222e9b84202e54
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The push/pop of %ebx was only added because smm_stub saves the canary
value in it. Now that we no longer use cpu_info in smm, we no longer
need to save the register.
BUG=b:179699789
TEST=Boot guybrush to the OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I554dbe016db8b1c61246c8ffc7fa252b2542ba92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Now that cpu_info() is no longer used by COOP_MULTITASKING, we no
longer need to set up cpu_info in SMM. When using CPU_INFO_V2, if
something does manage to call cpu_info() while executing in SMM mode,
the %gs segment is disabled, so it will generate an exception.
BUG=b:179699789
TEST=Boot guybrush to OS with threads enabled
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Id64f32cc63082880a92dab6deb473431b2238cd0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
We only ever start and execute threads on the BSP. By explicitly
checking to see if the CPU is the BSP we can remove the dependency on
cpu_info. With this change we can in theory enable threads in all
stages.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS and verify coop multithreading still works
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iea4622d52c36d529e100b7ea55f32c334acfdf3e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58199
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For older CPU models where CPUID leaf 0xb is not supported, use
initial LAPIC ID from CPUID instead of LAPIC register space to
to detect if logical CPU is a hyperthreading sibling. The one
in LAPIC space is more complex to read, and might not reflect
CPU topology as it can be modified in XAPIC mode.
Change-Id: I8c458824db1ea66948126622a3e0d0604e391e4b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
It is not a requirement to have X2APIC mode enabled to use
CPUID leaf 0xb EDX to detect logical CPU is a hyperthreading
sibling.
Change-Id: I288f2df5a392c396f92bb6d18908df35de55915d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Remove code, which was only needed for B and C2 stepping
of P54C. The linux kernel source has commentary on X86_BUG_11AP:
* See if we have a good local APIC by checking for buggy Pentia,
* i.e. all B steppings and the C2 stepping of P54C when using their
* integrated APIC (see 11AP erratum in "Pentium Processor
* Specification Update")
Change-Id: Iec10335f603674bcef2e7494831cf11200795d38
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
ExtINT is related to external PIC mode i8259 interrupts,
they should be delivered to one CPU (BSP) only.
Change-Id: I78490d2cbe3d9f52e10ef2471508263fd6c146ba
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42434
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Set PKG_CST_CONFIG_CONTROL MSR bit 15 to make bits 15:0 read-only.
Change-Id: Ieb740aa94255cb3c23a56495c4b645d847637b7f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The bits REMOTE_IRR and SEND_PENDING are documented as read-only,
and reserved bits should not be modified either.
Change-Id: I6bcb9eb990debe169340a0bfe662158b62a8f4dc
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55700
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The bit LAPIC_SPIV_ENABLE returns 0 after reset even though
LAPIC has not been temporarily disabled.
Change-Id: Id261bc68fe9d1b1b0e5a3ef599a8f33a686d283b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Only the enable_lapic() part is required while doing
SMP init. Also disable_lapic() must not be called if
we rely on LAPIC for timer source.
Change-Id: Ib5e37c1a0a91fa4e9542141aa74f1c1876fee94e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Make use of the newly introduced ACPI macros for CPPC table generation
that currently exists of a bunch of confusing assignments of structs
that only get partially filled.
Test: dumped SSDT before and after do not differ.
Change-Id: I844d191b1134b98e409240ede71e2751e51e2159
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57888
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Lance Zhao
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
There is currently a fundamental flaw in the current cpu_info()
implementation. It assumes that current stack is CONFIG_STACK_SIZE
aligned. This assumption breaks down when performing SMM relocation.
The first step in performing SMM relocation is changing the SMBASE. This
is accomplished by installing the smmstub at 0x00038000, which is the
default SMM entry point. The stub is configured to set up a new stack
with the size of 1 KiB (CONFIG_SMM_STUB_STACK_SIZE), and an entry point
of smm_do_relocation located in RAMSTAGE RAM.
This means that when smm_do_relocation is executed, it is running in SMM
with a different sized stack. When cpu_info() gets called it will be
using CONFIG_STACK_SIZE to calculate the location of the cpu_info
struct. This results in reading random memory. Since cpu_info() has to
run in multiple environments, we can't use a compile time constant to
locate the cpu_info struct.
This CL introduces a new way of locating cpu_info. It uses a per-cpu
segment descriptor that points to a per-cpu segment that is allocated on
the stack. By using a segment descriptor to point to the per-cpu data,
we no longer need to calculate the location of the cpu_info struct. This
has the following advantages:
* Stacks no longer need to be CONFIG_STACK_SIZE aligned.
* Accessing an unconfigured segment will result in an exception. This
ensures no one can call cpu_info() from an unsupported environment.
* Segment selectors are cleared when entering SMM and restored when
leaving SMM.
* There is a 1:1 mapping between cpu and cpu_info. When using
COOP_MULTITASKING, a new cpu_info is currently allocated at the top of
each thread's stack. This no longer needs to happen.
This CL guards most of the code with CONFIG(CPU_INFO_V2). I did this so
reviewers can feel more comfortable knowing most of the CL is a no-op. I
would eventually like to remove most of the guards though.
This CL does not touch the LEGACY_SMP_INIT code path. I don't have any
way of testing it.
The %gs segment was chosen over the %fs segment because it's what the
linux kernel uses for per-cpu data in x86_64 mode.
BUG=b:194391185, b:179699789
TEST=Boot guybrush with CPU_INFO_V2 and verify BSP and APs have correct
%gs segment. Verify cpu_info looks sane. Verify booting to the OS
works correctly with COOP_MULTITASKING enabled.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I79dce9597cb784acb39a96897fb3c2f2973bfd98
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5b8ecdfe75d99028fee820a2034466a8ad1c5e63
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58080
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The %fs and %gs segment are typically used to implement thread local
storage or cpu local storage. We don't currently use these in coreboot,
so there is no reason to map them. By setting the segment index to 0,
it disables the segment. If an instruction tries to read from one of
these segments an exception will be raised.
The end goal is to make cpu_info() use the %gs segment. This will remove
the stack alignment requirements and fix smm_do_relocation.
BUG=b:194391185, b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iaa376e562acc6bd1dfffb7a23bdec82aa474c1d5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This will help reduce duplication and make it easier to add new members
to the cpu_info struct.
BUG=b:194391185, b:179699789
TEST=Compare assembly of romstage and ramstage before and after
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I31f264f4bb8b605fa3cb3bfff0d9bf79224072aa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
It took me a while to understand the SMM set up flow. This adds a
clarifying comment.
BUG=b:194391185, b:179699789
TEST=None
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I9c73e416b8c583cf870e7a29b0bd7dcc99c2f5f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57858
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Including arch/cpu.h is needed to have the declaration for cpuid_eax.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ic22aba062117e3afa818fa2fc39cb0738e6a1612
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The code under `cpu/x86/tsc` is only compiled in when its `Makefile.inc`
is included from platform (CPU/SoC) code and the `UDELAY_TSC` Kconfig
option is enabled.
Include `cpu/x86/tsc/Makefile.inc` once from `cpu/x86/Makefile.inc` and
drop the now-redundant inclusions from platform code. Also, deduplicate
the `UDELAY_TSC` guards.
Change-Id: I41e96026f37f19de954fd5985b92a08cb97876c1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57456
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures mp_run_on_all_aps() is passing 'MP_RUN_ON_ALL_CPUS'
macro rather hardcoding `0` while running `func` on all APs.
Change-Id: Icd34371c0d4349e1eefe945958eda957c4794707
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
IDS (Integrated Debug Services) options are meant to be enabled when one
wants to debug AGESA. Since they are compile-time options, using Kconfig
is the logical choice. Currently, none of the options builds.
Tested with BUILD_TIMELESS=1 without adding the configuration options
into the binary, and Asus A88XM-E does not change.
Change-Id: I465627c19c9856e58ca94aa0efedbddb6baaf3f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53985
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Since current AMD SoCs don't need some wait time between INIT and SIPI,
we can skip the 10ms wait there, which improves the boot time a bit.
before: CPU_CLUSTER: 0 init finished in 632 msecs
after: CPU_CLUSTER: 0 init finished in 619 msecs
mpinit still works on Mandolin and all CPU cores show up and are usable.
This also doesn't change the binary in a timeless build for boards/SoCs
that don't select X86_AMD_INIT_SIPI which I verified for lenovo/x230.
BUG=b:193885336
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I1e044776f45021742a88a5e369a74383c1baaab6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
The alignment for `struct cpu_info` is wrong on x86_64. c_start.S uses
the `push` instruction when setting up the cpu_info struct. This
instruction will push 8 bytes but `unsigned int` is 4 bytes. By making
it a `size_t` we get the correct size for both x86_32 and x86_64.
BUG=b:179699789
TEST=Boot guybrush to the OS
Suggested-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I8ef311aaa8333ccf8a5b3f1f0e852bb26777671c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56573
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive, and make it constant.
In the case of Intel model 2065x the mca_get_bank_count() call replaces
a magic number.
Change-Id: I245b15f57e77edca179e9e28965383a227617174
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56244
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When accessing the MCA MSRs, the MCA bank number gets multiplied by 4
and added to the IA32_MC0_* define to get the MSR number. Add a macro
that already does this calculation to avoid open coding this repeatedly.
Change-Id: I2de753b8c8ac8dcff5a94d5bba43aa13bbf94b99
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56243
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the common mca_get_bank_count function instead of open-coding the
functionality to get the MCA bank number. Also re-type the num_banks
variable from signed in to unsigned int, since the number of MCA bank is
always positive.
Change-Id: I70ad423aab484cf4ec8f51b43624cd434647aad4
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56184
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Commit 1aa60a95bd broke microcode loading for chipsets that have a
microcode blob with a total_size field set to 0. This appears to be
support for older chipsets, where the size was set to 0 and assumed to
be 2048 bytes. The fix is to change the result of the subtraction to a
signed type, and ensure the following comparison is done without
promoting the signed type to an unsigned one.
Resolves: https://ticket.coreboot.org/issues/313
Change-Id: I62def8014fd3f3bbf607b4d58ddc4dca4c695622
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56153
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Stefan Ott <coreboot@desire.ch>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add IFITTOOL as a dependency where needed and remove where it is
unneeded.
Change-Id: I88c9fc19cca0c72e80d3218dbcc76b89b04feacf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Allow to compile the experimental x86_64 code.
Tested on Lenovo Thinkpad T410.
Hangs in SMM relocation. When skipped boots into GNU/Linux.
Change-Id: I60f2fccba357cb5fb5d85feb4ee8d02abfe6bc7e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45699
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
On x86_64, the default heap size is too small when using 32 CPUs.
Change-Id: Ib4f770a7a54d975d213b2456cc7d1ed9151cb6f9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Introduce `USE_EXP_X86_64_SUPPORT` in `src/arch/x86/Kconfig` and guard
it with `HAVE_EXP_X86_64_SUPPORT`. Replace the per-CPU implementations
of the same functionality with the newly-added Kconfig options. Update
documentation and the config file for QEMU accordingly.
Change-Id: I550216fd2a8323342d6b605306b0b95ffd5dcd1c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Introduce the `ARCH_ALL_STAGES_X86` Kconfig symbol to automatically
select the per-stage arch options. Subsequent commits will leverage
this to allow choosing between 32-bit and 64-bit coreboot where all
stages are x86. AMD Picasso and AMD Cezanne are the only exceptions
to this rule: they disable `ARCH_ALL_STAGES_X86` and explicitly set
the per-stage arch options accordingly.
Change-Id: Ia2ddbae8c0dfb5301352d725032f6ebd370428c9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
