Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a preparatory work for USB PD unit test. With this, we won't
need to duplicate these constants in both the implementation and the
test.
BUG=chrome-os-partner:31200
TEST=make buildall
BRANCH=None
Change-Id: Ia814a95450859caaa6d90e4cd866cb671d010b31
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211653
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
I2C reads from the PD happen in two separate transactions, but no stop
condition is set after the first transcation. Therefore, it is necessary
to lock the I2C bus across both transactions to prevent other tasks
from using the bus in between.
BUG=chrome-os-partner:29839
TEST=Manual on Samus. Boot to recovery screen, plug + unplug power
supply, verify that no I2C error messages are printed to console.
Then repeat 100x.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie441637f499980a349022e281379ad2cc825b1aa
Reviewed-on: https://chromium-review.googlesource.com/211649
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Set input current limit based on the max current from the
PD negotiation. For samus, this information is passed to
the EC as a host command. For ryu, the max current is set
directly following a negotiation.
CONFIG_CHARGER_INPUT_CURRENT is now just the default limit,
but after a successful PD negotiation, the limit can be
raised.
Note, for now the input current limit for samus is set to
2/3 of the value negotiated for. This is due to hardware
problems measuring input current on p2b boards.
BUG=chrome-os-partner:28532, chrome-os-partner:24461
BRANCH=none
TEST=tested on a samus. Verified input current limit using
"charger" console command from EC. Input current limit
after a reboot is 512. When zinger is plugged in, it jumps
to the appropriate value (currently 1280mA), and when
the negotiation is changed using the "pd 0 dev 5" command
on the PD console, the input current limit is adjusted to
match (2000mA).
Change-Id: Iab9186a0f9814655e3240217a9baf4a38f15f84d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211023
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Change USBC port 1 PD comparator to use window mode, which
uses COMP1's non-inverting input for COMP2's non-inverting
input (pin PA1). This allows us to free up pin PA3 and PA7
for the next build.
BUG=chrome-os-partner:31215
BRANCH=none
TEST=make sure PD communication works on both ports by plugging
in a zinger. Then set gpioset USB_C0_REF_PD_ODL 1, to change
comparator voltage to 1.5 V and verify that neither port works.
Then gpioset USB_C0_REF_PD_ODL 0 and gpioset USB_C1_REF_PD_ODL 1
and make sure that both ports work. This proves that both ports
are using USB_C0_REF_PD_ODL as the comparator value (PA1).
Change-Id: I6e1e5606af43196b04c84417552002b063aa4134
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211416
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
HAS_TASK_HOSTCMD is not a good indicator that we intend to use I2C Host Commands
On platforms such a veyron we use an STM32F0 with SPI HC for example however
i2c-stm32f0.c was very eager to still provide host commands via I2C.
If one wants to use I2C host commands they need to define
CONFIG_HOSTCMD_I2C_SLAVE_ADDR anyway, so the presence of that is a better
indicator.
The boards that want I2C host commands are ryu and samus_pd.
veyron/pinky needs SPI host commands, so this patch makes this case possible.
The rest of the boards that use STM32F0 do not have HAS_TASK_HOSTCMD set.
BUG=None
TEST=make buildall -j
BRANCH=None
Change-Id: Ia5561afdc6e72019c24c5c4b775944b2b88cb950
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211434
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The STM32F0 has a fancier SPI than the L1 series we've been using so far.
Notably it supports 16 bit data packing. This mode is activated automatically
by reading/writing to the SPI_DR register as 16 bits. We do not want this
feature since we only do 8 bit operations. This change prevents a misalignment
of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit
transfers.
Another unwanted feature is the FIFO. We rely on DMA and some buffers instead.
Keeping the FIFO enabled causes extra characters. The way this patch disables
the fifo is by changing the FIFO reception threshold to only 1 byte (which is
the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1
chips should not affect anything as that area of the register is reserved.
BUG=none
BRANCH=none
TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and
STM32F0(new support/veyron)
Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211476
Reviewed-by: Doug Anderson <dianders@chromium.org>
Added a check for if we are in RO and write protect screw is
present which will stop the PD task to prevent PD communication.
By default this check is disabled since the p2 samus units do
not have access to WP screw. This check will need to be enabled
for EVT.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=enabled the check, loaded on a p2 samus, and verified
that in RO, the console prints out "PD not allowed" and there
is no communication with an attached zinger. Then ran "sysjump
RW" and verified that power negotiation with zinger succeeded.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I5007db659d8b057431426157a2150127b97a7b3f
Reviewed-on: https://chromium-review.googlesource.com/211020
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add PD communication enable flag. When disabled, the ports
will still detect source/sink connect and disconnect, and
will provide VBUS to a device, but will not send or respond
to any PD communication.
Use the CONFIG_USB_PD_COMM_ENABLED macro to define the
default state of PD communication enabled flag which may
vary board to board.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=load onto samus. use "pd 0 enable" console command to
toggle between enabled and disabled. when disabled, test
that plugging in a zinger only gets you the default VBUS 5V
and that no negotiation takes place. when enabled, test
that plugging in zinger negotiates successfully.
Change-Id: I78ac3091f12d9699b19647be48ab7b6f434f5d7d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211045
If we are in SNK_DISCOVERY state and get PD_RDY, we are not sure what
the power source is. In this case, instead of happily go to SNK_READY
state, we should do a hard reset to be safe.
BUG=None
TEST=Check PD on samus/zinger still works.
BRANCH=None
Change-Id: I2baca06d45ba41e30d2ccf7a02fb65eb3966e5c1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210925
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we are in disconnected states and get a request, it's likely either
ourself or whatever on the other side is confused. Do a hard reset in
this case.
BUG=None
TEST=None
BRANCH=None
Change-Id: Ic6504fccc55b79bd3ec4cc47007252e7dc69c778
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210924
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In PD state machine, we often need to do "go to X state, and if after Y
ms we are still in X state, go to Z state." However, we do this in a way
that are suspectible to premature timeout if PD task is waken at an
unfortunate time. Let's add methods to set the state w/ or w/o timeout
to prevent this.
BUG=None
TEST=Boot on samus. Plug in zinger, and check we have 20V power.
BRANCH=None
Change-Id: I91db44ef71e31007eef4edd0f826bf81505e51e5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210874
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If a battery is found in disconnect state, we need to apply a charge
current to get it out of that state, even if the battery is full.
BUG=chrome-os-partner:29465
TEST=Manual on Samus. Put full battery into disconnect state then
power-on the EC. Pull AC and verify that the battery is no longer
disconnected.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I43e872e225dc5a651f566d7b190cff85a487805e
Reviewed-on: https://chromium-review.googlesource.com/210343
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Remove code for preventing PD negotiation until the battery
is at some minimum SOC. This was originally necessary because
transitioning voltages would cause the source voltage to go
briefly to 0V, which would kill power to the system unless
the battery was at some minimum level of charge. But, that
isn't true anymore. It is safe to transition up or down in
voltage and the source voltage should never drop to 0V.
BUG=chrome-os-partner:29499
BRANCH=none
TEST=make -j buildall. No need to do any more testing because
this code has been disabled for a while.
Change-Id: I8a3dca117f01f0f9c7d04b5d489e4a8588a89be6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211021
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In order for the AP to access the SPI part one needs to drive
PD_DISABLE_DEBUG to 1. While all the closed-case debugging is being
worked out set this signal 1 by default so that the AP can boot.
BUG=chrome-os-partner:31149
BRANCH=None
TEST=Built and flashed on ryu. SPI works from initial poweron.
Change-Id: I1fdb0457da9db07063f86959d9eb969e3bcd83ec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211141
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This fixes the bug that SRC_ROOT is not set. This should be the last fix
for flash_ec. DEFAULT_BOARD is intentionally left as is. For developers
who don't want to use --board option every time, they need to set
DEFAULT_BOARD in their environment variables.
BUG=chromium:397202
TEST=util/flash_ec --board=link
BRANCH=None
Change-Id: If23f73adbd37f2a79cb5176e3665562e278f46db
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210523
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
BUG=chrome-os-partner:28887
BRANCH=None
TEST=Run ectool battery cutoff and console cutoff
command with and without at-shutdown option.
Change-Id: If631e1fdcd5950f2ca23b30801d54cfb32287313
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203695
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Add console commands to send the Vendor-Defined Messages used to flash a
USB-PD target.
Also add a simple test script to flash Zinger through its CC line. To
run the script, the board must have CONFIG_USB_PD_CUSTOM_VDM defined.
By default fruitpie has this config option enabled.
BRANCH=none
BUG=chrome-os-partner:28330
TEST=With a fruitpie connected to a zinger run
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW.
Change-Id: I06f8f545e28b93b2e646e668d81b594eb7976a2d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203375
Reviewed-by: Todd Broch <tbroch@chromium.org>
Fix bug in pd transmission. The retry mechanism was not working right
and was causing us to not do any retries.
BUG=none
BRANCH=none
TEST=Test with a zinger unplugged from the wall. Samus sends source
cap and doesn't get a response. Verify on console printout that we
retried 3 times.
Change-Id: Id273bf054655c2d24a791f4eaf4cb8d87253abe2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Increase stack size to account for pd communication errors. With
lots of pd communication errors, I see a max stack usage of 520
bytes, which is larger than the old stack size of 488 and was
causing stack overflows.
BUG=none
BRANCH=none
TEST=load onto samus and generate pd errors by plugging in an
unpowered zinger (samus sends source cap every 100ms, but no
response). measure task usage.
Change-Id: Iab2b0f781cb39d8e1ea906de48bd5b37e229d291
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210580
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If chromeos-ec package hasn't been built, flash_ec tries to find
stm32mon in local build/ directory. However, this is broken in the last
CL when we move away from crosutils. Let's fix it.
BUG=chromium:397202
TEST=Flash samus_pd
BRANCH=None
Change-Id: I05395a727fa965032a24f51c07deaebf2d7c7e51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210419
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Packets can be 128 bytes, and are preceded by a prefix byte. So we
need a 129-byte buffer, not a 128-byte buffer.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=do pd software sync; see that 128-byte packets transfer correctly
Change-Id: Ic1e6cfec2c042537768d1cd0eecea509cc90c052
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210502
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previous assumption assumed that the flash was remapped
to address 0.
This is not the case anymore since cl/210063
BUG=chrome-os-partner:30997
TEST=Check we can boot the EC now.
BRANCH=None
Change-Id: I46e1dc0ad840b21661aa5d87817369b29a659c9b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210407
The script currently depends on common.sh from crosutils, which is not
installed on beaglebone and also pulls in dependency on other
repositories. Let's switch to shared shflags library and include output
formatting functions in flash_ec script. This way we are independent
from crosutils.
BUG=chromium:397202
TEST=Run the script to flash EC
BRANCH=None
Change-Id: Ib18987410eb32d773d55fb4e53133adf230167b9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209827
Reviewed-by: Dan Shi <dshi@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously if you were working on a single board you had to add BOARD=
to all of your make command lines. Now if you are in a board directory
you can just use "make", or "make clean", or any other top level make
command.
This commit also adds support for a top level "make flash" command that
can be used from the board directories as well. This command uses
openocd and requires that the board provides an openocd-flash.cfg file.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=(from a few board directories) make clean; make -j
(from the discovery-stm32f072 directory) make flash
Change-Id: Ie09a74881371169a2c3cd9cd9922f39f4873f1a6
Reviewed-on: https://chromium-review.googlesource.com/209669
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Host commands can be generated by either the PDCMD task (in response
to PD interrupts), or the HOSTCMD task (in response to passthru
requests). Use a mutex to serialize access to the EC->PD interface.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Boot samus
Change-Id: If65d5eb4bbef91e6c811a06ea2e1487e17143dc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210401
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This is necessary for PD software sync. Also need to increase the
hook task size to avoid stack overflow.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=boot samus; on PD console, see hash calculated.
Change-Id: I37e571f9cd03a31eb4eaad903c3dda72f7e51fc1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209812
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Zinger EVT units will have hardware change for PA0 to be able to
wake up from standby. Part of the change is that we have to output
high on PA0 in order for the comparator to compare against 0.65V, which
is inverted from the previous version.
BUG=chrome-os-partner:28335
BRANCH=none
TEST=reworked a p2 zinger with PA0 changes, plugged into samus,
and verified we still charge.
Change-Id: I7344f1d1decddc4e6600e41c313e1e7a5a5de067
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209832
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On Ryu, we are using TPS65913, which doesn't support the 8-second long
key press power-off. Let's switch to firmware timer.
BUG=None
TEST=Do a long power button key press, and see the AP powering off and
not restarting.
BRANCH=None
Change-Id: Ic9eb6d525498c7cdedf8f053dd0a2fa2b568a443
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209850
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have three copies of 'typec' commands in three different boards. The
commands current mix hardware-specific logic and console command logic
together. Adding a board_get_usb_mux() interface to separate the logic
and deduplicate the console command logic.
BUG=None
TEST=make buildall
TEST=Test 'typec' command and verify GPIO settings.
BRANCH=None
Change-Id: Ie1825f49d32609c732db384679cb917f2f1a4082
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209955
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, on stm32f cortex-m0 systems, interrupts are always being
directed to the RO vector table. This can cause strange problems when
running RW software because it is still calling IRQ handlers in the RO
code.
Unfortunately, on cortex-m0 the ability to specify the vector table
location in flash (VTOR register) is optional, and stm32f0 parts do not
have it. Instead, in order to run RW IRQ handlers, at init time, this
CL copies the vector table from flash to the base address of SRAM
(0x20000000), and then selects SRAM to be mapped to 0x00000000 where
the core looks to find the vector table.
BUG=none
BRANCH=none
TEST=Tested on zinger.
- Verified that vector table is copied to SRAM by printing out 48 words
from SRAM base address 0x20000000 in main() and verifying that it matches
the vector table in flash in the disassembly.
- Verified the vector table at SRAM 0x20000000 points to the RW handlers
when in RW and the RO handlers when in RO.
- Also printed out PC in one IRQ handler and verified it was in the
appropriate section of code.
Also, ran on samus_pd and did a sysjump RW to make sure at least one other
system works.
Change-Id: I22aff1b5e0de9b23fd3324f0cbe4f6c45a81967e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210063
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add back in sending hard reset on board fault.
BUG=none
BRANCH=none
TEST=Using zinger and firefly, create an overvoltage error by down
stepping with a 0 VOLTAGE_DOWN_STEP_TIME, and make sure that a hard
reset is received by firefly and that we re-establish negotiation
after the OVP fault is cleared.
Also tested with zinger and samus. On samus I set the input current
to 3.5A, which immediately triggers an OCP, and verified that we
get a HARD RESET from zinger and that after the reset we negotiate
correctly and get back to normal (note that when VBUS goes down, the
EC resets the input current limit to default 2A, so that's why we
don't continue getting OCP).
Change-Id: I991b15411c4ce05c1086851b1e2e56e2effab749
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209865
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow a sink to request a new voltage without dropping the established
negotiation. For this to work the sink must save the last received
source cap packet and use that to make a new RDO from the SNK_READY
state.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Tested on a firefly connected to zinger. made sure we can press
buttons to change voltage and we don't lose the existing negotiation.
Also tested on samus, ports 0 and 1, using pd x dev 5/12/20 to switch
between voltages and verified we don't lose existing negotiation.
Change-Id: I5a550b667f3aff7975185e091f3caac4555a907e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209864
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug in which output was disabled on down voltage transitions.
This also changes the behavior of the OVP protection. On down-step
transitions, the OVP threshold is not lowered for a specified amount
of time after the transition to allow the output to dissipate down to
the new voltage. This will still catch a problem if the voltage goes
up instead of down, but avoid OVPing immediately on a normal down
transition.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Attach to firefly and probe output voltage. Make sure we
transition smoothly going down in voltage.
Change-Id: I7f3a0c17cc8b392a25d24d56d2b7155b806acb64
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209863
Board bring up. GPIO / UART / timer / console / task / hook are
working now.
BRANCH=tot
BUG=none
TEST=run on evaluation board and see LED 0/1 are blinking.
Console commands are available to use.
Change-Id: If93a2c94b8abe1c2c931c03a7a12ddd2bed9d9f6
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Some PMIC chip (e.g. TPS65913) doesn't support the 8-second long key
press power-off. For this, we have to check the state of the power
button in firmware, and do not assert PMIC_PWRON during the shutdown
sequence to prevent the AP from restarting.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=with the next CL, on Ryu, do a long power button key press, and see
the AP powering off and not restarting.
Change-Id: I03f703b4ff6d86edea150dfa32f60d30f1ddffd9
Reviewed-on: https://chromium-review.googlesource.com/207381
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
We used the incorrect src_caps index when choosing PD voltage. Let's fix
it to ask for all available power until we are able to ask only for what
we need.
BUG=None
TEST=make buildall
BRANCH=None
Change-Id: I068264246c2586b8192220eff47838da438899b0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207802
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The design voltage is 4.35V and the current charging voltage, 4.4V, is
too high. Let's lower this to 4.34V to meet the designed voltage.
BUG=none
BRANCH=none
TEST=none
Change-Id: Id5ab111d7ef390fe509adbb75112c78de1aab8a9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207687
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
