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>
The arch include files are overshadowed by PSP verstage include files.
The reason is that psp_verstage implements its own set of inb() and
outb() functions, which use a runtime configurable IO base address
instead of a built time constant.
But this works at the moment only because of the order in which the
include files are added. Since that is very error prone, this patch
introduces another solution to the problem.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I16fa4a4cb5168024aaef30119e9aa8a34dbaacbe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/86874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
QEMU has a maximum of 512 of emulated harts supported.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I149c8d8a43733c8ba3e02a84b0a3606d98f8b2c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/81083
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Alicja Michalska <ahplka19@gmail.com>
Reviewed-by: Carlos López <carlos.lopezr4096@gmail.com>
Spike Simulator commit 191634d2854d implemented a ns16550 serial device
which puts the base address at 0x10000000.
Tested: Start Spike Simulator and see that coreboot prints onto the UART.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I0e3db9d8b141c733bf609f906018096e3594ce83
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85852
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fw_cfg device can be used by other qemu boards outside i440fx (and
q35, which manually includes the code). Factor out the fw_cfg code as a
separate driver that qemu mainboards can enable.
Change-Id: I8c5c4cb5f5478abd21aab8e8d0b503db41d81d40
Signed-off-by: Carlos López <carlos.lopez@openchip.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85673
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Since QEMU commit 728b923f548d
("target/arm: Do memory type alignment check when translation enabled")
alignment is checked for device memory. That causes exceptions during
bootup of coreboot trying to load things (e.g. stages) from the memory
mapped flash.
To fix it the memory mapped flash region will be marked as MA_MEM
(normal memory) instead of MA_DEV (device memory). Technically that
isn't 100% correct, but avoids having to write a custom memory mapped
flash driver that checks for alignment on all accesses. Since it is
emulation and therefore always normal memory anyway, there shouldn't be
any side effects.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I98bd1a18495e3d153ce53abec8686c7871ee12c5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/85147
Reviewed-by: David Milosevic <David.Milosevic@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
By default, QEMU bails when trying to use bigger images mounted with
'-drive if=pflash', which is required to make use of writable flash
introduced in CB:82555. This changes both default size in Kconfig as
well as FMAP layouts.
Since QEMU 5.0.0 it is possible to change the limit of firmware size
with `max-fw-size` machine configuration option, up to 16 MiB, as bigger
sizes would overlap with IO APIC memory range. Default is still 8 MiB,
so it makes sense to have identical default in coreboot.
Error thrown by QEMU when trying to use too big ROM:
qemu-system-x86_64: combined size of system firmware exceeds 8388608 bytes
Change-Id: If36cb754a8e75e23bce49ff568dd88e5db279bb8
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82639
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
qemu-system-x86_64 uses AMD64 SMM save state format, despite emulating
Intel chipset. In addition, even though it implements SMI_STS register,
QEMU never sets any bits in it. As there is little emulated hardware
that can be generating SMI, assume that all SMIs come from APM. This
source is used e.g. to disable ACPI (which wasn't working until now on
QEMU) and SMMSTORE.
Tested by invoking SMMSTORE commands from the payload with SMM logging.
Change-Id: I2fc7b74bdc13be8d76bc536283ab5a14fffec45f
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82558
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
`boot_dev` can be const, and we can use MEM_REGION_DEV_INIT() as all
the values are known at compile time.
Change-Id: Icd3757ba4b5e8bfbee9e9c9d18bf0ee71520a8ac
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/84089
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Previously RAM probing was necessary for our QEMU-RISCV target in order
to find the available amount of memory.
Now we get the memory from the devicetree propagated by QEMU, so there
is no reason to keep it anymore.
Tested:
Start QEMU-RISCV and cause an exception to make sure the trap handler
still works.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I9b1e0dc78fc2a66d6085fe99a71245ff46f8e63c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83873
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recently merged commit 8cc1d79ed0 (mainboard/qemu-aarch64: Get top
of memory from device-tree blob) missed a rebase and hence needs the
include path updated.
Tested `make qemu` for qemu-aarch64.
Change-Id: Id669eeaabbc1710bb7e408659f2d79f682427919
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Trying to probe RAM space to figure out top of memory causes an
exception on AArch64 virtual machines with recent versions of QEMU, but
we temporarily enable exception handlers for that and use it to help
detect if a RAM address is usable or not. However, QEMU docs recommend
reading device information from the device-tree blob it provides us at
the start of RAM.
A previous commit adds a library function to parse device-tree blob that
QEMU provides us. Use it to determine top of memory in AArch64 QEMU
virtual machines, but still fall back to the RAM probing approach as a
last-ditch effort.
Change-Id: I4cc888b57cf98e0797ce7f9ddfa2eb34d14cd9c1
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80364
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Depending on how firmware image was passed to QEMU, it may behave as:
- ROM - memory mapped reads, writes are ignored (FW image mounted with
'-bios');
- RAM - memory mapped reads and writes (FW image mounted with e.g.
'-device loader');
- flash - memory mapped reads, write and erase possible through
commands. Contrary to physical flash devices erase is not required
before writing, but it also doesn't hurt. Flash may be split into
read-only and read-write parts, like OVMF_CODE.fd and OVMF_VARS.fd.
Combined size of system firmware must not exceed 8 MiB by default
(FW image(s) mounted with '-drive if=pflash').
This function detects which of the above applies and fills
region_device_ops accordingly.
Tested by starting QEMU with firmware passed as '-drive if=pflash',
'-drive if=pflash,readonly=on' and '-bios'. When started with firmware
passed through '-device loader', coreboot complains about corrupted
FMAP, but this is the same behavior as without this change:
[ERROR] Invalid FMAP at 0x40000
[EMERG] Cannot locate primary CBFS
Writable pflash support was added about 17 years ago, so it should be
supported by all QEMU versions currently in use. Since QEMU 5.0.0 it is
possible to change the limit of firmware size with `max-fw-size` machine
configuration option, up to 16 MiB, as bigger sizes would overlap with
default IO APIC memory range.
Change-Id: I3ab9f22c6165064a769881d4be5eab13a0a2f519
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82555
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Define the PCI I/O base address necessary to use port I/O functions on
the qemu-aarch64 mainboard, so that we can get the VGA display devices
working. The config value is from hw/arm/virt.c [1]:
[VIRT_PCIE_PIO] = { 0x3eff0000, 0x00010000 },
[1] https://gitlab.com/qemu-project/qemu/-/blob/v8.2.3/hw/arm/virt.c#L164
Change-Id: I85439ba68740d64f789983b37d9c95f849ce4f72
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/82059
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Trying to probe RAM space to figure out top of memory causes an
exception on RISC-V virtual machines with recent versions of QEMU, but
we temporarily enable exception handlers for that and use it to help
detect if a RAM address is usable or not. However, QEMU docs recommend
reading device information from the device-tree blob it provides us at
the start of RAM.
A previous commit adds a library function to parse device-tree blob that
QEMU provides us. Use it to determine top of memory in RISC-V QEMU
virtual machines, but still fall back to the RAM probing approach as a
last-ditch effort.
Change-Id: I9e4a95f49ad373675939329eef40d7423a4132ab
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Add coreboot support for qemu's sbsa-ref (Server Base System
Architecture) machine (-m sbsa-ref).
The qemu-sbsa coreboot port runs on EL2 and is the payload of the
EL3 firmware (Arm Trusted Firmware).
Note that, coreboot expects a pointer to the FDT in x0. Make sure
to configure TF-A to handoff the FDT pointer.
Example qemu commandline:
qemu-system-aarch64 -nographic -m 2048 -M sbsa-ref \
-pflash <path/to/TFA.fd> \
-pflash <path/to/coreboot.rom>
The Documentation can be found here:
Documentation/mainboard/emulation/qemu-sbsa.md
Change-Id: Iacc9aaf065e0d153336cbef9a9b5b46a9eb24a53
Signed-off-by: David Milosevic <David.Milosevic@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79086
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
When switching back and forth between 32 to 64 bit mode, for example to
call a 32-bits FSP or to call the payload, new page tables in the
respective stage will be linked.
The advantages of this approach are:
- No need to determine a good place for page tables in CBFS that does
not overlap.
- Works with non memory mapped flash (however all coreboot targets
currently do support this)
- If later stages can use their own page tables which fits better with
the vboot RO/RW flow
A disadvantage is that it increases the stage size. This could be
improved upon by using 1G pages and generating the pages at runtime.
Note: qemu cannot have the page tables in the RO boot medium and needs
to relocate them at runtime. This is why keeping the existing code with
page tables in CBFS is done for now.
TEST: Booted to payload on google/vilbox and qemu/q35
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: Ied54b66b930187cba5fbc578a81ed5859a616562
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80337
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This changes the virt target so that it can be run with the -bios option
and a pflash backend for the flash. QEMU can now be run as follows:
qemu -M virt -m 1G -nographic -bios build/coreboot.rom \
-drive if=pflash,file=./build/coreboot.rom,format=raw
coreboot will start in DRAM, but still have a flash to put CBFS onto and
to load subsequent stages and payload from.
Tested bootflow:
coreboot -> OpenSBI -> Linux -> u-root
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I009d97fa3e13068b91c604e987e50a65e525407d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Philipp Hug <philipp@hug.cx>
Current version of qemu raise an exception when accessing invalid
memory. Modify the probing code to temporary redirect the exception
handler like on ARM platform.
Also move saving of the stack frame out to trap_util.S to have all at
the same place for a future rewrite.
TEST=boots to ramstage
Change-Id: I25860f688c7546714f6fdbce8c8f96da6400813c
Signed-off-by: Philipp Hug <philipp@hug.cx>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36486
Reviewed-by: ron minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 8dc95ddbd4 ("emulation/qemu-i440fx: use fw_cfg_dma for
fw_cfg_read") adds DMA support to interface with the QEMU firmware
configuration device, and uses it to read from the "files" exposed by
the device. However, the file selection step still uses port-based IO.
Use DMA for fw_cfg file selection when possible, as a step towards
porting this driver to other architectures.
Change-Id: I46f9915e6df04d371c7084815f16034c7e9879d4
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
The QEMU firmware configuration driver can help initialize SMBIOS tables
using the table data that QEMU provides over the device. While doing so,
it reads from the device "file" manually using port-based IO.
Use the fw_cfg_read() helper function to read the SMBIOS-related file,
so that the driver is easier to port the driver to other architectures.
Change-Id: I18e60b8e9de34f2b0ff67af4113beec1d7467329
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80367
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Parts of the QEMU firmware configuration device driver refers to SMBIOS
related kconfig values. These depend on GENERATE_SMBIOS_TABLES and are
undefined if it isn't enabled, causing a build error.
Cover the SMBIOS-related region in this driver with an #if directive
checking the necessary config option. This is mostly to help port the
driver to non-x86 architectures where support for generating SMBIOS
tables isn't there yet.
Change-Id: I3ff388d4574eb52686a5dda3dcbc3d64a7ce6f7b
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80366
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit 977b8e83cb ("mb/emulation/qemu-aarch64: Add MMU support") adds
MMU support for ARM64 QEMU VMs, but registers a limited 1GiB region for
the DRAM, with a note that ramstage should update it.
However on recent versions of QEMU "virt" VMs, accessing RAM outside
this registered region results in an exception even if the address is
backed by actual RAM. This interferes with RAM detection which catches
these exceptions, effectively limiting us to detecting a maximum 1GiB of
RAM even if more is available.
Register the entire RAM space to MMU instead of just the 1GiB, so that
probing RAM addresses can correctly detect how much RAM we have.
Change-Id: I3afbd27b91ab37304a29a62506f965ac3cfb1c06
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
This renames bus to upstream and link_list to downstream.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I80a81b6b8606e450ff180add9439481ec28c2420
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78330
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Macros can be confusing on their own; hiding commas make things worse.
This can sometimes be downright misleading. A "good" example would be
the code in soc/intel/xeon_sp/spr/chip.c:
CHIP_NAME("Intel SapphireRapids-SP").enable_dev = chip_enable_dev,
This appears as CHIP_NAME() being some struct when in fact these are
defining 2 separate members of the same struct.
It was decided to remove this macro altogether, as it does not do
anything special and incurs a maintenance burden.
Change-Id: Iaed6dfb144bddcf5c43634b0c955c19afce388f0
Signed-off-by: Nicholas Sudsgaard <devel+coreboot@nsudsgaard.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80239
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Jakub Czapiga <czapiga@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I422cb475723006ca42be93508fb0bf4b1e4e84d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80104
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Erik van den Bogaert <ebogaert@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Introduce the HAVE_CONFIGURABLE_APMC_SMI_PORT Kconfig option that when
not selected will result in a default implementation of
pm_acpi_smi_cmd_port to be included in the build that returns APM_CNT.
SoCs that provide their own pm_acpi_smi_cmd_port implementation, need to
select this Kconfig option.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iaceb61b0f2a630d7afe2e0780b6a2a9806ea62f9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Use same indent levels for switch/case in order to comply with the
linter.
Change-Id: I602cf024ec84b15b783d36014c725826f9d6595e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79418
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Having a separate romstage is only desirable:
- with advanced setups like vboot or normal/fallback
- boot medium is slow at startup (some ARM SOCs)
- bootblock is limited in size (Intel APL 32K)
When this is not the case there is no need for the extra complexity
that romstage brings. Including the romstage sources inside the
bootblock substantially reduces the total code footprint. Often the
resulting code is 10-20k smaller.
This is controlled via a Kconfig option.
TESTED: works on qemu x86, arm and aarch64 with and without VBOOT.
Change-Id: Id68390edc1ba228b121cca89b80c64a92553e284
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55068
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
On all targets the domain works as a host bridge. Xeon-sp code intends
to feature multiple host bridges below a domain, hence rename the
function to pci_host_bridge_scan_bus.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I4e65fdbaf0b42c5f4f62297a60d818d299d76f73
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78326
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
This is in preparation of a larger heap. I went for 2MB because why not?
Change-Id: I51f999a10ba894a7f2f5fce224d30bf914107c38
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the mainboard directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic451e68b1ad9ccdf34484dd98bd7fca7e177ef22
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68982
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Align implementation with real hardwares, such that ECAM
(PCI configuration via MMIO) is available for use when
console is initialised.
Change-Id: I288991f31d3f1678132aa4315168c09eabbbe98d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76206
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This devices is always present so hooking up the ops in devicetree makes
more sense.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I369129e365ce8596cad25b97d12168bb08e3ed0e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76241
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
