We currently set STM32_FLASH_OPT_LOCKED
to (STM32_FLASH_CR & FLASH_CR_OPTWRE), however the bit is set
when option byte are _unlocked_.
From STM32F0 Reference Manual:
Bit 9 OPTWRE: Option byte write enable
When set, the option byte can be programmed. This bit is set
on writing the correct key sequence to the FLASH_OPTKEYR register.
This bit can be reset by software
BRANCH=none
BUG=chromium:739608
TEST=Flash hammer, flashwp true; reboot; flashinfo
=> hammer does not hang on reboot, RO is protected
Change-Id: I1b6eb5d638534ece90d6d5164586f49bdb0c151d
Reviewed-on: https://chromium-review.googlesource.com/561036
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
After entering prepare_to_sleep() and doing interrupt_disable(), if an
interrupt happens, it will stay pending (as the handler is masked).
Then, when calling 'wfi' in __idle(), we will go through the instruction
rather than entering deep-sleep (if requested) as we have a pending
interrupt.
The downside of this corner case is that we never undo the actions done
to prepare for deep-sleep in the IDLE_DEEP_SLEEP clause of
prepare_to_sleep(). For USB suspend, this means that on the subsequent
deep-sleep entry, we are going to try to save GR_USB_CFG/the USB
device address while the USB controller is already in reset/power-down,
recording a null value in SCRATCH18. Then, at resume time, we will
restore 0 in USB_CFG and the USB device will no longer work.
As the USB configuration is difficult to restore in case of deep-sleep
abortion, simply skip writing a bogus value in SCRATCH18 on the real
deep-sleep entry happening afterwards. This is good enough to resume
properly on USB.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:38160821
TEST=manual: add a (long) panic_printf trace in prepare_to_sleep() in
order to dramatically increase the probability of getting an
interruption pending after entering the function. On cr52, trigger USB
suspends by suspending the host, and see we no longer regularly get a
null USB device address at USB resume.
Change-Id: Ied3fc003eefe7fc164a320b15b5f9d400551198e
Reviewed-on: https://chromium-review.googlesource.com/559332
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Virtual battery implements a smart battery interface, but the actual
battery on the system may speak a different protocol. Support such
batteries by removing direct i2c access from the virtual battery driver.
Fetch data from storage when available, and call generic battery
routines when not.
BUG=chromium:717753
BRANCH=None
TEST=Manual on kevin, boot and verify "Unhandled VB reg" prints are not
seen. Verify by-eye that all regs in cros 4.4 kernel sbs-battery.c are
handled (except REG_MANUFACTURER_DATA). Verify that sysfs manufacturer,
model name, time_to_full_avg and time_to_empty_avg values are all sane.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia8fc0a80ac7576fa8bdcc3b7dac0609d9d754234
Reviewed-on: https://chromium-review.googlesource.com/547004
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
STM32F0 cannot keep PWM output active when chip is in deep sleep.
The only other board that uses both CONFIG_LOW_POWER_IDLE
and CONFIG_PWM on stm32 is jerry, and this logic should also apply
to it.
Also, switch using_pwm from array to bitmask to simplify handling.
BRANCH=none
BUG=b:36173380
TEST=On AP, tell it to autosuspend hammer:
echo auto > /sys/bus/usb/devices/1-2/power/control
Then see, using idlestats, that hammer does to deep sleep.
In hammer console: pwm 0 50, see that PWM output is stable,
idlestats shows EC does not sleep.
In hammer console: pwm 0 -1, idlestats shows EC sleeps again.
Change-Id: Ic74c1905364fe4335239da95a99193d0e3e979f7
Reviewed-on: https://chromium-review.googlesource.com/541115
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Remove code related to DH_SWAP_BY_POINTERS and
DH_REPLACE_LAST_THREE_LADDERSTEPS_WITH_DOUBLINGS, as they are
not really worth it (code size increase of 60/100 bytes respectively
for 1000/500 us time gain).
BRANCH=none
BUG=b:62813194
TEST=make BOARD=hammer PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=hammer --image=build/hammer/x25519.bin
EC console: runtest, taskinfo
Change-Id: If21948bb2c7c20f97ba8b321dd2688cd3d0ba74a
Reviewed-on: https://chromium-review.googlesource.com/554440
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Move generic implementation to curve25519-generic.o
- Always use optimized version on cortex-m0.
- Rename .s files to .S, remove unnecessary lines in assembly files.
- Rename crypto_scalarmult_curve25519 to x25519_scalar_mult to match
the signature provided by the generic implementation.
- Replace some handcoded memcpy with function calls
- Remove unnecessary "volatile" specifications in the code.
BRANCH=none
BUG=b:62813194
TEST=To test old implementation only:
- Increase CONFIG_RO_SIZE to 60kb
- Increase console stack size to 2048
make BOARD=hammer PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=hammer --image=build/hammer/x25519.bin
EC console: runtest, taskinfo
=> Used to takes ~4'17" to run (X25519 duration 256347 us).
1496/2048 stack size usage in CONSOLE task
=> Now takes ~1'25" to run (X25519 duration 84520 us)
732/2048 stack size usage in CONSOLE task
TEST=In test/x25519.c, uncomment #define TEST_X25519_1M_ITERATIONS
make BOARD=hammer PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=hammer --image=build/hammer/x25519.bin
EC console: runtest, wait ~23 hours, test passes.
TEST=- Define CONFIG_CURVE25519_CORTEXM0 (next patch)
makes newsizes
build/hammer/RW/ec.RW.flat shrank by 1888 bytes: (52208 to 50320)
Change-Id: Icce38d3c32f431a85ac0f951cf34456b490dc665
Reviewed-on: https://chromium-review.googlesource.com/540962
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Use device events for waking the system from Deep S3.
This enables the trackpad and DSP as Deep S3 wake sources and allows
the AP to log them properly.
BUG=b:36024430
BRANCH=eve
TEST=manual testing on Eve with trackpad and DSP wake events
Change-Id: If17698a4901002e1590f4852f970fd9963964cb6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/555633
Reviewed-by: Shawn N <shawnn@chromium.org>
RMA auth uses X25519 to generate a relatively small challenge and
response.
Currently, nothing calls the rma_auth code. We'll need console and
TPM vendor commands to do so.
BUG=b:37952913
BRANCH=none
TEST=make buildall
Change-Id: Iec7f2d0e3dc8243f79b009ead16bb3ba9f1bef9d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544184
as it turns out, we're pretty aggressive in iterating over all TCPCs
checking for alerts when any of them generate an interrupt or their
interrupt line is low. this can cause unfortunate behavior if the
driver hasn't initialized itself (and the chip) yet for interrupts to
be handled or we've released (disconnected) the driver so we can do a
TCPC firmware update. so, check the PD task state to see if it makes
sense to service the port's interrupt.
note: there seems to be a quirk with the ps8751 in that it holds its
ALERT# (interrupt) line low during firmware update. this line is
supposed to be falling edge triggered, so it's technically not
interrupting, but since we also poll the line level, we think there's
a continuous interrupt that isn't acutally there. we get away with
this because pd_exchange_status() has a 5ms delay in its polling loop
to avoid spinning.
the particular test case was to unplug the PD power brick during TCPC
firmware update (over i2c). the interrupt handler would be called,
accessing the TCPC over i2c and causing all sorts of havoc.
TEST=tested with follow-up CLs and verified ps8751 firmware update
works on electro.
BRANCH=none
BUG=b:35586896
Change-Id: I880cff49e0e9637256efa9003bcc46274536e631
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544661
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to report specific wake events from differernt devices
add a host command that allows setting device event mask, and
triggering a host event when that device event is set.
This is done as a separate command and mask because we are running
out of host events, and it takes over the unused thermal overload
event that was never used in EC or BIOS.
The first use case for this is platforms that have AP wake events
that go to the EC, for instance devices that use Deep S3 and have
a limited set of wake pins. (such as Eve)
This allows the AP to determine the exact wake source for an event
so it can be logged and acted on by the AP if necessary.
BUG=b:36024430
BRANCH=eve
TEST=manual testing on eve with trackpad and dsp wake events
Change-Id: I48d94014c00dc1dad098ab96af0ddc7860229762
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/555632
Reviewed-by: Scott Collyer <scollyer@chromium.org>
In the CL:505861, we print the warnning message to indicate that the VBAT
has ever dropped if the IBBR bit is set but do not clear the IBBR. This
forbid the access to BBRAM until EC power-on reset.
In this CL, we clear the IBBR bit to make BBRAM work again without the
need of EC power-on reset.
BRANCH=none
BUG=none
TEST=No build error for make buildall; Check warining messages are
printed and IBBR bit is cleared.
Change-Id: I58a0370c1c496b3c1208d9d5ac6b55c4d66fe8b6
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/542976
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Use existed macro instead of creating new one.
BRANCH=none
BUG=none
TEST=plug USB-C power adapter and USB-C to hdmi adapter, both work.
Change-Id: I133142232ac6abfa7f285c289eb03c4d65e84d5f
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/554655
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When LED control pin is high, LED can't totally turn off because
of leakage. Modify LED control from push-pull to open drain/Low
to fix the issue.
BRANCH=None
BUG=None
TEST=Use "ectool led" to turn on and turn off power and battery led
to check if there is leakage
Change-Id: I05f1d5d5b25e9108ca0200cfef787e8dcc0edec8
Reviewed-on: https://chromium-review.googlesource.com/484139
Commit-Ready: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Jimmy Wang <jimmym_wang@compal.com>
Implement U2F (universal second factor authentication) feature
over TPM vendor commands.
The raw U2F APDU as defined by the FIDO Alliance 'U2F Raw Message Formats'
specification can be sent using the VENDOR_CC_U2F_APDU command.
So the vendor command is taking a ISO7816-4:2005 APDU format frame as input
as defined by the spec and returns another APDU using ISO7816-4 status
code.
The APDU is processed by the common U2F code using u2f_apdu_rcv(),
this hardware specific code provides:
- the user physical presence detection (done by the power button press)
returned by the pop_check_presence() callback.
- the connection to the cryptographic hardware to generate/derive the
keys used by the U2F and individual attestation functions.
This feature/vendor command has 3 modes:
- disabled
- U2F (only the commands/flags defined by the U2F specification)
- G2F (the U2F commands plus some extensions for individual attestation)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and HIDTest.
Change-Id: Ic2591f369763fb4ba67926e2b4a0c2cd35330a18
Reviewed-on: https://chromium-review.googlesource.com/518139
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the common code to support FIDO U2F (Universal second factor
authentication) protocol implementation: the APDU parsing and standard
commands execution, plus a few non-standard flags and hooks.
The u2f.h header is the unmodified copy from the U2F v1.1
Specifications archive.
Mostly copied over from the cr52 code-base.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
CQ-DEPEND=CL:*390230
Change-Id: I636d4a77ea69d69b5ab18a958e58ee6fcb2476bc
Reviewed-on: https://chromium-review.googlesource.com/518136
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Base32 encoding is used to turn the RMA reset binary
challenge/response into less-typo-prone text, at 5 bits per character.
BUG=b:37952913
BRANCH=none
TEST=make runtests
Change-Id: I474750a20204ba353cea1e91982aa03e8071c0c2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544177
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch makes EC read the slot to verify and jump to from the
battery backed up RAM (BBRAM).
BUG=b:38462249
BRANCH=none
TEST=Boot Fizz
Change-Id: I0c78861ea3ccdc45d0aa08e690e3a68f53658409
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/518255
similar to the USB_PD_TCPC case, add release/init operations when the
pd_task enters/leaves the PD_STATE_SUSPENDED state. one use case for
PD_SUSPEND is to get exlusive access to the TCPC for things like
firmware update, so the release/init operation is needed to get the
TCPC and driver into a good state.
updated all tcpm_drv style drivers. for backward compatibility, "old"
drivers that may not handle init/release properly simply return
EC_ERROR_UNIMPLEMENTED for tcpm_release(). pd_task() uses this as a
signal that it should not try to re-init() the driver.
TEST=tested in combination with follow-on CLs to do TCPC firmware
update on electro. also built for kevin, eve, sand which are
some of the other boards using these drivers.
"make buildall -j" passes.
BRANCH=none
BUG=b:35586896
Change-Id: I3d2964a79e710428f7a6e7004d68ab424af85be8
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544660
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch sets/clears RESET_FLAG_AP_OFF on S5<->S3 transitions.
It's set when the system gracefully shuts down and cleared when the
system boots up. The result is EC tries to go back to the
previous state upon AC plug-in on battery-less systems.
This is required for digital signage and kiosk.
This also reverts: CL 514209, 486946, and 486945.
BUG=b:37536389
BRANCH=none
TEST=Tested as follows:
A. Boot to S0
A.1. Unplug AC while system is in S0 then plug in - PASS
A.2. Unplug AC while system is in S3 then plug in - PASS
A.3. Press recovery+power in S0 - PASS
A.4. Press recovery+power in G3 - FAIL (To be fixed)
A.5. Execute reboot console command - PASS
A.6. Execute reboot OS command - PASS
A.7. Execute reboot console command in G3 - PASS
B. Boot to G3
B.1 Unplug AC while system is in G3 then plug in - PASS
B.2 Unplug AC after B.1 then plug in - PASS
B.3 Shutdown by power button on recovery screen then unplug
plug in AC - PASS
B.4 Execute reboot ap-off console command - PASS
B.5 Execute shutdown command from OS then plug in AC - PASS
Change-Id: Iaa6f930585050fdd3511c711b449dff47525066d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517287
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds vboot for EC by EC (vboot EC) for x86 systems.
When ec is transitioning s5->s3, it checks the power supply is
enough to boot AP or not. If not, it runs other checks and may
finally validate and jump to a RW image.
BUG=b:38462249
BRANCH=none
TEST=Boot Fizz on barrel jack and type-c charger.
Change-Id: I5988b0595976370c5303c45541702ae89d86fc97
Reviewed-on: https://chromium-review.googlesource.com/518254
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
eCTS tests are small. We can use smaller flash size to expedite
tests. This patch reduces flashing time for stm32l476 from 24 sec
to 6 sec.
BUG=chromium:736020
BRANCH=none
TEST=python util/run_ects.py
Change-Id: I829ee2c947664f2d7ed373f52ff336e9a9580817
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/553580
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In a different environment, returned characters are corrupted if
baudrate isn't specified. This patch replaces tty_read method with
the one using pySerial.
BUG=chromium:736778
BRANCH=none
TEST=Run run_ects.py and verify all tests pass.
Change-Id: I8c14f6a04c900d2670ad86c1b91f3fe6625ba69c
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/550848
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds i2c suite to run_ects.py. It also adds checks for
return values from i2c_read and i2c_write functions.
BUG=chromium:653183
BRANCH=none
TEST=Run run_ects.py and verify all test pass.
Change-Id: Ie3d6e1e6f131235e2b28f39e1546c9cb4c3b92f6
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/547024
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since the script is expected to upload results and probably send
alerts by e-mail, it's better to be written in Python so that we
can utilize chromite library. It will no longer run outside chroot
because of imports from chromite.lib.
BUG=chromium:735546
BRANCH=none
TEST=Run run_ects.py and verify all tests pass.
Change-Id: I6c79b061cdaef4d30305cf531f37b6734d18b7d9
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/546579
Reviewed-by: Randall Spangler <rspangler@chromium.org>
looks like we had a bit of a race condition: set_state() was
effectively just an assignment opration to pd[port].task_state. it's
called asynchronously from pd_set_suspend() in response to a
PD_SUSPEND message from the AP as well as from pd_task() before it
enters its main event loop. this can take a long time because
tcpci_tcpm_init() has a 300ms timeout. last one wins.
similarly, when pd_task() is running its main loop, pd_set_suspend()
really needs to wait for pd_task() to actually enter the
PD_STATE_SUSPENDED state before the caller can assume that the
pd_task() has stopped accessing the TCPC.
the particular failure case was when depthcharge would decide to do a
TCPC firmware update. it starts by sending a PD_SUSPEND to the EC,
then accessing the TCPC. unfortunately, the pd_task() hadn't gotten
out of the way yet, thus causing TCPC access chaos.
so, i'm adding a req_suspend_state flag to the pd_protocol struct so
we can tell pd_task() to suspend itself in a controlled manner. when
pd_task() is ready to do a state change - basically at the top of the
main event loop - it'll change to PD_STATE_SUSPENDED and clear the
req_suspend_state flag.
in any case, pd_set_suspend() still needs to wait around for pd_task()
to enter the suspended state as we don't have a fancy handshake
mechanism between these tasks.
TEST=in combination with some follow-on CLs, ps8751 firmware update
works properly where previously it needed a ~2 second delay
for the EC pd_task() to settle. the way to trigger the
failure was to insert or remove the power brick.
BRANCH=none
BUG=b:62356808
Change-Id: I363803ff60db31ccf84d592f8c9d1610fbe0f9ce
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544659
Reviewed-by: Shawn N <shawnn@chromium.org>
Recovery mode can be triggered with or without hw reinit. And both the
modes are triggered using the same button combination held down for
different amount of time. For recovery mode with hw reinit (>30
seconds), LED blinks for 4 seconds. However, for recovery mode without
hw reinit(>10 seconds), there is no user indication. This change turns
on the LED as soon as the >10 second condition is satisfied. This
provides an indication to the user that recovery mode is triggered.
BUG=b:62886608
BRANCH=None
TEST=make -j buildall
Change-Id: I949c3e7e98441131df987b6351c1f614f3b4831c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/549775
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
flash_physical_protect_now(), which is called when
EC_FLASH_PROTECT_ALL_NOW is set, should protect the entire flash
temporarily until reboot. Current behavior enable flash protect on all
region permanently. The correct implementation should be writing an
invalid key to the flash controller to disable flash flash only
temporarily until reboot.
Since the implementation of flash-stm32f3 and flash-stm32f4 is almost
the same after restoring the changes made in commit
35f4d8acaa, we merge to file by creating a
symlink from flash-stm32f3.c to flash-stm32f4.c to reduce code
duplication.
BRANCH=none
BUG=b:37584134
TEST=on eve:
1) `ectool --name=cros_tp flashprotect`
Flash protect flags: 0x00000008 wp_gpio_asserted
2) `flashrom -p ec:type=tp --wp-enable
3) `ectool --name=cros_tp reboot_ec`
3) `flashrom -p ec:type=tp --wp-status`
WP: status: 0x80
WP: status.srp0: 1
WP: write protect is enabled.
WP: write protect range: start=0x00000000, len=0x00040000
4) `ectool --name=cros_tp flashprotect`, all_now should present
Flash protect flags: 0x0000000f wp_gpio_asserted ro_at_boot ro_now \
all_now
5) `ectool --name=cros_tp reboot_ec; sleep 0.3; \
ectool --name=cros_tp rwsigaction abort` to stay in RO.
In EC console, `flashinfo`, should show that only RO is actually
flash protected:
Protected now:
YYYYYY..
6) `flashrom -p ec:type=tp -w ec.bin -i EC_RW` works
7) `make BOARD=ryu -j` works (for testing flash-stm32f3.c)
Change-Id: Ia7a60ae8b3084198abb468e4fc8074b4445d6915
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/549681
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If we have requested the host to go to recovery mode, the host will
usually not need an RW hash because it won't do EC SW sync. Therefore,
do not auto-start calculation of our hash if we've requested recovery.
This may avoid past recovery-breaking bugs due to unexpected RW contents.
If the host does need the hash after all, it will manually request that
the computation start.
BUG=chromium:612966
BRANCH=None
TEST=Boot to recovery mode on kevin, verify that "hash start" print is
not seen on UART.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I66d2d74398357dfe30e39882feec8cfba4cc945c
Reviewed-on: https://chromium-review.googlesource.com/540695
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a delay before flash_erase deferred started so the task does not halt
CPU, and cause the response of EC_CMD_FLASH_ERASE to not be delivered.
When the above situation happens the host I2C controller will timeout.
A 100ms delay should be long enough on any board to allow the response
to be sent.
BRANCH=none
BUG=b:38018926
TEST=on eve units where flashrom always fail:
`flashrom -p ec:type=tp -w ec.bin` succeeds.
Change-Id: I399a60064392da41a3e27f8630175ab427047ab7
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/547375
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
This patch updates the mutex test suite so that it can be run
within the current framework.
BUG=chromium:736155
BRANCH=none
TEST=run cts.py -m mutex
test name TH_RETURN_CODE DUT_RETURN_CODE TH_STR DUT_STR RESULT
lock_unlock_test SUCCESS SUCCESS 1 1 PASS
Change-Id: I69ee0857a0c633d7c6c8909f8c6f58ca6fd272ce
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544790
This patch makes each test print start marker before sync. This will
allow us to distinguish the failure before even sync is attempted
(CTS_RC_DID_NOT_START, thus probably caused by the previous test)
and the failure caused by the hanging partner, in which case the one
good and alive will be stuck in sync (and should return _DID_NOT_END
or even better _BAD_SYNC once we implement timeout in sync).
This patch also:
* Adds did_not_start_test to and removes debug_test from meta suite
* Consolidates test runner loops into common cts_main_loop
* Removes dut_common.h and th_common.h
* Removes debug print macro and CTS_DEBUG
* Replaces all infinite loops after tests with task_wait_event(-1)
* Removes meaningless comments and debug printfs
* Removes CTS_TEST_ID_*
* Adds sync() to task suite
BUG=chromium:736104
BRANCH=none
TEST=Run run_ects.sh and verify all tests pass
Change-Id: I6ccdf26afac6b8e8cb16483c5d75e4e77e7962f4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/545176
This patch updates the hook test suite so that it can be run
within the current framework.
BUG=chromium:736047
BRANCH=none
TEST=cts.py -m hook
test name TH_RETURN_CODE DUT_RETURN_CODE TH_STR DUT_STR RESULT
test_init_hook SUCCESS SUCCESS 1 1 PASS
test_ticks SUCCESS SUCCESS 1 1 PASS
test_priority SUCCESS SUCCESS 1 1 PASS
test_deferred SUCCESS SUCCESS 1 1 PASS
Change-Id: I3e7f29da61e794b06b03241f3d7706c2db94b5be
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/545084
The Eve board defines left and right LEDs, but the LED control loop is
checking for auto control to be disabled on the power/battery LED IDs.
This is breaking factory testing for LED colors when the battery level
is low because it is flashing RED and ignoring the colors that the
factory software attempts to set.
BUG=b:63049012
BRANCH=eve
TEST=manual testing on Eve with low battery
Change-Id: I65b822111b3054a5994d71ec4e2a089c487acf97
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/549740
Reviewed-by: Todd Broch <tbroch@chromium.org>
the EC firmware build for chell ran out of space, so i'm turning off
some CLI commands. i'm turning off all the commands we've already
turned off for kevin (see board/kevin/board.h).
TEST="make buildall -j" passes
BUG=b:62356808
BRANCH=none
Change-Id: Ie7191f841d826cefc8b17f5325b221842db2eb1d
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544095
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Don't discard irqprio data when the IRQ_PRIORITY macro is used directly
(for watchdog / watchdog timer).
This change is probably a NOP for all platforms, since the power-on
default for the IRQ prio register seems to be zero, which is the same
priority we're setting in our direct use of IRQ_PRIORITY.
BUG=chromium:634701
BRANCH=None
TEST=Verify 'prio_44' entry exists in irqprio section by checking
ec.RO.map on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idaffc484a2ce4749c18212f179b3951ff570aed0
Reviewed-on: https://chromium-review.googlesource.com/545201
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On a keyboard-less, volume-button-less board, we support simplified
sysrq handling.
For Fizz, we use the recovery button to trigger sysrq event and
holding it down to trigger warm reset.
BUG=b:38418116,b:38417391
BRANCH=none
TEST=On Fizz, try
1. Press recovery button and release -> sysrq sent
2. Press and hold recovery button -> warm reset
3. Press recovery button and power button -> enter recovery mode
Change-Id: If8760319dba3df4545e9805b396ac89c241dae80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/537817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This script will run nightly in the lab and publish the results.
Publishing results will be implemented later.
BUG=chromium:735546
BRANCH=none
TEST=Run run_ects.sh inside & outside chroot and verify all tests pass.
Change-Id: I405ea601eff33f1a4328f2606c8bb4050ff8d253
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/543681
We need to add a few library routines for sensor task.
Routines added are taken from nds32's library.
BRANCH=none
BUG=none
TEST=Add sensor task to reef_it8320 board.
Test screen rotation functionality on reef_it8320.
Change-Id: I2eee33f897b38e05bddd30b16f875944259b2c0d
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/527537
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we don't strip a serial string read from a file, TH serial doesn't
match with the one read from lsusb. It causes TH to be recognized as
a DUT.
This patch also makes error messages more helpful when DUT is not found
or multiple DUTs are connected.
BUG=none
BRANCH=none
TEST=cts/cts.py -m meta, task
Change-Id: Ifcf96089b9620ef8809a7d2924dacf67d3af419c
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/542019
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Openocd is upgraded to 0.10.0, which supports stm32l476. So, now
we can run eCTS inside chroot. This allows new developers to spend
no time on setting up software as all necessary tools (e.g. specific
version of make, openocd, lsusb, ARM toolchains) come with cros_sdk.
BUG=chromium:653949
BRANCH=none
TEST=cts/cts.py -m meta
Change-Id: Iba7ba94e95ceadcedcb53b76e47054ba1b2b47dd
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/542017
Reviewed-by: Randall Spangler <rspangler@chromium.org>
