AMD systems support 8-bit IOAPIC IDs. Some silicon initialization code
modules, like OpenSIL, may allocate an 8-bit ID by default. To respect
that configuration or set ID properly in coreboot, whole 8-bit ID field
has to be cleared and set.
Add new IOAPIC_8BIT_ID Kconfig option to allow setting 8-bit long IOAPIC
IDs.
TEST=Set IOAPIC IDs starting with 240 on Gigabyte MZ33-AR1.
Change-Id: Ie85b2272b0bc64a95d76c5677816941f1334901d
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Use flexible array member cper_ia32x64_context to simplify the struct
usage.
Change-Id: I729cb914031b55b2b58bc9e459ee0ea15c7626e8
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90479
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds config ARCH_RISCV_RV64 to support build of riscv64
payloads. New files under arch/riscv contain:
- Basic ldscript and payload entry point.
- Functions for riscv64 io and cache operations.
- Default timer code based on mtime delegation.
- Default cb_header_ptr passing with device tree to payload.
Change-Id: Ieb3d456d5edda87a3a4886ccfc17a7824c630427
Signed-off-by: Ziang Wang <wangziang.ok@bytedance.com>
Signed-off-by: Dong Wei <weidong.wd@bytedance.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89646
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The name check is a bit confusing, since it is not a check structure.
The check structure is below it.
Change-Id: I000e9e5f2ce8210fce76ef81b4242150d02fceed
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The naming of the parameters was quite confusing which caused them to be
used incorrectly. For example the cper_ia32x64_ctx_sz_bytype function
was given the register size in bytes, but it sill multiplied it by 8,
thinking that it got the number of registers instead.
Fix the parameter names to make it more obvious what is the number of
register array entries and what is the actual size in bytes of the
array.
Change-Id: I17a0fadba57ee8ede996eead4cdfb20f1ab3031e
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90477
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the APs are much faster then the working hart, it is possible that it
will enter HART_SLEEPING state before the working hart checks whether or
not the APs woke up by checking the HART_AWAKE state.
One can reproduce this issue by adding the following print message and
testing it in QEMU. One will notice that it will get stuck.
+ printk(BIOS_SPEW, "waiting for hart %d\n", i);
while (atomic_read(&OTHER_HLS(i)->entry.sync_a) != HART_AWAKE)
Fix it by adding another sync step at the end of `smp_resume()`.
Tested: QEMU RISC-V with -smp 64 parameter
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I1e0485831f71dde400d793b9f7bda88ae6519913
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
If the section guid is CPER_SEC_PROC_IA32X64_GUID we want the x86
processor specific section instead of the generic one.
This was probably some kind copy error from the line above.
Change-Id: I6a6a885bf8ab97cb5d256513cf8134078b707d3c
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@amd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90476
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This change prepares an alternative entry point for the ARM64
ramstage. It is written in assembly language, avoids the usage of the
stack, and overrides the program stack pointer (SP register) if the
`preram_stack` and `postram_stack` point to different addresses.
Previous Boot Flow:
- header.ld -> jump into `stage_entry` C code for ROMSTAGE onwards ->
`stage_entry` being called and followed by `main` function
Updated Boot Flow:
- header.ld -> jump into `_start` (assembly entry point) for
ramstage specifically -> Update the existing SP (stack pointer)
register if the `preram_` or `postram_` stack address is not
same -> call into `stage_entry` and follow the `main` function.
BUG=b:456953373
BRANCH=None
TEST=Able to build google/bluey.
Change-Id: I4eec24aff1c9d01180c3452a3631dd344656c771
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90403
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Refactor the stack definition macros to explicitly define separate
memory regions for the stack, addressing resource conflicts on
certain SoCs like Qualcomm x1p42100.
The original STACK macro is split into PRERAM_STACK and
POSTRAM_STACK.
Motivation:
On the Qualcomm x1p42100 SoC, the boot flow presents two
constraints for the initial stack location:
- Boot IMEM is unavailable after the ADSP is loaded.
- The existing SSRAM stack address is reserved for QC QSEE by the
Trust Zone.
Solution:
- PRERAM_STACK: Used by coreboot (e.g., till romstage) for static
stack allocation (from an alternative SSRAM or BOOT IMEM region).
- POSTRAM_STACK: Used starting from ramstage, leveraging the
DRAM-mapped memory.
This conditional split allows coreboot to manage stack memory
independently for the limited environment before DRAM is fully
initialized (ENV_ROMSTAGE_OR_BEFORE), resolving the hardware memory
conflicts while maintaining compatibility with existing code via
aliasing.
BUG=b:456953373
BRANCH=None
TEST=Able to build google/bluey.
Change-Id: I6356adc63d595f59050e6dc5961404be4a9534c0
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90402
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jayvik Desai <jayvik@google.com>
This moves all the definitions and declarations that are part of the
ACPI Platform Error Interface (APEI) into the corresponding header file.
Change-Id: Ied3915e4f598cd393f396de26b07ade7ce3a7ab1
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Refactor the DMA coherent memory region definition to support
stage-specific allocations.
In some boot flows, it is necessary to define separate DMA coherent
buffers for the early boot stage (e.g., romstage/bootblock) and the
later stage (ramstage). It allows the firmware to use only the memory
it needs, where it needs it, and prevents small-scale memory constraints
from crippling the overall boot flow.
The arch-specific, and now redundant, definitions of DMA_COHERENT are
removed from arm/memlayout.h and arm64/memlayout.h.
BUG=b:456953373
TEST=Able to build google/quenbi.
Change-Id: Ic32d14dda6cda0f731233dd3d86f3215c6af3637
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90049
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add boot timestamps to measure the duration of loading the Secure OS
(BL32) payload in the `run_bl31()` function.
The Secure OS is loaded if the Kconfig option
`CONFIG_ARM64_USE_SECURE_OS` is enabled. The new timestamps are:
- "TS_TFA_LOAD_BL32_START": Placed immediately before the Secure OS
(BL32) loading process begins.
- "TS_TFA_LOAD_BL32_END": Placed after the BL32 entry point information
is set up and before the BL33 parameters are finalized.
This instrumentation helps profile the boot time cost of the Trusted
Firmware-A (TFA) BL32 component loading.
Change-Id: I6ca74b8d4b11dfab4829f8bc5fbaa39ee5212137
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/90113
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Include guards should cover the whole file.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Idbb7b26b31460ad5ac6b8a55a41eb274a8fcec92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub "Kuba" Czapiga <czapiga@google.com>
The 'id' in OTHER_HSL macro is non-typed, downflow would occur when
‘id’ is unsigned and less greater than hart_id. Cast it to int.
Change-Id: I777337b7e374024aff6fb36de603b799b1a65371
Signed-off-by: Ziang Wang <wangziang.ok@bytedance.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/89338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
On older CPUs lacking ESRM (Enhanced Short Rep Mov) the rep stos
instructions are very slow. Since the MTRR that covers the SPI ROM
is disabled when setting up the NEM, the CPU will run with cache
disabled and is even slower.
The Sandy Bridge BWG and the Sandy Bridge UEFI reference code do not
disable the MTRR on the XiP, allowing the CPU to run at full speed
when setting up CAR. On UEFI the CAR is set up by touching each
cache-line once. It doesn't clear the CAR while doing so.
Do the same to speed up setting CAR:
- Invalidate the cache
- Enable the SPI ROM XiP MTRR
- Set CR0.CD=0
- Touch one spot in each cache-line
- Clear CAR after NEM has been set up
To ensure that the CAR MTRR area is 64-byte aligned add an ALIGN to
the linker script. All existing boards should use a 64-byte alignment
for CAR.
TEST=Booted on Lenovo X220 and measured with cbmem -t:
TODO: Test on platforms that have FSRM (Ivy Bridge and newer).
Before:
0:1st timestamp 1,083 (0)
11:start of bootblock 93,765 (92,681)
After:
0:1st timestamp 0
11:start of bootblock 24,027
Boots 69msec faster than before or about 4 times faster.
Change-Id: Ia8baef28fd736ef6bb02d8a100d752ac0392e1cf
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88792
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested on QEMU with ECC. Use mmap_helper to handle loading of compressed
ramstage. Bootblock fits in SEEPROM with both console and LZ4
romstage compression, but not with verbose CBFS debug messages.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Change-Id: I91c72c52849eb1e3fafe43390351537d04382e46
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
On PPC64 each address is logically OR'ed with HRMOR (Hypervisor Real
Mode Offset Register) before it is dispatched to the underlying memory,
meaning that memory space overlaps at the least significant bit set in
HRMOR. coreboot is entered with HRMOR = 4GB-128MB both on hardware
(when started by hostboot bootloader) and in Qemu in hb-mode. This means
that memory overlaps every 128MB in this particular case. HRMOR can be
explicitly ignored when MSB of an address is set, but this would require
using different memory model for linking.
If we zero HRMOR in bootblock, linking can be done against real address.
This greatly simplifies memory layout and allows to forget about HRMOR
from that point on.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: I0170463968c91b943c4b0dc15fe73fa616a164da
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67067
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Clear DF flag before invoking MOVS instruction to make sure it
increments %esi/%edi on each mov.
Change-Id: I209f50dec2003ea9846e5958d3e77b8979f338df
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88796
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit extends the cooperative multitasking functionality to
support the x86_64 architecture. Previously, cooperative multitasking
was only available for x86_32, as indicated by the error directive in
thread.c.
A new thread_switch_64.S file has been added to implement 64-bit
register handling for thread switching, and thread_switch.S has been
renamed to thread_switch_32.S accordingly.
Change-Id: I14ed625160a62e42d800757d30397c6c85f943b4
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/88216
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During finalize_load(), cpu/x86/mtrr/earlymtrr.c:postcar_mtrr is signaled
to be loaded as reloc_params, e.g. with its cache flushed.
Add a comment line to specify the relationship to improve the readability.
I didn't see code to set up parameter at first time.
So, I just guess that adding a comment would be helpful. :)
Change-Id: Ic7d3f9cf514ce5a8efc2af9e78992cb39a91e537
Signed-off-by: NyeonWoo Kim <knw0507@naver.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86866
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Currently there are 3 GDTs (Global Descriptor Tables) being used on x86:
- preRAM (gdt_init.S)
- SMM (smm_stub.S)
- RAM (c_start.S)
They have different layouts and thus different offsets for the segments
being used in assembly code. Stop using different GDT segments and
ensure that for ROM (preRAM + SMM) and RAM (ramstage) the segments
match. RAM will have additional entries, not found in pre RAM GDT,
but the segments for protected mode and 64-bit mode now match in
all stages.
This allows to use the same defines in all stages. It also drops the
need to know in which stage the code is compiled and it's no longer
necessary to switch the code segment between stages.
While at it fix the comments in the ramstage GDT and drop unused
declarations from header files, always set the accessed bit and drop
GDT_CODE_ACPI_SEG.
Change-Id: I208496e6e4cc82833636f4f42503b44b0d702b9e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87255
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add an exception handler to SMM to debug crashes when a serial
console is enabled and DEBUG_SMI is set. This allows for narrowing
down issues faster than letting the machine triple fault.
Change-Id: I2ccaf8d23d508d773ce56912983884ad6832ede6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
I found duplicated code masking stack pointer.
So, i'd like to remove the duplicate for refactoring :-).
This is my build output of c_start.o, before vs after modifying.
before modifying
...
44: f3 ab rep stos %eax,%es:(%edi)
46: bc 00 00 00 00 mov $0x0,%esp
4b: 83 e4 f0 and $0xfffffff0,%esp
4e: b0 6e mov $0x6e,%al
50: e6 80 out %al,$0x80
52: 83 e4 f0 and $0xfffffff0,%esp // deleted.
55: e8 fc ff ff ff call 56 <_start+0x56>
...
after modifying
...
44: f3 ab rep stos %eax,%es:(%edi)
46: bc 00 00 00 00 mov $0x0,%esp
4b: 83 e4 f0 and $0xfffffff0,%esp
4e: b0 6e mov $0x6e,%al
50: e6 80 out %al,$0x80
52: e8 fc ff ff ff call 53 <_start+0x53>
...
P.S. it is commits which introduced duplication.
32bit : 4d75dbd1c1
64bit : 1c4c7ad1e5
Change-Id: I417ce90279fea4b00432e6a209f77a6dd0c0fee6
Signed-off-by: NyeonWoo Kim <knw0507@naver.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Now that we require the FMAP to start at offset 0 in the flash, we can
assume this across the entire codebase and therefore simplify it on
several ends.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Ieb1a23f9c0ae8c0e1c91287d7eb6f7f0abbf0c2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86771
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Stop using magic values and use defines for Global Descriptor Table
(GDT) offsets. Use the existing defines from the corresponding headers.
Change-Id: I40c15f6341bdef9cd457619ec81e7ac624ec2d63
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/87254
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
FMAP should not contain information about the memory map.
Done with the following command:
"find -name \*.fmd -exec sed -i 's/\(FLASH\).* \(.*\) /\1 \2 /' {} \;"
for AMD:
All addresses that amdfwtool expects as command line parameter have the
ADDR_REL_BIOS (flash address) address_mode setting. One exception is
the *_FW_A_POSITION and *_FW_B_POSITION addresses. But amdfwtool checks
if memory or flash addresses are passed and converts accordingly. So
changing the address from memory -> flash doesn't matter for the
resulting binary.
Since commit 41a162b7a8 ("soc/amd/phoenix/Makefile.inc: Pass APOB_NV
address as offset") and therefore since phoenix SOC, APOB_NV is passed
as flash offset. But before that the memory ABL always assumed a MMIO
address (no matter the address_mode) so we need to add a little quirk
for that.
tested: boot glinda based mainboard and also check that memory training
is still cached successfully in APOB_NV.
Change-Id: Iac86ef9be6b14817a65bf3a7ccb624d205ca3f99
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Consider special requirements for computing cache size in certain SoCs,
such as `soc/amd/glinda`.
Use the helper function to implement SoC-specific logic for computing
cache size.
Change-Id: I60707de4c8242a8fbda8cb5b791a1db762d94449
Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently all platforms on RISC-V require a FDT.
The inclusion of the FDT is currently done in the platform Makefiles.
In order to factor out some common code this patch adds the inclusion
in the architecture Makefile. The FDT must be aligned to 8 byte
according to device tree spec. It avoids misaligned access.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I3b304a89646fe84c98e9f199f315bebb156de16c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
The upstream arm-trusted-firmware has removed the DISABLE_PEDANTIC
option in Commit 79eb1aff7850 ("Remove DISABLE_PEDANTIC build option").
Therefore, drop the option for BL31.
Change-Id: Iaca07ce190c566fe79814fd8bbd8821d3ea76955
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86263
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
As suggested by the linter:
Prefer 'unsigned long' over 'unsigned long int' as the int is unnecessary
Link: https://qa.coreboot.org/job/coreboot-untested-files/lastSuccessfulBuild/artifact/lint.txt
Cc: "Jérémy Compostella" <jeremy.compostella@intel.com>
Change-Id: Ida1de23830b0b67ab7fac635b02a4e99c65746f8
Signed-off-by: Ariel Otilibili <otilibil@eurecom.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85782
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Disable the debug code as there were unexplainable stack corruptions
detected on some platforms.
No problems were observed on:
- QEMU
- Xeon-SP
Change-Id: I1f1b9f01af7fbb0c19becf6ea53d436898584c5e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85594
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Match function name "init" with "remove" by renaming all
*_breakpoint_disable() to *_breakpoint_remove().
Change-Id: Id3da25cfa6fc0594887f3112e269e57e8ecb32b3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85540
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to debug stack smashing add a write breakpoint to the
stack canary (at _stack or _car_stack) and print the IP when the
stack canary is written.
TEST: Wrote to address _stack in ramstage and got the EIP of the
code that smashed the stack canary.
Change-Id: I8adf07a8425856795a4a71da5c41bec2244b02a8
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84833
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On platforms with multiple IOAPICs the GSI base must not be
linear, which is currently assumed by acpi_create_madt_ioapic_from_hw().
Integrate the existing struct device DEVICE_PATH_IOAPIC type and allow
to assign custom GSI bases for each IOAPIC. Write out the IOAPIC devices
into the MADT table if any.
For now, since no platform adds IOAPIC devices, the existing behaviour
remains the same. Allows to get rid of soc_get_ioapic_info().
Change-Id: Ie13d4f5c4f0704f0935974f90e5b7cf24e94aab3
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85226
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
These header files do not seem to be used in coreboot. Presumably
they're left over after the code that used them was removed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ide70239c7c2e93fff548d989735450396308c62b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85370
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Currently only a fixed number of harts/cores can be detected.
This patch adds a Kconfig option which allows to detect the number of
harts at runtime if a SOC or mainboard has a scheme to do so.
As part of that patch SMP logic has been mostly moved to smp_resume,
since it is easier to debug issues at the time smp_resume is called
than it is at smp_pause, since the serial is usually not present at the
time of the first smp_pause call.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icc53185991fed4dbed032a52e51ff71d085ad587
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The reasoning is that even though vendors currently tend to open source
their OpenSBI implementation, they often do so in their own repository.
So instead of adding all possible source repositories as submodules, we
shall allow specifying a path to an already compiled OpenSBI ELF file.
This is similar of what we currently do on ARM64 with the BL31 binary.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I6592ad90a254ca4ac9a6cee89404ad49274f0dea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: ron minnich <rminnich@gmail.com>
HPET General Capabilities and ID Register at offset 0x0 and Timer 0
Configuration and Capability Register at offset 0x100 are used to
determine the generation of HPET ACPI tables. This patch adds
macro definitions for these registers and fields. Definitions are
from IA-PC HPET (High Precision Event Timers) Specification Revision
1.0a.
Change-Id: I31413afcbfc42307e3ad3f99d75f33f87092d7aa
Signed-off-by: Yuchi Chen <yuchi.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84252
Reviewed-by: Shuo Liu <shuo.liu@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For more than 2 years the option has been unconfigurable.
Since no one seems to have fixed that, the options seems to be
not needed by anyone. So instead of making it configurable now,
we can just as well remove it.
Change-Id: I4055d497c7c23e148d2a09f216c7b910a9b3ea9b
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
For platforms without writable PAM-F segment support (e.g. some
simics virtual platforms), put ROM table pointers (e.g. ACPI/SMBIOS
low pointers) into EBDA.
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Signed-off-by: Jincheng Li <jincheng.li@intel.com>
Change-Id: I2aac74708279813f9a848044d470fdc980ea4305
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
QEMU aarch64 boots to payload when compiled with clang.
Change-Id: I940a1ccf5cc4ec7bed5b6c8be92fc47922e1e747
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/74501
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
EBDA (Extended BIOS Data Area) is a memory area below 0xA0000 and
one of the default areas where OS will scan ACPI RSDP pointer from.
coreboot's default EBDA's starting address is 0xF6000, which is in
PAM (Programmable Attribute Map) F-segment's scope. For some platforms
without writeable PAM-F segment (e.g. some simics virtual platforms),
corboot's default EBDA is not writable.
Make DEFAULT_EBDA_LOWMEM, DEFAULT_EBDA_SEGMENT, DEFAULT_EBDA_SIZE
as Kconfig items so that coreboot's EBDA could be relocated to a
writable low memory place.
Change-Id: Icd7ba0c902560f7d498934392685dc2af9c5ce09
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Co-authored-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
