Reset pin of USB Hub is connected to GPIO118, it is low active.
Config GPIO118 as GPO and output high.
BRANCH=none
BUG=none
TEST=emerge-oak coreboot
Change-Id: I630cfd1c1019447736e7e5b286790fead4bdcfb6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b4b5cd98d0b3c5d2bab408ecebebc924d1f2b7df
Original-Change-Id: I1ea0e1baac3da4d13301307f01bbe51e108298dd
Original-Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/321054
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13976
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Oak introduces a 1.8V to 3.3V level shifter for EC SPI bus after rev5.
BRANCH=none
BUG=none
TEST=emerge-oak coreboot
Change-Id: I71868b003fc71dee0532033299afc155a9fbec9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 030b478fedf046a7b818696779299c591415fcbd
Original-Change-Id: Ibff9705832700867279cb1b39b752b8f5f27cf33
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/320026
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13970
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=build pass and boot to oak kernel
Change-Id: Id2c3bbb70a1de54a56ee04ecda76178b1bdf1a4d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8641689e008c58e909606c225dddb81dc6457ae9
Original-Change-Id: I96ef8a36bc70594097e9df964934b7e3eca5d5f9
Original-Signed-off-by: jun.gao <jun.gao@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/319031
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=boot to shell on Rev3
Change-Id: Ifca80705e392ce171ef33bf98ef787e3cd5ffd6b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7d511df7f527ae96c2da01804c62fe98a13fed56
Original-Change-Id: I68ab8be50f210fa17bd731b400a087b150566e3b
Original-Signed-off-by: CC Ma <cc.ma@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303207
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13104
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We define a mechanism to pass board specific parameters to BL31. The
idea is BL31 doesn't need to have the board revision knowledge, it
only needs to process the board specific parameters to initialize and
control specific hardware. In this way, we can support different boards
with same BL31 binary.
BRANCH=none
BUG=none
TEST=booted on oak-rev2 and oak-rev3 boards, and confirmed they got
different board arguments in ARM TF
Change-Id: I0df2c6d7d1ffac7d443511c3317c142efeb5701e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f9a4a2776110c5ddc113f0d605d4337d5773ace
Original-Change-Id: I985d9555238f5ac5385e126479140b772b36bac8
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292678
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13101
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We define a mechanism to pass board specific parameters to BL31. The
idea is BL31 doesn't need to have the board revision knowledge, it
only needs to process the board specific parameters to initialize and
control specific hardware. In this way, we can support different boards
with same BL31 binary.
[pg: add the code, but don't actually enable the support yet, because it
relies on code that still needs to be merged to arm-trusted-firmware.]
BRANCH=none
BUG=none
TEST=booted on oak-rev2 and oak-rev3 boards, and confirmed they got
different board arguments in ARM TF
Change-Id: I9ea3ce6c8f79dd427be67f30bc940d2038173b81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f9a4a2776110c5ddc113f0d605d4337d5773ace
Original-Change-Id: I985d9555238f5ac5385e126479140b772b36bac8
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292678
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13100
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=build pass and boot to oak kernel
Change-Id: I8aa9ca0fce804cc1682947b7e184781dd5d437f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8641689e008c58e909606c225dddb81dc6457ae9
Original-Change-Id: I96ef8a36bc70594097e9df964934b7e3eca5d5f9
Original-Signed-off-by: jun.gao <jun.gao@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/319031
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=none
TEST=emerge-oak coreboot
BRANCH=none
Change-Id: I3ed8bad1bdc7d17e334e0136f92a51c8e7ba4e67
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b614eeb1bba5660438c214e82225832809caca8e
Original-Change-Id: I0f7b0a426dae1548b34114a024c92befdf6002f6
Original-Signed-off-by: Peter Kao <peter.kao@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292692
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13106
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=none
TEST=emerge-oak coreboot
BRANCH=none
Change-Id: I6b05898de2d0022e0de7b18f1db3c3e9c06d8135
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b614eeb1bba5660438c214e82225832809caca8e
Original-Change-Id: I0f7b0a426dae1548b34114a024c92befdf6002f6
Original-Signed-off-by: Peter Kao <peter.kao@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292692
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13105
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=boot to shell on Rev3
Change-Id: I77c5a8aa31ab10d82115a60bdfee1da35707619f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7d511df7f527ae96c2da01804c62fe98a13fed56
Original-Change-Id: I68ab8be50f210fa17bd731b400a087b150566e3b
Original-Signed-off-by: CC Ma <cc.ma@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/303207
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13103
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=boot oak to kernel on rev1
Change-Id: I0773c81398df445aec16bcfcd0c5a8fe5a588b5c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ae15c42c2f7d9c2a716e5b6098d85e17279f5eae
Original-Change-Id: I65abf810d35ae5e7156cf6f5730117e690183d18
Original-Signed-off-by: mtk05962 <bayi.cheng@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/292693
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13102
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The sourcecode is 99% the same. Only two lines differ, but not
in functionality.
Also rename mrccache.c -> mrc_cache.c
Tested-on: boot + suspend/resume on x220
Change-Id: I36f79d066336f223b608c70c847ea6ea6e4ad287
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14007
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The mrc_cache definition and the struct mrc_container are the same
over all intel platforms.
Change-Id: I128a4b5693d27ead709325c597ffe68a0cc78bab
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/13998
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The SST25VF064C doesn't support the auto incrementing write which
all other supported SST chips support. Allow the chips to select
their write method.
Change-Id: Ic088d35461a625469ee6973d1267d7dd11963496
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14000
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing MCT code proceeded to the next DRAM training phase if
the minimum lane quality standard passed for either the read or
write direction. Ensure that both pass for a given set of delay
values before proceeding to the next training phase.
Change-Id: I2316ca639f58a23cf64bea56290e9422e02edf1c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13993
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
The AMD Family 15h BKDG rev. 3.14 indicates that the maximum read latency
must be calculated prior to DQS position training, however the read
latency calculations use read DQS delay values that have not been
set prior to DQS position training.
Set the read DQS delay values to 1UI (i.e worst case) before calculating
the read latency prior to DQS position training.
Change-Id: I6ae88c891e92b21dc0ca3c47b8f3d269f83b3204
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13995
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>
A couple of arrays were not properly initialized. This
did not appear to affect operation of the codebase however
it led to some ugly values being displayed when debugging
was turned on.
Also bounds check an array index; as before this did not
appear to affect operation but was a potential point of
failure.
Change-Id: I243b7197a74aed78ddca808eb3b0f35f1fe9d95a
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/13934
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of having to supply CAR memory region during compilation
time it is possible to determine it in runtime. FSP2.0 blobs carry
a copy of UPD structure pre-populated with 'default' values. The
default value for StackSize is actually the real value blob needs.
Change-Id: I298e07bb12470ce659f63846ab096189138e594f
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14001
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Different DIMM modules give different SMBIOS type 17 lengths, so we
can't use `meminfo->dimm_cnt*len' for entry struct size, otherwise
it'll give a wrong SMBIOS size when two or more different DIMMs are
installed on the machine.
Change-Id: I0e33853f6aa4b30da547eb433839a397d451a8cf
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/14008
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Instead of just defaulting to disabled, remove the option for
x86 since it doesn't work there.
Change-Id: I2b84b9f866f9231943e573b873c970f420c7c9a5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14017
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Change 13363 (555d6c2) introduced a bug where cbmem_add_bootmem() was
converted to use a new function. Unfortunately instead of passing a
pointer, NULL was passed due to type confusion. This change fixes that
problem by passing address of stack variable instead of NULL.
Change-Id: Ib8e1add3547cda01f71bf1dea14d3e58bdd99730
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/14033
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Commit 71512b2c (northbridge/i945/gma: fix build error with native graphics init)
unintentionally changed the code to ignore the NVRAM setting
`tft_brightness`. Revert that hunk to restore the original behavior.
Change-Id: Iffdfc5272732bad3476f35ddac1f5a7564270531
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/14002
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This adds most important MMIO reserved memory resources,
real DRAM memory resources, and some DRAM resources that
can not be used as RAM for whatever reason.
Change-Id: Id5a80cf18d67ace991e8046fa46c4b7ed47c626a
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13360
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
UART bar gets overwritten during resource allocation stage. As result
the serial driver ends up using stale BAR so serial output does not
work. This driver simply tells resource allocator not to change BAR
of UART device.
Change-Id: I81f4f04089106c80bea97f0bbaba890df00c8ac5
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13997
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This is the minimal setup needed to get all CPU cores enabled. That
includes sending an IPI to APs and setting up MTRRs. Microcode updates
are not performed for two reasons:
* CSE (Converged Security Engine) upgrades the microcode before
releasing reset
* Microcode update files are not available at this point in time
Change-Id: Ia1115983696b0906fb4cefcbe1bbe4fc100751ca
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13910
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On platforms that didn't use 32-bit addresses, enabling the
CONFIG_TRACE option (Trace function calls) would break the build due
to a cast from a pointer of a different size.
This fixes this warning:
src/lib/trace.c:29:58: error: cast from pointer to integer of different
size [-Werror=pointer-to-int-cast]
Change-Id: Iaab13c1891b6af7559ea6982ecc6e74c09dd0395
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13962
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Use UDELAY_IO selected by CPU_VIA_C7, so no manual inclusion
(or secondary UDELAY implementation) is needed
Change-Id: Ib086a1bfe8ffca5757bf553c5a62a45da7a410b6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13782
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of manually including udelay_io.c in each romstage,
select UDELAY_IO for all i440BX boards in the chipset.
Change-Id: I411191927f3fba1d0749edcf79378e8013fb195a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13781
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add a port of Auron_Paine based on upstream Auron and the Auron_Paine
code originally from commit bd61dfd in Google branch
firmware-paine-6301.58.B .
Change-Id: I3a1faec3195a81bb3a6496b8bd610fc8a89e66aa
Signed-off-by: Georg Wicherski <gwicherski@gmail.com>
Reviewed-on: https://review.coreboot.org/11907
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Pass memory training information to MemoryInit, so memory
training can be completed.
Change-Id: Icb1bf308b77a1c8481313c259c3f3dd1d8379863
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/13870
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to
statically allocate the different memory regions it needs and guarantees
at build time that there are no dangerous overlaps between them. At the
end of its (ramstage) execution, however, it usually loads a payload
(and possibly other platform-specific components) that is not integrated
into the coreboot build system and therefore cannot provide the same
overlap guarantees through memlayout.ld. This creates a dangerous memory
hazard where a new component could be loaded over memory areas that are
still in use by the code-loading ramstage and lead to arbitrary memory
corruption bugs.
This patch fills this gap in our build-time correctness guarantees by
adding the necessary checks as a new intermediate Makefile target on
route to assembling the final image. It will parse the memory footprint
information of the payload (and other platform-specific post-ramstage
components) from CBFS and compare it to a list of memory areas known to
be still in use during late ramstage, generating a build failure in case
of a possible hazard.
BUG=chrome-os-partner:48008
TEST=Built Oak while moving critical regions in the way of BL31 or the
payload, observing the desired build-time errors. Built Nyan, Jerry and
Falco without issues for good measure.
Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13949
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is a step towards isolating the timer drivers.
Change-Id: I4c9349054be0cf520cd4407be9fb393b664223a4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13922
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There's no need to use a struct resource type for
fsp_find_reserved_memory(). struct resource is mainly associated
with a device and that memory is added to cbmem after memory init.
Other uses ins FSP 2.0 just use struct range_entry. Use that
instead for consistency.
Change-Id: Id7d39da1c2e23f97cdaafd7f5d281cefa6fee543
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13960
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
The FSP 2.0 implementation doesn't handle FSP modules for
SoCs that are required to be XIP. There is no notion of
"loading" in that situation where one should be copying
anything anywhere.
Additionally, the loading code does not handle overlaps within
the current running program which is doing the loading.
Change-Id: Ide145581f1dd84efb73a28ae51b3313183fa127a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13959
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
