The current elog implemetation searches for an active PME status bit by
iterating the PCI devices. On disabled or hidden devices a BUG gets
triggered: BUG: pch_log_rp_wake_source requests hidden ...
This is caused by the use of the PCH_DEV_* macros which resolve to
_PCH_DEV and finally call pcidev_path_on_root_debug.
Disabled devices are skipped already so we can safely use the DEVFNs
instead, circumventing the BUG.
Change-Id: Id126e2c51aec84a4af9354b39754ee74687cefc8
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39089
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Leverage the common sku id space helper encoders.
dedede uses the non-legacy SKU ID space.
squash in,
mainboard/google/dedede: Migrate onto get fw_config helper
BUG=b:149348474
BRANCH=none
TEST=only tested on hatch
Change-Id: I0c21a748fddef0985022cb4e77a8db95d6692f4b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Leverage the common sku id space helper encoders and
set the sku id max to 0xff for legacy to ensure we
behave the same.
BUG=b:149348474
BRANCH=none
TEST=tested on hatch
Change-Id: I60a37a5f9659b8df4018872956f95e07a3506440
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39035
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add an optional commandline flag to define the filename of the resulting
output file. If this flag is not defined, it will behave like before by
using the old filename with a ".new" suffix.
With this additional flag it is not necessary to move the output file at
build-time, and the stdout print "Writing new image to <filename>" makes
more sense in the build context.
Change-Id: I824e94e93749f55c3576e4ee2f7804d855fefed2
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38828
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add gpio definition for Jasper Lake gpio controller.
Also created a separate file for JSL and TGL gpio keeping common asl file.
gpio_soc_defs.h must pass correct information/macro values to asl file
for code to work.
GPIO controller includes 4 gpio community and 10 groups. Patch adds
definition for all gpio within community and groups
Updated IRQ mapping for all gpios
TEST=Check if jslrvp and tglrvp code is compiling
Change-Id: Iae4e694ecb30658e43c5ed99e5436579fd7d2ed2
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Signed-off-by: Usha P <usha.p@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39111
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
For a very long time, SeaBIOS sometimes failed to build when using
multiple threads. This known problem has been haunting everyone for a
very long time. Until now.
Unlike most other payloads, building SeaBIOS results in two files: the
SeaBIOS payload itself and SeaVGABIOS. Each file has its own target, and
there's a third target called "seabios", which has the same recipe as
the SeaBIOS file, which calls `payloads/external/SeaBIOS/Makefile` with
a bunch of arguments. In addition, SeaVGABIOS depends on "seabios".
When executing serially, if the file of either SeaBIOS or SeaVGABIOS is
needed, the SeaBIOS Makefile will be run. This will generate both files,
so it is not necessary to run the Makefile more than once.
However, when using multiple threads, it can happen that one thread
wants to make the SeaBIOS file, while another one wants to make the
SeaVGABIOS file, which depends on "seabios". This implies that both
threads will execute the SeaBIOS Makefile at about the same time, only
to collide when performing git operations. Since git uses a lock file
when updating the index, one of the threads will fail to acquire the
lock with an error, which will ultimately cause the build to fail.
Whenever this happened, manually aborting with Ctrl-C made the build
process fail again because of the same error. The only way to get past
this problem, other than using one thread, was to let the unfinished
jobs complete. The thread that acquired the lock on the SeaBIOS git
repository would finish building SeaBIOS, so that target would not need
to be remade. When restarting the build, only the target that failed is
rebuilt, so it does not collide with any other thread.
To address this issue, make the SeaVGABIOS file target depend directly
on the SeaBIOS file instead, and remove the duplicate "seabios" target.
Change-Id: I251190d3bb27052ff474f3cd1a45022dab6fac31
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39188
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
All boards using this code use i82371eb (that shares PCI ID with i82371ab).
Dropping the code lightens compressed ramstage by a few dozen bytes.
Change-Id: Iab1e83b8f5fff44a33619c7925e5448169a2a87c
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38598
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
XOE# and XDIR# can be used as GPOs 23/22 if X-Bus functionality is not
required. Turns out asus/p2b-ls is using them to control termination
for the onboard SCSI buses. Add support to allow this reconfiguration.
Change-Id: I2dab6fafbd67a98ed1cac1ffcf9352be4a87c3e9
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38352
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Relocate the first size check. This was automatically continuing
and not looking for the caller incorrectly passing a destination.
New information indicates that the APOB_NV should always be present
in the system. Augment the missing size check to inferring whether
a missing size is valid, as in the case of older products, or truly
missing when it's needed.
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Change-Id: I51f5333de4392dec1478bd84563c053a508b9e9e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Fix two out-of-bounds reads in lz4 decompression:
1) LZ4_decompress_generic could read one byte past the input buffer when
decoding variable length literals due to a missing bounds check. This
issue was resolved in libpayload, commonlib and cbfstool
2) ulz4fn could read up to 4 bytes past the input buffer when reading a
lz4_block_header due to a missing bounds check. This issue was resolved
in libpayload and commonlib.
Change-Id: I5afdf7e1d43ecdb06c7b288be46813c1017569fc
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
cbfs_get_handle() and cbfs_get_attr() are both looping over elements to
find a particular one. Each element header contains the element's
length, which is used to compute the next element's offset. Invalid or
corrupted CBFS files could lead to infinite loops where the offset would
remain constant across iterations, due to 0-length elements or integer
overflows in the computation of the next offset.
This patch makes both functions more robust by adding a check that
ensure offsets are strictly monotonic. Instead of infinite looping, the
functions are now printing an ERROR and returning a NULL value.
Change-Id: I440e82fa969b8c2aacc5800e7e26450c3b97c74a
Signed-off-by: Alex Rebert <alexandre.rebert@gmail.com>
Found-by: Mayhem
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
