This is the only AGESA f14 board which has a different version string.
As it is most likely a copy-paste error, drop the redefinition of this
macro from buildOpts.c and use the value defined in AGESA f14 headers.
Change-Id: I384bd96db51457e68a320b99ecdbb2ada0dfbdd5
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41621
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Until now, the buildOpts.c files were primarily made out of copy-pasted
AGESA options, commented-out definitions and several useless comments;
that is, the materialization of technical debt in GCC-parsable form...
Until now.
It is assumed that the boards in the tree still boot. So, by comparing
their settings, we can extract saner defaults to place into AGESA. Many
of the settings were common across all boards of the same family, so we
promote those values to default settings. In some cases flipping a flag
was required, so the macros to alter that option had to be adapted as
well. Since those AGESA versions are expected to never receive updates,
it should not be a problem to change their files to suit our needs.
As a result, all but two buildOpts.c files now have less than 100 lines.
AGESA f14 boards need less than 50 lines, and f15tn/f16kb just require
about 60 or 70 lines in those files. Hopefully, this will make porting
more mainboards using AGESA f14/f15tn/f16kb a substantially easier task.
TEST=Use abuild --timeless to check that all AGESA f14/f15tn/f16kb
mainboards result in identical coreboot binaries.
Change-Id: Ife1ca5177d85441b9a7b24d64d7fcbabde6e0409
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
This change updates pch_hda.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
BUG=none
BRANCH=none
TEST="BUILD for Volteer"
Signed-off-by: Venkata Krishna Nimmagadda <venkata.krishna.nimmagadda@intel.com>
Change-Id: Ia2bab6dcbac9eae76ac4258c44bb19425c8b5c80
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41799
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
This change updates camera_clock_ctl.asl to use ASL2.0 syntax. This
increases the readability of the ASL code.
BUG=none
BRANCH=none
TEST="BUILD for volteer"
Signed-off-by: Venkata Krishna Nimmagadda <venkata.krishna.nimmagadda@intel.com>
Change-Id: I6370e4b268331bfba5bc0392f27c560836b6ea72
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41798
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Determine the TcssDma0 and TcssDma1 enabling based on TBT DMA
controllers setting.
BUG=🅱️146624360
TEST=Booted on Volteer and verified TcssDma0 and TcssDma1 enabling.
lspci shows TcssDma0(0d.2) and TcssDma1(0d.3).
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I61ac4131481374e9a2a34d1a30f822046c3897fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41812
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Enable heci1 device from devicetree for PCI enumeration. This is
required for ME status dump using HFSTSx resgisters in PCI config
space. Heci1 device is later disabled through heci disable flow.
TEST=Build, boot waddledoo. ME status dump is seen in console logs.
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: Icb77db3f0666c2d14ebef2c3214564346d1fd3c9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Matching the same behavior change in depthcharge's FIT image code
(CL:2212466), this patch changes the order in which compat strings
involving revision and SKU numbers are matched when looking for a
compatible device tree. The most precise match (board-revX-skuY) is
still the highest priority, but after that we will now first check for
revision only (board-revX) and then for SKU only (board-skuY). The
reason for this is that SKU differentiation is often added later to a
project, so device trees for earlier revisions may not have SKU numbers
defined. So if we have a rev0 board (with sku0 as the "default SKU",
because the board only started having different SKUs with rev1) we want
it to match the board-rev0 device tree, not board-sku0 which was added
as an alias to board-rev1-sku0 to provide the best known default for
potential later revisions of that SKU.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ia3cf7cbb165170e2ab0bba633fec01f9f509b874
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
On Picasso, DRAM is up by the time FSP-M runs. This change relocates
FSP-M binary to a specific address (0x90000000) in DRAM. Currently,
this address is randomly chosen to ensure it does not overlap any of
the other stages. Once we have a unified memory map set up for
Picasso, this address can be updated along with it.
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I1a49765f00de9f97fa3dbd5bc288a3ed0d7087f6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41828
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The first DRAM part supported by SPD_LPDDR4X_200b_4Gb_3733_DDP_1x16 is
NT6AP256T32AV-J2 so the SPD content is generally extracted from it's
SPD. On the other hand, SPD bytes 4 / 6 / 13 were amended to follow SoC's
requirement.
BUG=b:152277273
BRANCH=None
TEST=build the image successfully.
Change-Id: If6fb0855a961d1c68315a727466bf45569cf2597
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41813
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch selects the fmd files based on config
BOARD_GOOGLE_BASEBOARD_PUFF and also renames the files
to align with basebaord name and layout size.
BUG=b:154561163
TEST=Built puff and verified that it selects the right fmd file.
Change-Id: Ice6196ca778c6c118ce89e1510a445339a5c3455
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41568
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch selects the fmd files based on config
BOARD_GOOGLE_BASEBOARD_HATCH and also renames them to
add the baseboard name and layout size tags.
BUG=b:154561163
TEST=Built hatch variants and verified that they select the
right fmd files.
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Change-Id: I5d99ae28cc972ffa635adf100b756c36e168a8f8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All hatch and puff variants use 16MiB SPI flash except the legacy ones
which used 32MiB flash. Kconfig.name is updated to select
BOARD_ROMSIZE_KB_32768 only for the legacy variants and
BOARD_GOOGLE_HATCH_COMMON selects BOARD_ROMSIZE_KB_16384 by default if
BOARD_ROMSIZE_KB_32768 is not selected.
TEST=Verified using abuild --timeless that all hatch variants generate
the same coreboot.rom image with and without this change.
Change-Id: I708506182966936ea38562db8b0325470e34c908
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41662
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: V Sowmya <v.sowmya@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Run the command below to fix all occurrences.
git grep -l OVERIDES | xargs sed -i 's/OVERIDES/OVERRIDES/g'
Change-Id: I5ca237500a0ecff59203480ecc3c992991f08130
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41856
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
VBOOT_EC_EFS is for EFS1 and EFS1 is deprecated. Puff uses EFS2
and its variants should follow.
BUG=b:157372086
BRANCH=none
TEST=emerge-puff coreboot
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I581f137b506a96df45e5bed21833856bb4f6aaa3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41806
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Implementation of the ACPI objects for the Type-C Connector Class was
added in the previous patch. This patch removes the functionality from
the ChromeEC's SSDT generator, and uses acpigen_usb instead.
TEST=Verified contents of SSDT are the same.
Change-Id: Icdbcee1f989ee3146f7495e08fc13f9386791858
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The USB Type-C Connector Class in the Linux kernel is not specific to
the ChromeOS EC, so this functionality is now split out into a separate
file, acpigen_usb.c. Documentation about the kernel side is available at
https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html.
Change-Id: Ife5b8b517b261e7c0068c862ea65039c20382c5a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41539
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The Linux ChromeOS EC driver now looks for 3 new properties under each
USBC.CONx device contained within the ChromeOS EC device. These
properties are just a reference to the device that controls the
switches for USB 2/3 muxing, SBU lines, and CC lines. It uses the new
function, soc_get_pmc_mux_device() to retrieve the device.
Change-Id: I03cd83f9b2901b5583053fac8ab6eab64717a07d
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40618
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ChromeOS EC is adding new entries to its USBC.CONx devices (see later
patch), and it needs to get access to the PMC.MUX device so that its
ACPI path can be retrieved. This provides a weak function to return NULL
for all Intel SoCs except for Tiger Lake, which locates the device if it
is found in the devicetree.
Change-Id: I3fe3ef25e9fac8748142f5b1bd870c9bc70b97ff
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
At least some Pollock engineering samples return FP5 socket type while
they are in fact FT5 socket type.
Change-Id: I06a19c19374532bfb367fc15c734707d8c7f65a3
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41796
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
soc_is_pollock() and soc_is_picasso() aren't used by any mainboard or
soc code. The same fuctionality is still provided by get_soc_type().
Change-Id: I046b4925bfeb4b31d11e2548ac87b7bbca0f6475
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41795
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow the ability for chipset or mainboard to choose to
compress FSP-M in cbfs using LZMA or LZ4 routines. However, only
non-XIP platforms will support FSP-M compression. Since the main
cbfs decompression paths are utilized add the appropriate checks
for including compression algorithms under the FSP-M compression
options.
On picasso FSP-M (debug builds) the following savings were measured:
no-compression:
fspm.bin 720896 none
FSP_COMPRESS_FSP_M_LZ4:
fspm.bin 138379 LZ4 (720896 decompressed) -80%
FSP_COMPRESS_FSP_M_LZMA:
fspm.bin 98921 LZMA (720896 decompressed) -86%
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I5c88510c134b56a36ff1cd97a64b51ab2fea0ab0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In an attempt to help reduce the amount of static ASL files that are
littered throughout the codebase, pmc.asl was converted to runtime SSDT
generation instead. If future SoCs reuse the same PMC, then this
function can be moved to soc/intel/common/block/pmc for example.
TEST=Verified the following was in the decompiled SSDT:
Scope (\_SB.PCI0)
{
Device (PMC)
{
Name (_HID, "INTC1026") // _HID: Hardware ID
Name (_DDN, "Intel(R) Tiger Lake IPC Controller")
Name (_CRS, ResourceTemplate ()
{
Memory32Fixed (ReadWrite,
0xFE000000, // Address Base
0x00010000, // Address Length
)
})
}
}
Also the following found in linux's /var/log/messages:
"acpi INTC1026:00: GPIO: looking up 0 in _CRS", indicating the PMC
ACPI device was found and its _CRS was locatable.
Change-Id: I665c873d8a80bd503acc4a9f0241c7a6ea425e16
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Dragonegg is no longer in development nor used. Remove it.
Change-Id: Ida30dba662bc517671824f8b70b73b4856836e97
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41783
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow the ability for chipset or mainboard to choose to
compress FSP-S in cbfs using LZMA or LZ4 routines. To accomplish
this fsp_load_component() is added as an assist for performing
the necessary logic and allow the caller to provide the destination
selection. Since the main cbfs decompression paths are utilized add
the appropriate checks for including compression algorithms under
the FSP-S compression options.
On picasso FSP-S (debug builds) the following savings were measured:
no-compression:
fsps.bin 327680 none
FSP_COMPRESS_FSP_S_LZ4:
fsps.bin 98339 LZ4 (327680 decompressed) -70%
FSP_COMPRESS_FSP_S_LZMA:
fsps.bin 71275 LZMA (327680 decompressed) -78%
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I8aa5d8c1cbaf4d08f38a918a9031a2570bc5247e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41449
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The LZ4 compressed stages assume in-place decompression. The constraints
are validated in cbfstool for _stages_ such that they can be decompressed
in place. However, that is only true for stages. As such, add a wrapper,
cbfs_stage_load_and_decompress(), that handles the LZ4 stage loading case.
BUG=b:155322763,b:150746858,b:152909132
Change-Id: I9525a266250aa6c775283b598c09d4f40692db55
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41755
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Builds where RESET_X86_VECTOR is adjusted would create unintentionally
large bootblock files since id section can move far away from .reset
and .text. Some builds segfault or may try to create close to 4 GB
large intermediate build objects.
For cases where build is successful, id section would not reside within
REGION(program) or REGION(bootblock).
A proper fix to always place the ID data at the end of the coreboot.rom
file is left as follow-up work. For now, just place id section below
.reset.
Change-Id: Idf0e4defcde6d5e264d4752cc93f4ffb6749d287
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The sections .rom.* were for romcc and no longer used.
Some romcc comments were left behind when guards were removed.
Change-Id: I060ad7af2f03c67946f9796e625c072b887280c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Current implementation returns the incorrect GPIO community PID.
The GPIO community index 3 should return PID for COMM_4 and index
4 should return PID for COMM_5.
TEST=Verify GPIO PM bits are correctly set through MS0x ACPI method.
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: I3da4945e93605a297baff076295433164fdf613d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41721
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
So far, the semantics have been that run-unit-tests stopped at the first
test suite that failed. This hides useful signal in later tests, so
always run all tests and collect the result.
Change-Id: I407715f85513c2c95a1cf89cfb427317dff9fbab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
They're not added as a dependency, even though that should be possible,
because we want the build tests to run even when the unit tests fail.
Change-Id: Ia3391d7b289160178fa773dfd7b7c51c6ef77805
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Put it in $(objutil) so that it's shared between board builds with
abuild even if that doesn't matter right now.
Change-Id: I5670d9b661891262ad936980f63fa93b07c27e95
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41770
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jan Dabros <jsd@semihalf.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CB:34634 expanded the VPD code to also be usable from romstage,
shuffling a few things around and adding some extra infrastructure in
the process. Unfortunately, the changes seem to have only been written
with x86 devices in mind and make coreboot always load the whole VPD
FMAP section (not just the used part) on devices where rdev_mmap() is
not a no-op.
This patch rewrites the VPD code to be based on region_device structures
that only represent the VPD area actually used (rather than the whole
FMAP section), and that only get mapped when accessed. (It would be even
better to pull this concept into the VPD decoder itself, but since that
is taken from third-party code and accesses in early stages aren't very
common, let's not go there for now.) It also moves the copying into
CBMEM to romstage so that late romstage accesses can already benefit
from it, and makes early decoding available in all stages because at
this point, why not.
Also fix a long-standing bug where the 'consumed' counter was not reset
between vpd_decode_string() calls to the RO and the RW VPD.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I55a103180b290c1563e35a25496188b6a82e49ff
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41757
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
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>
This reverts commit 1726fa1f0ce474cde32e8b32be34a212aff3ffba.
Reason for revert: Resource allocator is split into old(v3) and
new(v4). So, this change to enable hotplug resource allocator for
volteer can land back.
BUG=b:149186922
Change-Id: Ib6a4df610b045fbc885c70bff3698a032b79f770
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41468
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
The templates for the zork reference boards are still being actively
worked on in the trembyle-bringup branch. Remove the zork template
from the main branch to avoid confusion when trembyle-bringup is
merged.
BUG=b:157099580
BRANCH=none
TEST=N/A
Signed-off-by: Paul Fagerburg <pfagerburg@chromium.org>
Change-Id: I0ff9de959c7b2646b90e68df05f0b2e9bdd60cf7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Current implementation returns the incorrect GPIO community PID.
The GPIO community index 3 should return PID for COMM_4 and index
4 should return PID for COMM_5.
TEST=Verify PCR port id is correct for each community.
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I5dc48e5b31f43853b3a613c17f13f7df71f1fbfa
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41725
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Angel Pons