Previously the g chip and cr50 board abused the ALTERNATE macro to
encode the pinmux configuration. This switches them over to using a
PINMUX macro that is designed for this purpose.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I5c1f70b7aa92d87cc105e672aa66aee7f267c9a2
Reviewed-on: https://chromium-review.googlesource.com/328823
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously these were often done in board.c files, which made it
impossible to include the gpio.inc anywhere else. As part of
refactoring the GPIO code we now need to be able to include gpio.inc
from common/gpio.c. Moving these defines into gpio.inc makes them
available wherever gpio.inc is included.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I28e7b5a1d40b113ae824b18f020b2d1e51e0c08a
Reviewed-on: https://chromium-review.googlesource.com/328822
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
EC clears the SCI/SMI/Wake masks in the resume sequence for S3
and S0ix. This works in the S3 case because Coreboot reprograms
the masks after EC. But in S0ix, these masks stay cleared forever.
This means that no further events are sent to the host.
This patch conditionally clears the masks only in the S3 transition.
BRANCH=glados
BUG=chrome-os-partner:48834
TEST=hostevent in EC console before and after S0ix to ensure SCI masks
are preserved
Change-Id: I23751680788ee7a239e321309a1334d37adc4f43
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Signed-off-by: Jenny TC <jenny.tc@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/320191
Commit-Ready: Jenny Tc <jenny.tc@intel.com>
Tested-by: Jenny Tc <jenny.tc@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If during EC boot we have space issue in shared memory then
ec hash calculation aborts and we cannot boot to RW.
This patch enables the config option to reclaim space from
little firmware loader. This leads to more shared memory
availability and resolves the boot issue.
BUG=chrome-os-partner:50127
BRANCH=glados
TEST=Build/Flash and verify DUT boots to RW. Increase PD logging
size to 512 and verify again that DUT boots to RW
Change-Id: Ic49e37fbc83e12a52cadd9796c5ef6f47d8cf33f
Signed-off-by: Shobhit Srivastava <shobhit.srivastava@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/327656
Reviewed-by: Srinivas Kowtal <srinivas.kowtal@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 22f8c71aca4d5bf225e420507e34032eef2ea5c0)
Reviewed-on: https://chromium-review.googlesource.com/328330
Commit-Ready: Divagar Mohandass <divagar.mohandass@intel.com>
Tested-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-by: Jenny Tc <jenny.tc@intel.com>
Change the report_error() macro that we use to indicate unhandled
conditions so that it can take an integer argument. Sometimes
that's useful.
BUG=none
BRANCH=none
TEST=make buildall, try some USB stuff, everything still works
No functional difference, console error output only.
Change-Id: Icdfd1f9162bb5e557c711b6363b73ef55fbc272d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/328490
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
To ensure it8320's compatibility on the LPC platform, we need to
disable SPI slave interface (default enabled) so that LPC module
will function normally.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=LPC module of it8320 works normally.
Change-Id: I259651b32f41ebae498e13bf07ebb68e5e520058
Reviewed-on: https://chromium-review.googlesource.com/328142
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
this is to move the existing code from chipset level to board level
since PseudoG3 is a board feature that required specific hardware.
BUG=none
BRANCH=glados
TEST=use hibernate command to enter PseudoG3
Change-Id: I309ef89e0ff7057ce46c634baa9791731a771984
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/327677
Reviewed-by: Shawn N <shawnn@chromium.org>
In http://crosreview.com/28402 code was added to power/gaia.c that
disabled keyboard scanning if the power button was pressed. The
purpose, according to that change, was to prevent accidental reboots by
pressing the power button together with another key that wasn't the
"Refresh" key (specifically: LCtrl, Tab, Reload, t, [, ], y, Dim Screen
and Mute).
At the time the original code was added, there was already code in the
power button interrupt handler to accomplish the same purpose: see
commit 29d25d807c ("Keyboard scan must stop driving columns when power
button is pressed."). It's unclear if the code in the interrupt handler
didn't work or if there was some other bug with it. ...or if perhaps
the changes in "gaia/power.c" weren't actually needed and the important
part of the original change was the mutex added to the scanning task.
In any case, current testing indicates that the code in power/gaia.c,
power/rockchip.c, and power/tegra.c isn't needed anymore. I ran through
the test sequence described in the original CL on my veyron_jerry and I
don't see any accidental reboots.
It's also instructive to note that only ARM boards (all presumably
copied from gaia) have this extra code. Presumably if the code was
actually needed then x86 boards would also need it.
In any case, let's remove it. It's suspected that there's some crazy
race where the disable in power/rockchip.c is overriding the enable in
the main power key handling code and leaving the keyboard disabled.
BRANCH=None
BUG=chrome-os-partner:48470
TEST=Same test as CL:28402
Change-Id: I6d21167ce3d773c9616abd4a728247a1934b96d6
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327843
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit dfae7e7ad45f4ce0e8f820caaa05a8754bba0250)
Reviewed-on: https://chromium-review.googlesource.com/328013
Before the change was made, the fan control timer keeps running
even all of the fans are off.
reproduce the problem:
1. fanset 3333
2. fanset 0
fan is disabled but fan control timer keeps running.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. fanset 3333
2. fanset 0
both fan and timer are off.
Change-Id: Id38f3a4c64bbb36e8b32baefd285dbb0bf14e47e
Reviewed-on: https://chromium-review.googlesource.com/327870
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
board_hibernate() may take alternate actions to place the chip into
hibernate, so inform the PD MCU that we're going to hibernate before
calling the function.
BUG=None
TEST=Run 'hibernate' on chell, verify that PD MCU goes to hibernate and
wakes when AC is attached.
BRANCH=glados
Change-Id: I71c12dcb416d54c79ac7d40e9bf430e268071fb2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327613
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
USB2_OTG_ID and USB2_OTG_VBUSSENSE pins were floated due to open drain
configuration. Improve EC power and remove power difference between S3
and S0ix. Improve EC power for SOC G3.
BRANCH=firmware-glados-7820.B
BUG=none
TEST=measure EC powers at S3/SOC-G3 and S0ix and check if there
are difference
Change-Id: I0535be675bc3a3a84214590e8190f1fedae1142c
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/327070
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 6dbad7f06e245bfa99e37326ed0517e81e207ef9)
Reviewed-on: https://chromium-review.googlesource.com/327480
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
This extends the test harness with a test verifying firmware upgrade.
The test in fact just determines the area available for upgrade, picks
the appropriate image and sends it to the device, 1K at a time.
The test does not verify that the device in fact switched to the new
image, the test succeeds if the device accepts all update messages.
BRANCH=none
BUG=chrome-os-partner:37774
TEST=verified that all tests still pass:
$ ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
SUCCESS: AES:ECB common
SUCCESS: AES:ECB128 1
SUCCESS: AES:ECB192 1
SUCCESS: AES:ECB256 1
SUCCESS: AES:ECB256 2
SUCCESS: AES:CTR128I 1
SUCCESS: AES:CTR256I 1
SUCCESS: EC-SIGN:NIST-P256:ECDSA
New max timeout: 1 s
SUCCESS: EC-KEYGEN:NIST-P256
SUCCESS: EC-KEYDERIVE:NIST-P256
SUCCESS: sha1:single:0
SUCCESS: sha256:single:0
SUCCESS: sha1:single:3
SUCCESS: sha256:single:3
SUCCESS: sha256:finish:1
SUCCESS: sha1:finish:3
SUCCESS: sha256:finish:2
-New max timeout: 3 s
SUCCESS: RSA-ENC:OAEP:SHA1:768
SUCCESS: RSA-ENC:OAEP:SHA256:768
SUCCESS: RSA-ENC:PKCS1-ES:NONE:768
New max timeout: 49 s
SUCCESS: RSA-ENC:PKCS1-ES:NONE:2048
SUCCESS: RSA-SIGN:PKCS1-SSA:SHA1:768
SUCCESS: RSA-SIGN:PKCS1-SSA:SHA256:768
SUCCESS: Firmware upgrade
Change-Id: I49052feb8e97a3e281bb20b7fddc359a55e96ae3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327416
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This patch suggests a firmware upgrade mechanism implemented through
an extended TPM command.
The firmware is transmitted in chunks, each chunk accompanied by its
checksum (first 32 bits of SHA1) and the base address.
The first chunk is of size zero and has the base address set to zero.
When the first chunk is received, the command handler determines the
destination flash space (A or B), erases it, and returns its base
address to the caller, such that the firmware update agent can tell in
which of the two spaces it should write the update.
The ultimate verification happens after the device is reset - the
integrity and authentity of the firmware upgrade is verified at that
point, the new firmware will not be started unless it is properly
signed.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=with all patches applied it is possible to upgrade firmware in
both spaces A and B.
Change-Id: I6aedc587ec630d65ba81000496f372c9044959a0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327415
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The g chip is used in multiple designs, likely to have different flash
memory layout and access permissions.
This patch introduces a mechanism which allows the board layer to
provide flash configuration information to the flash driver.
The flash region which is going to be enabled for write access depends
on the area the code is executing from. If running from the bottom
half (A), the whole top half should be writeable (this includes both
NVRAM area and the B code space). If running from B, the writeable
area starts on top of RO and extends to the end of NVRAM.
CQ-DEPEND=CL:*248190
BRANCH=none
BUG=chrome-os-partner:37754
TEST=with the rest of the patches applied verified that software
update can happen in both spaces, A and B.
Change-Id: Iab1c1a2766ae9bcfe04ff170c010f180cd1f770f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327412
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
It is difficult to tell what went wrong if a flash operation failed.
This patch adds printouts in cases of failure. The extension command
console channel is used.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=observed error messages reported while debugging firmware update
code.
Change-Id: I73d509ac5088249e8d34e32e760f3d2f063c91cd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327411
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In order to prevent the influence of the deviation of AVCC during ADC
conversion, the internal reference voltage (Vref) of ADC is fixed to
2.816V even it derives from AVCC.
Modified sources:
1. wheatley/board.c: Modified max adc voltage of ADC to 28.160V.
2. adc_chip.h: Modified internal ref voltage of ADC to 2.816V.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ib514f4bdc114802870eb3c77c650e18c05eb9617
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/327046
Reviewed-by: Shawn N <shawnn@chromium.org>
Add the config option to enable battery cutoff functionality.
BUG=none
BRANCH=none
TEST=use console command to cutoff battery, and verify it wakes up when
the adapter is plugged in.
Change-Id: I50ceeb2efc5dbd7843fbe8c1cef489a32848817f
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327249
Reviewed-by: Shawn N <shawnn@chromium.org>
The ultra debug board uses a different FTDI chip (vid:did 0403:6010),
which has two ports.
The SPI interface on this chip is hooked up to the second port, but
the code indiscriminately uses the first port when trying to open the
SPI channel, on all devices known to it.
Adding a new field in the supported_devices table allows to keep
default behavior, but use port B (the second port) when required.
Also, fix printout formatting problem.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=tpmtest succeeds with the new board
Change-Id: I01f7937444c8df61d7439a66d9da89fb2cac5372
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327232
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
When deciding which of the two images to start, A or B - consider the
image timestamp if everything else is equal. The later image should
take precedence.
Also, simplify the existing logic, and consider image A to be 'newer'
if both copies are the same otherwise.
BRANCH=none
BUG=chrome-os-partner:37754
TEST=with the rest of the patches applied, verified that the newer
image of the two gets started
Change-Id: I2c7a50ecfc8d254498c8e96f8651b8d53005897c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327414
Reviewed-by: Marius Schilder <mschilder@chromium.org>
The launcher should explicitly disable writes to the code space where
the loaded code is going to be running from.
BRANCH=None
BUG=chrome-os-partner:37554
TEST=with the rest of the patches applied firmware updates work as
expected.
Change-Id: I744f7016e4427188f53e8fa3302e8c06cf836e2e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327413
Reviewed-by: Marius Schilder <mschilder@chromium.org>
There is no point in defining tpm test exception classes per test
type, one common class is enough, especially if the source module of
the exception is reported.
BRANCH=none
BUG=none
TEST=tried running the test without the USB FTDI cable plugged in, got
the following error message:
$ ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Error in tpmtest.py:54: Failed to connect
$
Change-Id: I5642aa70c8a581099887b58e3a436d7f8d7608a1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327300
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Currently, a majority of the users don't use the experimental EC console
and as it stands, they have to wait approximately 300ms after pressing
enter after every command.
This commit adds a OOBM command to change the interrogation mode.
Additionally, it allows this command to be entered from the EC console.
Usage:
interrogate <never | always | auto> [enhanced]
Type the percent key to enter the (primitive) OOBM console. From
there a user can enter 'interrogate never' followed by enter to
completely disable the interrogation that occurs.
By default, the EC-3PO console will start in the 'always' state.
BUG=None
BRANCH=None
TEST=./util/ec3po/run_tests.sh
TEST=Run cros lint --debug for all changed files.
Change-Id: I10eef0c796eab4e0af1c232a3d3da8898ba3d348
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/327035
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wai-Hong Tam <waihong@chromium.org>
The RO image is now required to be signed following a cumbersome
procedure. It turns out that it is rebuilt even if the underlying
source files do not change. The reason being that it depends on tpm2
library and even includes it during linking (without actually linking
anything in), this was done to simplify the makefile.
This patch decouples the RO image from the tpm2 library, as a result
the RO image is not rebuilt every time make runs.
BRANCH=none
BUG=chrome-os-partner:49950
TEST=ran several times the following commands:
$ rm -rf build/cr50 && make BOARD=cr50 -j
there is no race conditions, the library is built in time.
- verified that running 'make' the second time does not cause the RO
image to be rebuilt any more.
Change-Id: Idbf84f6ac01e1a6d3da363489b8fc74fd5a54da5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327192
We found the deviation of ITIM32 is huge since apb2's clock isn't divisible
by 1MHz. (The default resolution of hwtimer is 1us.)
The solution is set the freq of apb2 the same as core clock. Note apb2 is
twice value of original one. It will increase power consumption slightly.
But we found the difference is acceptable no matter core clock is 15M
or 13MHz.
In this version, we also use the arrays to adjust i2c bus timing if
bus' freq is 400K or 1MHz for all source clock freqs of i2c.
Modified sources:
1. i2c.c: Support all source clock freqs of i2c for best bus timing.
2. clock.c: Set divider of apb2 if it's clock isn't divisible by 1MHz.
3. uart.c: Modified baud-rate for apb2 which is the same as core clock.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I6089caaaf9aa16186d7c6acf6f5fea0682a55655
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/327120
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fixed the bug that some of DP80's data is skipping if the speed of writing
by host is high. The solution is grabbing all data and sending them to UART
until FIFO of DP80 is empty in ISR.
Modified sources:
1. lpc.c: Fixed the bug that some of DP80's data is skipping.
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Ie53a5c7f0a80a1f836b571a00871cb57b42c87db
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/326931
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The output enable bit was being set before the output value was
initialized.
BRANCH=none
BUG=none
TEST=Confirmed the fix with a logic analyzer
Change-Id: If8228d716b4924b5fd65b8f59436f4b37f05644e
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327212
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The required output length is not known until padding
verification completes (this check is already done
in the appropriate padding check functions).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass.
Change-Id: I452244d052b7f334a6907bd653645671033a0890
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/327074
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
If OUTDIR brings in a "@", the build breaks because that delimits the
path, leading to invalid file names.
This can happen (and happened) when building on a Jenkins CI instance
which uses jobname@number as path for parallel checkouts on a
single build node.
BRANCH=none
BUG=none
TEST=build with make out=foo@bar ... failed and works now.
Change-Id: Id0594f0d7312419110091443755ec11b5f8ee2d8
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/327110
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
In the S0 <-> S3 transition, Coreboot sends EC messages to set/clear the
wake masks when the SMI is invoked. For S0ix, EC sets and clears the
wake mask via this patch.
These functions are directly invoked from the state machine transition states.
During S0ix entry, the wake mask for lid open is enabled. During S0ix exit,
the wake mask for lid open is cleared. All pending events are also cleared
BRANCH=none
BUG=chrome-os-partner:48834
TEST=test lidopen in S0ix
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Change-Id: I52a15f502ef637f7b7e4b559820deecb831d818f
Reviewed-on: https://chromium-review.googlesource.com/320190
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
For some reason the default linker does not find libftdi1 anymore.
Other Chrome OS packages linking to this library still build just
fine, it turns out they are using the default gcc for linking.
Let's do the same for building tpmtest library.
BRANCH=none
BUG=none
TEST=the following sequence now works fine:
cd test/tmp_test
touch *
make
and the resulting library allows to successfully run TPM tests on
the b1 board.
Change-Id: I10fe51a4747a3527b500d3255d8347e6a689c345
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327065
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The SPS GPIOs are hard wired, so there is no need to configure the
mux, but the default mode of pin operation is "output". The three SPS
input pins (CLK, CS, and MOSI) need to be explicitly configured as
such.
BRANCH=none
BUG=chrome-os-partner:50141
TEST=spiraw and TPM tests now pass
Change-Id: Ie8f6c6c3cd09420aab831113a1456227d2b3c44b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327064
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If a label is specified, then the NUL terminating
character is considered part of the label per the
TPM2 implementation.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass.
Change-Id: If5fccc293f7ab52fd6c33e2f3c38695c2921d919
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/326910
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
In normal operation the 16 bit timer number 1 is set up to count every
microsecond, and every 1000 counts (i.e. every millisecond) to assert an
IRQ (Interrupt Request). After a microsecond the IRQ is deasserted.when
the count is again not at its limit.
The IRQ handler ignores the IRQ from the timer itself.
If the clock is stopped or the autoreload of the counter is disabled
then the value of the count is left unchanged. If this count is the
limit then the IRQ will remain asserted. For stopping the clock this is
approximatly a 1 in 1000 chance, or is certain if the autoreload is
disabled.
If the IRQ from the timer continues to be asserted, then the NVIC will
continue to generate a fresh call to the IRQ handler as each previous
exception completes.
The fix is to do what almost every IRQ handler does for almost every
processor, and clear the request in the peripheral that is causing the
interrupt, rather than hoping that the timer will clear it itself. This
agrees with how the event timer is used. There may be a lurking bug in
the system timer handler as well as it also expects the timer to clear
its own IRQ.
BUG=chrome-os-partner:48499
TEST=Pass 2000s of continuous calls to port_80_interrupt_disable() /
port_80_interrupt_enable() without WDT being triggered. Stop the
autoreload and see it doesn't watchdog.
BRANCH=glados
Change-Id: I4726854b7784e2e4a39b8cb74c350206d71f90df
Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/326781
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Referring to i2c ports as i2c0 thru i2c4 is confusing, due to the
special naming of controller 0 ports, so use their actual names from the
datasheet.
BUG=None
TEST=Trigger failure on i2c0_1, verify that "i2c0_1 bad status .." is
seen on console.
BRANCH=glados, strago
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ibd0d638e5af1c0a64e6f4b1a709b790b6b10d5e6
Reviewed-on: https://chromium-review.googlesource.com/325822
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EC boot / hash computing can be a bottleneck for system boot time.
Reduce this bottleneck by running our processor at 48 MHz through boot,
until vboot hashing of RW completes.
BUG=chrome-os-partner:49583
TEST=Boot chell, verify vboot hash completes within 1 sec of EC boot and
'cbmem' delta between 'vboot select&load kernel' and 'finished EC
verification' is reduced to ~250 ms (which includes sysjump time).
BRANCH=glados
Change-Id: I18d87e685b89decef761e51517bfcfc43dcf8ef0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326792
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Isl9237 default setting sets 1.3s debounce time from ACOK assertion
to switching. It's too long for EC being notified AC is present.
Change the value to 150ms.
BUG=none
BRANCH=glados
TEST=In Kunimitsu system, plug in Zinger and capture timestamp when EC
receive AC_PRESENT interrupt, it's reduced by ~1.2s.
Change-Id: I2b027eef816949527138f7b8b53d5408fc823093
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/326844
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
USB2_OTG_ID and USB2_OTG_VBUSSENSE pins were floated due to open drain
configuration. Improve EC power and remove power difference between
S3 and S0ix. Improve EC power for SOC G3.
BRANCH=firmware-glados-7820.B
BUG=none
TEST=measure EC powers at S3/SOC-G3 and S0ix and check if there are
difference.
Change-Id: I6471a05a1f5f75b5c805e80190a3cc7ac96d7c3b
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/326901
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 31bff74cff46bf80518cc269da304a1090cb7eea)
Reviewed-on: https://chromium-review.googlesource.com/326991
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
The new register definitions file has been supplied, it is not
defining some fields which were present only in FPGA. Some tweaks are
required to accommodate this.
BRANCH=none
BUG=chrome-os-partner:50141
TEST=new code successfully boots on the evaluation board
Change-Id: Ie4158554e0aaf039d59669558861a763a23f0ceb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326803
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In case of no battery condition, current code sets the charger input
current to the charger maximum input current. To avoid damage to the
board, set the charger input current to the maximum current that the
board can support.
BUG=none
BRANCH=none
TEST=Manually tested on kunimitsu, removed the battery & then using EC
console command 'charger', verified that the current value is set
to 3000mA.
Change-Id: I94c40228a6362822c841a6e0c226bea0d3398b73
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/325522
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Before pd logging enabled, there is about 1320 bytes for
shared meory; after pd logging is enabled and reserved 512 bytes,
only around 780 bytes for shared memory. In shared_mem_acquire(),
we request 1024(ChUNK_SIZE) while 780 only available. This causes
hashing abort and could not boot to RW.
BUG=chrome-os-partner:50127
BRANCH=glados
TEST=In kunimitsu system, boot to RO and check available shared
memory is higher than 1024; system can soft sync, boot to RW.
Change-Id: Ic521a1eb95491cbe9351a800d6471449cbd7b084
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/326762
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Blink the LED in S3 as well as S0iX states so there is no user visible
difference in their behavior.
BUG=chrome-os-partner:49274
BRANCH=glados
TEST=Enter S0iX on chell (need SKU4) and verify LED blinks. Also verify
that the LED still blinks in S3.
Change-Id: I91b123de17787159f4e7d6aca2e86b80885b8f4e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326740
Reviewed-by: Shawn N <shawnn@chromium.org>
fmap_decode now checks the fmap name to determine if the fmap it is
decoding is the correct one. This change puts a comment in the ec fmap
header to note the use.
BUG=none
BRANCH=none
TEST=make buildall -j
CQ-DEPEND=CL:322262
Change-Id: Icdd56eef5474b51cb178b6ba37c530c2357341b2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326450
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The TPM2 api does not require keys to be word-aligned,
so have the compiler generate alignment-safe reads where
necessary.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2/ pass, more TCG tests pass.
Change-Id: I247e29f2bec139ab7ed4010ffb58cdae77ba9e0b
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/326201
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Added a 'drp' option to the console command usbc_action that is
used to toggle dualrole mode operation on and off. The default
Plankton operation is not affected as this control is initialized
to be disabled. When dualrole mode is enabled, then both CC lines
are used and monitored.
BRANCH=none
BUG=chrome-os-partner:50074
TEST=Manual
Tested Plankton connected to Samus. Verified that when dualrole mode
is enabled that it can connect as both SRC and SNK. Tested with Type C
cable initially connected and disconnected. In addition, verified that
power role swaps behave correctly, and that when disabled, default
Plankton operation is resumed.
Change-Id: I60adfa25844a01a50ba45d5d92e17a3318f3e0a0
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/325545
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Creating bootloader for the chip involves signing the image with an
'air gap' - some physical presence action is required. We don't want
this to be required when the builder is building cr50 for test
purposes.
The solution is to keep using the dummy private key when building by
default, and invoking make differently when building an image which
would be accepted by the hardware.
Setting CR50_RO_KEY variable in the environment or in the make command
line will cause the signer use the value of this variable as the name
of the file containing the key to use for signing the RO image.
Should this file be a public key, the signer will stop and look for a
fob containing the matching private key, and will stream the RO image
through the fob for signing.
Using the fob requires that the signer runs under sudo, but we do not
want the generated files to belong to root, some more code is added to
change the generated files' ownership to user running the make.
BRANCH=none
BUG=chrome-os-partner:49950
TEST=ran the following tests:
- verified that the build still succeeds by default.
- invoked make as follows:
CR50_RO_KEY=cr50_rom0-dev-blsign.pem.pub make BOARD=cr50
observed the signer stop to wait for the user to interact with the
USB fob and proceed. Made sure that the generated image runs
successfully on the evaluation board.
- verified that 'make BOARD=cr50 clean' still works (i.e. none of the
generated files is owned by root).
Change-Id: I733ec6386c1dfd838d83d22fb589fa64e5eeaced
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326484
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
