| Age | Commit message (Collapse) | Author |
|---|
|
Add more fields for PCIe slots status and link control and
slot capabilities.
Change-Id: I64e40ea6bd731cd52ce006224b7c3091d5ef3aac
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
In certain cases data within protected memmory areas like SMRAM could
be leaked or modified if an attacker remaps PCI BARs to point within
that area. Add support to the existing SMM runtime to allow storing
PCI resources in SMRAM and then later retrieving them.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I23fb1e935dd1b89f1cc5c834cc2025f0fe5fda37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Fix typo in the comment for Common Clock Configuration.
Change-Id: Idd01e787458a9090d53b9a57547b8158480dcc16
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73311
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
|
|
Add extended capability ID for Address Translation Services. This
definition can be found in PCI Express Base Specification rev6.0
9.3.7.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I777070ea223fc7e83c510c8eadbe4e028825eef6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71929
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Root Complex Event Collector Endpoint Association Extended
Capability is defined in section 7.9.10 of PCIe 5.0 spec.
Add its Extended Capability ID, association bitmap for RCiEPs
register, and RCEC associated bus numbers register.
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Change-Id: I7bede8ed88304a2925e6e1e4128bcdd625ee0e53
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add definitions for Link Capability and Slot Capability and these
definitions may be used in smbios type 9.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Id66710d5569a7247d998cab20c2e41f2e67712cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69092
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
* Add DPC related definitions which are defined in 7.9.14 of PCIe
6.0 spec.
* Add AER related definitions which are defined in 7.8.4 of PCIe
6.0 spec.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: Ifb6722c326ef69ef1bf3b1c2c1d5bc0cb29d7c12
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69106
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.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>
|
|
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>
|
|
This adds SPDX-License-Identifiers to all of the files in src/include
that are missing them or have unrecognized identifiers.
Files that were written specifically for coreboot and don't have license
information are licensed GPL-2.0-only, which is the license for the
overall coreboot project.
Files that were sourced from Linux are similarly GPL-2.0-only.
The cpu/power files were committed with source that was licensed as
GPL-2.0-or-later, so presumably that's the license for that entire
commit.
The final file, vbe.h gives a pointer to the BSD-2-Clause license
at opensource.org.
Change-Id: I3f8fd7848ce11c1a0060e05903fb17a7583b4725
Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
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>
|
|
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>
|
|
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I84c8470764a4e6e09220044966111ffe72078099
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55674
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
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>
|
|
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>
|
|
Change-Id: Ie325541547ea10946f41a8f979d144a06a7e80eb
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
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>
|
|
This change adds support for allocating resources for PCI express hotplug
bridges when PCIEXP_HOTPLUG is selected. By default, this will add 32 PCI
subordinate numbers (buses), 256 MiB of prefetchable memory, 8 MiB of
non-prefetchable memory, and 8 KiB of I/O space to any device with the
PCI_EXP_SLTCAP_HPC bit set in the PCI_EXP_SLTCAP register, which
indicates hot-plugging capability. The resource allocation is configurable,
please see the PCIEXP_HOTPLUG_* variables in src/device/Kconfig.
In order to support the allocation of hotplugged PCI buses, a new field
is added to struct device called hotplug_buses. This is defaulted to
zero, but when set, it adds the hotplug_buses value to the subordinate
value of the PCI bridge. This allows devices to be plugged in and
unplugged after boot.
This code was tested on the System76 Darter Pro (darp6). Before this
change, there are not enough resources allocated to the Thunderbolt
PCI bridge to allow plugging in new devices after boot. This can be
worked around in the Linux kernel by passing a boot param such as:
pci=assign-busses,hpbussize=32,realloc
This change makes it possible to use Thunderbolt hotplugging without
kernel parameters, and attempts to match closely what our motherboard
manufacturer's firmware does by default.
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Change-Id: I500191626584b83e6a8ae38417fd324b5e803afc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35946
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Most of the current implementations for FSP-based platforms
make (sometimes wrong) assumptions how FSP reorders root ports
and what is specified in the devicetree. We don't have to make
assumptions though, and can read the root-port number from the
PCIe link capapilities (LCAP) instead. This is also what we do
in ASL code for years already.
This new implementation acts solely on information read from
the PCI config space. In a first round, we scan all possible
DEVFNs and store which root port has that DEVFN now. Then, we
walk through the devicetree that still only knows devices that
were originally mentioned in `devicetree.cb`, update device
paths and unlink vanished devices.
To be most compatible, we work with the following constraints:
o Use only standard PCI config registers.
o Most notable, don't try to read the registers that
configure the function numbers. FSP has undocumented
ways to block access to non-standard registers.
o Don't make assumptions what function is assigned to
hidden devices.
The following assumptions were made, though:
o The absolute root-port numbering as documented in
datasheets matches what is read from LCAP.
o This numbering doesn't contain any gaps.
o Original root-port function numbers below a PCI
device start at function zero and also don't
contain any gaps.
Change-Id: Ib17d2b6fd34608603db3936d638bdf5acb46d717
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35985
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
So, the PCI to PCI bridge specification had a pitfall for us:
Originally, when decoding i/o ports for legacy VGA cycles, bridges
should only consider the 10 least significant bits of the port address.
This means all VGA registers were aliased every 1024 ports!
e.g. 0x3b0 was also decoded as 0x7b0, 0xbb0 etc.
However, it seems, we never reserved the aliased ports, resulting in
silent conflicts we preallocated resources. We neither use much
external VGA nor many i/o ports these days, so nobody noticed.
To avoid this mess, a bridge control bit (VGA16) was introduced in
2003 to enable decoding of 16-bit port addresses. As older systems
seem rather safe and well tested, and newer systems should support
this bit, we'll use it if possible and only warn if not.
With old (AGP era) hardware one will likely encounter a warning like
this:
found VGA at PCI: 06:00.0
A bridge on the path doesn't support 16-bit VGA decoding!
This is not generally fatal, but makes unnoticed resource conflicts
more likely.
Change-Id: Id7a07f069dd54331df79f605c6bcda37882a602d
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35516
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michael Niewöhner
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch adds generic log to perform subsystem programming
based on header type.
Type 0: subsystem offset 0x2C
Type 2: subsystem offset 0x40
Type 1: Read CAP ID 0xD to know cap offset start, offset 4 to locate
subsystem vendor id.
Change-Id: Id8aed6dac24517e93cd55d6bb3b254b7b4d950d3
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31983
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: David Guckian
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Basic PCI MSI-X table helper functions.
Imported from GNU/Linux kernel PCI subsystem.
To be used on Cavium to configure MSI-X tables.
Change-Id: I94413712e7986efd17e6b11ba59f6eb390384c8c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26329
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This patch moves out LTR programming under L1 substate
to pchexp_tune_device function, as substate programming
and LTR programming are independent.
LTR programming scheme is updated to scan through entire
tree and enable LTR mechanism on pci device if LTR mechanism
is supported by device.
BRANCH=none
BUG=b:66722364
TEST=Verify LTR is configured for end point devices and max
snoop latency gets configured.
Change-Id: I6be99c3b590c1457adf88bc1b40f128fcade3fbe
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/21868
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
Changed a few comments to reduce line length. File
src/include/cpu/amd/vr.h was skipped.
TEST=Build and run on Galileo Gen2
Change-Id: Ie3c07111acc1f89923fb31135684a6d28a505b61
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18687
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: please, no space before tabs
TEST=Build and run on Galileo Gen2
Change-Id: If60a58021d595289722d1d6064bea37b0b0bc039
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18652
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: space required after that ',' (ctx:VxV)
TEST=Build and run on Galileo Gen2
Change-Id: I297bfc3d03dc95b471d3bb4b13803e81963841b5
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18647
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
pci_def.h is supposed to only contain definitions, such that it may be
included in assembly files. Declaration of functions in said file
prevents that.
Change-Id: I0f90a74291c8a2ef7a1e1027d2d2182f896050fb
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/13300
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
To help hypervisors to assign PCI devices individually to virtualization
guests, page align dynamically allocated MMIO resources.
Tested with kontron/ktqm77 which has dynamically configured onboard
devices on the root bus and secondary buses. Booted Linux and checked
the configuration with `lspci -v`. Got the configuration through Muen's
tools which are very picky about overlapping and alignment. Booted a
Muen based system that uses many onboard devices. GMA, xHCI and one NIC
(on a secondary bus) were verified to function properly.
Change-Id: I2b7115070e1ccad64565feff025289732c3b5e66
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/12111
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
BRANCH=none
BUG=None
TEST=Build Braswell/Strago
Change-Id: I11a4c02af3b40edf2252b9e20298941b99f31d21
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1629d7454a3d4adb8930d14849c41c9a711f4c9a
Original-Change-Id: Ie907637f7c823de681ef2e315e803dffc6ad33d3
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241081
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9487
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Enable L1 Sub-State when both root port and endpoint support it.
[pg: keyed the feature to MMCONF_SUPPORT, otherwise boards
without that capability fail to build.]
Change-Id: Id11fc7c73eb865411747eef63f5f901e00a17f84
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ac04ad7e2261846e40da297f7fa317ccebda092
Original-BUG=chrome-os-partner:31424
Original-TEST=Build a image and run on Samus proto boards to check if the
settings are applied correctly. I just only have proto boards and
need someone having EVT boards to confirm the settings.
Original-Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Original-Change-Id: Id1b5a52ff0b896f4531c4a6e68e70a2cea8c736a
Original-Reviewed-on: https://chromium-review.googlesource.com/221436
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/8832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Set PCIe "Enable Clock Power Management", if endpoint supports it.
BUG=chrome-os-partner:31424
BRANCH=none
TEST=build and boot on rambi, check Enable Clock Power Management
in link control register is set properly
Change-Id: Ie54110d1ef42184cfcf47c9fe4d735960aebe47f
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/220742
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
[Edit commit message.]
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8447
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Not used and did not have 12 bits reserved to address full PCIe
configuration space per every function.
Change-Id: Ib04a1eb2487735375b4ee738d48a5bebe41ba3c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5835
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
|
|
There are EHCI compatible host controllers on ARM without PCI bus
architecture. Currently we have not come across one with the debug
capability though.
Change-Id: I8775c9814f6fdf8754f97265118a7186369d721d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5175
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Add a function to test if pci_devfn_t matches with a device
instance of struct device, by comparing bus:dev.fn.
Change-Id: Ic6c3148ac62c7183246d83302ee504b17064c794
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3474
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
Change-Id: Iadc813bc8208278996b2b1aa20cfb156ec06fac9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/3755
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
These are guarded by individual Kconfig entries. The deprecated
CONFIG_PCIE_TUNING defines have been removed in favor of using specific
config options.
This is the generic half, there is board-specific pieces
still to come that tune before and after ASPM is enabled.
Change-Id: I3fe46282eada67629e9eeeed07e487dff54f2729
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/735
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
|
|
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4159 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@2435 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
1. x86_setup_mtrr take address bit.
2. generic ht, pcix, pcie beidge...
3. scan bus and reset_bus
4. ht read ctrl to decide if the ht chain
is ready
5. Intel e7520 and e7525 support
6. new ich5r support
7. intel sb 6300 support.
yhlu patch
1. split x86_setup_mtrrs to fixed and var
2. if (resource->flags & IORESOURCE_FIXED ) return; in device.c pick_largest_resource
3. in_conherent.c K8_SCAN_PCI_BUS
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1982 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1663 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
- Reworked pnp superio device support. Now complete superio support is less than 100 lines.
- Added support for hard coding resource assignments in Config.lb
- Minor bug fixes to romcc
- Initial support for catching the x86 processor BIST error codes. I've only seen
this trigger once in production during a very suspcious reset but...
- added raminit_test to test the code paths in raminit.c for the Opteron
- Removed the IORESOURCE_SET bit and added IORESOURCE_ASSIGNED and IORESOURCE_STORED
so we can tell what we have really done.
- Added generic AGP/IOMMU setting code to x86
- Added an implementation of memmove and removed reserved identifiers from memcpy
- Added minimal support for booting on pre b3 stepping K8 cores
- Moved the checksum on amd8111 boards because our default location was on top of
extended RTC registers
- On the Hdama added support for enabling i2c hub so we can get at the temperature
sensors. Not that i2c bus was implemented well enough to make that useful.
- Redid the Opteron port so we should only need one reset and most of memory initialization
is done in cpu_fixup. This is much, much faster.
- Attempted to make the VGA IO region assigment work. The code seems to work now...
- Redid the error handling in amdk8/raminit.c to distinguish between a bad value
and a smbus error, and moved memory clearing out to cpufixup.
- Removed CONFIG_KEYBOARD as it was useless. See pc87360/superio.c for how to
setup a legacy keyboard properly.
- Reworked the register values for standard hardware, moving the defintions from
chip.h into the headers of the initialization routines. This is much saner
and is actually implemented.
- Made the hdama port an under clockers BIOS. I debuged so many interesting problems.
- On amd8111_lpc added setup of architectural/legacy hardware
- Enabled PCI error reporting as much as possible.
- Enhanded build_opt_tbl to generate a header of the cmos option locations so
that romcc compiled code can query the cmos options.
- In romcc gracefully handle function names that degenerate into function pointers
- Bumped the version to 1.1.6 as we are getting closer to 2.0
TODO finish optimizing the HT links of non dual boards
TODO make all Opteron board work again
TODO convert all superio devices to use the new helpers
TODO convert the via/epia to freebios2 conventions
TODO cpu fixup/setup by cpu type
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@1390 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@999 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
|
pci definitions
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@839 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
|
