Currently the led blinks once sec every 2 secs. But
as per the hardware reuqirements it should be one sec every 4
secs.
BRANCH=none
BUG=chrome-os-partner:62655
TEST=Enter s0ix, s3 manually and make sure it blinks once
every 4 secs.
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@google.com>
Change-Id: I3ade6c5789c172c66dfb022cd12439752d96addc
Reviewed-on: https://chromium-review.googlesource.com/437601
Commit-Ready: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Tested-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since the INAs are now enabled based on rdd_attach, there is no need
to have a a delay following enabling the 3.3V rail and the delay can't
be a usleep() because ina_connect() is not being called from
rdd_attach which is running in an interrupt context.
BUG=chrome-os-partner:62375
BRANCH=none
TEST=manual The usleep() call was causing a reboot but was only
visible when using UART console. Verified that with this CL the reboot
was no longer happening.
Change-Id: Id9bbef4e89dee39a2dfa443c3af54c1f9a611ebd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438675
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
There is no point in keeping in one file multiple hooks task callbacks
to handle chipset shutdown and resume conditions.
Also, the policy of disabling deep sleep needs to be decided in the
board level hooks.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=ran reef through 200 cycles of suspend/resume
Change-Id: I4d30cd04b986b243a5bea44c6978a5f82f8f62a7
Reviewed-on: https://chromium-review.googlesource.com/437729
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
The cr50 needs to be aware of the power state of the system and of the
moment when the AP is reset, because this is when the TPM needs to be
reset too.
Arm and x86 platforms provide different hints in these cases.
In case of x86 there is a single signal cr50 can rely on: PLT_RST_L.
This active low signal is asserted when the system is going into any
power state deeper than s0ix. The cr50 can fall into deep sleep when
PLT_RST_L is asserted, and has to wake up and reset the TPM when this
signal is deasserted. There could be other wake triggers, but the tpm
should not be reset unless PLT_RST_L is inactive. It is also important
not to fall into deep sleep when PLT_RST_L is pulsed to reboot the
system.
In case of ARM there are two separate signals. Deasserting SYS_RST_L
signal is the trigger to reset the TPM, The GPIO_DETECT_AP going low
for a duration of time is the indication of the AP going into some
kind of sleep mode. The ARM case requires more clarification.
This adds run time configuration of the the sleep state control input.
Once the input turns low, the CHIPSET_SHUTDOWN signal is sent and deep
sleep mode is enabled. Again, this will require adjustment for ARM
platforms.
The wake from deep sleep state is controlled by the wake pins as
before, but by level instead of edge. This makes sure that in case the
trigger for deep sleep goes away while deep sleep preparation is under
way, the device resumes immediately instead of getting stuck missing
the edge.
The TPM_RST_ input is now triggering interrupts on deassertion
- this is the moment when the TPM needs to be reset. The ISR is being
renamed accordingly.
The processing previously happening inside the ISR is being moved into
a deferred function running on the hooks task context.
There is no need to invoke TPM reset related functions from the PMU
wake up ISR anymore.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=as follows:
1. make buildall -j succeeds
2. started on Reef, still in progress after 100 iterations, early to
call
suspend_stress_test --suspend_min 40 --suspend_max 45 \
--wake_max 15 wake_min 10
(note that reef does not fall into s3 any more, so the test does not
verify H1 deep sleep)
3. modified the target to fall into s3 during the test and
successfully repeated it for 100 iterations
4. tried battery disconnect a few times and observe successful boot.
Change-Id: Ica06ec0d363b53eede3be327404ff5807fa3a610
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436865
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Being able to determine what sleep state the system is in is very
handy, and reading the state is pretty safe.
Let's declare the idle console command safe and disallow its
parameters when console is locked.
BRANCH=none
BUG=none
TEST=verified that it is possible to read the idle state when console
is locked, but not possible to set it.
Change-Id: I97f680bf033290220a4fa7fd5a7af170736443d8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436905
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The lid and base matrix were wrong, chrome would enter tablet mode while
in clamshell mode.
Sensors are powered in S3 and S5.
Enable lid angle to disable keyboard while in tent mode.
Disable Trackpad in S5, but just block the interrupt while in tablet
mode and not in S0.
Allow reporting tablet switch mode to AP via ACPI event.
BUG=chrome-os-partner:62385
BRANCH=eve
TEST=When device is laying on a table, lid angle at 180, both sensors
report gravity along Z axis:
ectool motionsense
Motion sensing active
Sensor 0: 368 -368 16752
Sensor 1: 828 -820 16293
When on the base bottom edge, report gravity along Y axis:
ectool motionsense
Motion sensing active
Sensor 0: 256 16160 -976
Sensor 1: 993 16362 -391
Sensor 2: 0 0 0
Sensor 3: 0 0 0
When on its left side, report gravity along X axis:
ectool motionsense
Motion sensing active
Sensor 0: 15968 368 1920
Sensor 1: 16503 219 2430
Sensor 2: 0 0 0
Sensor 3: 0 0 0
Power down machine. Power back up. Check sensors are still working.
Check we can not resume machine while in tent mode from keyboard.
Resuming from trackpad does not work yet.
Change-Id: I4ee6efc57f217d76e5eb97683efa56ceb211cad8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437906
Reviewed-by: Alexandru Stan <amstan@chromium.org>
All boards have been transitioned to charge_state_v2.c
So charge_state_v1.c, HOOK_CHARGE_STATE_CHANGE, and
CONFIG_CHARGER_TIMEOUT_HOURS can be removed
BUG=chrome-os-partner:36272
TEST=make -j buildall
BRANCH=none
Change-Id: I3f20c5198ea75185f9894deb792575a1be31432a
Reviewed-on: https://chromium-review.googlesource.com/435467
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The INAs are only used for development and testing
purposes. Therefore, the 3.3V rail to the INAs is off by default and
the I2Cm module is not enabled. Enabling INA power and connecting the
I2Cm module was done at the beginning of each USB to I2C request. The
problem with this approach is that INA measurments didn't always
succeed due to not enough time for the INAs to initialize.
Rather than add some arbitrary delay, it is better to tie the INAs to
when rdd is attached/detached. It is only when rdd is attached that
the INAs will be accessed, so there is no need to enable/disable for
each individual I2C transaction.
This CL ties the enabling/disabling of the INA and I2Cm module to the
rdd state. This change makes the previous use of
usb_i2c_board_enable() and usb_i2c_board_disable() obslete.
BRANCH=none
BUG=chrome-os-partner:62375
TEST=manual
Connect servo with suzyq connected:
sudo servod -p 0x5014 -b eve -c eve_r0_inas.xml
Then execute single INA reads dut-control pp3300_dx_edp_mv and verify
that it returns meaningful numbers. Without this CL single reads via
dut-control would always return 0.
Change-Id: I799552bfd0701efd1828a0d720ac2a6cedee5ca1
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436864
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The nvmem_release_cache() function checks if there is a pending write
and refuses to release the lock if so. It should also be checking if
submits have need suspended, as the task suspending commits is holding
the lock and is supposed to release it explicitly when done.
BRANCH=none
BUG=chrome-os-partner:62531
TEST=verified that the message reporting attempts to commit when cache
is unlocked is not showing up at startup any more,
Change-Id: I5a63e7421cdd4a6b11dddff3103e1d63e0be0e65
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437758
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This patch makes it clear what state each of the straps is in, the
information is printed on the console at startup time.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=tried the new code on the dev board, observed the following in
the console output at startup:
strap pin readings: a1:3 a9:1 a6:1 a12:3
which is consistent with expectations give the dev board
schematics and mode of operation.
Change-Id: Ie7b2511e0da84b8c9e3462d3f88365e6f2227bfe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434938
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The timerinfo command shows the number of microseconds since boot,
expressed as a hexadecimal value. Some of us are not as good in
converting hexadecimal seconds value into decimal number of seconds
and microseconds. This patch adds the decimal value to the output.
BRANCH=none
BUG=none
TEST=verified that timerinfo output makes sense:
> time
Time: 0x000000000b66d280 us, 191.287936 s
...
> time
Time: 0x000000000caec680 us, 212.780672 s
Change-Id: I3bd4ba16f3cfb74ba8fcec4899fbff0ab259007c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Eve has two charge LEDs. This CL adds support to set a given color for
either left, right, or both LEDs. In addition, the LED policy for Eve
has been enhanced to accommodate separate charge LEDs.
Added amber and white color option plus console command 'led' can
choose the left/right side by adding 0|1 after the color.
S0: Default both LEDs are blue. If charger is connected, then the
active charging port's LED will be amber or green based on battery
level.
S3: If not charging, then both LEDs are blinking white. If charging
then follow same policy as S5.
S5: If not charging, then both LEDs are off. If charging then follow
previous policy, but applied only to the charging port's LED. The port
that isn't actively charging will have its LED off.
BRANCH=none
BUG=chrome-os-partner:60797
TEST=manual Verified the LEDs follow the operation as defined above.
Change-Id: I6f91d8a28999360aa620c7178d48c41625a1fa54
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437404
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
The output of pinmux command is garbled (it probably was OK until the
console UART TX buffer was significantly reduced in size by
https://chromium-review.googlesource.com/418948).
Let's flush the console every so often.
Also, fixed the bug where the second GPIO port base address in PIMUX
was off, and added a newline to separate UART section of the output.
BRANCH=none
BUG=none
TEST=ran pinmux command successfully. make -j buildall passes
Change-Id: Iae0dcbbd0a55d704ffe2296d6e0e81b2c6aec527
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436765
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
During shutdown sequence sensor rails can be powered down asynchronously
to the EC hence EC cannot interlock the sensor states with the power down
states. To avoid this issue, defer switching the sensors rate with a
configurable delay if in S3. By the time deferred function is serviced,
if the chipset is in S5 we can back out from switching the sensor rate.
BUG=chrome-os-partner:61489
BRANCH=none
TEST=Manually tested on Electro. Put the device in S5 and observed
no I2C errors printed on EC the console.
Change-Id: I40b75ebbf0d05fafffdfd535962423c3960fafbf
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/433338
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
charge_ramp needs to make a decision based upon the VBUS level on one
specific port - the port that is ramping. The VBUS level on any other
charge ports (if present) is not relevant.
BUG=chrome-os-partner:54099
BRANCH=reef, gru
TEST=With subsequent patches, verify charge_ramp success with a variety
of BC1.2 chargers.
Change-Id: Ie0a51a577e2b7491222560cd08dd5321ff3b7975
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/435561
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: Shawn N <shawnn@chromium.org>
The commit changes the behaviour to block accesses over the USB-SPI
bridge while the console is restricted.
BUG=chrome-os-partner:62340
BRANCH=None
TEST=Build and flash cr50 on snappy; lock console; try to flash EC bin
using CCD. Verify that it fails with flashrom not able to find a flash
chip.
TEST=Disable console lock; Try to flash EC bin; verify it succeeds.
TEST=Repeat above tests but trying to read AP flash instead.
TEST=make -j buildall
Change-Id: Ib69af1a7372d841783acee2262efbf995d031234
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/435437
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Previously, and invalid strap configuraiton was not updating the copy
in the long life register. Since we don't expect to have invalid strap
pins, but if they are read, it's not expected to change run to
run. Therefore, to have consistent behavior, store the properties
determined in the long life register in all cases.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=manual
Tested with Reef/Gru which both have valid table entries and verified
that board properties were being saved in the long life
register. Tested on Eve which has currently an invalid strap config
and repeated the test.
Change-Id: I3a018db0e3a88ad33a85125a892b74b44593d5df
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436004
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
During TPM I2CS stress testing as described in chrome-os-partner:59191
there were instances of write mismatch errors. Previously, there was a
CPRINTF for this condition. The CPRINTF being in the i2cs ISR then
affects any subsequent i2cs activity and can create a cascade of
errors.
To avoid this issue, added a counter to track these instances and made
it to be retrieved similar to the fifo adjust counter.
BRANCH=none
BUG=chrome-os-partner:57338,chrome-os-partner:59191
TEST=manual
Ran the stress test as described in chrome-os-partner:59191 and found
that when the write mismatch occurred the counter ticked up by 2 where
before there would be numerous console log prints of the same error.
Change-Id: I2837d02037e2f47b5bd4b001d3394ad6eb4bd92c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410032
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Setting the VSYSREG_SET register as per Charge State Machine of
the BD9995X datasheet.
1. Set VSYSREG_SET <= VBAT so that the charger is in Fast-Charge
state when charging.
2. Set VSYSREG_SET > VBAT so that the charger is in Pre-Charge
state when not charging or discharging.
BUG=chrome-os-partner:55220
BRANCH=none
TEST=Manually tested on Reef. Observed 'Charger State Machine Status'
register value when charging it is in Fast-Charge state and
when not charging/discharging it is in Pre-Charge state.
Change-Id: I5cd5afa92384acb4fd9d69128a2a03ae6992dc5b
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/430880
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>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Values should be as follows:
tTypeCSinkWaitCap: 310 to 620ms
tPSHardReset: 25 to 35ms
Current values are:
tTypeCSinkWaitCap (PD_T_SINK_WAIT_CAP): 240ms
tPSHardReset (PD_T_PS_HARD_RESET): 15ms
BUG=chromium:686122
TEST=manual testing on kevin along with make -j buildall
- used a kevin to send a hard reset to uut
> pd 0 hard
C0 st36
C0 st37
34725 ms <-- time it took hard reset to execute
C0 HARD RST TX
- used a kevin, operating as source, that does not send
source caps to test a uut operating as a sink.
C0 st6
C0 st36
613266 ms <-- time sink waited for source cap
- plugged in charger and logged pd negotiation
[1510.574091 event set 0x00200000]
C0 st15
C0 st3
[1510.845115 event set 0x08000000]
C0 st6
Req C0 [1] 5000mV 3000mA
[1510.945827 New chg p0]
C0 st7
[1510.949953 CL: pC0 st8
0 s0 i500 v15000]
[1510.954055 event set 0x00200000]
[C0 st9
1511.061285 event set 0x00400000]
[1511.064752 CL: p0 s0 i3000 v5000]
[Req C0 [3] 15000mV 3000mA
1511.067538 event set 0x00200000]
C0 st7
C0 st8
[1511.077896 CL: p0 s0 i500 v5000]
[1511.079048 event set 0x00200000]
C0 st9
[1511.275448 CL: p0 s0 i3000 v15000]
[1511.276913 event set 0x00200000]
Req C0 [3] 15000mV 3000mA
[1511.445719 CL: p0 s0 i500 v15000]
[1511.446117 event set 0x00200000]
C0 st7
C0 st8
C0 st9
[1511.565730 CL: p0 s0 i3000 v15000]
[1511.566566 event set 0x00200000]
[1511.812205 event set 0x00400000]
[1513.274941 event set 0x00200000]
[1529.324670 Battery 90% / 0h:29 to full]
BRANCH=none
Change-Id: I6e80637cfc50dcfc431feb0e473ec22f408d6f1a
Reviewed-on: https://chromium-review.googlesource.com/434103
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Defined the config option CONFIG_USB_PD_DTS to board.h.
- Added ccd_set_mode function in board.c
- Removed ccd attach/detach functions from board.c as that function is
- now integrated in the the usb_pd state machine.
- Removed the fixed polarity that was being used in usb_pd_config.h so
that the DUT port could connect as a SNK device.
- Defined PD_ROLE_DEFAULT to override the value in usb_Pd.h so that
CHG is SNK and DUT is SRC
This set of changes allows servo_v4 to act like a suzyq. Hoever, PD
messaging is still not supported. The CHG port can still connect as a
SNK device, but VBUS on the DUT is only being provided by the host and
not the CHG port.
BUG=chrome-os-partner:61878
BRANCH=None
TEST=Manual Connected zinger to CHG port and verifed via servo_v4
console that it reached SNK_READY. Connected DUT port to Reef and
verified that it reached SRC_ACCESSORY state and that the correct SBU
polarity was selected and that lsusb shows H1 as a USB device.
Bus 003 Device 042: ID 18d1:5014 Google Inc.
Change-Id: I4a0ab2468f383a3ba4db3a3236bb18df6a2c405a
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428309
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The cipher command implementation had to change to account for reduced
heap size and to improve coverage.
Note that the goal of this command is not to verify correctness of the
encryption services provided by the dcrypto, but to allow to exercise
the crypto engine on multiple passes, each time using the same clear
text but different initialization vector.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=ran cipher command on a few devices:
> cip
Will wait up to 4074 ms
running 1000 iterations
blob size 7111 at 1e020
original data 8f3d99fbfcbd26dd0c4d8dc444d106ee
hashed data 826a4e9b04d214fbbd5fbf4e0fba8068
Encryption results: min 1128 us, max 1456 us, average 1180 us
Decryption results: min 1124 us, max 7348 us, average 1193 us
>
Change-Id: Idf72b355dce0f288d4a3d8a065bc08eb9c4f6bc3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434167
Reviewed-by: Nagendra Modadugu <ngm@google.com>
All host commands must be 4-digit uppercase hex digits.
EC_CMD_HOST_EVENT_GET_WAKE_MASK is currently defined as 0x008d
BUG=chrome-os-partner:62518
TEST=make -j buildall
100bcffc R __host_cmd_0x00000x0087
100bd008 R __host_cmd_0x00000x008C
100bd014 R __host_cmd_0x00000x008D
100bd020 R __host_cmd_0x00000x008F
100bd02c R __host_cmd_0x00000x0092
BRANCH=none
Change-Id: If2460efa7453e8007514b10dd9a973120006c7e1
Reviewed-on: https://chromium-review.googlesource.com/435581
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change explicitly sets the GPIO pin connected to the trackpad
IRQ gate low. The GPIO output registers are reset to zero.
So, this patch doesn't practically change anything.
BUG=chrome-os-partner:58792
BRANCH=none
TEST=Verified the value was 0 by gpioget command and the trackpad was
functional on a current Electro & a reworked Electro.
Change-Id: I52fec1efdd29453ee121cf1705242d877c0c4f1f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/427369
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch locks the ec.
This also locks PD communication until sysjump to RW.
We don't want to allow communication to outside world until
we jump to RW. This can by overridden with the removal of
the write protect screw to allow for easier testing.
Electro doesn't operate on 15w power normally but 15w is enough for
recovery process.
BUG=chrome-os-partner:62487,chrome-os-partner:61801
BRANCH=none
TEST=flash -p ec --wp-enable.
Boot, shutdown, suspend, resume, & charge Electro. Run recovery
process with battery 2% charged and a charger on port 0.
Change-Id: I634291c00eb471e24ed2b06444302d9e2e42bbc8
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/435005
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We wanted to reduce the number of interrupts that uart was producing so
we increased the number of characters needed in the fifos before it
would trigger an interrupt. Right now it needs 4 characters. If you
aren't printing a multiple of four characters, then not all text will be
printed.
This change changes the rxilvl back to 1. This will make using the
consoles and testing cr50 functionality more reliable.
BUG=chrome-os-partner:62158
BRANCH=none
TEST=login and boot still work fine. The AP and EC consoles print all
output correctly.
Change-Id: I2d48d02a275173d560c03e5363845a5afc94df7a
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434891
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Eve has two 3 color PWM controlled LEDs. This CL adds basic support
for these LEDs so that they can be set to off, red, green, or blue. In
addition, the LED policy from Kevin is appropriated.
In S0 the LEDs will be blue.
In S3/S5 if no charger is connected, then the LEDs are off
If a charger is connected and the charge level is less than a
threshold, both LEDs are set to red. When the charge level gets above
a certain level or if the charge state is idle, then the LEDs are set
to green.
BRANCH=none
BUG=chrome-os-partner:60797
TEST=manual
Turn the system on so it's in S0, verify both LEDs are blue.
Close the lid with no external charger and verify that the LEDs are
both off. Connect the charger, and using battfake <> EC command verify
that when the charge level is less than the threshold the LEDs are
red, otherwise they are green. Set battfake to 0, and verified
flashing red.
Change-Id: I556ccdafde03cd5f5205e8948d5737dcbdc09d6d
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434146
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
The current strap pin logic was checking for case of no pullup
resistors detected on either pair of strap pins, but did not check
explicitly for at least one pullup on each pair or strap pins. This
condition, which isn't expected, is an invalid configuration and
therefore can't be used to determine either SPI vs I2C or as a table
lookup entry.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=manual
Tested on Eve which has 4.7k pullup resistors to PP3300_A this rail is
not going down as expected. The result is that a pullup is read on
DIOA6 which is expected and strong pullups are read on
DIOA9|DIOA1. With this CL the strapping pin logic produces the
folloiwng output:
--- UART initialized after reboot ---
[Reset cause: hard]
[Image: RW_B, 0.0.14/DEV/cr50_v1.1.5933-18d527f
tpm2:v0.0.286-21er-linux.mtv.corp.go]
[0.004160 Inits done]
[0.005476 Invalid strap pins! default properties = 0x42]
Change-Id: Ibe85bc55d62b4c060b6c39629a225edc6d1dc341
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433146
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
For device that are using ceramic caps, when battery is full, discharge
to 97% and then charge again until the battery is full. This should also
help us meet CEC energy spec.
BUG=chrome-os-partner:56255
BRANCH=gru
TEST=Manual on kevin, insert charger with battery at 97%, verify battery
does charge until 100%, and then discharge down to 96% and verify battery
charges. Charge to 100% again.
Change-Id: I5099cbbb1228823cc611c456e7e3d8311f1c94d6
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/434220
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic8db5c706d82f7ca2ded2e90129747e7fbefdb38
Reviewed-on: https://chromium-review.googlesource.com/427959
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I49ea5fc27a7f11f66daba485a87d0dfe7d0c770f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/427408
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The previous implementation of DCRYPTO_app_cipher
consumed roughly 16ms to cipher a 16kB buffer
(i.e. performance that is far worse than the
hardware is capable of).
This change speeds up the implementation by about
85%, to the tune of roughly 2.2ms for a 16kB buffer.
The gains originate from various sources: loop
unrolling, data-pipelining, eliminating local
variables (to reduce register pressure), eliminating
support for unaligned input/output data, compiling
hot code with -O (rather the default -Os), and
using the hidden key-ladder, which need only be
setup once per reset.
This change also switches from AES-128 to AES-256.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall succeeds;
cipher command succeeds;
TCG tests pass
Change-Id: I133741be6d9f1353d6ae732d0e863b4b18cc8c9e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/433359
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This vendor command allows the host to retrieve the internal TPM
state. The first version of the command will return the failure
information collected during assert, if it ever happened, retry
counter value and the maximum retry counter value to be able to detect
if TPM is in lockout.
The structure is packed, it is serialized before being sent to the
host.
BRANCH=none
BUG=chrome-os-partner:60555
TEST=when running on a reef with a depthcharge image capable of
displaying TPM state on errors observed state information added
to the recovery screen text display.
Change-Id: I9d37f7a971013ce802f63218d43697fab68276c9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/430952
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Add support for verifying messages signed
with 4096-bit RSA keys. Such messages may
be generated by host side applications.
Also update tpmtest.py to test 4k verification.
BRANCH=none
BUG=none
TEST=added new tests to tpmtest.py; TCG tests pass
Change-Id: I7450bd710c154c68c030ce176bfe7becbfbcb729
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/428220
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>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
tpm_reset just requests a tpm reset it doesn't reset the tpm. Rename the
function to reflect that.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I6f4763b5de578a8cf263b2fac98fad3af2c25d65
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434245
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The nvdc voltage has a kind of deep, so that rarely observed
NVDC down at this point because of back-boosting.
Our sequence to enable charger bit and setting vsysreg
is correct but rohm introduce charger may need some more time
to be stable when between chg_en and vsys_set to start charge
BUG=chrome-os-partner:60380
BRANCH=gru
TEST=Manual on kevin, trigger battery disconnect, re-attach AC, verify
system boots cleanly. and see voltage probing on c54@60380
Change-Id: Ic05091379322ffaac16fe827a47345c76c85f3e5
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/434252
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
With introduction of encryption it is becoming impossible to read
NVMEM contents directly from flash. Decrypting the contents each time
there is a read request creates a significant performance hit. NVMEM
needs to be rearchitecture such that there is no need to run
decryption each time NVMEM read is performed.
This patch does just that, implementation details are described in the
header comment in common/nvmem.c.
To reduce memory impact the size of NVMEM is being decreased from 16K
to 12K. This is acceptable because eviction objects stored in NVMEM
serialized now, which dramatically reduces NVMEM size requirements.
The TPM2 NVMEM size definition must be kept in sync.
Another optimization this change introduces is bypassing writing into
the flash if NVMEM contents did not change, which is verified by
examining the hash of the cached storage.
A test is added to verify that the new commit scheme works as
expected, and the nvmem test is re-introduced to the list of test ran
on each 'make buildall'.
CQ-DEPEND=CL:433839
BRANCH=none
BUG=chrome-os-partner:62260,chrome-os-partner:62421
BUG=chrome-os-partner:62437
TEST=ran the following tests, all succeeded
make buildall -j
TEST_LIST_HOST=nvmem make runtests
tcg test suite
corp enroll on reef, reboot a few times, verify that enrollment sticks
Change-Id: I177daa3ceb4fd7aac299ca26b4506b863e31b946
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
