This allows for serial console during the bootblock and enables
bootblock console by default.
Change-Id: I7746e4f819486d6142c96bc4c7480076fbfdfbde
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Previously broadwell used a romcc bootblock and starting verstage in
romstage was madatory but with C_ENVIRONMENT_BOOTBLOCK it is also
possible to have a separate verstage.
This selects using a separate verstage by default but still keeps the
option around to use verstage in romstage.
With a separate verstage the romstage becomes an RW stage.
The mrc.bin however is only added to the RO COREBOOT fmap region as it
requires to be run at a specific offset. This means that coreboot will
have to jump from a RW region to the RO region for that binary and
back to that RW region after that binary is done initializing the
memory.
Change-Id: I900233cadb3c76da329fb98f93917570e633365f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30384
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This puts the cache-as-ram init in the bootblock.
Before setting up cache as ram the microcode updates are applied.
This removes the possibility for a normal/fallback setup although
implementing this should be quite easy.
Setting up LPC in the bootblock to output console on SuperIOs is not
done in this patch, therefore BOOTBLOCK_CONSOLE is not yet selected.
Change-Id: I44eb6d380dea5b82e3f009a46381a0f611bb7935
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The only functional difference is the use of stack guards.
Change-Id: I95645271e0d93a97f544a1cc4e9a4320738e6a20
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Free several resources when AHCI initialization fails. Note that it is
only safe to free resources when the command engine has stopped, since
otherwise they may still be used for DMA.
Found-by: Coverity CID 1260719, 1260727, 1261090, 1261098
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I6826d79338b26ff9696ab6ac9eb4c59f734687d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
As of CL:1605641, vboot2 code should be used for setting and
checking display init state. Remove all vboot1 OPROM-related
code, and use the vboot2 display init code which has already
been added in previous commits.
coreboot should not be reading vboot NVRAM flags directly.
Remove the function vboot_wants_oprom(), and instead rely on
display_init_required(), which uses the
VBOOT_WD_FLAG_DISPLAY_INIT value stored in
vboot_working_data.flags, initialized during verstage.
Note that this means in the case of CONFIG_VBOOT=y, the return
value of display_init_required() can only be trusted after
verstage has been executed. This should not be a problem
assuming that all display initialization occurs in ramstage.
BUG=b:124141368, b:124192753, chromium:948529
TEST=Build locally
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: Ic8f9dc5a3c7f1546a8fed82bde02be4d04568f8d
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1605641, chromium:1605525
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32723
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Verified Boot OPROM code is being refactored. OPROM is being
generalized into "display initialization". As such, the NVRAM
request flag is being renamed from OPROM_NEEDED to
DISPLAY_REQUEST.
BUG=b:124141368, b:124192753, chromium:948529
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I74374abf7d1deb594c073f7a4a76c9de46092143
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1605640
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Based on IT8786E-I V0.4.1 datasheet with following remark:
"Please note that the IT8786E-I V0.4.1 is
applicable only to the D version."
Signed-off-by: Kyösti Mälkki <kyosti.malkki@3mdeb.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Change-Id: I7317da6a72db64f95f9a790ef96ed7a5f93b3aea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30335
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
If username is not set, then the ssh option is not available.
This was initially confusing for me.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I731c29a1daa9f8c298710471c7d1fe758b059d08
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32540
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao <lance.zhao@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
We need to support entering D3Cold from the OS to work around a bug in
the SDHC where the data lines get stuck always reading zeros.
BUG=b:122749418
TEST=Verified the linux kernel can transition between D3 and D0. Also
verified that the device can suspend and resume and continue to have a
functioning SD controller after.
Change-Id: Ifbf48f20c03a752ce3ff773296b536e92db16a62
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This patch adds a workaround for Samsung C-die 2G/4G memory chips.
For unknown reasons, some boards with Samsung LP3 memory chips
could not pass early CS/CMD training. MRC has to change the
granularity from 16 ticks to 8 ticks, which implies bad margin
with this memory chip. Another way is to enhance the drive
strength for CS. This patch is to enhance the drive strength for CS
and CMD. Enhancing the drive strength for CMD could gain margin abaout
3 more ticks. Root cause needs to be further investigated with memory
vendor.
BUG=b:131177542
BRANCH=None
TEST=USE=fw_debug emerge-atlas chromeos-mrc coreboot chromeos-bootimage
& check the MRC log to ensure correct Rcomp values are passed to
MRC. Tested with board ID #8 and #11.
Change-Id: I9ea3ceda8dc8bf781063d3c16c7c2d9b44e5ddd6
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32695
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
Call the raminit from a common location instead of from the mainboard
specific code.
Change-Id: I65d522237a0bb7b2c032536ede10e2cf93c134d8
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32760
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To improve the bootflow, the scope of the pei_data needs to be
extended.
Change-Id: Ic6d91692a7bf9218b81da5bb36b5b26dabac454e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32762
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This also links the gpio configuration instead of including it as a
header.
Change-Id: I9309d2b842495f6cff33fdab18aa139a82c1959c
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This reverts commit 99e836c843.
This relands commit c4ab50cdde.
The issues with -Wtype-limits in the vboot submodule have been resolved
now, so we can enable this flag again.
Change-Id: I32e8cc88e69072e7ee66cf443b578a9a8ea0ebe2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32749
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
This patch uprevs the vboot submodule to the new upstream HEAD commit
dac763c782 Make vboot -Wtype-limits compliant
Change-Id: I363e218e019b25483bc4c06315ca4e0e34599daf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Move boot_count_increment() to romstage.c, drop preprocessor code and
only increase counter once on regular boot.
Tested on Lenovo T520 (Intel Sandy Bridge).
Still boots to OS, no errors visible in dmesg.
Change-Id: I6aa52b75edf19953405b70284c7e7db30f607cd6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32067
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add more chip register to move PEI data to devicetree.cb.
* Set northbridge/southbridge and runtime detectable settings.
* Fill in values from devicetree.
This change is still a noop as the pei structure is completely overwritten
with the exsting mainboard pei structure.
The followup commit will migrate to devicetree.cb.
Tested on Lenovo T520, boots MRC path with the new devicetree settings.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Change-Id: Ic6d9f0fd6a2b792ac693d6016ed9ce44945c900c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Move the onboard SPD to second channel as native raminit does and workaround
mrc expecations in northbridge code.
Required to move pei data to devicetree and to use the same code for mrc and
native raminit.
Tested on Lenovo T520:
Other fields then spd_data[0] are ignored.
Change-Id: If1910e82a4bd178c2a6c2991c91e09782122888e
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32682
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The GPIO invert registers are already defined in the PCH code, so
just use the 8-bit versions of the registers instead of creating
a new GPIO field for the single bits.
This allows us to get rid of the Field(GPIO...) code that's causing
problems with IASL version 20190509.
Signed-off-by: Martin Roth <martinroth@chromium.org>
Change-Id: Iac5dfb71b3a2b5a25c05a403cf5f403c7acecaaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32753
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Ctrl-delete does nothing, so it falls through to the default case.
Add a comment to make this explicit.
Found-by: Coverity Scan #1260878
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I4a6f51cb04696b6ebcb554c5667a5bbea58622c1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32750
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
At least one channel must be present, so print an error if there is
not. However, we cannot always assume it will be the first channel,
so make the appropriate selection when printing the timings.
Found-by: Coverity Scan #1370{584,585,588,589,590-596,600}
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I6b59989242e498474782876302e0850e3e4cf2d3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
The gpio table is only used by depthcharge, and depthcharge rarely
has a need for the "recovery" gpio. On a few boards it does use the
gpio as a signal for confirming physical presence, so on that boards
we'll advertise the board as "presence".
All these strings probably should have been #defines to help avoid
typos (e.g., the "ec_in_rw" in stout seems questionable since everybody
else uses "EC in RW").
Cq-Depend: chromium:1580454
BUG=b:129471321
BRANCH=None
TEST=Local compile and flash (with corresponding changes to depthcharge)
to 2 systems, one with a "presence" gpio and another without. Confirmed
that both systems could enter dev mode.
Change-Id: Id6d62d9e48d3e6646cbc1277ea53f0ca95dd849e
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32718
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Depthcharge uses the keyboard type to help determine whether
it can trust the keyboard for security-sensitive confirmations.
Currently it trusts anything except usb, but now there's a need
to distrust ec-based ps/2 keyboards that are associated with untrusted
ECs. To help facilitate this, coreboot needs to report more
details about non-usb keyboards, so this change replaces the current
instances of unknown with enum values that distinguish uart and gpio
from ec-based keyboards.
BUG=b:129471321
BRANCH=None
TEST=Local compile and flash to systems with trusted and non-trusted
ECs. Confirmed that security confirmation can't be performed via
keyboard on a system with an untrusted EC but can still be performed
on a system with a trusted EC.
Change-Id: Iee6295dafadf7cb3da98b62f43b0e184b2b69b1e
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
A12 is not current set for ISH_GP6 so the ISH_LID_CL#_TAB
signal is not making it to the ISH properly. Enable the second native
function instead of the first.
BRANCH=none
BUG=b:131785573
TEST=gpioget on ISH now shows the correct gpio level
Change-Id: Ib3a654ae659037263aa9aa29d45b42ca67b7955b
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32738
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
'name' and 'env' are supposed to be file system paths,
but could overflow the buffer if configured incorrectly.
Let's avoid that entirely.
Found-by: Coverity Scan #1362515
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I1aef36819d49ebcbde1c51995dc0961c85e74150
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32686
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Systems with C_EVIRONMENT_BOOTBLOCK and VBOOT enabled requires functions
tsc_freq_mhz(), vbnv_cmos_failed() and vboot_platform_is_resuming()
in verstage.
Add tsc_freq.c and pmutil.c to verstage.
BUG=NA
TEST=Booting Embedded Linux on Facebook FBG-1701 + Building Google Banon
Change-Id: Ia509eda6bf415aaa63be71013249493aa472289d
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32733
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
It is possible that 'malloc_fo_sub' and 'remalloc_fo' can
fail, so add appropriate error checks for those cases.
This incidentally fixes a possible memory leak when
'malloc_fo_sub' succeeds but 'remalloc_fo' does not.
Found-by: Coverity Scan #1396050
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Change-Id: I944b67f5cdcfd7a687e81d8bb01a209c9dc9b0b8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32696
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Elyes HAOUAS