After ChromeOS NVS was moved to a separate allocation and the use
of multiple OperationRegions, maintaining the fixed offsets is not
necessary.
Use actual structure size for OperationRegions, but align the
allocations to 8 bytes or sizeof(uint64_t).
Change-Id: I9c73b7c44d234af42c571b23187b924ca2c3894a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The system will hang when resuming from S3 if the SSD reset gpio is not
reset early enough.
Change GPP_A11 in baseboard to PLTRST to avoid an S3 resume hang.
BUG=b:174776411
BRANCH=none
TEST=none
Change-Id: Ia78d813cb6bc689b07e8d8ead1ade6e77f925ce1
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Part of the soc/amd/stoneyridge code already uses the FCH_IOAPIC_ID and
GNB_IOAPIC_ID defines. Use those defines in the remaining location to
make sure that the IOAPIC IDs are always consistent between the hardware
register, the MADT and the IVRS ACPI tables.
TEST=Timeless build of amd/gardenia results in identical binary.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I410a6560de66889b153c8a66b8dc5474ac114ba7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Now that device NVS is no longer used as such, stop using it to store
ACPI device settings consumed by the SSDT generator. Instead, provide
the get_acpi_device_state() function to allow saving ACPI device BARs
and activation state from other compilation units. Also, introduce an
enum and a struct to ease handling device state.
Tested on out-of-tree Compal LA-A992P, SerialIO SSDT does not change.
Change-Id: I9e70bf71e808651cb504399dcee489a4d1a70e67
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52521
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The same functionality can be provided through a runtime-generated SSDT.
The remaining parts of device NVS are removed in a follow-up.
Since the SSDTs are only loaded after the DSDT (if loaded at all), using
SSDT-provided objects outside method bodies is not possible: the objects
are not yet in OSPM's ACPI namespace, which causes in ACPI errors. Owing
to this, the operation regions used by the _PS0 and _PS3 methods need to
be moved into the SSDT, as they depend on the SSDT-provided BAR1 values.
Tested on out-of-tree Compal LA-A992P, generated SSDT disassembles with
no errors and contains expected values. Linux does not complain either.
Change-Id: I89fb658fbb10a8769ebea2e6535c45cd7c212d06
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52520
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Use the same code from Lynx Point on Broadwell, and adjust as needed.
Also add a config file to ensure the code gets build-tested.
Tested on out-of-tree Compal LA-A992P (Haswell ULT), UART 0 works.
Change-Id: I527024098738700d5fbaf3e27cf4db331a0322bd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
In ACPI mode the device cannot be enumerated and thus the payload and
bootloader doesn't know about the active resources.
An ACPI aware OS can use the _CRS to determine the active MMIO window.
Mark the BAR0 as reserved if the device is in ACPI mode to make sure the
BAR is reserved in e820 tables.
Change-Id: I6079b1eb7b0c87c752515340aac8776244b30ca0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55271
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Create the gimble variant of the brya0 reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:190334274
BRANCH=None
TEST=util/abuild/abuild -p none -t google/brya -x -a
make sure the build includes GOOGLE_GIMBLE
Change-Id: If425571d95b3b20910f890428fb5726ebad2fdf4
Signed-off-by: Mark Hsieh <mark_hsieh@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55300
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The `location` member of `struct boot_state_callback` is conditionally
guarded depending on `CONFIG(DEBUG_BOOT_STATE)` using preprocessor. It
is probably intended to save some space when the `location` strings do
not get printed. However, directly using the `location` member without
any guards will cause a compile-time error. Plus, preprocessor-guarded
code gets nasty really quickly.
In order to minimise preprocessor usage, introduce the `bscb_location`
inline helper function, which transforms the compile-time error into a
link-time error. It is then possible to substitute preprocessor guards
with an ordinary C `if` statement.
Change-Id: I40b7f29f96ea96a5977b55760f0fcebf3a0df733
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Create the scout variant of the puff reference board by copying
the template files to a new directory named for the variant.
(Auto-Generated by create_coreboot_variant.sh version 4.5.0).
BUG=b:187080143
BRANCH=None
TEST=util/abuild/abuild -p none -t google/hatch -x -a
make sure the build includes GOOGLE_SCOUT
Signed-off-by: Jeff Chase <jnchase@google.com>
Change-Id: I3be9d2d30821c2c9132ed94c9faf1f33b62bbc7e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55173
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
We are not currently tracking how long it takes to load verstage. The
enum values already exist, they just weren't used.
BUG=b:179092979
TEST=Dump timestamps
501:starting to load verstage 2,280,656 (1)
502:finished loading verstage 2,340,845 (60,189)
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I2cde58cb8aa796829a4e054e6925e2394973484b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The warm reset bit in the NCP_ERR register doesn't behave as the PPR [1]
suggested; no matter if something was written to the register, the
NCP_WARM_BOOT bit never got set and the NCP_ERR register in I/O-space
always reads back as 0x7f.
[1] checked with PPR for AMD Family 19h Model 51h A1 (CZN) #56569 Rev
3.01
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I569372db9f36ec7bbc741f4d7312ade312daa70b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55101
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
