| Age | Commit message (Collapse) | Author |
|---|
|
Use same indents for switch/case to fix linter issues.
Change-Id: I5c6abf5b918bac3df8d7617824392f2ec932cb32
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Platform can now select VGA_ROM_RUN_DEFAULT Kconfig to perform graphics
initialization for PCI-E based discrete card through VGA OpRom
(SoC or Mainboard user can't select VGA_ROM_RUN directly because
it's part of choice option).
(Note: Some payloads, like SeaBIOS, are also able to run Option ROMs,
so coreboot does not need to enable VGA_ROM_RUN Kconfig)
For payload like depthcharge, create VGA_ROM_RUN_DEFAULT Kconfig
for mainboard to select design with DGPU where OpROM is embedded
inside the DGPU card.
Allow auto selection of VGA_ROM_RUN_DEFAULT from VGA_BIOS Kconfig.
Also NO_GFX_INIT Kconfig to avoid running VGA_ROM_RUN
by default in case SeaBIOS is used.
TEST=Able to get Pre-OS splash screen with AMD Radeon RX 5700 PCI-E
DGPU when mainboard user selects VGA_ROM_RUN_DEFAULT.
Change-Id: Iecb2fcdb105af449bc20ad727759cdef17d5e376
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49016
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add the register PNP_IO4, which will be used by IT5570E in CB:48894.
Change-Id: Ic820295247323f546d4c48ed17cfa4eab3dc5e92
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48924
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Introduce a new device `gpio` that is going to be used for generic
abstraction of gpio operations in the devicetree.
The general idea behind this is that every chip can have gpios that
shall be accessible in a very generic way by any driver through the
devicetree.
The chip that implements the chip-specific gpio operations has to assign
them to the generic device operations struct, which then gets assigned
to the gpio device during device probing. See CB:48583 for how this gets
done for the SoCs using intelblocks/gpio.
The gpio device then can be added to the devicetree with an alias name
like in the following example:
chip soc/whateverlake
device gpio 0 alias soc_gpio on end
...
end
Any driver that requires access to this gpio device needs to have a
device pointer (or multiple) and an option for specifying the gpio to be
used in its chip config like this:
struct drivers_ipmi_config {
...
DEVTREE_CONST struct device *gpio_dev;
u16 post_complete_gpio;
...
};
The device `soc_gpio` can then be linked to the chip driver's `gpio_dev`
above by using the syntax `use ... as ...`, which was introduced in
commit 8e1ea52:
chip drivers/ipmi
use soc_gpio as gpio_dev
register "bmc_jumper_gpio" = "GPP_D22"
...
end
The IPMI driver can then use the generic gpio operations without any
knowlege of the chip's specifics:
unsigned int gpio_val;
const struct gpio_operations *gpio_ops;
gpio_ops = dev_get_gpio_ops(conf->gpio_dev);
gpio_val = gpio_ops->get(conf->bmc_jumper_gpio);
For a full example have a look at CB:48096 and CB:48095.
This change adds the new device type to sconfig and adds generic gpio
operations to the `device_operations` struct. Also, a helper for getting
the gpio operations from a device after checking them for NULL pointers
gets added.
Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with
CB:48711 and OCP DeltaLake with CB:48672.
Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786
Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com>
Tested-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Also tidy up some adjacent comments.
Change-Id: I2e881900a52e42ab3f43ffe96cfbdcc63ff02e23
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Change-Id: I346040eb6531dac6c066a96cd73033aa17f026d0
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Many uses of `azalia_set_bits` are used to toggle the reset bit. To
avoid having to repeat the register operations and the corresponding
comment, create two helpers with self-explanatory names. They will be
put to use in subsequent commits, with one change for each function.
Change-Id: If0594fdaf99319f08a2e272cd37958f0f216e654
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The `4` here doesn't have to do with the size of u32. Instead, it is
because the verb header contains the number of jacks, which is the
number of four-verb groups.
Change-Id: I3956ce5ec2a7abc29982504cf75b262a1c098af5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
This function is equivalent to `azalia_find_verb` in its current form,
so replace them. Also, adapt and move the function description comment.
Change-Id: I40d1e634c31b00bd7808a651990d9bd6f0d054e9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Allow to specify which table should the verb list be read from.
Change-Id: Id1bc40c4364cda848f416bad9eeab1b8ca3e9512
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The `dev` parameter isn't used anywhere.
Change-Id: I05643f8201137ffe89ded1e3f989c5a0f04e0af1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
To allow dropping copies of this function, make it non-static. Also,
rename it to `azalia_find_verb` as the function is now globally visible.
Finally, replace the copies in chipset code with `azalia_find_verb`.
Change-Id: Ie66323b2c62139e86d3d7e003f6653a3def7b5f2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
The other five copies of this function in the tree do not have these
debug prints. Remove them from here for consistency. Note that this
information is already printed elsewhere, so nothing is being lost.
Change-Id: I999032af1628bf8d66a057dc72368f02ef6eb8d1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48347
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
There's many copies of this function in the tree. Make the copy in
azalia_device.c non-static and rename it to `azalia_set_bits`, then
replace all other copies with it. Since azalia_device.c is only built
when AZALIA_PLUGIN_SUPPORT is selected, select it where necessary.
This has the side-effect of building hda_verb.c from the mainboard
directory. If this patch happens to break audio on a mainboard, it's
because its hda_verb.c was always wrong but wasn't being compiled.
Change-Id: Iff3520131ec7bc8554612969e3a2fe9cdbc9305e
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48346
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Currently it's not possible to add multiple graphics drivers into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics drivers can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace all duplications of fill_fb_framebuffer and provide a single one
in edid_fill_fb.c. Should not change the current behaviour as still only
one graphic driver can be active at time.
Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
A mainboard-level hda_verb.c may not exist for variant setups.
Change-Id: If2c92d9498cba7c084ef4c7065bc4ae83c7da761
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48353
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
Only two definitions are actually used somewhere, the rest is unused.
Change-Id: Iec52d0d47fce6a1ec5455b670824b995a7a34a4c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47407
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a NULL check and only skip setting the default operations
if `.ops` was set by a driver. It's fairly unlikely that some-
body adds a driver and forgets the `.ops` pointer. So this is
mostly to increase readability: Nobody should have to wonder
if we're missing a NULL-check.
The condition is moved out of the loop to reduce indentation
levels. Alternatively, we could jusk skip drivers that don't
have `.ops` set (i.e. continue the loop).
Change-Id: I5dcc05ebb092fb9c4be929c81ea2b05a10b1311b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46297
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Devices of class type "system" are arbitrary devices and it's not clear
which of them need bus mastering. Therefore, enable bus mastering
conditionally based on Kconfig option PCI_ALLOW_BUS_MASTER_ANY_DEVICE.
Change-Id: Ia04e83606a0a081c0758ec59e52627aa1dbd2622
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45151
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: Ic7cacce28f473dda76ca203016dbb8e00149a990
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Move this function to pci_ops.c, which is already included in the smm
build. This is required to use this function in elog functionality,
which is called from SMM.
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ie5583c04366c9a16bc1b00a6892d39eeafe5da49
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47260
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
|
|
Instead of checking whether the return value equals -1, just check if it
is negative. Some Azalia implementations already do it, but most do not.
Change-Id: I43ce72a01c07eff62d645db28c09584b386532ff
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46727
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
As an intermediate step for CB:45150, add an additional Kconfig option
which is used to configure bus mastering for any devices and use
PCI_ALLOW_BUS_MASTER to allow coreboot setting the bus mastering bit in
general.
Change-Id: I33b37a79022007a16e97350db61575b63fa8256b
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45149
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: I902915133035fb2adff7edd9c931d4b1d3e7dc40
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This change allows a generic device to be described in the devicetree
under a PCI device, such as a root port.
Previously any device under a PCI device was expected to also be a PCI
device and that does not allow for a virtual/generic device to be
present, for example to provide ACPI properties for a root port.
The changes are:
- Ignore non-PCI devices found under a PCI device when scanning and do
not print an error for each devfn scanned.
- Don't treat non-PCI devices as leftover and remove them, instead
enable them as a static device.
- Don't attempt to configure a static device in the tree that is not a
PCIe device type.
With these changes it is now possible to have a generic device under a
PCI device, for example in a USB4/TBT root port (PCIe hotplug device)
this generic device will add ACPI properties for the PCIe tunnel routed
to the external port:
device pci 07.0 on
chip soc/intel/common/block/pcie
device generic 0 on end
end
end
TEST=boot on volteer with the USB4 root port devices in chipset.cb and
ensure they are enabled properly and there are no errors printed in the
coreboot log, and that the device properties are created in the SSDT.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I56a491808067dc862a7adfd46852f0bd6b41cd95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46542
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The work done by enable_static_devices() and scan_generic_bus()
is common and can be used by other device handlers to enable a
single static device.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ibfde9c4eb794714ebd9800e52b91169ceba15266
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46541
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This change adds a helper function `pci_dev_is_wake_source()` that
checks PME_STATUS and PME_ENABLE bits in PM control and status
register to determine if the given device is the source of wake.
BUG=b:169802515
BRANCH=zork
Change-Id: I06e9530b568543ab2f05a4f38dc5c3a527ff391e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Coverity detects the dev->link_list NULL pointer dereferences while
calling report_resource_stored. Add sanity check for dev->link_list to
prevent NULL pointer dereference.
Found-by: Coverity CID 1419488
TEST=None
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I953a6524fff509a7833896392b25a3245c8cd705
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45627
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Ief990b4174d13b3472ac75a042ae8d878640dda3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
|
|
Check that nobody misuses the Kconfigs SUBSYSTEM_*_ID. They are meant to
be used for overriding the devicetree subsystem ids locally but shall
not be added to a board's Kconfig. Instead, the devicetree option
`subsystemid` should be used.
Add a linter script for this that finds and warns about such misuse.
Also add a note in the Kconfigs' description.
TEST=CB:45513
Change-Id: I21c021c718154f1396f795a555af47a76d6efe03
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
When <device/pnp.h> is needed, it is supposed to provide <device/pnp_def.h>.
So remove redundant <device/pnp_def.h> includes.
I'll remove also <device/pnp_type.h> in a separate patch.
Change-Id: Ib9903ae456c32db4ba346020659c17c27a939e89
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45316
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Add method for converting DDR4 speed in MHz to MT/s. Checks that MHz is
within a speed grade range.
BUG=b:167155849
TEST=ddr4-test unit test
BRANCH=Zork
Change-Id: I1433f028afb794fe3e397b03f5bd0565494c8130
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: I68590605e261ecaace9f3cea28cfa6ec3b913a8a
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
The bus master bit is set at many places in coreboot's code, but the
reason for that is not quite clear. We examined not setting the
bus master bit whereever possible and tried booting without it,
which worked fine for internal PCI devices but not for PCIe. As a PCIe
device we used a Samsung M.2 NVMe SSD.
For security reasons, we would like to disable bus mastering where
possible. Depending on the device, bus mastering might get enabled
by the operating system (e.g. for iGPU) and it might be required for
some devices to work properly. However, the idea is to leave it disabled
and configure the IOMMU first before enabling it.
To have some sort of "backwards compatibility", add a method which
configures bus mastering based on an additional config option. Since
CB:42460 makes usage of this treewide, enable it by default to keep the
current behaviour for now.
Tested with Siemens/Chili, a Coffee Lake based platform.
Change-Id: I876c48ea3fb4f9cf7b6a5c2dcaeda07ea36cbed3
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42459
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Remaining notable differences at function 'codec_detect(u8 *base)'.
Change-Id: Ia64e0ba10f145cf2eae0cb2ff4951b1455963d5d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ia0ba6c2f76221123acd3c5303b0a018c651f3617
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44125
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The DISPLAY_3D class is for graphics devices that are not connected to
displays. This includes GPUs implementing muxless Nvidia Optimus.
According to CB:31502, some AMD GPUs are identified as DISPLAY_OTHER.
Therefore, consider the entire DISPLAY class as GPUs.
Change-Id: I0f203a013c010337ae7a9fddbd13330f380050a4
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: I5d3a5ede47aefc7cc2ee330f8a0bcded16138764
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44173
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit ad247ac5d8ef4a38bd1d61fbd28076f343a46c5c.
It doesn't work like this. The `dev->enable` field has already been
updated and is always `0` at this point.
Change-Id: I5b3560dcea2f226c841f4823526db2fdab149d22
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
I would like to make assertions evaluate at compile time where possible,
but sometimes people used a literal assert(0) to force an assertion in a
certain code path. We already have BUG() for that so let's just replace
those instances with that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I674e5f8ec7f5fe8b92b1c7c95d9f9202d422ce32
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Add find_dev_nested_path helper function to simplify finding deeply
nested devices.
BUG=b:157580724
TEST=Find bluetooth device on dalboz
Change-Id: I48fa5fcad0030fb6dcea97b9fc76e1d3d3f9b28f
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43776
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
Looks like no one really knows what this bit would be useful for, nor
when it would need to be set. Especially if coreboot is setting it even
on PCI *Express* bridges. Digging through git history, nearly all
instances of setting it on PCIe bridges comes from i82801gx, for which
no reason was given as to why this would be needed. The other instances
in Intel code seem to have been, unsurprisingly, copy-pasted.
Drop all uses of this definition and rename it to avoid confusion. The
negation in the name could trick people into setting this bit again.
Tested on Asrock B85M Pro4, no visible difference.
Change-Id: Ifaff29561769c111fb7897e95dbea842faec5df4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
The Kconfig lint tool checks for cases of the code using BOOL type
Kconfig options directly instead of with CONFIG() and will print out
warnings about it. It gets confused by these references in comments
and strings. To fix it so that it can find the real issues, just
update these as we would with real issues.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I5c37f0ee103721c97483d07a368c0b813e3f25c0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Iaf22dc1986427e8aa4521b0e9b40fafa5a29dbbd
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
One would expect disabled devices to not be present. So, don't print
misleading warnings about it, because it only confuses people.
Change-Id: I0f14174a1d460a479dc9f15b63486f4f27b8f67c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43767
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
It does nothing useful anymore. Drop it before it grows moss.
Change-Id: I5f95376fe2a38eda5d819c53edb85ef11ab7a0f1
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43591
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
There is some boilerplate required to iterate over the USB supported
protocol structs. Encapsulate all the in a method to make the callers
simpler.
BUG=b:154756391
TEST=Built test trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I401f10d242638b0000ba697573856d765333dca0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43352
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This code is not even being build-tested. Drop it before it grows moss.
Change-Id: Id3f9dd264e82f93a438422e388d70e3f88ae0df9
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
|
|
Kconfig 4.17 started using the $(..) syntax for environment variable
expansion while we want to keep expansion to the build system.
Older Kconfig versions (like ours) simply drop the escapes, not
changing the behavior.
While we could let Kconfig expand some of the variables, that only
splits the handling in two places, making debugging harder and
potentially messing with reproducible builds (e.g. when paths end up
in configs), so escape them all.
Change-Id: Ibc4087fdd76089352bd8dd0edb1351ec79ea4faa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
|
|
This decouples the linear framebuffer type from the symbols needing it.
Change-Id: I733e630e0aa2fb2947d079caef26253ce443fe91
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42432
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Once we support building stages for different architectures,
such CONFIG(ARCH_xx) tests do not evaluate correctly anymore.
Change-Id: I599995b3ed5c4dfd578c87067fe8bfc8c75b9d43
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42183
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This will allow enumerating an xHCI controller to allow dynamically
generating the ACPI device nodes.
BUG=b:154756391
TEST=Boot trembyle and see capabilities printed on console
xHCI Supported Protocol:
Major: 0x2, Minor: 0x0, Protocol: 'USB '
Port Offset: 1, Port Count: 2
xHCI Supported Protocol:
Major: 0x3, Minor: 0x10, Protocol: 'USB '
Port Offset: 3, Port Count: 1
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I3065c3fffad01b5378a55cfe904f971079b13d0f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
A function pci_dev_disable_bus_master() is created. This function
can be used to disable Thunderbolt PCIe root ports, bridges and
devices for Vt-d based security platform at end of boot service.
BUG=None
TEST=Verified PCIe device bus master enable bit is cleared.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
|
Change-Id: Ie004a94a49fc8f53c370412bee1c3e7eacbf8beb
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41944
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This change makes the following improvements to debug logging in
resource allocator:
1. Print depth is added to functions in pass 1 to better represent how
the resource requirements of child devices impact the resource windows
for parent bridge.
2. Device path is added to resource ranges to make it easier to
understand what device the resouce ranges are associated with.
3. Prints in pass 2 (update constraints, resource ranges, resource
assignment) are shifted left by 1 to make it easier to visualize
resource allocation for each bridge including domain.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I3356a7278060e281d1a57d253537b097472827a1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41478
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change updates the log level for prints in resource allocator v4
to BIOS_DEBUG instead of BIOS_SPEW. These are critical in debugging
issues and should be enabled at log level BIOS_DEBUG.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib863619f5e1214e4fe6f05c52be6fa2de36e6c3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41477
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
4G boundary""
This reverts commit e15f352039a371156ceef37f0434003228166e99.
Reason for revert: Resource allocator is split into old(v3) and
new(v4). So, this change to provide an option to allocate prefetch
memory above 4G boundary can be added back. Since the support for
allocating above 4G boundary is available only in resource allocator
v4, Kconfig option is accordingly updated to add depends on
RESOURCE_ALLOCATOR_V4.
Change-Id: I94e5866458c79c2719fd780f336fb5da71a7df66
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41467
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Addressing comment from CB:41443 that was received after the change
landed. memranges_create_hole() takes size as the last parameter. So,
the I/O hole created at 0x3b0 needs to set size as 0x3df - 0x3b0 + 1
as 0x3df is the upper limit of that hole.
Change-Id: I08fca283436924427e12c6c69edced7e51db42a9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change disables the old resource allocator by default and instead
uses the new v4 resource allocator. Only the chipsets that explicitly
select RESOURCE_ALLOCATOR_V3 will continue to use the old v3 resource
allocator.
Change-Id: I2ab9f1d612b5f193f058011a18b1d6373e09f788
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41445
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
|
|
This change adds back support for the resource allocator using
multiple ranges as originally landed in CB:39486(commit hash 3b02006)
and reverted in CB:41413(commit hash 6186cbc). The new resource
allocator can be selected by Kconfig option RESOURCE_ALLOCATOR_V4. It
was identified that there are some AMD chipsets in the tree that do
not really work well with the dynamic resource allocation. Until these
chipsets are fixed, old (v3) and new (v4) of the resource allocator
need to live side-by-side in the tree. There were some other chipsets
in the tree which originally demonstrated problems with the new
resource allocator, but have been since fixed in the tree.
This change picks up the same additions as performed in CB:39486 along
with the following changes:
1. Changes to avoid fixed resources in the entire tree. Use of
search_bus_resources() is replaced with a walk of the entire tree
in avoid_fixed_resources(). This is required to ensure that all fixed
resources added to any device (including domain) are taken into
consideration to avoid overlap during dynamic resource allocation.
2. Changes to set up alignment for memranges when initializing
them. This is done to ensure that the right granularity is used for
IORESOURCE_IO(no special alignment) and IORESOURCE_MEM(4KiB) resource
requests.
3. mark_resource_invalid() is dropped as the resource no longer needs
to be marked in any special way if allocation is not being
done. Instead setting of IORESOURCE_ASSIGNED flag is skipped in this
case.
4. initialize_memranges() is updated to check IORESOURCE_ASSIGNED
instead of base == limit.
Original commit message:
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.
Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.
b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.
c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.
d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.
e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.
Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.
Change-Id: Ide4d98528197bb03850a8fb4d73c41cd2c0195aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41443
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
find_pci_tolm() is updated to ensure that it ignores resources that
have a zero size. This change removes the setting of resource flags to
IORESOURCE_ASSIGNED when the resource is not really allocated any
space by the allocator. It also drops the setting of base to limit
since that is not required anymore.
Change-Id: If8c0d4bf1aa9cd6a5bdf056140f65cf2d70ed216
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41566
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change moves the resource allocator functions out of device.c
and into two separate files:
1. resource_allocator_v3.c: This is the old implementation of
resource allocator that uses a single window for resource
allocation. It is required to support some AMD chipsets that do not
provide an accurate map of allocated resources by the time the
allocator runs. They work fine with the old allocator since it
restricts itself to allocations in a single window at the top of the
4G space.
2. resource_allocator_common.c: This file contains the functions that can
be shared by the old and new resource allocator.
Entry point into the resource allocation is allocate_resources() which
can be implemented by both old and new allocators. This change also
adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old
resource allocator. This config option is enabled by default
currently, but in the following CLs this will be enabled only for the
broken boards.
Reason for this split: Both the old and new resource allocators need
to be retained in the tree until the broken chipsets are fixed.
Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
find_pci_tolm()
This change updates find_pci_tolm() to not consider any unassigned
resources. This is achieved by adding the following checks:
1. Call search_bus_resources() with mask set to IORESOURCE_MEM |
IORESOURCE_ASSIGNED.
2. In the callback tolm_test, check that the new resource selected has
a non-zero size.
This change is being made so that the resource allocator does not have
to set the IORESOURCE_ASSIGNED flag for marking a resource as
invalid.
Change-Id: I796784dd93aa165e20a672c985b4875991901c87
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
The I/O windows of PCI bridges can be disabled individually by
setting their limit lower than their base. Always do this if a
resource wasn't assigned a value.
Change-Id: I73f6817c4b12cb1689627044735d1fed6d825afe
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41552
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This function is too long and quirky. Factor the actual resource write
out, so we can focus on the logic.
Change-Id: I6c7f930614dcd63d4ee2a4ca7cf541a9de4fd557
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
After removal of CAR_MIGRATION there are no more reasons
to carry around ENV_STAGE_HAS_BSS_SECTION=n case.
Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit
zero-initializers.
Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
On some SoCs, there are PCI devices that may get hidden from PCI
enumeration by platform firmware. Because the Vendor ID reads back as
0xffffffff, it appears that there is no PCI device located at that BDF.
However, because the device does exist, designers may wish to hang its
PCI resources off of a real __pci_driver, as well as have it participate
in ACPI table generation.
This patch extends the semantics of the 'hidden' keyword in
devicetree.cb. If a device now uses 'hidden' instead of 'on', then it
will be assumed during PCI enumeration that the device indeed does
exist, and it will not be removed as a "leftover device." This allows
child devices to be enumerated correctly and also PCI resources can be
designated from the {read,set}_resources callbacks.
It should be noted that as of this commit, there are precisely 0 devices
using 'hidden' in their devicetree.cb files, so this should be a safe
thing to do.
Later patches will begin moving PCI resources from random places (typically
hung off of fixed SA and LPC) into the PMC device (procedure will vary per-
platform).
Change-Id: I16c2d3e1d1433343e63dfc16856cff69cd815e2a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The struct (formerly assigned to default_pci_ops_bus.ops_pci) only
contained a NULL (well, 0) pointer for the set_subsystem callback, but
usage of that callback is guarded with NULL checks when it is used,
therefore it can be removed.
TEST=still compiles
Change-Id: I3943c8ae73b95e744a317264d7ceb8929cb28341
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41432
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: I8a207e30a73d10fe67c0474ff11324ae99e2cec6
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41360
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit 3b02006afe8a85477dafa1bd149f1f0dba02afc7.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: Id9872b90482319748b4f3ba2e0de2185d5c50667
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41413
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit 44ae0eacb82259243bf844a3fe5ad24a7821e997.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This reverts commit dcbf6454b6d2d9b3627a14126ef20ed4b9c7d954.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
Change-Id: I58c9fff1a18ea1c9941e29c2c6e60e338c517c30
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41465
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
|
|
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both
be active at the same time. This adds a way to specify which devices
belong on which bus.
i.e.,
device pci 14.3 on # - D14F3 bridge
device espi 0 on
chip ec/google/chromeec
device pnp 0c09.0 on end
end
end
device lpc 0 on
end
end
BUG=b:154445472
TEST=Built trembyle and saw static.c contained the espi bus.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
pci_domain_set_resources is duplicated in all the SOCs. This change
promotes the duplicated function.
Picasso was adding it again in the northbridge patch. I decided to
promote the function instead of duplicating it.
BUG=b:147042464
TEST=Build and boot trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change adds a Kconfig option to request allocation of prefetch
memory for hotplug devices above the 4G boundary. In order to
select this option by default and still allow users to disable this if
required, another option is added to request allocation of prefetch
memory below 4G boundary which defaults to n but can be overriden
by mainboards.
Without this change, if the number of pciexp bridges supporting
hot-plug is more than 4 or if the reserved prefetch memory size for
hot-plug cases was increased, then the resource allocator would fail
to satisfy the resource requirement below 4G boundary.
BUG=b:149186922
TEST=Enabled resource allocation above 4G for prefetch memory on volteer
and verified that it gets allocated above 4G boundary.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I061d935eef9fcda352230b03b5cf14e467924e50
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39489
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change updates the resource limit for PCI domain to allow
resource allocation above 4G boundary. The resource limit is set to
the highest physical address for the CPU.
BUG=b:149186922
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idfcc9a390d309886ee2b7880b29502c740e6578e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39488
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
BUG=b:149186922
TEST=Verified that resources get allocated above the 4G boundary
correctly on volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I7fb2a75cc280a307300d29ddabaebfc49175548f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change updates the resource allocator in coreboot to allow using
multiple ranges for resource allocation rather than restricting
available window to a single base/limit pair. This is done in
preparation to allow 64-bit resource allocation.
Following changes are made as part of this:
a) Resource allocator still makes 2 passes at the entire tree. The
first pass is to gather the resource requirements of each device
under each domain. It walks recursively in DFS fashion to gather the
requirements of the leaf devices and propagates this back up to the
downstream bridges of the domain. Domain is special in the sense that
it has fixed resource ranges. Hence, the resource requirements from
the downstream devices have no effect on the domain resource
windows. This results in domain resource limits being unmodified after
the first pass.
b) Once the requirements for all the devices under the domain are
gathered, resource allocator walks a second time to allocate resources
to downstream devices as per the requirements. Here, instead of
maintaining a single window for allocating resources, it creates a
list of memranges starting with the resource window at domain and then
applying constraints to create holes for any fixed resources. This
ensures that there is no overlap with fixed resources under the
domain.
c) Domain does not differentiate between mem and prefmem. Since they
are allocated space from the same resource window at the domain level,
it considers all resource requests from downstream devices of the
domain independent of the prefetch type.
d) Once resource allocation is done at the domain level, resource
allocator walks down the downstream bridges and continues the same
process until it reaches the leaves. Bridges have separate windows for
mem and prefmem. Hence, unlike domain, the resource allocator at
bridge level ensures that downstream requirements are satisfied by
taking prefetch type into consideration.
e) This whole 2-pass process is performed for every domain in the
system under the assumption that domains do not have overlapping
address spaces.
Noticeable differences from previous resource allocator:
a) Changes in print logs observed due to flows being slightly
different.
b) Base, limit and size of domain resources are no longer updated
based on downstream requirements.
c) Memranges are used instead of a single base/limit pair for
determining resource allocation.
d) Previously, if a resource request did not fit in the available
base/limit window, then the resource would be allocated over DRAM or
any other address space defeating the principle of "no overlap". With
this change, any time a resource cannot fit in the available ranges,
it complains and ensures that the resource is effectively disabled by
setting base same as the limit.
e) Resource allocator no longer looks at multiple links to determine
the right bus for a resource. None of the current boards have multiple
buses under any downstream device of the domain. The only device with
multiple links seems to be the cpu cluster device for some AMD
platforms.
BUG=b:149186922
TEST=Verified that resource allocation looks correct based on
addresses assigned on Volteer.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia1f089877c62e119c6a994a10809c9cc0050ec9a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39486
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Used commands:
perl -i -p0e 's|\/\*[\s*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-only */|' $(cat filelist)
perl -i -p0e 's|\/\*[\s*]*.*is[\s*]*free[\s*]*software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*either[\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License,[\s*]*or[\s*]*.at[\s*]*your[\s*]*option.[\s*]*any[\s*]*later[\s*]*version.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-2.0-or-later */|' $(cat filelist)
perl -i -p0e 's|\/\*[\s*]*.*is[\s*#]*free[\s*#]*software[;:,][\s*#]*you[\s*#]*can[\s*#]*redistribute[\s*#]*it[\s*#]*and/or[\s*#]*modify[\s*#]*it[\s*#]*under[\s*#]*the[\s*#]*terms[\s*#]*of[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*as[\s*#]*published[\s*#]*by[\s*#]*the[\s*#]*Free[\s*#]*Software[\s*#]*Foundation[;:,][\s*#]*either[\s*#]*version[\s*#]*3[\s*#]*of[\s*#]*the[\s*#]*License[;:,][\s*#]*or[\s*#]*.at[\s*#]*your[\s*#]*option.[\s*#]*any[\s*#]*later[\s*#]*version.[\s*#]*This[\s*#]*program[\s*#]*is[\s*#]*distributed[\s*#]*in[\s*#]*the[\s*#]*hope[\s*#]*that[\s*#]*it[\s*#]*will[\s*#]*be[\s*#]*useful[;:,][\s*#]*but[\s*#]*WITHOUT[\s*#]*ANY[\s*#]*WARRANTY[;:,][\s*#]*without[\s*#]*even[\s*#]*the[\s*#]*implied[\s*#]*warranty[\s*#]*of[\s*#]*MERCHANTABILITY[\s*#]*or[\s*#]*FITNESS[\s*#]*FOR[\s*#]*A[\s*#]*PARTICULAR[\s*#]*PURPOSE.[\s*#]*See[\s*#]*the[\s*#]*GNU[\s*#]*General[\s*#]*Public[\s*#]*License[\s*#]*for[\s*#]*more[\s*#]*details.[\s*]*\*\/|/* SPDX-License-Identifier: GPL-3.0-or-later */|' $(cat filelist)
perl -i -p0e 's|(\#\#*)[\w]*.*is free software[:;][\#\s]*you[\#\s]*can[\#\s]*redistribute[\#\s]*it[\#\s]*and\/or[\#\s]*modify[\#\s]*it[\s\#]*under[\s \#]*the[\s\#]*terms[\s\#]*of[\s\#]*the[\s\#]*GNU[\s\#]*General[\s\#]*Public[\s\#]*License[\s\#]*as[\s\#]*published[\s\#]*by[\s\#]*the[\s\#]*Free[\s\#]*Software[\s\#]*Foundation[;,][\s\#]*version[\s\#]*2[\s\#]*of[\s\#]*the[\s\#]*License.*[\s\#]*This[\s\#]*program[\s\#]*is[\s\#]*distributed[\s\#]*in[\s\#]*the[\s\#]*hope[\s\#]*that[\s\#]*it[\s\#]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist)
perl -i -p0e 's|(\#\#*)[\w*]*.*is free software[:;][\s*]*you[\s*]*can[\s*]*redistribute[\s*]*it[\s*]*and\/or[\s*]*modify[\s*]*it[\s*]*under[\s*]*the[\s*]*terms[\s*]*of[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*as[\s*]*published[\s*]*by[\s*]*the[\s*]*Free[\s*]*Software[\s*]*Foundation[;,][\s*]*version[\s*]*2[\s*]*of[\s*]*the[\s*]*License.[\s*]*This[\s*]*program[\s*]*is[\s*]*distributed[\s*]*in[\s*]*the[\s*]*hope[\s*]*that[\s*]*it[\s*]*will[\s*]*be[\s*]*useful,[\s*]*but[\s*]*WITHOUT[\s*]*ANY[\s*]*WARRANTY;[\s*]*without[\s*]*even[\s*]*the[\s*]*implied[\s*]*warranty[\s*]*of[\s*]*MERCHANTABILITY[\s*]*or[\s*]*FITNESS[\s*]*FOR[\s*]*A[\s*]*PARTICULAR[\s*]*PURPOSE.[\s*]*See[\s*]*the[\s*]*GNU[\s*]*General[\s*]*Public[\s*]*License[\s*]*for[\s*]*more[\s*]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist)
Change-Id: Ia01908544f4b92a2e06ea621eca548e582728280
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41178
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This replaces GPLv2-or-later and GPLv2-only long form text with the
short SPDX identifiers.
Commands used:
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.*of.*the.*License.*or.*(at.*your.*option).*any.*later.*version.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-or-later */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*as.*published.*by.*the.*Free.*Software.*Foundation[;,].*version.*2.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This program is free software[:;].*you.*can.*redistribute.*it.*and/or.*modify.*it.*under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation[.;,].+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
perl -i -p0e 's|/\*[*\n\t ]*This software is licensed under.*the.*terms.*of.*the.*GNU.*General.*Public.*License.*version.*2.*as.*published.*by.*the.*Free.*Software.*Foundation,.+This.*program.*is.*distributed.*in.*the.*hope.*that.*it.*will.*be.*useful,.*but.*;.*without.*even.*the.*implied.*warranty.*of.*MERCHANTABILITY.*or.*FITNESS.*FOR.*A.*PARTICULAR.*PURPOSE..*.*See.*the.*GNU.*General.*Public.*License for more details.[\n\t ]*\*/|/* SPDX-License-Identifier: GPL-2.0-only */|s' $(cat filelist)
Change-Id: I7a746088a35633c11fc7ebe86006e96458a1abf8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
That makes it easier to identify "license only" headers (because they
are now license only)
Script line used for that:
perl -i -p0e 's|/\*.*\n.*This file is part of the coreboot project.*\n.*\*|/* This file is part of the coreboot project. */\n/*|' # ...filelist...
Change-Id: I2280b19972e37c36d8c67a67e0320296567fa4f6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41065
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
This change moves all ACPI table support in coreboot currently living
under arch/x86 into common code to make it architecture
independent. ACPI table generation is not really tied to any
architecture and hence it makes sense to move this to its own
directory.
In order to make it easier to review, this change is being split into
multiple CLs. This is change 3/5 which basically is generated by
running the following command:
$ git grep -iIl "arch/acpi" | xargs sed -i 's/arch\/acpi/acpi\/acpi/g'
BUG=b:155428745
Change-Id: I16b1c45d954d6440fb9db1d3710063a47b582eae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40938
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
.acpi_fill_ssdt() does not need to modify the device structure. This
change makes the struct device * parameter to acpi_fill_ssdt() as
const.
Change-Id: I110f4c67c3b6671c9ac0a82e02609902a8ee5d5c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40710
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
dev_name() does not need to modify the device structure. Hence, this
change makes the struct device * parameter to dev_name() as const.
Change-Id: I6a94394385e45fd76f68218bf57914bddd2e2121
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40703
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
.write_acpi_tables() should not be updating the device structure. This
change makes the struct device * argument to it as const.
Change-Id: I50d013e83a404e0a0e3837ca16fa75c7eaa0e14a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40701
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
|
This change adds a helper function dev_find_matching_device_on_bus()
which scans all the child devices on the given bus and calls a
match function provided by the caller. It returns the first device
that the match function returns true for, else NULL if no such device
is found.
Change-Id: I2e3332c0a175ab995c523f078f29a9f498f17931
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40543
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change adds a helper function to find PCI device with dev# and
function# behind a PCI-to-PCI bridge device.
BUG=b:153858769
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ie5672b35cda66431a0f1977f217bdf61d3012ace
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40474
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change checks to ensure that device/path passed into any of the
functions in device_const.c is not NULL. Since NULL is not expected to
be passed into these functions, this change adds a die() call in case
the assumption is broken.
Change-Id: I1ad8d2bcb9d0546104c5e065af1eeff331cdf96d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
Change-Id: Idea18f437c31ebe83dd61a185e614106a1f8f976
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|
|
`.read_resources` and `.set_resources` are the only two device
operations that are considered mandatory. Other function pointers
can be left NULL. Having dedicated no-op implementations for the
two mandatory fields should stop the leaking of no-op pointers to
other fields.
Change-Id: I6469a7568dc24317c95e238749d878e798b0a362
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40207
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Providing an explicit no-op function pointer is only necessary for
`.read_resources` and `.set_resources`. All other device-operation
pointers are optional and can be NULL.
Change-Id: I3d139f7be86180558cabec04b8566873062e33be
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40206
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Unmentioned fields are initialized with 0 (or NULL) implicitly. Beside
that, the struct has grown over the years. There are too many optional
fields to list them all.
Change-Id: Icb9e14c58153d7c14817bcde148e86e977666e4b
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40126
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Done with sed and God Lines. Only done for C-like code for now.
Change-Id: Id5fe26564147ec532850430ea55b19ee94d5c5a5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40050
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
|
|
These two identifiers were always very confusing. We're not filling and
injecting generators. We are filling SSDTs and injecting into the DSDT.
So drop the `_generator` suffix. Hopefully, this also makes ACPI look a
little less scary.
Change-Id: I6f0e79632c9c855f38fe24c0186388a25990c44d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39977
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: David Guckian
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change Graphics Init default for RUN_FSP_GOP to depend on
INTEL_GMA_HAVE_VBT rather than INTEL_GMA_ADD_VBT, since
RUN_FSP_GOP selects INTEL_GMA_ADD_VBT for several Intel SoC's.
Test: create default config for gogle/cyan, RUN_FSP_GOP
still default display init selection but no more circular
dependency warning from config.
Change-Id: I8b978d9938c3d0024d4dd40000b988430664cee7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Adjust the defaults for Graphics Initialization so
that the "best" option for a board is selected by default.
Net effect is to select RUN_FSP_GOP over VGA_ROM_RUN
in cases where the platform supports GOP init and the
mainboard has a VBT file included.
Test: run 'make menuconfig' and check default Display
Init option for google/cyan, observe RUN_FSP_GOP is default.
Change-Id: I2184dbdd943d035d1682b3ae7bd8d005221434b1
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39871
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
AMD's Family 17h SoCs share the same video device ID, but may need
different video BIOSes. This adds the common code changes to check the
vendor & device IDs along with the revision and select the correct video
BIOS to use.
Change-Id: I2978a5693c904ddb09d23715cb309c4a356e0370
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/2040455
Reviewed-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-by: Matt Papageorge <matt.papageorge@amd.corp-partner.google.com>
Reviewed-by: Justin Frodsham <justin.frodsham@amd.corp-partner.google.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
|
