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>
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>
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>
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>
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>
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>
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>
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>
