| Age | Commit message (Collapse) | Author |
|---|
|
By default this limits PCI buses to CONFIG_MMCONF_BUS_NUMBER.
Some platforms have multiple PCI root busses (e.g. xeon_sp), where bus
numbers are limited. This provides a basic check. On some platforms it
looks like programming 0xff to the subordinate bus number confuses and
hangs the hardware.
Change-Id: I0582b156df1a5f76119a3687886c4d58f2d3ad6f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59395
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
|
|
<device/pci.h> chain-includes <device/pci_def.h> & <device/pci_type.h>.
Change-Id: I4e5999443e81ee1c4b1fd69942050b47f21f42f8
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72626
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The patch that introduced the selection of software connection manager,
CB:64561 - 060df17f1d (soc/intel/alderlake/acpi: Add Kconfig options for
SCM and FCM) added a default to enable the software configuration
manager directly in the choice.
This leads to warnings when running make menuconfig:
src/soc/intel/alderlake/Kconfig:439:
warning: defaults for choice values not supported
src/soc/intel/meteorlake/Kconfig:337:
warning: defaults for choice values not supported
src/soc/intel/tigerlake/Kconfig:299:
warning: defaults for choice values not supported
I'm not sure why the Kconfig linter didn't catch this, but this
issue is currently breaking the build for me. This patch fixes
it so that instead of setting the default directly, a new Kconfig
value is selected that then sets the default correctly.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I674046a93af8f7c2f3003900804deefa89dae295
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71776
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
|
|
A mainboard port needs to:
- select `CONFIG_MAINBOARD_HAS_EARLY_LIBGFXINIT'
- implement the Ada package `GMA.Mainboard' with a single function
`ports' that returns a list of ports to be probed for displays.
- set the desired `GFX_GMA_DEFAULT_MMIO' IO memory address to use
in romstage (and ramstage) for the graphic device.
BUG=b:252792591
BRANCH=firmware-brya-14505.B
TEST=libgfxinit compiles in romstage.
libgfxinit successfully executes in romstage and ramstage using
the requested MMIO setting on skolas.
Change-Id: I3c2101de10dc5df54fe873e43bbe0f1c4dccff44
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70276
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Software Connection Manager doesn't work with Linux 5.13 or later,
resulting in TBT ports timing out. Not advertising this results
in Firmware Connection Manager being used and TBT works
correctly.
Add Kconfig options to chose between SCM (Software Connection
Manager) and FCM (Firmware Connection Manager). FCM is primary, as
it's more compatible save for ChromeOS devices as ChromeOS uses
SCM.
Linux patch:
torvalds/linux@c6da62a
c6da62a219d028de10f2e22e93a34c7ee2b88d03
Tested with StarBook Mk VI (i7-1260P).
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: Iac31d37c0873f41f7b14e1051fe214466d1ebdd8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Move specific enum ddr3_module_type to <device/dram/ddr3.h>.
Change-Id: I8fd7892dda26158a5bdd6cd4972c7859a252153e
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71547
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Move specific enum ddr2_module_type to <device/dram/ddr2.h>.
Change-Id: I748658f9b349bff9b1ebe2c0a6acf71bf2a221ce
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71546
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Increase the default linear framebuffer max height/width for desktops
so that native display resolution works properly on 2160p and 1440p
ultrawide displays.
TEST=build/boot google/fizz, verify libgfxinit display init works
properly on 3440x1440p and 3840x2160p displays.
Change-Id: I95a1f1275a4faea195b73997c648023119807958
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Unlike gcc, a clang build will fail when only a comment is used to
indicate that the fallthough is intended. To fix the clang build, use
__fallthrough instead. This will fix the build errors introduced by
commit f45c7671d9ed ("Set x86_64 as supported architecture for clang")
that enabled clang builds for a case that uses yabel to run the VBIOS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4ed337025adeb833f352d198fc0f13b5e1c209c4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70889
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Don't rely on this being 0.
Change-Id: I7c0d16b6a265bf9c7abcfdf2f18a43706ee03ea1
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69752
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
<device/mmio.h>` chain-include `<arch/mmio.h>:
https://doc.coreboot.org/contributing/coding_style.html#headers-and-includes
Also sort includes while on it.
Change-Id: Ie62e4295ce735a6ca74fbe2499b41aab2e76d506
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
This patch provides helper functions to read or write a register via the
MDIO bus. They can be used from drivers to easily access registers on
the MDIO bus.
Change-Id: I293d93435d27269a071b4b9b94a1b55307c575a7
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69611
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch extends the available device paths with a new device 'mdio'.
MDIO is the 'Management Data Input/Output' called interface which is
used to access an Ethernet PHY behind a MAC to change settings. The real
payload data path is not handled by this interface.
To address the PHY correctly on the MDIO bus, there is a 5 bit address
needed, which often can be configured via pins on the mainboard.
Therefore, the new introduced device has an 'addr' field to define its
address. If one wants to use a MDIO device in devicetree, the syntax is
straight forward (example):
device mdio 0x2 on end
As the MDIO interface is driven by the MAC, most likely this MDIO device
will be hooked in as a child device of the (PCI attached) MAC device.
With the new introduced ops_mdio a new interface is added to provide an
API for read and write access over MDIO.
Change-Id: I6691f92c4233bc30afc9029840b06f74bb1eb4b2
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69382
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I11593245fedc26489e3506d773aaff1ad34188b1
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69804
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add pcie_find_dsn() to detect and match PCIe device serial
number. In addition, vendor ID is matched when provided.
Change-Id: I54b6dc42c8da47cd7b4447ab23a6a21562c7618
Signed-off-by: Jonathan Zhang <jonzhang@meta.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
|
|
This option is not working so don't advertise it.
Change-Id: I910162756a567289b2484a5445360a3197ae848c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69506
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
The function pci_scan_bus had 3 post codes in it:
0x24 - beginning
0x25 - middle
0x55 - end
I got rid of the middle postcode and used 0x25 for the code signifying
the end of the function. I don't think all three are needed.
0x24 & 0x25 postcodes are currently also used in intel cache-as-ram
code. Those postcodes should be adjusted to avoid conflicting.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I19c9d5e256505b64234919a99f73a71efbbfdae3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
It is no longer necessary to explicitly add "ERROR: "/"WARNING: " in
front of every BIOS_ERR/BIOS_WARN message.
Change-Id: I22ee6ae15c3d3a848853c5460b3b3c1795adf2f5
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
No platform uses this anymore.
Change-Id: Ifccb59ae45daa8fec41a9a2d46c628ff24a0c998
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69140
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Currently, we're building support for all memory types into every board,
and letting the linker remove anything that isn't needed. This is okay,
but it'd be nice to be able to build in just what's actually needed.
This change adds options to specify both what is used and what is not.
By doing it that way, the default values don't change, but platforms can
start removing support for memory types that are not needed. When all
platforms (SoCs, CPUs and/or Northbridge chips) specify what memory
types they support, the defaults on the options to use a particular
memory type can be set to no, and the options not to use a memory type
can be removed.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I07c98a702e0d67c5ad7bd9b8a4ff24c9288ab569
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68992
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Also sort includes.
Change-Id: I1727bf56b4090d040aab413006dec7aca0587d44
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Idd78271f2158bdc29ce9ac8d81f46ad8cbe84c5e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I8ea6e773d858b30d75ff93d4fe07301f3825c1cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68240
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
add functions to check whether a device is enabled pci
device or a pci device on a specific bus number.
TEST: compile and qemu run successfully
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: I3257c8404017372f6cdd9f6cf9453502447343a0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68101
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I7e84760566db5da7ff88dcbe9fb028ebcb390bdc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68043
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
use is_enabled_cpu() on cycles over device list to check
whether the current device is enabled cpu.
TEST: compile test and qemu run successfully with coreinfo
payload
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: If64bd18f006b6f5fecef4f606c1df7d3a4d42883
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67797
Reviewed-by: Tim Wawrzynczak <inforichland@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add function defs and prototypes of functions checking whether
a device is {a cpu,an enabled cpu}
TEST: compile test and qemu executed successfully with
coreinfo payload
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Change-Id: Iabc0e59d604ae4572921518a8dad47dc3d149f81
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Most of these changes are suggested by clang-format(13.0-54) tool on
Debian testing.
Change-Id: I9bf5f516db4f12ffe1e9a714c7a8ae179c12b149
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Refer to PCI Express Base rev6.0 v1.0, 4.2.7 Link Training and Status
State Rules, Lane Error Status is normal to record the error when link
training. To make sure Lane Error Status is correct in OS runtime,
add a Kconfig PCIEXP_LANE_ERR_STAT_CLEAR that clears the PCIe lane error
status register at the end of PCIe link training.
Test=On Crater Lake, lspci -vvv shows
bb:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
(prog-if 00 [Normal decode])
Capabilities: [a30 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn- PerformEqu-
LaneErrStat: LaneErr at lane: 0
Signed-off-by: Wilson Chou <Wilson.Chou@quantatw.com>
Change-Id: I6344223636409d8fc25e365a6375fc81e69f41a5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
|
|
Add the missing spaces to two log message, like the one below.
WARNING: Device PCI: 03:00.0 requests a BAR with34 bits of address space, which coreboot is notconfigured to hand out, truncating to 29 bits
Change-Id: If933d8fb0db5b58ff12f043cc73172a3f6ffc624
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
The top-down allocation feature was merged prematurely before
platforms that don't report their resources correctly were fixed.
Let's turn it off by default.
Change-Id: I982e6d7355b9e689de10357d6c16ed718705270e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67328
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
This reverts commit 117e436115484f0ce184114b22b716616592e77e.
Depends on top-down allocation to keep the behavior to place
hot-plug reservations above 4G. The latter was merged prema-
turely, though.
Change-Id: I5721cb84b29fc42240dff94f49a94461d88e7fbc
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67329
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
We currently have two competing mechanisms to limit the placement of
resources:
1. the explicit `.limit` field of a resource, and
2. the IORESOURCE_ABOVE_4G flag.
This makes the resource allocator unnecessarily complex. Ideally, we
would always reduce the `.limit` field if we want to "pin" a specific
resource below 4G. However, as that's not done across the tree yet,
we will use the _absence_ of the IORESOURCE_ABOVE_4G flag as a hint
to implicitly lower the `limit` of a resource. In this patch, this
is done inside the effective_limit() function that hides the flag
from the rest of the allocator.
To automatically place resources above 4G if their limit allows it,
we have to allocate from top down. Hence, we disable the prompt for
RESOURCE_ALLOCATION_TOP_DOWN if resources above 4G are requested.
One implication of the changes is that we act differently when a
cold-plugged device reports a prefetchable resource with 32-bit
limit. Before this change, we would fail to allocate the resource.
After this change, it forces everything on the same root port below
the 4G line.
A possible solution to get completely rid of the IORESOURCE_ABOVE_4G
flag would be rules to place resources of certain devices below 4G.
For instance, the primary VGA device and storage and HID devices
could be made available to a payload that can only address 32 bits.
For now, effective_limit() provides us enough abstraction as if the
`limit` would be the only variable to consider. With this, we get
rid of all the special handling of above 4G resources during phase 2
of the allocator. Which saves us about 20% of the code :D
Change-Id: I4c7fcd1f5146f6cc287bd3aa5582da55bc5d6955
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65413
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The `IORESOURCE_ABOVE_4G` flag was only explicitly set for our dummy
device that reserves resources behind a hotplug port. The current re-
source allocator implicitly extends this to all devices below the port,
including real ones. Let's make that explicit, so future changes to the
allocator can't break this rule.
Change-Id: Id4c90b60682cf5c8949cde25362d286625b3e953
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66719
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
|
|
Add option to resource allocator v4 that restores the top-down
allocation approach at the domain level.
This makes it easier to handle 64-bit resources natively. With
the top-down approach, resources that can be placed either above
or below 4G would be placed above, to save precious space below
the 4G boundary.
Change-Id: Iaf463d3e6b37d52e46761d8e210034fded58a8a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41957
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Some devices require that several bytes are written with a single I2C
write command. Extend the i2c_bus interface functions and add both, read
and write for more than one byte at a defined byte offset.
Change-Id: I0eec2e1d4185170f02b4ab35aa6546dc69569303
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67098
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
|
|
Change-Id: I52548e544165b4732d9989da6455c8fd77bf99d3
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
Change-Id: I80fccfa6d108b68d6f33a3d47766205b423a41ff
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67058
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
|
|
It seems pass 1 and 2 were inconsistent. The first would account for
resources with a limit of 0 even though the second can't assign anything
for them.
Change-Id: I86fb8edc8d4b3c9310517e07f29f73a6b859a7c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65402
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
If we have a PCIe root port without `ops_pci` or without
`get_ltr_max_latencies`, the parent device wouldn't be PCI.
Hence, check for a PCI path early.
Change-Id: I358cb6756750bb10d0a23ab7133b917bfa25988b
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
As the frequency field in the SMBIOS type 17 table is deprecated,
we need to provide the maximum and configured speed in MT/s. Add
a method to convert from frequency to MT/s using a lookup table.
BUG=b:239000826
TEST=Build and verify with other patches in train
Change-Id: I0402b33a667f7d72918365a6a79b13c5b1719c0d
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
|
|
The PCIe spec explicitly states that the bottom-two bits of the next
offset are reserved for future use and should be masked. We can also
change the loop condition to avoid wrong offsets below 0x100 (exten-
ded capabilities always reside in the extended config space).
The whole patch series was tested on Google Samus and keeps the L1ss
configuration of the WiFi device in tact.
Change-Id: I0b622a0ce0a4a1127d266226ade0ec1e66e9fb79
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66459
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add some inline functions for the bit-wise operations, change the loop
body to an if-bail-out style and remove stateful variables.
Change-Id: Ia8db915f375737064e3486d313383d9b6c3eb2b8
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66458
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Keeping these checks in generic code seems rather dangerous.
In theory, it could lead to endless loops even for compliant
devices, if we accidentally detect arbitrary register contents
as capability and use them as a pointer to another one. Not
to forget that the register reads can have side effects.
All users of this `cafe` have been converted to use
pciexp_find_ext_vendor_cap().
Change-Id: I70d21534e04282a4156572a290b83c46be085e0c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66456
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
We have this quirk in our tree since the introduction of L1-substate
support[1]. The way we searched for this capability was rather crude:
We simply assumed that it would show up in the first data word of
another capability.
As it turned out that it is actually a proper vendor-specific capa-
bility that we are looking for, we can drop some of the mystic code.
This was confirmed to work on the device that was originally used
during development, Google/Samus.
[1] commit 31c6e632cf (PCIe: Add L1 Sub-State support.)
Change-Id: I886fb96e9a92387bc0e2a7feb746f7842cee5476
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66455
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Vendors can choose to add non-standard capabilities inside a
Vendor-Specific Extended Capability. These are identified by
the Extended Capability ID 0x0b.
Change-Id: Idd6dd0e98bd53b19077afdd4c402114578bec966
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Move the `offset` parameter into pciexp_find_extended_cap(). If it's
called with `0`, we start a new search. If it's an existing offset,
we continue the search.
This makes it easier to search for multiple occurences of a capa-
bility in a single loop.
Change-Id: I80115372a82523b90460d97f0fd0fa565c3f56cb
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66453
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
If we already encountered the last extended capability in the
list, we'd call pciexp_get_ext_cap_offset() with `offset == 0`.
So it also needs to check if the passed offset is valid.
As there were no callers of pciexp_find_next_extended_cap()
yet, pciexp_get_ext_cap_offset() was only ever called with
`PCIE_EXT_CAP_OFFSET`.
Change-Id: I155c4691a34ff16661919913a3446fa915ac535e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66452
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
It's possible that some BARs are not got their resource successfully
mapped, e.g. when these BARs are too large to fit into the available
MMIO window.
Not assigned resources might be with base address as 0x0. During
global resource search, these not assigned resources should not be
picked up.
One example is MTRR calculation. MTRR calculation is based on global
memory ranges. An unmapped BAR whose base is left as 0x0 will be
mistakenly picked up and recognized as an UC range starting from 0x0.
Change-Id: I9c3ea302058914f38a13a7739fc28d7f94527704
Signed-off-by: Shuo Liu <shuo.liu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66347
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
|
|
coreboot uses TianoCore interchangeably with EDK II, and whilst the
meaning is generally clear, it's not the payload it uses. EDK II is
commonly written as edk2.
coreboot builds edk2 directly from the edk2 repository. Whilst it
can build some components from edk2-platforms, the target is still
edk2.
[1] tianocore.org - "Welcome to TianoCore, the community supporting"
[2] tianocore.org - "EDK II is a modern, feature-rich, cross-platform
firmware development environment for the UEFI and UEFI Platform
Initialization (PI) specifications."
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I4de125d92ae38ff8dfd0c4c06806c2d2921945ab
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65820
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Looking into pciexp_get_ext_cap_offset() it seems a little hackish
and prone to endless loops. Either it should limit the loop or bail
out when pci_read_config32() returns 0xffffffff, meaning "Unsupported
Requests".
This commit fixes an endless loop when the queried PCIe device is
downstream of a legacy PCI bus which doesn't support extended config
space, thus pci_read_config32() will return 0xffffffff, for example,
the combination below with CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS
enabled.
TEST=Build and boot to OS in ASUS P8C WS with the following
peripherals and CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS enabled:
00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series
Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4)
00:1c.4/00.0 SATA controller [0106]: Marvell Technology Group Ltd.
88SE9170 PCIe 2.0 x1 2-port SATA 6 Gb/s Controller [1b4b:9170]
(rev 13)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev a4)
00:1e.0/00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8111 PCI
Express-to-PCI Bridge [10b5:8111] (rev 21)
00:1e.0/03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc.
VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044]
(rev c0)
00:1e.0/00.0/00.0 Network controller [0280]: Qualcomm Atheros AR93xx
Wireless Network Adapter [168c:0030] (rev 01)
with 00:1c.4/00.0 being successfully tuned with pciexp_tune_dev(), and
00: 1e.0/00.0/00.0 not tuned as expected.
Change-Id: Ibb92548c47288b40e851fcc0a8a37937e8bdbf3c
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66439
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Some PCI capabilities should only be enabled if it is available not
only on a device, but also all bridge upstream of it. Checking only
the device and the bridge just above it may not be enough.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I1237d3b4b86dd0ae5eb586e3c3c407362e6ca291
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66383
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
'parent_cap' should be found from 'parent' instead of 'dev'.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I99dab83d90287ca924d30dc4aeac0ff96e877e5c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Use 0x016llx to print device resource info so that both 64bit and
32bit resources could be displayed correctly.
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Change-Id: I0ec4c47cca4a09ceb7dc929efaa5630b1f9df81c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
We actually want the bus driver to process the 1 zero-length write
we are passing. So set the count to 1.
Change-Id: I5a41abb68c27a83715b6baec91ece9fa90b66a8c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66337
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
|
|
As we walk the results of largest_resource(), we actually know that the
condition can only be true for the first return value. So there's no
need to keep track of the first loop iteration.
Change-Id: I6d6b99e38706c0c70f3570222d97a1d71ba79744
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
While what this round() function does is documented, it still seems
hard to follow what happens when reading a call. I tried to come up
with a better name, but eventually reading an explicit ALIGN_UP()
worked best.
Change-Id: Ifd49270bbae0ee463a996643fc76bce1f97ec9b7
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65400
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
These comments are a very nice example of documented code. The
comment blocks use the full, allowed line length, though. That
is nice for code, but can make text blocks harder to read. So
reflow the comments to a 72-char width (like we use in emails
and commit messages).
Also add some articles where they seemed missing and fix some
smaller nits.
Change-Id: If4cdbb383cf67f01200c8e4163fc3c576a5c3a87
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The comment said special care needs to be taken if a resource cannot
be allocated. However, the opposite seems true: There is nothing to
be done, we simply leave the resource w/o the IORESOURCE_ASSIGNED
flag. There's also no code to be found that would currently do some-
thing special. allocate_child_resources() directly continues with
the next resource after printing an error.
Change-Id: I21acbc891ea4dfb62decf9abe0ace91016486116
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
These should help to make the reviews as platforms
remove KiB scaling.
Change-Id: I40644f873c0ea993353753c0ef40df4c83233355
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Function fixed_io_resource() and alias io_resource() were
previously unused. Unlike previously, IORESOURCE_STORED flag
needs to be set by the caller, when necessary.
For fixed resources, fields alignment, granularity and
limit need not be initialised, as the resource cannot
be moved. It is assumed the caller provides valid base
and size parameters.
Change-Id: I8fb4cf2dee4f5193e5652648b63c0ecba7b8bab2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55458
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Unlike fixed_mem_resource_kb() the arguments are not in KiB.
This allows coccinelle script to assign the base and size
without applying the KiB division or 10 bit right-shift.
Unlike with fixed_mem_resource_kb() the IORESOURCE_STORED flag is
passed in the flags parameter until some inconsistencies in the tree
get resolved.
Change-Id: I2cc9ef94b60d62aaf4374f400b7e05b86e4664d2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55436
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
There is a lot of going back-and-forth with the KiB arguments, start
the work to migrate away from this.
Change-Id: I329864d36137e9a99b5640f4f504c45a02060a40
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64658
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Improves readability in console log.
Change-Id: Ied0cbb746ff3ca6250ed9322dfb2726da0949e16
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65230
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
|
|
When trying to find the parent i2c bus of a given device, ensure that
the bus link doesn't point to itself, else we'll get stuck in an
infinite loop.
Change-Id: I56cb6b2a3e4f98d2ce3ef2d8298e74d52661331c
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65229
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
This patch adds the I2C equivalent of an SMBus quick write to an I2C
device, which is used by some I2C drivers as a way to probe the
existence (or absence) of a certain device on the bus, based on
whether or not a 0-byte write to an I2C address is ACKed or NACKed.
i2c_dev_detect() is implemented using the existing i2c bus ops transfer()
function, so no further work is needed for existing controller drivers
to utilize this functionality.
Change-Id: I9b22bdc0343c846b235339f85d9f70b20f0f2bdd
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
|
|
When a PCI resource is marked as 64-bits, the IORESOURCE_ABOVE_4G flag
needs to be passed to the v4 allocator to ensure that the resource will
be allocated in a range large enough to succeed.
BUG=b:214443809
TEST=agah can successfully allocate all of the Nvidia GN20 BARs
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I3f16f52f2a64f8728853df263da29871dca533f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
|
|
coreDOOM is a port of DOOM to libpayload, based on the doomgeneric
source port. It renders the game to the coreboot linear framebuffer,
and loads WAD files from CBFS.
Tested with QEMU i440fx/q35 and a Dell Latitude E6400 using the
libgfxinit provided linear framebuffer.
Project page: https://github.com/nic3-14159/coreDOOM
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: Ice0403b003a4b2717afee585f28303c2f5abea5d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57222
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@tutanota.com>
|
|
This will replace LOG_{MEM/IO}_RESOURCE macros once
the new resource constructors are available.
Change-Id: I21b030dc42dcb8e462b29f49499be5fd31ea38f5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
device.c should not hold arch specific code.
Change-Id: I9dfdb905a83916c0e9d298e1c38da89f6bc5e038
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64297
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
|
|
Change-Id: I81bf00af1b56a0181c376db92f5f85297b6993ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: If795087ecdaea24ad7834dcc6d5bf6a72f2aea8f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63208
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Clang is unhappy about codepath of an invalid parameter because
variables remain unset.
Change-Id: I1ba392a48cf3f81a29d9645e5cf220b122d588af
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Without setting the set_resources field for pciexp_hotplug_dummy_ops,
we will get an error during pciexp_hotplug_dummy.
[ERROR] NONE missing set_resources
Because the set_resources field is considered mandatory, explicitly set
it as no-op noop_set_resources.
BUG=b:220639445
TEST=emerge-brya coreboot
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Change-Id: Ifee7479c69cf16025dbd4e3924056ed7f8e253cf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63101
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch introduces CONFIG_I2C_TRANSFER_TIMEOUT_US,
which controls how long to wait for an I2C devices to
produce/accept all the data bytes in a single transfer.
(The device can delay transfer by stretching the clock of
the ack bit.)
The default value of this new setting is 500ms. Existing
code had timeouts anywhere from tens of milliseconds to a
full second beween various drivers. Drivers can still have
their own shorter timeouts for setup/communication with the
I2C host controller (as opposed to transactions with I2C
devices on the bus.)
In general, the timeout is not meant to be reached except in
situations where there is already serious problem with the
boot, and serves to make sure that some useful diagnostic
output is produced on the console.
Change-Id: I6423122f32aad1dbcee0bfe240cdaa8cb512791f
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
|
|
Shorten define names containing PCI_{DEVICE,VENDOR}_ID_ with
PCI_{DID,VID}_ using the commands below, which also take care of some
spacing issues. An additional clean up of pci_ids.h is done in
CB:61531.
Used commands:
* find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]\{2\}\([_0-9A-Za-z]\{8\}\)*[_0-9A-Za-z]\{0,5\}\)\t/PCI_\1ID_\3\t\t/g'
* find -type f -exec sed -i 's/PCI_\([DV]\)\(EVICE\|ENDOR\)_ID_\([_0-9A-Za-z]*\)/PCI_\1ID_\3/g'
Change-Id: If9027700f53b6d0d3964c26a41a1f9b8f62be178
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39331
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Both the secondary and subordinate bus numbers are configured in this
function but it's not easy to search for in the tree as the PCI writes
are hidden inside a bigger write to 'PCI_PRIMARY_BUS'. Use separate
variables and PCI config writes to improve the readability.
Change-Id: I3bafd6a2e1d3a0b8d1d43997868a787ce3940ca9
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59131
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
PCI bus 0 is not below any PCI device. In case of pci_domain_scan_bus(),
it's our virtual `domain` device.
Expecting a PCI device above bus 0 resulted in undefined behavior for
all boards with PCI. Only boards with a PCI device 00:00.0 that looked
like a PCIe bridge showed issues, though (e.g. OCP/DeltaLake).
Change-Id: I1fd68b9dc0d2e388ec2bbba4adbadd33e14f0171
Signed-off-by: Nico Huber <nico.h@gmx.de>
Fixes: commit 777ffff442 (device/pci_device.c: Scan only one device for PCIe)
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62376
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Get rid of Kconfig symbol introduced at commit 5d31dfa8
High Definition Audio Specification Revision 1.0a says, there
are 15 SDIWAKE bits.
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: Ib8b656daca52e21cb0c7120b208a2acdd88625e1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62202
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can
indicates support for "Resizable BARs" via a PCIe extended capability.
When support this capability is indicated by the device, the size of
each BAR is determined in a different way than the normal "moving
bits" method. Instead, a pair of capability and control registers is
allocated in config space for each BAR, which can be used to both
indicate the different sizes the device is capable of supporting for
the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and
to also inform the device of the size that the allocator actually
reserved for the MMIO range.
This patch adds a Kconfig for a mainboard to select if it knows that it
will have a device that requires this support during PCI enumeration.
If so, there is a corresponding Kconfig to indicate the maximum number
of bits of address space to hand out to devices this way (again, limited
by what devices can support and each individual system may want to
support, but just like above, this number can range from 20 to 63) If
the device can support more bits than this Kconfig, the resource request
is truncated to the number indicated by this Kconfig.
BUG=b:214443809
TEST=compile (device with this capability not available yet),
also verify that no changes are seen in resource allocation for
google/brya0 before and after this change.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I14fcbe0ef09fdc7f6061bcf7439d1160d3bc4abf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61215
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Some PCIe devices have extended capability lists that contain
multiples instances of the same capability. This patch provides a
function similar to pciexp_find_extended_cap that can be used to
search through multiple instances of the same capability by returning
the offset of the next extended capability of the given type following
the passed-in offset. The base functionality of searching for a given
capability from an offset is extracted to a local helper function and
both pciexp_find_extended_cap and pciexp_find_next_extended_cap use
this helper.
Change-Id: Ie68dc26012ba57650484c4f2ff53cc694a5347aa
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
Change 'printk(BIOS_WARNING, "ERROR:' to printk(BIOS_ERR, "'.
Change-Id: Id25bdb1e6b6d7085eff9c2be8263223a91dff061
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61629
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
|
|
Change-Id: I7fa1f9402b177a036f08bf99c98a6191c35fa0b5
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The object pointed to by the struct device * argument is not modified,
therefore it can be made const.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I300d2a59eb0513ddd08d4f1d2a3c6eb829e3f836
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Unknown if yabel works for X86_64 but now it builds.
Change-Id: Iacdb9fde91a992b5010120f5824383ca4aebdd1a
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59661
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Not tested on hardware.
Change-Id: I8ce8d56da326aeff5ff9b400ded02d4309372519
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Some SOC add PCI root busses structs at runtime without adding a
device struct to the bus because pci_scan_bus does it. An example
would be xeon_sp which has multiple root busses.
TEST: ocp/deltalake boots again.
Change-Id: I81d9c94652e34dbf9e8cec64fc34ef0042563037
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60876
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
|
|
Change-Id: Iba3135178f2d6021702971e4d887e9b4f8afeb76
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60556
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
The `pci_dev_disable_bus_master()` function doesn't need to be guarded
with `CONFIG(PC80_SYSTEM)`, so move it out of the guard.
Change-Id: I813e0f72c3c624c73ab9ecbe7512359608ace927
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60599
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Some device drivers may need to get access to the LTR values for their
respective devices, therefore export this function instead of marking it
static.
BUG=b:204343849
Change-Id: Id372600e8adec0d55d3483726bb9353139685774
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
|
|
Only scan one device if it's a PCIe downstream port.
A PCIe downstream port normally leads to a link with only device 0 on
it. As an optimization, scan only for device 0 in that case.
Signed-off-by: Jianjun Wang <jianjun.wang@mediatek.com>
Change-Id: Id184d03b33e1742b18efb3f11aa9b2f81fa03806
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
|
|
This method will allow preloading the VGA_BIOS_FILE. By preloading the
file, into cbfs_cache we reduce boot time. In the future we can also add
support for loading the second VGA_BIOS_FILE and the DGPU VGA_BIOS_FILE.
BUG=b:179699789
TEST=Boot guybrush to OS and verify 12 ms reduction in boot time
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Icb54fe3a942e9507ff6f1173ba5620a8f4ce6549
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
|
|
The `dev` parameter of the `azalia_codecs_init()` function is not used.
Remove it, and update all call sites accordingly.
Change-Id: Idbe4a6ee5e81d5a7fd451fb83e0fe91bd0c09f0e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59119
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Make the `codec_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codec_init()` for consistency with
the other functions of the API.
Also, update the function's signature to make it more flexible. Remove
the unused `dev` parameter and allow callers to pass the verb table to
use. Update the original call site to preserve behavior.
Change-Id: I5343796242065b5fedc78cd95bcf010c9e2623dd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59117
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Handle the return value of `azalia_program_verb_table()` and print
different messages accordingly.
Change-Id: I99e9e1416217c5e67c529944736affb31f9c7d2f
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59115
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Make the `codecs_init()` function non-static so that it can be used in
other places. Rename it to `azalia_codecs_init()` to avoid name clashes
with static definitions in southbridge code (which will be removed in
subsequent commits).
Change-Id: I080a73102b0c4f9f8a283cd93bba9b3b23169be0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59108
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
List of changes:
1. Create Module Type macros as per Memory Type
(i.e. DDR2/DDR3/DDR4/DDR5/LPDDR4/LPDDR5) and fix compilation
issue due to renaming of existing macros due to scoping the Memory
Type.
2. Use dedicated Memory Type and Module type for `Form Factor`
and `TypeDetail` conversion using `get_spd_info()` function.
3. Create a new API (convert_form_factor_to_module_type()) for
`Form Factor` to 'Module type' conversion as per `Memory Type`.
4. Add new argument as `Memory Type` to
smbios_form_factor_to_spd_mod_type() so that it can internally
call convert_form_factor_to_module_type() for `Module Type`
conversion.
5. Update `test_smbios_form_factor_to_spd_mod_type()` to
accommodate different memory types.
6. Skip fixed module type to form factor conversion using DDR2 SPD4
specification (inside dimm_info_fill()).
Refer to datasheet SPD4.1.2.M-1 for LPDDRx and SPD4.1.2.L-3 for DDRx.
BUG=b:194659789
TEST=Refer to dmidecode -t 17 output as below:
Without this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Unknown
....
With this code change:
Handle 0x0012, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 16 bits
Data Width: 16 bits
Size: 2048 MB
Form Factor: Row Of Chips
....
Change-Id: Ia337ac8f50b61ae78d86a07c7a86aa9c248bad50
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56628
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Currently, the MMCONF Kconfigs only support the Enhanced Configuration
Access mechanism (ECAM) method for accessing the PCI config address
space. Some platforms have a different way of mapping the PCI config
space to memory. This patch renames the following configs to
make it clear that these configs are ECAM-specific:
- NO_MMCONF_SUPPORT --> NO_ECAM_MMCONF_SUPPORT
- MMCONF_SUPPORT --> ECAM_MMCONF_SUPPORT
- MMCONF_BASE_ADDRESS --> ECAM_MMCONF_BASE_ADDRESS
- MMCONF_BUS_NUMBER --> ECAM_MMCONF_BUS_NUMBER
- MMCONF_LENGTH --> ECAM_MMCONF_LENGTH
Please refer to CB:57861 "Proposed coreboot Changes" for more
details.
BUG=b:181098581
BRANCH=None
TEST=./util/abuild/abuild -p none -t GOOGLE_KOHAKU -x -a -c max
Make sure Jenkins verifies that builds on other boards
Change-Id: I1e196a1ed52d131a71f00cba1d93a23e54aca3e2
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57333
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
The `find_resource` function will never return null (will die instead).
In cases where the existing code already accounts for null pointers, it
is better to use `probe_resource` instead, which returns a null pointer
instead of dying.
Change-Id: I329efcb42a444b097794fde4f40acf5ececaea8c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Lance Zhao
|
