If we have no ISR for an enabled GPIO interrupt (eg. for a UART GPIO
interrupt that wakes from low-power idle) then clear it, to avoid
interrupt storm.
BUG=b:63958831
BRANCH=eve
TEST=Verify we can repeatedly wake from low-power idle on eve by hitting
'enter' on the EC console.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6a01cae33e3bf1a3b5b42c0389c4613dc1cb9b7d
Reviewed-on: https://chromium-review.googlesource.com/584011
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Currently sweetberry hits an integer truncation issue
at 2.4 ohm when uA per div goes below 1. We can use 100ths
of a uA as the current per div scale.
BRANCH=None
BUG=chromium:608039
TEST=log from sweetberry with 10 ohm config.
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I9e9216230329483fd0bfcb44ce23cd15bae864b3
Reviewed-on: https://chromium-review.googlesource.com/577051
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
hwtimer ticks at 8 * 32768 Hz rather than 250 KHz, so adjust our timing
appropriately. Also ensure that udelay() will delay for at least the
requested time, taking into account our timer precision.
BUG=b:63858553
TEST=Generate square wave with 1000us udelay between GPIO edge toggle,
verify period is 1000us + code overhead. Also verify timer behavior on
overflow with 'forcetime' command. Also verify accuracy of system clock
to 0.2% with `timerinfo` and a stopwatch.
BRANCH=None
Change-Id: I5da41bd7250db87de5143cc54ebd0bb750fb7003
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578551
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Unique device ID register (96 bits) is at a different place on STM32F4
compared to other STM32.
BUG=none
BRANCH=none
TEST=Using board_read_serial() from hammer/board.c in
sweetberry/board.c, confirmed that we can extract and assign a unique
USB serial number.
Change-Id: Idb257f0f20422482c729a2b97b4b16ee231ca4d9
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/579575
Commit-Ready: Gwendal Grignou <gwendal@google.com>
Tested-by: Gwendal Grignou <gwendal@google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This CL adds CHIP_VARIANT_NPCX7M6G to support another npcx7 ec SKU.
Please note that the default setting in npcx7_evb is npcx7m6f.
For the EVB using the 128-pins EC package, please change CHIP_VARIANT
from npcx7m6f to npcx7m6g in build.mk.
BRANCH=none
BUG=none
TEST=No build errors for make buildall; Set CHIP_VARIANT=npcx7m6g in
board/npcx7_evb/build.mk; Build the image and test on EVB.
Change-Id: I2f857e4f6524eab45930bac3cc209409d4a53ee8
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/569320
Commit-Ready: Jun Lin <riverq@gmail.com>
Tested-by: Jun Lin <riverq@gmail.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
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>
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>
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>
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>
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
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>
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>
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>
The INFO1 mask field contents serves as input for the rollback
protection mechanism, when the RO decides if an RW is allowed to run
on the device.
The existing code updates INFO1 mask to match the lowest rollback
priority of the two images (RW_A and RW_B) present on the device.
INFO1 mask should be also updated when the current image is endorsed
by the host. In this case the alternative RW is destroyed, so the
INFO1 mask could be set based solely on the currently running image.
This patch refactors the code to allow setting INFO1 mask based on one
or both RW headers' contents.
BRANCH=cr50
BUG=b:62138152
TEST=verified that "normal" INFO1 mask updates still work as before,
the mask is modified to match the image with the lowest rollback
priority.
Also verified that when the VENDOR_CC_INVALIDATE_INACTIVE_RW
command is received the INFO1 mask is updated based on the
currently running image.
Change-Id: I23172388674e1f3a4c2489e139dd197a84029f54
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/541738
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Mapped reads are relative to CONFIG_EC_*_STORAGE_OFF, not
CONFIG_R*_MEM_OFF. The previous implementation happened to work for
internal mapped storage (eg. stm32) but failed for external mapped
storage which is copied to SRAM before execution (eg. npcx).
BUG=b:62841029
TEST=Verify sysjump works again on eve/poppy/soraka. Verify sysjump
and sig verification continues to work on fizz and stm32.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id51ce5697555eea38b246b58dbf47f22d4befaa7
Reviewed-on: https://chromium-review.googlesource.com/541861
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
On stm32f412, AHB prescaler must be 1 in order for stm32f412 to be
clocked at greater than 50MHz. APBX prescaler must be 2 so the clocks
can be in the right range. When APBX prescaler != 1, it results in 2x
timer clocks on both APB1 and APB2. We added a new
clock_get_timer_freq() function for stm32 to get timer specific clock
frequency so we can return 2x timer clocks when APBX != 1.
Flash latencies also need to be changed when we clock at 96MHz, the
FLASH_ACR_LATENCY defines are moved into the variant-specific switches
so each board can defined latency when setting CPU clocks.
BUG=b:38077127
TEST=`make BOARD=rose -j`, touch performance improved by 2x.
Change-Id: Ieb211ad80c168d3f57e72a8d16b954b703ee1444
Reviewed-on: https://chromium-review.googlesource.com/539375
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reject updates for the first 60 seconds after a hard reboot. This should
prevent people from using the reboot at the end of an update to get
around the update rate limiting. Reboots don't happen during normal cr50
operation, so this should not prevent updates. It will just prevent
updating cr50 many times in a row.
This change does not limit updates after deep sleep or POR.
BUG=b:62097097
BRANCH=cr50
TEST=Try to update cr50 two times. Verify that on the second time the
update is rejected. Put cr50 into deep sleep, wake it up and verify it
can be updated immediately. Get cr50 to do a POR and verify it can be
updated immediately.
Change-Id: I828ef210e1c5bcf59d4753b8178ee4e1369d5d36
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/520727
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for update related vendor commands in mn50 by relocating
relevant code from board/cr50 to chip/g.
BUG=b:36910757
BRANCH=None
TEST=./extra/usb_updater/usb_updater -d 18d1:502a build/mn50/ec.bin
Change-Id: Iec0fe5585b5b6eb099f9254dfb0e5b02d5106abc
Reviewed-on: https://chromium-review.googlesource.com/537999
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The setup time of original i2c setting which i2c freq is 1MHz is closed
to the margin of the spec. This CL improves the setup time with a new
setting. (For example, in npcx evb, measured setup time now is about
480 ns.)
This CL also removes the timing settings of higher i2c source clock
frequencies which are not used so far to save the code size.
BRANCH=none
BUG=b:38217035
TEST=No build error for make buildall; run stress test with i2cxfer and
i2cscan on gru with 400K and 1MHz i2c freq.
Change-Id: I5428a7dab1d935fd428ee9012604813e752cead8
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/527739
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Holding the mutex just around the dcrypto_call is not enough: dcrypto
instruction memory content might change in presence of multiple calling
tasks.
Switching to broad acquire/release pattern instead.
Note to sub-projects: pair your dcrypto_init(_and_lock) w/ matching dcrypto_unlock
BUG=none
BRANCH=cr50
TEST=tcg_tests pass
Change-Id: Idb7f2d79ce533db95cab51d89e3869ecf9f3d499
Reviewed-on: https://chromium-review.googlesource.com/535916
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
with the board ID match happening in the RW we need to be able to set
the rollback counter to a value which would guarantee a fallback
during the next boot.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches verified the ability to set the
counter to trigger a fallback on the next reboot.
Change-Id: I161f39354e5523121e26e8ad84a791a8b06e5123
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535976
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Until the Board ID check is moved to RO, it is possible to start an RW
with a mismatching Board ID.
Let's add a function to check for mismatch and report the status.
Also eliminating the unnecessary check for empty header Board ID field
- it is going to match any board ID anyways and fixing a CPRINTF
statement in read_board_id().
BRANCH=cr50
BUG=b:35586335
TEST=verified that empty board ID header does not trigger a mismatch
on a board with a non-empty INFO1. With the rest of the patches
applied verified that board ID mismatch is reported properly.
Change-Id: Ie03f8137e494117b7a238e3af72527e0a46369e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535975
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In the FIDO U2F Authenticator Transports Extension, the list of
transports will be extended to:
FIDOU2FTransports ::= BIT STRING {
bluetoothRadio(0), -- Bluetooth Classic
bluetoothLowEnergyRadio(1),
uSB(2),
nFC(3),
uSBInternal(4)
}
Given our implementation is internal, update the value from bit(2) uSB
to bit(4) uSBInternal.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate
with an ASN.1 parser.
Change-Id: I62fe72ffed9b7eb34e31164fded46f458e5cbc16
Reviewed-on: https://chromium-review.googlesource.com/536775
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Implement system_get_chip_unique_id() for the g hardware.
It includes the hardware revision, the chip device id and
the read-only key id.
The key-id is included because this unique id is used as serial number
inside certificates and for security reason, we want a different id if
the RO has changed (e.g Node locked firmware).
The id is also 32-byte long for convenience reason when used for
certificates, but the high 16 bytes are currently zeros.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=dump the x.509 individual attestation certificate which includes
the unique id as serial number.
Change-Id: If24597d0de696d2700122d425724f14703fc5256
Reviewed-on: https://chromium-review.googlesource.com/536774
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Before this change, the current task id was cached in dcrypto_init() if
it hadn't already been called. This resulted in the task id of the first
caller to dcrypto_init() being cached until reset.
The cached task id was used when generating notifications that hardware
crypto operations were complete. This was fine as long as the task that
invoked dcrypto_init() was also the task that invoked dcrypto_call(). If
this wasn't the case, the task that invoked dcrypto_init() would be
notified of an event it wasn't expecting and the task that invoked
dcrypto_call() would not be notified and would time out.
This change locks a mutex and then caches the current task id in
dcrypto_call() before invoking the hardware operation so that the
correct task will be notified when the operation has completed.
BRANCH=none
BUG=none
TEST=make -j buildall
Change-Id: I30a920d85359cc990d77c88b1607bbe4cf674206
Reviewed-on: https://chromium-review.googlesource.com/522350
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The contents of the board ID fields of the Cr50 image headers is an
important piece of information which determines if an image can run on
a particular H1 chip.
This patch adds this information to the output of the 'version'
command, printing both the contents of the fields of the RW images and
if the image would run with the current INFO1 board ID contents (Yes
or NO).
The board_id feature is in fact g chipset specific, this is why
board_id support files are being moved from the cr50 board scope to
the g chip scope.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=observed expected output in the version command:
> bid
Board ID: 000000fa, flags 000000ff
> vers
Chip: g cr50 B2-C
Board: 0
RO_A: * 0.0.10/29d77172
RO_B: 0.0.10/c2a3f8f9
RW_A: * 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
RW_B: 0.0.20/DBG/cr50_v1.1.6543-2c68a2630+
BID A: 00000000:00000000:00000000 Yes
BID B: 000000ea:0000fffc:000000ff No
Build: 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
tpm2:v0.0.289-cb2de5a
cryptoc:v0.0.8-6283eee
2017-06-09 15:34:19 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I5b283abf304a7408ca8f424407044fca238185e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530033
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
By default, read USB serial number from flash, but provide a way
for boards to override the function (e.g., to read serial number
from unique chip id).
BRANCH=none
BUG=b:62280271
TEST=Flash hammer
lsusb -d 18d1:5022 -v -v | grep iSerial
shows different chip IDs on different boards.
Change-Id: I0917752bb8e04c1eff4dffc0b3714f63dcd942b0
Reviewed-on: https://chromium-review.googlesource.com/523045
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
All other chips rely on gpio_enable_interrupt to enable interrupts. They
aren't enabled by default. This changes chip/g to match that.
If chip/g boards have interrupts, they also enable them in the
init_interrupts function in board.c. Nothing needs to be added to enable
interrupts.
BUG=b:35587228
BRANCH=cr50
TEST=use 'gpiocfg' to verify the setup hasn't changed.
Change-Id: I1e975999e0174b9dcbbe63c09c6110dc4161f8ff
Reviewed-on: https://chromium-review.googlesource.com/530006
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This CL locks VCC_RST# alternative bit, NO_VCC1_RST, of DEVALTA
in case the developers switch it to GPO77 unexpectedly by setting
VCC1_RST_LK bit in DEV_CTL4.
BRANCH=none
BUG=none
TEST=Use rw console command to make sure NO_VCC1_RST bit is
locked on npcx7_evb.
Change-Id: Ic7882ef1c8050c3daca85bd241d5368f009e4e2e
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/522206
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In this CL, we add selecting LFCLK sources functionality for npcx7 ec
series. (Please notice not all of npcx7 ec series support this feature.)
Beside internal LFCLK source, ec also can choose the external 32kHz
crystal oscillator as LFCLK source for the specific application. We also
introduce a new definition, CONFIG_CLOCK_SRC_EXTERNAL, to switch this
feature in the board level driver.
This CL also adds:
1. LFCG register definitions in registers.h.
2. Change the order of each npcx modules by memory address.
BRANCH=none
BUG=none
TEST=Output LFCLK source through GPIO75. Compare with external 32kHz
crystal osc. on npcx7_evb and make sure the sources are the same.
Change-Id: I137146bf51ccb51266b9aac1e2e28bcea87dc4f5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/520745
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Invoking signer with sudo is required only when signing requires a USB
fob. Let's not use it in unless necessary.
BRANCH=cr50
BUG=chromium:728751
TEST=verified that Cr50 build succeeds when both using and not using
the signing fob.
Change-Id: I8f40bd52f1752bfd88ec002f298b991faf7a2512
Reviewed-on: https://chromium-review.googlesource.com/528373
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This CL adds:
1. Fixed the incorrect address of BKUP_STS register.
2. Cleared the IBBR bit of BKUP_STS register at initial because
its default value is 1(means the content of BBRAM is invalid) whenever
VBAT is powered up.
3. Add debug msg when IBBR bit is set to indicate the BBRAM's
corruption.
4. Modified the valid BBRAM offset from 1 to 0 and size from 63 to 64.
BRANCH=none
BUG=b:38187362
TEST=No build error for make buildall; Check IBBR is cleared at initial.
Check IBBR is set by changing the VBAT voltage below VBAT MIN.
Test console command "reboot ap-off" on poppy.
Change-Id: I69d98b50d4e0aec17b55a4a9b5e8f1a412a3fe45
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/505861
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There are some useful UART bitbang commands, statistics, and logs and
such. These shouldn't be enabled by default, and this commit makes it
so.
BUG=b:35648297
BRANCH=cr50
TEST=Build an image that enables UART bit banging with BITBANG_DEBUG set
to 0. Verify that the associated debug commands and statistics are not
present.
Change-Id: Ic0348a6fb1620229e2ed601e0ff549596d814e1e
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/527605
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add nucleo-f411re for testing STM32F411.
Fix registers.h to include F411 specific features.
TEST=Check uart,gpio works. Check BMI160 accel/gyro sensor works over
i2c
Install firmware with "make BOARD=nucleo-f411re flash"
BUG=b:38018926
BRANCH=none
Change-Id: I8514d1aa48e06708053e72f8d4be15738eda6cf4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249994
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
When invoking vendor command handlers in try_vendor_command(), the
buffer containing the command is passed to the handler to communicate
the command contents and to hold the command execution return data. It
was fine when invoking vendor command handlers from the TPM stack, as
the receive buffer is 4K in size and is large enough for any expected
vendor command response.
It is different in case of USB: the command is in the receive buffer
of the USB queue, and the response data could easily exceed the
command size, which would cause corruption of the USB receive queue
contents when the response data is placed into the same buffer where
the command is.
Let's introduce a local storage to pass the command and receive the
response data from the handler. 32 bytes is enough for the foreseeable
future, should a need arise for a larger buffer, testing would result
in an error (a new error type is added to indicate insufficient buffer
space for command processing).
BRANCH=none
BUG=b:35587387,b:35587053
TEST=with the rest of the patches applied verified proper processing
of the 'Get Board ID' command for which response size exceeds the
request size.
Change-Id: I2131496f3a99c7f3a1869905120a453d75efbdce
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525092
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
