| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=samus
BUG=chrome-os-partner:37264
TEST=manual,
ectool --name cros_pd pdsetmode 0 0xff01 1 0 successfully exits displayPort
mode again.
Change-Id: Ica2faf8de92460f01c2af9be829795c0cd538135
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254990
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 5e9eb3263d4f47f006f7b8e4eeaadd229a8df611)
Reviewed-on: https://chromium-review.googlesource.com/255130
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove resetting pericom 30 seconds after detecting SDP. This
is not helpful anymore since we have fixed pericom detection
problems and have a charge ramp for SDPs.
BUG=chrome-os-partner:36813
BRANCH=samus
TEST=connect samus A port to samus C port. this detects as
SDP and ramps to 1A, but every 30 seconds resets the pericom.
with this change it detects SDP, ramps to 1A and stays constant.
Change-Id: I2400a06d237cef8c03f921960954dcf54d93de1e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251583
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VCORE_PGOOD signal to the EC goes through a buffer which is
powered by PP1050_VCCST that itself is gated by SLP_S3. Until
this point the input is invalid and may be oscillating so only
enable it as an interrupt once we are in S3->S0 state.
BUG=chrome-os-partner:36864
BRANCH=samus
TEST=boot on samus to ensure power sequencing still works properly
Change-Id: I90ad3b578297a5194c110407be1cba2d65226290
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251324
Reviewed-by: Alec Berg <alecaberg@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we have RAM to spare, increase the stack sizes of certain tasks
that may come close to stack overflow.
BUG=chrome-os-partner:36914
TEST=Manual on samus / samus_pd. Run task_info, verify new task stack
sizes.
BRANCH=Samus
Change-Id: Id667f963bffbf7776e7cbe07b7e7d34f4ac27398
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251420
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Auto select a battery firmware image based on the current "battery info."
sprintf(auto_image_name,"/lib/firmware/battery/maker.%04X.hwid.%04X.bin"
maker_id, hardware_id);
BUG=chrome-os-partner:24741
BRANCH=glimmer
TEST=Verified Simplo Battery Update on glimmer
Change-Id: Ie6b2f797a4629fdde3a45e9a6a83c4568655db7a
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250130
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add i2c retries to backlight control. Also check return value,
if i2c transfer fails, do not continue.
Also modified backlight control so that we only send I2C commands
when backlight chip is enabled (in S0 and lid is open).
BUG=chrome-os-partner:36803
BRANCH=samus
TEST=test suspend/resume and booting and make sure panel always
comes up.
Change-Id: I0dd71c12d0c3f64a08fb389c37f64b1b0ac16fb8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250670
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This separates the configuration of the ARM core GPIOs from the
routing of internal peripherals to external pins. Both are still
described in the gpio.inc file, but are less dependent on each
other.
BUG=chrome-os-partner:33818
BRANCH=none
TEST=manual
Before this CL, running "sysjump rw" or trying to use more than 8
GPIOs caused hangs and reboots. Now it doesn't.
Change-Id: If962a7c5ad4136837b2ea00ae016a440f07d7e23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251015
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the default build target creates .hex files, emit
the complete ec.hex output as well as the RO and RW halves.
BUG=none
BRANCH=none
TEST=make BOARD=cr50
Change-Id: Ia87bbace29d89695ef6a9c090c895ca10f14d919
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251014
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the struct gpio_info to use uint32_t for the mask field,
instead of signed integer.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I8cc7e3d06a00bd3c890522a896e36e1eb18a862e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251013
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove task_resched_if_needed, since we don't do any task scheduling
modifications. Just return instead.
This makes it work on F0 as well, where we don't have task_resched_if_needed
BUG=None
TEST=With series, see watchdog help work on any veyron
BRANCH=veyron
Change-Id: I93cce722b6d53008b015c7cdd56b7e77dc07bbff
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242713
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 8363dfb14cb36fca412132ab14d2c9451de7d94e)
Reviewed-on: https://chromium-review.googlesource.com/250671
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix complile bug, initialize local var boostin_voltage.
BUG=none
BRANCH=samus
TEST=make -j buildall
Change-Id: Ie178d3bfe164fc900b1c52a05412f75d5a090ddd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250820
(cherry picked from commit 54f01a6c030ed7608a4bf0d673740a0dca24a52f)
Reviewed-on: https://chromium-review.googlesource.com/250821
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The wrong constant was used in the previous commit.
BUG=chrome-os-partner:36744
TEST=None
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I74e365b00adb6909a4940229647f9aecebe5e0b1
Reviewed-on: https://chromium-review.googlesource.com/250700
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disable the i2cscan console command by default to save space
BUG=none
BRANCH=samus
TEST=make -j buildall
From .map file, 512 bytes of flash saved
Change-Id: I4bcb50b00e843abbc3523a3e0d4cc599a1e01d3a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249850
Reviewed-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To save flash space, disable "idlestats" console command on samus_pd.
This saves 384 B of flash
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34489
TEST=make buildall and check firmware size.
=== build/samus_pd/ BASELINE ===
FLASH 57.8k / 60.0k [ text 48.0k rodat 9.7k data 0.1k ]
RAM 11.8k / 16.0k [ data 0.1k bss 11.7k ]
=== #undef CONFIG_CMD_IDLE_STATS ===
FLASH 57.4k / 60.0k [ text 47.9k rodat 9.4k data 0.1k ]
RAM 11.8k / 16.0k [ data 0.1k bss 11.7k ]
Change-Id: Iba9654a88ec195026945881bc2687a1e67747706
Reviewed-on: https://chromium-review.googlesource.com/241452
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes an additional call to board_set_usb_mux to
ensure that the USB lines are correctly muxed for Case
Closed Debugging to work.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I80694a1bc6cabb9c2ac2437552a68210855e94f0
Reviewed-on: https://chromium-review.googlesource.com/247722
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the Case Closed Debugging system provided a
way for the board to connect and disconnect the CCD USB
lines correctly, but this functionality is better
implemented by board_set_usb_mux.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I697ee9740c64ac93557d9fca8b2d10e858c51193
Reviewed-on: https://chromium-review.googlesource.com/247721
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I8ec4396370b7e3068d29d569b73fddc648e1f76f
Reviewed-on: https://chromium-review.googlesource.com/247720
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need a dummy read after enabling AHB peripheral clock before we can
access the peripheral. For APB, we also need a dummy read for STM32F3.
BRANCH=All affected
BUG=chrome-os-partner:33007
TEST=make buildall
Change-Id: I47f4a024dca294f555428c3f2053c1d32835ebe0
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/246181
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LRESET# interrupt should be GIRQ19 bit 0 instead of bit 1.
BRANCH=None
BUG=chrome-os-partner:36326
TEST=Run on Glower and doesn't see LRESET# interrupt storm.
Change-Id: I1adedea63e9ec2851e1e09fc8c0eb8185070dad1
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247790
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just so that we can program the EC more conveniently.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Program a Glower.
Change-Id: Iaba0839c4a5b8dee805f7d31e4049198ce43918f
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247142
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|