Add charge ramp module to samus. For BC1.2 DCPs allow ramping
up to 2A, and for BC1.2 SDPs allow ramping to 1A.
Charge ramp is disabled when in RO and write protected.
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.
tested in RO and write protected, BC1.2 chargers do not ramp. when
you jump to RW it does ramp.
Change-Id: I7c36c8fb0a34139c69a475307c325f891099b3dd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249933
Reviewed-by: Shawn N <shawnn@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>
Change unwedge code to not attempt unwedging circuit if VBUS is
at 5V because the circuit can't wedge itself at 5V. If BQ PROCHOT
is high, we should just read it to clear it, and move on.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test with ramp code. make sure ramp never gets stuck at
minimum value because we are in the middle of unwedging the
circuit when ramp starts.
also test that manually wedging charge circuit with zinger using
"charger voltage 7000" is still recovered from.
Change-Id: I209bf324eab39bdca1948b7764870a909ea480c8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250463
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix booting without battery by avoiding waking the extpower task
until it has run extpower_board_hacks() the first time.
The problem was if there was no battery and AC was attached,
extpower_board_hacks() would run twice on boot, once in extpower
task initialization, before the while(1) loop, and a second time
due to the AC_PRESENT interrupt. This would cause
extpower_board_hacks() to think that AC had transitioned from 1
to 1, which represents a glitch on ACOK, so it would disable
charging, thus causing us to lose power.
BUG=chrome-os-partner:35570
BRANCH=samus
TEST=load on a samus and boot with and without battery
Change-Id: Idf6d0022f7dbedbb66a2fbe1c2b7dd885eabc43b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250301
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The switch to PID namespaces inside the chroot broke flash_ec's ability
to detect (and then kill) other processes that use the EC serial PTY
(leading to potential flashing failures). After a long discussion we
decided that users who need features like this should be forced to run
their chroot without PID namespacing (using cros_sdk --no-ns-pid). This
patch adds a hard check for this to flash_ec, so that using it in an
unsafe way becomes impossible.
In addition, this ports the more advanced SIGSTOP/SIGCONT logic to
flash_ec that was pioneered in fwgdb. With this, other processes
accessing that PTY will just freeze and become available again after
flash_ec finished.
BRANCH=none
BUG=chromium:444931
TEST=Ran on a Jerry with and without --no-ns-pid, with and without
an open EC terminal, all results as expected.
Change-Id: I45ffc3ec6cfe9c25a0b82b4d5288a41485c326c4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249835
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A change to the toolchain or environment surfaced an issue where the writes to
packet RAM were being split into two 16-bit writes. This was interacting
poorly with the AHB2APB bridge.
Marking the packet RAM destination pointer volatile forces the compiler to use
full 32-bit writes.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Check that Ryu's console is accessible over USB
Change-Id: I0c3db08c704389a627570b90ef97bce81ab553fa
Reviewed-on: https://chromium-review.googlesource.com/248840
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Change the idle task overslept warning printf to save stack space.
The current warning uses CPRINTF which adds too much to the stack
and overflows the idle stack.
BUG=chrome-os-partner:33138, chrome-os-partner:36636
BRANCH=samus
TEST=comment out the if (margin_us < 0) check and always print
warning message. Without this CL stack overflows. With this CL,
stack does not overflow and gets to 168/256, which is plenty of
headroom considering the task doesn't do much.
Change-Id: I19a8336b8584d2a1342e7b9290aad471d326a060
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250300
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Increase extpower task stack size due to occasional stack
overflow in extpower task on plugging/unpluggin AC.
BUG=chrome-os-partner:36760
BRANCH=samus
TEST=load onto samus, connect/disconnect a bunch of times
and check high water mark on stack usage: 368/512
Change-Id: I4531176ce6f15356a2267cdecf907a7694567da9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249920
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>
This is another workaround for charge circuit wedging. It appears
that the BQ PROCHOT is not entirely reliable at detecting charge
circuit wedged, so let's take a big hammer to this and say if
we have a >5V charger and we haven't been charging for a while,
then attempt to unwedge the charge circuit. Only impact on user
is the battery won't charge quite as fast since we stop charging
briefly to unwedge the circuit.
BUG=chrome-os-partner:36081, chrome-os-partner:36620
BUG=chrome-os-partner:36636
BRANCH=samus
TEST=remove the PROCHOT check and wedge the circuit using "charger
voltage 7000" and make sure that we unwedge after 10s (or 2min
if we never recovered from last time).
Change-Id: I6a0d83aef5fcfdecaeb85367d8207aeea7a99c06
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248940
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@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>
If 2 interrupts happen at the same time, there is a chance that the nested
interrupt will not call svc_handler when it needs to. In extreme cases this
could lead to tasks not getting woken up when they're supposed to and watchdog
resetting.
The reason stuff worked was because there were enough other interrupts
around to eventually call the scheduler and switch to the ready task.
This change modifies the interrupt calls to not call the scheduler directly
(because in nested interrupt situation this causes problems), but defer the
call to scheduling until after the irq finishes by triggering a low priority
interrupt which will for sure call svc_host at the end. The PendSV irq was
used for this purpose.
BUG=chrome-os-partner:36193
TEST=No more SPI errors caused by scheduler problems
TEST=usleeps now are more accurate, they're guaranteed to not take forever now
BRANCH=veyron
Change-Id: I42acde6b3eb7be2540a0de9a8562dee2ea2be7ab
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248902
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Divide-by-0 was jumping to a missing __aeabi_ldiv0 label. Add it,
equivalent to the cortex-m code.
BUG=chrome-os-partner:36126
BRANCH=minnie
TEST=hack into main():
volatile uint64_t a = 1, b = 2;
a /= b;
and see that code compiles.
Change-Id: I93884c6e41c8a3c5f47c141c323860efbfbc9ba9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248640
Reviewed-by: Daisuke Nojiri <dnojiri@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>
Fix bug recently introduced in 1ab9aac that causes some units to not
charge after an EC reboot with zinger plugged in. The problem is that
we don't log the previous state of ACOK on initialization of the
extpower task. So, the PD MCU gets stuck in charge state NONE when
you unplug zinger because the EC thinks that ACOK transitioned from
low to low.
Fixed in two ways: first, the EC stores the initial state of ACOK when
extpower task first runs. second, changed extpower_board_hacks() to
run the same code when ACOK goes from low to low as it does when it
goes high to low.
BUG=chrome-os-partner:36596
BRANCH=samus
TEST=Found a unit that reliably shows the problem. loaded this fix in
RO and ToT in RW. sysjump RW with AC plugged in, then when you unplug
AC, the PD goes to chgstate NONE and won't ever charge on subsequent
attaches. sysjump RO with AC plugged in, then when you unplug AC, the
PD acts as normal and goes to chgstate NONE and then 5V, and will
allow charging every time AC is subsequently attached.
Change-Id: I4124535b17d43a5711586ff2894df67a3bd49ec6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248170
Reviewed-by: Shawn N <shawnn@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>
This is to add llama board support:
- new files in board/llama folder, including battery.c and led.c
- new file power/mediatek.c, which is mostly based on power/tegra.c
- modified flash_ec for llama board
- disable tests for llama board.
BRANCH=none
BUG=none
TEST=make BOARD=llama
Change-Id: Ie1ae068c1a402f08e1449668b1be8f31105bb804
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/243510
Reviewed-by: Rong Chang <rongchang@chromium.org>
Tested-by: lok.ben ben.mtk <ben.lok.mtk@gmail.com>
Commit-Queue: lok.ben ben.mtk <ben.lok.mtk@gmail.com>
The STM32 bootloader reacts to the first command it sees and then sticks
to that interface. On some devices, the AP is connected to I2C or UART
on the EC, and if the AP talks when we are trying to flash the EC, the
EC sticks to that interface and ignores requests from the servo board.
Fix this by holding warm_reset so that the AP is down.
BRANCH=None
BUG=None
TEST=Flash Ryu several times.
TEST=Flash Plankton to make sure it doesn't break devices without
warm_reset.
Change-Id: I860fc65ba7fdaf0cbc9a0be641148b5095de394b
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247360
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Commit-Queue: Vic Yang <victoryang@chromium.org>
This includes:
- Enabling SBU path for debug USB usage in USB mode (not in DP mode)
- Add a console command to enable DFU mode for lab devices. This
requires the additional Silego chip on the device.
BRANCH=None
BUG=None
TEST=Hook up a Ryu with the additional Silego chip. Issue 'dfu' command
and see DFU device in 'lsusb' output. Issue the command again and the
device goes away.
Change-Id: I3f942c6abe52784351f2242c9b0b6400e9b2b6fd
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247350
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Bug fix for the new samus charging software workarounds. The problem
occurs occasionally, especially with 5V chargers, and causes the
new software workarounds to get out of sync with the actualy state
of the charging circuit such that when ACOK actually goes high, we
stop charging, and then when ACOK goes low we start charging, and
we end up in a high frequency loop of enabling/disabling charging.
The fix is to add a 100ms delay when ACOK goes low before allowing
charging again. This guarantees that the circuit will settle down
before we try charging again.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=can reproduce with an EVT2 samus connected to a DVT samus at
~15% battery. On the DVT samus, allow charging from the other other
samus with charge override. Without this change, most of the time
the PD console goes back and forth between enabling and disabling
charging. With this change, we don't can actually charge briefly,
although there is still a problem where VBUS can dip too low and
cause ACOK to actually go low.
Change-Id: If83def862fb58ef3938e2a443e1a081bd27713ec
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247460
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@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>
On some systems, recovering from charge circuit being wedged doesn't
happen immediately, and we end up constantly detecting charge circuit
wedged problems and recovering from it. This CL adds a counter to
check_charge_wedged() and reads PROCHOT but does not trigger the
charge circuit wedged until after a certain number of checks after
the last charge wedged condition. This allows more time for the
condition to magically go away before intervening.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=found two units that were regularly detecting charge circuit
wedged and recovering from it (every 4 seconds, 2 seconds before
detecting the issue and 2 seconds to recover). on one unit, the
problem went away on its own. On the second unit, I loaded this CL
into RO, and ToT in RW, then verified that RO does not continually
trigger charge circuit wedged problems, while RW still does.
Change-Id: I4c4e5c52ad382f178696d61c7b36faf9e8978926
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247160
Reviewed-by: Duncan Laurie <dlaurie@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>
With DBC, the backlight transitions are fairly perceptible at low
brightness levels. Smoothing out backlight transitions over a 200ms
period makes these far less perceptible.
BRANCH=samus
BUG=chrome-os-partner:36245
TEST=The following command should read back the value of 0xe7 after
system boot, resume as well as after panel off/on sequence:
ectool --dev=0 i2cread 8 0 0x58 0x15
Change-Id: Ia24b87a0ead179d968cfc1239be757c1822450e4
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246741
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
REG_CONTROL has two sets of reserved bits:
- Bits 5 thru 7 are read x, write 0.
- Bits 1 and 3 have undocumented function and should not be changed from
read value.
BUG=chrome-os-partner:36360
TEST=Manual on Samus. Cold boot unit and insert 2.4A charger. Verify
that charger is correctly detected.
BRANCH=Samus
Change-Id: I240d352817910eda404b72be13e2c913a4b76079
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246560
Reviewed-by: Alec Berg <alecaberg@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>
These are needed for fixed-point math calculations.
Taken from the same public repo where we got the 32-bit divide
routines for Cortex-M0. With minor modifications to match changes
we've made so far for the existing divide routines (put each function
in its own section, delete dead code, etc.)
BUG=chrome-os-partner:36126
BRANCH=minnie
TEST=hack in a debug console command to allow arbitrary int64 divide, see that
it works as expected
Change-Id: I987dbca7c806c71bc38fa816971ac3a54c1641a5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244501
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>
When INA doesn't have power, in order to unwedge it properly,
we need to disable charing AND enable learn mode to disable the
BQ. Without turning on learn mode, the BQ can backboost and
cause ACOK to remain high.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=load on a samus and test getting the INA wedged using
"charger voltage 7000" and make sure it recovers all the time.
Change-Id: Icc4c508f9db1210e2384cb741a33f50afee191e7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245841
Reviewed-by: Duncan Laurie <dlaurie@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>
Non-SDP ports can be identified as SDP on slow plug insertion. To ensure
no long-term misdetection, automatically do a single re-detection 30
seconds after detecting an SDP port.
BUG=chrome-os-partner:36166
TEST=Manual on Samus. Slow-plug a 1A Apple charger, verify that
detection is originally 500mA. After 30s, verify that detection becomes
1000mA. Also verify that only one additional re-detection is triggered.
BRANCH=Samus
Change-Id: I2babaecdf2252436d1f6b35f5654c14eff9c526b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245153
Reviewed-by: Alec Berg <alecaberg@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>
mcdp_info is a logging payload, so related structures need to be moved
to the public include file.
BUG=chrome-os-partner:35935
TEST=make buildall -j
BRANCH=Samus
Change-Id: Idb939db884821fa85faafbfe643e713f5bcdbc59
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244780
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Alex did the reset workaround in power_on function.
<https://chromium-review.googlesource.com/#/c/214360/>
Now, the new version RK808 has fixed this issue, so we needn't this
workaround.
BUG=chrome-os-partner:35976
BRANCH=veyron
TEST=The BUCK1_ON_VSEL register default value is 0x18, and coreboot and
kernel will change this register to other value, but never set 0x18 to
it. So we can read this register in coreboot and print out to console to
check whether the RK808 reset to default after cold reboot. With this
patch, the value always reset to 0x18. I have test on jerry, mighty,
speedy.
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Power up system: it should power back up
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Press refresh-power: system should reboot
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Shut down and power back up.
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Press refresh-power: system should reboot
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
Change-Id: Icfdd3a7eeadce2c597bf286b36bea0aa58cfe4c4
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243202
Reviewed-by: Douglas Anderson <dianders@chromium.org>
When inductive charging just starts, there might be a blip on
CHARGE_DONE signal and it'd cause our charging control logic to shut
down charging. Fix this by waiting for a second before we start
monitoring CHARGE_DONE.
Also, once we see CHARGE_DONE=1 and disable charging, CHARGE_DONE will
go low. Handle this by ignoring all subsequent CHARGE_DONE change until
the next time the lid is opened.
BRANCH=Ryu
BUG=None
TEST=Pass the updated unit test.
TEST=Charge a base on Ryu P3.
Change-Id: I9d911cd689d8e88ebcd66e6eca7c86dd70704880
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/243365
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
