Up until now, every image includes the time of compilation in the
build information. This makes it impossible to verify that a
particular image came from a particular source code snapshot.
With this change, specifying USE_GIT_DATE=1 to the make command
will use the author date of HEAD as the timestamp. That means
that successive builds from the same source will produce
bitwise-identical output (assuming the same toolchain, of
course).
BUG=none
BRANCH=none
TEST=manual
Do this twice:
\rm -rf build
make BOARD=cr50 USE_GIT_DATE=1
md5sum build/cr50/ec.bin
The md5sum should be the same for both runs.
Change-Id: If64307101a453cb13c62fa003f1bf432f4998273
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252751
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
We put each assembly function in its own section. So the sections for
64-bit signed and unsigned divide end up too far apart for b<cond>
(8-bit delta) or b (11-bit delta). Instead, use bl, which has no such
limit. This is a little less efficient in the case where numerator
and denominator are both positive, but equivalent if either or both is
negative, and is far outweighed by the cost of the unsigned divide
itself.
The other alternative would be to put both uldivmod and ldivmod in the
same section. However, we're often tight on code size on cortex-M0
parts, so that's less desirable.
BUG=chrome-os-partner:26126
BRANCH=minnie
TEST=add the following function
static int command_divtest(int argc, char **argv)
{
int64_t a, b, c;
char *e;
if (argc < 2)
return EC_ERROR_PARAM_COUNT;
a = strtoi(argv[1], &e, 0);
b = strtoi(argv[2], &e, 0);
c = a / b;
ccprintf("%d / %d = %d\n", (int)a, (int)b, (int)c);
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(dt, command_divtest,
"a b",
"Divide test",
NULL);
and test with divides in all 4 quadrants (+/- 20 divided by +/- 5,
for example)
Change-Id: I2a5e49c4534044c2f509e325f8dd6bdf10b544c4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252243
Reviewed-by: Alec Berg <alecaberg@chromium.org>
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>
Make sure the EC sends the battery state of charge to the PD every
time it changes.
BUG=none
BRANCH=samus
TEST=create command to fake battery percentage in
driver/battery/smart.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
if (argc > 1)
batt_fake = strtoi(argv[1], &e, 0);
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, NULL, "", NULL);
and in battery_get_params():
if (batt_cap > -1)
batt_new.remaining_capacity = batt_cap;
On samus use battfake command to change battery percentage back and
forth every few seconds for minutes and make sure the PD receives
host command 0x100 and that it is still happy.
Change-Id: Ic69ab2af900fa2a38e3d2f6562675684487f556e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252350
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously the STM32F3 support was non-functional due to
it being a cut and paste of the STM32F0, and the clocks
are not set up the same way on the two platforms. Also,
the STM32F initialization code was incorrectly calling
the F0/L buad rate setup code.
This change has the variant specific USART code pass the
input frequency to the baud rate divisor clock to the
baud rate setup code, instead of that code calling
clock_get_freq() to determine the input clock frequency.
This is required because the STM32F3 is not configured
such that the clock_get_freq value and the input to
the USART baud rate divisor match.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify USART works on discovery as well as Ryu
Change-Id: I71248d83b53969d0e7020747a9bb9570803f30ac
Reviewed-on: https://chromium-review.googlesource.com/250920
Reviewed-by: Vic Yang <victoryang@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
Change USB type-A ports to default to CDP. The port will
automatically revert back to SDP if it needs to.
BUG=chrome-os-partner:36876
BRANCH=samus
TEST=load on samus, make sure ports advertise as CDP by
connecting A to C port to charge itself (note this causes
other problems, but good enough to make sure we detect
CDP).
Change-Id: Ic09b31788557d2c6ff4292c62a2ac0168b136c64
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251834
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix bug in RTC module for stm32f0 in which it doesn't handle the
24 hour rollover appropriately and can cause a watchdog reset
if in deep sleep during rollover.
BUG=chrome-os-partner:36920
BRANCH=samus
TEST=add line to rtc_init()
STM32_RTC_TR = 0x00235952
This initializes RTC clock to 8 seconds before rollover. Using samus
make sure unit is allowed to go to deep sleep (S3/S5 and not charging)
and see that without this CL we watchdog most of the time, and with
this CL we don't watchdog ever.
Change-Id: I3f4b4b1ab7b2be1d4e344477d5eaaa0dc916773a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251852
Reviewed-by: Alexandru Stan <amstan@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.
BUG=chrome-os-partner:34946
BRANCH=none
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: I63d4ba38f2e137aff32831386f1bde2cc7c57850
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249934
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Depending on the hardware, each ADC channel may need a different
sampling time. To keep things simple, let's allow per-board ADC sampling
time configuration instead of per-channel configuration.
BRANCH=Ryu
BUG=None
TEST=Configure sampling time to 3 and measure IADP on Ryu P4 and check
it's more accurate.
Change-Id: I3c1eeea22439c0340f84fdeb3624fc84450358ca
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/251701
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
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>
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>
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>
