In CB:44488 the cbmem addition was re-filling the object
when it should be memcpy()ing from static object. Correct
that oversight. The side effect from the previous implementation
would be if FSP-M modified the GPE state.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I158a89ae28431896fa9b5789292000fcbf0b066d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44533
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPP_A19(DP_HPD1) and GPP_A20(DP_HPD2) were configured native function
(NF1) without internal pull-down which wrongly presents HPD interrupts.
DP_HPD had been removed for EVT design as those events are through eSPI.
This change configures GPP_A19 and GPP_A20 to be no connection and
disables DdiPort1Hpd and DdiPort2Hpd.
BUG=b:162566436
TEST=Booted to kernel and verified no kernel HPD pins assertion message
on Volteer EVT board.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ia3245741b776b75073d2b43d36c8ea40b476b3ed
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44501
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The wake source macro for GPE events was using 'GPIO'. However,
current usage is really all GPEs. Therefore, provide clarity
in the naming in order to allow for proper GPIO wake events
that are separate from the ACPI GPE block.
BUG=b:159947207
Change-Id: I27d0ab439c58b1658ed39158eddb1213c24d328f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Configure TRACKPAD_INT_ODL pad reset config to DEEP and
map PMC_GPE_DW to PMC_GPP values.
TEST=System should wake from S3 via trackpad
Change-Id: I58ce3720e0fdeefb2c9440bb3006897ef80211ea
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43949
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
PMC_GPE_DW mapping was not configured correctly and hence
coreboot skipped programming Tier 1 GPIOs resulting in failure of
S3 wake from Trackpad.
TEST=System should wake from S3 via trackpad
Change-Id: I59ce3720e0ffeefb2c9440bb300689def80211ea
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
After `make clean` a new build should not be based on stale artifacts.
Hence we have to remove them.
Change-Id: I540a83a6c87b843b1c4c9c55990bf3e91fe90d79
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
After `make clean` a new build should not be based on stale artifacts.
Hence we have to remove them.
Change-Id: I18292c674986078d991668124193b6aa31234d47
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44179
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Similar to commit b45ed65, the HOB structure is actually a 8 byte
address pointing to the HOB data.
Tested=Verified the values of the hob fields are the same printed by
soc_display_memmap_hob().
Change-Id: I348d3cd80a56e86d22f20fcadf0316b462b86829
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Enable long mode in SMM handler.
x86_32 isn't affected by this change.
* Enter long mode
* Add 64bit entry to GDT
* Use x86_64 SysV ABI calling conventions for C code entry
* Change smm_module_params' cpu to size_t as 'push' is native integer
* Drop to protected mode after c handler
NOTE: This commit does NOT introduce a new security model. It uses the
same page tables as the remaining firmware does.
This can be a security risk if someone is able to manipulate the
page tables stored in ROM at runtime. USE FOR TESTING ONLY!
Tested on Lenovo T410 with additional x86_64 patches.
Change-Id: I26300492e4be62ddd5d80525022c758a019d63a1
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37392
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Eugene Myers <cedarhouse1@comcast.net>
Add support for Cannonlake-LP SoCs (Whiskeylake-U,
Coffeelake-U, Cometlake-U) as a separate parsing profile,
copying the existing 'Sunrise' profile and adjusting for differences
in reset mapping and GPIO macro generation
Test: convert inteltool GPIO log dump into coreboot macros for
an out-of-tree CML-U board.
Change-Id: I86296697ee892af7aa0818fb608b6d68fad2f307
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44457
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maxim Polyakov <max.senia.poliak@gmail.com>
Add new librem_whl baseboard and Librem Mini variant.
Tested with SeaBIOS, Tianocore, and Heads payloads.
All functions working normally except SATA, which is limited
via a FSP UPD to 3Gbps until the correct HSIO PHY settings
can be determined.
https://puri.sm/products/librem-mini/
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Change-Id: I36af42766f85eb17f86f6ec9b48b87125fb911e6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40278
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
FSP enables IPU (Imaging Processing Unit) by default even if its
disabled in devicetree. We need to fill FSP upd based on the device
enablement in devicetree.
BUG=None
BRANCH=None
TEST=IPU is disabled and doesn't show in lspci.
Change-Id: I0f9a40e85427fd88bb12a40770ecf7b939b1d8cd
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Enable the introduced LPSS ACPI uart driver.
Tested on Hermes using Linux 5.6:
The UART2 appears as /dev/ttyS2.
Change-Id: Ic15be4a807012216e52c848120de7e39522f57b7
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44411
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Emit ACPI code for LPSS UARTs operating in ACPI mode. In this mode the
device vendor ID reads as 0xffff, the PCI devices is still operate.
Add ACPI device IDs for APL, GLK, SPT, SPT_H and CNP_H.
The mainboard's devicetree needs to be adapted to include the chip
driver and the PCI ID when it wouldn't have been hidden.
Example:
chip soc/intel/common/block/uart
device pci 19.2 hidden
register "devid" = "PCI_DEVICE_ID_INTEL_CNP_H_UART2"
end # UART #2
end
Tested on Linux 5.6 with Sunrise Point ACPI ID for UART2.
Tested on Windows for all other UARTs.
Change-Id: I838d16322be38f5421c1f63b457a0af552e0ed96
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40405
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPE events were not be recorded in the eventlog. Add those
to the eventlog when the status register indicates those events.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ifb3167fd24f2171b2baf1a65eb81a318eb3e7a86
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Previously the chipset state was snapshotted very late in the boot
(ramstage). Instead start gathering the state early in romstage
prior to calling any FSP routines so there's a clean snapshot.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id41686e6cdf5bebc9633b514b4121b0447f9be2d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44488
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Now that no one is consuming this object, remove its definition.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ib5aeec1733b6c9fa49569e30c4c369f70af0939c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44487
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Now that no one is consuming this object, remove its definition.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I60e4a9bfdf2752923f46a35aaab7034f9fa9b309
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44486
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Now that all users of the functions manipulating global state
and using soc-specific objects are removed remove those functions.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I18c4c8b0c7852dde8cf0b6b3f11e43e15c3ce155
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Transition the current call sequence to using the newly added common
ACPI helper functions. Semantically, the expectations are that this
sequence is the equivalent of previous acpi_clear_pm1_status(). However,
in subsequent patches picasso will be snapshotting state way sooner than
ramstage.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I34e2ba7c5cd123b98c39291537e74175ec043e85
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44484
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Transition the current call sequence to using the newly added common
ACPI helper functions. Semantically, the expectations are that this
sequence is the equivalent of previous acpi_clear_pm1_status().
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Id3ae19013c68d2c97b084046f600596ecc462374
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to reduce code duplication provide an acpi_fill_gnvs()
helper function. Intent is to move stoneyridge and picasso over
to using this common implementation instead of duplicating it.
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I21c6e2c24eaf42f31ae57c05df7f633d7dc266d9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44482
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The existing code in common/block/acpi is mixing multiple operations:
saving things to cbmem in common code but then soc code uses that
information, reliant upon soc-specific struct soc_power_reg object,
and only saving/snapshotting ACPI registers very deep in ramstage.
To unwind the above provide some functions that are more targeted:
- Add struct acpi_pm_gpe_state object
- Add acpi_fill_pm_gpe_state()
- Add acpi_pm_gpe_add_events_print_events()
- Add acpi_clear_pm_gpe_status()
BUG=b:159947207
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia7afed2861343802b3c78728784f7cfaf6f53f62
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Unlike Linux kernel which has a static shadow region layout, we have
multiple stages in coreboot and thus require a different shadow offset
address. Unfortunately, GCC currently only supports adding a static
shadow offset at compile time using -fasan-shadow-offset flag.
For this reason, we enable GCC to determine asan shadow offset address
at runtime using a callback function named __asan_shadow_offset().
This supersedes the need to specify this address at compile time. GCC
then makes use of this shadow offset to protect stack buffers by
inserting red zones around them.
Some other benefits of having this GCC patch are:
a. We can place the shadow region in a separate linker section with
all its advantages like automatic fit insurance. This ensures if
a platform doesn't have enough memory space to hold shadow region,
the build will fail. (However, if we use a fixed shadow offset on a
platform that actually doesn't have enough memory, it may still
build without any errors.)
b. We don't modify the memory layout compared to the current one, as
we are placing the shadow region at the end of the space already
occupied by the program.
c. We can be much more flexible later if needed (thinking of other
stages like bootblock).
d. Since we are appending the shadow buffer to the region already
occupied, we make efficient use of the limited memory available
which is highly beneficial when using cache as ram.
Further, we have made sure that if you compile you tree with ASan
enabled but missed this patch, it will end up in the following
compilation error:
"invalid --param name 'asan-use-shadow-offset-callback'"
So, you cannot accidentally enable the feature without having your
compiler patched.
Change-Id: I401631938532a406a6d41e77c6c9716b6b2bf48d
Signed-off-by: Harshit Sharma <harshitsharmajs@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This fix is required to avoid the division-by-zero error described at
https://mail.coreboot.org/pipermail/coreboot/2014-March/077418.html
while trying to run the DDR3 memory at 1866 MT/s (933 MHz).
With this fix in place, ASUS A88XM-E boots fine with RAM at 1866 MT/s.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I8e7d00e362879b1247ecf2ab828936268bf9075f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40485
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Required for adding the XMP profiles support. SPD buffer is
already 256 bytes at AMD AGESA vendorcode, so this is fine.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I7340b110477a4cc1ecb1c239181436e51952568f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40484
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Naming a device allows an ACPI _ROM method to be written for it. GPUs
may require this to make the configuration data contained within
available to an OS driver. This may be required for GPUs that do not
contain their vBIOS, or perhaps the drivers require it in this form/fashion.
Working on an Acer Aspire VN7-572G (Skylake-U). nouveau successfully
obtains the vBIOS via ACPI (kernel 5.7.11).
Change-Id: Ida87aebf8fdf341ab350c2bb3704d2ef695cf8f0
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Rob Barnes