| Age | Commit message (Collapse) | Author |
|---|
|
While the board configuration still works without this,
It's nicer to have the device statically defined since
the NIC is hardwired to the board.
Change-Id: Ic6682865dd17672c3782bfba9511cd120d1657c1
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/13455
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a "depends on SMP" to the value SQUELCH_EARLY_SMP Kconfig value to
disable its selection when SMP is not enabled.
TEST=Build for Galileo
Change-Id: Ia3aa1d2169ed793e1bb26538b74b12347453d5af
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13639
Tested-by: build bot (Jenkins)
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the code to enable debug serial output using HSUART1:
* Enable the code using Kconfig value ENABLE_BUILTIN_HSUART1
* Note that the BIST value is always zero as validated in
esram_init.inc
* The initial TSC value is currently not saved!
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Testing is successful if serial output is present on HSUART1 at
115200 baud, 8-bit, no parity
Change-Id: I7e6181e8b9bc901c3ab236f0b56534850bb6bfd0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13445
Tested-by: build bot (Jenkins)
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
|
|
As the audio card needs 1.8V I2C operation. This patch adds
entry into devicetree.cb to set I2C port 4 operate at 1.8V.
TEST=Built & booted lars board. Verified that I2C
port 4 is operating at 1.8V level
Change-Id: Ia77841a26d024785d53251ca4b17afcf77f36a5b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e431e7acd85f6d7bf9d47f54ed41c48b8276071c
Original-Change-Id: Iccc85a5e3bbf2b5362665036e1294a6635e38fbe
Original-Signed-off-by: David Wu <David_Wu@quantatw.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/321000
Original-Commit-Ready: David Wu <david_wu@quantatw.com>
Original-Tested-by: David Wu <david_wu@quantatw.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13627
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Enable the option to back up Vboot non-volatile data from CMOS
to flash as these boards have the necessary nvram fmap region
and are using vboot2 which does not backup to the TPM.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I7bfe88f2cb7826f3315987aaf56f77df708896ce
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35df03c5ef24406129cba920ee9af6d55458cd45
Original-Change-Id: Ia7c014fe2768c55941a65ec5605ef4fbc986151c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324123
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This adds a new kconfig option that will back up the VBNV data
from CMOS to flash, and restore it if the CMOS data is invalid
during boot.
This allows special flags to not get lost when power is lost,
RTC reset is triggered, or CMOS is corrupted.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell:
1-boot and run "enable_dev_usb_boot"
2-reboot and check that it is enabled with crossystem
3-run "mosys nvram clear"
4-reboot and check that it is still enabled
Change-Id: I38103d100117da34471734a6dd31eb7058735c12
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8a356e616c6885d5ae3b776691929675d48a28f9
Original-Change-Id: I06e7ddff7b272e579c704914a0cf8cc14d6994e8
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324122
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The developer mode gpio switch on rialto is always hardcoded (through a
resistor) as developer mode. We need to ignore it to allow transitions to
verified mode with the virtual developer mode stuff.
TEST=We can now exit dev mode on rialto
Change-Id: I94a949f0973132de5fd008224af79cf612151193
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e78bb8f81eaa9c082e47ad818b64843c2565d00b
Original-Change-Id: If11d752d58a5f26fc270ef01b529dad18b4cce46
Original-Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325861
Original-Commit-Ready: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13626
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Certain platforms query the recovery mode switch more than just within
vboot during the boot flow. Therefore, it's important that the first call to
get_recovery_mode_switch() is consistent through memory training because
certain platforms use the recovery mode switch to take different action
for memory training. Therefore, defer the clearing of the rec mode
switch to a place when it's known that memory is up and online.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Three finger salute is honored on chell by retraining memory.
Change-Id: I26ea51de7ffa2fe75b9ef1401fe92f9aec2b4567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b0de9369242e50c7ff3b164cf1ced0642c7b087
Original-Change-Id: Ia7709c7346d1222e314bf3ac7e4335a63e9a5144
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325120
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
kunimitisu platform updated these two fields if maxim codec
is detected.
BUG=chrome-os-partner:49570
BRANCH=glados
TEST=Build & Booted kunimitsu board. Verified that kernel
can read new strings.
Change-Id: Icbe0d87f0b46da794db36191b0e12948fe6a2fe6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f3d07ef07c382a2df140b457273feb3899228e10
Original-Change-Id: Ia6a111d15b851ae3fa918816e13b54ace215a09a
Original-Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/324631
Original-Commit-Ready: Yang Fang <yang.a.fang@intel.com>
Original-Tested-by: Yang Fang <yang.a.fang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13603
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch added nhlt_soc_serialize_oem_overrides and
nhlt_serilalize_oem_overrides to be able to override oem_id and
oem_table_id.board file can pass specific string by calling
nhlt_soc_serialize_oem_overrides
kernel use these two fields to construct a topology binary name
if the designate file is not found a default dfw_sst.bin will be used
it is optional.
BUG=chrome-os-partner:49570
BRANCH=glados
TEST=Build & Booted kunimitsu board. Verified that kernel
can read new strings.
Change-Id: I00b64fb8bb63de601d3116e0b8941057c1efa230
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 374ce08b2d8a2f4e5dd7f51eacb505dbb77fd171
Original-Change-Id: I03623c8ac81efb5a5ea3ec9c6cd604d2e9294022
Original-Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/322860
Original-Commit-Ready: Yang Fang <yang.a.fang@intel.com>
Original-Tested-by: Yang Fang <yang.a.fang@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13602
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This modifies the vbnv_flash driver to make it safe for use
in cache-as-ram by handling the global variables safely.
To make this cleaner all of the variables were moved into
one structure and referenced from there.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell using following patches to
test backup and restore of vbnv_cmos into flash
Change-Id: I3a17fa51cfd754455502ac2e5f181dae35967f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48876561fa4fb61e1ec8f92596c5610d97135201
Original-Change-Id: Id9fda8467edcc55e5ed760ddab197ab97d1f3d25
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13599
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The VBNV region size is determined by vboot and is not really
configurable. Only the CMOS implementation defined this config
variable so switch it to use VBNV_BLOCK_SIZE defined by vboot
in vbnv_layout.h instead.
This requires updating the broadwell/skylake cmos reset functions
to use the right constant.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d
Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324520
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add a wrapper around the vbnv implementations and call into the different
backend functions from there. Also move some of the common functions to
the common code and simplify the backend drivers. This will allow some
of the code to be re-used so the CMOS backend can backup the data into
the flash backend.
One side effect of this is that the cache of VBNV was removed from CMOS
and EC backends and moved into the VBNV wrapper, but the flash backend
also still has a separate cache because it has more state and complexity
in the implementation. The wrapper cached data is not used for normal
vbnv_read/vbnv_write because some callers need the ability to force a
write if the backend storage is cleared (i.e. CMOS clear).
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4d2e0e99af7e8a44aec77ad9991507401babcca6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c30f60434a64f6c0eb9ede45d48ddafff19dd24f
Original-Change-Id: Ia97f6607c5ad837b9aa10b45211137221ccb93a0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13597
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Successfully invoke TempRamInit from the FSP binary:
* Don't relocate the FSP binary image
* Copy the FSP binary into ESRAM
* Specify Kconfig values to easily debug ESRAM and TempRamInit code
* Specify the FSP binary file location
* Specify the FSP binary image ID
* Specify where in the flash image the FSP image must reside
* Specify the FSP data file location
* Specify where to place the FSP data file in the flash image
* Specify where in the ESRAM the FSP image must reside
Test 1 on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Add "select ENABLE_DEBUG_LED_FINDFSP"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Testing is successful if the SD LED is on indicating that the FSP.bin
file was properly located, The test fails if the SD LED is flashing.
Test 2 on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file
* Remove "select ENABLE_DEBUG_LED_FINDFSP"
* Add "select ENABLE_DEBUG_LED_TEMPRAMINIT"
* Testing is successful if the SD LED is on indicating that the FSP.bin
file was properly located, The test fails if the SD LED is flashing.
Change-Id: I1e2e413a8573f750c611b0f9df101b2c869a789e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13443
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The Quark SoC uses ESRAM instead of cache-as-RAM. This code requires
that utils/xcompile/xcompile change the machine architecture from i686
to i586 to ensure that the Quark does not attempt to execute unsupported
instructions:
* Adjust Makefile.inc to add the RMU to the coreboot image
* Add code to enable the ESRAM
Directly use the QuarkSocPkg/QuarkNorthCluster/Include/QuarkNcSocId.h
file from the EDK2 tree (https://github.com/tianocore/edk2.git) to
enable
easy differences and correct issues in coreboot that were found in EDK2.
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file
* Add "select ADD_RMU_FILE"
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Remove power from the board
* Apply power to the board
* Testing is successful if the SD LED is on indicating that the end of
esram_init.inc was reached
Change-Id: I91d919da144bb72a5d4c4a8050ffab256632a395
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13440
Tested-by: build bot (Jenkins)
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Remove the "static" declaration from fsp_run_silicon_init and declare
the routine in ramstage.h. This routine can be called directly when FSP
is already in RAM.
TEST=Build and run on Galileo
Change-Id: Iddb32d00c5d4447eab5c95b0ad5c40309afa293e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13630
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add missing file to fix complaints by git commit script.
TEST=None
Change-Id: I4aac63821a7208fb86fa6c0dda16b7537e49a69a
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13610
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Idefa304a27823c741fab72ff5c2f20fed1aa5a39
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13523
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Also updated KGPE-D16 strings to KCMA-D8 throughout the copy to work
around Jenkins failures caused by an unmodified clone.
Change-Id: I943e81c8c2987a8333fc2a1cdb3675abf2d90cf1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13521
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I28ad2298ad4dfb428dcd41a4f00db88c5e817cd7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13173
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
On certain systems and CPUs Core Performance Boost (CPB) may cause
sporadic system lockups. This issue is also somewhat known on the
various proprietary BIOSes, therefore it seems to be a hardware
incompatibility when present.
Allow the user to disable CBP if needed.
Change-Id: Id6395d067d48963f6c084ad0bf79e23419af24d8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13172
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Certain registered DIMMs failed training due to an error
likely introduced during historical rebase. Ensure that
the SubMemclkRegDly bit is set according to BKDG
recommendations on Family 15 processors.
Change-Id: I24c95265dada9eabf4df280b6f2b4a1eb9cecaf1
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13148
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Under certain conditions, not elucidated in the BKDG,
an extra memclock of CAS write latency is required.
The only reliable way I have found to detect when this
is required is to try training without the delay, and
if DQS position training fails, adding the delay and
retraining.
This is probably related in some form or another to
the badly broken DQS Write Early algorithm given
in the BKDG.
Change-Id: Idfaca1b3da3f45793d210980e952ccdfc9ba1410
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13531
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Multilink Family 15h processors were being configured with an
incorrect PowerStepUp/PowerStepDown value. Set the value
according to the BKDG, and clean up the terrible formatting
of the power_up_down() function that led to the incorrect
values being overlooked until now.
Also change u32 declarations to uint32_t in modified functions.
Change-Id: I16e1f5205d6b5f349a3e7167dea04c9eefda4684
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13174
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
- Stop blinking when coming out of standby.
- Remove code to set blink when going into S3. This never
worked correctly.
Change-Id: I958990f3203d3cbe7ae64833800d631c1034327f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13171
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the files to build soc/intel/quark and mainboard/intel/galileo for a
minimal coreboot image. Please note that this configuration does not
run. Include HTML documentation for the Galileo Gen 2 board.
Testing is successful if build completes successfully.
TEST=Build for Galileo
Change-Id: Idd3fda1b8ed9460fa8c92e6dcaa601c3c9f63a36
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13507
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
These devicetree patches set the ACPI PM Disabled variable to 1.
This will disable the ACPI PM timer and remove from FADT table.
BRANCH=none
BUG=chrome-os-partner:48646
TEST=Build for skylake board with the PmTimerDisabled policy in
devicetree set to 1.
iotools mmio_read32 0xfe0000fc should return 0x2.
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
should list only "tsc hpet". acpi_pm should be removed from this list.
Change-Id: Ia66f37e13f0f2f527651418b8b5c337b56c25c7f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: db3e8130495038850c7034b89701b4a5fcf88dce
Original-Change-Id: Ib1b876cfa361b8cbdde2f9e212e3da4fd724e498
Original-Signed-off-by: Archana Patni <archana.patni@intel.com>
Original-Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/319362
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13589
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Keeping ACPI PM timer alive prevents XTAL OSC shutdown in S0ix
which has a power impact.
Based on a DT variable, this patch disables the ACPI PM timer
late in the boot sequence - disabling earlier will lead to a hang
since the FSP boot flow needs this timer. This also hides the ACPI PM
timer from the OS by removing from FADT table. Once the ACPI PM timer
is disabled, TCO gets switched off as well.
BRANCH=none
BUG=chrome-os-partner:48646
TEST=Build for skylake board with the PmTimerDisabled policy in
devicetree set to 1.
iotools mmio_read32 0xfe0000fc should return 0x2.
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
should list only "tsc hpet". acpi_pm should be removed from this list.
Change-Id: Icfdc51bc33b5190a55196d67e18afdaaa2f9b310
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 18bcb8a434b029295e1f1cc925e2b47e79254583
Original-Change-Id: Ifebe8bb5a7978339e07e4e12e174b9b978135467
Original-Signed-off-by: Archana Patni <archana.patni@intel.com>
Original-Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/319361
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13588
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The setting of the SPI controller BAR was conditional
on the nominal frequency being set. Therefore, that doesn't
mean the SPI BAR is set on all boots. Move the setting of
the BAR in the southbridge_bootblock_init() which is called
prioer to cpu_bootblock_init().
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Confirmed spibar is always set on glados.
Change-Id: Ia58447d70f5e39a4336d4d08593f143332de833a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 56fff7c25c2eb0ccd90e08f71c064b83c66640f8
Original-Change-Id: I1e0cff783f4b072b80589a3a84703a262b86be3a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/319461
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13587
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Vboot keeps track of the size of the hashed region in each
RW slot. While that size was being used to calculate the hash
it wasn't being honored in restricting the access within the
FMAP region for that RW slot. To alleviate that create a sub
region that covers the hashed data for the region in which
we boot from while performing CBFS accesses.
BUG=chrome-os-partner:49764
BUG=chromium:445938
BRANCH=glados
TEST=Built and booted chell with cbfstool and dev-util patches.
Change-Id: I1a4f45573a6eb8d53a63bc4b2453592664c4f78b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ac9e84af5b632e5735736d505bb2ca6dba4ce28
Original-Change-Id: Idca946926f5cfd2c87c4a740ad2108010b6b6973
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324093
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to support both separate verstage and a verified boot after
romstage one needs to ensure the proper GPIO and EC configuration
been complete. Therefore, move that logic to
car_mainboard_post_console_init() in car.c file which gets called
in the early flow of a CAR stage (either verstage or romstage).
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=None
Change-Id: I331f25ad4764cab972af7198f6154f604d2dbeae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2c1cb04645cbf34696e6adf48acec9d396e87ca9
Original-Change-Id: I8d14ea16b2d07bbf04c5c33e4205a85d9f21847b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324075
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13585
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to support both separate verstage and a verified boot after
romstage one needs to ensure the proper GPIO and EC configuration
been complete. Therefore, move that logic to
car_mainboard_post_console_init() in car.c file which gets called
in the early flow of a CAR stage (either verstage or romstage).
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built kunimitsu w/ separate verstage.
Change-Id: If34cae5516a6df7f72f1f57cab495db70787177e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 543155665e1b05efe82c7440c124a5c83c656aa6
Original-Change-Id: I7281c4373fcbaaf0beedaa63dcf0dedb5316349f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324074
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13584
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to support both separate verstage and a verified boot after
romstage one needs to ensure the proper GPIO and EC configuration
been complete. Therefore, move that logic to
car_mainboard_post_console_init() in car.c file which gets called
in the early flow of a CAR stage (either verstage or romstage).
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built glados w/ separate verstage and booted.
Change-Id: I626a500c183d21f94d976e24f09af15a242fba9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b564514a8b93f53a919fcdac3589e30dbac82124
Original-Change-Id: Icc989ec5700b3f1a144a6b41198b7dd2c2aac6f7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324073
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13583
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to support both separate verstage and a verified boot after
romstage one needs to ensure the proper GPIO and EC configuration
been complete. Therefore, move that logic to
car_mainboard_post_console_init() in car.c file which gets called
in the early flow of a CAR stage (either verstage or romstage).
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell w/ separate verstage and booted.
Change-Id: Ic728c2904006376fdc2b27b512f72173a2260be3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 42d190af8996fea894305ebe686afbfda5f2b8a5
Original-Change-Id: I95aeb97737d0ddfa6c53269c9d14db16ed5e47cc
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324072
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13582
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
When vboot_handoff_flag() is called in the bootblock or a separate
verstage there's no memory nor the possibility of dram coming online.
Therefore, don't bother to attempt call cbmem_find().
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell with separate verstage which pulls in vboot_common.c
dependency. No more linking errors w/ cbmem_find() not being
around.
Change-Id: I494c93adc1c00459fdfaa8ce535c6b4c884ed0fb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 414ce6aeaff657dc90289b25e5c883562189b154
Original-Change-Id: I8a5f2d154026ce794a70e7ec38883fa3c28fb6e7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324070
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13580
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Some of the functions within bootmode.c may be required
by boards in verstage. Therefore, allow this file to be built
in verstage.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell w/ bootmode.c dependencies in separate verstage.
Change-Id: Id291c1b5cc6594c3ee16c7c3385e682addc0efb6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 084b620e12e7f948087786c0e34d5999a73137a5
Original-Change-Id: I2207819ec1490767cb1cf4b92e34e714783c1c22
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324071
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13581
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to not reboot loop in the face of failed vboot verification
on resume set the PM1 control register to indicate S5. After the
subsequent cold reset the PM1 control register will indicate S5
as it should.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=On chell injected failed vboot verification. Ensured a reboot
loop doesn't ensue.
Change-Id: Ie5e9e3f6441a217a5e02b4d78aaf21f8249b8a43
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a63b57d7bc59bcaf5518f7cc4afccd3d5da6df1c
Original-Change-Id: I5e467854bf065a138bd46e476a7e7088f51454ca
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323504
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13579
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To allow skylake platforms to run with verified memory init
code the chipset needs to implement vboot_platform_is_resuming()
so that the vboot code can make proper decisions.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
Change-Id: I508a339c07dcc9e7c56a0df4201660827b3ae07a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a3e11789339bcd8fc8fc99b704c6a1110acf5302
Original-Change-Id: I40264019eb28e85795258112c720056a6a3fc523
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323503
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13578
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. To that end, allow Chrome OS EC to supply the plumbing
to vboot for storing and retrieving the RW slots' hash digest
using the vstore backend.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
Change-Id: Ib056f7e6b3386447ed1ff95c740ef5b4544f9049
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c78546b1d6298a4c397a587c564df6d9d097e75
Original-Change-Id: I86c96a4092deab2dfa51b3043b9dba16b6a4c201
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323502
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13577
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Sometimes it's necessary for the platform to perform clean up
tasks prior to reboot when employing vboot. For example, x86 systems
that resume and do vboot verification may need to clear their
sleep control register prior to doing a cold reset so that the
next boot doesn't appear to be a resume. Allow that hook by
introducing vboot_platform_prepare_reboot().
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Ensure vboot_platform_prepare_reboot() called from vboot_reboot().
Change-Id: I622c9181d9fa3048204e3df3223d5dd4b458abca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f31ffc40bde002dec398fd4dd9d2ee9d65df0d7b
Original-Change-Id: I97318cec34494a7fc4b1ecf2cb22715d20e730ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323501
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13575
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Display ME firmware status before os boot. Specifically this
patch reads out the ME hfsts1 and hfsts2 status registers that provide
information about overall ME health before device gets disabled.
This change reused most of the code from bdw me_status implementation.
BUG=chrome-os-partner:47384
BRANCH=glados
TEST=Builds and Boots on FAB4 SKU2/3. Can observe me status table
Change-Id: Ia511c4f336d33a6f3b49a344bfbaea6ed227ffeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a9d0fb411c3921654f0fdcea2a3d4ee601987af2
Original-Change-Id: Ied7e2dcd9a1298a38dfe1eda9296b9ca8eccf6b1
Original-Credits-to: Duncan Laurie <dlaurie@chromium.org>
Original-Signed-off-by: Dhaval Sharma <dhaval.v.sharma@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/323260
Original-Commit-Ready: dhaval v sharma <dhaval.v.sharma@intel.com>
Original-Tested-by: dhaval v sharma <dhaval.v.sharma@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13573
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add support functions for the Chrome EC temporary storage interface.
BUG=chrome-os-partner:46049
BRANCH=none
TEST=tested on glados with modified coreboot
Change-Id: Id2bc46df9cb2d82b15e3309e78d07407a622b6f0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a7e6f693666b162e11eb0611715f10a8f465ad88
Original-Change-Id: Ieefabfc5bcb9d8a5064f0da967c46d0f377ca320
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/315217
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13572
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Update to the latest EC command header.
BUG=chrome-os-partner:46049
BRANCH=none
TEST=emerge-glados coreboot
Change-Id: I132f91b31931ed40c20c0f5dbbf4449663768418
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e6d9d51cfe99fe7c3806d1f74ea67b2d2ed5e7e
Original-Change-Id: I3c2e268689d64683f4a138e20f518e6eda49a138
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/315216
Original-Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13571
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add the files for minimal Quark X1000 SoC support:
* Declare pei_data structure
* Declare sleep states and chipset_power_state structure
* Specify top of memory
* Empty FspUpdVpd.h file
TEST=None
Change-Id: If741f84904394780e1f29bd6ddbd81514c3e21c9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13439
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Port i2c driver from uboot to coreboot
BUG=chrome-os-partner:47462
TEST=emerge-cyclone coreboot
BRANCH=tot
Change-Id: I8ce2a965acaed68ad0f0518648490ec471c6810b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c2e9592662787ebed1d0aa8cafaa00fd12c2e9c
Original-Change-Id: If791228edf29405fa4b2f959a21510bd7da9865b
Original-Signed-off-by: Ruilin Hao <rlhao@marvell.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/313342
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/13113
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Port gpio driver from uboot to coreboot
BUG=chrome-os-partner:47462
TEST=None
BRANCH=tot
Change-Id: Ib6cfbb6e44cb642c7af937778076a51d405ff4a2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5cf94502faad96147d4a4adb42eb13edb64a6439
Original-Change-Id: Ia2e081a85347e2fc8bb365ca527ee2ee32af86f1
Original-Signed-off-by: Ruilin Hao <rlhao@marvell.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/313341
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Yuji Sasaki <sasakiy@chromium.org>
Reviewed-on: https://review.coreboot.org/13112
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Port spi driver from uboot to coreboot
BUG=chrome-os-partner:47462
TEST=None
BRANCH=tot
Change-Id: I747be7001f4cfb8eec33e8e5bdef3fe5bb0eb2ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9fbc5c2feb6ffacb54ed94e5c7b94b38be2b2ded
Original-Change-Id: Ibea9a050ac8bdab6ce4eeb07accde53aeadade5f
Original-Signed-off-by: Ruilin Hao <rlhao@marvell.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/313340
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Yuji Sasaki <sasakiy@chromium.org>
Reviewed-on: https://review.coreboot.org/13111
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Skeleton for soc armada38x
BUG=chrome-os-partner:47462
TEST=None
BRANCH=tot
Change-Id: I76f631ee6cdfc90c44727cb20aa960796bc785a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e91cc19468325f005c6ac920bbe27a174c409727
Original-Change-Id: Iac5fc34df1ba18b4515029aa2fcff8f78a5df191
Original-Signed-off-by: Ruilin Hao <rlhao@marvell.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/313179
Original-Commit-Ready: Kan Yan <kyan@google.com>
Original-Tested-by: Kan Yan <kyan@google.com>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/13110
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Walk the bus and try to find enabled devices.
Disable the PEG port if no devices are attached.
Change-Id: I67fcc831fd78ecc6dba83f4e0662ec7549cc2591
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/12894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Issue observed:
The system boots with 4G in channel 0 and 4G in channel 1.
The system doesn't boot with any combination of 4G + 1G in
channel 0 and 4G in channel 1.
In both cases DIMM1 failed, while DIMM0 showed no issues.
Problem description:
The CLK to CMD/CTL was off by a half clock cycle.
The find the issue I X-Y plotted timC vs timB for every
lane on the failing rank.
You can see an offset by 32 units for timB, that is not present on
other ranks.
It turns out that the XOVER CMD/XOVER CTL enable bit for DIMM1 was
missing in program_timings(), which caused the clock offset.
Problem solution:
Add two functions to calculate XOVER CMD and XOVER CTL and use both
to set XOVER in program_timings() and dram_xover().
Final testing result:
The system boots with 4G + 1G in channel 0 and 4G in channel 1.
Test system:
* Intel IvyBridge
* Gigabyte GA-B75M-D3H
Change-Id: I88694c86054ade77e9d8bb2f1fdaf7bc559c1218
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/13415
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Selecting UNCOMPRESSED_RAMSTAGE prevents lzma.c from being compiled for
romstage. Adjust the logic in rmodule.c to prevent calls to the ulzma
routine when UNCOMPRESSED_RAMSTAGE is selected.
TEST=Build and run on Galileo
Change-Id: I7409e082baab3c2a086c57ad5aa9844ba788c7cd
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13591
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This requires payload integration somewhere to be useful, because
without that, adding it will (hopefully) break the signature.
Change-Id: I67b8267e5040e26353df02d258e92a0610e19a52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Use the flags to preset the GBB flags field. The Kconfig defaults are
chosen for a "developer" configuration.
Change-Id: Ifcc05aab10b92a2fc201b663df5ea47f92439a3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The GBB contains hardware-specific data plus some configuration. The
latter isn't supported by this change yet and will come later.
The fields that are supported (hardware ID, bmpfv, vboot keys) are
configurable through Kconfig and point to Chrome OS-style default (eg.
developer keys).
While adding vboot keys, the two keys used to sign RW regions are also
added to Kconfig, even if not yet used.
Change-Id: Icfba6061ca83182df560cd36052fbb257826d4b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Add a target at the end of the build that can be used to run additional
scripts or additional targets after coreboot.rom is built.
- Source a site-local Kconfig file to allow site-specific configuration.
This eliminates the need to add a hook for a script at the end of the
build because you can add one yourself in site-local.
Example site-local/Makefile.inc:
build_complete::
ifeq ($(CONFIG_SITE_LOCAL),y)
echo "Running additional steps in site-local"
# run some script here to make my build unreproducible.
endif
.phony: build_complete
Example site-local/Kconfig:
menu "site-local"
config SITE_LOCAL
bool "site-local enabled"
help
Enable my site-local configuration to do stuff.
endmenu
Change-Id: Id4d1e727c69b5cdb05e7d52731bbb1d1e201864a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13413
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Sync and merge useless differences.
Change-Id: I4eea66c35af66d473dd56db9ccf105c878266f22
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/7513
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Strip out the AMD internal version tag, e.g.
* @e \$Revision: 63425 $ @e \$Date: 2011-12-22 11:24:10 -0600 (Thu, 22 Dec 2011) $
which are false/inconsistent and serve no real meaning or purpose now.
Change-Id: I4cca0899eba66a1c361ba784c5ac0222b0ee1aa6
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/7516
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
pci_def.h is supposed to only contain definitions, such that it may be
included in assembly files. Declaration of functions in said file
prevents that.
Change-Id: I0f90a74291c8a2ef7a1e1027d2d2182f896050fb
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/13300
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Instead of instructing users to edit xcompile when they want to build
a quark platform, give the build a way to set -march=586 so that
the quark code will build correctly. The Quark processor does not
support the instructions introduced with the Pentium 6 architecture.
Change-Id: I0ed69aadc515f86f76800180e0e33bcd75feac5a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13552
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: FEI WANG <wangfei.jimei@gmail.com>
|
|
The registers associated with the MTRRs for Quark are referenced through
a port on the host bridge. Support the standard configurations by
providing a weak routines which just do a rdmsr/wrmsr.
Testing:
* Edit the src/mainboard/intel/galileo/Makefile.inc file
* Add "select DISPLAY_MTRRS"
* Add "select HAVE_FSP_PDAT_FILE"
* Add "select HAVE_FSP_RAW_BIN"
* Add "select HAVE_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Testing is successful if:
* The MTRRs are displayed and
* The message "FspTempRamExit returned successfully" is displayed
TEST=Build and run on Galileo
Change-Id: If2fea66d4b054be4555f5f172ea5945620648325
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13529
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
This fixes some spelling and whitespace issues that I came across
while working on various things in the tree.
There are no functional changes.
Change-Id: I33bc77282f2f94a1fc5f1bc713e44f72db20c1ab
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13016
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
... and move them into the code using them, instead.
Change-Id: I2391234797ad00da8038dda198eadf0b0fcaedb2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13526
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I67271f2a209fc96eea6181f8875a5e69cf98d8c4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13511
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add the AMD A8-660K APU.
Change-Id: I210a8ba962529c26a535965689672a46b09e325f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13510
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ic1da46d2abc8d20987048e4ef1e7a776d0c685d6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13555
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I8996f8ab739a07014a4189738b5624485d752d9d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
- Add CONFIG_ prefix to two symbols.
- Remove the use of the third symbol as it will never be matched.
Change-Id: Ifa7f6884001cb05fb8397f193c4b08a0161f498c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13539
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The COVERAGE_MAGIC macro has a trailing `4' on it, which makes it a
64-bit large integer, as opposed to a 32-bit unsigned integer, as
originally designated in `util/cbmem/cbmem.c'. Remove this number so
building with CODE_COVERAGE will succeed.
Change-Id: Ib5d7f2704a4c092c3eca6f62e219edb30950d793
Signed-off-by: Jean Lucas <jean@4ray.co>
Reviewed-on: https://review.coreboot.org/13520
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ie175b5b490f77cc380536ebd737da8618d4b448b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13170
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
Under certain conditions when the APs are still executing during
MCT setup the system can hang. This was the root cause of most
of the S3 resume failures on this platform; waiting for AP stop
before MCT setup allows for reliable S3 resume.
Change-Id: I329eea9a8912d7b57efe6aae327d24fd6c3fd782
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13169
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Under certain conditions, such as when microcode updates are
being performed, it is important to make sure all APs have
finished updates and are halted before continuing with the
boot process.
Add a new wait_ap_stopped() function to allow for this
functionality to be added to the appropriate mainboard
romstage source files.
Change-Id: Ib455c937888a58b283bd3f8fda1b486eea41b0a7
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13168
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ib331bd330530d4d6be5eb7351d9f9b15c135dd63
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13167
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I5a4e223b2e247decd30d8fb2a083be4cff6500a4
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13166
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I15fedb067f1911799f7528b60b8754f2984b38ec
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13161
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
|
On certain Winbond SuperIO devices, when a PS/2 mouse is not
present on the auxiliary channel both channels will cease to
function if the auxiliary channel is probed while the primary
channel is active. Therefore, knowledge of mouse presence
must be gathered by coreboot during early boot, and used to
enable or disable the auxiliary PS/2 port before control is
passed to the operating system.
Add auxiliary channel PS/2 device presence detect, and update
the Winbond W83667HG-A driver to flag the auxiliary channel as
disabled if no device was detected.
Change-Id: I76274493dacc9016ac6d0dff8548d1dc931c6266
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13165
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ic4b68a032068208d56b2a04150f7fc7d61b38eba
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13164
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The IOMMU/HT device was not routed correctly; add the proper APIC
mappting to the mptable generation code. Also clarify comments
surrounding the pin mappings.
Change-Id: I72ceb0f22dabdfa71a1f6231ccb841face08ff7a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13163
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Ib4f46944f076f1e696cf16a1e532eb8635b603c9
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13162
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I52fc2c2294edead3b5dacf397c0a1ab2e08b1e3f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13160
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: I766eca6369b60a79a6823bc744934e3f1fbc17b2
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13159
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The existing code did not allow for the second core of the BSP to
reside on an APIC ID other than 1, leading to a boot hang on Family
15h processors when APIC_ID_OFFSET was set to anything other than 0.
Furthermore, insufficient AP stack space was allocated for AP start.
Change-Id: I4ded3cfb3736149e2265848014352d7622d5042a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13158
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Change-Id: If67999098fbe2831eeb30cb8b362c558db5d2688
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13157
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Since this code is pulled in through commonlib, it will break compilation
of cbfstool on OSX.
Change-Id: I342bfa7e755aa540c4563bb5cd8cccacee39d188
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13525
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change granluarity to granularity.
Change wacbmem_entryanty to warranty.
Update copyright dates.
TEST=None
Change-Id: Ib7775cb33616751760919a5850777dc6f77a6be9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13528
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Change-Id: Idf74e400efa3fea8eb74f372e4f261ab6567db8a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13513
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
Change-Id: I7dcde170d0f59ea9886342c0d2c09b70b9d0d84d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13537
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
|
|
This is the very very minimum needed to compile the code.
Change-Id: I7f9e5f564181071591a4640019f59f91a4c456c6
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/13297
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Some newer x86 systems can boot from non-memory-mapped boot media
(e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or
other memory, similar to how most ARM chipsets work. In such cases, we
may not have enough code space for romstage very early on. This means
that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to
be implemented within the limited amount memory of storage available.
Since the reset vector has to be contained in this early code memory,
the bootblock is the best place to implement loading of other stages.
Implement a bootblock which does the minimal initialization, up to,
and including switch to protected mode. This then transfers control
to platform-specific code. No stack is needed, and control is
transferred via a "jmp" such that no stack operations are involved.
Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/13485
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
bootblock.S was used strictly for setting up the system so that the
assembly generated by ROMCC could be executed. Since the
infrastructure now exists to run a bootblock wihtout ROMCC, rename
this file accordingly. this is done to prevent any future confusion.
Change-Id: Icbf5804b66b9517f9ceb352bed86978dcf92228f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://review.coreboot.org/11784
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It break x230 access to channel 1.
This reverts commit 9f1fbb9a3002e8d74d53d7973bd1c7e3d4879238.
Change-Id: I8a3b13d17729f25cea3460ac2f87bca3c193d388
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: https://review.coreboot.org/13512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
|
|
Change-Id: I136c259136ce66a0c319a965ae0ee27f66dce1b3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13155
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
since commit f1e321001d5954096f06f9a43138219a9a46536e, the UART init
should be in bootblock_mainboard_early_init() which runs before
console init. (see src/lib/bootblock.c)
Change-Id: Ib00afdd6e81e7689fbd743c8a5f547d424896d71
Reviewed-on: https://review.coreboot.org/13448
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Move the default select of "Use native graphics initialization" for
Peppy to the ChromeOS section as SeaBIOS (default payload) requires a
vBIOS and takes twice as long to load with this option enabled. For the
same reasons, this option shouldn't be enabled by default (def_bool y).
Change-Id: I1f2163e0a1e4bf8e5041dad150bdf7de804fb4db
Signed-off-by: Jean Lucas <jean@4ray.co>
Reviewed-on: https://review.coreboot.org/13493
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
TEST=Boot to OS
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Change-Id: I9b43eb4f6f7af62a8a0bbe7bfa08feee1eaca24e
Reviewed-on: https://review.coreboot.org/13506
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Some trivial cleanup.
Change-Id: I866efc4939b5e036ef02d1acb7b8bb8335671914
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13427
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Now coreboot should do BIOS CAR setup along with NEM
mode setup.
This patch also provides a mechanism to use 16MB code caching
benefit although LLC still limited to 1M/1.5M based
on SOC LLC limit.
Here with unlimited cache line gets replaced. Now we could use
unlimited cache size along with well defined data size
[pg: updated to current upstream #defines]
BUG=chrome-os-partner:48412
BRANCH=glados
TEST=Builds and Boots on FAB4 SKU2/3.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: pchandri <preetham.chandrian@intel.com>
Signed-off-by: Dhaval Sharma <dhaval.v.sharma@intel.com>
Change-Id: I96a9cf3a6e41cae9619c683dca28ad31dcaa2536
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2ec51f15c874ad2f1f4fad52fa8deced7b27a24b
Original-Change-Id: Id62c15799d98bc27b5e558adfa7c7b3468aa153a
Original-Reviewed-on: https://chromium-review.googlesource.com/320855
Original-Commit-Ready: Subrata Banik <subrata.banik@intel.com>
Original-Tested-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13138
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
If coreboot's build process is reproducible (eg. using the latest git
timestamp as source), bl31 is, too.
This requires an arm-trusted-firmware side merge first (in progress) and
an update of our reference commit for the submodule, but it also doesn't
hurt anything because it merely sets a variable that currently goes
unused.
Change-Id: If139538a2fab5b3a70c67f4625aa2596532308f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13497
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
The KGPE-D16 and KCMA-D8 use a Winbond W83667HG-A SuperIO. While
the Nuvoton NCT5572D is effectively the same core, and a close
enough match to get things working initially, the W83667HG-A
has a different LDN mapping and several extra features that
require a separate support driver.
Clone the Nuvoton NCT5572D and modify according to the W83667HG-A
datasheet, version 1.4.
Change-Id: I707ba2e40a22d41cd813003d84a82cb20304f55b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13156
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
Change-Id: I412a0e5f2e0686b10a295dd7c0e9b537dc1a0940
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13154
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
|
