We retroactively decided to use the variant name "pinky" for the Rk3288
board we're currently bringing up, and retcon the unadorned "veyron"
name to refer to the Rockchip evaluation board. Since we currently have
no interest to maintain coreboot support for that board in our tree,
let's rename everything to "veyron_pinky" and forget about "veyron".
CQ-DEPEND=CL:217592
BUG=chrome-os-partner:30167
TEST='emerge-veyron libpayload coreboot' fails but
'emerge-veyron_pinky libpayload coreboot' succeeds.
Change-Id: I366391efc8e0a7c610584b50cea331a0164da6f3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217674
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/211053
Reviewed-by: Julius Werner <jwerner@chromium.org>
config.veyron was written by hand and had some minor mismatches (entries
in a different order than Config.in, negative entries for some options
that no longer exist, etc.). Most importantly, it was missing the
negative entry for CONFIG_LP_REMOTEGDB, which is required to make our
ebuilds build a correct image.dev.bin with GDB support.
Ran it through make oldconfig once so that everything is in the right
place again.
BUG=None
TEST=Remote GDB on Veyron works (woohoo!)
Change-Id: Ic5ebe25fe8ef1b63031569a178c5419ca7e31754
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208255
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add support board veyron:
1)Support driver rktimer
2)Support driver rkserial
3)Support config.veyron
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I2cccedf3b62883dd372842a7972e93f2ebbfb282
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/206184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
With new config options added the existing configs became stale and
the library can't be built without make stopping and waiting for the
user to confirm new configuration defaults.
The following was used to normalize the configs:
$ for f in configs/config.*; do
cp $f .config
make oldconfig
mv .config $f
done
hitting return through each dialog.
CQ-DEPEND=CL:205476
BUG=none
TEST=manual build for strom does not stop anymore at 'make oldconfig' phase
Change-Id: I9678b4c69fc01640be490907136cf8e0916e4957
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205359
Reviewed-by: Julius Werner <jwerner@chromium.org>
There have been leaks of GPL code into libpayload for a while now, for
new features or improvements that require third party code with no
adequate alternative among BSD-licensed software. It seems silly and
counter-productive to keep holding back features and performance
improvements from libpayload for a use-case (proprietary payloads) that
doesn't even seem to be implemented anywhere to date. Open-source
payloads should not need to suffer to appease commercial ones.
Instead, this patch introduces a new Kconfig option to explicitly allow
inclusion of GPL code. It will use Kconfig dependencies and/or Makefile
rules to ensure that no GPL code can end up in the final payload if that
option is unset, allowing proprietary payloads to keep working with the
existing BSD-licensed feature set. New features and patches (that are
sufficiently separate and self-contained to allow guarding through this
config option) can choose whether to import GPL code, and need to depend
on this option if they do.
Also clean up all (known) existing uses of GPL code to depend on the new
option, add some recent third-party imports to the LICENSES file, and
relicense the selfboot.c files to BSD with permission of the author.
BUG=chrome-os-partner:24957
TEST=Compiled Falco and Nyan_Big both with and without the new option,
disassembled output binaries to ensure that memcpy() looks as expected.
Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203513
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
With new config options added the existing configs became stale and
the library can't be built without make stopping and waiting for the
user to confirm new configuration defaults.
The following was used to normalize the configs:
$ for f in configs/config.*; do
cp $f .config
make oldconfig
mv .config $f
done
hitting return through each dialog.
BUG=none
TEST=manual build for strom does not stop anymore at 'make oldconfig' phase
Change-Id: I5ee85a17c1612d598b7b26c115c2e9efafde1df9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203623
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds code to initialize the two DWC3 USB host controllers and
their associated PHYs to the IPQ806x SoC (closely imitating the existing
DWC3 implementation for Exynos5), and uses them to initialize USB on the
Storm mainboard.
BUG=chrome-os-partner:29375
TEST=Hack up netboot to get around missing SPI flash, load a file over
TFTP. Hack a storage read into the storage attach function, dump the
data and confirm that it looks right. Enable USB debugging and confirm
3.0 devices get enumerated at SuperSpeed (mostly).
Change-Id: Iaf7b96bef994081ca222b7de9d8e8c49751d3f1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202157
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
- Put SSD into reset on transition to S3/S5 to prevent leakage
- Fix GPIO number for wlan disable used in smihandler
- Enable generic hub driver in libpayload
- Fix comment in devicetree about S0ix
BUG=chrome-os-partner:28502
BRANCH=None
TEST=Build and boot on samus
Change-Id: Idce566d0f22622d36697be54ab51cacb576c5d6d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203185
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
XHCI driver was not enabled in libpayload and some ports were
disabled that should be enabled.
The Chrome OS GPIOs also need to be reported as 0xFFFFFFFF to
properly indicate unused so crossystem does not attempt to
export GPIO number 255 in the kernel and trigger a warning.
BUG=chrome-os-partner:28234
TEST=Build and boot on wtm2
Change-Id: Ib5727ef6e618c959640b200757cfa13f95c7cb0f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The config files need to be renormalized after two new Kconfig options
for the IPQ806x have been added. Otherwise, trying to just 'make
oldconfig' with them from a command line hangs with extra questions. (I
never quite figured out why the ebuild seems to be unaffected by this.)
BUG=None
TEST=None
Change-Id: I272e40ef81e18c4d4e043b053d732c2e1c2599e9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202803
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
storm:
Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202045
Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As the USB driver for storm hardware is not yet available, do not
define it in llibpayload.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just compilation/building
Change-Id: I6aea72cda33b61deb0a7dc69f8295f8c3f61406b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200827
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a placeholder for a real libpayload config, it is fairly close
to the real one and will allow building chrome os image for storm in
the meanwhile.
BUG=chrome-os-partner:27784
TEST=manual
. with this and some other patches 'emerge-storm libpayload
depthcharge' does not fail anymore.
Change-Id: Ie1a96310a7b329fac9d869cfe83005ea20c7e235
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198928
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Some kconfig options have changed but the configs haven't been updated. When
make oldconfig is run from the ebuild through emake, that doesn't seem to
causea problem for whatever reason. When run manually, however, kconfig stops
to ask for each config it doesn't have a value for. This change updates the
configs to correct that issue.
BUG=None
TEST=Ran make oldconfig manually for all boards. Built and booted on big.
BRANCH=None
Change-Id: I138f8ad9239a3834d28dc492e0a90a94442b2af1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194908
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These drivers are needed right away and never really fit into depthcharge's
driver model anyway.
CQ-DEPEND=CL:194064
BUG=None
TEST=Built and booted nyan, link, and peach_pit and verified that timer values
in cbmem were reasonable. Built for nyan_big, nyan_blaze and daisy.
BRANCH=None
Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194058
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194057
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
I don't even know why these were off (at least the XHCI one)... well,
now they aren't. As far as coreboot is concerned, Snow is just a test
platform anyway, and these are useful to have.
BUG=None
TEST=It works.
Change-Id: Ibef65e8be6cf752276ffc87df6dda04869dd97cd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193733
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
BUG=None
TEST=emerge-nyan_blaze chromeos-coreboot-nyan builds OK
Change-Id: I707a5efdbdbc573ef73cd366bb7c90fa7c4e74c2
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/190722
Reviewed-by: Julius Werner <jwerner@chromium.org>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This adds the EHCI driver back to libpayload and configures
the devicetree to route ports to EHCI.
This is hopefully just temporary until the issues with XHCI
can be worked out.
BUG=chrome-os-partner:23635
BRANCH=rambi
TEST=build and boot from USB on rambi
Change-Id: I0549661f5e5fd83477f4839a05e7e21175b24b64
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175513
All USB ports need to be routed through XHCI, so
remove UHCI and EHCI stacks (will also reduce binary size
of depthcharge)
BUG=chrome-os-partner:23396
TEST=Boot into dev mode screen, use keyboard and see that it works.
BRANCH=none
Change-Id: I05c56657f16c459294c0e9ceff339fe7a8e03ca2
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173579
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
The coreboot tables were moved but this wasn't updated, breaking all payloads.
BUG=None
TEST=Booted with this fix and saw that depthcharge starts again.
BRANCH=None
Change-Id: Id85d24cf936fac3eae82c20f61fe912b7ca8d185
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173794
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
While nyan's serial hardware is essentially the same as the 8250, it's
registers are spaced 4 bytes apart.
CQ-DEPEND=CL:173492
BUG=None
TEST=With a corresponding change in depthcharge which adds an alternative
serial driver, got console output from depthcharge.
BRANCH=None
Change-Id: I43c040c175d08cfb1bde8002a89254dce9e36b7b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173545
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
This range needs to be adjusted because there isn't any space reserved for the
framebuffer yet on nyan.
BUG=None
TEST=With this and other changes, got console output from depthcharge.
BRANCH=None
Change-Id: I41e85713ba28200e3b38e0efaea58a0de02b7aad
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173544
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
This is a direct copy of the bayleybay configuration.
BUG=chrome-os-partner:23121
TEST=emerge-rambi libpayload
Change-Id: Ib90f5797b4656ac366d16da5f3243fea20357dc5
Reviewed-on: https://chromium-review.googlesource.com/172587
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Bernie Thompson <bhthompson@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Add the coreboot board files for samus
- Based on Bolt
- GPIO setup based on 0.91 schematic
- Support both memory types
- No HDA verb table for this platform
- Some GPIO interrupts are shared and need to be passed to OS
BUG=chrome-os-partner:22996
BRANCH=samus
TEST=emerge-samus chromeos-coreboot-samus
Change-Id: I8dbd7639456c631a0115b03a493d94b5e2361ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
An earlier change modified the serial port configuration option name
and updated most board configurations, but Bayleybay was left behind.
BUG=None
TEST=Baylebay builds smoothly again
Change-Id: I8b779c1fb24820ca5ff95dcd6641ae1df94f7e1b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170961
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This config is based on the pit config but has been tuned somewhat to be
appropriate for the hardware on the nyan board.
BUG=None
TEST=With this and other changes, built for the nyan board.
BRANCH=None
Change-Id: Ide209a05a311d475151253d45f9315a6c35da565
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
While the 8250 compatible serial port driver is primarily useful on x86
systems because it works with the legacy x86 com ports, some devices which
aren't x86 based have 8250 compatible UARTs as well. This change renames the
CONFIG_X86_SERIAL_CONSOLE option to the more general and direct
CONFIG_8250_SERIAL_CONSOLE and fixes up the dependencies so that non-x86
systems can enable the driver, although it will default to on on x86 and off
otherwise.
Also, the default IO port address that's added to the sysinfo structure on x86
and which is intended to be overwritten by a value in the coreboot tables is
not used on ARM. That variable is adjusted so that it's more clear it's a
default value, and made dependent on x86 since that's the only place its value
is actually used.
BUG=None
TEST=With this and other changes, built for an ARM board which has an ns16550
(and essentially 8250) compatible UART. Built for pit and for link.
BRANCH=None
Change-Id: Ifeaade0e7bd76d382426e947275a9c933da4930e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170834
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is a copy of falco configuration with XHCI enabled and {E,O,U}HCI
disabled.
BUG=none
TEST=manual
$ emerge-bayleybay libpayload
now succeeds
Change-Id: I25db5ac203344abc090f3f195284df88195f25b0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170553
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The existing USB_MEMORY mechanism to instantiate non-PCI host
controllers is clunky and inflexible... most importantly, it doesn't
allow multiple host controllers of the same kind. This patch replaces it
with a function that allows payloads to directly instantiate as many
host controllers of whatever type they need.
CQ-DEPEND=CL:169541
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ic21d2016a4ef92c67fa420bdc0f0d8a6508b69e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This is mostly a rewrite, don't even try to read a diff.
Tested with an internal rate matching hub on a QM77 board and three hubs
integrated into DELL monitors.
Original-Change-Id: Ib12fa2aa90af4e0f37143d2ed92c4a1705b6d774
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3451
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 5736fab4be)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Idec16258a5b7286de48b5d3974eeefcab45a7e50
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168096
Now that we're enabling 3.5GB...
BUG=chrome-os-partner:22144
BRANCH=none
TEST=loaded depthcharge on kirby
Change-Id: Ic21d0efbf1fe7593737e010e3ad2dc81edc3b276
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167666
Reviewed-by: ron minnich <rminnich@chromium.org>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit. Built libpayload and depthcharge on all
supported platforms.
BRANCH=None
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:18637
BRANCH=none
TEST=boot on Snow, see depthcharge boot the system
Change-Id: I1f9e3ff795caa7f881ca4e9975258395ef6fee50
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62189
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
