| Age | Commit message (Collapse) | Author |
|---|
|
With the recent switch to SMM module loader v2, the size of the SMM for
module google/volteer increased to above 64K in size, and thus failed to
install the permanent SMM handler. Turns out, the devicetree is all
pulled into the SMM build because of elog, which calls
`pci_dev_is_wake_source`, and is the only user of `struct device` in
SMM. Changing this function to take a pci_devfn_t instead allows the
linker to remove almost the entire devicetree from SMM (only usage left
is when disabling HECI via SMM).
BUG=b:186661594
TEST=Verify loaded program size of `smm.elf` for google/volteer is
almost ~50% smaller.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I4c39e5188321c8711d6479b15065e5aaedad8f38
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
On Intel 6-series PCHs, the GCAP register is R/WO (Read / Write Once),
and needs to be written to after the HD Audio controller is taken out
of reset. Add a Kconfig option to read and write back GCAP in order to
lock it down. Follow-up commits will select this option when switching
platforms to use common Azalia code, to preserve original behaviour.
Change-Id: I70bab20816fb6c0bf7bff35c3d2f5828cd96172d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The default of 32 buses per hotplug bridge is rather high. Especially
for platforms that limit MMConf space to 64 buses: they run out of
numbers if there is more than a single hotplug bridge.
Lower the default to
* 8 if MMConf is limited to 64 or less buses,
* 16 if MMConf is limited to 128 or less buses.
Change-Id: I06d522dd92ceea9f4798273b26f947a5333800c3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52069
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The indirection seems unnecessary. The macros throw features like
`-Wmisleading-indentation` off, though.
Default build for QEMU/Q35 is unchanged.
Change-Id: Ie4eab935a367b5ad6b38225c4973d41d9f70ef10
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51887
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
device: Correct code style
Revise the following aspects to follow coreboot's coding style:
- Drop braces for single-statement condition.
- Remove unnecessary newlines.
BUG = N/A
TEST = Build Compulab Intense-PC with secure oprom enabled
Change-Id: I78ce97b0ce1587119a71893c867c2dd062552a31
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
|
|
These aren't used anywhere anymore.
Change-Id: I4cf2fc0d07a772886e90fba4f66591a7b0a40e6c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Drop unnecessary typedefs and rename DDR4-specific definitions to avoid
name clashes, as done for DDR3 in earlier commits. This allows including
and using both DDR3 and DDR4 headers in the same compilation unit.
Change-Id: I17f1cd88f83251ec23e9783a617f4d2ed41b07f0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51898
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
To avoid name clashes with definitions for other DRAM generations,
rename the enum type and values to contain `ddr3` or `DDR3`.
Change-Id: If3710149ba94b94ed14f03e32f5e1533b4bc25c8
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51896
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
These typedefs are not necessary. Remove them, and rename some elements
to avoid any confusion with other DRAM generations, such as DDR4.
Change-Id: Ibe40f33372358262c540e371f7866b06a4ac842a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51895
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I11b362d5e586194501de5dbd11f9c934a9d53940
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Add the AZALIA_MAX_CODECS Kconfig option and use it.
Change-Id: Ibb10c2f2992257bc261e6cb35f11cc4b2d956054
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The HD Audio spec states that the STATESTS register is 16 bits wide.
Change-Id: If7859ed33e58d907a91c4ac8675892e37998cf41
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50790
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
The timeout is never reached when the codec is functioning properly.
Using a small timeout value can result in spurious errors with some
codecs, e.g. a codec that is slow to respond but operates correctly.
When a codec is non-operative, the timeout is only reached once per
verb table, thus the impact on booting time is relatively small. So,
use a reasonably long enough timeout to cover all possible cases.
Remove the unconditional 25 µs delay and increase the timeout delay.
The new value of 1 ms is the maximum of all existing implementations.
Currently, the only boards using this code are AMD reference boards:
- AMD Bilby
- AMD Mandolin
- AMD Padmelon
Change-Id: Ia5e4829d404dcecdb9e7a377e896a319cb38531a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Use timer.h helpers instead of open-coding timeout handling in polling
loops. The 25-microsecond delay in `wait_for_valid` looks odd, and may
be removed in subsequent commits. For now, preserve existing behavior.
Change-Id: Id1227c6812618597c37408a7bf53bcbcae97374a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50789
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
I was bugged by spurious "Failed to enable LTR" messages for years.
Looking at the the current algorithm, it is flawed in multiple ways:
* It looks like the author didn't know they implemented a
recursive algorithm (pciexp_enable_ltr()) inside another
recursive algorithm (pciexp_scan_bridge()). Thus, at every
tree level, everything is run again for the whole sub-
tree.
* LTR is enabled no matter if `.set_ltr_max_latencies` is
implemented or not. Leaving the endpoints' LTR settings
at 0: They are told to always report zero tolerance.
In theory, depending on the root-complex implementation,
this may result in higher power consumption than without
LTR messages.
* `.set_ltr_max_latencies` is only considered for the direct
parent of a device. Thus, even with it implemented, an
endpoint below a (non-root) bridge may suffer from the 0
settings as described above.
* Due to the double-recursive nature, LTR is enabled starting
with the endpoints, then moving up the tree, while the PCIe
spec tells us to do it in the exact opposite order.
With the current implementation of pciexp_scan_bridge(), it is
hard to hook anything in that runs for each device from top to
bottom. So the proposed solution still adds some redundancy:
First, for every device that uses pciexp_scan_bus(), we enable
LTR if possible (see below). Then, when returning from the bus-
scanning recursion, we enable LTR for every device and configure
the maximum latencies (if supported). The latter runs again on
all bridges, because it's hard to know if pciexp_scan_bus() was
used for them.
When to enable LTR:
* For all devices that implement `.set_ltr_max_latencies`.
* For all devices below a bridge that has it enabled already.
Change-Id: I2c5b8658f1fc8cec15e8b0824464c6fc9bee7e0e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51328
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Let the linker do its job.
This fixes building with !CONFIG_PCIEXP_HOTPLUG on some platforms.
Change-Id: I46560722dcb5f1d902709e40b714ef092515b164
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Load VBIOS in pci set_resources to PCI_VGA_RAM_IMAGE_START (0xc0000)
since pci_dev_init() will not load it in GOP case (VGA_ROM_RUN is not
set). Add Cezanne GFX PID.
BUG=b:171234996
BRANCH=Zork
Change-Id: I4a6fea9b6cd60c862e15ed2ed539869c0f9bd363
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Replace the existing, odd looking, unordered definitions used for
LTR configuration with the usual names used by upstream libpci.
TEST=Built google/brya0 with BUILD_TIMELESS=1: no changes.
Fixes: Code looked like UEFI copy-pasta. Header file was a mess.
Change-Id: Icf666692e22730e1bdf4bcdada433b3219af568a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51327
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Rename `set_L1_ss_latency` to what it does: `set_ltr_max_latencies`.
TEST=Built google/brya0 with BUILD_TIMELESS=1: no changes.
Change-Id: I7008aa18bf80d6709dce1b2d3bfbb5ea407a0574
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51326
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This makes it clear what this function pointer is used for.
Change-Id: I2090e164edee513e05a9409d6c7d18c2cdeb8662
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51009
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move SPD manufacturer ID decoding to device/dram. Will be used by the
following patch outside of SMBIOS scope as well.
Change-Id: Iec175cd6ab1d20761da955785e4bc0e87ae02dbb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
It’s good practice to put the unit into the name.
Change-Id: I1493f61d4e495c22f09abf1829bb2eab9b1fd2b6
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I30ed9661d8e84be49d362baafbb2bc624952c287
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50522
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
On some mainboards, codec configuration depends on settings that are
only known at runtime, which is impossible to specify using one verb
table. Add an optional `mainboard_azalia_program_runtime_verbs` hook
where mainboards can program runtime-dependent codec verbs.
Change-Id: I7efeba5c26051aeb5061cce191ace08c304a6c70
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
On some boards, Azalia configuration depends on config settings that are
not known at compile-time. Expose a function to program a verb table, to
be used in subsequent commits.
Change-Id: Ie9607f6e733df66f0ca26a4bb70e0864ce1d4512
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50387
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The type of `verb_size` is unsigned, thus use `%u` to print its value.
Change-Id: I2b353b940e881dc8b5f0b902509d97d89c997a70
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
It was commented that the need for the delay was mainly related
to external displays and only with VBIOS execution. Move the
delay such that it is done only when we actually need to execute
the VBIOS aka option rom.
A delay is currently only defined for librem/purism_bdw in
its Kconfig. As the description of the issue sounds like it
would equally happen on other platforms when VBIOS is involved,
promote the Kconfig visible option to global scope.
Change-Id: I4503158576f35057373f003586bbf76af4d59b3d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48787
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
First and last printk() log the same string.
Add done at end of function.
BUG = N/A
TEST = Build and boot faceboot FBG1701
Change-Id: I66a64c7473a65206c3a4c4396c8c8ecba1eb1a57
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Revise the following aspects to follow coreboot's coding style:
- Drop braces for single-statement condition and loop bodies.
- Use `__func__` to print the current function's name.
- Reflow pointer dereferences to fit in a single line.
- Adjust the `*` position in pointer variable declarations.
- Drop unnecessary `else` statements.
BUG = N/A
TEST = Build Compulab Intense-PC with secure oprom enabled
Change-Id: I780251d946d5bea97658476d61d25555ec768dfc
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49963
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
`make lint` reports errors and warnings
Solve the next errors:
- SPACE_BEFORE_TAB
- SPACING
BUG = N/A
TEST = Build Compulab Intense-PC with secure oprom enabled
Change-Id: Ic7062e07a76bf95fe8e2e849f1d14342c9081a23
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49938
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
All uses of `mmconf_resource_init` have been replaced in previous
patches with `mmconf_resource`, which uses Kconfig symbol values.
Change-Id: I4473268016ed511aa5c4930a71977e722e34162a
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
This is necessary because ASL Memory32Fixed values cannot contain
operations, even if they can be evaluated to constants. Add a sanity
check in pci_mmio_cfg.h to ensure consistency with MMCONF_BUS_NUMBER.
Change-Id: I8f0b5edf166580cc12c1363d8d6b6ef0f2854be9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50033
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Only specify the type of MMCONF_BASE_ADDRESS and MMCONF_BUS_NUMBER once.
Change-Id: Iacd2ed0dae5f1fb6b309124da53b3fa0eef32693
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50032
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Systems can boot to the OS without a display. Don't kill the boot
process based on a vBIOS error, instead just display a warning.
If the issue is actually fatal for some reason, it's going to die
at some point anyway.
BUG=b:175843172
TEST=Boot morphius to OS without a display
BRANCH=Zork
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I7d261321cdbe423dd754f6a354e5f50b53563fcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ia6c7de99164682dcbcc375969403d2bfb9675f3c
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49544
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: I24c40d511eeaa5073acd2b47b20b4ec2f85bb69e
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49545
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: Ia278e1f2d1162fa9541bf0cead3b2734144190be
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ia1648bd7ba4858268ca5f1a5c7b42b7de717d3d6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
|
|
Change-Id: Ia6936675684e3eaf2a57e2d28e465b1f0768249b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49512
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
|
|
Use same indents for switch/case to fix linter issues.
Change-Id: I5c6abf5b918bac3df8d7617824392f2ec932cb32
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Platform can now select VGA_ROM_RUN_DEFAULT Kconfig to perform graphics
initialization for PCI-E based discrete card through VGA OpRom
(SoC or Mainboard user can't select VGA_ROM_RUN directly because
it's part of choice option).
(Note: Some payloads, like SeaBIOS, are also able to run Option ROMs,
so coreboot does not need to enable VGA_ROM_RUN Kconfig)
For payload like depthcharge, create VGA_ROM_RUN_DEFAULT Kconfig
for mainboard to select design with DGPU where OpROM is embedded
inside the DGPU card.
Allow auto selection of VGA_ROM_RUN_DEFAULT from VGA_BIOS Kconfig.
Also NO_GFX_INIT Kconfig to avoid running VGA_ROM_RUN
by default in case SeaBIOS is used.
TEST=Able to get Pre-OS splash screen with AMD Radeon RX 5700 PCI-E
DGPU when mainboard user selects VGA_ROM_RUN_DEFAULT.
Change-Id: Iecb2fcdb105af449bc20ad727759cdef17d5e376
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49016
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add the register PNP_IO4, which will be used by IT5570E in CB:48894.
Change-Id: Ic820295247323f546d4c48ed17cfa4eab3dc5e92
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48924
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Introduce a new device `gpio` that is going to be used for generic
abstraction of gpio operations in the devicetree.
The general idea behind this is that every chip can have gpios that
shall be accessible in a very generic way by any driver through the
devicetree.
The chip that implements the chip-specific gpio operations has to assign
them to the generic device operations struct, which then gets assigned
to the gpio device during device probing. See CB:48583 for how this gets
done for the SoCs using intelblocks/gpio.
The gpio device then can be added to the devicetree with an alias name
like in the following example:
chip soc/whateverlake
device gpio 0 alias soc_gpio on end
...
end
Any driver that requires access to this gpio device needs to have a
device pointer (or multiple) and an option for specifying the gpio to be
used in its chip config like this:
struct drivers_ipmi_config {
...
DEVTREE_CONST struct device *gpio_dev;
u16 post_complete_gpio;
...
};
The device `soc_gpio` can then be linked to the chip driver's `gpio_dev`
above by using the syntax `use ... as ...`, which was introduced in
commit 8e1ea52:
chip drivers/ipmi
use soc_gpio as gpio_dev
register "bmc_jumper_gpio" = "GPP_D22"
...
end
The IPMI driver can then use the generic gpio operations without any
knowlege of the chip's specifics:
unsigned int gpio_val;
const struct gpio_operations *gpio_ops;
gpio_ops = dev_get_gpio_ops(conf->gpio_dev);
gpio_val = gpio_ops->get(conf->bmc_jumper_gpio);
For a full example have a look at CB:48096 and CB:48095.
This change adds the new device type to sconfig and adds generic gpio
operations to the `device_operations` struct. Also, a helper for getting
the gpio operations from a device after checking them for NULL pointers
gets added.
Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with
CB:48711 and OCP DeltaLake with CB:48672.
Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786
Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Also tidy up some adjacent comments.
Change-Id: I2e881900a52e42ab3f43ffe96cfbdcc63ff02e23
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: I346040eb6531dac6c066a96cd73033aa17f026d0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Many uses of `azalia_set_bits` are used to toggle the reset bit. To
avoid having to repeat the register operations and the corresponding
comment, create two helpers with self-explanatory names. They will be
put to use in subsequent commits, with one change for each function.
Change-Id: If0594fdaf99319f08a2e272cd37958f0f216e654
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The `4` here doesn't have to do with the size of u32. Instead, it is
because the verb header contains the number of jacks, which is the
number of four-verb groups.
Change-Id: I3956ce5ec2a7abc29982504cf75b262a1c098af5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
This function is equivalent to `azalia_find_verb` in its current form,
so replace them. Also, adapt and move the function description comment.
Change-Id: I40d1e634c31b00bd7808a651990d9bd6f0d054e9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Allow to specify which table should the verb list be read from.
Change-Id: Id1bc40c4364cda848f416bad9eeab1b8ca3e9512
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The `dev` parameter isn't used anywhere.
Change-Id: I05643f8201137ffe89ded1e3f989c5a0f04e0af1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
To allow dropping copies of this function, make it non-static. Also,
rename it to `azalia_find_verb` as the function is now globally visible.
Finally, replace the copies in chipset code with `azalia_find_verb`.
Change-Id: Ie66323b2c62139e86d3d7e003f6653a3def7b5f2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The other five copies of this function in the tree do not have these
debug prints. Remove them from here for consistency. Note that this
information is already printed elsewhere, so nothing is being lost.
Change-Id: I999032af1628bf8d66a057dc72368f02ef6eb8d1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
There's many copies of this function in the tree. Make the copy in
azalia_device.c non-static and rename it to `azalia_set_bits`, then
replace all other copies with it. Since azalia_device.c is only built
when AZALIA_PLUGIN_SUPPORT is selected, select it where necessary.
This has the side-effect of building hda_verb.c from the mainboard
directory. If this patch happens to break audio on a mainboard, it's
because its hda_verb.c was always wrong but wasn't being compiled.
Change-Id: Iff3520131ec7bc8554612969e3a2fe9cdbc9305e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Currently it's not possible to add multiple graphics drivers into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics drivers can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace all duplications of fill_fb_framebuffer and provide a single one
in edid_fill_fb.c. Should not change the current behaviour as still only
one graphic driver can be active at time.
Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
A mainboard-level hda_verb.c may not exist for variant setups.
Change-Id: If2c92d9498cba7c084ef4c7065bc4ae83c7da761
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48353
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
Only two definitions are actually used somewhere, the rest is unused.
Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a NULL check and only skip setting the default operations
if `.ops` was set by a driver. It's fairly unlikely that some-
body adds a driver and forgets the `.ops` pointer. So this is
mostly to increase readability: Nobody should have to wonder
if we're missing a NULL-check.
The condition is moved out of the loop to reduce indentation
levels. Alternatively, we could jusk skip drivers that don't
have `.ops` set (i.e. continue the loop).
Change-Id: I5dcc05ebb092fb9c4be929c81ea2b05a10b1311b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46297
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Devices of class type "system" are arbitrary devices and it's not clear
which of them need bus mastering. Therefore, enable bus mastering
conditionally based on Kconfig option PCI_ALLOW_BUS_MASTER_ANY_DEVICE.
Change-Id: Ia04e83606a0a081c0758ec59e52627aa1dbd2622
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ic7cacce28f473dda76ca203016dbb8e00149a990
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Move this function to pci_ops.c, which is already included in the smm
build. This is required to use this function in elog functionality,
which is called from SMM.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie5583c04366c9a16bc1b00a6892d39eeafe5da49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47260
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Instead of checking whether the return value equals -1, just check if it
is negative. Some Azalia implementations already do it, but most do not.
Change-Id: I43ce72a01c07eff62d645db28c09584b386532ff
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46727
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As an intermediate step for CB:45150, add an additional Kconfig option
which is used to configure bus mastering for any devices and use
PCI_ALLOW_BUS_MASTER to allow coreboot setting the bus mastering bit in
general.
Change-Id: I33b37a79022007a16e97350db61575b63fa8256b
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45149
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I902915133035fb2adff7edd9c931d4b1d3e7dc40
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This change allows a generic device to be described in the devicetree
under a PCI device, such as a root port.
Previously any device under a PCI device was expected to also be a PCI
device and that does not allow for a virtual/generic device to be
present, for example to provide ACPI properties for a root port.
The changes are:
- Ignore non-PCI devices found under a PCI device when scanning and do
not print an error for each devfn scanned.
- Don't treat non-PCI devices as leftover and remove them, instead
enable them as a static device.
- Don't attempt to configure a static device in the tree that is not a
PCIe device type.
With these changes it is now possible to have a generic device under a
PCI device, for example in a USB4/TBT root port (PCIe hotplug device)
this generic device will add ACPI properties for the PCIe tunnel routed
to the external port:
device pci 07.0 on
chip soc/intel/common/block/pcie
device generic 0 on end
end
end
TEST=boot on volteer with the USB4 root port devices in chipset.cb and
ensure they are enabled properly and there are no errors printed in the
coreboot log, and that the device properties are created in the SSDT.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I56a491808067dc862a7adfd46852f0bd6b41cd95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46542
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The work done by enable_static_devices() and scan_generic_bus()
is common and can be used by other device handlers to enable a
single static device.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ibfde9c4eb794714ebd9800e52b91169ceba15266
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This change adds a helper function `pci_dev_is_wake_source()` that
checks PME_STATUS and PME_ENABLE bits in PM control and status
register to determine if the given device is the source of wake.
BUG=b:169802515
BRANCH=zork
Change-Id: I06e9530b568543ab2f05a4f38dc5c3a527ff391e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Coverity detects the dev->link_list NULL pointer dereferences while
calling report_resource_stored. Add sanity check for dev->link_list to
prevent NULL pointer dereference.
Found-by: Coverity CID 1419488
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I953a6524fff509a7833896392b25a3245c8cd705
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ief990b4174d13b3472ac75a042ae8d878640dda3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Check that nobody misuses the Kconfigs SUBSYSTEM_*_ID. They are meant to
be used for overriding the devicetree subsystem ids locally but shall
not be added to a board's Kconfig. Instead, the devicetree option
`subsystemid` should be used.
Add a linter script for this that finds and warns about such misuse.
Also add a note in the Kconfigs' description.
TEST=CB:45513
Change-Id: I21c021c718154f1396f795a555af47a76d6efe03
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
When <device/pnp.h> is needed, it is supposed to provide <device/pnp_def.h>.
So remove redundant <device/pnp_def.h> includes.
I'll remove also <device/pnp_type.h> in a separate patch.
Change-Id: Ib9903ae456c32db4ba346020659c17c27a939e89
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add method for converting DDR4 speed in MHz to MT/s. Checks that MHz is
within a speed grade range.
BUG=b:167155849
TEST=ddr4-test unit test
BRANCH=Zork
Change-Id: I1433f028afb794fe3e397b03f5bd0565494c8130
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I68590605e261ecaace9f3cea28cfa6ec3b913a8a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The bus master bit is set at many places in coreboot's code, but the
reason for that is not quite clear. We examined not setting the
bus master bit whereever possible and tried booting without it,
which worked fine for internal PCI devices but not for PCIe. As a PCIe
device we used a Samsung M.2 NVMe SSD.
For security reasons, we would like to disable bus mastering where
possible. Depending on the device, bus mastering might get enabled
by the operating system (e.g. for iGPU) and it might be required for
some devices to work properly. However, the idea is to leave it disabled
and configure the IOMMU first before enabling it.
To have some sort of "backwards compatibility", add a method which
configures bus mastering based on an additional config option. Since
CB:42460 makes usage of this treewide, enable it by default to keep the
current behaviour for now.
Tested with Siemens/Chili, a Coffee Lake based platform.
Change-Id: I876c48ea3fb4f9cf7b6a5c2dcaeda07ea36cbed3
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42459
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Remaining notable differences at function 'codec_detect(u8 *base)'.
Change-Id: Ia64e0ba10f145cf2eae0cb2ff4951b1455963d5d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ia0ba6c2f76221123acd3c5303b0a018c651f3617
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44125
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The DISPLAY_3D class is for graphics devices that are not connected to
displays. This includes GPUs implementing muxless Nvidia Optimus.
According to CB:31502, some AMD GPUs are identified as DISPLAY_OTHER.
Therefore, consider the entire DISPLAY class as GPUs.
Change-Id: I0f203a013c010337ae7a9fddbd13330f380050a4
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I5d3a5ede47aefc7cc2ee330f8a0bcded16138764
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44173
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit ad247ac5d8ef4a38bd1d61fbd28076f343a46c5c.
It doesn't work like this. The `dev->enable` field has already been
updated and is always `0` at this point.
Change-Id: I5b3560dcea2f226c841f4823526db2fdab149d22
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
I would like to make assertions evaluate at compile time where possible,
but sometimes people used a literal assert(0) to force an assertion in a
certain code path. We already have BUG() for that so let's just replace
those instances with that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I674e5f8ec7f5fe8b92b1c7c95d9f9202d422ce32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add find_dev_nested_path helper function to simplify finding deeply
nested devices.
BUG=b:157580724
TEST=Find bluetooth device on dalboz
Change-Id: I48fa5fcad0030fb6dcea97b9fc76e1d3d3f9b28f
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Looks like no one really knows what this bit would be useful for, nor
when it would need to be set. Especially if coreboot is setting it even
on PCI *Express* bridges. Digging through git history, nearly all
instances of setting it on PCIe bridges comes from i82801gx, for which
no reason was given as to why this would be needed. The other instances
in Intel code seem to have been, unsurprisingly, copy-pasted.
Drop all uses of this definition and rename it to avoid confusion. The
negation in the name could trick people into setting this bit again.
Tested on Asrock B85M Pro4, no visible difference.
Change-Id: Ifaff29561769c111fb7897e95dbea842faec5df4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@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>
|
|
Change-Id: Iaf22dc1986427e8aa4521b0e9b40fafa5a29dbbd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
One would expect disabled devices to not be present. So, don't print
misleading warnings about it, because it only confuses people.
Change-Id: I0f14174a1d460a479dc9f15b63486f4f27b8f67c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
It does nothing useful anymore. Drop it before it grows moss.
Change-Id: I5f95376fe2a38eda5d819c53edb85ef11ab7a0f1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43591
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is some boilerplate required to iterate over the USB supported
protocol structs. Encapsulate all the in a method to make the callers
simpler.
BUG=b:154756391
TEST=Built test trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I401f10d242638b0000ba697573856d765333dca0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43352
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: Id3f9dd264e82f93a438422e388d70e3f88ae0df9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
|
|
Kconfig 4.17 started using the $(..) syntax for environment variable
expansion while we want to keep expansion to the build system.
Older Kconfig versions (like ours) simply drop the escapes, not
changing the behavior.
While we could let Kconfig expand some of the variables, that only
splits the handling in two places, making debugging harder and
potentially messing with reproducible builds (e.g. when paths end up
in configs), so escape them all.
Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
|
|
This decouples the linear framebuffer type from the symbols needing it.
Change-Id: I733e630e0aa2fb2947d079caef26253ce443fe91
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42432
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
Change-Id: I599995b3ed5c4dfd578c87067fe8bfc8c75b9d43
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42183
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This will allow enumerating an xHCI controller to allow dynamically
generating the ACPI device nodes.
BUG=b:154756391
TEST=Boot trembyle and see capabilities printed on console
xHCI Supported Protocol:
Major: 0x2, Minor: 0x0, Protocol: 'USB '
Port Offset: 1, Port Count: 2
xHCI Supported Protocol:
Major: 0x3, Minor: 0x10, Protocol: 'USB '
Port Offset: 3, Port Count: 1
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
A function pci_dev_disable_bus_master() is created. This function
can be used to disable Thunderbolt PCIe root ports, bridges and
devices for Vt-d based security platform at end of boot service.
BUG=None
TEST=Verified PCIe device bus master enable bit is cleared.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Change-Id: Ie004a94a49fc8f53c370412bee1c3e7eacbf8beb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This change makes the following improvements to debug logging in
resource allocator:
1. Print depth is added to functions in pass 1 to better represent how
the resource requirements of child devices impact the resource windows
for parent bridge.
2. Device path is added to resource ranges to make it easier to
understand what device the resouce ranges are associated with.
3. Prints in pass 2 (update constraints, resource ranges, resource
assignment) are shifted left by 1 to make it easier to visualize
resource allocation for each bridge including domain.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3356a7278060e281d1a57d253537b097472827a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41478
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change updates the log level for prints in resource allocator v4
to BIOS_DEBUG instead of BIOS_SPEW. These are critical in debugging
issues and should be enabled at log level BIOS_DEBUG.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib863619f5e1214e4fe6f05c52be6fa2de36e6c3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41477
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
4G boundary""
This reverts commit e15f352039a371156ceef37f0434003228166e99.
Reason for revert: Resource allocator is split into old(v3) and
new(v4). So, this change to provide an option to allocate prefetch
memory above 4G boundary can be added back. Since the support for
allocating above 4G boundary is available only in resource allocator
v4, Kconfig option is accordingly updated to add depends on
RESOURCE_ALLOCATOR_V4.
Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Addressing comment from CB:41443 that was received after the change
landed. memranges_create_hole() takes size as the last parameter. So,
the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1
as 0x3df is the upper limit of that hole.
Change-Id: I08fca283436924427e12c6c69edced7e51db42a9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change disables the old resource allocator by default and instead
uses the new v4 resource allocator. Only the chipsets that explicitly
select RESOURCE_ALLOCATOR_V3 will continue to use the old v3 resource
allocator.
Change-Id: I2ab9f1d612b5f193f058011a18b1d6373e09f788
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
|
