For arch/x86 the realmode part has to be located within the same 64
KiB as the reset vector. Some older intel platforms also require 4 KiB
alignment for _start16bit.
To enforce the above, and to separate required parts of .text without
matching *(.text.*) rules in linker scripts, tag the pre-C environment
assembly code with section .init directive.
Description of .init section for ELF:
This section holds executable instructions that contribute to the
process initialization code. When a program starts to run, the
system arranges to execute the code in this section before calling the
main program entry point (called main for C programs).
Change-Id: If32518b1c19d08935727330314904b52a246af3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is just to ease merging with Broadwell.
Tested with BUILD_TIMELESS=1, Asrock B85M Pro4 remains identical.
Change-Id: I9239489fe48f04714e6626b57ef07ca8b3013024
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46910
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since there's only one set of values, the if-clause is unnecessary.
Change-Id: I2fb4582377fe2f204d2cee0dc513a4d5d24feabe
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
They aren't specific to AC power operation anymore. Also adapt autoport.
Change-Id: Ib04d0a08674b7d2773d440d39bd6dfbd4359e0fb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49089
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All mainboards use the same values for AC and battery, even desktop
boards without a battery. Use the AC values everywhere and drop the
battery values. Subsequent commits will rename the AC power options
accordingly, and will also clean up the corresponding acpigen code.
This is intentional so as to ease reviewing the devicetree changes.
Also update util/autoport accordingly.
Change-Id: I581dc9b733d1f3006a4dc81d8a2fec255d2a0a0f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It is not used anywhere. Drop it.
Change-Id: I92a72a46db237cf855491a664cdfadca34306f6c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49087
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All platforms moved to initialise GNVS at the time
of SMM module loading.
Change-Id: I31b5652a946b0d9bd1909ff8bde53b43e06e2cd9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48699
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Sandy Bridge steppings appear in the BWG, and Ivy Bridge steppings
appear in reference code. Add them for the sake of completeness.
Change-Id: I7d17cdd04a771ca319c908fc757f868e95ea7944
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48410
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The steppings correspond to the CPUID bits 3:0, so move them to the CPU
scope, and include the CPU header from files using the stepping macros.
Change-Id: Idf8fba4911f98953bb909777aea57295774d8400
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48409
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Followup work forces gdtptr and gdt towards the top of
bootblock. They need to be realmode-addressable, i.e.
within top 64 KiB or same segment with .reset.
Change-Id: Ib6f23b2808d0a7e0d277d00a9b0f30c49fdefdd5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47965
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
We have identical gdtptr16 and gdtptr. The reference in
gdtptr_offset calculation is not accounted for when
considering --gc-sections, so to support linking
gdt_init.S separately add dummy use of gdtptr symbol.
Realmode execution already accessed gdt that was located
outside [_start16bit,_estart16bit] region. Remove latter
symbol as the former was not really a start of region,
but entry point symbol.
With the romcc bootblock solution, entry32.inc may have
been linked into romstage before, but the !ENV_BOOTBLOCK
case seems obsolete now.
Change-Id: I0a3f6aeb217ca4e38b936b8c9ec8b0b69732cbb9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47964
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Packing bootblock sections is somewhat easier to understand
when these all appear in one .ld file.
Change-Id: Ie8629a89fa47a28db63ecc33c631b29ac5a77448
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47597
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Do not combine the host bridge device ID with the CPU stepping because
it is confusing. Although Sandy/Ivy Bridge processors incorporate both
CPU and northbridge components into the same die, it is best to treat
them separately. Plus, this change enables moving CPU stepping macros
from northbridge code into the CPU scope, which is done in a follow-up.
Change-Id: I27ad609eb53b96987ad5445301b5392055fa4ea1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Since most assembly files are no longer concatenated together
but built separately, section changes with .previous at the
end of the files have become spurious.
TEST=BUILD_TIMELESS
Change-Id: I2970eed2b114a53475ba385eec4e97bb7ae7095c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47963
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This adds a helper function for long mode to call some code in protected
mode and return back to long mode.
The primary use case is to run binaries that have been compiled for
protected mode, like the FSP or MRC binaries.
Tested on Intel Skylake. The FSP-M runs and returns without error while
coreboot runs in long mode.
Change-Id: I22af2d224b546c0be9e7295330b4b6602df106d6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48175
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This makes it possible to select both the legacy LAPIC AP init or the
newer parallel MP init.
Tested on i440fx with -smp 32.
Change-Id: I007b052ccd3c34648cd172344d55768232acfd88
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
CONFIG_MAX_CPUS=4 is the maximum supported with SMM_ASEG.
TESTED: on q35 and i440fx -smp 4/32.
Change-Id: I696856870e34e7a7ad580bc83c6b38f1dfb4511d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Adapt the old lapic init code for x86_64.
Change-Id: I5128ed574323025e927137870fb10b23d06bc01d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Qemu i440fx does not support an smihandler at the moment.
Change-Id: I5526b19b8294042a49e5bca61036e47db01fd28a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On x86_64 the cannary is 8 bytes in size, so write the additional
4 bytes to make SMM handler happy.
Tested on Intel Skylake in long mode. No longer dies in SMM.
Change-Id: Id805c65717ec22f413803c21928d070602522b2c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48215
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The previous code was crashing when jumping back to ramstage, now it
works. The GDT is now using the same values as the other ones in
coreboot.
Change-Id: Id00467d9d8a4138ddea73adbda4b39f12def583f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48214
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allows to compile the file under x86_64 without errors.
The caller has to make sure to call the functions while in protected
mode, which is usually the case in early bootblock.
Change-Id: Ic6601e2af57e0acc6474fc3a4297e3d2281decd6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48165
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Allows to compile the file under x86_64 without errors.
The caller has to make sure to call the functions while in protected
mode, which is usually the case in early bootblock.
Change-Id: Ic6d98febb357226183c293c11ba7961f27fac40c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48164
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enter long mode on secondary APs.
Tested on Lenovo T410 with additional x86_64 patches.
Tested on HP Z220 with additional x86_64 patches.
Still boots on x86_32.
Change-Id: I53eae082123d1a12cfa97ead1d87d84db4a334c0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This can be done using in the INTERMEDIATE target in the proper place.
Change-Id: I28a7764205e0510be89c131058ec56861a479699
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46453
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce a weak function to let the platform code provide the processor
voltage in 100mV units.
Implement the function on Intel platforms using the MSR_PERF_STATUS msr.
On other platforms the processor voltage still reads as unknown.
Tested on Intel CFL. The CPU voltage is correctly advertised.
Change-Id: I31a7efcbeede50d986a1c096a4a59a316e09f825
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
One mainboard using this socket has less than 20 bytes of space left in
its bootblock, hindering development. Double the bootblock size to solve
the problem.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I620c13eab53c3326a4f4660b63ed1dd0fc81f563
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47585
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It was supposed to return true for both S2 and S3, but
level S2 was never stored in acpi_slp_type or otherwise
implemented.
Change-Id: Ida0165e647545069c0d42d38b9f45a95e78dacbe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This partially reverts commit 67910db907.
The symbol X86_RESET_VECTOR continues to live, for the time being,
under soc/amd/picasso.
Change-Id: Ib6b2cc2b17133b3207758c72a54abe80fc6356b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reusing the 'size' variable for a different purpose later on in the
function makes the code harder to read.
Change-Id: Iceb10aa40ad473b41b7da0310554725585e3c2c2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
If the stub size would be larger than the save state size, the stagger
points would overlap with the stub.
The check is placed in the stub placement code. The stub placement
code is called twice. Once for the initial SMM relocatation and for
the permanent handler in TSEG. So the check is done twice, which is
not really needed.
Change-Id: I253e1a7112cd8f7496cb1a826311f4dd5ccfc73a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47069
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It is too easy to confuse those with IA32_SMRR_PHYS_x registers.
Change-Id: Ice02ab6c0315a2be14ef110ede506262e3c0a4d5
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46896
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Actual support CBnT will be added later on.
Change-Id: Icc35c5e6c74d002efee43cc05ecc8023e00631e0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46456
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Calculate the frequencies based on the appropriate MSRs and pass them to
SMBIOS tables generator. Ivybridge microarchitecture does not yet
implement CPUID 16H leaf used to obtain the required frequencies.
TEST=Intel Core i7-3770, TianoCore UEFI payload displays the CPU
frequency correctly equal 3.4GHz in Boot Manager Menu, dmidecode shows
correct frequencies according to Intel ARK, 3.4GHz base and 3.9GHz turbo
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: Iefbae6111d39107eacac7e61654311646c6981eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently coreboot has limited use for the SMM save state. Typically
the only thing needed is to get or set a few registers and to know
which CPU triggered the SMI (typically via an IO write). Abstracting
away different SMM save states would allow to put some SMM
functionality like the SMMSTORE entry in common places.
To save place platforms can select different SMM save sate ops that
should be implemented. For instance AMD platforms don't need Intel SMM
save state handling.
Some platforms can encounter CPUs with different save states, which
the code then handles at runtime by comparing the SMM save state
revision which is located at the same offset for all SMM save state
types.
Change-Id: I4a31d05c09065543424a9010ac434dde0dfb5836
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44323
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The SMM_ASEG code only supports up to 4 CPUs, so assert this at
buildtime.
Change-Id: I8ec803cd1b76f17f4dccd5c573179d542d54c277
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The ASEG smihandler bails out if an unsupported SMM save state
revision is detected. Now we have code to find the SMM save state
depending on the SMM save state revision so reuse this to do the same.
This also increases the loglevel when bailing out of SMM due to
unsupported SMM save state revision from BIOS_DEBUG to BIOS_WARNING,
given that the system likely still boots but won't have a functioning
smihandler.
Change-Id: I57198f0c85c0f7a1fa363d3bd236c3d41b68d2f0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Fix compilation on x86_64.
Tested on HP Z220:
* Still boots on x86_32.
Change-Id: Id7190d24172803e40acaf1495ce20f3ea38016b0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44675
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Use heap for linker script calculated constant to fix relocation
symbols in mixed assembly code.
Tested on HPZ220:
* Still boots in x86_32.
Tested on Lenovo T410:
* Doesn't need the MMX register fix in long mode.
Change-Id: I3e72a0bebf728fb678308006ea3a3aeb92910a84
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This allows for ccopts symbols and preprocessor to be used inside the
smm.ld linker script.
Change-Id: I4262c09ca52c1fca43c1c115530efe489a722c32
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44321
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clarify what the function does by renaming it from do_lapic_init() to
lapic_virtual_wire_mode_init().
Change-Id: Ie4430bf0f6c6bf0081b6aaeace351092bcf7f4ac
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47020
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested with BUILD_TIMELESS=1, Google Wolf does not change.
Change-Id: I029ab0dccbf7b61d641cccf79b491fabf97ab74a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46720
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
