This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Checksum is calculated by using 2s complement method. 8-bit sum of the
entire subpart directory from first byte of header to last byte of last
partition directory entry.
BUG=chrome-os-partner:53508
Change-Id: I991d79dfdb5331ab732bf0d71cf8223d63426fa8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15200
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that the flash size is increased to 16MiB, add RW_NVRAM and
RW_LEGACY sections to chromeos.fmd file.
BUG=chrome-os-partner:54390
Change-Id: I6c79d35295c4bc774f05f8045ac920474d7a791f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15192
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Migrate google/rikku (Acer Chromebox CXI2) from Chromium tree to
upstream, using google/guado as a baseline.
original source:
branch firmware-rikku-6301.110.B
commit 2e71207 [CHERRY-PICK: broadwell: Update to microcode 0x1F]
TEST=built and booted Linux on rikku with full functionality
blobs required for working image:
VGA BIOS (vgabios.bin)
firmware descriptor (ifd.bin)
Intel ME firmware (me.bin)
MRC (mrc.bin)
external reference code (refcode.elf)
Change-Id: Iba618a0b2cf2d613f6429b3e7606e0b47fa97a4d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/12802
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
CBMEM console stores all the console logs in CBMEM. Address of this
location in CBMEM where console logs are stored needs to be passed up to
OS using GNVS.
1. Add CBMC to GNVS fields in globalnvs.asl
2. Add cbmc member to global_nvs_t structure in nvs.h
3. Initialize gnvs->cbmc to address of cbmem console
BUG=chrome-os-partner:54342
Change-Id: Idcd4573e626fa433c1623bdcbe29921de64539b2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15177
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
FSP methods may require reset under certain conditions. That is indicated
by returning specific return code. Add the missing return status codes.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: I460353c5f835548a98255bd3e11dbfd08260ea52
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15185
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Update EMMC DLL setting for reef board, after that system can
boot up into EMMC successfully.
BUG=chrome-os-partner:54228
TEST=Boot up into EMMC and check with Rootdev
Change-Id: I614cd624dce9069c5565599a955f87906bcea53b
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/15156
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add a bootblock which builds with C_ENVIRONMENT_BOOTBLOCK selected.
This is the first piece in supporting FSP 2.0. Move esraminit from
romstage into the bootblock. Replace cache_as_ram with
car_stage_entry.S and code in romstage.c
TEST=Build and run on Galileo Gen2
Change-Id: I14d2af2adb6e75d4bff1ebfb863196df04d07daf
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15132
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable uses of a common bootblock_pre_c_entry routine. Pass in TSC
value as a uint64_t value.
TEST=Build for amenia and Galileo Gen2
Change-Id: I8be2e079ababb2cf1f9b7e6293f93e7c778761a1
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15124
Tested-by: build bot (Jenkins)
Reviewed-by: Lee Leahy <lpleahyjr@gmail.com>
If a bridge has the primary bus equal to the secondary bus the
busmaster_disable_on_bus() will infinitely call itself. Avoid the
inifinite recursion by checking current bus number against the
secondary bus number.
BUG=chrome-os-partner:54262
TEST=Ran on reef. Able to actually get the chipset to assert SLP_Sx
signals which means no more infinite recursion.
Change-Id: I52b21fbba24e6a652ea8f9f87f5f49f60109c8f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15157
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Like other boards there will likely be information needed from
GNVS in the SMM handler. Therefore, it's important that the point
is stashed accordingly.
BUG=chrome-os-partner:54275
TEST=Noted GNVS messages from SMM console on reef.
Change-Id: If12b69731330a1e0af7f8fe880635e5ffd02d715
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15152
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The UART support is needed in SMM in order for DEBUG_SMI to
function.
BUG=chrome-os-partner:54262
TEST=Ran on reef with DEBUG_SMI enabled. Can observed SMI messages.
Change-Id: Ibd6b12e27d5776046b400adf72f24133b9e54af8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15151
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
It appears that PM1 is not wired up to the SMI status register, but
it does definitely cause SMIs to trigger. Therefore, provide a fake
PM1 status bit by checking the power button status when SMI status
is indicating no status as well as the PM1 control indicating that
SCI mode is not enabled.
BUG=chrome-os-partner:54262
TEST=Smashed power button on reef to cause SMI in firmware. No longer
loops infinitely with constant SMIs firing.
Change-Id: I9aa1b5f79b651cbc19a2d3353d9ef65429386889
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15155
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Provide the bit definitions for the SMI status register. Also,
utilize them which means deleting some of the handlers that can't
exist because there are no status bits.
BUG=chrome-os-partner:54262
Change-Id: I389c7cb3cad01ba0eca52a337ffee352a2010bfa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15154
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Instead of hardcoding the PCI mmio size read it from devicetree.
Set a default value of 2048 MiB and 1024MiB for laptops without
discrete graphics.
Tested on Sandybridge Lenovo T520.
Change-Id: I791ebd6897c5ba4e2e18bd307d320568b1378a13
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15140
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. The checksum method that was documented is not correct. So, no use
filling in a value based on wrong calculations. This can be added back
once updated information is available.
2. Checksum does not seem to affect the booting up of SoC. So, fill in 0
for now.
Change-Id: I0e49ac8e0e04abb6d7c9be70323612bdef309975
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15145
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Update pack and header order and mark the entries as mandatory and
recommended w.r.t. ordering (mandatory = essential for booting,
recommended = okay to change, but this config is tested and known to work).
Change-Id: Ia089bdaa0703de830bb9553130caf91a3665d2c4
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15144
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Since the HTIF is a non-standard interface, and coreboot already has a
8250 driver, I started implementing an 8250 core for spike[1].
[1]: https://github.com/riscv/riscv-isa-sim/pull/53
Change-Id: I84adc1169474baa8cc5837358a8ad3d184cfa51b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15150
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the default (medlow) code model, pointers are loaded with a lui, addi
instruction sequence:
lui a0, 0xNNNNN
addi a0, a0, 0xNNN
Since lui sign-extends bits 32-63 from bit 31 on RV64, lui/addi can't
load pointers just above 0x80000000, where RISC-V's RAM now lives.
The medany code model gets around this restriction by loading pointers
trough auipc and addi:
auipc a0, 0xNNNNN
addi a0, a0, 0xNNN
This way, any pointer within the current pc ±2G can be loaded, which is
by far sufficient for coreboot.
Change-Id: I77350d9218a687284c1337d987765553cf915a22
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The uart8250mem driver needs it.
Change-Id: I09e6a17cedf8a4045f008f5a0d225055d745e8db
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Due to USB LDO issue in current steppings, cold reboot needs to be
temporarily disabled. Thus, hard_reset call should be the same as
soft_reset.
Once future steppings are available INTEL_COMMON_RESET can be enabled again.
Change-Id: If0ec56db3864d500acc93d2b363a78a6cd7632da
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15143
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Update the Galileo board implementation checklist.
TEST=Build and run on Galileo Gen2
Change-Id: I1c88e9500d304273a3176d8b034a805920aab9bb
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15137
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Remove code duplication and use the common function
store_current_mrc_cache instead.
No functionality is changed.
Tested on Sandybridge Lenovo T520.
Change-Id: I4aa5463f1b1d5e1afbe44b4bfc659524d86204db
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15074
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Sometimes we need to pass board specific messages to BL31,
so that BL31 can do board specific operation based on
common code.
BRANCH=None
BUG=chrome-os-partner:51924
TEST=Build gru
Change-Id: I096878699c6e6933debdf2fb3423734f538691ae
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: af83e1b
Original-Change-Id: Ib7585ce7d3bf01d3ce53b388bf9bd60f3b65f5f1
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349700
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15116
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
All current Oak boards have PD chips with update speeds that range from
slow (Oak) to "OMG it's so awfully slow I could make a cup of coffee and
it would still not be done" (Elm). Set the flag that enables the "Your
system is applying a critical update. Please don't turn it off." message
on EC software sync so that our users don't accidentally carry it back
to the store and demand a refund while it's still not done booting.
BRANCH=None
BUG=chrome-os-partner:51145
TEST=Booted Oak in normal mode with a new EC-RW image. Confirmed that I
saw the magic screen.
Change-Id: I000eab36d26b61b25d1f0da505f02ced15457255
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 274644b
Original-Change-Id: I64ba698985d5fbcf2b94115df72b70a5319106ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/348787
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15114
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The VBOOT_OPROM_MATTERS configuration option signals to vboot that the
board can skip display initialization in the normal boot path. It's name
is a left-over from a time when this could only happen by avoiding
loading the VGA option ROM on x86 devices. Now we have other
boards that can skip their native display initialization paths too, and
the effect to vboot is the same. (Really, we should rename oprom_matters
and oprom_loaded to display_skippable and display_initialized or
something, but I don't think that's worth the amount of repositories
this would need to touch.)
The only effect this still has in today's vboot is to reboot and
explicitly request display initialization for EC software sync on
VBOOT_EC_SLOW_UPDATE devices (which we haven't had yet on ARM). Still,
the vboot flag just declares the capability (for skipping display init),
and it should be set correctly regardless of whether that actually makes
a difference on a given platform (right now). This patch updates all
boards/SoCs that have a conditional path based on
display_init_required() accordingly.
BRANCH=None
BUG=chrome-os-partner:51145
TEST=Booted Oak, confirmed that there's no notable boot time impact.
Change-Id: Ic7c77dbd8356d67af7aee54e7869f9ac35241b99
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9c242f7
Original-Change-Id: I75e5cdda2ba2d111ea50ed2c7cdf94322679f1cd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/348786
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch adds code to initialize the two DWC3 USB
host controllers, and uses them to initialize USB3.0
on the gru rk3399 board.
BRANCH=none
BUG=chrome-os-partner:52684
TEST=boot from USB3.0 on gru/kevin rk3399 platform
Change-Id: If6a6e56f3a7c7ce8e8b098634cfc2f250a91810d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0306a9e
Original-Change-Id: I796fa1133510876f75873d134ea752e1b52e40a8
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/347524
Original-Commit-Ready: Brian Norris <briannorris@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15112
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
1. Make the xHCI driver to support xHCI controller v1.1
2. And a new function xhci_ring_doorbell(), it aims to
add a memory barrier before ringing the doorbell, to ensure
all TRB changes are written to memory.
BRANCH=none
BUG=chrome-os-partner:52684
TEST=boot from USB on Kevin rk3399 platform
Change-Id: Ife1070d1265476d0f5b88e2acf3299fc84af5832
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0c21e92
Original-Change-Id: I4e38e04dc3c7d32ee4bb424a473c70956a3c3ea9
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/346831
Original-Commit-Ready: Brian Norris <briannorris@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15111
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Not all x86 architectures support the mm register set. The default
routine that saves BIST in mm0 and a "weak" routine that saves the TSC
value in mm2:mm1. Select the Kconfig value
BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to
save the BIST and timestamp values.
TEST=Build and run on Amenia and Galileo Gen2.
Change-Id: I8119e74664ac3522c011767d424d441cd62545ce
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15126
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Initialize the GPIOs during the boot block to properly route the SOC
UART pins.
TEST=Build and run on Galileo Gen2
Change-Id: I22c24f8c83f04566a0bbd598a141a5209569a924
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15133
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use Kconfig values to enable debug spinloops in assembly_entry.S. This
makes it easy to debug the assembly code.
TEST=Build and run on Galileo Gen2
Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Conditionally add a debug spinloop to enable easy connection of JTAG
debuggers.
TEST=Build and run on Galileo Gen2 with a JTAG debugger.
Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 5ede3d8cce.
No longer needed due to FSP being updated, with the 139_40 release,
to accept StackBase field
BUG=chrome-os-partner:52784
BRANCH=none
TEST=built and booted with FSP 139_40
Change-Id: Ic832d8dc4ca87631f5fef80d4d41558d9a72630a
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/15068
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
FSP 2.0 spec has updated the signatures for the FSPM and FSPS blobs
with the 139_40 release. In order to successfully pass through
memory/silicon init the header files must be updated to the latest
versions
BUG=chrome-os-partner:52784
BRANCH=none
TEST=built and booted
Change-Id: Ib60d0d9afa4ee29dff26177826ba59db81b630e8
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/15066
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Scan the boot block when building it with C_ENVIRONMENT_BOOTBLOCK
selected.
TEST=Build and run with Galileo Gen2
Change-Id: I922f761c31e95efde0975d8572c47084b91b2879
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15130
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add car_stage_entry as an optional routine in the checklist.
TEST=Build and run on Galileo Gen2
Change-Id: I52f6aefc2566beac01373dbebf3a43d35032a0df
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15129
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Support ROM_SIZE greater than 16 MiB. Work around SMBIOS rom size
limitation of 16 MiB by specifying 16 MiB as the ROM size.
TEST=Build and run on neoncity
Change-Id: I3f464599cd8a1b6482db8b9deab03126c8b92128
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15108
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Kyösti Mälkki