This change adds support for allocating resources for PCI express hotplug
bridges when PCIEXP_HOTPLUG is selected. By default, this will add 32 PCI
subordinate numbers (buses), 256 MiB of prefetchable memory, 8 MiB of
non-prefetchable memory, and 8 KiB of I/O space to any device with the
PCI_EXP_SLTCAP_HPC bit set in the PCI_EXP_SLTCAP register, which
indicates hot-plugging capability. The resource allocation is configurable,
please see the PCIEXP_HOTPLUG_* variables in src/device/Kconfig.
In order to support the allocation of hotplugged PCI buses, a new field
is added to struct device called hotplug_buses. This is defaulted to
zero, but when set, it adds the hotplug_buses value to the subordinate
value of the PCI bridge. This allows devices to be plugged in and
unplugged after boot.
This code was tested on the System76 Darter Pro (darp6). Before this
change, there are not enough resources allocated to the Thunderbolt
PCI bridge to allow plugging in new devices after boot. This can be
worked around in the Linux kernel by passing a boot param such as:
pci=assign-busses,hpbussize=32,realloc
This change makes it possible to use Thunderbolt hotplugging without
kernel parameters, and attempts to match closely what our motherboard
manufacturer's firmware does by default.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: I500191626584b83e6a8ae38417fd324b5e803afc
Add support for x86_64 bootblock on qemu.
Introduce a new approach to long mode support. The previous patch set
generated page tables at runtime and placed them in heap. The new
approach places the page tables in memory mapped ROM.
Introduce a new tool called pgtblgen that creates x86 long mode compatible
page tables and writes those to a file. The file is included into the CBFS
and placed at a predefined offset.
Add assembly code to load the page tables, based on a Kconfig symbol and
enter long in bootblock.
The code can be easily ported to real hardware bootblock.
Tested on qemu q35.
Change-Id: Iec92c6cea464c97c18a0811e2e91bc22133ace42
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
All of the EC_EVENT_* macros can be replaced with the EC_HOST_EVENT_*
macros defined in ec_commands.h, which is synchronized from Chromium OS
ec repository.
BRANCH=none
BUG=none
TEST=emerge-kukui coreboot
Change-Id: I12c7101866d8365b87a6483a160187cc9526010a
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Some mainboards with an ASPEED BMC do the serial routing setup in the
BMC boot phase on cold boot. This results in scrambled console output
when this is not finished fast enough.
This adds a delay of 500ms as workaround in the BMCs uart setup that
can be selected at mainboard level.
A user may disable the workaround when using another BMC firmware like
OpenBMC, u-bmc or some custom BMC bootloader with fast serial setup.
Change-Id: I7d6599b76384fc94a00a9cfc1794ebfe34863ff9
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36591
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On this platform the ramstage is run on a different core so passing
cbmem_top via calling arguments is not an option. To work around this
populate _cbmem_top_ptr with cbmem_top_chipset which is also used in
romstage.
Change-Id: I8799c12705e944162c05fb7225ae21d32a2a882b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36557
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
While commented as 10 ms + 250 us, those delay loops actually
accounted for a total of 840 ms. And they seem unnecessary
as followup code has potentially infinite retries when
polling for status changes.
Tested on aopen/dxplplusu, dual-socket P4 Xeon HT model_f2x.
Change-Id: Ib7d1d66ed29c62d97073872f0b7809d719ac2324
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested on thinkpad X200 with CONFIG_H8_FN_KEY_AS_VBOOT_RECOVERY_SW
selected, the RW_A slot is properly selected unless the FN button is
pressed. 600+ms are spend waiting for the EC to be ready.
Change-Id: I689fe310e5b828f2e68fcbe9afd582f35738ed1d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35998
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Multiple git checkouts cause GRUB2 to constantly rebuild even if there
were no changes to code or config. This is due to changing timestamps.
Fix this by not creating or switching branches but instead rely on
`git checkout -f` which does not touch existing unchanged files.
To be sure to not break anyones workflow checkout is skipped and a
warning gets printed if the tree/index is unclean.
Change-Id: I7cf66f63268de973a654146a0a47c3d5ca516d4d
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36343
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
