Program MCHBAR, DMIBAR, EPBAR, EDRAMBAR and GDXCBAR.
Also program the PAM registers. The system agent was being
programmed in romstage during pre-console initialization, after
moving to C_ENVIRONMENT bootblock this was missing, restoring
the same.
TEST=Build and Boot Kunimitsu
Change-Id: Iaf310cfb83e58eb8d5affb481dfc343f5d45961b
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16224
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In newer toolchain with binutils 2.26 and GCC 5.3.0, we build binutils
and GCC with machine type riscv32 and riscv64 instead of riscv. We can
see it in this riscv-gnu-toolchain commit:
https://github.com/riscv/riscv-gnu-toolchain/commit/dedbf07
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Signed-off-by: Martin Roth <martinroth@google.com>
Change-Id: Id552859ec256d80108e073d25cd51dd1fc3fbfac
Reviewed-on: https://review.coreboot.org/14257
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since commit 3bfd7cc (drivers/pc80: Rework normal / fallback selector
code) the reboot counter stored in `reboot_bits` isn't reset on a reboot
with `boot_option = 1` any more. Hence, with SKIP_MAX_REBOOT_CNT_CLEAR
enabled, later stages (e.g. payload, OS) have to clear the counter too,
when they want to switch to normal boot. So change the bits to (h)ex
instead of (r)eserved.
To clarify their meaning, rename `reboot_bits` to `reboot_counter`. Also
remove all occurences of the obsolete `last_boot` bit that have sneaked
in again since 24391321 (mainboard: Remove last_boot NVRAM option).
Change-Id: Ib3fc38115ce951b75374e0d1347798b23db7243c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/16157
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
Change the code guard for do_printk_va_list() accordingly, since it's
used by vboot (not Chrome OS) code.
Change-Id: I44e868d2fd8e1368eeda2f10a35d0a2bd7259759
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16230
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
CONFIG_VBOOT was recently moved to be independent from CONFIG_CHROMEOS.
However, the latter still has some 'select' clauses to ensure that
required TPM libraries are built. The TPM is an essential part of vboot,
and without these libraries the vboot code cannot compile... therefore,
they should be moved under CONFIG_VBOOT.
Change-Id: I0145558e5127c65c6a82d62f25b5a39e24cb8726
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16229
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 462e1413 ("rockchip: rk3399: enable sdhci clk
for emmc")
Enabling this clock in coreboot is no longer needed as it's handled
in the kernel driver now.
BUG=chrome-os-partner:52873
TEST=boot from usb/sdcard and check there is /dev/mmcblk0
BRANCH=none
Change-Id: I92cf51f175fe56a09ab9329b29a27c77ef4328e1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5707d1269a253dabf825be120d1f9348ffaab6d0
Original-Change-Id: I8bca870c663d8ce8fac5daaaaf8225489f22ed13
Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/367421
Original-Commit-Ready: Brian Norris <briannorris@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16152
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is a temporary work-around since the current threshold of 70 on
TSR2 results in thermal trip and shutdown while the kernel is
booting. Changing this threshold to 100 allows kernel to boot up to
userspace. Following values were read:
$ cat /sys/class/thermal/thermal_zone4/temp
81800
$ cat /sys/class/thermal/thermal_zone4/type
TSR2
BUG=chrome-os-partner:56155
BRANCH=None
TEST=Boots to OS.
Change-Id: I951553ed4c93b02239a51a0d3036e4a750eea04b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16156
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This reverts commit a83bbf5854.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Instead of assuming all region_devices have an mmap() and munmap()
implementation fail those calls when one isn't provided.
BUG=chrome-os-partner:56151
Change-Id: I9b03e084aa604d52d6b5bab47c0bf99d9fbcd422
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16190
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The SPI host controller for the SPI boot device doesn't allow
normal probing because it uses the hardware sequencer all
the time. Therefore, it's pointless to include unnecessary
SPI flash drivers.
BUG=chrome-os-partner:56151
Change-Id: Ifcc6492b4bccf7d01b121d908976c9087d12deb0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16189
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The SPI host controller for the SPI boot device doesn't allow
normal probing because it uses the hardware sequencer all
the time. Therefore, it's pointless to include unnecessary
SPI flash drivers.
BUG=chrome-os-partner:56151
Change-Id: I04551fdb0b207c7ec2f1f171cff62ed7334a5ad5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16188
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
All flash drivers are automatically included in the build unless
COMMON_CBFS_SPI_WRAPPER was selected. However, there are cases
where these drivers are unnecessary such as certain intel platforms
where spi controller uses hardware sequencing without any ability
to manually probe the device. Therefore, provide an option that the
SoC can set the default value for. The COMMON_CBFS_SPI_WRAPPER
option is still honored by not including all drivers when that
is selected.
BUG=chrome-os-partner:56151
Change-Id: Ie9aa447da450f7c8717545f05cff800139a9e2dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16187
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This option is no longer used in the code base. Remove it.
BUG=chrome-os-partner:56151
Change-Id: Ia73cce7546c9839518c9e931b03c50856abc2018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16186
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The BOOT_MEDIA_SPI_CHIP_SELECT option is not used in any of the
code. Remove its usage.
BUG=chrome-os-partner:56151
Change-Id: I522b62a2371b8a167ce17c48117669390cda14cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16185
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Having an assignment in assert does not make sense. This seems like it
was intended to check if chip is always same as segments->chip.
Change-Id: I297d9e76a0404a1f510d43f8b9c39e96b557689f
Reported-by: Coverity ID 1357439
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16219
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com>
Provide more informative messages when CONFIG_ELOG_DEBUG is enabled
as well as more informative error messages in the case of
elog_scan_flash() failing. In the sync path the in-memory buffer is
dumped in before the contents are read back from the non-volatile
backing store and dumped again if the subsequent parsing fails.
BUG=chrome-os-partner:55932
Change-Id: I716adfb246ef6fbefc0de89cd94b3c1310468896
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16184
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The function name "pmc_tco_regs" is changed to "smbus_tco_regs"
since TCO offsets belongs to SMBUS PCI device.
BUG=none
BRANCH=none
TEST=Built and booted kunimitsu
Change-Id: I4ac26df81a8221329f2b45053dd5243cd02f8ad7
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16155
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
> Overrunning array "am335x_gpio_banks" of 4 4-byte elements at element
> index 4 (byte offset 16) using index "bank" (which evaluates to 4).
As the first index is 0, also error out if the index is equal the array
size.
Change-Id: I6b6b6e010348a58931bd546dfc54f08460e8dbbc
Found-by: Coverity (CID 1354615: Memory - illegal accesses (OVERRUN))
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/16165
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I4af90fd2fcfb2a823f9e6b1e975c71581f0b55e9
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16164
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously, make could be built as one of the crosgcc* targets, but
there was no way to just rebuild make, as there is for IASL.
- Add an independent target - gnumake.
- Add gnumake to the help text.
- Add gnumake to the list of NOCOMPILE targets (Not compiling coreboot)
Change-Id: I4df25f2e209ca14944d491dbfb8e9b085ff7aca3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16163
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a python script that does basically the same thing as the
rebase.sh script, but in the other direction. rebase.sh takes files
from the chromium tree (cros) and pulls them to the coreboot.org tree.
cborg2cros, as the name implies, updates patches to go into the cros
tree from coreboot.
It adds the 'UPSTREAM: ' identifier to the start of the commit message,
and uses the text '(cherry-picked from commit #####)' instead of
'Original-Commit-Id: #####'
It also adds the 'TEST=', 'BRANCH=', and 'BUG=' lines if they aren't
there.
Change-Id: Ibad9a5f0d0d2c713cf08e103c463e2e82768c436
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15323
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch enables the CHROMEOS_RAMOOPS_NON_APCI Kconfig option as a
default across all non-x86 Chrome OS boards.
CQ-DEPEND=CL:367905
BRANCH=None
BUG=None
TEST=See depthcharge CL.
Change-Id: If14ef4f9b1bd480f2d52df3892c73059bb9b07d5
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 8c3b74fb21aadd6de7af62f32fa98fc211d75085
Original-Change-Id: I16ff7f68762a995cd38e5fddaf6971d4b9f07e21
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/368010
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16154
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This reverts commit 850e45f19f.
google_chromeec_init() is a weird function that can lead to confusing
behavior. I'm not sure how it's meant to work on the boards that use it,
but it causes problems on Kevin and other non-x86 boards have never used
it either. It doesn't really do anything anyway (the EC works fine
without an initial HELLO), so at best it's just a waste of time... let's
take it back out.
There's also no need to display the current time on every boot... other
boards don't do that and the eventlog already fills the same purpose.
Cut it out to avoid one extra host command overhead.
BRANCH=None
BUG=chrome-os-partner:55995
TEST=Recovery reasons now get correctly propagated across the EC reboot.
Change-Id: Ic3b772780d4d05e362c269969e6e4e7069482bb6
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 103d86e68cd164bea39aa1edc8668d80358edbde
Original-Change-Id: I58fd5e6094e1c8cb6368e7a4569ab9231375fbc9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/367351
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://review.coreboot.org/16153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
3 out of 4 architectures currently zero out the payload BSS in early
assembly code, which is pointless since the code loading the payload has
already done that (with a more efficient memset). ARM64 has never had
any code like this and can run just fine without it. This also defeats
the new optimization of moving the heap out of the BSS, since all three
implementations assume that everything between _edata and _end is BSS.
We should just take this out.
Change-Id: I45cd2dabd94da43ff0f77e990f11c877cee6cda1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfs_get_handle() allocates memory for a handle and doesn't free it if
it errors out later, leaving the memory permanently leaked. Fix.
Change-Id: Ide198105ce3ad6237672ff152b4490c768909564
Reported-by: Coverity
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16207
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Don't verify HOB list pointer or HOBs when FSP returns a reset request.
BRANCH=none
BUG=chrome-os-partner:56159
TEST=Build and run on Galileo Gen2.
Change-Id: I6382f5ff92092623955806ebff340608c4ee156a
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16162
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP unconditionally locks parts of the NVRAM in the RTC.
This change will enable coreboot to update the locking policy
and be able to unlock the region
BUG=chrome-os-partner:55944
TEST=Check 'crossystem dev_boot_usb=1'
Change-Id: I70fd2bafa6ff9eb9cdf284b9780e4b90dee0f4ce
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/16144
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
3ms delay was found in testing to be sufficient for
qup_i2c_write_fifo_flush(), but 1 additional ms was added to give
additional headroom.
Change the Delay from 10ms to 4ms.
BUG=b:28942403
TEST=Boot up Gale board and the TPM functions normally.
BRANCH=None
Change-Id: I6821e2a101cc44e11d74eb6a6215aa9b848ae8c6
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: d93520fab15c5695ea18db21d0f3b24a108f204d
Original-Change-Id: I202f5b8a1ef62bb039c56ba5a25b48b205cf4a67
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/357961
Original-Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: SARAVANAKUMAR SUDALAI <ssudalai@qti.qualcomm.com>
Reviewed-on: https://review.coreboot.org/16126
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Rockchip RK3399 integrates a USB Type-C PHY in charge of things like
SuperSpeed line muxing for rotated cable orientations in the SoC. While
fancy, this is very complicated and we don't want to implement support
for the whole thing in firmware. The USB Type-C standard has
intentionally been designed in a way that the USB 2.0 (HighSpeed) lines
always "just work" in any orientation (by just shorting different pins
in the connector together) so that simple use cases like ours can get
basic USB functionality without much hassle.
However, a semi-configured Type-C PHY can confuse USB 3.0 capable
devices into thinking we're actually supporting SuperSpeed, and fail at
that rather than establishing a reliable HighSpeed connection. This
patch sets enough bits in the Type-C PHY to electrically isolate the
SuperSpeed lines from the connector so that the connected device isn't
going to get any fancy ideas and reliably falls back to USB 2.0.
Also clean up the rest of the USB code while we're at it: avoid writing
a few bits that are already in the right state from their reset values
anyway, or reading values whose content we already know for this SoC.
Rename the USB controllers to the name actually used in the Rockchip
documentation (USB OTGx) rather than the name blindly copied from
Exynos code (USB DRDx).
BRANCH=None
BUG=chrome-os-partner:54621
TEST=Plug a USB 3.0 Patriot Memory stick into both ports in all
orientations, observe how it gets reliably detected now (safe for some
known hardware issues on my board).
Change-Id: Ifce6bcddd69f2e8f2e2a2f48faf65551e084da1e
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: c526906f998bf66067d3addb8b3d3a126c188b1e
Original-Change-Id: Ie80a201a58764c4d851fe4a5098a5acfc4bcebdf
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/366160
Original-Reviewed-by: liangfeng wu <wulf@rock-chips.com>
Original-Reviewed-by: Shelley Chen <shchen@chromium.org>
Original-Reviewed-by: <515506667@qq.com>
Reviewed-on: https://review.coreboot.org/16125
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In particular:
- Fix the condition of the loop that fills the mid-level page table
- Adhere to the format of sptbr
Change-Id: I575093445edfdf5a8f54b0f8622ff0e89f77ccec
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
I copied it from commit e10d2def7d of spike and made sure the copyright
header is still there.
Change-Id: Ie8b56cd2f4855b97d36a112a195866f4ff0feec5
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15832
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add GPIOs initialisation before dock check.
Needed in order to properly detect the presence or absence of the lenovo
dock.
Previously the check always reported the dock as connected and currently
it always reports it as disconnected since the GPIOs are not properly
initialised during the check.
Tested and confirmed working.
Change-Id: I7fbf8c2262a1eb5dee9cbe5e23bf44f7f8181009
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16139
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add FSP 2.0 header files, these files are common for Skylake
and Kabylake, name the folder as skykabylake to signify the same.
Change-Id: I71b43a59c9a9b0adf1ee48285e4a72e24a13df2d
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16050
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
That's more useful than just COREBOOT for more complex scenarios
Change-Id: I93cd686d698799a3331ca2ea487cd6efb304caa0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16143
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It was a band-aid that isn't required any more.
Change-Id: Ib1793ae8fe25eecf9bd5ab8e5feef0d9380b43c2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16142
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It cooperates better with the file sorting heuristic.
Change-Id: I1c071243720352970dd2c4c2afed12451f91dcaa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16141
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To override fallback/foo's position or alignment in region BAR, use
fallback/foo-BAR-{position,align} = 0x1234
Like for the global settings, specifying both isn't allowed
because that's rather pointless.
Change-Id: I94f41ebc9f35108267265df4164f23b70e3d0bf6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16140
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They're now sorted later in the process after the per-region file lists
are determined.
Change-Id: I0bba381d09dc4b99e2fe5cae16ff7ffcb5b3aa82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16138
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Make sure that files with a fixed position are placed first (whose order
doesn't matter: either they collide or they don't), then all aligned
files (where we just hope that the right thing happens) and finally the
files with no further requirements (again, hope).
It's still a pretty good heuristic given a typical coreboot image.
The global sorting that happens earlier in the build flow will be
removed in the future to make room for per-region requirements.
Change-Id: I269c00b2ece262c95d310b76a6651c9574badb58
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16137
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rizwan Qureshi