The DRAM size can not be determined before DRAM is initialized. Since
mt8173 only support 2GB and 4GB DRAM models. We map 0x0 to the end of
2GB DRAM address before DRAM is initialized.
BRANCH=none
BUG=none
TEST=boot to kernel
Change-Id: I27a00106b0aa91c3dacfcd2bcd9208f08b108dc5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9720e67c86f0d37a08f7c32e900996c75d60288a
Original-Change-Id: I87d9c6ac11486decde102b7821f550c2f1a51f1c
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/327960
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/331175
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13987
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Runs the LITTLE core at highest freqency to speed up the boot time.
Set Vproc to 1.125V and set the freqency to 1.6Ghz for backward
compatibility. (The highest frequency for the IC before E3 is 1.6Ghz.)
BRANCH=none
BUG=chrome-os-partner:47422
TEST=flash the bootloader and measure the boottime by cbmem result
Change-Id: Id0b906bf34ac534667eb6e8f576e30942ceb923e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5fc38548d158158f07cded8cfc8ea5a0a7952161
Original-Change-Id: I62af26c13d98211974243100c581abcb5408fd63
Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/324685
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13980
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=none
BUG=none
TEST=boot oak to kernel on rev2
Change-Id: I368fcac1cf5e2261d00a34882a7341733ebd0732
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6ea0407f7273bc88613bc23a6fc4c41f9cca1adb
Original-Change-Id: Ic422e7265fdd35c573d8cd44280a1f7dc163a6db
Original-Signed-off-by: Bayi Cheng <bayi.cheng@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/323932
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/13979
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add multi-bytes read support.
BRANCH=none
BUG=none
TEST=saw edid log and dev screen
Change-Id: I106be98e751e2a3b998ccaedb28f71f3c6e18994
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94ee0b834947e8d971943aa24e61a9353c7b7306
Original-Change-Id: Iac5fe497da92b7d09383e0d6a04d98709aea5b20
Original-Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/325211
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/13978
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
- Change the makefile command $(shell pwd) to $(CURDIR) to find the
current directory without going out to the shell.
Change-Id: I4890eba6129630acd2883b92de77308d39949443
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13967
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Libpayload installs into the libpayload/ directory under the directory
you point it to. Since we were pointing it to build/libpayload, it
was installing to build/libpayload/libpayload.
Change-Id: I11029fcfb232d9b66eb3f310fa9e663236d4b213
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13966
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With this patch the numbers are the "base" addresses for the lines,
which is consistent with the PCI configuration space view.
Change-Id: I2c70d976f6f9f9f615d13bc7a634d6f8037e0c7b
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14028
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
... instead of the overall first one.
Change-Id: If9b2674ff2ef83b7c24a3388316b6f4128bc1007
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14027
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
An alternative to this patch is to copy the filetypes table from
util/cbfstool/cbfs.h and use that.
Change-Id: Iebf3a7a8912761ff6825a6f51c8b68df0dcc5990
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/14026
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
- Rename obj to coreinfo_obj so it doesn't conflict with the obj
variable in libpayload.
Change-Id: I2ffb06a87e30a5eeff5b0dfc0ba62b5e9ab46e26
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13938
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
- Add powerpc64le-linux-gnu & nds32le-elf to the instructions as
supported architectures
- Add nds32le-elf as a supported architecture so it will stop warning
when you build it.
Change-Id: Ifcdbc3d082eae5b9b5f8828914e7d2b7ed1f13a4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13961
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently, if SeaBIOS is set as the payload, it gets rebuilt every
single time we do a build.
Change it to re-build just when there’s a config change.
Change-Id: Ib141f2cbf8796d449172432bb30fa4806cf90328
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13948
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This doesn't do anything more than the clean target, but having both
clean and distclean targets in all makefiles makes standardizing the
cleaning routines easier.
Change-Id: I41578de371a8f767ee23266c30e65e928f0985c4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13939
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Previously the SeaBIOS directory would never get updated after the
initial clone because the tag would always match. This can be shown
by noticing that the text 'Fetching new commits from the SeaBIOS
git repo' is never seen.
This change will always try to pull the latest code if 'Master'
is selected.
Change-Id: I460e2fb0c6f683a0f85343d164880c2d9e6d95cc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13947
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a comment to try to lower possible confusion later if the jenkins
tool builder fails to build a new tool. The URLs for the packages that
are downloaded are checked against known locations so that someone can't
maliciously download a package from somewhere and run it on the build
server. This provides a little bit of security, but could confuse
someone if they don't realize it.
Change-Id: I7858e3d86fc705b480f6792b6adf3d5349580e01
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13955
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We've recently added a jenkins test builder for the coreboot toolchain.
This patch allows what it builds to be controlled from the makefiles
checked into git instead of by a rule on the builder itself.
Change-Id: I65f70bac5ab97ecb27aae93ee370b26a2ab1f9c0
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13954
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Yidi Lin