| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The L4/L5 families have four I2C controllers. The fourth has its
registers in a separate region, and enable bits are not contiguous with
the first three.
This CL adds a few if-statements in i2c driver code, in order to support
all four controllers.
BUG=b:282999020
TEST=Observe I2C activity on HyperDebug I2C4
Change-Id: If27eda73b3da32190bad7df5db8c6bb6c78b4c5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4537011
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL will add macros used to set MIWU interrupt priorities. These
macro can be set by each board to adjust priorities as needed.
BUG=b:279918234
TEST=build agah
Change-Id: Ide840e4ab8cc9aa8deb83b6ad76fa64bc0d83972
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4518230
Auto-Submit: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
| |
BUG=b:280889889
TEST=add CONFIG_RNG to NPCX based board.h file (e.g. npcx9_evb)
Change-Id: I93b3a7742c3b7d614cc1218104cd642b3339f8b3
Signed-off-by: David Cross <davidmcross@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4507895
Reviewed-by: Bobby Casey <bobbycasey@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Making this change causes common trng functions to move memory
locations. This change only affects fingerprint (FPMCU) boards
BUG=b:280889889
TEST=make BOARD=bloonchipper, CONFIG_CMD_RAND enabled in board.h
ALLOW_CONFIG=1 ./util/compare_build.sh -b all
=> All boards match, except the following Fingerprint boards:
bloonchipper
dartmonkey
hatch_fp
nami_fp
nocturne_fp
nucleo-dartmonkey
Change-Id: I4dbb5e255be0f61eb7b446af4565bea487c08e52
Signed-off-by: David Cross <davidmcross@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4507892
Reviewed-by: Bobby Casey <bobbycasey@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file i2c-stm32l4.c practically already had support for changing I2C
speed. This CL renames and exports the function for setting speed, such
that i2c_controller.c can call it.
BUG=none
TEST=Observe HyperDebug I2C still working, and now able to change speed
Change-Id: I2fbe674795f9e8ed0b8d324cc1ff68f4df4174a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4506619
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some voltage dividers, factor_mul is large enough that the
intermediate value can overflow, so use a 64-bit int.
BRANCH=None
BUG=b:271941405
TEST=VBUS ADC calculation doesn't overflow on dibbi
Change-Id: I993e62e7c0ae31c70f962303e7a618841f2bc772
Signed-off-by: Reka Norman <rekanorman@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4506010
Commit-Queue: Reka Norman <rekanorman@chromium.org>
Tested-by: Reka Norman <rekanorman@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving the body of the USB_SPI_CONFIG() macro into usb_spi.c allows
eliminating the "trampoline functions", for a slight performance
improvement, and simplification of the code.
BUG=b:273601311
TEST=HyperDebug still able to forward SPI requests
Change-Id: Id64c0a30c791962dbe4360c92dc512e6c2adc2f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4370998
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Brian Nemec <bnemec@google.com>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the finger printer sensor needs multiple SPI transactions in the same
command state without de-asserting the CS pin, this commit implements:
- spi_transaction_async() - does the same thing as the original
spi_transaction does but keeps asserting the CS pin.
- spi_transaction_flush() - de-assert the CS pin.
- spi_transaction_wait() - a noop function as we don't support SPI DMA.
The original spi_transaction() is hence changed to call
spi_transaction_async() and spi_transaction_flush() to
prevent code duplication.
BRANCH=none
BUG=b:266703380, b:269695617
TEST=Test console commands
spi_flashinfo/spi_flashread/spi_flashwrite/spi_flasherase.
TEST=write a test console command to read the unique ID from flash with
multiple spi_transaction_async() calls + 1 spi_transaction_flush() call.
Change-Id: I3aacef0063a7cf2c1f70dfe2683b67110cdd9f5f
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4305803
Reviewed-by: Bobby Casey <bobbycasey@google.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: David Cross <davidmcross@google.com>
Commit-Queue: David Cross <davidmcross@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL extends the SPI controller driver to support the concurrent
transaction:
- if the parameter "rxlen" is set to SPI_READBACK_ALL when
spi_transaction() is called, the received data during the transmission
phase should be stored in the "rxdata" buffer.
BRANCH=none
BUG=b:268286582
TEST=Loopback test on the npcx9 EVB, make sure the received data in the
rxdata buffer is the same as that in the txdata buffer.
Change-Id: Ia5ae17fefb69ce18709ded87693b34ed861f4997
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4259466
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: David Cross <davidmcross@google.com>
Commit-Queue: David Cross <davidmcross@google.com>
Reviewed-by: Bobby Casey <bobbycasey@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current pre-scalar setting (fixed to 0), the max watchdog timeout
that the user can set is ~8 seconds. It is not enough for some
application requirements such as FPMCU. This commit extends the max
timeout by adjusting the pre-scalar dynamically.
BRANCH=none
BUG=b:273577369
TEST=pass "make buildall -j"
TEST=Change the CONFIG_WATCHDOG_PERIOD_MS > 8 seconds; type console
command "watims ${timeout}"; make sure watchdog panic occurs as
expected.
TEST=Set the CONFIG_WATCHDOG_PERIOD_MS to the default (1600); make sure
WDCNT and WDCP are the same before/after applying this commit.
Change-Id: I11b764811f65f0956593ab6725a619a1a44464c4
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4444452
Reviewed-by: David Cross <davidmcross@google.com>
Tested-by: David Cross <davidmcross@google.com>
Commit-Queue: David Cross <davidmcross@google.com>
Reviewed-by: Bobby Casey <bobbycasey@google.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=`make BOARD=helipilot`
BRANCH=none
Signed-off-by: David Cross <davidmcross@google.com>
Change-Id: Ib6e0ccc2eac31f47326e27459c9ee8c32585a7ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4007183
Reviewed-by: Bobby Casey <bobbycasey@google.com>
Reviewed-by: CH Lin <chlin56@nuvoton.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:248508087
TEST=make buildall -j
BRANCH=none
Force-Relevant-Builds: all
Change-Id: If691bd1400b65c5595b833293578e16208c49849
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4376399
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support to usb_spi.c for processing a new "Flash Command Start"
packet, as an alternative to the existing "Command Start" packet. The
new serial flash version carries additional flags, among others, to
request a one-byte "Write enable" transaction to take place before the
main transaction, and to request repeated polling of the "busy bit"
after the main transaction. These allow the number of USB round trips
to be reduced when using Servo Micro or C2D2 for flash programming.
Also, flags of the new request allow the caller to ask for dual or quad
lane communication, which can be supported by board-specific SPI
drivers. This is intended for use on the HyperDebug debugger board.
BUG=b:273601311
TEST=c2d2 flashing gets slight performance boost
Change-Id: Id4d1ec9f37387b4e083a397ca15300455f7a0ada
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4346952
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This first attempt turned out to be too closely coupled to the
capabilities of the STM32L5xx OctoSPI, allowing odd combiations that is
never used by actual SPI flash chips.
BUG=b:273601311
TEST=make BOARD=c2d2
Change-Id: I3fd5b1356d1c2c3a7d63dbdf8e1a5fd45ddfe0a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4432090
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:248508087
TEST=make buildall -j200
TEST=./util/compare_build.sh -b all
=> Most of the compare result match except for
adlrvpm_ite, adlrvpp_ite, adlrvpp_mchp1727, cozmo,
icarus, it8xxx2_pdevb, mchpevb1, npcx_evb, npcx_evb_arm
pico. And differ the change is the address of
clock_enable_module.
BRANCH=none
Change-Id: I5750c5d5037f303f6cf55a73a1cd5a9501b49aa1
Signed-off-by: Yi Chou <yich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4369174
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function is not used anywhere except test/rng_benchmark.cc, so we
will have a problem with code coverage when implementing the function
using Zephyr API.
The RNG benchmark was modified to use trng_rand_bytes() function.
BUG=b:277029648
BRANCH=none
TEST=./test/run_device_tests.py --board bloonchipper -t rng_benchmark
Change-Id: Ic6cf7e511b2e8fe88a08e9e1c4354f7afa9ae425
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4423151
Tested-by: Patryk Duda <patrykd@google.com>
Commit-Queue: Patryk Duda <patrykd@google.com>
Reviewed-by: Keith Short <keithshort@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HC version v1 response has 132 bytes, but ISH response buffer is
smaller than this. We will get error as below:
localhost ~ # ectool version --name=cros_ish
EC result 14 (RESPONSE_TOO_BIG)
Hence increase ISH response buffer size to 260 bytes.
BUG=b:271502099
BRANCH=none
TEST=on Rex platform with ISH enabled, "ectool version --name=cros_ish"
will print firmware version, no error.
Change-Id: I81cbea19a2b4719b88b232bfea02803b0a244b89
Signed-off-by: Li Feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4302834
Reviewed-by: Yuval Peress <peress@google.com>
Reviewed-by: Tanu Malhotra <tanu.malhotra@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The USB_SPI_CONFIG() macro allowed a set of "run-time" flags to be given
by board.c. However, these flags have to be known at compile time, and
always are. They can more conveniently be given through a CONFIG_
define.
With the above, and a little tweak in hammer/board.h (mimicking what was
already done for I2C), then every invocation of the USB_SPI_CONFIG()
across the codebase is identical, setting the stage for moving the
declarations into usb_spi.c, and eliminating the macro altogether.
BUG=b:273601311
TEST=none
Change-Id: Id565338238a7c21f7e2c6c24b7c4e3d7648482f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4368551
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Brian Nemec <bnemec@google.com>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, all methods in usb_spi.c pass along pointers to config
and state, as if prepared to have multiple USB interfaces each
implementing their own instance of the SPI->USB bridge protocol. Doing
so would make little sense, as a single instance is already able to
manipulate multiple SPI busses.
This CL eliminates the pointer parameters, for a tiny performance
improvement, and code simplification.
BUG=b:273601311
TEST=none
Change-Id: Ifbfdb18b4a2ba656732e4eb143de9f678416067a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4352128
Reviewed-by: Brian Nemec <bnemec@google.com>
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pre-watchdog warning interrupt handler currently invokes
get_panic_data_write() to retrieve a pointer to panic data. This has a
side-effect of initializing the panic data with PANIC_MAGIC and a panic
data size without other pertient fields set. As a result, the EC reports
malformed panic to the AP causing an unparsable EC crash to be reported.
Revert the ITE watchdog warning interrupt usage of
get_panic_data_write() to using the global PANIC_DATA_PTR pointer to
panic data.
BRANCH=none
BUG=b:247100203
TEST=On drawcia, dead battery boot, invoke waitms 1100 (pre-wdt warning),
invoke ectool panicinfo to check for well-formed panic data
TEST=On drawcia, invoke crash watchdog, invoke ectool panicinfo to check
for well-formed panic data.
Change-Id: I5a75bec0efa79d00c358edc0645a0a0d39a879d2
Signed-off-by: Aaron Massey <aaronmassey@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4358752
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enhance the interface to board-specific SPI driver such that it can take
flags for advanced serial flash chip protocols (dual/quad lanes, dummy
cycles, double transfer rate).
BUG=b:273601311
TEST=c2d2 can still flash (using single-lane)
Change-Id: Iee6a17077ea8c382c7d59bd404bf5d033bd9b517
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4336273
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables SHA256 accelerator for all boards using NPCX9.
Before:
[0.007394 hash start 0x00040000 0x0002f97c]
[0.291092 hash done e7faf382c6bd60c892cb4af...]
After:
[0.038571 hash start 0x00040000 0x0002f97c]
[0.095532 hash done e7faf382c6bd60c892cb4af...]
BUG=b:272132276
BRANCH=None
TEST=Agah
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I10660e423ee16b2a6bcb3dd147593b6c7e4cf952
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4348896
Reviewed-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During my investigation into performance of SPI flashing with servo-like
devices, I stumbled upon an odd behavior. It seems that asynchronous
execution of write-only SPI transactions does not quite work on STM
chips.
For transactions that consist of writing a few bytes followed by reading
a block of data, the current spi_transaction_async() works well, in that
it first performs the write part, then waits for the DMA to finish,
before setting up the larger read part, and returning without waiting
for it to finish. Later, spi_transaction_flush() will call
spi_dma_wait() to know when the transfer has completed.
For write-only transactions, however, spi_transaction_async() blocks in
its "intermediate" spi_dma_wait(), before realizing that there is
nothing to read, meaning spi_transaction_async() in effect blocks until
the transaction is complete, and the subsequent spi_dma_wait() in
spi_transaction_flush() is superfluous.
I have found that with this very small change, spi_transaction_async()
will return soon after a write-only transaction has been initiated, and
spi_transaction_flush() will wait for its completion.
BUG=b:273601311
TEST=Flash using c2d2 and HyperDebug
Change-Id: I015f2870b1f0e561050b75618545dee6bcf04690
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4336269
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The config from EC collides with the same config from Zephyr.
BUG=b:239712345
BRANCH=none
TEST=make runhosttests buildall
Change-Id: Ic6e63ea6dd9e745e82feb2af04b77069c2d78af1
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4295699
Reviewed-by: Keith Short <keithshort@chromium.org>
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
Commit-Queue: Patryk Duda <patrykd@google.com>
Tested-by: Patryk Duda <patrykd@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ADC drivers for STM32L4 (and L5) seems to have significant flaws.
The chip has the ability to continuously perform ADC conversions
according to a set sequence of channels and bit depths. In addition to
that, the chip can perform a one-off "injected" sequence of up to four
channels, in response to a hardware or software trigger.
The driver uses only a software triggered "injected" sequence to convert
two pre-set channels.
The code of `adc_read_channel()` has some odd properties, though. On
first invocation, it sets up the injected sequence to consist of the two
configured ADC channels. Each invocation takes one particular ADC
channel number as input, but the code simply kicks of the sequence of
two channels to read, and then returns the relevant of the two,
discarding the other reading.
The has the needless limitation that it cannot be used with more than
two ADC channels.
Since it is permitted to modify the list of channels in the injected
sequence as long as no conversion is in progress, it would be more
straightforward, if each invocation of `adc_read_channel()` would
reconfigure the injected sequence to consist of a single channel, the
one requested. This CL makes that change.
BUG=b:269621551
TEST=Read and of a dozen ADC channels on HyperDebug
Change-Id: I62387979faf494cfefc3b6e7dd1d9a1954017ae6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265223
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Eric Yilun Lin <yllin@google.com>
Auto-Submit: Jes Klinke <jbk@chromium.org>
Reviewed-by: Eric Yilun Lin <yllin@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STM32L4/5 ADCs use three bits to configure the time to sample the
input voltage, that is the time during which an analog MUX conducts,
allowing the internal holding capacitor to settle. The enums declared
in adc_chip.h has eight usable values, plus an additional value called
DEFAULT.
It makes sense to have the DEFAULT be represented by a zero value, such
that if a board.c file does not mention the sample_time field in its
adc_t, then due to the C convention of data being zero-initialized, the
code can detect it and apply a sensible default.
However, the body of adc_configure() has no such logic, but takes the
raw enum value and attempts to stuff it into a 3-bit field, which will
be off by one, and overrun for the largest enum value of 8.
Also, I find the term "sample rate" misleading, as it implies a
continuous process. This sample time setting applies equally to one-off
injected conversions, as it refers to the duration of the sampling of
the input signal, before conversion begins, not a rate of conversions
happening.
BUG=b:269621551
TEST=Made measurements with the longest same time setting
Change-Id: Id8d297fcec883565dea1e09d6bbbfa1ab564778d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265222
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In several cases, the L4 and L5 series can use the same driver, which is
different from other STM32Lx chips.
This CL introduce a warning at the top of such files, alerting readers
to the fact that they are also used by L5 despite this not being
apparent from the file name.
BUG=b:269621551
TEST=none
Change-Id: I6edff6c0aea57ea9679729db20a292d75b4b8df0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4264176
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The convention of the STM32_ADC1_ISR register is that writing a 1 to any
bit clears that one latched interrupt status bit. Existing code wrongly
uses |= on this register, effectively clearing every latched bit in the
register, not merely the intended one.
BUG=b:269621551
TEST=Observe ADC conversions on HyperDebug
Change-Id: Ia9fe3f6ca6f2f67614628b23bc7ba2e3a3caf058
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265221
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The L5 family has basically the same ADC component as L4.
L5 does not have ADC3, but that happened to not be used by the
stm32l4.c, so the existing implementation can be used without
modification.
BUG=b:269621551
TEST=Observe ADC conversions on HyperDebug
Change-Id: I4ce279dca3ff23ae2a9d2f00c23399732eecf15f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4265220
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapt dfu_bootmanager_main.c to compile without flash support.
BUG=b:192262089
TEST=make BOARD=hyperdebug
Change-Id: I9ceca733062b46ed7087ef7725bc1f6ac68c6b0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4193071
Commit-Queue: Jes Klinke <jbk@chromium.org>
Reviewed-by: Brian Nemec <bnemec@google.com>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looking at the code, it is apparent that the "pll" parameter to the
"clock" console command is valid whether STM32_HSE_CLOCK is defined or
not (though the effect may be slightly different).
This CL updates the documentation to list "pll" as a valid option also
when STM32_HSE_CLOCK is not defined.
BUG=none
TEST=make BOARD=hyperdebug
Change-Id: I7da89c15b44fbc3dad2a5fe129b0e361d7f50714
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4216263
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM Cortex documentation calls for an ISB instruction to be executed
immediately after modifying the stack pointer, see for instance:
https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-processor/programmers-model/core-registers
It would seem that instruction prefetch will "anticipate" stack pointer
movements by counting the push and pop instructions, and that the
prefetch queue needs to be cleared if the stack pointer is manually
changed. Our particular code executes does not use the stack pointer,
but executes a register jump, which I assume will also clear the
prefetch queue. So in all likelihood, the barrier instructions is not
required here, but we could as well add it, as the documentation calls
for it.
BUG=none
TEST=make BOARD=hyperdebug, observe DFU upgrading still works
Change-Id: I2a0609670b3554a39057b429fc2e0cd1201d185c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4216262
Reviewed-by: Brian Nemec <bnemec@google.com>
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the .isort.cfg from platform/ec and use the one from chromite
instead. This should be compatible with cros format.
BRANCH=None
BUG=b:267757300
TEST=Ran firmware_builder.py
Change-Id: Ice4955b6995bd1f9380e97f58e89efb7c1e8aeb1
Signed-off-by: Jeremy Bettis <jbettis@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4221928
Auto-Submit: Jeremy Bettis <jbettis@chromium.org>
Tested-by: Jeremy Bettis <jbettis@chromium.org>
Commit-Queue: Jeremy Bettis <jbettis@chromium.org>
Commit-Queue: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STM32L5 series behaves the same as STM32L4 to a large degree, so
this CL adds code to enable RTC clock on L5 using the same register bits
as on L4.
The "backup registers" however, sit in a new "Tamper" component on L5,
and not in the RTC component as on L4. This CL adds register
declarations for the TAMP component.
Lastly, jumping to the ROM bootloader with C function pointer
call, as was done in jump_to_dfu(), does not work on the STM32L5 ROM
bootloader (at least not on my Nucleo-X552EZ board.) The flaw seems to
be that an ARM vector table contains a reset vector, and separately
contains an initial value for the stack register. The previous code
made no attempt at setting the stack point as the bootloader expected,
and depending on how the EC code (and the STM ROM bootloader) is
compiled, this may or may not work. This CL adds assembly code to set
the stack pointer to the value given in the ROM header, before
performing the jump.
BUG=b:192262089
TEST=Upgrade firmware on STM32L5 based Nucleo board using dfu-util
Change-Id: I2a871f0eaf9ea9f4c27c75ccb472cd4ff9616524
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4190164
Reviewed-by: Brian Nemec <bnemec@google.com>
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, I copied STM32L4 declarations for STM32L5, making
adjustments for base addresses, and other obvious differences. It turns
out that the external interrupt controller has som subtle changes to its
registers. Most notably the EXTICR registers (used for selection which
external pin is routed to which of the 16 edge detection "engines") have
been moved from the SYSCFG component into EXTI component.
BUG=b:192262089
TEST=Observe edge detection working on HyperDebug (based on STM32L5)
Change-Id: I4ad4f2559c60bef73a29812ebac1316cfa389a3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4166670
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in espi_msvw[12]_interrupt relies on undefined behavior today.
__builtin_ctz is specified as returning values in the range [0, 31], but
we are checking for 32.
This behavior may be unexpected compared to the CTZ/CLZ instruction on
ARM, which use the value 32 to indicate that there are no ones in the
provided input.
GCC 11+ optimizes the two loops below into infinite loops, as it can see
that the condition will never be met.
After this change, the disassembly of espi_mswv1_interrupt can be
confirmed to contain an exit behind a branch.
... // r4 is loaded with girq24_result and has bits successively cleared
1a: b90c cbnz r4, 20 <espi_mswv1_interrupt+0x20>
1c: e8bd 81f0 ldmia.w sp!, {r4, r5, r6, r7, r8, pc}
20: fa94 f5a4 rbit r5, r4
...
BUG=None
BRANCH=main
TEST=Examined the disassembly for espi_msvw[12]_interrupt; see above
Change-Id: I68a5c753233a17b6b0fb61a31f1eeccf78c00aba
Signed-off-by: Dustin L. Howett <dustin@howett.net>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4114450
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Alexandru Stan <amstan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Existing code for extracting chip independent EC pin flags from stm32
registers suffered from a copy/paste error, meaning that it could never
recognize interrupt triggering on a falling edge.
BUG=none
TEST=make BOARD=hyperdebug
Change-Id: I4c752b092bfd3c6ea70192006a9453e0b81b0d9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4166669
Tested-by: Jes Klinke <jbk@chromium.org>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix checkpatch error:
> Prefer 'unsigned int' to bare use of 'unsigned'
BUG=b:262047616
TEST=./util/compare_build.sh -b all -j 120
=> MATCH
BRANCH=none
Change-Id: Ibf82332a1e1ea0a0a03d3993336e24883e495e05
Signed-off-by: Andrea Grandi <agrandi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4126483
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The coding of the enum ncl_status is not correctly defined in the SHA256
chip driver. This CL fixed it to meet the actual return code from the
SHA ROM API.
BRANCH=none
BUG=b:155771688
TEST=manually dump and check the return value from SHA ROM API.
Change-Id: Iee3ec5c7102ddc93f7afda6523c59393a5a0047a
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4113813
Commit-Queue: Keith Short <keithshort@chromium.org>
Reviewed-by: Keith Short <keithshort@chromium.org>
Tested-by: CH Lin <chlin56@nuvoton.com>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Reviewed-by: Fabio Baltieri <fabiobaltieri@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STM32L5 series of chips have a SPI controller capable of using up to
eight data lines for fast transfers, primarily with SPI flash chips.
This CL adds declarations of register addresses and bits.
BUG=b:192262089
TEST=Flashed OpenTitan FPGA via HyperDebug OctoSPI
Change-Id: I33d16ba493756cf338353a5f0952be97070720d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4087327
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Tested-by: Jes Klinke <jbk@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The STM32L5 series has a special "OctoSPI" controller, which differs
from the standard spi controllers in capabilities and means of
programming. Rather than adding drivers for OctoSPI to the common EC
code, this change allows special-purpose drivers for HyperDebug to be
implemented in its board directory.
BUG=b:192262089
TEST=Observed HyperDebug forwarding to OctoSPI controller
Change-Id: Ia31eefcb53b08cc23aa0f14a8899bc227a88ea0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077429
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Tested-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Jes Klinke <jbk@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For devices similar to Servo Micro, in case of multiple entries in
spi_devices, this change allows the USB host to request which device its
transaction requests are to be forwarded to.
BUG=b:192262089
TEST=HyperDebug board forwards to two SPI busses
Change-Id: Ic94e66a8d7f5502c3016a26a1beb24236b3c4893
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077428
Commit-Queue: Jes Klinke <jbk@chromium.org>
Tested-by: Jes Klinke <jbk@chromium.org>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL add support logging system boot time and hostcommand to get
boot time info.
EC logs elapsed time (in micro second) info since boot for different
signal events,that can be used to calculate system boot time in cold
boot and warm boot scenarios.
Below are the events when EC logs time info
ARAIL EC turns on A-RAIL
RSMRST EC releases RSMRST#
ESPIRST ESPIRST received
PLTRST_LOW PLTRST# asserted
PLTRST_HIGH PLTRST# deasserted
EC_CUR_TIME EC current time
cnt increments on every warm reboot and reset to 0 on
cold reboot
BUG=b:249163956
BRANCH=none
TEST='ectool boottime' AP console command is used to fetch data
'reboot' on AP console to trigger warm reboot
'apshutdown' on EC console to trigger cold reboot
Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com>
Change-Id: I47abe3f8a0b7ab43f2af11bf8387c006ba383020
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4081566
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Tested-by: Li-Yu Yu <aaronyu@google.com>
Reviewed-by: Boris Mittelberg <bmbm@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c8325ba18b9f4d5b1f3f3bc739e83d8f591308cf.
Reason for revert: broke at least 9 cq builds (https://ci.chromium.org/ui/p/chromeos/builders/cq/cq-orchestrator/b8795833246203447793/overview)
Original change's description:
> ec: Support logging system boot time info
>
> This CL add support logging system boot time and hostcommand to get
> boot time info.
> EC logs elapsed time (in micro second) info since boot for different
> signal events,that can be used to calculate system boot time in cold
> boot and warm boot scenarios.
>
> Below are the events when EC logs time info
>
> ARAIL EC turns on A-RAIL
> RSMRST EC releases RSMRST#
> ESPIRST ESPIRST received
> PLTRST_LOW PLTRST# asserted
> PLTRST_HIGH PLTRST# deasserted
> EC_CUR_TIME EC current time
> cnt increments on every warm reboot and reset to 0 on
> cold reboot
>
> BUG=b:249163956
> BRANCH=none
> TEST='ectool boottime' AP console command is used to fetch data
> 'reboot' on AP console to trigger warm reboot
> 'apshutdown' on EC console to trigger cold reboot
>
> Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com>
> Change-Id: I15fedbde252e0452270ef0e3fd4391bf624169f1
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3794612
> Reviewed-by: Boris Mittelberg <bmbm@google.com>
> Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Bug: b:249163956
Change-Id: Ie83026c4a3a38c3dd24522901233f06e03430a54
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4077335
Reviewed-by: Jonathon Murphy <jpmurphy@google.com>
Commit-Queue: Piotr Pawliczek <pawliczek@chromium.org>
Tested-by: Piotr Pawliczek <pawliczek@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL add support logging system boot time and hostcommand to get
boot time info.
EC logs elapsed time (in micro second) info since boot for different
signal events,that can be used to calculate system boot time in cold
boot and warm boot scenarios.
Below are the events when EC logs time info
ARAIL EC turns on A-RAIL
RSMRST EC releases RSMRST#
ESPIRST ESPIRST received
PLTRST_LOW PLTRST# asserted
PLTRST_HIGH PLTRST# deasserted
EC_CUR_TIME EC current time
cnt increments on every warm reboot and reset to 0 on
cold reboot
BUG=b:249163956
BRANCH=none
TEST='ectool boottime' AP console command is used to fetch data
'reboot' on AP console to trigger warm reboot
'apshutdown' on EC console to trigger cold reboot
Signed-off-by: Rajesh Kumar <rajesh3.kumar@intel.com>
Change-Id: I15fedbde252e0452270ef0e3fd4391bf624169f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3794612
Reviewed-by: Boris Mittelberg <bmbm@google.com>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sort all includes in board with the clang-format rules used by
the zephyr project.
BRANCH=None
BUG=b:247100970
TEST=zmake build -a
TEST=./twister --clobber -v -i
TEST=make -j72 buildall_only runtests
TEST=zmake compare-builds -a
Signed-off-by: Jeremy Bettis <jbettis@google.com>
Change-Id: I6ad72b167cbb768a64c338fa633eb4bf5a401897
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4060360
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
Tested-by: Jeremy Bettis <jbettis@chromium.org>
Commit-Queue: Jeremy Bettis <jbettis@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sort all includes in chip with the clang-format rules used by
the zephyr project.
BRANCH=None
BUG=b:247100970
TEST=zmake build -a
TEST=./twister --clobber -v -i
TEST=make -j72 buildall_only runtests
TEST=zmake compare-builds -a
Signed-off-by: Jeremy Bettis <jbettis@google.com>
Change-Id: I13454e38fa3766aa0ba26a058075f51965b8462e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4053346
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Commit-Queue: Jeremy Bettis <jbettis@chromium.org>
Tested-by: Jeremy Bettis <jbettis@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add "chip/stm32/usb_hw.h" for usb_uint
Add <stddef.h> for size_t
Switch from board.h to config.h
BRANCH=None
BUG=b:247100970
TEST=zmake build -a
TEST=./twister --clobber -v -i
TEST=make -j72 buildall_only runtests
TEST=zmake compare-builds
Signed-off-by: Jeremy Bettis <jbettis@google.com>
Change-Id: I8d6c7cb89cd54812b90afd9ec06d81f8122fbdc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4053345
Reviewed-by: Tomasz Michalec <tmichalec@google.com>
Commit-Queue: Tomasz Michalec <tmichalec@google.com>
Auto-Submit: Jeremy Bettis <jbettis@chromium.org>
Tested-by: Jeremy Bettis <jbettis@chromium.org>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was found that the hardware SHA256 accelerator is broken. This is
caused by the table address of SHA ROM API changed from 0x100 to 0x13C
since the ES2 chip.
This CL fixed the issues described above.
BRANCH=none
BUG=b:155771688
TEST=burn the same RW image; #define/#undef CONFIG_SHA256_HW_ACCELERATE;
verify the RW hash value is the same in the console message.
TEST=with the test CL:2455022, move test patterns in test/sha256.c
to board/npcx9_evb/test_sha256.c; pass all test patterns.
Signed-off-by: Jun Lin <CHLin56@nuvoton.com>
Change-Id: I12ce8531a925f02474f66d90bf7efd950b3eeba3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4033807
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: caveh jalali <caveh@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Boris Mittelberg <bmbm@google.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISH should set PMC LTR(Latency Tolerance Reporting) for DMA operation.
Without doing this, we observed system shutdown during D0i3.
This CL set LTR to 2ms before DMA operation and set LTR to a large
number after DMA operation is completed to enable SOC to go into the
lowest possible power state.
BUG=b:234136500
BRANCH=none
TEST=on Nirwen platform, ISH enter D0i3 host loading case, and also
stitching to coreboot case; S0i3 is hit and no shutdown.
Signed-off-by: Leifu Zhao <leifu.zhao@intel.com>
Signed-off-by: Li Feng <li1.feng@intel.com>
Change-Id: Ib0fe907470774998dda29a40197d6c18ad6372f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/4003320
Code-Coverage: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com>
Reviewed-by: Kyoung Kim <kyoung.il.kim@gmail.com>
Reviewed-by: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com>
Commit-Queue: Kangheui Won <khwon@chromium.org>
Tested-by: Haribalaraman Ramasubramanian <haribalaraman.r@intel.corp-partner.google.com>
Code-Coverage: Zoss <zoss-cl-coverage@prod.google.com>
Reviewed-by: Kangheui Won <khwon@chromium.org>
|