We were using bn_modexp() to perform a simple modular square.
A bn_modexp_word() does this faster.
BRANCH=none
BUG=b:68167013
TEST=generate 128 primes from prng seed and verify they're same as before; tcg_test passes
Change-Id: I411a7d3fe2d68f93dc40bf74b941a637f9aa20ed
Reviewed-on: https://chromium-review.googlesource.com/778057
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With the upcoming change to add a new command to get/set/clear host
events and masks, it seems to be the right time to bump up the host
events and masks to 64-bit. We are already out of available host
events. This change opens up at least 32 bits for new host events.
Old EC commands to operate on host events/masks will still deal with
lower 32-bits of the events/mask. On the other hand, the new command
being added will take care of the entire 64-bit events/masks. This
ensures that old BIOS and kernel versions can still work with the
newer EC versions.
BUG=b:69329196
BRANCH=None
TEST=make -j buildall. Verified:
1. hostevent set 0x4000 ==> Sets correct bit in host events
2. hostevent clear 0x4000 ==> Clears correct bit in host events
3. Kernel is able to query and read correct host event bits from
EC. Verified using evtest.
4. Coreboot is able to read correct wake reason from EC. Verified
using mosys eventlog list.
Change-Id: Idcb24ea364ac6c491efc2f8dd9e29a9df6149e07
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the i2c master sends a stop condition before we've buffered the last
Rx byte (eg. due to higher than normal i2c interrupt latency) then we
don't want to drop the last byte on the floor, it's still meaningful.
BUG=b:65711378
BRANCH=glados
TEST=Spam TCPC_REG_ROLE_CTRL commands from caroline to caroline_pd,
verify no errors are observed on either side for 12,000,000
transactions.
Change-Id: I0c4a81d97315cff553a5448c0940746e1ef0ed2c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/771936
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EC_IN_RW signal is used to determine if the switch to dev mode can be
safely made. However, EC_IN_RW needs the EC_RST_L line driven low in
order to be reset. In faft tests that utilize crosEcSoftrecPower
method, EC_RST_L is not being driven by servo to fix other test
failures related to keeping EC and AC reboots in sync.
This CL adds a new argument 'wait-ext' to the EC reboot command.
When this option is used, instead of the EC generating a reset via
it's system watchdog, it will wait 10 seconds for EC_RST_L to be
driven.
BUG=b:64603944
BRANCH=coral
CQ-DEPEND=I086687c3dd7591460099267880d56ab8265d2e4b
TEST=Ran "/usr/bin/test_that --board=coral <ip addr> firmware_DevMode"
mutliple times and verified that it passes. Previoulsy, this test
always fails when the EC is in RW before it starts. Also tested
platform_ServoPowerStateController_USBPluggedin and verified it passed.
Change-Id: I614f9156066d5719601ee43e29c7a064f9bba6e2
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/737524
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Enables the clock to the debug module so that when connecting via SWD
debugger the watchdog and timers are stopped.
BRANCH=master
TEST=Build on stm32f0x board and connect via SWD, observe no watchdog
reset.
Change-Id: Ic40b16c09acc5920da2c1a39e9391a6b21849d2c
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-on: https://chromium-review.googlesource.com/765290
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add espi control module for it83xx.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. it8390+Intel SKL-Y RVP3 and boot to shell.
2. console command "kbpress 1 4" to test keyboard data.
(board code for espi module test on CL:392587)
Change-Id: I1b32bd16f7e01abf07b9c9a68ebef2399cc9828d
Reviewed-on: https://chromium-review.googlesource.com/394471
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The original assembly code of deep sleep bypass will cause build error
if both CONFIG_LOW_POWER_IDLE and CONFIG_LTO are defined when buildiing
board glkrvp/zoombini. This CL fixed it by change the bypass assembly code
from:
asm ("push {r0-r5}\n"
"ldr r0, =0x100A8000\n"
"wfi\n"
"ldm r0, {r0-r5}\n"
"pop {r0-r5}\n"
"isb\n"
);
to:
asm ("push {r0-r5}\n"
"wfi\n"
"ldm %0, {r0-r5}\n"
"pop {r0-r5}\n"
"isb\n" :: "r" (0x100A8000)
);
BRANCH=none
BUG=none
TEST=No build errors for "make buildall".
TEST=build zoombini/glkrvp with CONFIG_LOW_POWER_IDLE and CONFIG_LTO,
no build errors.
TEST=build npcx7_evb/npcx_evb and do stress test for deep idle->wakeup
on EVB, no symptom observed.
Change-Id: I90b13b4baf418e3f4b3234d4811e3978b6436aac
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/756535
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
With this change, we can keep a PWM channel active during
low-power idle (EC deep doze).
BRANCH=none
BUG=none
TEST=The pwm channel is function normally in deep doze mode.
And tested pwm frequency setting are:
300, 250, 200, 150, 100, 50, and 10 (Hz)
Change-Id: Ie94cd96e819c869bdde6d7675d8f1a6cfc627f3b
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/752702
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With these changes
$ CROSS_COMPILE_nds32=/opt/coreboot-sdk/bin/nds32le-elf- \
make BOARD=it83xx_evb
works for me.
The -mno-gp-direct option is replaced with -mcmodel=large in new
compilers, as indicated in private email with Andes Tech. It was also
used as a work-around and leaving out the option altogether reduces the
code size significantly, so it's now dropped.
BRANCH=none
BUG=b:35572628
TEST=the above command creates an image
Change-Id: Ib580d65e6e52f291fdb920b7b65fb22cfda9f736
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/753623
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Sometimes the AP will generate a short 'wake' pulse on the SPS CS line
just in case the chip is in the sleep state. This pulse is supposed to
wake up the chip and prepare it to process the actual SPS transaction
which follows the wake pulse in 100 us.
It turns out that under certain conditions it takes the Cr50 longer
than 100 us to react to the wake pulse, for instance when it writing
into flash which is in the same bank the code is running from, there
is no way to avoid stalling in this case.
What happens then is that the 'CS deasserted' interrupt for the wake
pulse comes while the actual SPS transaction is in progress. In this
case when processing the CS deassertion interrupt the Cr50 should not
consider it an end of a transaction, but just ignore it making sure
that the next CS deassertion still would trigger an interrupt.
BRANCH=none
BUG=b:68012381
TEST=verified that this patch helps the AP firmware test case which
was often failing due to TPM getting out of sync.
Change-Id: I412459552f4b2d13cd72800c1af7d583226e8466
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754505
TPM reset processing takes certain time, and conceivably the AP could
start SPI transactions before TPM reset is finished. If the SPS
interface comes up while the CS line is active, the H1 controller
considers this a start of the SPI cycle, even though it is not - the
AP has already transferred the header and is waiting for the flow
control.
Let's not complete SPS interface initialization while the CS line is
kept active.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I53cd49c6139f3c29c4b6d234c7ee4d527c8282f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no point in invoking SPS receive handler if there has been no
data transferred while CS was asserted, as would be the case when the
AP generates the wake up pulse.
Also, make sure that the flag indicating that data was seen is cleared
when the interface is reinitialized, as TPM reset could come during an
SPS transaction.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I82d63d257b67a715d6dbc540c2d7480e5ff718ff
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
gcc 6.3 (as provided by coreboot-sdk) needs that to know which code
paths end early.
Also add a loop after the command that is "supposed" to reset the
machine so that the compiler believes it (and in case that assumption
fails).
BRANCH=none
BUG=b:65441143
TEST=none
Change-Id: Idb87253ec7880d66ffec30d75f4d007f02f63aab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/742916
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Add a common hook handler on CHIPSET_RESUME to log port80 resume
message instead of duplicating the same code in all chip lpc_resume.
BUG=b:68669668
BRANCH=None
TEST=Verified that port80 resume is logged on S0ix and S3 resume.
Change-Id: I313692f5499717d0d8f62be2ba3b8566c46e4dde
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new LPC helper routine lpc_resume_clear_masks that can be used
to clear SCI, SMI and wake masks upon resume from S3. This is done to
mask the events until host explicitly unmasks them.
It also ensures that these masks do not get reset on resume from S0ix
where the host does not re-configure these masks.
BUG=b:68669668
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. On resume from S0ix, SCI mask is not reset.
3. On resume from S3, SCI mask is reset and then set again by host request.
Change-Id: I17a86bd60ef066b3716fb79ecce62f311eb45509
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
According npcx ec wake-up mechanism by espi VW events, the driver
needs to make sure the IE/WE bits in VWEVMSn and the VWUPD bit in
ESPIWE registers are both set. Or ec won't wakeup by VW signals until
the other wake-up events occured. (WE bit of VWEVMSn is introduced on
npcx7.)
In this CL, we turn on IE/WE bit in VWEVMSn registers during espi driver
initialization and toggle the bits of ESPIWE register for VW and general
events such as ESPI_RST and so on when ec turn on/off host interface's
interrupts to make sure ec can wake-up from deep idle by espi events in
time.
BRANCH=none
BUG=none
TEST=No build errors for npcx5/7 series. Using "suspend_stress_test -c
1000" to do stress test and no symptom occurred on poppy. Both warmboot
and coldboot stress test for 5 hours and no symptom occurred on poppy.
Change-Id: I853532508bf9da5f3abc39e20ab848e659ca5e26
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/725559
Reviewed-by: Amit Maoz <amit.maoz@nuvoton.corp-partner.google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Also, fix uart_rx_available to only call
clock_refresh_console_in_use when the default pad is selected.
BRANCH=none
BUG=b:65526215
TEST=On Lux, EC console works, so does pad-switching EC-EC comm,
and idlestats shows that the EC goes to deep sleep.
TEST=In uart_alt_pad_write_read, increase usleep time in loop from
100 to 10000 (the shorter 100us time prevents EC from going
into deep sleep during the transaction), no transaction
error in EC-EC communication when system goes into deep sleep.
Change-Id: I3855b07f37def0ac9cfd700318ba64c432d3c42b
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/735103
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Define NPCX_UART_* macros instead of having so many ifdef
NPCX_UART_MODULE2 in the code.
Also, do not set NPCX_WKEDG bit in npcx_uart2gpio: instead
set it in uart_config just just like NPCX7 does it.
BRANCH=none
BUG=b:65526215
TEST=On Lux, EC console works, so does pad-switching EC-EC comm.
TEST=Flash soraka, using "idlestats", check that EC goes into
deep sleep, and that it can be woken up typing in EC console.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: I84b4f980fa79ed43640df4afc23cdc24cca21d99
Reviewed-on: https://chromium-review.googlesource.com/730029
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
NPCX5* only has one UART controller, which can be switched
between 2 pads. We keep the default pad for EC console,
however, we allow switching to the alternate pad for short,
infrequent, transactions. Both pads are assumed to use the
same baudrate and other line settings.
When switching pad, we first configure the new pad, then switch
off the old one, to avoid having no pad selected at a given time,
see b/65526215#c26.
Because of the added complexity of npcx_gpio2uart (and the fact
that it uses the global variable "pad" define in uart.c), we
move the implementation to uart.c (npcx_uart2gpio is also moved
for consistency).
When the pad is switched to alternate pad, characters input
and output on the EC console (default pad) would be lost. To
compensate for this, we:
- Switch back to main pad in case of EC panic, so that output
is shown on EC console.
- Immediately abort current alternate pad transaction if a
character is received on the default pad. Note, however,
that the first character will be lost (this can be worked
around by telling user to press enter, and have servod/FAFT
always send 2 blank lines (instead of just one) before
sending a command).
- Inhibit pad switching for 500ms after receiving a character
on default pad. Assuming a reasonable typing speed, this
should allow developers to type console commands relatively
comfortably, while not starving the alternate pad communication
for too long.
The logic above could be simplified significantly by implementing
software flow control (XON/XOFF, see b/67026316).
BRANCH=none
BUG=b:65526215
TEST=While follow-up CL that writes long 1k buffers, the following
works fine:
- type 'uart' in EC console
- Read battery power consumption from servod, which "types" in
the EC console:
while true; do dut-control ppvar_vbat_mw; sleep 1; done
no failure is seen.
TEST=Add this test code in uart_alt_pad_read_write, after the pad
has been switched, and check that panic information is
consistently printed correctly:
{
static int t;
if (t++ > 20)
t = t / ret;
}
Change-Id: I18feed2f8ca4eb85f40389f77dac3a46315310e7
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/659458
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In some scenarios we want to take RW updates w/o taking version numbers into consideration,
much like the behavior we get w/ CR50_DEV.
But then without the additional CR50_DEV features enabled for the rest of the code.
BRANCH=none
BUG=none
TEST=compiles
Change-Id: I7dd946ab77bbdc35850ed934cd53735418e13845
Reviewed-on: https://chromium-review.googlesource.com/724967
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
Instead of duplicating the handling of host events and host event
masks in chip lpc drivers, add routines in common code to provide
basic functions like setting/getting of masks, setting/getting of
events and handling of masks transitions across sysjump.
BUG=None
BRANCH=None
TEST=make -j buildall. Verified following:
1. Event masks are correctly retained across sysjumps.
2. Wake from S3 works fine.
3. Wake from S0ix works fine.
4. SCI generated correctly.
Change-Id: Ie409f91b12788e4b902b2627e31ba5ce40ff1d27
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/707771
Reviewed-by: Shawn N <shawnn@chromium.org>
It turns out the code logic is not exactly correct: the range for
coarse trim values is 0..0xFF.
Use the fixed top of the range value and do not print messages if the
value is at the range boundary.
BRANCH=cr50
BUG=b:67788437
TEST=Observed occasional messages on the Cr50 console when
plugging/unplugging Suzy-Q, but not the constant spew.
Change-Id: I94ab581769ba8326346b636b1342136e98d61ff1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/723981
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In npcx5, the flash interface pinmux should be turned on in order to
access the external flash. However, in npcx7, the internal flash is
used. It is meaningless to turn the pinmux on. And it also causes the
alternative function of these pins not work normally(such as
GPIOA0/GPIOA2) if the pinmux is enabled. This CL uses the preprocessor
flag NPCX_INT_FLASH_SUPPORT to conditionally prohibit the execution of
flash pinmux code.
BRANCH=none
BUG=none
TEST=No build errors for "make buildall". Build npcx_evb and npcx7_evb
boards, make sure the pinmux are correctly configured seperately.
Change-Id: Iba2300159f204b65d15852ec1755714df0c64816
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/704316
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Previously, an error reading Board ID would prevent any image from
running, even a wildcard (unrestricted) image with mask=flags=0 which
would match any Board ID.
Now, if Board ID can't be read, match the image against
type=type_inv=flags=0. This will match only an unrestricted image.
(This is better than checking directly for an unrestricted image,
because that check is more susceptible to clock-jitter-induced errors.)
BUG=b:67651806
BRANCH=cr50
TEST=Hack read_board_id() to return error. See that an unrestricted
image will now boot.
Change-Id: I1071e146b4541e8efd50c8409b8f76012a107731
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/713574
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The default RTCCLK comes from LSI, which can vary from 30kHz to 60kHz.
To use stm32 RTC for applications requiring accurate timing, let's setup
LSE (a more accurate clock source) as RTCCLK.
Also fix a typo in register.h as 'BCDR' should be 'BDCR' globally.
BUG=b:63908519
BRANCH=none
TEST=boot scarlet rev1 and wait for an hour,
confirm rtc time == kernel system time.
Change-Id: If4728bdd3b6384316e5337004a49c172eaec869d
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/679601
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a PERSO_AUTH appid to sign data passed through the
AUTH mn50.
Add a signer command to start and generate signatures.
Clean UART init to avoid spurious nonprinting characters
that will contaminate the siugnature.
BUG=b:36910757
BRANCH=None
TEST=generates signature for uart and spi
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I5fc3c4ee34898421060b57b774a09734f6a1bae5
Reviewed-on: https://chromium-review.googlesource.com/670984
Reviewed-by: Marius Schilder <mschilder@chromium.org>
The way AP resets ec rtc alarm is to set rtc alarm wake time in 0 sec.
In current implementation, this still sets host_rtc_alarm_set.
...So when rtc irq is triggered next time, it wakes up the host even if
the alarm is not set by the host.
Let's fix it.
BUG=b:66971951, b:67379662
BRANCH=none
TEST='powerd_dbus_suspend' and see the host stay in suspend mode
Change-Id: I1e14f669e3d887874548813c7c5b4d21d80bc62e
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/699657
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When the host sets rtc alarm wake time = 0, it wants
to reset and disable the alarm.
Also, align the implementation in npcx with that in stm32
to check both delay_s and delay_us.
BUG=b:66971951, b:63908519
BRANCH=none
TEST='ectool rtcsetalarm 3'. After alarm goes off, run
'ectool rtcgetalarm' and then see 'Alarm not set'.
Change-Id: I693f1c72cba492e837891c716f79e2aa4da59b2a
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/691256
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
To aid with severe flash space shortage, let's enable
CRYPTO_TEST_SETUP only if CR50_DEV is set to a value exceeding 1.
board/mn50/board.h used to define CR50_DEV without any value assigned
to it, correct this so that the check in dcrypto.h works when mn50 is
built.
BRANCH=cr50
BUG=b:65253310
TEST=compiling with CR50-DEV=1 vs CR50_DEV=2 saves more than
17.5 Kbytes per RW image.
Change-Id: Ic77fa45b1a8f7631efa91c08e63438d412196eed
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690993
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we don't use IT8320's PD module, we should dis-connect resistor
to GND and disable CC related function to make sure these pins can
work as other function.
BRANCH=none
BUG=none
TEST=CCCSR register setting is 0xff after initialization if
we don't enable CONFIG_USB_PD_TCPM_ITE83XX.
Change-Id: I97e019ec1c9c852cd758b364a5e7913de1fc84f4
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/689435
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In npcx7, we introduced a new bit, VWUPDW, in ESPISTS register to
indicate a Master-to-Slave VW signal was updated and the relevant WE
bit is 1. But there's no relevant IE bit in ESPIIE for VWUPDW, old
mechanism for clearing pending bits of ESPISTS will ignore this bit.
And ec cannot enter deep sleep anymore since this bit is set. This CL
fixed this bug by setting bit 17 of mask variable if ec is npcx7 series.
BRANCH=none
BUG=none
TEST=No build errors for npcx5/7 series.
Change-Id: I80c57d3c230e9d06ba134538ccdcd29f290bb7bf
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/672183
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Amit Maoz <Amit.Maoz@nuvoton.com>
In this CL, we introduced new bit fields of eSPI registers on npcx5/7
for the incoming patches. We also remove useless registers such as
VWGPMS, VWGPSM and PING in order to let the driver look more clearly.
This CL also includes:
1. Fixed typo from ESPIIWE to ESPIWE.
2. Introduce ESPIWE bits fields on npcx5/7.
3. Introduce new bit fields in ESPISTS of npcx7.
4. Remove useless VW1-4, VW1IE1-4 bits in ESPISTS and ESPIIE registes.
5. Introduce new bit field, WE, in VWEVMSn register of npcx7.
BRANCH=none
BUG=none
TEST=No build errors for npcx5/7 series. Using "suspend_stress_test -c
1000" to do stress test and no symptom occurred on poppy. Both warmboot
and coldboot stress test for 3 hours and no symptom occurred on poppy.
Change-Id: Ie8aa3dbd148588b0d9a756572d66604a6836a760
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/672026
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Amit Maoz <Amit.Maoz@nuvoton.com>
The current stm32 rtc driver only uses RTC_TR and RTC_SSR.
So we son't be able to use rtc for applications which need
time > 24 hours.
To support such applications, this patch adds operations
for RTC date register (RTC_DR).
BUG=b:63908519
CQ-DEPEND=CL:666985
BRANCH=none
TEST=manually with 'ectool rtcset/rtcset' and '/sys/class/rtc/rtc0',
verify the conversion between calendar time and Unix epoch time works.
Change-Id: Iacd5468502e4417a70880d7239ca5e03353d9469
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/659337
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The array storing deltas between sequential prime numbers could be
compressed, as the vast majority of the values in the array does not
require more than 4 buts to store.
The new storage format is as follows:
- each differential value (difference between two consecutive primes)
is halved and stored in 4 bits, two halved values are packed per
byte.
- I the first one of of the two sequential halved values exceeds 0xf,
it is stored in the array followed by a zero, stored as is (without
halving), thus taking two bytes.
- if the second one of the two sequential halved values exceeds 0xf,
both values are stored in the array as is, both prepended by zeros,
thus taking 4 bytes.
The code calculating the sequential primes parses the array according
to this format. Storing the primes in this format allows to shave from
the image size 1848 bytes.
BRANCH=cr50
BUG=b:65253310, b:65287300
TEST=verified that test_rsa test from the tpmtest suite passes.
verified that the list of prime numbers printed out when
PRINT_PRIMES is defined and test_rsa is ran is the same before
and after this patch.
Change-Id: Ifdc2858a48f868ef816ccb4e351d9f60703d16e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/664253
Reviewed-by: Nagendra Modadugu <ngm@google.com>
- To i2c channel(d/e/f), we remove instructions that aren't necessary.
- Changes of i2c_reset():
Before the change, we try to send a START/STOP bit if we get a reset.
But i2c_unwedge() already done it, so we just need reset i2c module
in i2c_reset().
- Add enhanced_i2c_start() to channel(d/e/f) for each transaction start:
We prepare transaction start by calling i2c_reset(),
but this doesn't match the definition of i2c_reset(),
so we correct it.
BRANCH=none
BUG=none
TEST=1. console commands: "i2cscan", "charger" and "battery".
2. sensors, battery, charger and mux work on reef_it8320.
Change-Id: I4e3595479e04a5994a5b19409cfc4e9a46f63d4f
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/674467
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change is required to reboot the chip without bringing down the
entire platform on boards where GPIOs are wired to external active reset
signals.
BRANCH=none
BUG=none
TEST=Scoped a pin across a reset.
Change-Id: I58d93697d39a8adcdac9324d5dd9da00745aec9a
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/644179
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When compilation is enabled, this function prints all prime numbers
generated using the PRIME_DELTAS array.
BRANCH=cr50
BUG=none
TEST=verified that prime numbers are printed out when running rsa_test.py
Change-Id: I37961aad146c4aeecca9a84550f313450e6c5853
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/683074
Reviewed-by: Shawn N <shawnn@chromium.org>
The WebUSB specification defines a specific Platform Descriptor in the
Binary Object Store:
https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
This descriptor provides a special 'Landing page' URL to the host
browser and associated privileges for it.
Bump the USB version for BOS descriptors to 2.1 to be compatible with
Chrome implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
BRANCH=twinkie
TEST=manual: on Twinkie (chip/stm32) and HG proto2 (chip/g), enumerate
WebUSB descriptors with lsusb and connect to a WebUSB page in Chrome
R61+.
Change-Id: I7211ab554f4a6c156c1e8e79a3d9f0d6644217c6
Reviewed-on: https://chromium-review.googlesource.com/664813
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the USB 2.0 specification, the "8.5.3 Control Transfers"
chapter says that "When all of the data structure is returned to the host,
the function should indicate that the Data stage is ended by returning a
packet that is shorter than the MaxPacketSize for the pipe. If the data
structure is an exact multiple of wMaxPacketSize for the pipe, the function
will return a zero-length packet to indicate the end of the Data stage."
When doing a 'Control Read' transfer and the returned data (in IN
packets) was a multiple of MaxPacketSize, we were omitting the
zero-length packet and so the host was blocked waiting for a successful
IN transaction.
This corner-case was a regression introduced by the re-writing of the
control transfer handling done by CL 318864. So the STM32 USB code which
is similar to the former code is dealing properly with this case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=none
TEST=manual, extend the configuration descriptor to be exactly 64 bytes,
and see the enumeration is no longer failing.
Change-Id: I108e8c6bb9eb727c41f3e1c607f0919fa1192d5a
Reviewed-on: https://chromium-review.googlesource.com/664814
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>
Reviewed-by: Shawn N <shawnn@chromium.org>
lsusb scans for USB_DT_DEBUG, which produces logspam
on the cr50 console. This isn't an error, just unimplemented.
Remove the printout.
BRANCH=cr50
BUG=b:65407184
TEST=no logspam on lsusb
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: Ib4fc7105015506927f45ee02f587f97e46e1ad9b
Reviewed-on: https://chromium-review.googlesource.com/663786
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For historical reasons, CCD, reset, and power button control were
scattered around several files. Consolidate the code in more sensible
(in retrospect) places.
No functional changes, just moving code.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50
Change-Id: Ic381a5a5d0627753cc771189aa377e88b81b155e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653766
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We disable i2c interface immediately after stop bit is set.
This might caused bus busy bit of status register unable to clear
(bus busy bit will be set at start condition and cleared at
stop condition).
So the next transaction, we won't get a good state to start.
This change also fix incorrect stop bit for write transaction:
IT83XX_I2C_CTR(p_ch) = xx
BRANCH=none
BUG=none
TEST=Ensure i2c interface is disabled after i2c stop condition.
Change-Id: I5416bfcef3f95357c6771dead6b0611b908f787e
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/645407
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Default setting of embedded flash's clock is 24 or 32 MHz
and PLL is 48 or 96 MHz correspondingly.
And it8320 supports e-flash clock up to 48 MHz,so we add
a new config option to support it.
BRANCH=none
BUG=none
TEST=Run FAFT with e-flash 48MHz and test results are passed.
Change-Id: I096ae3abc8fec9bd7e0556c57605e87a31ac3b07
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/645466
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
