Both the HPET_BASE_ADDRESS define from arch/x86/include/arch/hpet.h and
the HPET_ADDRESS Kconfig option define the base address of the HPET MMIO
region which is 0xfed00000 on all chipsets and SoCs in the coreboot
tree. Since these two different constants are used in different places
that however might end up used in the same coreboot build, drop the
Kconfig option and use the definition from arch/x86 instead. Since it's
no longer needed to check for a mismatch of those two constants, the
corresponding checks are dropped too.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia797bb8ac150ae75807cb3bd1f9db5b25dfca35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62307
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Lance Zhao
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All x86 chipsets and SoCs have the HPET MMIO base address at 0xfed00000,
so define this once in arch/x86 and include this wherever needed. The
old AMD AGESA code in vendorcode that has its own definition is left
unchanged, but sb/amd/cimx/sb800/cfg.c is changed to use the new common
definition.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ifc624051cc6c0f125fa154e826cfbeaf41b4de83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62304
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Some Intel southbridges have HPET_MIN_TICKS in their Kconfig files, but
the CONFIG_HPET_MIN_TICKS symbol is used in the common acpi code in
acpi/acpi.c, so define this option in arch/x86/Kconfig to have it
defined in all cases where the function that ends up using this
information gets called. Since we now have the type information for this
Kconfig option in a central place, it can be dropped from the Kconfig
file of the Intel southbridges that change the default value.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ibe012069dd4b51c15a8fbc6459186ad2ea405a03
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62298
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit b433d26ef1 (arch/x86: Define
HPET_ADDRESS_OVERRIDE) added this Kconfig option and referenced the
via/cx700 chipset which has been dropped before the 4.9 release. No SoC
in the current tree selects HPET_ADDRESS_OVERRIDE and all SoCs have
their HPET mapped at 0xfed00000, so drop this unused and no longer
needed Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4021ed6f84473c7a9223323fc8aa5d3f935d8084
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62276
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 0e688b113d (arch/x86/id.S: Fix
building with clang) broke building with GCC 8.3 so this approach
should work for both GCC 8.3 and clang. The clang error is:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Change-Id: Ide3d313800641d4d9b5f79127f84d9fdb4ec2b96
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
This reverts commit 0e688b113d.
Reason for revert: Breaks building with GCC 8.3 which is currently
needed to build bootable coreboot images for Ironlake boards:
src/arch/x86/id.S: Assembler messages:
src/arch/x86/id.S:14: Error: value of 4294967344 too large for field of 4 bytes at 48
src/arch/x86/id.S:15: Error: value of 4294967327 too large for field of 4 bytes at 52
src/arch/x86/id.S:16: Error: value of 4294967318 too large for field of 4 bytes at 56
Change-Id: I9e13b15c062bc6598717382b1fedfa120c6d7209
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61926
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
The following error message is now gone:
CC bootblock/arch/x86/id.o
/tmp/id-35b17a.s:35:7: error: expected relocatable expression
.long - ver
^
/tmp/id-35b17a.s:36:7: error: expected relocatable expression
.long - vendor
^
/tmp/id-35b17a.s:37:7: error: expected relocatable expression
.long - part
^
Tested with BUILD_TIMELESS=1 on x86_32 with gcc. The binary stays the
same.
Change-Id: I930e7b96c4428bcb95ff1903e6a3e7679171ffee
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
It's available in %r3 in bootblock and needs to be passed to payload in
%r27. We use one of two hypervisor's special registers as a buffer,
which aren't used for anything by the code.
Change-Id: I0911f4b534c6f8cacfa057a5bad7576fec711637
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
"hb-mode" is a -machine flag for QEMU. "hb" stands for Hostboot, which
is OpenPower firmware created by IBM.
QEMU for PPC64 can run initial program in two different modes:
* hb-mode=off with load address 0x00000000
* hb-mode=on with load address 0x08000000
Real hardware always loads firmware at 0x08000000 and coreboot shouldn't
require a special build to be run on QEMU.
Memory layout is updated to reflect change of load address.
Change-Id: I1bdc97a095bd46fccc862985b3bd24f4fa5bc054
Signed-off-by: Yaroslav Kurlaev <yaroslav.kurlaev@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
BSS is loaded as part of the bootblock, it is zeroed in the file so it
doesn't have to be cleared explicitly by the code.
Code for clearing is left as a comment along with a warning about alignment
requirements.
Vector operations are sometimes generated for code such as
'uint8_t x[32] = {0}', this results in an exception when vector registers
(VR) are not enabled. VSR (vector-scalar register) operations are also
enabled, there is no reason not to.
Change-Id: I878ef61619eb4a191805c8911d001312a0d717a0
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57076
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Each time the spinlock is acquired a byte is decreased and then the
sign of the byte is checked. If there are more than 128 cores the sign
check will overflow. An easy fix is to increase the word size of the
spinlock acquiring and releasing.
TEST: See that serialized SMM relocation is still serialized on
systems with >128 cores.
Change-Id: I76afaa60669335090743d99381280e74aa9fb5b1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60539
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to util/kbc1126/README.md, for these ECs to work, the
address and size of their two firmware should be written to $s-0x100`
(`$s` means the image size, done with kbc1126_ec_insert), which means
that every existing section (especially those used to store code)
should not overlap this address, otherwise the bootblock will get
damaged when inserting firmwares of the EC.
In this commit, ecfw_ptr is a structure initialized at build time
according to CONFIG_KBC1126_FW1_OFFSET and CONFIG_KBC1126_FW2_OFFSET
(to do so, they should be redefined as hex), and linked to
CONFIG_ECFW_PTR_ADDR within bootblock, so kbc1126_ec_insert is not
needed at build time any more.
Test passed on Elitebook Folio 9470m.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I4f0de0c4d7283e630242fbe84a46e0547783c49e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The commit d023909b "treewide: Disable R_AMD64_32S relocation support"
clflush the address stored in _cbmem_top_ptr, which is the same address
cbmem_top() returns, instead of clflush _cbmem_top_ptr itself.
Fix that by providing the correct address to clflush.
Change-Id: If74591e7753cd9c3c097516430a212d416f53e4d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The cpu_relax method is defined for x86. This CL adds a no-op method so
that it can be used in common code.
BUG=b:179699789
TEST=none
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcb4546ceb2894eeb37589d0282b7e076d7a4747
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
CONFIG(SMP) was an invalid condition to use in cases where one
stage requires spinlocks and another one does not. The
stage not requiring spinlock still required <smp/spinlock.h>
to be implemented with no-op stubs.
This reverts commit 037ee4b556
soc/amd/picasso: Add dummy spinlock for psp_verstage
Change-Id: Iba52febdeee78294f916775ee9ce8a82d6203570
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
There is no platform in our tree that requires the PCI MMIO ops but
doesn't want the pci_s_* definitions. The only case where we include
the `pci_mmio_cfg.h` header but don't want the pci_s_* functions to
use MMIO is on older x86 platforms, so move the guard there.
Change-Id: Iaeed6ab43ad61b7c0e14572b12bf4ec06b6a26af
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
AMD platforms require the SPI contents to be 64 byte aligned in order to
use the SPI DMA controller.
BUG=b:179699789
TEST=Build guybrush and verify cbfs was invoked with -a 64
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I842c85288acd8f7ac99b127c94b1cf235e264ea2
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56579
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Introduce the `smbios_dev_info` devicetree keyword to specify the
instance ID and RefDes (Reference Designation) of onboard devices.
Example syntax:
device pci 1c.0 on # PCIe Port #1
device pci 00.0 on
smbios_dev_info 6
end
end
device pci 1c.1 on # PCIe Port #2
device pci 00.0 on
smbios_dev_info 42 "PCIe-PCI Time Machine"
end
end
The `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` Kconfig option enables using
this syntax to control the generated Type 41 entries. When this option
is enabled, Type 41 entries are only autogenerated for devices with a
defined instance ID. This avoids having to keep track of which instance
IDs have been used for every device class.
Using `smbios_dev_info` when `SMBIOS_TYPE41_PROVIDED_BY_DEVTREE` is not
enabled will result in a build-time error, as the syntax is meaningless
in this case. This is done with preprocessor guards around the Type 41
members in `struct device` and the code which uses the guarded members.
Although the preprocessor usage isn't particularly elegant, adjusting
the devicetree syntax and/or grammar depending on a Kconfig option is
probably even worse.
Change-Id: Iecca9ada6ee1000674cb5dd7afd5c309d8e1a64b
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The commit 04a40379b has a wrongly written variable, which sets an
IOAPIC register to a wrong value and makes the Linux kernel unable to
boot.
Tested on HP EliteBook 2760p, the kernel boots after this patch.
Change-Id: Ifda7bb61a431dbf9c2df2f738aa806dd6d8097b8
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58558
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Remove the test for count=0 that leaked from drivers/generic/ioapic
implementation. See commit ea2fb8d80 and commit 8cc25d229.
Change-Id: I26944b930851fbea160c844ea46e2faa61c9af8e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The number of redirection table entries (aka interrupt vectors) inside
an I/O APIC may depend of the SKU, with the related register being of
type read/write-once. Provide support utilities to either lock or set
this registers value.
Change-Id: I8da869ba390dd821b43032e4ccbc9291c39e6bab
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55289
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add system wake-up type in smbios type 1 - system information.
TESTED=On S9S, can override original value and show expected result
using "dmidecode -t 1".
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: If79ba65426f1f18ebb55a0f3ef022bee83c1a93b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
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>
With the recent addition of SMBIOS table 20, the cbmem area on
google/brya0 overflows and
ERROR: Increase SMBIOS size
SMBIOS tables: 2128 bytes.
is seen in the logs.
Therefore, double the size of the SMBIOS area from 2 KiB to 4 KiB to
accomodate more tables as needed. This happens during ramstage so 2k
is not a big deal at this point.
Change-Id: I43aa6a88d176e783cc9a4441b35b8d608c4101cd
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since cpu_info() is no longer required to use threads, we no longer need
to initialize it in romstage or earlier. This code was also incomplete
since it didn't initialize the %gs segment.
BUG=b:179699789
TEST=Boot guybrush to OS
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I615b718e9f035ca68ecca9f57d7f4121db0c83b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
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>
All boards with DRIVERS_GENERIC_IOAPIC select it.
Presumably the related configuration of routing IRQ0 when
IOAPIC is enabled should be always done to provide i8259
legacy compatibility for payloads.
Change-Id: Ie87816271fa63bba892c8615aa5e72ee68f6ba93
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55287
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
If available, use data from MEMINFO CBMEM table and saved handles
from type 17/19 tables to generate type 20 (Memory Device Mapped
Address) SMBIOS table.
Windows 10/11 and some other OSes use this table to report the total
memory available on a given device.
Change-Id: I2574d6209d973a8e7f112eb3ef61f5d26986e47b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58271
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
<clocks.h> and smp_processor_id() aren't used anywhere anymore. Get rid
of them.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I1a8c892b066e6ac0e7cec5316633d44165344e78
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57819
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
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>
Currently, static analyzers don't recognize that hlt() doesn't return,
so they show errors like uninitialized variables assuming that it does
return. This takes care of that problem.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ia2325700b10fe1f89d749edfe5aee72b47d02f2e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56978
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Felix Held