As a temp measure until a proper solution is implemented, reset the
restart counter when the PCR_Read command is issued by the host.
This is a good indication that Chrome OS is through the boot process,
as PCR value is used to determine the boot mode.
BRANCH=none
BUG=chrome-os-partner:55667
TEST=installed the new image on a Kevin cr50 and rebooted it in normal
and recovery modes, observed on the cr50 console the message like
> system_process_retry_counter:retry counter 1
Change-Id: Ib55e161d5edbf8f6e2d387fd756b94aa53c20ed8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364311
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
'+' flag can be used with signed integer type (%d) and causes positive
integers to be prefixed with '+' (e.g. +1745). This emphasizes output
values as a signed value. It can be mixed with left-justification flag
'-': %-+8d. It's ignored when used with unsigned integer or non-integer
types: %u, %x, %p, %s, %c, etc.
BUG=none
BRANCH=none
TEST=make buildall &&
int32_t d = 1745;
CPRINTS("'%-+8d'", -d); /* '-1745 ' */
CPRINTS("'%-+8d'", d); /* '+1745 ' */
CPRINTS("'%d'", d); /* '1745' */
CPRINTS("'%+08d'", -d); /* '000-1745' */
CPRINTS("'%+08d'", d); /* '000+1745' */
CPRINTS("'%+d'", -d); /* '-1745' */
CPRINTS("'%+d'", d); /* '+1745' */
CPRINTS("'%+s'", "foo"); /* 'foo' */
CPRINTS("'%-+8s'", "foo"); /* 'foo ' */
CPRINTS("'%+08x'", d); /* '000006d1' */
CPRINTS("'%+u'", d); /* '1745' */
Change-Id: I8dcd34b0cf03dbefc500b9c98fea235d85bde8d3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363924
When the case close debug (CCD) feature is provided by an external chip
(e.g security chip or TCPC), we still need to be able to detect debug
accessory with Rd/Rd (by setting Rp/Rp when VBUS is detected without
seeing Rp).
Add a CONFIG_CASE_CLOSED_DEBUG_EXTERNAL configuration parameter for this
case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:55410
TEST=manual:on Kevin, enable CONFIG_CASE_CLOSED_DEBUG_EXTERNAL,
plug a SuzyQ (with Rd/Rd) and verify that the device in debug mode
when transitioning to S5.
Change-Id: Ie04a000a7b0eb670e3808f7bca1180298dfcd9db
Reviewed-on: https://chromium-review.googlesource.com/363400
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The SoC looks for two RO images at reset, and is typically
configured for two RW images as well. This CL reports version
strings for all those images, as well as identifying the active
RO and RW copies.
Since the RO image doesn't contain a version string, we create
one using the epoch_, major_, minor_, and img_chk_ members of its
signed header.
BUG=chrome-os-partner:55558
BRANCH=none
TEST=make buildall; run on Cr50 hardware
The "version" command now includes information like this:
RO_A: * 0.0.2/a3c3d5ea
RO_B: 0.0.2/8895c9eb
RW_A: cr50_v1.1.4965-a6c1c73-dirty
RW_B: * cr50_v1.1.4959-2f49d5c
The '*' indicates the active image.
The test/tpm_test/tpmtest.py program has been updated to request
the version information at startup, and it also now reports
similar information, just all on one line:
RO_A:* 0.0.2/a3c3d5ea RO_B: 0.0.2/8895c9eb RW_A: cr50_v1.1 ...
The active images are marked with a '*' following the ':', so
that the same regexp can match either format:
($ro, $rw) = m/RO_[AB]:\s*\*\s+(\S+).*RW_[AB]:\s*\*\s+(\S+)/s;
Change-Id: Ic27e295d9122045b2ec5a638933924b65ecc8e43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362861
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
For the purpose of spoofing dual-role capability, treat
soft-disconnected batteries as not present, since they are not capable
of supplying a current until they are revived.
BUG=chrome-os-partner:55617
BRANCH=None
TEST=Manual on kevin w/ subsequent CL. Put battery into soft-disconnect
state. Attach charger and verify EC doesn't lose power and battery again
supplies current.
Change-Id: Ie6b83b3d4e1e33c4bbbd1a90450506e7dcd1dfb2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363003
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BD99955 charger auto exits from the battery learn mode if the charge
is inhibited. Hence, do not inhibit the charger in battery learn mode.
BUG=chrome-os-partner:55491
BRANCH=none
TEST=Manually tested on Reef using 'ectool chargecontrol' command.
Able to enter/exit battery learn mode safely.
Change-Id: If05f9a9451842b77619e0a8c5db5e54fec24f399
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/362123
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change implements logic for installing
endorsement certificates in the RW section.
The endorsement certificates are initially
provisioned in a fixed RO flash region and
are copied in the RW TPM data region (once
this region has been initialized).
Also add code for reading from the info bank,
which is where the endorsement seed is
initially stored.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=TCG tests running
Change-Id: Id8c16d399202eee4ac0c4e397bdd29641ff9d2f3
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/362402
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Flush our UART buffer to ensure that we don't miss prints when we reboot
the EC.
BUG=chrome-os-partner:55539
BRANCH=None
TEST=Manual on kevin, issue cold reboot host command, verify that
"Executing host reboot command" is seen on console.
Change-Id: I96d5687b413ba4f603e3e7845b5cbba1c2d65efa
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The tpm firmware version register should report the current RW image's
version, not the RW_A.
BRANCH=none
BUG=chrome-os-partner:55145
TEST=verified that tpm firmware version reported by coreboot on the AP
console matches the version running on the device, for both RW_A
and RW_B.
From coreboot console log on two different runs:
Firmware version: RO: 84e2dde7 RW: cr50_v1.1.4943-f81a901
Firmware version: RO: 84e2dde7 RW_B: cr50_v1.1.4943-f81a901
Change-Id: I43f5432e44e38dbf9b42750dd2042a0f005bcbfb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362612
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
During initialization the NvMem module looks for either a valid
partition or that the NvMem area is fully erased. If neither of
these two conditions were found, then it was only returning an
error code and logging a message to the console.
This CL modifies nvmem_init() so that if the error case as described
above is detected, then it will call nvmem_setup() which will
create two valid partitions. In addition, the setup function
erases all of the existing data in the NvMem space.
Enhanced the unit test that deals with both partitions being
corrupted so that it verifies the version numbers are correct
and that all user buffer data is set to 0xff.
BUG=chrome-os-partner:55536
BRANCH=None
TEST=Manual
Executed make runtests TEST_LIST_HOST=nvmem and verifed that all
tests passed.
Change-Id: Ib932e02f15bd1aad7811032a12d826c76476e53f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362448
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The clock() function was introduced to provide free running clock for
the TPM2 library, which expects this clock to run with a millisecond
resolution.
This patch fixes the bug where the function in fact was returning the
clock running at a microsecond resolution.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=with the appropriate modification of the user of this function
all lockout related TCG tests pass.
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361180
(cherry picked from commit b4e78b309900402499b8742199fb4536570d3000)
(cherry picked from commit fefaa02a4f2c807a3ad50137bd7dba7f5f081c31)
Change-Id: Ic02fffca610426d22e58609eb8c3693aec96ad5c
Reviewed-on: https://chromium-review.googlesource.com/362118
The manufacturing status check verifies if the proper certificates are
found in the device NV RAM. This check can not succeed unless NV RAM
metadata is initialized by calling _TPM_Init().
If the check shows that the device has not been through manufacturing
sequence yet, TPM_Manufacture() needs to be invoked to make sure that
all relevant TPM structures are initialized and properly stored in NV
RAM. _TPM_Init() needs to be invoked again after that.
BRANCH=ToT
BUG=chrome-os-partner:43025
TEST=restarting Kevin device with pre-manufactured CR50 takes it
through factory initialization on every reboot. Restarting Kevin
once TPM is through manufacturing process shows that the
previously saved rollback counters are preserved.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361093
Reviewed-by: Nagendra Modadugu <ngm@google.com>
(cherry picked from commit 61a0fe734e808d1dbdf56fb6023e04adf66553b3)
(cherry picked from commit 3207a57fb2f5957b6e833d9ab1f9ea46021c5e1e)
Change-Id: I80b69f2c4b8d0e4cca154db510867df39c707ce2
Reviewed-on: https://chromium-review.googlesource.com/362084
This copies the generic USB update code into common
so it can be used on other platforms. There should be
no functional change. cr50 folks want no change to their
code so vbendeb@chomium.org will refactor this back
together at a later date.
BUG=chromium:571476
TEST=none
BRANCH=none
Change-Id: I710afb22940013e7db5d8694898b90c0ae245777
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362131
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In certain test scenarios the tpm task is hogging all resource and
causes watchdog resets. Let's kick the watchdog in every loop, Long
calculations already have watchdog kicking in place.
BRANCH=ToT
BUG=none
TEST=tests executed in rapid succession do not cause watchdog resets
any more.
(cherry picked from commit de8fb11bfd07d3fea2048b6848b8a183c31e2580)
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360229
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Change-Id: Ifaad6f9b4af2218f601412a36a075b4b4275d56f
Reviewed-on: https://chromium-review.googlesource.com/362170
MKBP can now support buttons, so this commit adds the
keyboard_update_button() function which will be used to handle the
non-matrixed buttons.
BUG=chrome-os-partner:54976
BUG=chromium:626863
BRANCH=None
TEST=Flash kevin, press volume and power buttons and verify that
keyboard is still functional.
TEST=make -j buildall
CQ-DEPEND=CL:358633
Change-Id: I1c2d36d2113715cf6bd8c6fa7b26fe9253f6ac9f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/358634
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, the matrix keyboard protocol does not have support for
handling non-matrixed keys. This commit adds support for buttons which
do not appear in the keyboard matrix as well as switches.
Additionally, the keyboard FIFO is now just a general MKBP events FIFO
which MKBP events are free to use. Now, buttons and switches wil join
the key matrix event.
BUG=chrome-os-partner:54988
BUG=chrome-os-partner:54976
BUG=chromium:626863
BRANCH=None
TEST=Flash kevin, and verify that keyboard is still functional.
TEST=make -j buildall
CQ-DEPEND=CL:358926
Change-Id: If4ada904cbd5d77823a0710d4671484b198c9d91
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/358633
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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:55225
BRANCH=glados
TEST=Enter S0iX on cave and verify LED blinks.
Also verify that the LED still blinks in S3.
Change-Id: I883147b1c8e599de077c9f06e567a63d535a01f8
Signed-off-by: james_chao <james_chao@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/359985
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There's a new OTP change for the BD99955 and therefore the following
changes needed to be made.
- Change VFASTCHG_SET1 to 8.704V before CHG_EN is set to 1.
- Change VSYS_REG to 6.144V when starting Fast Charging.
- Change VSYS_REG back to 8.906V when Fast Charge is finished.
- Wait for 50ms to set CHG_EN to off (0) after Fast Charging has ended.
BUG=chrome-os-partner:55220
BUG=chrome-os-partner:55238
BRANCH=None
TEST=Flash kevin, plug discharged battery in. Plug AC in. `bd99955 r
0x11 1' and verify that VSYSREG is set to 0x1800 (6144mV).
TEST=`bd99955 r 0x1a 1' and verify that VFASTCHARGE is set to
0x2200 (8704mV).
TEST=Remove battery. `bd99955 r 0x11 1' and verify that VSYSREG is set
to 0x2300 (8960 mV).
TEST=Plug in battery and let charge to full. Verify that VSYSREG is set
to 0x2300 (8960 mV).
Change-Id: I5e5ca2cdcd4ead383416901c904df1e6fe5a9e28
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360421
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Added code to get the VBUS level by reading the charger registers.
BUG=chrome-os-partner:55117
BRANCH=none
TEST=Manually tested on Amenia, VBUS_VAL (5Ch) & VCC_VAL (5Eh)
registers are updated with the correct VBUS value on the
respective ports.
Change-Id: I3b019b2d87e4c347f12596df387a2a659092ae25
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/359416
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
When cr50 is not trying to do ccd, we dont need to monitor the devices.
Disable device state detection interrupts and the AP and EC UARTs.
BUG=none
BRANCH=none
TEST=gru and kevin monitor devices correctly when ccd is enabled, and
dont monitor anything when it is disabled.
Change-Id: Ic3f5974320486ff6dd0147c490a1c294cc2f6a76
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356770
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The code reporting the RW version is in fact using a fixed location in
flash memory. This is fine for a single RW image (i.e. the vast
majority of the EC boards), but is wrong for CR50 which can run one of
two RW images.
The fix is to account for this by providing the currently running
image type to the function retrieving the image version.
Note that RW and RW_B versions end up at different offsets into the
image, it is impossible to retrieve the version of the not currently
running RW by just changing the offset into the flash memory.
BRANCH=none
BUG=chrome-os-partner:55145
TEST=as follows:
- build, update and start a cr50
- check the vers. command output, observe that it is running from
RW and reports the correct RW version string:
> vers
Chip: g cr50 B1 0_0
Board: 0
RO:
RW: cr50_v1.1.4856-df14f6a
Build: cr50_v1.1.4856-df14f6a 2016-07-11 11:52:44 vbendeb@eskimo.mtv.corp.google.com
>
- build the image again, update and restart the cr50
- check the vers. command output, observe that it is running from
RW_B and reports the correct RW version string:
> vers
Chip: g cr50 B1 0_0
Board: 0
RO:
RW_B: cr50_v1.1.4856-df14f6a
Build: cr50_v1.1.4856-df14f6a 2016-07-11 11:52:44 vbendeb@eskimo.mtv.corp.google.com
>
- erase the RW space base
flasherase 0x4000 0x20000
- run the vers command again. It was failing before this fix, now
it still shows the proper RW_B version.
Change-Id: Iab8bc0e61b50dd65a9e18a0369b18bdd9cc05421
Reviewed-on: https://chromium-review.googlesource.com/359580
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The AP no longer uses PHY0 to to interact with Cr50. Cr50 only uses PHY1
so dont switch the PHY when disabling CCD just release the usb.
BUG=none
BRANCH=none
TEST=After running 'ccd disable' the command 'usb' still returns PHY B,
but 'lsusb | grep 5014' on the host doesn't show any devices. When CCD
is enabled 'lsusb | grep 5014' shows a device on the host.
Change-Id: Icec0acc7a0d00f7eb56c6feef3ff4cf5a3f99735
Reviewed-on: https://chromium-review.googlesource.com/359931
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
cts.tasklist contains tasks run only for CTS. These tasks are added to the
tasks registered in ec.tasklist with higher priority. This design allows
board directories to be free from CTS stuff.
cts.tasklist can be placed in each suite directory (cts/suite/cts.tasklist).
If a suite does not define its own cts.tasklist, the common list is used
(i.e. cts/cts.tasklist).
BUG=chromium:624520
BRANCH=none
TEST=Ran the followings:
make buildall
make CTS_MODULE=gpio BOARD=nucleo-f072rb
make CTS_MODULE=gpio BOARD=stm32l476g-eval
Change-Id: Ibb242297ee10a397a8fcb6ff73d8cbc560daa885
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359445
Reviewed-by: Chris Chen <twothreecc@google.com>
If wait_us < 0, comparison against motion_min_interval actually fails,
and this negative wait_us causes task_wait_event() never returns if we
are not using any motion task event except the timer. The motion task
will then stop running and sensor data stay unchanged.
BRANCH=none
BUG=chrome-os-partner:54092
TEST=hardcode wait_us to a negative value before motion_min_interval check,
and see motion task is still running by EC console cmd timerinfo
Change-Id: Ic1e7ffeeb9d2ec1f5c5beb4387294014298123af
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/358332
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If the EC has CONFIG_HOSTCMD_RTC set to 'y', then export this via the
features host command. The kernel can then use this feature to expose
an RTC device under /dev/rtc*.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
BRANCH=none
BUG=chrome-os-partner:54639
TEST=`ectool inventory` shows RTC on kevin
Change-Id: I644c8e61c4d9f691cc6ca94ef60bee4384c21660
Reviewed-on: https://chromium-review.googlesource.com/359414
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
elm EC console output is very spammy, as EC_CMD_MOTION_SENSE_CMD
is called every 100ms, so we want to set "hcdebug" to "off" as
the default (which still includes errors, but no "normal"
commands).
BRANCH=none
BUG=chrome-os-partner:55001
TEST=make buildall -j
TEST=Flash elm EC, see that output is fairly quiet.
Change-Id: I70d91c291d934b4f032e5c57f3c333e2c10b93bc
Reviewed-on: https://chromium-review.googlesource.com/359112
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
While the proper manufacturing initialization is in the works, we need
to be able to initialized the device, but do not want to run
manufacturing process on every reboot.
Let's store the state in the lowest location of the NVRAM, this patch
will be reverted when the proper initialization procedure is in place.
BRANCH=none
BUG=chrome-os-partner:50115
TEST=used the device in Kevin. Observed that factory initialization
sequence was invoked only on the first boot, the following boots
had no problems reading rollback counters.
Change-Id: I812cbad4d91db47de76ecfa5a14c56ae9c0efdab
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358680
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Currently, it is assumed the host will sooner or later retrieve the
events from the sensor ring: It is only used by Android and the sensor
HAL is enabling the ring buffer at boot.
But if nobody processes the ring, and the ring is almost full, the EC will
generate interrupt for every new events.
This can happen with ARC, where events generated for ChromeOS
will be in the ring but nobody will process them until Android is
started.
Add a command to allow sending ring MKBP events. It will be used when
the IIO ring buffer is enabled / disabled.
It also can be used for preventing raising interrupt when the device is
about to go to sleep.
BRANCH=ryu,cyan
BUG=b:25425420,b:27849483
TEST=Check with fiforead that no events are queued when IIO ring
buffer is disabled.
Check with ectool and androsensor that interrupt generation stops.
Change-Id: Ibc85eed2e0eae3a9ec07d191e692118bc2fd0dab
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356689
For certain board configurations, KSI2 will be stuck asserted for all
scan columns if the power button is held. We must be aware of this case
in order to correctly handle recovery mode key combinations.
BUG=chrome-os-partner:54602
BRANCH=None
TEST=Manual on gru. Do three-key salute, verify EC detects recovery mode.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I03d76e1121107484f79520745858388f6cae096c
Reviewed-on: https://chromium-review.googlesource.com/357590
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When verifying RW using rwsig, we need to be able to erase the RW
signature to remain in RO. This change excludes the RW signature from
the area protected by system_unsafe_to_overwrite, so flash write can be
used to overwrite the RW signature while still in the RW system image.
BUG=none
BRANCH=lucid
TEST="ectool flashwrite 0x1ff00 corrupt_sig" runs successfully, and on
reboot the EC firmware verification fails.
Change-Id: I7e234664ae564eef30a8b021ea0539b6c0ae898e
Reviewed-on: https://chromium-review.googlesource.com/356810
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The CR50 RO version is identified not just by the git hash, but also
by the fuse settings and keys used for signing. The first four bytes
of the entire RO image's hash are saved in the image header. Adding
these four bytes to the version string reported to the host allows to
uniquely identify both RO and RW firmware versions.
BRANCH=none
BUG=none
TEST=verified that the appropriate string is showing up:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO: 97594095 RW: cr50_v1.1.4803-dcac93a-dirty
localhost ~ #
Change-Id: I30a21fad15d99523b1edfa1baa32d80b44e7d0df
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356735
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Not everything with a temperature sensor uses thermal throttling. This
change modifies the conditional build to enable building temp sensor
source without thermal throttling.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I8c0753f12899e9f203c04477ae520bcda40d5fd8
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356484
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
For designs where the host SOC is responsible for setting the USB-C SS
mux, the EC must track the desired mux state and inform the host when
the desired state changes. Then, the host must ask the EC for the new
desired state and set the mux accordingly.
BUG=chrome-os-partner:52639
BRANCH=None
TEST=Manual on gru with subsequent commit.
Attach USB dongle in port 1 and DP dongle in port 0, then verify `ectool
usbpdmuxinfo` output:
Port 0: DP
Port 1: USB
Flip DP dongle and verify output changes:
Port 0: DP INV
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6a99ce93a76c3197f9195cfaa25c5217d09aeb75
Reviewed-on: https://chromium-review.googlesource.com/355281
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Created a new TPM register define at the beginning of the
vendor defined configuration register space 0xF90 - 0xFFF.
Note that this same space is defined for each locality.
In order to retrieve the FW version string, the TPM register
at offset 0xF90 needs to be written. This will initialize
a the pointer index to 0. The same register is then
read by the AP and each read will return up to 4 bytes of the
FW version string. Once Cr50 detects the string termination
character, it stops incrementing the index so that 0s continue
to be returned for each subsequent read.
In addition there is a max value of reads for the case when the
version string is corrupt and doesn't have a '\0' character.
BRANCH=none
BUG=chrome-os-partner:54723
TEST=Manual
Added a routine in /coreboot/src/drivers/spi/tpm.c tpm_init()
that does the write/read sequence described above. This test
routine produced the folloiwng AP console output:
Reading TPM EC Version!!
scollyer@ code goes here
Read 1: cr50 0x30
Read 2: _v1. 0x2e
Read 3: 1.47 0x37
Read 4: 81-1 0x31
Read 5: 3619 0x39
Read 6: 95-d 0x64
Read 7: irty 0x79
Read 7: 0x0
Cr50 FW Version: cr50_v1.1.4781-1361995-dirty
Read Count = 29
Initialized TPM device CR50 revision 0
Change-Id: I5d68a037f7a508e3109c35e841dbcb3a893ce22f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355701
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The "PC Client Protection Profile for TPM 2.0" document defines SPI
bus addresses for different localities. That definition is not honored
in the cr50 implementation, this patch fixes it: locality zero
register file is based off 0xd40000.
BRANCH=none
BUG=chrome-os-partner:54720
TEST=verified that upstream Linux driver is happy now
Change-Id: Ibc01035a5dcc823a0ec82374d758de08a70083b6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355610
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added mutex lock for nvmem write/move operations. In the
current implementation, there is no single entry point
for the platform specific NvMem calls. The mutex lock is
coupled with a task number so that the same task can attempt
to grab the lock without stalling itself.
In addition to the mutex lock, changed where the cache.base_ptr
variable is updated. Previously, this was done prior to the
partition being copied from flash to the shared memory area.
Now, the variable is only updated after the copy so that read
operations will always read from the correctly from either
flash or from cache memory if a write operation has been
started.
BRANCH=none
BUG=chrome-os-partner:52520
TEST=Manual
make runtests TEST_LIST_HOST=nvmem and verify that all tests pass.
Tested with tcg_test utility to test reads/writes using the
command "build/test-tpm2/install/bin/compliance --ntpm
localhost:9883 --select CPCTPM_TC2_3_33_07_01".
Change-Id: Ib6f278ad889424f4df85e4a328da1f45c8d00730
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353026
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a host event to support MKPB:
When sent, the ACPI code will send a notification to the kernel
cros-ec-lpcs driver that will issue EC_CMD_GET_NEXT_EVENT.
We can allow code (sensor stack for instance) that uses MKBP to work
on ACPI based architecture.
Obviously, host event over MKPB is not supported.
BRANCH=none
BUG=b:27849483
TEST=Check we get sensor events on Cyan through the sensor ring.
(cyan branch)
Change-Id: Iadc9c852b410cf69ef15bcbbb1b086c36687c687
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353634
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we jump from RO to RW, tcpc_vbus declared in tcpci.c
is initialized to 0. So even if we had VBUS present before,
PD_FLAGS_VBUS_NEVER_LOW is not set and soft reset cannot be used
later when source cap is timeout. This causes power loss and reboot
when we boot up system without battery.
Set PD_FLAGS_VBUS_NEVER_LOW after tcpm_init() so we can refresh
tcpc_vbus from TCPC first.
BUG=chrome-os-partner:53496
BRANCH=none
TEST=test on elm.
Remove battery and boot up successfully only with AC.
Use "sysjump rw" command and ec won't reboot by pd hard reset.
Change-Id: Id4737f076a9572cb540310f9fdce062198257967
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/352833
Reviewed-by: Rong Chang <rongchang@chromium.org>
Previously our charger ISR called a deferred task which woke our charger
task. We can skip the deferred task and just wake our charger task
directly.
The other meaningful change here is to assume that we're using the
charger for VBUS detection / BC1.2 if we have a usb_chg task, which
holds true for all of our current boards with this charger.
BUG=None
TEST=Manual on kevin with subsequent commit. Verify charger connect /
disconnect detection works properly on both ports, with zinger, donette
and generic DCP charger.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iad4f3ea90947b50859c549b591675e325717209f
Reviewed-on: https://chromium-review.googlesource.com/352822
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If i2c communication with the TCPC is failing after 300ms+ then it's
likely going to fail forever, so return an error to allow the PD task to
continue initialization.
BUG=chrome-os-partner:53815
BRANCH=None
TEST=Manual on reef. Disconnect TCPC, attach charger to other port, and
verify charge manager correctly sets current limit based on detection.
Change-Id: I2c12320971a77504292f75393791e609e34897b4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/352501
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There is only one charger IC and one interrupt PIN for both the ports
and also from the ISR it's not possible to decode from which port the
interrupt is triggered hence a deferred function is used to trigger
the wake event for the ports. As there is no additional benefit of
having an extra task, added code to use only one USB charger task for
both the ports.
BUG=chrome-os-partner:54272
BRANCH=none
TEST=Manually tested on Amenia. BC1.2 detection is success
and the battery can charge on both the ports (VBUS/VCC).
Change-Id: I2745a5a179662aaeef8d48c8c1763919e8853fd0
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/351752
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If the lid is initially closed, keyboard scan should be disabled.
BUG=chrome-os-partner:53566
BRANCH=none
TEST=Check ESC+Refresh+PwrBtn is detected.
Check keyscan is enabled if lid is open.
Check keyscan is disabled if lid is closed.
Check power button is functional if lid is opened.
Check power button is masked if lid is closed.
Change-Id: I2354a657d8bf0c13207517cc789547a68befd240
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/351534
Reviewed-by: Shawn N <shawnn@chromium.org>
In TCPCI specifiction R1.0 4.7.2, the last step of transmitting
hard reset message is enable PD message passing by writing to
RECEIVE_MESSAGE register.
BRANCH=none
BUG=chrome-os-partner:52815
TEST=manual
build and load on reference board with anx7688 port controller.
connect zinger to port 0, and use ec uart console to send hard
reset message:
pd 0 hard
check PD communication
Signed-off-by: Rong Chang <rongchang@chromium.org>
Change-Id: I52968b603f0227d7d9a112b0216cd5fd6362a0b2
Reviewed-on: https://chromium-review.googlesource.com/348142
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Koro Chen <koro.chen@mediatek.com>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Section 5.3.1 TPM Register Space Decode of TCG PC Client
Platform TPM Profile (PTP) Specification Rev 00.43 allows
partial access to registers: "Software may access only part
of a register, e.g. read or write one byte of a 4 byte register."
BUG=chrome-os-partner:54286
BRANCH=none
TEST=tpm driver successfully sets TPM_STS_COMMAND_READY
(see more details in BUG)
Change-Id: I92995f04c6f6221ab7e00d086c4067e447557476
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351701
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
