This allows a servo_v4 to export case closed debugging
automatically, if it detects that it's been plugged into
a ccd device.
BUG=chromium:571476
TEST=Connect to reef in both orientations.
BRANCH=None
Change-Id: I8e2781056b22e834132bc4bb839ef2763fa0b4b8
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/375359
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This is based off of the protocol in the stm32 directory. We should
unify these implementations and the other ccd endpoints at some point.
Right now I though that I should keep the implementation the same as the
other g chips ccd drivers.
BUG=chrome-os-partner:57059
BRANCH=none
CQ-DEPEND=CL:390015
TEST=manual
download the servo patch and run 'sudo servod -c ccd_cr50.xml -c
reef_r1_inas.xml'
Test the usb i2c bridge by running 'dut-control | grep pp'
Attach servo and verify cr50 will not enable i2c
Change-Id: I0f72671505f5451a960d3baea4b2c34b6910d892
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388896
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
In dead battery mode, we can find ANX7688 will pull the CC to Rp in the beginning;
some of the adapters will drop the VBUS since this should be treated as a
disconnection, hence the whole system lost the only power source and cannot boot up.
According to chrome-os-partner:58283, there's a chance for ANX7688 to be in an
abnormal state if the system provides it with 3.3V first but RESET_N and PWR_EN
are still in an unstable level. To prevent this situation, we try to enable the
3.3V only after RESET_N and PWR_EN are in their initial state.
BRANCH=none
BUG=chrome-os-partner:58283
TEST=plug in the adapter, check ANX7688 does not pull CC to Rp in the beginning,
and boot up system in dead battery mode
Change-Id: Ibb81a33a7dd957d3bdc6c54bb7723cc9ffdcfd26
Signed-off-by: Milton Chiang <milton.chiang@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/394408
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Doing a hard reboot after a usb spi transaction is overkill. This
changes the hard reboot to a EC reset so the AP, EC, and TPM will reset
without affecting ccd.
BUG=none
BRANCH=none
TEST=running 'sudo flashrom -p raiden_debug_spi:target=EC' doesn't
interfere with the cr50 console but resets the AP, EC, and TPM.
Change-Id: I15579c75deb837842585d1473de2182bede4ad96
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396919
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Cr50 no longer reboots when sys_rst_l is asserted so it is now safe for
cr50 to react to sys_rst when we assert it. This change removes the
is_sys_rst_asserted check before TPM reset.
BUG=none
BRANCH=none
TEST='sysrst pulse' causes the tpm to reset.
Change-Id: I8dd5ae85fc3ca839af20b7e67ef081cbb118b068
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396616
Reviewed-by: Scott Collyer <scollyer@chromium.org>
To be able to identify different cr50 devices connected to the same
machine we need a serial number. This change uses dev id 0 and 1 to come
up with one.
BUG=chrome-os-partner:56641
BUG=chrome-os-partner:58342
BRANCH=none
TEST=lsusb -vd 18d1:5014 | grep iSerial shows different numbers for
different devices. Verify when ccd is disabled the serial number is 0.
Change-Id: I85c54af4a21bdfd0542019c02aa8420d9a879fae
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395633
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add the production endorsement CA public key to
the endorsement certificate validation flow.
This change retains recognition of the test
endorsement CA public key as well, and either
issuer is accepted as valid.
BRANCH=none
BUG=none
TEST=build succeeds
Change-Id: I2666fdfb19ce8c950ef1a9190bc7b994a105132c
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/396554
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Endorsement registration is done with 0 for FWR keyladder branch.
The certificate packet has hmac with key derived from keyladder.
Thus RW can check that the certificate packet it is about to load does
indeed match its current keyladder status. If not, reject.
BUG=none
BRANCH=none
TEST=launch RW that has 1 for FWR and observe fail; 0 for FWR RW succeeds.
Change-Id: I820892a54fbf9aa52a6f778595b5b7ef4389cff3
Reviewed-on: https://chromium-review.googlesource.com/393233
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Commit-Queue: Marius Schilder <mschilder@chromium.org>
This change adds options to the powerbtn console command to press and
release the power button.
BUG=chrome-os-partner:58123
BRANCH=none
TEST=manual
'powerbtn press' force a power button press
'powerbtn release' release the power button. This will not
override the signal if the button is physically pressed.
Change-Id: I52631d30dbae874ba6637f728cb6e435cb626e12
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396207
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On both Reef and Gru there are INA (shunt bus voltage monitor) ICs
connected to the Cr50 I2C master bus. The use case for these chips is
in a lab setting using case closed debugging. Power to the INA chips
is controlled by a separate Cr50 gpio signal.
By default, the INAs are powered off and the I2C master bus is not
connected. A function ina_connect() is provided which needs to be
called prior to attempting to access the INAs via I2C.
BRANCH=none
BUG=chrome-os-partner:57059
TEST=manual
Tested both Reef and Gru. Verified that console command 'ccd ina
on|off' works as expected and that can repeatedly read registers on
the INA using the following command "i2cxfer r16 0 0x40 0".
Read 0x2771 [10097] which is the default value. In addition
wrote register 14 (bits 15:1 are writeable) and verified the value was
able to read the value back which was written.
Change-Id: I670f7897555dae29642264531599dc4471c52bbd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394168
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This command will be used to perform power validation.
BUG=none
BRANCH=none
TEST=ectool backlight command can be used to enable/disable Display
Backlight while system is in S0 state.
Change-Id: Ic61aa4cf5beadc83ea9dd38bb11cf10c53d4c20e
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/393007
Reviewed-by: Shawn N <shawnn@chromium.org>
When the kernel reads sensor data via LPC, it expects the order to be:
- ACCEL
- ACCEL
- GYRO
(other sensors data are read through EC commands)
BMI160 expects ACCEL, GYRO and MAG to be next to each other.
Reorganize motion_sensor array to fit these 2 requirements:
If BMI160 in the lid:
- BASE_ACCEL
- LID_ACCEL
- LID_GYRO
...
If BMI160 in the base:
- LID_ACCEL
- BASE_ACCEL
- BASE_GRYO
...
BUG=none
BRANCH=amenia,reef,wheatley
TEST=On reef, check the sensor data pull directly by the AP (for chrome
for lid angle) is correct. Check ARC++ works are expected.
Change-Id: If9477be0de44472e38a057c0b8533cb54acee220
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394751
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
While USB updates have a mechanism to trigger the target reset, SPI
updates do not have it.
This patch adds an extension command to cause the device reset.
BRANCH=none
BUG=chrome-os-partner:58226
TEST=with the rest of the patches applied verified that the system
gets reset and the new image version kicks in on both gru (over
SPI) and reef (over USB).
Change-Id: I498538670e2c43d17b13510288eb9ae75eb7b761
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395628
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Usually CR50 TPM reset happens when the AP reboots, the CR50 RO does
not get a chance to run in this case, so the running RW does not
change either,
Once the idle RW section was updated, the only way to start it is to
reboot the CR50 completely, Rebooting CR50 causes the whole system
reset, so it should not be happening at random moments in time.
This patch introduces a mechanism to delay reboot to the moment when
the TPM is reset. The reboot request would be posted in the end of the
update, and then the AP would reboot, triggering a TPM reboot, which
in turn would trigger the CR50 reset.
The USB update handler now posts the reboot request instead of
triggering the reboot immediately.
BRANCH=none
BUG=chrome-os-partner:58226
TEST=with the rest of the patches applied verified that the system
gets reset and the new image version kicks in on both gru (over
SPI) and reef (over USB).
Change-Id: Iff859f2e7a48c5035a27fffd17aefe7e318af569
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395627
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Interrupt test checks whether DUT can be interrupted by an interrupt
and an interrupt handler can be invoked as expected.
Note the previous interrupt test ported from test/interrupt.c runs in
an emulated environment on the host, thus does not test the real
interrupt capability of the chip.
BUG=chromium:653195
BRANCH=none
TEST=Run cts.py -m interrupt
Change-Id: I21cecff07594f048633d1c1b699fb3a1876379e0
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363943
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The current implementation of the ecrst and sysrst commands don't
have a way to show the state of the EC_RST_L and SYS_RST_L.
This tweaks the commands to accept an optional "pulse" argument
in addition to the boolean arg, which will assert, pause, then
deassert the relevant signal. With no args at all, the current
signal state is shown.
BUG=chrome-os-partner:58123
BUG=chrome-os-partner:56835
BRANCH=none
TEST=manual
sysrst pulse resets the AP
sysrst on/off asserts/deasserts SYS_RST_L
sysrst displays the current SYS_RST_L state
ecrst pulse resets the EC (and AP)
ecrst on/off asserts/deasserts EC_RST_L
ecrst displays the current EC_RST_L state
Change-Id: I8e1c9a577afd9ed9e770f1b3f5c0a69e4607de66
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395587
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Make sure that ioexpander is set to output,
and that the uservo usb power enable is set.
BUG=chromium:651860
TEST=check that servo micro is initialized properly
BRANCH=None
Change-Id: Iff994c63cd333933d51db38202a41b7b6fc86d66
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395186
Reviewed-by: Kevin Cheng <kevcheng@chromium.org>
The EC firmware already has a default sysinfo command, but it's
not relevant for Cr50 and is disabled. This CL adds a sysinfo
command that IS relevant to the Cr50.
BUG=none
BRANCH=none
TEST=make buildall; try on Gru
> sysinfo
Reset flags: 0x00000800 (hard)
Chip: g cr50 B2
RO keyid: 0x3716ee6b
RW keyid: 0xb93d6539
DEV_ID: 0x017a30b0 0x04656742
>
Change-Id: I251f86c1192aee373f1399ea4146ad355c592861
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395567
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The sysjump capability is not used in Cr50 (it either does
nothing or causes a hard reboot), so just disable these commands.
BUG=none
BRANCH=none
TEST=make buildall; test on Gru
Build with and without CR50_DEV=1, confirm that these commands
aren't present.
Change-Id: Idf882f10a2f750ac0d04cb3d35bb1d6f45cb6cee
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395566
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change adds apreset, ecreset, ec_rst, sys_rst and powerbtn options
to the ccd console command.
BUG=chrome-os-partner:58123
BUG=chrome-os-partner:56835
BRANCH=none
TEST=manual
sysrst resets the AP
sysrst on/off controls SYS_RST_L
ecrst resets the ec
ecrst on/off controls EC_RST_L
powerbtn 500 will simulate a power button press for 500 ms
Change-Id: I89adc88eb407730c9d57811a07bfef8fcf63c5b9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/393809
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=none (similar to chrome-os-partner:56765, though)
BRANCH=none
TEST=flashrom's "--flash-name" shows SPI chip info instead of EC info
on reef
Change-Id: I1090dd5d4079ff94201fce9fd3e03a384eb3cb7b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392349
Reviewed-by: Shawn N <shawnn@chromium.org>
- changed the pad assignment for plt_rst_l from DIOA13 to DIOM3;
- removed the board property used to keep uart rx disabled, Uart0 is
now enabled by default on Cr50.
- removed resetting fallback counter on USB updates for reef boards,
they are going to use the same mechanism as kevin and gru.
BRANCH=none
BUG=chrome-os-partner:56540
TEST=Tested on Reef Board ID 1 and Gru Board ID 1. Verfied that
plt_rst_l signal is being detected and that there are no
interrupt storms related to not having a pullup resistor on the
uart rx line. Verified that both platforms successfully boot into
chrome OS using cr50 TPM.
Change-Id: I300a0c75e60acbecf93500b46aced303955a192a
Signed-off-by: Scott <scollyer@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391140
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes some console commands that shouldn't be present in
production builds, even when the console is unlocked.
BUG=chrome-os-partner:57408
BRANCH=none
CQ-DEPEND=CL:391045
CQ-DEPEND=CL:391188
CQ-DEPEND=CL:391244
CQ-DEPEND=CL:391314
CQ-DEPEND=CL:391611
CQ-DEPEND=CL:391612
CQ-DEPEND=CL:391613
CQ-DEPEND=CL:391614
CQ-DEPEND=CL:391127
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ic5034a87ba032b14a7e613e6debdbb635a7c1c9a
Reviewed-on: https://chromium-review.googlesource.com/391046
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The application may need to read/write/erase the flash memory,
but we not want console users to do so. This CL adds
CONFIG_FLASH_PHYSICAL, which allows the higher-level CONFIG_FLASH
to be undefined while still providing the chip-specific
flash_physical_* accessor functions.
There aren't many board.h files that needed changes, since
CONFIG_FLASH_PHYSICAL is enabled by default, just like CONFIG_FLASH.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
See that it still boots, updates, wipes, restores, etc. without
linking common/flash.o in the production image; and that the
flash commands are still there in the dev build.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7eb1bbcb414b1c70ee427c4fcb5cea899dbb9e93
Reviewed-on: https://chromium-review.googlesource.com/391188
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Some Type-C to DP adapters generate two or more HPD events while
others generate only one HPD event. Currently hotplugging only
works with the former adapter. Now hotplugging is triggered on
one or more HPD events.
BUG=chrome-os-partner:57198
BRANCH=none
TEST=Manuel
- plug USBC->DP cable into TV then into kevin
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- plug USBC->DP cable into kevin then into TV
localhost ~ # ectool usbpdmuxinfo
Port 0: DP INV
- unplug USBC->DP cable from TV
Port 0: OPEN INV
Change-Id: Ied30f1eb3e1186b52067ffc9a37ed22a9012b457
Reviewed-on: https://chromium-review.googlesource.com/388737
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388531
Commit-Ready: Shawn N <shawnn@chromium.org>
There is no point in invoking TPM reset while the current invocation
is in progress. One of the cases when this is happening is early start
up on Kevin/Gru: the device starts booting, the EC comes around to
pulsing sys_rst_l when TPM is already busy installing endorsement
certificates.
There is no point in issuing another reset at that point, just let the
process continue.
BRANCH=none
BUG=chrome-os-partner:52366
TEST=firmware_TPMKernelVersion firmware_TPMExtend autotests still pass
on kevin. Certificate installation during startup does not get
interrupted any more.
Change-Id: Ibdface9f7a76186e210ef0f4111cd5fe9905bba9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389811
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Similar to the TPM SPI interface, added code to disable sleep an I2CS
interrupt is received. Enabling sleep follwoing a 1 second delay when
the TPM fifo register has been read by the host. The I2CS TPM layer
doesn't know when a command has finished, but the one second delay is
more than enough delay since sleep will be disabled again when the
next I2CS interrupt is received.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Tested without these changes first. Shortened sleep delay to 30
seconds, and disconnected suzyq. Waited 30 seconds then issued the
command on the AP console:
tpmc read 0x1007 0xa
[ 59.796813] tpm tpm0: tpm_transmit: tpm_send: error -16
ERROR: write failure to TPM device: Device or resource busy
In addition, using logic analyzer verifed that there was activity on
SDA/SCL but no response from Cr50. With this CL in place, ran the
test and got the following:
tpmc read 0x1007 0xa
2 0 1 0 1 0 0 0 0 4f
With the logic analyzer I was able to confirm that there was no
activity from the host on the I2CS bus until the command was issued.
Change-Id: If07573ae8f72b983bca57979d53c22660b91b95e
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387910
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This locks the Cr50 console by default, and makes the unlock
process take the full 5 minutes unless the battery is removed.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; test on Gru & Reef
Build the image with
make buildall
or
make BOARD=cr50
Put it on Gru & Reef, and confirm that the console is locked, by
running "lock" or "help". Try to unlock it with "lock off" and
observe that you have to poke the power button for five minutes
before it unlocks.
Remove the battery and confirm that "lock off" now only requires
a single power button press to take effect.
Build the image with
CR50_DEV=1 make BOARD=cr50
and now the behavior is back to the way it was before this CL.
Change-Id: I9f2cc67a1dd63f260221a8711a8591070018be3b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389238
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The assumption is that removing the cover and disconnecting the
battery is sufficiently obvious and time-consuming that it's not
necessary to sit there poking the power button repeatedly.
We still erase the NVMEM completely before unlocking, of course.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall; test on Gru
Toggle the Cr50 console with "lock on", then "lock off". Confirm
that the 5-minute process only requires one poke when the battery
cable is disconnected. Also confirm that both ways abort if you don't
press the button at all.
Change-Id: Iaa0f5eb102b914c95f3a34002438cbe80affcfb5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388879
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The Cr50 console provides access to all sorts of dangerous
commands. To protect user secrets, we must erase the persistent
storage before unlocking the console.
Note that this will not powerwash the AP, leaving you with the
impression that you've just forgotten your password. You'll have
to manually powerwash (Ctrl+Alt+Shift+R) afterwards. That will be
addressed in a future CL.
BUG=chrome-os-partner:55728
BRANCH=none
TEST=make buildall, test on Gru
Lock the console if it's not already ("lock enable"), then unlock
it with "lock disable". Confirm that the NVMEM region is erased
following a successful unlock process.
Change-Id: Iebcd69c9f757f5ab5d496218f065197d3f1f746c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382666
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just a variable & comment renaming. No functional changes.
BUG=none
BRANCH=none
TEST=make buildall; test on Gru
At the console, try "lock on", "lock off". It works the same.
Change-Id: I65381d5550f68855be8d7961abbaa117dc97184b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/389237
Reviewed-by: Randall Spangler <rspangler@chromium.org>
To reset the TPM task, we send it an event so that it will reset
only when it's not busy doing actual TPM stuff that might fiddle
with the stack or shared memory. But that means that we can't
always know when the task finally gets around to resetting
itself.
This CL adds a tpm_reset() function that blocks until the reset
actually occurs. Obviously it can't do that if it's being called
in interrupt context or from the TPM task itself, but otherwise
it does.
BUG=chrome-os-partner:52366
BRANCH=none
CQ-DEPEND=CL:361680
TEST=make buildall, test on Gru, manual tests
In addition to the normal rebooting, logging in/out, and so
forth. I added a temporary console command to call tpm_reset()
and scattered a bunch of ccprintfs around it. When called due to
SYS_RST_L, it didn't block. When invoked with the console
command, it did.
Change-Id: I51e8b1299dbdcd1a12273cf48a890e93ed32a8c8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rather than doing a full cr50 reset when the system reset SYS_RST_L is
asserted, just reset the state of the TPM task and library. Re-clear
.bss for those modules, then re-initialize.
BRANCH=none
BUG=chrome-os-partner:52366
CQ-DEPEND=CL:366792
TEST=make buildall; test on Gru
Trigger a SYS_RST_L by using the AP's reboot command, power
off/on, log in/out/in.
See that the Cr50 does not reboot and the firmware and userspace
are still happy about the TPM.
Change-Id: I32cd2bb72316f68c74db77a20a8d09112b402d4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361680
This command will be used to perform power validation.
BUG=none
BRANCH=none
TEST=ectool extpwrlimit command can be used to set the max voltage/current
drawn from external charger.
Change-Id: Ic258954c1e3a714be7f648e77234dab594227ce0
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/388843
Reviewed-by: Shawn N <shawnn@chromium.org>
Use the FW reset register rather than the physical reset pin for
bd99955 power-on reset to avoid bad side effects during reset.
BUG=chrome-os-partner:57671
BRANCH=Kevin
TEST=Manual on kevin, do EC cold reset w/ 15V attached to port 0,
peripheral attached to port 1. Verify port 1 stays at <= 5V.
Change-Id: If90d754bf6256a50901132de0b2ccde69aec2ebe
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388757
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 80291c05a6e96d0042969980ab09b2549cb44a75)
Reviewed-on: https://chromium-review.googlesource.com/388748
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
INT_AP_L is used as a sync trigger to the host during i2cs
transactions. This signal is nominally set high and pulled up to
1.8V. However, when the AP is off, this line won't be pulled up which
would lead to excessive power draw by the Cr50 if this signal remains
driven high.
Added a change to set this signal as an input while the AP is powered
off. When the AP powers back up, it's changed back to an input and
driven high which is the default level.
BRANCH=none
BUG=chrome-os-partner:57733
TEST=manual
Change-Id: I12f175a7899eff6b90acb5a82282e526db3c1b9f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388799
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Added i2ctest console command to test the reliability of the I2C.
By reading/writing to the known registers this tests provides the
number of successful read and writes.
BUG=chrome-os-partner:57487
TEST=Enabled the i2ctest config on Reef and tested the
i2c read/writes.
BRANCH=none
Change-Id: I9e27ff96f2b85422933bc590d112a083990e2dfb
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/290427
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>
The AP UART is used to detect if the device is in s0. When it is cr50
should not be in deep sleep for any reason. This change makes DIOA5 a
wake pin before entering deep sleep.
BUG=chrome-os-partner:56100
BRANCH=none
TEST=make buildall
Change-Id: Icb57824c0ca1421f5f508fce7cf5609010b91e32
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388793
Reviewed-by: Scott Collyer <scollyer@chromium.org>
For TPM operation with Intel chipset APs, the signal PLT_RST_L needs
to trigger a TPM reset. For current Reef boards, this signal is
connected to DIOA13. The next version will have it on DIOM3.
This CL adds support for platform reset connected on DIOA13 and uses a
new board property so that it doesn't affect Kevin/Gru.
BRANCH=none
BUG=chrome-os-partner:55115
TEST=manual
Used H1 dev board configured as Reef. Created high to low transisition
on to verify that platform reset was detected. Tested on Kevin to
ensure that resets were not occurring.
Change-Id: I58f02b7ffa644a9197f4303ae6e640df181040bd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380336
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
