The DPTF charger particpant device needs to be notified when the
AC state changes so it can re-evaluate the PPCC object and apply
the proper charge rate limit if necessary.
Change-Id: I6723754e2fe12862f50709875140fcadcddb18eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189029
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Brad Geltz <brad.geltz@intel.com>
(cherry picked from commit ed1ee577014421b021e8814edc91a1b696bf9eed)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Update the ec_commands header (direct from EC source) and
add support for the new charger current limit interface
which will be used by DPTF.
Change-Id: Ia9a2a84b612a2982dbe996f07a856be6cd53ebdb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185758
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 1fcca2d75856ecefd3aeb1c551182aa76d649466)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6925
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8df6cdbcacb082af88c069ef8b542b44ff21d97a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6616
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Currently the workaround for indicating a "full" battery kicks
in at 3%, but this turns out to be too high for some devices.
So move the workaround start point to 6% from full, or 94%.
Change-Id: Ib4305df3a68e89f3a10a096d0e89d8105ea9037b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 982dc496a0553c90dee56fda6411b7c21a5d7da9)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6521
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC recently added events for Thermal and Battery shutdown
to provide some sort of notification to the OS that it is
about to pull power.
Original-Change-Id: Ibbdb5f11b8fa9fc80612a3cc10667c612420b1bb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
(cherry picked from commit 03a53ed5e58caa018d49df193510d95bdf5bed7b)
Change-Id: I0cdf89a60b541840029db58d49921340e7ab60eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167314
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 16d00848f48da83f6d6c813137a35af45bb05c4b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6458
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Whenever spi_xfer is called and whenver it's implemented, the natural unit for
the amount of data being transfered is bytes. The API expected things to be
expressed in bits, however, which led to a lot of multiplying and dividing by
eight, and checkes to make sure things were multiples of eight. All of that
can now be removed.
BUG=None
TEST=Built and booted on link, falco, peach_pit and nyan and looked for SPI
errors in the firmware log. Built for rambi.
BRANCH=None
Change-Id: I02365bdb6960a35def7be7a0cd1aa0a2cc09392f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192049
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6175
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The spi_flash_probe and and spi_setup_slave functions each took a max_hz
parameter and a spi_mode parameter which were never used.
BUG=None
TEST=Built for link, falco, rambi, nyan.
BRANCH=None
Change-Id: I3a2e0a9ab530bcc0f722f81f00e8c7bd1f6d2a22
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192046
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6174
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Comment #endif /* FOO */ pairings.
Alphabetise headers and remove any #if CONFIG_ guards around them.
Background rational:
Remove guarding the inclusion of headers based on CONFIG_ options. This
*potentially* could hide issues such as functions being swapped from
under our feet, since different runtime behaviour could be declared with
the same function same name and type-signature. Hence, depending on the
header we happen to get may change runtime behaviour.
Change-Id: Ic61bdfb64d99f0e2998c6451ae6686915b7bb3d4
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6059
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's helpful to have a generic function that will tell
the EC to reboot if the EC isn't running a specified
image. Add that and implement google_chromeec_early_init()
to utilize the new function still maintaing its semantics
of if recvoery mode is enabled the EC should be running its
RO image. There is a slight change in that no communication
is done with the EC if not in recovery mode.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Built and boot with recovery request. Noted EC reboot.
Change-Id: I22240f6a11231e39c33fd79796a52ec76b119397
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182060
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5039
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The PATx methods will be passed a temperature in deci-kelvin,
so it needs to be converted back to kelvin before being sent
to the EC.
The PAT disable method is changed to take the temperature ID
as an argument so individual sensors can be disabled.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and
esif_uf userspace application. Start and stop DPTF and see
that temperature thresholds are set to sane values.
Change-Id: Ieeff5a5d2d833042923c059caf3e5abaf392da95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182023
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5036
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The EC now supports two auxiliary programmable trip points for
thermal monitoring. These are expected to be used by DPTF and
need to be exported.
In order to support these the header was updated from the latest
chrome ec source.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I257d910daac4e36280c0cecf4129381a32ffcb9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5027
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is a empty struct that has propagated through the superio's & ec's
but really does nothing. Time to get rid of it before it adds yet more
cruft. However, since this touches many superio's at once we do this in
stages by first changing the function type to be a pure procedure.
Change-Id: Ibc732e676a9d4f0269114acabc92b15771d27ef2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5617
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
This is not complete yet but it compiles and doesn't cause
any issues by itself. It is tied into the EC pretty closely
so that is part of the same commit.
Once we have more of the EC support done it will need some
more work to make use of those new interfaces properly.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, dump DSDT and look over \_SB.DPTF
Change-Id: I4b27e38baae18627a275488d77944208950b98bd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179459
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5002
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Some boards need to override which IRQ the i8042 keyboard
controller has its interrupt on instead of the default
IRQ#1. The SIO_EC_PS2K_IRQ macro provides the mainboard
an ability to override the interrupt location.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. New IRQ is correctly
picked up by kernel allowing keyboard support.
Change-Id: Ic2b222018dfc3aa30e24a31009e832ae0fb7e9cf
Reviewed-on: https://chromium-review.googlesource.com/177222
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4978
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
FixedIO seems like a nice short version of IO but in reality
it is limited to 10-bit ISA addresses and so should not really
be used in most situations.
Change all the references to use IO() directly instead.
BUG=chromium:311294
BRANCH=none
TEST=emerge-samus chromeos-coreboot-samus and check for iasl
warnings using updated iasl compiler revision 20130117.
Boot the imge and ensure that EC regions are still exported
in /proc/ioports.
Change-Id: I54de65892bed9e43dbba916990cf2b70c370843c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174810
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4910
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Two new events possible from the EC for starting and stopping throttle.
These are handled in a per-board method that is defined under the
thermal zone. This is not quite where I wanted it but the scoping
rules in ACPI don't let me have a defined external object in the
same scope.
Change-Id: I766f07b4365b29df3daa8e45e88f7c38c645c287
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63988
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4415
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
We will soon need to call google_chromeec_get_board_version to determine
correct DDR SPD. We must do so before DDR is initialized, so allow this
function to be called from romstage.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I882d84e38d11bf66067193a6f408f941f2cf8a81
Reviewed-on: https://gerrit.chromium.org/gerrit/61191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For devices with ChromeOS EC on SPI bus, use the standard SPI driver interface
(see spi-generic.h) to exchange data.
Note: Only EC protocol v3 is supported for SPI bus.
Change-Id: Ia8dcdecd125a2bd7424d0c7560e046b6d6988a03
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the new Chrome EC protocol version 3 to Coreboot.
Note, protocol version 3 is not applied on any bus implementations yet.
LPC (x86) and I2C (arm/snow) are still using v2 protocol. The first one to use
v3 protocol will be SPI bus (arm/pit). LPC / I2C will be updated to v3 only
when they are ready to change.
Change-Id: I3006435295fb509c6351afbb97de0fcedcb1d8c4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3750
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since EC protocol v3, the packet format will be the same for all buses (inclding
I2C, SPI, and LPC). That will simplify the implementation in each individual bus
driver source file.
To prepare for that, we will move the protocol part into crosec_proto.c:
crosec_command_proto, with bus driver in callback "crosec_io".
Change-Id: I9ccd19a57a182899dd1ef1cd90598679c1546295
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Chrome EC protocol V3 has several new command structure and constants defined.
Simply cherry-picking changes from upstream.
Change-Id: I7cb61d3b632ff32743e4fa312e0cc691c1c4c663
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
Change-Id: I3f8060bff32d3a49f1488b26830ae26b83dab79d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: http://review.coreboot.org/3746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome EC still does not tolerate SERIRQ in quiet mode
and so the keyboard does not work properly.
Change-Id: I9ab052187c9926ce0e2c86b86dfe987dd6564c1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default for this variable should be n, it should only depend on
EC_GOOGLE_CHROMEEC, and it should be (and is) explicitly enabled when
needed. This prevents it from being turned on when the EC bus is SPI.
Change-Id: Idc6651a764be4f055341a36b9b4a58990f050b0c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3737
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This used to contain the path for the EC include files, but
those files are included in coreboot now.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4fce9831c5e21b0a69a6295dbda2580e1ca83369
Reviewed-on: https://gerrit.chromium.org/gerrit/47606
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3057
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"Plug-n-play" is not supported on all platforms using Google's Chrome EC.
For example, EC on I2C bus will need explicit configuration and initialization.
So move the plug-n-play initialization to the LPC implementation.
Verified by building Google/Link (with EC/LPC) successfully.
Change-Id: I49e5943503fd5301aa2b2f8c1265f3813719d7e3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3089
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Google's Chrome EC can be installed on LPC or I2C bus, using different command
protocol. This commit adds I2C support for devices like Google/Snow.
Note: I2C interface cannot be automatically probed so the bus and chip number
must be explicitly set.
Verified by booting Google/Snow, with following console output:
Google Chrome EC: Hello got back 11223344 status (0)
Google Chrome EC: version:
ro: snow_v1.3.108-30f8374
rw: snow_v1.3.128-e35f60e
running image: 1
Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3074
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The Chrome EC can be connected by different types of bus like LPC / I2C / SPI,
and the current implementation is only for LPC.
To support other types, we must first isolate the LPC protocol stuff and add
configuration variable (EC_GOOGLE_CHROMEEC_LPC) to specify bus type.
Verified by building google/link (with chromeec) configuration successfully.
Change-Id: Ib2920d8d935bcc77a5394e818f69e9265e26e8a0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3068
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Google ChromeEC is an EC with completely open source firmware.
See https://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/platform/ec.git;a=summary
for the EC firmware source code (aka more information about the ChromeEC)
This patch adds support for the ChromeEC on coreboot's side.
Great thanks to the ChromeEC team for this amazing work. It's another
important milestone towards a free and open firmware stack on modern
hardware.
Change-Id: Iace78af9d291791d2f5f80ccca1587b418738cec
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2481
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
