Add the proper checks to be able to compile source-only PD devices with
the common runtime.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:37078
TEST=make buildall
build honeybuns without CONFIG_USB_PD_DUAL_ROLE defined
Change-Id: I7ad0b39b2e62736117ec2d7b5163502afbf14786
Reviewed-on: https://chromium-review.googlesource.com/259112
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The Rp resistor on CC1 is set for a 3.0A capability,
so Vnc (no-connection voltage) is 2.45 V.
CC2 is not connected (captive cable), so for a PD source, it's identical
to being always pulled-up to 3.3V (no sink connection).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:37078
TEST=connect to Samus and see PD activity
Change-Id: I8df0561cea59896d65d9be6523d4eed953851129
Reviewed-on: https://chromium-review.googlesource.com/259301
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Modified version of /board/fruitpie.
Attempted to capture GPIO definitions. Other changes
consisted of modifying functions to enable compilation.
No real functionality as of yet.
TEST=Serial console and I2C functions have been verified
BUG=chrome-os-partner:37078
BRANCH=samus
Change-Id: Iedfc724a058e4220176193ef0f66e5bf45eabbd9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252426
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
W25X40 uses a different protection register encoding than our existing
W25Q64 code. Move the SPI ROM option to a config, and add support for
the new part.
BUG=chrome-os-partner:37688
TEST=`make buildall -j`. W25X40 protection code tested in a subsequent
commit.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8
Reviewed-on: https://chromium-review.googlesource.com/258440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously the EC UART connected to the SensorHub console
was being driven push/pull potentially fighting with a
connected servo. This way servo wins, but at least we
don't drive the line in opposite directions causing a
large current flow.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I02b8e09af6c902b523494b757f4bc7ea4365df2e
Reviewed-on: https://chromium-review.googlesource.com/255954
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
1. Override the panel backlight enable signal from SoC in llama board,
force the backlight off on lid close.
2. Revise the function llama_lid_event to mtk_lid_event, makes more sense.
BRANCH=master
BUG=none
TEST=lid switch to open/close, observe the LCD backlight behavior.
the backlight should be off, when lid is close.
the backlight should be on, when lid is open.
BOARD=llama
Change-Id: Id1bff440c8bb6cee19c82615e916b8a2f2aa62ac
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
(cherry picked from commit a90516b0a5493a55536e29d550f65cc743156710)
Reviewed-on: https://chromium-review.googlesource.com/255441
Reviewed-by: Rong Chang <rongchang@chromium.org>
Modify charge ramp so that when it ramps it ramps from 500mA and
up to the maximum allowed by that supplier. Also modify Samus and
Ryu to use charge ramping for CDP and proprietary chargers due
to the possibility that they may not be able to supply the amount
that is supposed to be guaranteed by their advertisement.
BUG=chrome-os-partner:37549
BRANCH=samus
TEST=test on a proprietary charger, make sure we can ramp. test
a DCP and make sure we also ramp as before.
Change-Id: I08fd43c8f0b21aa54d114fbe5a1296c9556357e4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256972
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Clear all lightbar segments first before starting konami sequence.
If currently displaying Google colors, we need this so the start
of the sequence shows up correctly.
BUG=chrome-os-partner:37469
BRANCH=samus
TEST=from S0 with google colors on lightbar, run "lightbar seq konami"
from EC console and make sure 1st and 4th segments are cleared before
starting konami sequence.
Change-Id: I92ba8f29414c279895658167f8d5958fe49ea034
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256192
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
mec1322 projects are running very low on flash space. We don't yet have
a loader to load either RO or RW at runtime, so remove the RO image
entirely. This is a temporary change and should be reverted once we have
a working loader.
BUG=chrome-os-partner:37510
TEST=make buildall -j
BRANCH=None
Change-Id: I8c502ec2bcabf246d5a3ea939f1a8d0c366acd9f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256381
Reviewed-by: Vic Yang <victoryang@chromium.org>
Change tap for battery lightbar sequence to not show the last segment
dimmed as a percentage of your battery.
BUG=chrome-os-partner:37335
BRANCH=samus
TEST=use battfake console command to test out every increment of 10%
and use "lightbar seq tap" to show tap.
Change-Id: I4f38d26a8cfbecfa6efc86fcc8751ca8cb34879b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256191
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Limit input current to 2A when battery is near full and we are using
a charger below the boost bypass threshold in order to prevent
charging noise from the charge circuit.
This also changes the threshold at which 5V ramping is allowed to
90% because this is roughly the threshold at which the battery stops
drawing full current.
BUG=chrome-os-partner:36534
BRANCH=samus
TEST=load onto samus. use battfake EC console command to test
various battery states of charge:
- With zinger, verify that at 20V we never limit input current based
on battery SOC.
- With zinger at 5V, verify that >= 90% we limit input current to
2A, and < 90% it's still 3A.
- With 5V BC1.2 DCP, verify that >= 90% we don't ramp, <90% we do.
Change-Id: I868828b5807572736ea58f62bf3596f6416533d2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256072
Reviewed-by: Shawn N <shawnn@chromium.org>
include/motion_lid.h is generally included by board.c in the various boards.
But include/motion_lid.h actually needs host_command.h defined or else
including it in board.c will cause a confusing error.
This probably doesn't show up on other platforms like samus and glimmer
because they define a few custom commands in board.c, but veyron
doesn't need that. motion_lid ought to just include it directly if it really
needs it.
BUG=None, see next commits in the series, they won't compile without this
TEST=See series
BRANCH=veyron
Change-Id: I42e966d891dbbcca7df484b59c9d1bb35d1357bc
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256696
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Bits 1 and 3 of the control register are read 1, write 1, but RO
firmware may have zero'd these bits. Therefore, always set the bits
high, ignoring the read value.
TEST=Manual on Samus. Starting from .90 RO, flash new RW and verify
BC1.2 charger detection is working.
BUG=chrome-os-partner:37241
BRANCH=Samus
Change-Id: I2f71718f74e50fe9b664dbe3da1578ee4c995136
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously the USB Stream buffer sizes were fixed at
USB_MAX_PACKET_SIZE (currently 64 bytes). But that
ended up using up too much packet RAM, a very limited
resource. This change makes them configurable and
adds asserts to insure that the sizes are valid for
the underlying hardware.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USART forwarding on discovery works
Change-Id: Ib19c0dcfa9b16f23c1d72a5a7fc18026ab103f05
Reviewed-on: https://chromium-review.googlesource.com/255232
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>
Previously the USART and USB Stream drivers exposed in_stream
and out_stream interfaces, which don't allow for sharing their
queues easily. This change converts these drivers over to the
producer/consumer model and updates the two uses.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that the discovery echo functionality is unchanged.
Change-Id: I29f043ab1712373f638e1621378df98647d736cf
Reviewed-on: https://chromium-review.googlesource.com/252820
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
- battery firmware filename need match with gs:// filename
- changed from "%04X" to "%04x"
- A fix for LGC battery firmware update.
- Add control flags:
F_AC_PRESENT - 1 iff AC is connected.
F_VERSION_CHECK - 1 if do version check
- option to disk version check for stress test.
- Add detail log messages
- Remove old debug flag.
BUG=chrome-os-partner:36310
BRANCH=none
TEST=run ec_sb_firmware_update on glimmer
Change-Id: Iebc15222a7a55a786291ce2d8931e70acc5b3c4d
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253970
Reviewed-by: Shawn N <shawnn@chromium.org>
Reads to RTC_SSR may be invalid if they occur close to the RTCCLK edge.
As suggested by the datasheet, perform consecutive identical reads to
ensure the read is valid.
BUG=chrome-os-partner:37216
TEST=Manual on Samus. Repeatedly call rtc_read in test function, verify
that RTC_SSR never incorrectly ticks up.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib26fbfab4a07263f638c580066e993675dd8c451
Reviewed-on: https://chromium-review.googlesource.com/254725
Reviewed-by: Alec Berg <alecaberg@chromium.org>
For factory testing, when purposely discharging on AC, don't
automatically detect and unwedged charge circuit.
BUG=chrome-os-partner:37171
BRANCH=samus
TEST=plug in AC and run: "ectool chargecontrol discharge". check
on ec console that battery is discharging. let sit for 3 minutes
and make sure charge circuit unwedge code never runs. run
"ectool chargecontrol normal" and make sure battery starts charging
again.
Also force discharge with "ectool chargecontrol discharge" and then
unplug and replug AC, make sure battery is not charging nor
discharging, then set mode back to normal and make sure we start
charging again.
Tested without this CL and everytime you force discharge the charge
unwedge is activated and messes everything up.
Change-Id: Icc7a504c148e1e08777e7aafce64ff4cc38a32c5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254722
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Return host command error codes for EC_CMD_CHARGE_CONTROL instead
of returning the result of EC functions which typically return
element from enum ec_error_list, which is a different error list.
BUG=chrome-os-partner:37171
BRANCH=samus
TEST=make -j buildall
Change-Id: Ia13cc8a2f747ddeafdc059c6e575dcc2f5b20b8d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254721
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
All current boards in ToT place pstate at the end of the RO section.
Remove the unused option to place it at the end of the RW section;
we'll never do that again.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I0d279a4c9786bb33367a7387423481cc9b94e115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253636
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When building hosttests, CONFIG_FLASH_BASE is not a numeric
constant (it's a pointer to a buffer). This makes the the shell
complain when the Makefile tries to convert it from hex to
decimal.
Since the Makefile only needs that value to convert .bin to .hex,
let's just wait to calculate it until we need it.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Before, "make hosttests" printed a bunch of this:
sh: ((uintptr_t)__host_flash): missing `)' (error token is "__host_flash)")
Now it doesn't.
Change-Id: If408eb347b4f2385893d53cdfbf8fd5033868737
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254410
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we're sourcing VBUS, there is no need to proceed with the pericom
debounce / reset procedure, since we know that we're not charging.
BUG=chrome-os-partner:37137
TEST=Manual on Samus. Insert USB keyboard, verify that pericom reset
doesn't occur. Insert SDP port + Apple charger, verify that pericom
reset / redetection still occurs.
BRANCH=Samus
Change-Id: I1a616f6e2287cd474b94e8fb61c19514d2ec2042
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254140
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a new supplier type for VBUS chargers (USB chargers which supply VBUS
but are not identified as another charger type).
BUG=chrome-os-partner:37168
TEST=Manual on Samus with subsequent kernel commit. Modify code to
reject all non-VBUS suppliers, charge with SDP port, and verify charge
icon appears in OS.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fbdb1cb57bd0224b01aaf5a763f93b678b6d204
Reviewed-on: https://chromium-review.googlesource.com/254346
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The npcx chip and evb use a SPI flash chip to hold the EC image. They
don't need pstate, and should use the SPI flash status register
directly.
1. Remove CONFIG_FLASH_PSTATE from npcx_evb.
2. Remap WP_L GPIO to GPIO 93 (this should be the same as the write protect
line to the SPI flash chip).
3. Change the npcx flash driver so that it directly reads/writes the SPI
status register instead of mucking with pstate.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=manual
Add a switch or jumper to the EVB so R1 can be closed.
Toggle the switch and see that WP_L state changes. Leave enabled.
flashinfo -> nothing is protected, WP_L is enabled (=0)
(also do this after each flashwp command to check the protection status)
flashwp enable -> RO is protected now and at boot.
reboot
flashwp enable -> RO is still protected.
flashwp disable -> RO is still protected. (because WP switch is enabled).
Toggle the switch so WP_L is disabled (=1)
flashwp disable -> Succeeds, flash is not protected
Change-Id: Ifa959bce69f8eb4724057ecaa6a6c5075783c19d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253633
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, the flash module assumed it needed to emulate a SPI write
protect register using a bank of flash to hold the persistent flash
write protect state. This is not true for mec and ncpx chips under
development, which use external SPI flash. So, gate that code with
CONFIG_FLASH_PSTATE. For compatibility, leave it on by default (as we
do with CONFIG_FLASH_MAPPED).
There is no change to the behavior of currently supported chips, since
all of them already assume pstate is present. Removing this feature
from npcx will be done in a subsequent change.
BUG=chrome-os-partner:34346
BRANCH=strago
TEST=make buildall -j; verify flash wp and flashinfo work properly on samus
Change-Id: Ie044eb042863e4a7359ea540166ffd8d0089589d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253632
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
This signs the RW firmware (with a non-secret key). The RO
firmware will verify the RW firmware and jump to it if it's good.
Note that this isn't the final solution, just the beginning.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Build and install it. You'll see something like this:
--- UART initialized after reboot ---
[Reset cause: reset-pin hard]
[Image: RO, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.000444 Verifying RW image...]
[0.423742 RW image verified]
[0.423946 Jumping to image RW[0.428492 UART initialized after sysjump]
[Image: RW, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.428931 Inits done]
Console is enabled; type HELP for help.
>
> sysinfo
Reset flags: 0x00000c02 (reset-pin sysjump hard)
Copy: RW
Jumped: yes
Flags: unlocked
>
Change-Id: Icafa554baca135ff1f80cbce4dad5f980e7fc122
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
