Electro is able to boot on 15w to Depthcharge but requires 18w or above
to boot to the logon screen. This patch allows 15w charger to boot
Electro to Depthcharge (as before) but prevents it from booting after
that unless the EC in RW negotiates with the charger and gets 18w or
more.
Without the patch:
1. Boot without battery
2. EC sysjumps to RW
3.a. With 18w charger, Depthcharge proceeds to boot
b. With 15w charger, Depthcharge proceeds then browns out
4. Boot without battery
5. Reboot by FSP for RTC well drop
6. Charger goes to disabled state
7. EC fails to negotiate with charger, hard resets charger
8. Brownout
9. Repeat from #4
With the patch:
1. Boot without battery
2. EC sysjumps to RW
3.a. With 18w charger, Depthcharge proceeds to boot
b. With 15w charger, Depthcharge times out and shuts down the system
So, the outcome is same. With the patch, the user at least is (or will
be) given a chance to know battery is the problem. I suppose we have to
add a screen showing battery is drained or dead. I currently see no
such code in vboot_select_and_load_kernel.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=chrome-os-partner:61801
BRANCH=none
TEST=Hack the code to enforce syslock. Disconnect battery.
Use 18w charger to boot the system. Use 15w charger not to boot.
Change-Id: I00d79a96221f1d3b8c6d529de9b8e4588d6112aa
Reviewed-on: https://chromium-review.googlesource.com/440390
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Current fast charge assumes only one battery voltage threshold range for
charger profile override. However we have multiple battery voltage
threshold ranges for few batteries hence added a code which can consider
multiple battery threshold ranges and choose respective charge profile.
BUG=chrome-os-partner:62653
BRANCH=none
TEST=Manually tested on Electro. Manipulate smp_cos4870 & sonycorp
battery voltage & temperature ranges and observed correct charge
profile is selected.
Change-Id: Icddc047e608cc8f63cd0c19be716e0f7908ca715
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/438804
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>
Take in account that sensors are down in S3, reinit them back when
moving from S3 to S0.
Do this only for board version 3 and older. board v4 will have
sensors powered in S3.
BUG=chrome-os-partner:61502
BRANCH=reef
TEST=Check EC power sensors up coming from S3 to S0:
[1.627437 power state 6 = S3->S0, in 0x00cf]
[1.627994 Port 80: 0x1001][1.628600 chipset -> S0]
[1.637391 TCPC p1 Low Power Mode]
[1.645020 Lid Accel: Done Init type:0x0 range:2]
[1.647733 Lid Accel ODR: 10000 - roundup 1 from config 1 [AP 0]]
[1.649015 TCPC p1 Low Power Mode]
[1.662231 TCPC p1 Low Power Mode]
[1.670560 Base Accel: MS Done Init type:0x0 range:2]
C0 st15
[1.679813 PB task 6 = released]
[1.680783 PB PCH pwrbtn=HIGH]
[1.681108 PB task 0 = idle, wait -1]
[1.683463 Base Accel ODR: 10000 - roundup 1 from config 1 [AP 0]]
[1.686275 Base Gyro: MS Done Init type:0x1 range:1000]
[1.697973 Base Gyro ODR: 0 - roundup 0 from config 0 [AP 0]]
[1.776627 Base Mag: MS Done Init type:0x2 range:2048]
[1.786490 Base Mag ODR: 0 - roundup 0 from config 0 [AP 0]]
...
Change-Id: Icb9961a0f3ce1b478c47057716211e6e14c13674
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428125
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 37e6fb246495ac972e0bc4ff6fcc16b9bf2eee7b)
Reviewed-on: https://chromium-review.googlesource.com/440511
Commit-Ready: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Tested-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
x86 devices use TPM_RST_L to detect the AP state, so we set
device_states[DETECT_AP].detect to GPIO_TPM_RST_L on those boards.
board_update_device_state uses this signal to poll the AP state once a
second to detect if the device is off.
If for some reason TPM_RST_L is deasserted, but the tpm reset handler
has not yet set the state to 'on', we will catch it when we poll the AP
state with board_update_device_state. It will call device_state_on with
TPM_RST_L. In that case device_state_on used to silently disable the
TPM_RST_L interrupt and not change the AP state. This change modifies
device_state_on to notify the tpm reset handler and prevent it from
disabling the tpm reset interrupt.
BUG=chrome-os-partner:62748
BRANCH=none
TEST=disable the deferred_tpm_rst_isr call in
configure_board_specific_gpios. Close the lid and wait 5 minutes. Open
the lid. Verify cr50 prints "device_state_on: tpm_rst_isr hasn't set the
AP state to 'on'" and the system boots normally.
Change-Id: I6e5b722fab6e7b0acb91dda0e5207e4411e97363
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439816
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds a host command to get PD chip info.
For PS8751, tcpci_get_chip_info will fail if the chip is in
low power mode. It can be woken up by reading a random register
first then wait for 10ms.
This code doesn't have the wake-up read to avoid 10ms delay.
Instead, we call this function immediately after the chip is
initialized because it'll gurantee the chip is awake.
Once it's called, the chip info will be stored in cache, which
can be accessed by tcpc_get_chip_info without worrying about
chip states.
localhost ~ # ectool pdchipinfo 0
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # ectool pdchipinfo 1
vendor_id: 0x1da0
product_id: 0x8751
device_id: 0x1
fw_version: 0x37
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1. make buildall
Change-Id: I3f1667d00ce1826936d90882ada1df6ed6b0ea37
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433166
This commit changes the Cr50 write protect behaviour to simply follow
the state of the battery present pin. The state can still be overridden
both ways by using the `wp` console command. A user can either force
write protect enabled or force write protect disabled. Additionally,
the behaviour can be reset to follow the state of the battery pin by
issuing `wp follow_batt_pres`. However, the ability to force the write
protect state requires an unlocked console.
BUG=chrome-os-partner:62726
BRANCH=None
TEST=Plug in battery, verify that WP is enabled. Plug in AC and unplug
battery, verify that WP is disabled.
TEST=Unplug battery, unplug AC, plug in AC, verify that WP is disabled.
TEST=Unplug battery, verify that WP is disabled. Use `wp' command to
enable WP, verify that it is enabled.
TEST=Plug in battery, disable WP using `wp` command, put cr50 into deep
sleep, wake it up, verify that WP is still disabled.
TEST=Plug in AC, plug in battery, disable WP using `wp` command, unplug
and plug battery connector, verify that WP is still disabled.
Change-Id: I83d9820067800801ddbde311eab0853c3c2216d3
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/439485
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
After configuring tpm_rst_l to be connected to the correct pin, check
the level of GPIO_TPM_RST_L to make sure we did not miss the rising
edge. If we did then call the tpm reset handler
BUG=chrome-os-partner:62748
BRANCH=none
TEST=verify electro boots, close the lid, wait 5 minutes, open the lid
and verify it still boots
Change-Id: I1a229fa53664767f0e5cad5f80285f5f030f2197
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439879
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The loss between PS8751 and Type-C connector is large and requires
a larger EQ and low squelch threshold for compensation.
- USB Type-c connector facing receiver equalization setting:
Compensate for channel loss up to 10.9dB
- High Speed Signal Detector threshold adjustment: -25%
BUG=chrome-os-partner:61101
BRANCH=none
TEST=Boot & charge
Change-Id: Ie74e2d0b8ad7206f5e60fb013613c382980c0eac
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433846
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The ap uart tx signal is disconnected if servo is attached, but it is
never reconnected when servo is detached. The 'ccd uart enable' command
only reconnects the EC uart tx signal, so if servo is detached the only
way to reenable ap uart tx is to detach and reattach suzyq. This can
cause cr50 to lose some ccd state.
This change reconnects the ap uart when servo is detached.
BUG=none
BRANCH=none
TEST=manual
disconnect servo
attach suzyq
verify the ap console is read write
attach servo
verify the ap console is read only
detach servo
verify the ap console is read write
Change-Id: I11cdd932b14d968ec77b18adf93dd0d3808fb2e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439704
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Without this, keyboard columns 10 and 11 do not work, as registers
for port F are never set.
Let's also remove port D, since we do not use it as part of the
keyboard scanning.
BRANCH=none
BUG=chrome-os-partner:62751
TEST=flash hammer, all keys work.
Change-Id: I0c07dc2420d7cd570ad8450c76f91a2bad9a50a5
Reviewed-on: https://chromium-review.googlesource.com/439908
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Follow CL:433083, integrate this to children.
BUG=chrome-os-partner:59712,chrome-os-partner:62641
BRANCH=reef
TEST=gpioget EN_P3300_TRACKPAD_ODL is 1 in S5 & below, 0 otherwise.
Change-Id: I86716e95d7a32c44df9fe46419dccd842eb7dd48
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/438779
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The reset count is very useful for debugging whether the tpm is locked
or if the version rolled back. This change makes reading the value
easier by adding it to the sysinfo command
BUG=none
BRANCH=none
TEST=reboot cr50 8 times verifying the reset count value is correct each
time and that sysinfo also shows a rollback is detected after the 7th
boot.
Change-Id: I94ac11a444ee73aa04bbdcc066c8e1c7a0a3ae8e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438788
Reviewed-by: Scott Collyer <scollyer@chromium.org>
There is no need to invalidate the inactive RW image if it's already
been done. Check the magic area of the header and if already 0s, then
set *response_size and return VENDOR_RC_SUCCESS.
BUG=chrome-os-partner:62588
BRANCH=none
TEST=manual
Update H1 FW on Eve. Using 'ver' command verify that it has valid A/B
RW images. Log into chromeos and see console messages indicating that
inactive image is being invalidated and via 'ver' command. Reboot via
H1 console and see that this time the message
vc_invalidate_inactive_rw: Inactive region already corrupted
is displayed.
Change-Id: I0894d456fdc63f64fc7272ad55d75ba94dbe94c4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438787
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
- Use amber for charge when in suspend/off states and leave red
to indicate something is wrong.
- Blink non-charging LED in S0ix/S3 states.
BUG=chrome-os-partner:60797
BRANCH=none
TEST=verify led operation in s3/s5 while charging
Change-Id: I16660942bf93f7cf6c951c19548c1c6838aabb72
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/438707
Reviewed-by: Scott Collyer <scollyer@chromium.org>
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>
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>
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>
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>
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>
- 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>
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>
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>
