This required changing the USB-SPI implementation slightly
so that all work is done within the deferred callback. In
particular, this allows the board specific enable and disable
functions to do things that can only be done from a task
context, like sleeping.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I3f6a01ed9d6f31a3259ba0a0f6b4e123d6d2e718
Reviewed-on: https://chromium-review.googlesource.com/260964
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously we defined separate functions to map registers to protect
ranges for each supported SPI ROM. This change instead adds a protect range
table + flags for each supported SPI ROM and adds common functions for
translation between ranges + registers. This makes supporting new parts
easier. Since we will never use most supported protection ranges, we can
even simplfy the tables.
The implementation is now similar to flashrom.
BUG=chrome-os-partner:37688
TEST=Manual on Glower.
flashwp disable + spi_flash_rsr --> 0
flashinfo --> shows no protection
spi_flash_prot 0 0x10000 + spi_flash_rsr --> 0x24
flashinfo --> shows 64KB protected
spi_flash_prot 0 0x20000 + spi_flash_rsr --> 0x28
flashinfo --> shows all 96KB protected
spi_flash_prot 0 0x40000 + spi_flash_rsr --> 0x2c
spi_flash_prot 0 0x80000 + spi_flash_rsr --> 0x10
spi_flash_prot 0 0 + spi_flash_rsr --> 0x00
spi_flash_prot 0 0x1000 --> error
spi_flash_prot 0x10000 0x10000 --> error
BRANCH=None
Change-Id: Ie5908ce687b7ff207b09794c7b001a4fbd9e0f5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259310
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On hard reset / hibernate, RAM will be erased and panic data will
normally be lost. When software panic data saving is enabled, try to
save this data just before hard reset and restore it when we come back
up.
BUG=chrome-os-partner:37380
TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash
divzero" on console. After hard reset, verify that "panicinfo" dumps
data and shows divzero exception code.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb
Reviewed-on: https://chromium-review.googlesource.com/255912
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the proper checks to be able to compile source-only PD devices with
the common runtime.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:37078
TEST=make buildall
build honeybuns without CONFIG_USB_PD_DUAL_ROLE defined
Change-Id: I7ad0b39b2e62736117ec2d7b5163502afbf14786
Reviewed-on: https://chromium-review.googlesource.com/259112
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
W25X40 uses a different protection register encoding than our existing
W25Q64 code. Move the SPI ROM option to a config, and add support for
the new part.
BUG=chrome-os-partner:37688
TEST=`make buildall -j`. W25X40 protection code tested in a subsequent
commit.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8
Reviewed-on: https://chromium-review.googlesource.com/258440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modify charge ramp so that when it ramps it ramps from 500mA and
up to the maximum allowed by that supplier. Also modify Samus and
Ryu to use charge ramping for CDP and proprietary chargers due
to the possibility that they may not be able to supply the amount
that is supposed to be guaranteed by their advertisement.
BUG=chrome-os-partner:37549
BRANCH=samus
TEST=test on a proprietary charger, make sure we can ramp. test
a DCP and make sure we also ramp as before.
Change-Id: I08fd43c8f0b21aa54d114fbe5a1296c9556357e4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256972
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Clear all lightbar segments first before starting konami sequence.
If currently displaying Google colors, we need this so the start
of the sequence shows up correctly.
BUG=chrome-os-partner:37469
BRANCH=samus
TEST=from S0 with google colors on lightbar, run "lightbar seq konami"
from EC console and make sure 1st and 4th segments are cleared before
starting konami sequence.
Change-Id: I92ba8f29414c279895658167f8d5958fe49ea034
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256192
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Change tap for battery lightbar sequence to not show the last segment
dimmed as a percentage of your battery.
BUG=chrome-os-partner:37335
BRANCH=samus
TEST=use battfake console command to test out every increment of 10%
and use "lightbar seq tap" to show tap.
Change-Id: I4f38d26a8cfbecfa6efc86fcc8751ca8cb34879b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256191
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Return host command error codes for EC_CMD_CHARGE_CONTROL instead
of returning the result of EC functions which typically return
element from enum ec_error_list, which is a different error list.
BUG=chrome-os-partner:37171
BRANCH=samus
TEST=make -j buildall
Change-Id: Ia13cc8a2f747ddeafdc059c6e575dcc2f5b20b8d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254721
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a new supplier type for VBUS chargers (USB chargers which supply VBUS
but are not identified as another charger type).
BUG=chrome-os-partner:37168
TEST=Manual on Samus with subsequent kernel commit. Modify code to
reject all non-VBUS suppliers, charge with SDP port, and verify charge
icon appears in OS.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fbdb1cb57bd0224b01aaf5a763f93b678b6d204
Reviewed-on: https://chromium-review.googlesource.com/254346
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously, the flash module assumed it needed to emulate a SPI write
protect register using a bank of flash to hold the persistent flash
write protect state. This is not true for mec and ncpx chips under
development, which use external SPI flash. So, gate that code with
CONFIG_FLASH_PSTATE. For compatibility, leave it on by default (as we
do with CONFIG_FLASH_MAPPED).
There is no change to the behavior of currently supported chips, since
all of them already assume pstate is present. Removing this feature
from npcx will be done in a subsequent change.
BUG=chrome-os-partner:34346
BRANCH=strago
TEST=make buildall -j; verify flash wp and flashinfo work properly on samus
Change-Id: Ie044eb042863e4a7359ea540166ffd8d0089589d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253632
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
This signs the RW firmware (with a non-secret key). The RO
firmware will verify the RW firmware and jump to it if it's good.
Note that this isn't the final solution, just the beginning.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Build and install it. You'll see something like this:
--- UART initialized after reboot ---
[Reset cause: reset-pin hard]
[Image: RO, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.000444 Verifying RW image...]
[0.423742 RW image verified]
[0.423946 Jumping to image RW[0.428492 UART initialized after sysjump]
[Image: RW, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.428931 Inits done]
Console is enabled; type HELP for help.
>
> sysinfo
Reset flags: 0x00000c02 (reset-pin sysjump hard)
Copy: RW
Jumped: yes
Flags: unlocked
>
Change-Id: Icafa554baca135ff1f80cbce4dad5f980e7fc122
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Refactoring effort to unify the set of PD intialization tasks that
need to occur. Those areas include:
1. host mode as it relates to power & pull-ups/downs
2. PD tx init
3. PD mux settings
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. compiles and functions on samus_pd
2. If sysjump w/ dongle connected than alternate mode re-entered
properly including muxing and HPD
Change-Id: I47f32acaeccbd7745e1e01a8b085b1804c4c5000
Reviewed-on: https://chromium-review.googlesource.com/249273
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Issues fixed on 0216:
1.Modified CONFIG_KEYBOARD_COL2_INVERTED support in keyboard_raw.c
2.Modified warm_reset checking in gpio.c
3.Modified system_get_chip_name in system.c for package info.
4.Modified fan.c and pwm.c for:
● If the DCRn value is greater than the CTRn value, the PWM_n signal is always low.
● Fan stall condition event:
If the measured fan speed is lower than the lowLimit value (unless the Fan Speed Low Limit value is 0) or in case of erroneous measurement, the userCallback is called.
5. Change cycle_pluses to 480 in board.c
Issues fixed:
1. Jump data at top of RAM is getting corrupted. Changed the flag to
RESET_FLAG_RESET_PIN. Added a workaround method to fix VCC1_RST
issue.
2. Hibernate wake need to report whether wake reason was GPIO or RTC
3. Hibernate wake must be distinguishable from watchdog reset. The
booter will log reset reason in Code RAM. I copy the log data to
battery-backup RAM in little FW. And system driver will refer this
data to distinguish if it's watchdog reset or not.
4. Watchdog reset flag is not set. Same fix as 3.
5. Should return error if unable to clear SPI flash status register.
6. Remove chip_temp_sensor.c
7. Remove use of pstate from flash driver
8. Remove support for watchdog warm reset
9. Keyboard raw driver must support COL2 inverted
10. LPC memory mapped data must be read-only from host
11. LPC should support PLTRST# signal
12. Problems reading chip type/version. Use core registers and ROM data to read IDs.
13. When chip type/version is unknown, report hex value.
14. Watchdog does not consistently print panic information.
15. Remove console force enable logic.
16. Enable only the peripheral clocks that are needed. Please notice
user should add bit mask in CGC_XXX_MASK if they want to enable
additional module. For example, if user wants to enable PWM3, he must
add PWDWN_CTL2_PWM3_PD bit in CGC_PWM_MASK.
Please see HOOK_FREQ_CHANGE and HOOK_INIT these two hook functions.
If I turn off all I2C modules in system_pre_init and turn on the
modules I need in i2c_init, I found its freq is not correct. The root
cause is hook_notify(HOOK_FREQ_CHANGE) is executed first (in
clock_init) before i2c_init. At this time, i2c modules are power-down
and writing to freq register is useless. I re-execute freq-changed
hook function after turning on modules again.
17. MPU properly configured to prevent code execution from data RAM
18. Partial nvcontext implementation. Copy these 16 bytes in our battery-backup RAM.
Additional items we also modified:
1. pwm.c: Support open-drain IO type of PWM. (PWM IO-Type cannot by
determined by GPIO, we use bit 1 & 2 of function byte of gpio_alt_func
array to support it)
2. ec_npcxflash.c: Use definition to replace constant value. Stop
watchdog during flash programing.
3. npcx_cmds.tcl: Adjust script sequence for robustness. Add unlock
MPU commands for Data RAM.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=manually verify changes
Change-Id: I722a77d29e7543b054819480c7b7477af4263119
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248670
Make tap for battery red threshold match the low battery red
threshold.
BUG=chrome-os-partner:36811
BRANCH=samus
TEST=use a fake battery console command to change battery percentage
on samus and make sure that the same level at which lightbar turns
red in S0 is the same level at which tap for battery shows red.
Change-Id: I084c8412beac4f5b311eb30f46f4f3273e9f2456
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252351
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If a panic caused us to reboot, send a host event to notify the AP.
BUG=chrome-os-partner:36985
TEST=Manual on Samus. Trigger EC panic, verify that "Panic Reset in
previous boot" is seen in /var/log/eventlog.
BRANCH=Samus
Change-Id: Icf0d00a8cfc7aa788f3ceadd65fe3139f40df503
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252410
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds a new pair of interfaces called producer and consumer
which are simpler (in that they don't hold onto the underlying
queue) than the stream interfaces. This makes it easier to
share a single queue between the endpoints that will manipulate
it. It was not possible to share a queue between two objects
that implemented the in_stream and out_stream interfaces.
This also adds a pair of adaptors that can convert a producer
or consumer into a stream of the correct type. These adaptors
will be used for existing code once the usb-stream and usart
drivers are converted over to use the producer/consumer
interfaces instead of the stream interfaces.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I42b4b1ac15cca28e1adc6d3cea315f15e17a0b4d
Reviewed-on: https://chromium-review.googlesource.com/250941
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Add CONFIG_UART_INPUT_FILTER, which is undefined by default.
BUG=chrome-os-partner:36745
TEST=buildall for the case where it is not defined.
Added a filter function to the btle code on hadoken.
Tested reset, transmit test, receive test, test end, and test mode end.
BRANCH=None
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I3a9c067ffcb114449b61f468271a48491a8c7ec5
Reviewed-on: https://chromium-review.googlesource.com/250580
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
If a non-timer task event is received while in usleep, we will again
attempt to sleep for the entire duration. This can cause an infinite
sleep in cases where a periodic task event occurs. Fix this by checking
the HW clock for our elapsed duration.
BUG=chrome-os-partner:36864
TEST=Manual on Samus. Verify that we don't get stuck in usleep during
VCORE_PGOOD interrupt storm.
BRANCH=Samus
Change-Id: Ie3ab8ce3c22822095845a3d9a6f33bd4b1273c6e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251311
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently we set the input current limit to its maximum when the system
is unlocked, so that we can boot the system with a powerful charger when
the battery is absent. However, with a low power charger, we risk
browning out the charger. If the battery is present, reduce the input
current limit so that low power chargers work in this case.
BRANCH=None
BUG=None
TEST=On Ryu, reboot EC when the a low power charger is used. Without
this change, the charger browns out right after the reboot. With this
fix, the problem doesn't happen anymore.
Change-Id: I9d491cbe45e77f864198c97a47624918e6c272db
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/248442
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
For boards with unimplemented GPIOs, don't display those GPIOs in
the output of "gpioget" or accept them as signal names in "gpioset".
BUG=none
BRANCH=none
TEST=manual
Pick a board with an unimplemented GPIO (search board/*/gpio.inc
for UNIMPLEMENTED), run "gpioget" and "gpioset". It shouldn't
show up.
Change-Id: I343ece7d6df5fa09fda8418e3f3148d74f1540ae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251012
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If you use the "md" command to display lots of memory, it can
cause the watchdog to trip. This just pokes it every now and then
to be sure it's happy.
BUG=none
BRANCH=none
TEST=manual
Print a lot, see that it doesn't timeout:
md 0 0x4000
Change-Id: Ic4e2746c07f4fbdf922e87ea3efbe90b88ae08c9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251011
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix bug with the new CONFIG_SOFTWARE_PANIC where a watchdog
panic will write panic data after jump_data pointer is
calculated. Since jump data uses the same RAM location as
panic data (the end of RAM), we rely on panic data being
written BEFORE jump data pointer is calculated so that we
don't use the same RAM space.
BUG=chrome-os-partner:36871
BRANCH=samus
TEST=without this CL, can reproduce problem where jump data
is corrupted using samus with following steps:
1) hibernate 1 (this will clear panicinfo)
2) waitms 3000 (this will cause a watchdog reset)
3) let system boot to S0
4) sysjump rw
On sysjump to RW, the jump data will be corrupt because while
we were in RO panic data was added where there wasn't any before.
This means the jump_data pointer in RW will differ from the
jump_data pointer that was used in RO and we will fail to find
the magic jump data. Most visible consequence of this is that the
USB ports will be disabled after these steps because we use
jump data to store last state of USB port enables.
With this CL, following the steps above, the USB ports are restored
to the pre-sysjump state, which is enabled.
Change-Id: Ia129419db7400eddb54bcf57b4d4aed63d5c52ef
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251110
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use the EC to check if PD MCU has crashed. The EC knows this
by checking the PD status bits: if PD MCU was in RW, and is
now in RO, AND it did not get to RO via a sysjump, then it
must have crashed. When the EC detects this, the EC will also
panic and reboot the entire system, so that we can software
sync to a known good state.
Also, when EC panics due to PD crash, it will log panic info.
BUG=chrome-os-partner:36636
BRANCH=samus
TEST=load onto samus EC and PD, try sysjump'ing back and forth
on PD MCU console and verify EC does not do anything. Crash
the PD MCU when in RW by reboot command and crash divzero command,
and make sure the EC panics with PD crash panic message. Crash
the PD MCU when in RO (before sysjumping to RW) and make sure
EC does not panic.
Change-Id: I57961028e6b23a878b8e477a9d8e180cb121a742
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250100
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Make non-exception "software" panics such as stack overflow and assert
failure save a panic log. Log the panic type in r4, and misc. panic data
in r5 so that panic reasons can be distinguished.
BUG=chrome-os-partner:36744
TEST=Manual on samus_pd. Run 'crash divzero' then 'panicinfo' after
reboot. Verify that panic info is printed with "r4 :dead6660". Trigger
stack overflow, verify that panic info is printed with "r4 :dead6661".
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5f7a8eb0a5c2ac5799d29bb241deb24fabf38f68
Reviewed-on: https://chromium-review.googlesource.com/249912
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In locked RO, the PD state machine is crippled and unable to determine
whether a charger is dual-role capable. In order to charge in locked RO,
assume that all chargers are dedicated.
BUG=None
TEST=Manual on samus_pd. Lock system and reboot to RO. Insert Zinger and
verify that system charges 3A @ 5V.
BRANCH=Samus
Change-Id: I88a3ff248914cd95ebce8e9b91de1001c0f78b55
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250650
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds CONFIG_FAN_UPDATE_PERIOD to limit the frequency at which
the fan speeds are updated. Short version: the CPU core temp
fluctuates rapidly, causing the fans turn off and on annoyingly
often (assuming you have good hearing and are in a quiet room).
With this CL, we limit the speed changes to only once every N
seconds. N should be long enough to be less annoying, yet short
enough that the CPU doesn't overheat while we're not looking.
BUG=chrome-os-partner:34789
BRANCH=ToT,samus
TEST=manual
Let it sit quietly, then visit a busy webpage, then let it sit a
while. The fan speed should only change every 10 seconds or so,
not every second.
Change-Id: Id985350394f24d56dc4a1e51af09487ac643285b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add new charge_ramp module which works with charge_manager to
slowly increase input current limit in order to find the optimal
charging current. To do this it looks for either VBUS drooping
too low or for the charger to over-current.
BUG=chrome-os-partner:34946
BRANCH=samus
TEST=tested with a variety of BC1.2 chargers, type-C only chargers,
and PD chargers to make sure we always stabilize charging at an
appropriate current limit.
Change-Id: Icc95aa2738ddb221f163f91c14a342a0674f9e0f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247304
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Make new VBUS charge supplier for Samus and Ryu which allows
default 500mA charging when VBUS is present. Before this was
accomplished via the type-C supplier, but type-C supplier should
only be used for 1.5A and 3A pull-up. VBUS supplier is lowest
priority so that any other supplier will take precedence over
the default charging rate.
This work is done in preparation for charge_ramp module where
we don't want to ramp for typeC supplier.
BUG=chrome-os-partner:34946
BRANCH=samus
TEST=make sure we can boot without battery on samus, and test
other chargers including legacy chargers, zinger, and donette.
Change-Id: I89f1e9520e4bf9e5debbaf8dd2de1262154eecf8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250312
Reviewed-by: Shawn N <shawnn@chromium.org>
When we find that charging is in a wedged state, we may wish to write a
PD log entry, but the PD MCU cannot detect such a state on its own.
Therefore, add a new command to ask the PD MCU to write a log of a given
type, and add a new board-specific custom log event.
BUG=chrome-os-partner:36668
TEST=Manual on samus:
./ectool --dev=1 pdwritelog charge 0
./ectool --dev=1 pdwritelog charge 1
./ectool --dev=1 pdwritelog 1 0
./ectool --dev=1 pdwritelog 2 0
./ectool --dev=1 pdlog
Verify log output matches expectation:
2015-02-12 11:12:49.290 P0 SRC
2015-02-12 11:12:49.296 P1 SNK Charger PD 20286mV max 20000mV / 3000mA
2015-02-12 11:12:49.303 P0 New connection
2015-02-12 11:12:49.310 P0 Board-custom event
--- END OF LOG --
Also, verify kernel logging of wedged event:
[ 181.378420] PDLOG 2015/02/12 19:13:44.019 P0 Event 02 (0000) []
Also, trigger wedged state on Samus and verify log entry is written.
BRANCH=Samus
Change-Id: I55c7c839cf8300fcd3931dccdaaf16c1065e31a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
VCONN should be off at the start of pd task. This is handled
initially by the defaults in gpio.inc. However in the case of a
sysjump after a RW only firmware update the previous state would be
preserved.
This in turn would allow us to evaluate polarity incorrectly if an
accessory was connected in the CC2 polarity and subsequently enable
both VCONNs which would leave the port with both CCx lines at 3.3V.
This change adds a new function, pd_config_init, which initializes
VCONN(s) to off. Future CLs will evaluate other PD related GPIOs that
may be left unitialized as a result of sysjump.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. Boot samus w/ samus_pd in RO
2. connect hoho | dingdong in CC2 polarity to type-C port
3. sysjump to RW
4. unplug / plug hoho | dingdongs
No longer see both VCONNs enabled.
Change-Id: Ia53c06ea8face4da6829f9667f4f44a9034183be
Reviewed-on: https://chromium-review.googlesource.com/248831
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Previously, we tried to minimize log spew by keeping track of previous
log entries and not writing new entries in some cases. Instead, we can
write a log on the following events only:
1. A port becomes active or
2. A port becomes inactive or
3. The active charge port power limit changes or
4. Any supplier change on an inactive port
Also, make charge_manager_save_log a non-static charge manager API
function, so that other modules can record a log, if they have reason to
believe a port has changed outside of a charge manager change.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Make various power actions and observe logging.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5d5d3e186e85fdb1c59797ffbfb2f5a6ec04d94d
Reviewed-on: https://chromium-review.googlesource.com/247891
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Since charge manager is now informed of all capability changes as they
happen, it makes sense to store the port capability within charge manager,
rather than storing in pd.
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: I3669050b37ddd67f6608bf790a07e74f86b6ac01
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247724
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The debounce timer might be too slow to actually update the state of
debounced_power_pressed by the time we do power_button_is_pressed in the S3->S5
state transition. Solution is to move the power_button_wait_for_release function
here and make sure there are no deferreds active.
BUG=chrome-os-partner:35948
TEST=During dev mode screen, press power button, note the device stays off
TEST=Print debounced_power_pressed in power_button_is_pressed(void), note it's
not 0 when power button is actually pressed
BRANCH=veyron
Change-Id: I8258e9e5524bd65d6ea9c77ea5649304d2195bf0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244590
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a dual-role charger is plugged, we will not realize it is dual-role
until after we see a type-C charge source. It can cause us to briefly
charge from a dual-role charger, which has bad side effects related to
charge override and the lightbar. Fix this by not charging from a port
until we are fairly certain that it is a dedicated charger (based upon
PD discovery timeout).
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: Ia4154f34dd0a850b6e72bebadbd938f034532f14
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247130
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we power swap from a source to a sink and begin charging, VBUS will
never be marked as present, which has bad side-effects when VBUS
disappears and we wish to stop charging.
BUG=chrome-os-partner:36389
TEST=Manual on Samus. Connect Samus-to-Samus and initiate charge
override on the port. Verify that charging from the port begins. Unplug
the cable and verify that the in-OS charge icon disappears. Repeat 10x.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I83206c341c0d74991ad60eef411d71d30b5c67a5
Reviewed-on: https://chromium-review.googlesource.com/246781
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some EC chips (mec1322) use external SPI flash which is not mapped
into the EC CPU's address space. These must explicitly read data from
flash when calculating the vboot hash or reading the version string of
the image which isn't currently loaded into code RAM.
To test this bug, I used a board with known working mapped flash, and
temporarily patched it to act like it didn't have mapped flash.
Also add a flashread console command, useful for manually testing.
BUG=chrome-os-partner:35308
BRANCH=glower,strago
TEST=manual
1. Apply this patch to samus
2. Check result for 'vboot hash RW'
3. Check result for 'version'
4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and
#define CONFIG_CMD_FLASH
4b. In chip/lm4/flash.c, add the following:
int flash_physical_read(int offset, int size, char *data)
{
const char *src;
if (offset > CONFIG_FLASH_SIZE ||
offset + size > CONFIG_FLASH_SIZE)
return EC_ERROR_INVAL;
src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset);
memcpy(data, src, size);
return EC_SUCCESS;
}
Steps 4a,4b will make the LM4 chip act like it doesn't have
memory-mapped flash.
5. From the dev system, util/flash_ec --board=samus --ro
6. Check result for 'vboot hash RW'. Should be same as 2.
7. Check result for 'version' for RW version. Should be same as in 3.
8. From the dev system, util/flash_ec --board=samus
9. sysjump rw
10. Check result for 'version' for RO version. Should be same as in 3.
11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results
should be the same (but endian-swapped, since flashread is byte
ordered and md is 32-bit ordered).
12. Revert changes from steps 4a-4b.
Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246200
Reviewed-by: Shawn N <shawnn@chromium.org>
Motion sense calculations do not require huge amounts of precision, so
fixed point is plenty accurate. And fixed point works on Cortex-M0,
which lacks a FPU.
BUG=chrome-os-partner:36126
BRANCH=minnie (samus already works with the FPU, but could grab this if we
want additional testing)
TEST=manual
1. Boot system
2. At EC console: accelinfo on 250
3. Move lid through several different angles (30 degrees to max open) and
see that it updates correctly and relatively smoothly. A few degrees
of angle jitter is normal.
4. At several angles, rotate the chromebook around and see that the lid
angle remains relatively stable.
5. If the hinge is made normal to the ground (or within 15 degrees of
vertical), the angle should read 500, since the acceleration vectors
don't yield good results in that orientation (for either fixed or float
math).
And run 'make buildall -j', which tests arc_cos() and lid angle calculations
Change-Id: I70a0d08b8914629a3e21ae5578cbe8e50f29ad68
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244116
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Fix bug on samus that the battery status doesn't always show on
lightbar when AC is plugged/unplugged. It doesn't show when the
battery is full is S3 or S5 because in these states we turn off
CHARGE_EN so that ACOK to the EC never toggles.
Instead, what we want to do is display battery status whenever the
active charge port changes. This will happen when AC is plugged or
unplugged OR if a user has AC on both ports and toggles between
them using the charge override hot-keys.
BUG=chrome-os-partner:36317
BRANCH=samus
TEST=test plugging and unplugging AC on both sides when battery is
full and unit is in S0, and when unit is in S5. also tested lightbar
flashes battery percentage when two zingers are plugged in and you
switch between them using Ctrl+Search+0|1|2.
Change-Id: I5cd7fff4f466adf857f1e63f07f3b0c7ae8422c7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245922
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Occasionally the charge circuit on samus gets wedged and will not
charge. This change detects when the charge circuit has failed
and automatically recovers from it. It uses the BQ PROCHOT warning
to detect the failure by setting PROCHOT to trigger when the BQ
thinks input current is higher than the input current limit. When
the failure is detected, the EC disables charging and tells PD MCU
to disable CHARGE_EN, then a couple seconds later, it re-enables
charging.
This CL also adds more communication between EC and PD for the EC
to be able to set the charge state for the PD. Valid charge states
are: No charging allowed, 5V charging only, and max charging. The
EC uses this as such:
- When the EC gets AC present interrupt, it sets off a deferred
function to change charge state to max charging after some delay
to give time for the charge circuit to settle down.
- When the EC gets AC disconnect interrupt, it disables charging
briefly, enables learn mode, and then sets 5V charging allowed.
This allows for the same starting conditions in the charge circuit
for every AC attach.
- When the EC detects a wedged charge circuit, it disables charging
and waits a few seconds before re-enabling 5V only charging.
Additionally, this change moves the charging cutoff in S3/S5/G3 when
the battery is full to the EC. With the added control for the EC
to set the PD charging state, it is more convenient for the EC to
manage cutting off charging when battery is full.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test the basics:
- connect/disconnect zinger a bunch of times
- connect and disconnect two zingers in different order
- connect two zingers and charge override between the two
test the automatic charge wedge recover:
- wedge the charge circuit by setting charger voltage under battery
voltage: "charger voltage 7000"
- wait a few seconds for the system to recover and check it is charging
with "battery" command
test full battery charge cutoff:
- added console command to change battery soc in board/samus/extpower.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
battery_soc = strtoi(argv[1], &e, 10);
batt_soc_change();
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, "", "", NULL);
- in S0, tested "battfake 100" does not disable charging.
- in G3, tested "battfake 100" disables charging and "battfake 99"
re-enables charging.
- set "battfake 100" and tested transitioning to S0 enables charging and
transitioning to S5 disables charging.
- attached two chargers and used charge override to select active port.
then toggled "battfake 100" to "battfake 99" back and forth and verified
charge override port is still the same.
test third-party 12V charger:
- plug in a bunch of times and make sure we stay at 5V for 500ms and then
transition to 12V
test with no battery:
- tested five different units with no battery and just zinger. 3/5 boot,
while the other 2 don't. But, the 2 that don't boot without battery also
can't boot w/o battery when this CL is reverted, so I don't think this
change is causing the problem, I think there is an electrical limitation.
test with EVT zinger:
- EVT zingers (P2 - C2) negotiate very quickly after connection, which
can cause INA problems w/o this CL. Tested an EVT zinger with samus and
did a bunch of connections and disconnections and verified that we always
wait at 5V for 500ms and that we don't wedge the INA circuit on connect.
test backwards compatibility:
- test new PD with old EC and make sure we can charge with zinger.
(note that if the charge circuit wedges, we won't be able to unwedge it).
- test old PD with new EC and make sure we can charge with zinger.
Change-Id: I7703b7a2ab1209d7f559b265b03517e79c74b16a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245253
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add hook for battery state of charge change. Hook will be used
to cleanup the samus charging workarounds to follow.
BUG=none
BRANCH=samus
TEST=make -j buildall
Change-Id: I99cbb8264783802139cac689804b056623063695
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245252
Reviewed-by: Shawn N <shawnn@chromium.org>
Ignore battery readings over 100%. This fixes a samus bug
where a false battery SOC reading causes charging to
stop.
BUG=chrome-os-partner:36115, chrome-os-partner:36081
BRANCH=samus
TEST=add following code to common/smart.c:
static int reset_soc;
in battery_get_params():
if (reset_soc) {
batt_new.state_of_charge = 65535;
reset_soc = 0;
}
after battery_get_params():
static int command_battsoc(int argc, char **argv)
{
reset_soc = 1;
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battsoc, command_battsoc,
"",
"",
NULL);
This changes the battery state of charge to 65535% for one
loop through charge state machine. w/o this CL, on samus the
battery stops charging when you call this, but with this CL
it is fixed.
Change-Id: I44f054a4e84260bd7cd7b77e44b1698645ab6c35
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244346
Reviewed-by: Shawn N <shawnn@chromium.org>
