Update all of the license headers to make sure they are compliant
with coreboot's license header policy.
Change-Id: Ied67c5079a7f49594edb39caf61fe7f386c3f80d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14323
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change the existing chromeos.fmd files and the dts-to-fmd script to mark
RW_LEGACY as CBFS, so it's properly "formatted".
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I76de26032ea8da0c7755a76a01e7bea9cfaebe23
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 717a00c459906fa87f61314ea4541c31b50539f4
Original-Change-Id: I4b037b60d10be3da824c6baecabfd244eec2cdac
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336403
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14240
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
A long time ago many Chrome OS boards had pages full of duplicated
boilerplate code for the fill_lb_gpios() function, and we spent a lot of
time bikeshedding a proper solution that passes a table of lb_gpio
structs which can be concisely written with a static struct initializer
in http://crosreview.com/234648. Unfortunately we never really finished
that patch and in the mean time a different solution using the
fill_lb_gpio() helper got standardized onto most boards.
Still, that solution is not quite as clean and concise as the one we had
already designed, and it also wasn't applied consistently to all recent
boards (causing more boards with bad code to get added afterwards). This
patch switches all boards newer than Link to the better solution and
also adds some nicer debug output for the GPIOs while I'm there.
If more boards need to be converted from fill_lb_gpio() to this model
later (e.g. from a branch), it's quite easy to do with:
s/fill_lb_gpio(gpio++,\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\),\n\?\s*\([^,]*\));/\t{\1, \2, \4, \3},/
Based on a patch by Furquan Shaikh <furquan@google.com>.
BUG=None
BRANCH=None
TEST=Booted on Oak. Ran abuild -x.
Change-Id: I449974d1c75c8ed187f5e10935495b2f03725811
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14226
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Nyan is an old board that was committed before several core code
modernizations to timestamp and CBFS code. Not all of those later
patches were correctly integrated with old boards like this, and the
core code has evolved to a point where it doesn't actually boot anymore.
This patch fixes that issue and brings the Nyan boards more in line with
how later ARM platforms look.
BRANCH=None
BUG=None
TEST=My Blaze boots again.
Change-Id: I3277a2f59ad8ed47063f7f6b556685313b1446f8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 6a1679e342a7adc2b2371b6e3f69a898a7a5c717
Original-Change-Id: I2a0a2abbd79b4b5f756125dcbb6cbd9441016d4e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/328543
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/13832
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This makes the test IDs the default, taken from depthcharge
master (board/*/fmap.dts, hwid property).
Change-Id: I25793962ac16f451f204dbba6ede6a64c847cfd5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13634
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
For devices with Chrome EC, state the "board" name(s), so they're built
as part of the image.
A number of EC boards aren't supported in the Chrome EC master branch,
they're brought along but commented out, waiting for a port to master
in the Chrome EC code base.
Change-Id: Ic6ab821de55cf9b4e8b48fe5ebc603adeb8bb28b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13548
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are generated from depthcharge's board/*/fmap.dts using the
dts-to-fmd.sh script.
One special case is google/veyron's chromeos.fmd, which is used for a
larger set of boards - no problem since the converted fmd was the same
for all of them.
Set aside 128K for the bootblock on non-x86 systems (where the COREBOOT
region ends up at the beginning of flash). This becomes necessary
because we're working without a real cbfs master header (exists for
transition only), which carved out the space for the offset.
Change-Id: Ieeb33702d3e58e07e958523533f83da97237ecf1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12715
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Move the CHROMEOS dependent symbols VIRTUAL_DEV_SWITCH and
VBOOT_DYNAMIC_WORK_BUFFER under the CHROMEOS config options for the
mainboards that use them.
Change-Id: Iad126cf045cb3a312319037aff3c4b1f15f6529d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Add 'select MAINBOARD_HAS_NATIVE_VGA_INIT' which is just used as a gate
symbol to display MAINBOARD_DO_NATIVE_VGA_INIT to the mainboards that
are already selecting MAINBOARD_DO_NATIVE_VGA_INIT.
Since MAINBOARD_HAS_NATIVE_VGA_INIT is not used in any code, this should
not have any other effects.
This fixes the warning:
warning: (BOARD_SPECIFIC_OPTIONS) selects MAINBOARD_DO_NATIVE_VGA_INIT
which has unmet direct dependencies (VENDOR_ASUS && BOARD_ASUS_KFSN4_DRE
|| MAINBOARD_HAS_NATIVE_VGA_INIT)
Change-Id: I8ceee69ebae90dc32f55df58c2e80fe25397f049
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add CHROMEOS dependencies to selects for the following Kconfig
symbols:
CHROMEOS_RAMOOPS_DYNAMIC
CHROMEOS_RAMOOPS_NON_ACPI
CHROMEOS_VBNV_CMOS
CHROMEOS_VBNV_EC
CHROMEOS_VBNV_FLASH
EC_SOFTWARE_SYNC
LID_SWITCH
RETURN_FROM_VERSTAGE
SEPARATE_VERSTAGE
VBOOT_DISABLE_DEV_ON_RECOVERY
VBOOT_EC_SLOW_UPDATE
VBOOT_OPROM_MATTERS
VBOOT_STARTS_IN_BOOTBLOCK
WIPEOUT_SUPPORTED
This gets rid of these sorts of Kconfig errors:
warning: BOARD_SPECIFIC_OPTIONS selects CHROMEOS_VBNV_EC which has
unmet direct dependencies (MAINBOARD_HAS_CHROMEOS && CHROMEOS)
Note: These two boards would never actually have CHROMEOS enabled:
intel/emeraldlake2 has MAINBOARD_HAS_CHROMEOS commented out
google/peach_pit doesn't have MAINBOARD_HAS_CHROMEOS
Change-Id: I51b4ee326f082c6a656a813ee5772e9c34f5c343
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch fixes up verified boot (vboot2) configuration of all
tegra 124 bases boards in the tree.
Change-Id: I81f2e83821cbfdbe2a55095543e7447efdde494e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10761
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Initializing timestamps and writing the "start romstage" timestamp already
happens earlier.
One question to sort out is what to do about the migration into cbmem, but at
least this compiles again.
Change-Id: Ie8a0b7998c6c9da71f036857987f3c781385034f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
MAINBOARD_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere
(with no overlap), and never read. Remove it.
Change-Id: Ica1f16182b556dbf4a3b747237af74bcc4c0608c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10254
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
vboot_verify_firmware() was only defined to ease upstreaming.
It was only an empty inline as it is so remove it. Additionally,
vboot2 does not require romstage_handoff so there's no need in
adding it for the nyan boards.
Change-Id: I4d84ac9fb60c756cf10742f26503f7f11af5f57b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10155
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These options will need to just be selected in within
the .config files. There's not need in duplicating all
these options.
Change-Id: I7b670bc59a3b35e39eee4faecaf4aa779d47a3bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9959
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For boards with MAINBOARD_HAS_CHROMEOS, we should also
state what kind of storage is available for vboot's
non-volatile data.
The flags are taken from the chromium repository and
have no effect with CHROMEOS disabled.
Change-Id: I1747ad26c8c7f6d4076740ec2800dbd52c5d6b3d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9952
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch switches the mainboards with board id straps
to use BOARD_ID_AUTO instead of BOARD_ID_SUPPORT.
On urara, which does not have those straps, the option is
removed. (And re-added for urara derivatives through setting
the config option BOARD_ID_MANUAL
BRANCH=none
BUG=chrome-os-partner:37593
TEST=emerg-nyan_big coreboot, emerge-urara coreboot, emerge-buranku coreboot
Change-Id: I5ac4024c6f1f9b9d7a5179d88722c69b23b82bbd
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 22a470698f9c9ed275aa8150a5bb8d8cf368b050
Original-Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Change-Id: I48c291ad6f255a28c833bebc2638bfafa2782e74
Original-Reviewed-on: https://chromium-review.googlesource.com/262935
Original-Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: http://review.coreboot.org/9906
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This change switches all mainboard vendors and mainboards
to be autoincluded by Kconfig, rather than having to be mentioned
explicitly.
This means, vendor and mainboard directories are becoming more
"drop in", e.g. be placed in the coreboot directory hierarchy
without having to modify any higher level coreboot files.
The long term plan is to enable out of tree mainboards / components
to be built with a given coreboot version (given that the API did
not change)
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ib68ce1478a2e12562aeac6297128a21eb174d58a
Reviewed-on: http://review.coreboot.org/9295
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This CL makes slight changes to the ChromeOS-specific GPIO definitions
of Tegra and Rockchip boards to prepare them for new features in
depthcharge. It adds descriptions for the EC in RW and reset GPIOs,
changes the value Tegra writes into the (previously unused) 'port' field
to describe the complete GPIO information, and removes code to sample
some GPIOs that don't need to be sampled at coreboot time (to help
depthcharge detect errors and avoid using a stale value for something
that should always represent the current state).
BRANCH=None
BUG=None
TEST=None (tested together with depthcharge patches)
Change-Id: I3774979dbe7cacce4932c85810596d80e5664028
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: df295d0432fbf623597cf36ebb170bd4f63ee08d
Original-Change-Id: I36bb16c8d931f862bf12a5b862b10cf18d738ddd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231222
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9570
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e
Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228322
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9413
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.
BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm
Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f
Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228324
Reviewed-on: http://review.coreboot.org/9411
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d
Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219901
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch aligns tegra124 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Nyan, Nyan_Big and Nyan_Blaze.
Change-Id: Ia82ab86b2af903690cc6c9d310f7bdda3425ea7c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4d23774e071ec22781991ff20fbf63802f620c88
Original-Change-Id: Ia126cff8590117788d1872e50608c257d2659c1f
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224504
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9326
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Pull out the common usb setup utmip functions from t124 into tegra usb.h. These
can be reused for t132 as well.
BUG=chrome-os-partner:31293
BRANCH=None
TEST=Compiles successfully for nyan, big and blaze
Change-Id: Idddd40e409b56875436db6918d05f2889d83870b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 12f12cb30a033cce645f53457d13a987aeec22a1
Original-Change-Id: I83f83bafad0f52ad651fe5989430f41142803f2b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211200
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8927
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The name was changed due to review comments misunderstanding, it
should be restored to properly convey what the function does.
BUG=chrome-os-partner:30489
TEST=verified that Storm still properly reports board ID
Change-Id: Iba33cf837e137424bfac970b0c9764d26786be9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c0fff28c6ebf255cb9cf9dfe4c961d7a25bb13ff
Original-Change-Id: I4bd63f29afbfaf9f3e3e78602564eb52f63cc487
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211413
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8979
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Original-Reviewed-on: https://chromium-review.googlesource.com/212365
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Note: This purposefully is probably broken in vendorcode/google/chromeos
as I'm just trying to set a base for dropping more patches in. The vboot
paths will have to change from how they are currently constructed.
(cherry picked from commit 4fa17395113d86445660091413ecb005485f8014)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9
Reviewed-on: http://review.coreboot.org/8881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Original-Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Original-Reviewed-on: https://chromium-review.googlesource.com/214050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit f3413d39458f03895fe4963a41285f71d81bcf5f)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I912f63b12321aa26a7add302fc8a6c4e607330ef
Reviewed-on: http://review.coreboot.org/8880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These boards are supposed to be able to determine the board ID at run
time based on GPIO settings.
BUG=chrome-os-partner:30489
TEST=verified that all boards build. Checked that storm proto0 reports
board ID of 0 on the console
Original-Change-Id: Iadd758a799d69e1e34579d7d495378856b64c45b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210119
(cherry picked from commit f4d41ddf906c1bf0d10da38011998fa0a630c332)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0d5f94d3428157a70f0a9d711b57432e3f796733
Reviewed-on: http://review.coreboot.org/8722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the majority of Chrome OS boards there is no need to include board
ID calculation in any stage but ramstage, where the ID should be
available for inclusion into the coreboot table.
BUG=chrome-os-partner:30489
TEST=build only, no other tests yet
Change-Id: I1451d52382bc48cc126d40267e0f61712f4a6d4b
Original-Change-Id: Ib9c06698a399d31e79a9b14143343ba2ad46d0fb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/210117
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 27dd40e85bfcd0a38f388bad4d79f5fbb77a7566)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8720
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some platforms use tertiary interpretation of GPIO input state to
increase number of distinct values represented by a limited number of
GPIOs. The three states are
- external pull down (interpreted as 0)
- external pull up (1)
- not connected (2)
This has been required by Nvidia devices so far, but Exynos and
Ipq8086 platforms need this too.
This patch moves the function reading the tertiary state into the
library and exposes the necessary GPIO API functions in a new include
file. The functions are still supposed to be provided by platform
specific modules.
The function interpreting the GPIO states has been modified to allow
to interpret the state either as a true tertiary number or as a set
two bit fields.
Since linker garbage collection is not happening when building x86
targets, a new configuration option is being added to include the new
module only when needed.
BUG=chrome-os-partner:30489
TEST=verified that nyan_big still reports proper revision ID.
Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d
Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209673
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8717
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of sprinkling the cbfs calls around (as well as getting
return values incorrect) use the common run_ramstage() to perform
the necessary work to load and run ramstage.
Change-Id: I37b1e94be36ef7a43efe65b2db110742fa105169
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8710
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is no point in duplicating boardid.h per board - they are all
the same. Let's keep a single instance in the common include directory
and let the linker report a problem if one tries using this function
on a board where it is not supported.
BUG=chrome-os-partner:30489
TEST=verified that coreboot builds fine for nyan_big and nyan_blaze.
Original-Change-Id: Ifbe9c2287a1d828d4db74c637d1d02047ac4da25
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209699
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 589e6415faf18ca6aaf44da343dd33eadc8a53d3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8eef89cb822611a0050e5a50fc4b970eebd8d962
Reviewed-on: http://review.coreboot.org/8666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes a chunk of romstage code from Tegra and all Nyan
boards that was supposed to enable some LCD power rails early, but never
really worked. The dev_find_slot() function can only find PCI devices,
which the CPU cluster is not. Since we're done with Nyan-RO and the
ramstage display code is fine as it is, there is no point in trying to
fix this... but we should remove it from ToT lest someone uses it as a
blueprint to add more dead code to future boards.
BRANCH=None
BUG=None
TEST=None
Original-Change-Id: I6eee256873299429d4e3934fe7d454120390f34d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207720
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit a3df62a3bcefcc20ae59648f5d1f0a01db3c02c6)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8deedea5e9787848aae3064509c611bc349313cc
Reviewed-on: http://review.coreboot.org/8638
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This replaces need for separate cbmemc_reinit() calls made
via CAR_MIGRATE() and in ramstage.
Change-Id: If7b4d855c75df58b173f26ef3c90a4a7563166d3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7859
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Hynix 2GB/4GB configs have been fine-tuned.
Kingston 2GB config is new, uses RAMCODE 0x6.
BUG=none
TEST=emerge-nyan_big coreboot-nyan_big OK. Flashed to my
Big 2GB system (PVT1/SKU1) and it booted OK.
BRANCH=nyan_big
Original-Change-Id: I8a23a5568ef84d5befc13623f78bce664130f314
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/203305
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit e47d18d8cff50f46d0a14715b6750f7aa6d0da82)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I363db37d6a63d9f5c578e68a0149259657e1ebfd
Reviewed-on: http://review.coreboot.org/8045
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CrOS devices with Chromeos EC need only use hostevent to communicate
recovery assertion to the BIOS. This CL removes wired GPIO from
determining recovery as it appears under certain conditions (cold
reset) the internal PU on the AP isn't strong enough and therefore the
value is sometimes seen as asserted.
BRANCH=none
BUG=chrome-os-partner:29333
TEST=compiles & BIOS no longer responds to rec_mode GPIO during boot.
Original-Change-Id: Ib220cfa5f5bfe7193d555bfd32c0444b063d00f2
Original-Signed-off-by: Todd Broch <tbroch@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202996
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
(cherry picked from commit d9927bcd67b0fb069fde231314e654d727092282)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6e086cbabc884f18deb2791a0f897e332b31032f
Reviewed-on: http://review.coreboot.org/8042
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The VDDIO to GEN2 I2C SCL/SDA pins is 1.8V and the external
pull-up voltage is 3.3V (the external 3.3V > I/O 1.8V) thus
the pinmux E_OD bit of these two pins needs to be set to
ensure GEN2 I2C pads work fine on 3.3V.
BRANCH=nyan
BUG=none
TEST=observed voltage drop from 3.3V to 2.36V on gen2 i2c
on blaze w/o this change. the waveform looks good on both
scl/sda pins w/ this change.
Original-Change-Id: I1b97f0c9c7580d1e532c3bdf7ac8690241ee7ee3
Original-Signed-off-by: Ken Chang <kenc@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/200996
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 2db39166ec525e56a19746f38a867305a2687365)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I0c84eade89311baf0a6f180cb5cc9e2145f6b7ea
Reviewed-on: http://review.coreboot.org/7952
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
BUG=none
BRANCH=nyan
TEST=built and booted on Big under various modes, verified that
expected boot mode showed up using "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I8d98487a2cb910874c8d741008ae59a6c89102e7
Original-Reviewed-on: https://chromium-review.googlesource.com/199691
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 9f4b2574c1af23dcdc01706e9a118441f46a0f97)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ibbf264a1e05323dfddb7cdb270ee6f2d49e83eff
Reviewed-on: http://review.coreboot.org/7946
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
When a watchdog reset happens, the SOC will reset but other parts of the
system might not. That puts the machine in a funny state and may prevent it
from booting properly.
BUG=chrome-os-partner:28559
TEST=Built for nyan, nyan_big and nyan_blaze. Booted normally, through EC
reset, software reset ("reboot" command from the terminal), and through watch
dog reset. Verified that the new code only triggered during the watchdog reset
and that the system rebooted and was able to boot without going into recovery
mode unnecessarily.
BRANCH=nyan
Change-Id: Id92411c928344547fcd97e45063e4aff52d2e9e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/198582
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit b298be41c0959c58aeb8be5bf15141549da2504c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7900
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This is a fix for the 'Lost arb' we're seeing on Nyan* during
reboot stress testing. It occurs when we are slamming the
default PMIC registers with pmic_write_reg().
Currently, I've only captured this a few times, and the bus
clear seemed to work, as the PMIC writes continued (where
they'd hang the system before bus clear) for a couple of regs,
then it hangs hard, no messages, no 2nd lost arb, etc. So
I've added code to the PMIC write function that will reset the
SoC if any I2C error occurs. That seems to recover OK, i.e. on
the next reboot the PMIC writes all go thru, boot is OK, kernel
loads, etc.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Original-Change-Id: I1ac5e3023ae22c015105b7f0fb7849663b4aa982
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/197732
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
(cherry picked from commit f445127e2d9e223a5ef9117008a7ac7631a7980c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I584d55b99d65f1e278961db6bdde1845cb01f3bc
Reviewed-on: http://review.coreboot.org/7897
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When across warm reset, if VDD_3V3_SD_CARD gets power-cycled but VDDIO_SDMMC3
does not, we will get ~1.5V leakage on VDD. To fix that, we reset VDDIO_SDMMC3
to 0 along with VDD_3V3_SD_CARD in Coreboot. Payloads must turn on VDDIO_SDMMC3
explicitly before accessing SD card.
Note the warnings of "VDD_SDMMC must set early" in comment seems only happens on
U-Boot and can be removed.
BUG=chrome-os-partner:27053
BRNACH=nyan
TEST=Ctrl-U to boot from SD card, login and type "reboot", then Ctrl-U to boot
again. Without this patch, system will fail in loading kernel.
Original-Change-Id: I7f85995317d18587d514ea3afcff3bfea0a33e93
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196961
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 2cfdb78d9dc229a3c06f19bbe137d59d923908a4)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie7d814e0424478c35a56fbc959437ee6a555684a
Reviewed-on: http://review.coreboot.org/7866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
