Fix compilation under x86_64.
Tested on HP Z220:
* Still boots on x86_32.
Change-Id: I2a3ac3e44a77792eabb6843673fc6d2e14fda846
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44676
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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: I916dd8482d56c7509af9ad0d3b9c28bdc48fd0b1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Enable ASan in romstage for haswell as it has been tested on
Lenovo ThinkPad T440P.
Change-Id: I6eae242c71f41c9159658ae68d61b4036ad42d42
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44160
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
* Enable optional x86_64 romstage, postcar and ramstage
* Add Kconfig for x86_64 compilation
* Add documentation for x86 qemu mainboards
* Increase CAR stack as x86_64 uses more than 0x4000 bytes
Working:
* Boots to Linux
* Boots to SeaBIOS
* Drops to protected mode at end of ramstage
* Enumerates PCI devices
* Relocateable ramstage
* SMM
Change-Id: If2f02a95b2f91ab51043d4e81054354f4a6eb5d5
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29667
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When compiled in RAMSTAGE use the segments for ramstage.
Allows to call this assembly code in ramstage to exit long mode.
The next commit makes use of this.
Tested on qemu:
Still boots on x86_64.
Change-Id: I8beb31866bd15afc206b480b1ba05df995adc402
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44504
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The AM335X is a SoC, so should be in the soc tree.
This moves all the existing am335x code to soc/ and updates any
references. It also adds a soc.c file as required for the ramstage.
Change-Id: Ic1ccb0e9b9c24a8b211b723b5f4cc26cdd0eaaab
Signed-off-by: Sam Lewis <sam.vr.lewis@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44378
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Enable long mode in SMM handler.
x86_32 isn't affected by this change.
* Enter long mode
* Add 64bit entry to GDT
* Use x86_64 SysV ABI calling conventions for C code entry
* Change smm_module_params' cpu to size_t as 'push' is native integer
* Drop to protected mode after c handler
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Lenovo T410 with additional x86_64 patches.
Change-Id: I26300492e4be62ddd5d80525022c758a019d63a1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
The Allwinner code has been removed from the master branch for quite
some time now.
Change-Id: I9e5fd267140c180ae145d12b325cc489725f9ad0
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44316
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This CPU variant has a different CPUID signature.
Change-Id: Ice2c1b86382e5d91d9eda717e6522ed0a9c2229f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44248
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Xeon-SP Skylake Scalable Processor can have 36 CPU threads (18 cores).
Current coreboot SMM is unable to handle more than ~32 CPU threads.
This patch introduces a version 2 of the SMM module loader which
addresses this problem. Having two versions of the SMM module loader
prevents any issues to current projects. Future Xeon-SP products will
be using this version of the SMM loader. Subsequent patches will
enable board specific functionality for Xeon-SP.
The reason for moving to version 2 is the state save area begins to
encroach upon the SMI handling code when more than 32 CPU threads are
in the system. This can cause system hangs, reboots, etc. The second
change is related to staggered entry points with simple near jumps. In
the current loader, near jumps will not work because the CPU is jumping
within the same code segment. In version 2, "far" address jumps are
necessary therefore protected mode must be enabled first. The SMM
layout and how the CPUs are staggered are documented in the code.
By making the modifications above, this allows the smm module loader to
expand easily as more CPU threads are added.
TEST=build for Tiogapass platform under OCP mainboard. Enable the
following in Kconfig.
select CPU_INTEL_COMMON_SMM
select SOC_INTEL_COMMON_BLOCK_SMM
select SMM_TSEG
select HAVE_SMI_HANDLER
select ACPI_INTEL_HARDWARE_SLEEP_VALUES
Debug console will show all 36 cores relocated. Further tested by
generating SMI's to port 0xb2 using XDP/ITP HW debugger and ensured all
cores entering and exiting SMM properly. In addition, booted to Linux
5.4 kernel and observed no issues during mp init.
Change-Id: I00a23a5f2a46110536c344254868390dbb71854c
Signed-off-by: Rocky Phagura <rphagura@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43684
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With a CPUID of 10676, it is clearly model_1067x... Wait, it's already
there, but the comment is wrong. This ID isn't for Core Duo CPUs.
Change-Id: Ia4b73537805e2a8fa9e28bde76aa20a524f8f873
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Without this change, there will be no console output when using a
Crystal Well CPU.
Tested with i5-4570R (with LGA1150 mod) on ASRock H81M-HDS.
Change-Id: Id18645c52d9c4a4ea7acb602bcb39b796d9e24b9
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Kconfig lint tool checks for cases of the code using BOOL type
Kconfig options directly instead of with CONFIG() and will print out
warnings about it. It gets confused by these references in comments
and strings. To fix it so that it can find the real issues, just
update these as we would with real issues.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
It's not related to spinlocks and the actual implementation
was also guarded by CONFIG(SMP).
With a single call-site in x86-specific code, empty stubs
for other arch are currently not necessary.
Also drop an unused included on a nearby line.
Change-Id: I00439e9c1d10c943ab5e404f5d687d316768fa16
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43808
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Code has evolved such that there seems to be little
use for global definition of cbmem_top_chipset().
Even for AMD we had three different implementations.
Change-Id: I44805aa49eab526b940e57bd51cd1d9ae0377b4b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43326
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: I3fc616eeb975aae7a5937f8b555ae554010d8dd3
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43207
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: I16fe12368ce7ffe2fd4d2a5580dd92c19a695848
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: I76bf20bb2ec1cdd7ffee4430c80609978afaa1a4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43206
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Other platforms do this as well. It will ease refactoring on follow-ups.
Change-Id: I643982a58c6f5370c78acef93740f27df001a06d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
The "normalized" boot mode is only used in a single place, so there's no
need to use a variable. Also, reword the associated comment, which seems
to be unnecessarily vague: the hardcoded assumptions are inside the MRC.
Change-Id: I260d10f231f5de765d2675416d7047717d391d8f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
Enable long mode in SMM handler.
x86_32 isn't affected by this change.
As the rsm instruction used to leave SMM doesn't restore MSR registers,
drop back to protected mode after running the smi_handler and restore
IA32_EFER MSR (which enables long mode support) to previous value.
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Qemu Q35.
Change-Id: I8bba4af4688c723fc079ae905dac95f57ea956f8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35681
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Except for whitespace and varying casts the codes were
the same when implemented.
Platforms that did not implement this are tagged with
ACPI_NO_SMI_GNVS.
Change-Id: I31ec85ebce03d0d472403806969f863e4ca03b6b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The assumption up to this point was that if the system had an x86
processor, verstage would be running on the x86 processor. With running
verstage on the PSP, that assumption no longer holds true, so exclude
pieces of code that cause problems for verstage on the PSP.
This change will add these files to verstage only if the verstage
architecture is X86 - either 32 or 64 bit.
BUG=b:158124527
TEST=Build and boot on Trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I797b67394825172bd44ad1ee693a0c509289486b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42062
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Eric Peers <epeers@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most LAPIC registers are 32bit, and thus the use of long is valid on
x86_32, however it doesn't work on x86_64.
* Don't use long as it is 64bit on x86_64, which breaks interrupts
in QEMU and thus SeaBIOS wouldn't time out the boot menu
* Get rid of unused defines
* Get rid of unused atomic xchg code
Tested on QEMU Q35 with x86_64 enabled: Interrupts work again.
Tested on QEMU Q35 with x86_32 enabled: Interrupts are still working.
Tested on Lenovo T410 with x86_64 enabled.
Change-Id: Iaed1ad956d090625c7bb5cd9cf55cbae16dd82bd
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36777
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add a function to check if a region overlaps with SMM.
* Add a function to check if a pointer points to SMM.
* Document functions in Documentation/security/smm
To be used to verify data accesses in SMM.
Change-Id: Ia525d2bc685377f50ecf3bdcf337a4c885488213
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41084
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit aac79e0b8f.
Reason for revert: This massively slows down the boot process because
the LAPIC delivery mode for the APs is not set anymore. Plus, not all
review comments were fully addressed, yet this got merged in anyway.
Change-Id: If9bae6aae0d4d1f21b067a7d970975193c2b16d5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42166
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
When Linux is booted, the kernel reports
"do_IRQ: 1.55 No irq handler for vector"
So far it comes with payloads SeaBIOS and depthcharge, not with
Grub. We assume Grub does something to avoid this problem.
AMD bug tracker system (JIRA PLAT-21393) says the APs can not be set
EXTINT delivery mode.
In Intel 64 and IA-32 Architectures Software Developer’s Manual volume
3A, see chapter 10.5.1 Local Vector Table, it says:
"The APIC architecture supports only one ExtINT source in a system,
usually contained in the compatibility bridge. Only one processor in the
system should have an LVT entry configured to use the ExtINT delivery
mode."
Tested on mandolin (Picasso) board, the error in dmesg is gone.
The bug 153677727 has two parts.
1. Soft lockup
2. do_IRQ 1.55.
The soft lockup issued has been fixed by
https://review.coreboot.org/c/coreboot/+/41128
BUG=b:153677727
TEST=mandolin
Change-Id: I2956dcaad87cc1466deeca703748de33390b7603
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42219
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Attempts to write to APM_CNT IO port should always be guarded
with a test to verify SMI handler has been installed.
Immediate followup removes redundant HAVE_SMI_HANDLER tests.
Change-Id: If3fb0f1a8b32076f1d9f3fea9f817dd4b093ad98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41971
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The gm45 northbridge supports at most 4 threads. However, the only two
mobile Core 2 Quad models are not BGA956, so account for that as well.
Change-Id: Ie198ac4c366ec0bd53ddb337b6f9c03c331c73f5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Pineview has at most 4 threads.
Change-Id: I0f45f002d0bab0345bc061ac3c7a29237a536cc5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41843
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ULT only has 4 threads, but we are not changing it here to preserve
binary reproducibility.
Change-Id: I041c5dff2de514244f9c919c4c475cca979c34ce
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41842
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Arrandale CPUs have at most 4 threads.
Change-Id: Ifecbf5583011ff5e36c576d582a6276bc9b72803
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41840
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A looong time ago when cache_as_ram.S was built into romstage,
the stage was also linked twice. First at a fixed low address
and then again relocated at the final execute-in-place address.
Change-Id: Ic624feef6794f2c24e38459a45583d84fc07a484
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Patrick Rudolph