Document a general overview of when and how microcode should be updated.
Also explain what microcode updates are, and why they are required.
Change-Id: I6dbe25122fa45a416ed64180ef1bfb11afe676ba
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44400
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Returning a const uint32_t doesn't do anything, and it conflicts with the
declaration of sku_id() in include/boardid.h.
Change-Id: I2719e5782c9977f8ca4ce8f1dd781f092aa73d64
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1428708
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44746
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
MediaTek SoCs have been maintained by Hung-Te and team for a couple of
years now, let's update the documentation to reflect that.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I5adc9160409a98f90edcff6e7915ed3161d235c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Follow HW schematic to correct DDSP_HPD1/2/3 and USB_OC3 pin.
BUG=b:165175296
BRANCH=none
TEST=Check all USB ports USB2 and USB3 both functional
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: I2f941141d761b1b69bc8f9ef0b0c4516062fec4a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Removing entry covering root region leads to situation where
num_entries counter is set to 0. This counter is further decremented
in function obtaining address to last entry (see root_last_entry()).
Such negative number may be further used as an index to the table.
Current implementation may lead to crash, when user removes last entry
with imd_entry_remove() and then calls for example imd_entry_add().
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: I6ff54cce55bf10c82a5093f47c7f788fd7c12d3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44668
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
One of the checks inside imdr_recover() was written with the
assumption that imdr limit is always aligned to LIMIT_ALIGN. This is
true only for large allocations, thus may fail for small regions.
It's not necessary to check if root_pointer is under the limit, since
this is implicitly verified by imdr_get_root_pointer().
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: I25d6291301797d10c6a267b5f6e56ac38b995b7b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Previously it was allowed to create an imd_entry with size 0, however
algorithm sets the offset of such entry to the exact same address as
the last registered entry.
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: Ifa2cdc887381fb0d268e2c199e868b038aafff5f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Add a check that root_size provided by the caller accounts for one
imd_entry necessary for covering imd_root region. Without this, we
may end up with writing on unallocated memory.
Signed-off-by: Jan Dabros <jsd@semihalf.com>
Change-Id: I0a39d56f7a2a6fa026d259c5b5b78def4f115095
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Get rid of the second check whether r is NULL (this is already done by imdr_has_entry()).
Signed-off-by: Anna Karas <aka@semihalf.com>
Change-Id: Ibee1664ee45b29d36e2eaaa7dff4c7cc1942010b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Remove the repetition from the comment.
Signed-off-by: Anna Karas <aka@semihalf.com>
Change-Id: Ibe6e38636b96b6d8af702b05a822995fd576b2fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44662
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Includes changes related to GPIO pad to configure I2C4 required for UFC
Change-Id: Ica3ac31f10214b8aff3bb64a2c3b42ccfa28bdcd
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
This unlocks 1866 MHz frequency for AMD boards of f15tn family.
Tested on ASUS A88XM-E with A10-6700 and Crucial BLT8G3D1869DT1TX0.
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Change-Id: I547d7e9ca89524d66ee0ee307de41699d991f9fc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40490
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 81066b7ce7.
Reason for revert: The hang observed when not exposing the reset GPIOs was root caused to zork sharing the same I2C bus between touchscreen and touchpad and interleaving of messages during probe which resulted in incorrect information returned back by touchscreen firmware. Exposing the reset GPIO changed the timing of probe and hence helped workaround the hang issue. The touchscreen driver is now fixed to perform I2C transactions in a single transfer and so the hang is no longer observed when reset GPIO isn't exposed.
BUG=b:162596241
BRANCH=zork
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ica11c33d542dd2324bb0b8905c5de06047cee301
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This will ensure that the cold reset is performed when CSE Lite jumps
from RO to RW.
BUG=b:162977697
TEST=Verify CSE reset is cold (sits in S5 for PCH Min Slp Duration time)
Change-Id: Ib1173e219ba46ee3275824220c8cf790b1d497fa
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44684
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Add "MEMORY_TYPE = lp4x" to the generated Makefile.inc to indicate
this is lpddr4x memory and to use the generic SPDs from the lpddr4x
respository of SPDs.
BUG=b:160157545
TEST=run gen_part_id for volteer and verify that it adds the line "MEMORY_TYPE =
lp4x" to the makefile produced.
Change-Id: I416690ae8aff8052474b16ef0d3e940e72e6a2fb
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Serial Presence Detect (SPD) data for memory modules is used by Memory
Reference Code (MRC) for training the memory. This SPD data is
typically obtained from part vendors but has to be massaged to format
it correctly as per JEDEC and MRC expectations. There have been
numerous times in the past where the SPD data used is not always
correct.
In order to reduce the manual effort of creating SPDs and generating
DRAM IDs, this change adds tools for generating SPD files for DDR4
memory used in memory down configurations on Intel Tiger Lake (TGL)
based platforms. These tools generate SPDs following JESD79-4C and
Jedec "4.1.2.L-5 R29 v103" specification.
Two tools are provided:
* gen_spd.go: Generates de-duplicated SPD files using a global memory
part list provided by the mainboard in JSON format. Additionally,
generates a SPD manifest file (in CSV format) with information about
what memory part from the global list uses which of the generated
SPD files.
* gen_part_id.go: Allocates DRAM strap IDs for different DDR4
memory parts used by the board. Takes as input list of memory parts
used by the board (with one memory part on each line) and the SPD
manifest file generated by gen_spd.go. Generates Makefile.inc for
integrating the generated SPD files in the coreboot build.
BUG=b:160157545
Change-Id: I263f936b332520753a6791c8d892fc148cb6f103
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
If there's already been an error and PSP_verstage is booting to RO,
don't reset the system. It may be that the error is fatal, but if the
system is stuck, don't intentionally force it into a reboot loop.
BUG=None
TEST=Force an error, still boots to RO instead of going into a boot loop
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Ibb6794fefe9d482850ca31b1d3b0d145fcd8bb8f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44652
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Jasper Lake does not have any use case for multiphase SI init so
Disable it.
BUG=b:162184827
BRANCH=None
TEST=Build and boot JSLRVP
Cq-Depend: chrome-internal:3221772
Change-Id: I2d591b46c403e68ff0b41ac8f87c742ae774111e
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43816
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: Maulik V Vaghela <maulik.v.vaghela@intel.com>
We hit a similar issue on Cereme, so I checked the trembyle base board
which also uses AUX4/HDP4 for the last DDI port, so using AUX3/HDP3 is
wrong there.
Change-Id: I99f9426969488cc5c5a14bd432b38bfd69ae7ef0
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44688
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Matt Papageorge <matthewpapa07@gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
Instead of halting if the vboot workbuf is not passed to coreboot by the
PSP, reset and reboot into recovery mode.
This process is made more difficult because if the workbuf isn't
available, we can't reboot directly into recovery - the workbuf is
needed for that process to be done through the regular calls, and we
don't want to go around the vboot API and just write into VBNV directly.
To overcome this, we set a CMOS flag, and reset the system.
PSP_verstage checks for this flag so it will update VBNV and reset the
system after generating the workbuf.
BUG=b:152638343
TEST=Simulate the workbuf not being present and verify the reboot
process.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: I049db956a5209904b274747be28ff226ce542316
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44538
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We need to pull update_mrc_cache into mrc_cache_stash_data, so moving
to end of the file to make sure update_mrc_cache is defined before.
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
reboot from ec console. Make sure memory training happens.
reboot from ec console. Make sure that we don't do training again.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I9e14fec96e9dabceafc2f6f5663fc6f1023f0395
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Create two new functions to fetch mrc_cache data (replacing
mrc_cache_get_current):
- mrc_cache_load_current: fetches the mrc_cache data and drops it into
the given buffer. This is useful for ARM platforms where the mmap
operation is very expensive.
- mrc_cache_mmap_leak: fetch the mrc_cache data and puts it into a
given buffer. This is useful for platforms where the mmap operation
is a no-op (like x86 platforms). As the name mentions, we are not
freeing the memory that we allocated with the mmap, so it is the
caller's responsibility to do so.
Additionally, we are replacing mrc_cache_latest with
mrc_cache_get_latest_slot_info, which does not check the validity of
the data when retrieving the current mrc_cache slot. This allows the
caller some flexibility in deciding where they want the mrc_cache data
stored (either in an mmaped region or at a given address).
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
reboot from ec console. Make sure memory training happens.
reboot from ec console. Make sure that we don't do training again.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I259dd4f550719d821bbafa2d445cbae6ea22e988
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44006
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
update telemetry value with the SDLE test result.
BUG=b:158964769
BRANCH=none
TEST=emerge-zork coreboot
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: Ic419ca5ca00e4e8602dbc12212a8a63ed3657e02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Move interrupt status and wake status clearing to after GPIO config so
that configuration does not incorrectly set interrupt or wake status.
i.e. when PULL_UP is configured on a pad, it incorrectly sets in the
interrupt status bit. Thus, the interrupt status bit must be cleared
after initial pad configuration is complete.
BUG=b:164892883, b:165342107
TEST=None
BRANCH=None
Signed-off-by: Josie Nordrum <josienordrum@google.com>
Change-Id: If4a5db4bfa6a2ee9827f38e9595f487a4dcfac2c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44640
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Each variant WiFi SAR CBFS will be added with the default name
"wifi_sar_defaults.hex".
so we just need to look up the default CBFS file as the WiFi SAR
source.
BUG=b:159304570
BRANCH=zork
TEST=1. cros-workon-zork start coreboot-private-files-zork
2. emerge-zork chromeos-config coreboot-private-files-zork \
coreboot chromeos-bootimage
Change-Id: Idf859c7bdeb1f41b5144663ba1762e560dcfc789
Signed-off-by: Kevin Chiu <kevin.chiu@quantatw.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44672
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Jasper Lake SoC had PCI root port mapping swap, thats why we were
using swapped mapping earlier for all the boards
Recently, patch was pushed to handle this swap in PCI enumeration code
for Jasper Lake and we need to correct this mapping. Now this mapping
aligns with actual port mapping in the schematics
BUG=None
BRANCH=None
TEST=NVMe and WLAN are getting detected after this changes
Change-Id: Ide5f8419a15f559cefeb6039f155fabf97c279f8
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
pmc_set_acpi_mode will set EC SMI mask to 1 in the end.
However google_chromeec_events_init will clear EC SMI mask.
If google_chromeec_events_init is ran after pmc_set_acpi_mode, the EC SMI mask
will be 0 in depthcharge and causes lidclose function not working.
So, pmc_set_acpi_mode() should run after google_chromeec_events_init.
This code is mainly from CB:42677
BUG=b:16338215
TEST=Close lid in depthcharge and the dut can be shutdown on waddledoo.
Signed-off-by: Kane Chen <kane.chen@intel.com>
Change-Id: I0f06e8b5da00eb05a34a6ce1de6d713005211c08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44563
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>
Configure gpio settings for FPMCU on Halvor.
BUG=b:153680359
TEST=After flash FP MCU FW, during bootup we see spi id spi-PRP0001:01 in dmesg.
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Change-Id: I5503cfe0fb9933e98ed01afeef8cad1345593ac6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44575
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Halvor uses TBT 0/1/2 for USB type C. We doesn't use PCIE/USB3 port
therefore disable PCIE/USB3 ports and enable TBT 2.
Follow volteer to set USB2 OC_SKIP.
BUG=b:165175296
BRANCH=none
TEST=Check all USB ports USB2 and USB3 both functional
Signed-off-by: Eric Lai <ericr_lai@compal.corp-partner.google.com>
Change-Id: Ifb844ce475f3d58f0c95be0f172fc49edb4cd5fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
default_memmove() calls memcpy() when (src > dst). This is safe for the
default_memcpy() implementation, but just calling memcpy() may invoke an
architecture-specific implementation. Architectures are free to
implement memcpy() however they want and may assume that buffers don't
overlap in either direction. So while this happens to work for all
current architecture implementations of memcpy(), it's safer not to rely
on that and only rely on the known implementation of default_memcpy()
for the forwards-overlapping case.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7ece4ce9e6622a36612bfade3deb62f351877789
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44691
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Create areas for console & timestamp data in psp_verstage and pass it to
the x86 to save for use later.
BUG=b:159220781
TEST=Build & Boot trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I41c8d7a1565e761187e941d7d6021805a9744d06
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42830
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
- 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.
- Enable Vtd IPU and IGD settings only if respective IPs are enabled.
BUG=165340186
BRANCH=None
TEST=IPU is disabled and doesn't show in lspci.
Change-Id: Ieff57fb0ebc8522546d6b34da6ca2f2f845bf61d
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44627
Reviewed-by: Daniel H Kang <daniel.h.kang@intel.corp-partner.google.com>
Reviewed-by: John Zhao <john.zhao@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
GPP_D16 is routed to the main power enable pin on several PCIe SD card
controllers on SD daughterboards. We should enable the power to these
chips as early as possible so they can participate in PCIe
enumeration.
BUG=b:162722965
TEST=Verified RTS5261 and GL9755 daughterboards enumerate on PCI and
can read SD cards.
Change-Id: Icf5e770f540e5d1e27b40f270bb004f4196bc7be
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Angel Pons