include/config_std_internal_flash.h is an optional header that
can be used to implement the most common EC flash layout.
However, CONFIG_INTERNAL_STORAGE, CONFIG_MAPPED_STORAGE, and
CONFIG_MAPPED_STORAGE_BASE are fixed by the SoC, so they belong
in config_chip.h, not in the optional header.
BRANCH=none
BUG=chrome-os-partner:23796
TEST=make buildall
Refactoring only, no behavioral differences.
Change-Id: I114c3e194837041920e6f228a2bed6747be8231c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301330
Reviewed-by: Shawn N <shawnn@chromium.org>
Since there is no more concept of a flash region belonging only to the
EC, we only need one FLASH_SIZE config, which represents the actual
physical size of flash.
BRANCH=None
BUG=chrome-os-partner:23796
TEST=With entire patch series, on both Samus and Glados:
- Verify 'version' EC console command is correct
- Verify 'flashrom -p ec -r read.bin' reads back EC image
- Verify software sync correctly flashes both EC and PD RW images
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I18a34a943e02c8a029f330f213a8634a2ca418b6
Reviewed-on: https://chromium-review.googlesource.com/297824
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When a debug accessory is connected to the type-C port while the write
protection is enabled, put the case closed debugging in "partial" mode
rather than "full".
Update the "partial" mode to provide read-only access to the AP and EC
consoles.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:44700
TEST=check the EC console input/output over USB is still working with SuzyQ
on a write-protected system, verify that the console input is disabled.
Change-Id: I5baa03d6e738d06437c45469f46b286e76a755a4
Reviewed-on: https://chromium-review.googlesource.com/297141
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The signer utility needs to be built and the flat image needs to be
signed. The signer utility is written in C++, supporting this required
adding a new make command to Makefile.rules and a build file for the
utility.
The signing now needs to be a part of generating the .flat file. To
achieve this an alternative set of rules is defined in Makfile.rules
for targets where RO image needs to be signed.
Rules for converting elf to hex have been consolidated as there is no
need to omit the --set-section-flags when it does not apply.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=as follows:
- ran 'rm build/cr50; make BOARD=cr50'
- observed that both build/cr50/ec.bin and
build/cr50/RO/ec.RO.flat have the required signature header in
the first 1024 bytes.
- verified that the cr50 board can be booted over SPI using the
image in build/cr50/RO/ec.RO.flat
Change-Id: Iacc22561de67fadfaf8e049bf9578cbd08cfad86
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295291
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This changes the register description to match the newer FPGA version.
The new version supports firmware integrity verification as well as
bootstrapping over SPI slave interface.
BRANCH=none
BUG=chrome-os-partner:43791
TEST=with the rest of the patches (providing ability to sign firmware
and load it over SPI) the code gets signed properly and loaded
and started on the target
Change-Id: Ibebe5f6c510fbfb2c7c6ff40ab58ea643f051b1b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295211
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Leave 1024 bytes at the cr50 RO section for the signature required by
maskrom bootloader.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with this and other changes the latest cr50 image gets signed and
booted properly.
Change-Id: I64efe242b958bbb4e320cb3bb16c653d210dd662
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/295201
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The SPS RX FIFO handler prototype changed from passing cs_enabled
to cs_disabled, but the callback function for the spshc command didn't.
Now it does.
The spshc command switches the protocol on the SPI Slave bus to
expect EC Host Commands.
BUG=none
BRANCH=none
TEST=manual
At the EC console:
spstpm off
spshc
On the build machine, with an FTDI cable connected to the SPS
input:
cd extra/ftdi_hostcmd
make
./test_cmds
Change-Id: I69294a977b83854c5f6348904330bf74416cc6ec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293619
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch syncs up TPM2 sources into the build area when building
cr50 image. This relies on a specific directory layout so that the ec
makefile has access to the tpm2 source tree.
The sources are copied using rsync, the tpm2 library is a dependency
for the RO/RW elf images, and is declared to be a phony make target,
which guarantees that the tpm2 make is always run when cr50 image is
built.
Include files in board/cr50/tpm2 are necessary to be able to build
tpm2 code using the bare metal toolchain used for building ec code.
memory.h is in fact empty, it is easier to add it here than to wrap it
in conditional compilation at the source.
Make variables CROSS_COMPILE and CFLAGS are exported for the benefit
of the tpm2 makefile. ROOTDIR indicates where tpm2 library should look
for .h files not available from the toolchain.
CQ-DEPEND=CL:292946
BRANCH=none
BUG=chrome-os-partner:43025
TEST=make buildall -j succeeds;
when linked with the latest tpm2 source, the combined image
starts the tmp task and reacts to the host sending the startup
command (failing due to unplugged stubs).
Change-Id: Ia3fd260588558c2bacd724df9583052fa4660ca3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/292975
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
TPM command processing should not be happening on the interrupt
context.
This patch adds a skeleton of the task which handles TPM functions. It
initializes the TPM and then enters endless loop waiting for an event
trigger from interrupt, which happens when a valid FIFO message is
received.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=none yet
Change-Id: I63dce2762cc07370a05bf00bdf144c5d9eb6019b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289332
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The default receive FIFO threshold of 8 (meaning that 9 bytes need to
be received before receive IRQ fires) is good for high volume
transfers, when the amount of transferred data greatly exceeds the
threshold.
But in case of TPM transactions, which start with a 4 byte header and
then stall while the device processes it, the default threshold
guarantees delays on every transaction, as the receiver does not start
processing the header until 5 idle bytes are transferred to bring the
total number to nine.
The suggested solution is to allow to specify the receive FIFO
interrupt request threshold at run time, by adding this value to the
receive function registration API.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=verified that spstest still works fine.
Change-Id: I92517205a7d0d47893b702efa188eb524fb18a49
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289331
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The new FPGA version adds a lot of few features, while temporarily
cutting off some existing capabilities like clocking configuration
(hardwared clocks used instead), pinmux assignment for SPS interface
(hardwared connections used), etc.
This patch removes some now unused code, modifies some configuration
items and adds TODO_FGPA comment blocks highlighting code which needs
to be reviews next time FPGA version changes).
The new register definitions file is derived from hardware
description.
BRANCH=none
BUG=chrome-os-partner:43791
TEST=with these changes in place the B1 board boots to the console
prompt.
Change-Id: I78ec6b2831a44cbfd40ee726a5d3c2cc11bf2cfa
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/291855
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This code kicks in when the target is compiled with
CONFIG_POLLING_UART defined.
This ensures that each message sent to the console is drained
completely before the code proceeds, which helps debugging early
bringup issues.
BRANCH=none
BUG=chrome-os-partner:43791
TEST=with this code enabled was able to debug cr50 bringup on the new
core version.
Change-Id: Iab42370d64d17ecc5210bd4db1f2c5f19b40bce8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/291853
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Remove assumption of only one SPI master going to the SPI flash.
SPI3 can be used as second SPI master.
Define a new module type, SPI_FLASH, that can be turned
on/off when flash is not in used without impacting other
SPI masters.
BRANCH=smaug
BUG=chrome-os-partner:42304
TEST=Test on Ryu board.
Change-Id: Ie72471cea6f0a357ffee055a610d032580a794e7
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/288514
This patch adds a module which runs on top of the SPS driver and
implements the TCG SPI TPM protocol.
Basic register read and write functions are implemented as well as
rudimentary TPM state machine (claiming/releasing locality).
An enhancement is made to the SPS driver to ensure that when the CS is
deasserted the transmit FIFO is reset too, on the off chance of the CS
going away mid transaction for whatever reason.
In this implementation the slave is guaranteed to stall the master for
a few bytes in both receive and transmit transactions, which is
further aggravated by the fact that RX FIFO threshold is set to 8
(this is the minimum number of bytes the master has to send to wake up
the slave). This could be fine tuned later, for instance made a
parameter of the receive callback registration function.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=trunksd initialization (with minor changes to accommodate new
VID/DID and some status bits, to be published) succeeds with the
cr50 connected to the USB/SPI cable.
Change-Id: I28d37c3b57dde9adf59e81426efe4f58880cf0b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285252
SPI slave and master interfaces require very different code to
support, they should have separate configuration options.
Host command code printouts should use their own console channel.
Using SPS to designate SPI Slave interface is not universally
acceptable, a bug has been opened to discuss the alternatives and
clean up the code.
BRANCH=none
BUG=chromium:512613
TEST=make buildall -j
Change-Id: I6683286a221c4689ecc247fdfe8ebca529f3f458
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286469
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The same calculation is used across the code, so move it to a common
macro.
BUG=chrome-os-partner:42104
TEST=Verify Glados still boots AP.
BRANCH=None
Change-Id: I90da348f37fc670971737cfc5ddcfb9c34096c4b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286169
Reviewed-by: Alec Berg <alecaberg@chromium.org>
There have been a few changes made to the sps driver recently, which
were not necessary but caused performance degradation: the continuous
loopback test is showing transmit underrun (0xff bytes stuck into the
frames).
This patch restores the driver to its state before the recent changes
and then makes a few modification to account for the new API:
- added a way to specify idle byte transmitted on MISO
- port number is dropped
The actual differences between the old and new version of the driver
can be seen as follows:
git diff dbf027f chip/g/sps.c
The restored driver passes the loopback test successfully.
BRANCH=none
BUG=none
TEST=used the enhanced 'spiraw' utility which sends frames of random
size in 10..1010 bytes, and then clocks the line to receive the
same amount of bytes back, syncs up in the returning stream of
bytes and compares received and transmitted data.
# run 'spst 100' on the target
$ src/examples/spiraw.py -l 100 -f 2000000
FT232H Future Technology Devices International, Ltd initialized at 2000000 hertz
$
which is an indication of the successful loop back of 100 frames.
The cli command on the target exits and reports the stats:
> spst 100
Processed 100 frames
rx count 108532, tx count 51366, tx_empty count 100, max rx batch 11
Before this change spiraw.py was reporting numerous mismatches on
the host side.
Change-Id: Iaa8c94e439ac32a6f10f12ddbdbf445865807386
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286015
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I accidentally removed this when poking around with the SPS
driver. This adds it back as a separate file. Enabling
CONFIG_SPS_TEST will restore the "spstest" console command to use
for low-level driver tests.
Note that invoking it will replace any other registered SPS
handler.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=manual
Connect the EC to the build host with an FTDI USB-to-SPI adapter.
On the EC console, invoke
spstest
Build and run the external ftdi_dongle test:
git clone sso://user/vbendeb/ftdi_dongle
cd ftdi_dongle/src
make
./examples/spiraw.py -l 10 -f 2000000
Change-Id: Ia6165e3be06d976c59c3e849349da0f7f5006f56
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284943
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This lets the RX interrupt handler configure the wire protocol
(clock polarity and phase) and SPS communication mode that it
would prefer.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
This is just a refactoring, since the sps_hc.c module is the only
thing that uses this (in one mode only). I tested it using
extra/ftdi_hostcmd and it still works.
Change-Id: I9ed26e9fa66de65e72f188184f4f3f41a5b5562a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284922
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The "sps" console command declared in sps_hc.c is misleading. It
shouldn't be "sps", when it's actually part of the host command
protocol stuff.
This CL changes the command name to "spshc" instead. The command
just enables or disables SPS host commands. Note that because
there's no notification if something else calls
sps_unregister_rx_handler(), there's no way for the sps_hc.c
module to know whether it's still registered.
BUG=none
BRANCH=none
TEST=make buildall
Using a test program, such as extra/ftdi_hostcmd/, I can send
host commands to an EC attached via an FTDI USB-to-SPI adapter.
On the EC console, this:
spshc off
causes the test program to fail, and this:
spshc
causes it to work again.
Change-Id: Ie0edbde179b570f170ff9464313e5e33ab985f21
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284942
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the SPI slave chip select is deasserted, it means that the
SPI master doesn't want to hear any more from the EC. We need to
clear any bytes left in the TX FIFO, so that the next SPI
transaction doesn't send those leftover bytes out.
Since the EC's SPI protocol for host commands uses software flow
control, those leftover bytes could screw up the messages. I
expanded a comment explaining how that works.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
And, with the EC connected to the build host via an FTDI USB-to-SPI
adapater, I used the extra/sps_errs/ test program to see the
original problem and that this CL fixed it:
cd extra/sps_errs
make
./prog -v
./prog -v -c 22
./prog -v
This sends a complete EC_CMD_HELLO message, then a truncated
message, then sends the whole message. Before this change to
sps.c, the third message response begins with the leftover bytes
from the aborted second message.
Bad third message:
Transfer(12) =>
03 64 01 00 00 00 04 00 a5 a5 a5 a5
Transfer(12) <=
a9 a8 a7 a6 f8 f8 f8 f8 f8 f8 f9 f9
^^ ^^ ^^ ^^
Good third message:
Transfer(12) =>
03 64 01 00 00 00 04 00 a5 a5 a5 a5
Transfer(12) <=
f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f9 f9
^^ ^^ ^^ ^^
Change-Id: Id6e431f91be0204921edee2f774b6c487966ddff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284746
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This adds a module that attaches to the SPS driver to process
host commands delivered over the SPI slave interface.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
This feature is not yet enabled, so there's nothing new to test.
That will come next.
Change-Id: If57a6fce698a7eb050e2a68b7f4d18d8b0e2956f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/284010
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The SPS (SPI Slave) driver handles incoming traffic from the SPI
master. This abstracts the basic hardware functions into a clean
API so that the response to the SPI bytes can be put into
separate files.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
If CONFIG_SPI is not defined, incoming SPI traffic is completely ignored.
Even when it's enabled, nothing is reacting to the traffic so
incoming SPI bytes return 0xFF bytes to the master (SPI traffic
is always bidirectional).
Change-Id: I9bbcebc9c5223b942362200fe43a11ac57dfff40
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/283581
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Add a description for the USB HID interface, neaten a bit of
console output. No new functionality.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Ie85a0192bc4ab9fa87afb4be41d496545a3b548a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/283051
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This unifies all the EC header files to use __CROS_EC_FILENAME_H
as the include guard. Well, except for test/ util/ and extra/
which use __TEST_ __UTIL_ and __EXTRA_ prefixes respectively.
BUG=chromium:496895
BRANCH=none
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Iea71b3a08bdec94a11239de810a2b2e152b15029
Reviewed-on: https://chromium-review.googlesource.com/278121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a new task and endpoints to handle large opaque (to the
USB) chunks of data. The expected use case is that the USB
endpoint accepts bytes from the host and passes them blindly to
the blob-handling task. At some point, the blob-handling task may
wish to send bytes back to the host. What those bytes are and
what they mean is determined at higher levels of abstraction.
BUG=chrome-os-partner:40969
BRANCH=none
TEST=make buildall
This CL doesn't enable the blob-handler; it just makes it
available. The next CL will enable and test it.
Change-Id: I6eba8e8010466e71efe9c5e06848b9f403df835f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/275131
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The USB spec mandates that all structs are little-endian over the
wire. Since we're a little-endian architecture (and the code
we're changing is intentionally chip-specific), we can just cast
the hardware buffer into the correct struct. This makes the code
easier to read and understand.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Ib2d3b04f4db1a531cb3f5ada1a2e6ee82e8a23aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274130
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our USB buffers are just arrays of uint8_t in program RAM, so
let's treat them that way. The DMA descriptors are in normal RAM,
too.
BUG=chrome-os-partner:40693
BRANCH=none
TEST=make buildall
Change-Id: Ibafe1a557a328bbf8cf37ce113675fcd35bad376
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273918
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This moves the STM32-specific code out of the common header file
and into the chip directory where it belongs. Note that this
doesn't actually change the code for non-STM32 SoCs; that will
happen in a separate CL for clarity.
BUG=chrome-os-partner:40693
BRANCH=none
TEST=make buildall
Change-Id: Ifdf0086e86a1088fb011b9ac4d6c70ab8da47aec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273577
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our existing GPIO macros use port# / gpio#, but the concept of different
GPIO ports does not exist on the mec1322. Therefore, add new GPIO macros
for chips which do not have distinct GPIO ports.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: Ibda97c6563ad447d16dab39ecadab43ccb25174b
Signed-off-by: Steven Jian <steven.jian@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/262841
Reviewed-by: Anton Staaf <robotboy@chromium.org>
- Use CONFIG_*_MEM when dealing with images in program memory.
- Use CONFIG_*_STORAGE when dealing with images on storage.
- Use CONFIG_WP when dealing with the entire WP RO region.
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Manual on Cyan with subsequent commit. Verify that FMAP matches
actual layout of image. Verify flashrom succeeds flashing + verifying EC
image using host command interface.
BRANCH=None
Change-Id: Iadc02daa89fe3bf07b083ed0f7be2e60702a1867
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270269
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
The CR50 device will have to have two different drivers, for SPI slave
and master modes. This patch adds the slave driver which is called
SPS.
CR50 SPS controller uses 2KB buffer split evenly between receive and
transmit directions as two FIFOs. RX write and TX read pointers are
maintained by hardware, RX read and TX write pointers are maintained
by software.
The FIFO area allows only 32 bit writes from the CPU core, which
complicates the function placing TX data into the FIFO. There is no
limit to read access size.
Another complication is that the hardware pointers in the FIFO in fact
have 11 bits (instead of 10 required to address 1K), so the software
needs to use 10 bits when accessing the FIFO, but 11 bits when writing
the pointers into the registers.
Driver API provides three functions:
- transmit a packet of a certain size, runs on the task context and can
exit before the entire packet is transmitted.,
- register a receive callback. The callback is running in interrupt
context. Registering the callback (re)initializes the interface.
- unregister receive callback.
A CLI command is added to help testing this driver. When invoked, it
installs the callback function to handle receive data. The data is
expected to be of the following format:
<size/256> <size%256> [<size> bytes of payload]
where size should not exceed 1098 bytes.
Received frames are saved in a buffer and once received are
transmitted back to the host.
BRANCH=none
BUG=none
TEST=used the enhanced 'spiraw' utility which sends frames of random
size in 10..1010 bytes, and then clocks the line to receive the
same amount of bytes back, syncs up in the returning stream of
bytes and compares received and transmitted data.
# run 'sps 100' on the target
$ src/examples/spiraw.py -l 100 -f 2000000
FT232H Future Technology Devices International, Ltd initialized at 2000000 hertz
$
which is an indication of the successful loop back of 100 frames.
The cli command on the target exits and reports the stats:
> sps 100
Processed 100 frames
rx count 108532, tx count 51366, tx_empty count 100, max rx batch 11
Change-Id: I62956753eb09086b5fca7504f2241605c0afe613
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269794
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Attempts to use ccprinf() before both uart and usb consoles have been
initialized cause the device lock up. Luckily both console channels
are buffered (and usb console buffering is about to be greatly
improved), all what needs to be done is to hold on to the attempts to
start transmit interrupts until hardware has been initialized.
BRANCH=none
BUG=none
TEST=attempts to print something on the console early in the process
do not cause the device to lock up any more, and the printouts
show up where expected.
Change-Id: I16cd1fab79bceaf7c2334a955fdb6046d21ed550
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268379
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
This fixes a slight mistake where we were enabling the wrong
interrupt (EP1 instead of EP2).
I'm not sure that this is necessary, since we don't actually do
anything about these interrupts except clear them.
BUG=none
BRANCH=none
TEST=manual
To test, I instrumented the hid_tx() interrupt handler. Before
this CL, it never fired. Now it does.
Change-Id: Iaa5816ec78f70ef101d4663c08842678ddc7d2f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267089
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a USB device driver for the Synopsys DWC USB device controller.
The common USB protocol stack code still need to be de-duplicated with
the STM32 implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33919
TEST=plug Cr50 to a Linux workstation and see USB descriptors using
"lsusb -v -d 18d1:5014"
Change-Id: I4a367241053de2c2d94aa06f82ea4bee51f9f89a
Reviewed-on: https://chromium-review.googlesource.com/231160
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
All current boards in ToT place pstate at the end of the RO section.
Remove the unused option to place it at the end of the RW section;
we'll never do that again.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I0d279a4c9786bb33367a7387423481cc9b94e115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253636
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This signs the RW firmware (with a non-secret key). The RO
firmware will verify the RW firmware and jump to it if it's good.
Note that this isn't the final solution, just the beginning.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Build and install it. You'll see something like this:
--- UART initialized after reboot ---
[Reset cause: reset-pin hard]
[Image: RO, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.000444 Verifying RW image...]
[0.423742 RW image verified]
[0.423946 Jumping to image RW[0.428492 UART initialized after sysjump]
[Image: RW, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.428931 Inits done]
Console is enabled; type HELP for help.
>
> sysinfo
Reset flags: 0x00000c02 (reset-pin sysjump hard)
Copy: RW
Jumped: yes
Flags: unlocked
>
Change-Id: Icafa554baca135ff1f80cbce4dad5f980e7fc122
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This separates the configuration of the ARM core GPIOs from the
routing of internal peripherals to external pins. Both are still
described in the gpio.inc file, but are less dependent on each
other.
BUG=chrome-os-partner:33818
BRANCH=none
TEST=manual
Before this CL, running "sysjump rw" or trying to use more than 8
GPIOs caused hangs and reboots. Now it doesn't.
Change-Id: If962a7c5ad4136837b2ea00ae016a440f07d7e23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251015
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
