This patch defines load addresses of regions using macros to increase
readability.
BUG=none
BRANCH=none
TEST=Diff firmware_image.lds before and after the change.
Change-Id: I24a13f4676b194efb748522f03c3134d1568f5ae
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/566940
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When usb_udpater reads board ID information from a binary blob, in
case the ID field can be represented as a 4 character ASCII string the
updater transposes the characters, resulting in a reversed string
printed.
Fix the transposition to verify that the result is printed properly.
BRANCH=none
BUG=b:63597142
TEST=ran the following commands:
$ make BOARD=cr50
$ CR50_BOARD_ID='TEST:ff00:ff00' H1_DEVIDS='0x0169c181 0x04656742' \
./util/signer/bs
$ ./extra/usb_updater/usb_updater -b build/cr50/ec.bin
read 524288(0x80000) bytes from build/cr50/ec.bin
RO_A:4919.0.0 RW_A:0.0.21[TEST:0000ff00:0000ff00] RO_B:-1.-1.-1 ...
Change-Id: I852cf9505d6b8b9e7133ca1008be1b22081a9d88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/567681
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The `brdprop` command simply returned board_properties, however,
board_properties is just a cache of the properties from init time. When
the `brdprop` command was issued, it would only return the cached value.
This commit changes the functionality of the `brdprop` command to always
query the LONG_LIFE_SCRATCH1 register.
BUG=b:63456150
BRANCH=cr50
TEST=Flash bob. Unplug and plug in battery, verify that
BOARD_WP_ASSERTED is set when running the `brdprop` command.
Change-Id: I0a7feb5e63f3e528b554ed0820924ac0705f5517
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/566240
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The LED pattern for lowest battery level is supposed to indicate that
there isn't enough battery present to boot the AP. The pattern_tbl
array had this value set to 2. However, it's better to tie this to the
constant defined in board.h so that it's consistent with when the AP
will be allowed to boot. In addition, adjusted the battery level
ranges to work correctly with the <= check.
BUG=b:35584895
BRANCH=eve
TEST=Used 'battfake' console command to verify that the patterns
changed at the expected battery charge levels.
Change-Id: Ie85a448ad4803be7e612c382b8e60fa42356d257
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/562542
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
This commit adds support for the PS8805, another Parade Tech TCPC with
integrated superspeed muxes. This also creates a generic Parade Tech
TCPC driver which supports the PS8xxx series.
The current supported TCPCs are:
- PS8751
- PS8805
BUG=b:63508740
BRANCH=None
TEST=`make -j buildall`
Change-Id: I78383af414996e0e8d6220985d286f95267136f8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/564799
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
There needs to be a way to set a board ID fields in the Cr50 RW
header. This patch adds this capability to the board signer and
release image creator scripts.
create_released_image.sh is being modified to include chrome OS
command line option parsing bash library, and a new command line
parameter is defined, --cr50_board_id. Its value is a string of three
colon separated fields, <board id>:<board id mask>:<board id flags>,
where
<board id> is a 4 character ASCII string, the RLZ board code
<board id mask> and <board id flags> are two hex values, without
preceding 0x.
This value is passed to the bs script through environment variable
CR50_BOARD_ID (to be in sync with the bs script taking already
optional parameters like H1_DEVIDS from the environment).
The bs script is slightly refactored, code modifying the manifest to
splice in the device ID nodes is put into a function, and code adding
the board ID nodes to the manifest is also included in the new
function.
The three fields of the CR50_BOARD_ID string are converted to integers
and added to three nodes in the manifest (board_id, board_id_mask, and
board_id_flags respectively).
BRANCH=none
BUG=b:62294740
TEST=created a released image image using
create_released_image.sh --cr50_board_id RXXX:ffffff00:ff00 \
<rest of parameters>
using the modified usb_updater (under a different patch) verified
that the header fields have been created as expected.
Change-Id: I8374024de347f341ac16b72c2fa4a774e8385466
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/562918
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This clean up is based on the review of a branch cherry-pick patch
(https://chromium-review.googlesource.com/c/556184).
Most of the comments apart from the suggestion of creating main() and
'workforce'() have been addressed.
BRANCH=cr50
BUG=b:62294740
TEST=verified that images created by running
H1_DEVIDS='xxx xxx' ./util/signer/bs elves elf.1 elf.2
H1_DEVIDS='xxx xxx' ./util/signer/bs
are still bootable on a Cr50.
Change-Id: I370526be060e11b8c640d35b1409a631233b0672
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/557997
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds code to interpret the contents of the Cr50 image's RW
headers board ID fields.
Board ID fields are added to the RW and RW_B version strings, as a
three field colon separated value.
The actual board ID is likely to be a 4 symbol ASCII string, if it
is, the 4 ASCII characters are displayed. If it is not - the 8
character hex value is printed. The rest of the fields are displayed
as 8 characters hex values.
BRANCH=none
BUG=b:62294740
TEST=tried the new option on various Cr50 images:
$ ./extra/usb_updater/usb_updater -b build/cr50/ec.bin
read 524288(0x80000) bytes from build/cr50/ec.bin
RO_A:4919.0.0 RW_A:0.0.21[00000000:00000000:00000000] ...
$ ./extra/usb_updater/usb_updater -b cr50.bin.dev
read 524288(0x80000) bytes from cr50.bin.dev
RO_A:0.0.10 RW_A:0.0.21[XXXR:00000004:00000001]...
Change-Id: I5a92a600d24e4a7d6d615f256b5979414e883d77
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/562919
Reviewed-by: Randall Spangler <rspangler@chromium.org>
STM32 I2C frequency can be computed as such:
tSCL = tSYNC1 + tSYNC2 + { [(SCLH+1) + (SCLL+1)] x
(PRESC+1) x tI2CCLK }
The default values we use come from the datasheet, which assume,
for 400 kHz setting, that tSYNC1 + tSYNC2 = 750 ns, and therefore
set tSCLH as 500 ns and tSCLL as 1250ns.
On hammer, we measured a total tSCL of ~2150 ns (465 kHz) with
these settings, so we can easily slow it down to ~2500 ns (400 kHz)
by increasing tSCLH to 750 ns (SCLH = 0x5).
As highlighted in 48b2edf031
"stm32f0/i2c: adjust the 100kHz setting to never go above 100kHz"
this has the disadvantage of slowing down other boards where
the RC value on the I2C bus are different, but slowing down should
always be safe, and is the best we can do without adding config
defines for the fall/rise time.
BRANCH=none
BUG=b:36172041
TEST=Flash hammer, measure SCL frequency to be about 400 kHz
Change-Id: Ia2cac9fb09228abd8a318d57335855be529485c2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/563219
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Running lsusb (to get iSerial) and openocd requires a privilege.
This patch makes cts.py run these commands as a root. Opening
ttyACM0 requires a privilege as well but it'll be done by asking
a user to add themselves to dialout group.
BUG=chromium:664309
BRANCH=none
TEST=Run cts.py on a freshly set up cros_sdk chroot.
Change-Id: Ib9d007459c4b1322b15f521a5253d833e2304c3c
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/558804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For hammer, we do not want to require finalization in factory, so
we just protect RO whenever WP GPIO is set.
BRANCH=none
BUG=b:63378217
TEST=Enable CONFIG_FLASH_PSTATE_LOCKED, flash hammer,
check with flashinfo that RO protection matches WP status.
Change-Id: I902ee478c00a3c932277d2a7d0622c070654a5eb
Reviewed-on: https://chromium-review.googlesource.com/563217
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
GPO32 is "PU [30K] during reset, then Hi-Z", so change to GPIO27
avoiding USB-C (P0) LED shortly light up during EC reset.
BRANCH=none
BUG=b:63048710
TEST=Rework poppy board by wiring EC_CHG_LED_Y_C0 to TP38
Change-Id: I91e3dd58849ce15f9a85408aec94fd3f94acf038
Reviewed-on: https://chromium-review.googlesource.com/558785
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Tony Lin <tonycwlin@google.com>
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
mux_lock is only used whenever the 2 PI3USB chips are sharing a
common I2C bus, and is only valid if mux_gpio and mux_gpio_level
are also set in the structure:
if (chip->mux_lock) {
mutex_lock(chip->mux_lock);
gpio_set_level(chip->mux_gpio, chip->mux_gpio_level);
}
Let's remove mux_lock on poppy.
BRANCH=none
BUG=chromium:740010
TEST=Flash poppy, BC1.2 charging works on both ports.
Change-Id: I76490c379efdfb3f37c590129429c163a03ae664
Reviewed-on: https://chromium-review.googlesource.com/563147
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Before
72afc55bd9 "stm32: cleanup flash-f by using constant from register.h"
lock() function would simply do:
STM32_FLASH_CR = FLASH_CR_LOCK;
which would clear all other bits in STM32_FLASH_CR, including
FLASH_CR_OPTER and FLASH_CR_OPTWRE.
This allow preserve_optb to work, as it does:
1. erase_optb
a. unlock()
b. Set FLASH_CR_OPTER
c. lock() (clears FLASH_CR_OPTER!)
2. write_optb
a. unlock()
b. Set FLASH_CR_OPTPG
c. Write option byte
d. Clear FLASH_CR_OPTPG
e. lock()
After the patch, we now have:
STM32_FLASH_CR |= FLASH_CR_LOCK;
which seems more correct. However, 1.c. does not clear FLASH_CR_OPTER,
and 2.b. ends up with both FLASH_CR_OPTPG and FLASH_CR_OPTER set,
and the programming operation does not do anything.
This patches does 3 things:
- Rename FLASH_CR_OPTSTRT to FLASH_CR_OPTER, as that's the correct
register name for STM32F0 and STM32F3.
- Fix the above by clearing FLASH_CR_OPTER in erase_optb
- Also clear FLASH_CR_OPTWRE in lock(). Not strictly necessary,
but this seems to be the right thing to do.
BRANCH=none
BUG=chromium:739608
TEST=On hammer, type flashwp true; reboot; flashwp all; reboot
flashinfo => All flash is protected
Change-Id: Ic276545ae3c0bdb685c7b117a7f896ec341731bb
Reviewed-on: https://chromium-review.googlesource.com/562839
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>
Split bn_modexp() into three variants:
bn_modexp() for large exponents (as before)
bn_modexp_word() for single word public exponents
bn_modexp_blinded() for large exponents w/ randomization
We randomize bn_modexp_blinded() with:
1) pick 64 bit random R1 and compute R1 ** -1 and R1 ** pubexp, mod N.
2) multiply input by R1 ** pubexp
3) pick 64 bit random R2 and add (e*d*R2 - R2) to private exponent (i.e.
a random multiple of phi(N))
4) exponentiate
5) multiply output w/ R1 ** -1 to obtain expected result
Since we enlarge the exponent, bn_modexp_blinded() is slower than
bn_modexp(). We only use bn_modexp_blinded() when private exponents are
in play and we have phi(N) available.
Also refactored the combined p256 and rsa dcrypto binary blob into two
parts. And added unique first word to each dcrypto blob to make code
caching reliable.
The TPM task stack maxes out at 8040/8192 in tcg_test due to increased
stack usage of bn_modexp_blinded() but is still within safe bounds,
with 88 byte redzone.
BRANCH=cr50
BUG=b:35587382,b:35587381
TEST=buildall, tcg_test (200+)
Change-Id: Ied1f908418f31f8025363179537aa4ebd2c80420
Reviewed-on: https://chromium-review.googlesource.com/540684
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
PSTATE is already included in WP_BANK_OFFSET + WP_BANK_COUNT,
so this change is not only unnecessary, but also harmful.
BRANCH=none
BUG=chromium:739608
TEST=Flash hammer, flashwp true; reboot; flashinfo
=> RO is protected
Change-Id: I31048c0156eff354fbcc6ae5828a6ef313b56b97
Reviewed-on: https://chromium-review.googlesource.com/561037
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
