The ISL9238 has a functionality where it will reload the adapter current
limit from a strap which is read from the PROG pin. This is problematic
when we decide to set the current limit prior to AC actually being
inserted. This commit disables this functionality from the charger.
It seems however that the charger will read the PROG pin and reload the
ILIM at least once before respecting the bits.
BUG=b:67120928, b:66017697
BRANCH=None
TEST=Plug and unplug and then plug again AC. Verify that the default
current limit is not set by the charger automatically.
Change-Id: Ia8e8742843f6ceb286635b31e0fe5c070a2b6dfe
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/759693
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Shamile Khan <shamile.khan@intel.corp-partner.google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The ISL9237/8 can both be powered by VSYS or AC, therefore, it's not
needed to reinitialize the charger after AC is present.
This commit moves the contents of charger_post_init() into a new init
function that will be run once at HOOK_INIT time.
BUG=b:67964166
BRANCH=None
TEST=make -j buildall
Change-Id: I637b1209f86f686013fee0783914fa1596076fa6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/759692
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The ISL9238 has functionality for a input voltage regulation loop. By
default, the regulation reference voltage is set to 4096mV, however we
can be kinder to chargers by raising this regulation reference. In
testing, there appears to be insignificant change in current pulled at
the higher limit.
BUG=b:67964166
BRANCH=None
TEST=Flash a board with a ISL9238, verify that 0x4b reads as 0x0d00.
TEST=make -j buildall
Change-Id: I920c4b922106fca3001f2759cad0479a368f735b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/745527
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch allows Fizz to switch the power source from a type-c
charger to a barrel jack adapter if the system is in S5.
BUG=b:38321259
BRANCH=none
TEST=Verify the following with 45W and 60W type-c chargers:
1. Boot Fizz with a type-c charger
2. Go to S5 if not already.
3. Plug in a BJ adapter. Fizz boots to S0 using BJ power.
Also verified other boot modes are not affected:
1. Auto boot on BJ insert
2. Auto boot on Type-C insert
3. Recovery boot on BJ
4. Recovery boot on Type-C
5. Stay off if it's previously S5
Change-Id: I86aa0fe6e403bcbacfe396997d897111ffcf8e74
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706251
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When sysjump to another image, if USB switch state and HW switch control
are not sychronized, the switch can be left in open state. This CL
resets USB switch on init to close USB.
BRANCH=oak
BUG=b:36234142
TEST=manual
plug BC1.2 charger, sysjump to another EC image and unplug the chager.
check pi3usb9281 control register(02h) bit2 == 1.
Change-Id: Iaadfaf51064ed1508271e974b9caf88b96bbe008
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/502835
Reviewed-by: Shawn N <shawnn@chromium.org>
The reset line for the parade TCPC on port 1, has an external 1k pull
up resistor. However, the gpio.inc description for this line was set
to ODR_LOW which results in a short reset pulse. This can lead to an
external charger seeing an unattach event and dropping VBUS. On some
Coral systems with certain chargers this results in a continuous
reboot loop when no battery is connected.
Changing the default state of this line to ODR_HIGH prevents reset
from being pulled low until the EC is intializing the TCPC and fixes
the continous reboot loop issue when no battery is connected.
BUG=b:68226308
BRANCH=coral
TEST=Using Robo system tested with the Lenovo Type C charger and
verified that the system can boot up without a battery when connected
to port 1. Bitland also verified this change in their test setup and
found no failures.
Change-Id: Ia16fe8cf770dc91da479497d234a2b6f9679b878
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/762066
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Currently, 'ectool temps all|<n>' just prints "300". This may easily
be mistakenly read as tenth of degree C (30.0 C), as the value
appears to make sense (close to room temperature). However, the value
is actually 300 K (27 C).
CQ-DEPEND=CL:763578
BRANCH=none
BUG=chromium:783845
TEST=ectool temps all shows temperature unit (K)
Change-Id: I70f7f04d061cb1d4f741d59f8b48c7963dd8280f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/763996
Reviewed-by: Shawn N <shawnn@chromium.org>
keyboard_clear_buffer() should not trash FIFO contents without
synchronization from fifo_add() / fifo_remove(), otherwise a bad
FIFO state may ensue.
BUG=chromium:781554
BRANCH=gru
TEST=Verify KB is functional on kevin through suspend / resume, verify
keyboard functions as S3 wake.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5d28c72359f6e1ce8778725a15c51cdfcd8ab90b
Reviewed-on: https://chromium-review.googlesource.com/761300
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
There are two Type-C ports and a DC Jack on GLKRVP. Added code
to allow system to boot from DC Jack also. This helps to boot
the device without Type-C connector during early stage of
software development.
BUG=b:69005234
BRANCH=glkrvp
TEST=GLKRVP can boot to OS without battery and DC Jack attached.
Also VBATA is set to battery voltage max.
When DC-Jack is present Type-C port is not enabled and
vice-versa.
Change-Id: I0fe5631c40490c56fba6ed5f3ad7ba7f5248460a
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/757874
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>
With this change, we can pass "make buildall" at local
after it83xx based boards were removed from skip_boards.
BRANCH=none
BUG=none
TEST=- Passed "make buildall -j"
- CROSS_COMPILE_nds32=nds32le-cros-elf- make BOARD=it83xx_evb -j,
build ec image by using nds32le-cros-elf toolchain.
- make BOARD=it83xx_evb -j, coreboot-sdk is used.
Change-Id: I689b67ed50ac5c80e7526f157ba28733d7216e14
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/762807
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
The original assembly code of deep sleep bypass will cause build error
if both CONFIG_LOW_POWER_IDLE and CONFIG_LTO are defined when buildiing
board glkrvp/zoombini. This CL fixed it by change the bypass assembly code
from:
asm ("push {r0-r5}\n"
"ldr r0, =0x100A8000\n"
"wfi\n"
"ldm r0, {r0-r5}\n"
"pop {r0-r5}\n"
"isb\n"
);
to:
asm ("push {r0-r5}\n"
"wfi\n"
"ldm %0, {r0-r5}\n"
"pop {r0-r5}\n"
"isb\n" :: "r" (0x100A8000)
);
BRANCH=none
BUG=none
TEST=No build errors for "make buildall".
TEST=build zoombini/glkrvp with CONFIG_LOW_POWER_IDLE and CONFIG_LTO,
no build errors.
TEST=build npcx7_evb/npcx_evb and do stress test for deep idle->wakeup
on EVB, no symptom observed.
Change-Id: I90b13b4baf418e3f4b3234d4811e3978b6436aac
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/756535
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
attenuation_factor is set to 1 because there is a calibration in iio
framework of kernel already which would be configured in the factory
flow.
BRANCH=None
BUG=b:69025351
TEST=Manually test on the DUT to make sure there is no additional
factor applied to raw data.
Change-Id: I25c5a3b341573bb82828164d3243f9adbac05372
Signed-off-by: Marco Chen <marcochen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759765
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This CL modifies the 2 flags --save_stats and --save_raw_data
so that they can take arguments to save the corresponding file
into directories that we specify. It also provides a new flag
--no_print_raw_data to suppress printing sweetberry readings in
real time.
This CL is part of the effort to start sweetberry measurements
while running power autotests.
BRANCH=None
BUG=b:68956240
TEST=./powerlog.py -b xxx.board -c xxx.scenario \
--save_stats ./xxx --save_raw_data ./xxx --no_print_raw_data
Change-Id: I01ebeafc5f4eebd0a77746e9968367f267e93d83
Signed-off-by: Mengqi Guo <mqg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756255
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
With this change, we can keep a PWM channel active during
low-power idle (EC deep doze).
BRANCH=none
BUG=none
TEST=The pwm channel is function normally in deep doze mode.
And tested pwm frequency setting are:
300, 250, 200, 150, 100, 50, and 10 (Hz)
Change-Id: Ie94cd96e819c869bdde6d7675d8f1a6cfc627f3b
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/752702
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The SET sub-command of EC_CMD_CHARGE_STATE sets charger current /
voltage parameters to arbitrary values and should be locked down.
EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe
operation modes, and should be allowed.
BUG=None
TEST=On kevin, set force_locked, plug zinger, and verify:
ectool chargestate param 4 3 <-- ACCESS_DENIED
ectool chargestate show <-- prints params
ectool chargecontrol idle <-- stops charging battery
ectool chargecontrol normal <-- battery charges again
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5
Reviewed-on: https://chromium-review.googlesource.com/757237
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The llama is a South American relative of the camel, though the llama
does not have a hump. These sturdy creatures are domestic animals used
by the peoples of the Andes Mountains.
BUG=None
TEST=`make buildall -j`
BRANCH=None
Change-Id: I55dbd8d5b0b14c41e27c4ef473833563f38878c3
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/761298
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Copied board-related files from scarlet folder and made edits to
fit rainier. Left in most battery related code and config since there
is enough logic to detect absent battery
BUG=chromium:776441
TEST=Run "make -j BOARD=rainier"
BRANCH=none
Signed-off-by: egemih@google.com
Change-Id: Ifd1201a9a44cebd9b433545f0ac7ee04741429c9
Reviewed-on: https://chromium-review.googlesource.com/755949
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Ege Mihmanli <egemih@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Tasks will no longer be scheduled before HOOK_INIT completion, so it's
no longer possible for the chipset task to notify HOOK_SHUTDOWN before
HOOK_INIT completes.
BUG=None
TEST=`make buildall -j`
BRANCH=None
Change-Id: I78349801738ff28fe9774df0c03296fe549dc9c9
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759242
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
With these changes
$ CROSS_COMPILE_nds32=/opt/coreboot-sdk/bin/nds32le-elf- \
make BOARD=it83xx_evb
works for me.
The -mno-gp-direct option is replaced with -mcmodel=large in new
compilers, as indicated in private email with Andes Tech. It was also
used as a work-around and leaving out the option altogether reduces the
code size significantly, so it's now dropped.
BRANCH=none
BUG=b:35572628
TEST=the above command creates an image
Change-Id: Ib580d65e6e52f291fdb920b7b65fb22cfda9f736
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/753623
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Fizz blinks the power LED to alert a user when power supply isn't
enough. This patch makes the blinking speed twice as fast (on:1sec,
off:1sec).
BUG=b:37646390
BRANCH=none
TEST=Verify the LED blinks as intended.
Change-Id: I017eaf36b91d987f4b03308b1e9ac8781e5f217d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757557
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sometimes the AP will generate a short 'wake' pulse on the SPS CS line
just in case the chip is in the sleep state. This pulse is supposed to
wake up the chip and prepare it to process the actual SPS transaction
which follows the wake pulse in 100 us.
It turns out that under certain conditions it takes the Cr50 longer
than 100 us to react to the wake pulse, for instance when it writing
into flash which is in the same bank the code is running from, there
is no way to avoid stalling in this case.
What happens then is that the 'CS deasserted' interrupt for the wake
pulse comes while the actual SPS transaction is in progress. In this
case when processing the CS deassertion interrupt the Cr50 should not
consider it an end of a transaction, but just ignore it making sure
that the next CS deassertion still would trigger an interrupt.
BRANCH=none
BUG=b:68012381
TEST=verified that this patch helps the AP firmware test case which
was often failing due to TPM getting out of sync.
Change-Id: I412459552f4b2d13cd72800c1af7d583226e8466
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754505
TPM reset processing takes certain time, and conceivably the AP could
start SPI transactions before TPM reset is finished. If the SPS
interface comes up while the CS line is active, the H1 controller
considers this a start of the SPI cycle, even though it is not - the
AP has already transferred the header and is waiting for the flow
control.
Let's not complete SPS interface initialization while the CS line is
kept active.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I53cd49c6139f3c29c4b6d234c7ee4d527c8282f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no point in invoking SPS receive handler if there has been no
data transferred while CS was asserted, as would be the case when the
AP generates the wake up pulse.
Also, make sure that the flag indicating that data was seen is cleared
when the interface is reinitialized, as TPM reset could come during an
SPS transaction.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I82d63d257b67a715d6dbc540c2d7480e5ff718ff
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Coral uses a 1 second delay to report battery being present to help
avoid VSYS glitches than can affect H1. On Eve, it was not expected to
remove and reconnect the battery while running. However, on Coral the
battery connector allows this action to take place.
Current if the battery is removed, when it's reconnected it can't
report as present because the timer_started flag is not being
reset. This CL checks for the case where the battery is not present
after being present and uses that as a trigger to reset the
battery_report_present_timer_started flag.
BUG=b:66923031
BRANCH=coral
TEST=While Coral unit has battery and ext AC connect, remove the
battery connector. Verifed the console log showed that this condition
was caught. Waited about 10 seconds, then reconnected battery and
verified that it reports as present.
[52.778818 Battery was present, but is now removed]
[60.211048 battery will now report present]
[60.217801 Battery FET: reg 0xe000 mask 0x4000 disc 0x0000]
[60.711195 battery woke up]
Change-Id: I41ae8c1b04a56697d20d3037b94189aff778fc4d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/754025
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In order for BC1.2 detection to succeed, USB data switches must be
open. Previously we performed BC1.2 detection whenever VBUS transitioned
up to 5V, including on power swap. In fact, there is no need to do BC1.2
detection on a PD-capable port, since we will always charge using the
USB-C or PD negotiated ILIM. Skip BC1.2 detection on power swap (and
more generally when a partner port is known to speak PD) by manually
triggering BC1.2 detection. In addition, manage USB switch state
differently, so that "auto mode" is only enabled during BC1.2 detection.
BUG=chromium:780905
BRANCH=gru
TEST=Attach USB-PD phone capable of role swap. Verify USB 2.0 device is
enumerated on plug, and not re-enumerated through a series of
"pd # swap power" commands on the EC console. Also verify BC1.2 charging
and PD charging are still functional on kevin.
Change-Id: I1d7d4dee3bc8d2e7885e7adb49ded84b4f515ad5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755878
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fizz has no battery, so any port / ILIM selection logic that could lead
to de-powering the device should be relaxed.
BUG=b:68953563
BRANCH=None
TEST=Boot fizz with both zinger and barrel charger, verify no panic /
brownout occurs.
Change-Id: I3bf353f5a26fe6210c67f8ee3f785012d4c063f0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756924
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
gcc 6.3 (as provided by coreboot-sdk) needs that to know which code
paths end early.
Also add a loop after the command that is "supposed" to reset the
machine so that the compiler believes it (and in case that assumption
fails).
BRANCH=none
BUG=b:65441143
TEST=none
Change-Id: Idb87253ec7880d66ffec30d75f4d007f02f63aab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/742916
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
It's undesirable to do BC1.2 detection on power swap, so add a function
to check if the partner port is known to be PD-capable.
BUG=chromium:780905
BRANCH=gru
TEST=With subsequent CL, attach USB-PD phone capable of role swap.
Verify USB 2.0 device is enumerated on plug, and not re-enumerated
through a series of "pd # swap power" commands on the EC console. Also
verify BC1.2 charging and PD charging are still functional on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa
Reviewed-on: https://chromium-review.googlesource.com/755877
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
One can pass either a board name (e.g. hammer) or a chip name (stm32)
to the flash_ec command. If given a board name, will map to a proper
chip name and then call its chip-flashing method.
The NEED_SERVO variable ("no" if servo not needed) was set according
to the board name. It was broken if only given a chip name. It should
be set according to the chip name.
BUG=b:68943874
BRANCH=None
TEST=Flashed the Staff firmware
SERVO $ dut-control ec_boot_mode:on
DUT $ ectool gpioset PP3300_DX_BASE 0
DUT $ ectool gpioset PP3300_DX_BASE 1
DUT $ flash_ec --chip stm32_dfu --image staff_ec.bin
SERVO $ dut-control ec_boot_mode:off
DUT $ ectool gpioset PP3300_DX_BASE 0
DUT $ ectool gpioset PP3300_DX_BASE 1
Change-Id: I1799f083115bfdf203a405733c5baefadbe3fe3e
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/755614
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Change chipset_force_shutdown() to not call power_button_pch_press()
when called from POWER_S5G3 state, so that we don't set pwrbtn=LOW
when entering G3.
BUG=b:68760602
BRANCH=none
TEST=push kahlee power button
Change-Id: I931fc73f2386f8124f1e082cccb095e3863cbb99
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/752682
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since poppy provides a custom battery present hw gpio, enable the
config option CONFIG_BATTERY_HW_PRESENT_CUSTOM.
BUG=b:65864825
BRANCH=None
TEST=Verified that when AC power is provided without battery present,
then EC auto powers up the AP. THis is essential for factory
testing. However, in order to make this work, CONFIG_SYSTEM_UNLOCKED
needs to be disabled. Verified device boots reliably after hardware
and software battery cutoff.
Change-Id: I9da1c68dfca3fd8c76570c78259adf42bf52522f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/752686
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When allowing an unlocked system to automatically power up we
may attempt to boot before the charger is ready to supply enough
power and get stuck in a reset loop.
In addition, if the batttery is not physically present in the system
then delay power-on until the charger is providing at least 15W of
power. (currently defined as LIKELY_PD_USBC_POWER_MW)
By adding a final check to the charge_prevent_power_on() function
to ensure that charge_manager_get_charger_current() is returning
a valid value instead of CHARGE_CURRENT_UNINITIALIZED then the
board is able to reliably boot.
This CL combines 2 CLs made on Eve which addressed the same problem
I'm seeing on Robo devices.
https://chromium-review.googlesource.com/582545https://chromium-review.googlesource.com/709473
BUG=b:68226308
BRANCH=coral
TEST=Used Robo system which was consistently failing when external
power was connected to Port 1. After adding this change was able to
consistently power up the system without going into a reboot loop. In
addition had signal wires attached to VBUS and VSYS so could verify
that VSYS was no longer collapsing.
Change-Id: Iadecf032feaacfda230bfc98a332cd7963fb0afe
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/752755
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
We didn't set BATT_FLAG_WANT_CHARGE in battery_get_params(), so
battery command always shows 'charging not allowed'.
Let's set the flag in the same condition as it is set in
battery/smart.c.
BUG=b:68027469
BRANCH=none
TEST='battery' on EC console shows 'Charging: Allowed'
Change-Id: Ifbdb6aee2572c8fc5f67103ca940738fb221ce5d
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/749025
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ensure GPIOs are inputs when read: Initialize GPIO direction on startup,
and clean up register accesses using reg names rather than magic numbers.
Add board version reporting with CONFIG_BOARD_SPECIFIC_VERSION.
BUG=None
BRANCH=servo
TEST=version is correctly 3
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: Ia04b01932fc36540af64b48b5e0bb6516f1529e2
Reviewed-on: https://chromium-review.googlesource.com/749693
Reviewed-by: Shawn N <shawnn@chromium.org>
