Add initial support for Oak rev1 board. This is just the
EC and includes battery charging but does not include
USB PD.
BUG=none
BRANCH=none
TEST=load on oak board and get console
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Change-Id: I626f3921025fbc39ba22b04eeb6dd1084cd70777
Reviewed-on: https://chromium-review.googlesource.com/261678
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>
Move parts of usb_pd_config.h that are not part of the phy layer
out of usb_pd_config.h and into board.h. This cleans up the
division between the TCPC and TCPM as only the TCPC needs to
use usb_pd_config.h.
Also cleans up the use of the CC detection voltage thresholds
by creating standard macros to use based on Rp strength for the
board.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I946cceb38bea8233095b8a4b287102bb8a3a296d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270337
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Since stm32 and mec1322 now support open-ended i2c_xfer, we can move the
lm4 i2c_read_string implementation to common code and delete all
chip-specific versions.
BUG=chrome-os-partner:39613
TEST=Run "battery" from EC console on Cyan and Oak, verify that battery
info + strings are correctly printed.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I06369df64bb2eb747d163664b4c96eeacb4b1faa
Reviewed-on: https://chromium-review.googlesource.com/272938
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Modify i2c_xfer to support transfers where start and stop conditions are
not issued together.
BUG=chrome-os-partner:39613
TEST=Manual with subsequent commit. Verify that 'battery' shows proper
values + strings.
BRANCH=None
Change-Id: If98c9493902326203880645828061c45c9cfd8be
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272995
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously the Producer and Consumer interfaces tracked the
Consumer and Producer respectively at the other end of the
queue that they interacted with. This was done to avoid
modifying the queue implementation, but resulted in a rougher
interface that required additional initialization steps and
prevented alternative configurations; many producers and one
consumer for example.
This commit uses the new queue policies to track this
information. The new direct policy behaves as the old producer
and consumers did. Now the producers and consumers are just
named references to the queue that they work on and a convenient
location for a notification callback when the queue is updated in
a way that is relevent to the producer or consumer.
All users of Producer and Consumer have been updated including the
stream adaptors which are in use by the echo test code and the
mcdp28x0 driver. Use of the stream adaptors has also been
simplified.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Manual testing of Ryu (P5) and discovery board echo task
Change-Id: I704be6378a31b4e20f5063295eff9943e4900409
Reviewed-on: https://chromium-review.googlesource.com/271792
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Fix master i2c when sending partial transfers using I2C_XFER_START
and I2C_XFER_STOP.
BUG=none
BRANCH=none
TEST=Tested i2c transfers on oak. tested transfers with
I2C_XFER_SINGLE (I2C_XFER_START | I2C_XFER_STOP) and tested
partial transfers with just one flag. For partial transfers
I tested two different types:
- i2c_xfer START only transmitting, then another i2c_xfer with
more trasnmitting followed by a STOP. verified with logic
analyzer that there is not restart in the middle.
- i2c_xfer START with transmitting and receiving, then another
i2c_xfer with more receiving followed by a STOP. verified with
logic analyzer that there is one restart in between
transmitting and receving and no restart in between the two
calls to i2c_xfer.
Change-Id: Ie4146d1cf7d39f7dc56fd02e65add6bf02772e67
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272690
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add config options for various parts of USB PD stack:
CONFIG_USB_POWER_DELIVERY: The use of this option has changed
slightly. It now represents whether or not to include the USB
PD protocol and policy layers of the software stack.
CONFIG_USB_PD_TCPC: Compile in type-C port controller module
which performs the phy layer of the PD stack.
CONFIG_USB_PD_TCPM_STUB and CONFIG_USB_PD_TCPM_TCPCI: If
CONFIG_USB_POWER_DELIVERY is defined, then one TCPM needs to
be defined to declare which port management module to use
to drive the TCPC.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I41aa65a478e36925745cd37a6707f242c0dfbf91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270171
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
stm32f051 I2C slave does not clear transmit interrupt status (TXIS) on
receiving NACK. That fails to support I2C master repeated-start read.
This change moves slave transmit from host command thread's TXIS loop to
interrupt event loop. And enables NACK interrupt to handle master
restart. On the I2C master side, this CL adds i2c_xfer flags.
With this CL, stm32f0 EC can talk to stm32f051 PD through host commands.
BRANCH=None
BUG=None
TEST=make BOARD=<board with stm32f0 EC and PD>
Verify EC console command "pdcmd 1 0 0x10 0x20 0x30 0x40"
Change-Id: I771b4fb3de3732f18da90ea5e27a79afb09689b0
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267041
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Add CONFIG_LTO to use GCC Link-Time Optimizations to try to reduce the
flash footprint of the firmware.
Add additional protection to some functions/data to avoid removal by the
linker when their usage is not obvious.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall (with and without LTO enable on all boards)
Change-Id: I586b8c1eda4592b416c85383b65153c1d5ab0059
Reviewed-on: https://chromium-review.googlesource.com/271291
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Correct image offsets to reflect our actual layout.
BUG=chrome-os-partner:39741
TEST=Manual on Cyan. Verify EC image boots and FMAP RO_FRID and RW_FWID
point to our actual IDs.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: If0c4e44f45cac1cdc0a99cf0ae4c17e0ead95486
Reviewed-on: https://chromium-review.googlesource.com/270353
Reviewed-by: Bernie Thompson <bhthompson@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>
Flash read,erase and write should access SPI flash
and not read SRAM MAPPED location.
flashrom -p and Software sync use the same flash functions to
perform flashread,flashearse and flashwrite.So these functions
should be reading RW image starting address offset.Address offset
sent by host should not depend on the actual SPI flash as the EC
code handles the right offset to program the ec.bin(via flashrom -p)
and RW image only via software sync.
BUG=chrome-os-partner:38103
BRANCH=None
TEST=flashrom -p options tested to read and update ec.bin
Change-Id: I3fb16accf3e05eaa3469a8a589962164574d5fb2
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/269231
Reviewed-by: Shawn N <shawnn@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>
Cleanup PD receive error enum by including RX in name since
we will have a different enum for TX errors.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I355092e0e73a022acb4a92736374cd2289d324bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Sometimes the chipset task is slow enough that we might get messages from
the AP before chipset_in_state(CHIPSET_STATE_ON) is true. This causes us
to leave the spi off after our usual reset after every transaction
(see chrome-os-partner:31390). This would put an end to any EC communications.
Instead of relying on CHIPSET_STATE_ON we could just save the value of
"enabled" before we turn it off, then use that as a condition instead.
There shouldn't be a race condition on "enabled" because the only other place
it gets modified is in the hooks, which can't preempt spi_init
(which usually happens in the host command task).
The only problem is that in case of a sysjump enabled will be 0,
so CHIPSET_STATE_ON was left as a backup to handle that case.
This fixup was squashed from Ied3788f83fef548dff3b01bec93d0e40101ba0f7
TEST=Resume minnie from "echo mem>/sys/power/state" a few times, note ec still works
BUG=chrome-os-partner:39564, chrome-os-partner:39576
BRANCH=veyron
Change-Id: I7c33243faebfd74dc33451024c1d75080babee03
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267593
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With mec1322's EMI set to decode IO 0x800, it does not have any other
interfaces to support POST code via IO 0x80.
This change is to enable Port80 POST code support via polling method.
Limitation:
- POST Code 0xFF will be ignored.
- POST Code frequency is greater than 1 msec.
BUG=chrome-os-partner:39386
TEST=Verified Port80 POST code is captured in EC console.
Verified "port80 task" console command will disable/enable Port80 task.
Verified "port80 poll" will get the last Port80 POST code.
BRANCH=none
Change-Id: I27e53e84b5be1fd98464a44407dd58b93d8c798d
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/266783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
i2c levels were not reporting correct value as programming the
controller to switch to Bit Bang mode was not enabled.
BUG=chrome-os-partner:39400
BRANCH=None
TEST=Wedge condition was simulated and unwedge was validated using
Oscilloscope
1. SDA was grounded, ran i2cxfer console command,
SCL line creates pulses when SDA gets wedged.
2.SCL was grounded to create cloack stretching, ran i2cxfer console
command and unwedge was confirmed.
Change-Id: Id96d8460820b7d19961ed94d1262112ebd146636
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267137
Reviewed-by: Shawn N <shawnn@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>
Identify and ignore cable reset PD command
BUG=chrome-os-partner:39464
BRANCH=samus
TEST=connect two samus'. on one samus add code to send a cable
reset like such:
int send_cable_reset(int port)
{
int off;
CPRINTF("C%d Send cable reset\n", port);
/* 64-bit preamble */
off = pd_write_preamble(port);
/* Hard-Reset: 3x RST-1 + 1x RST-2 */
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC1));
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC3));
/* Ensure that we have a final edge */
off = pd_write_last_edge(port, off);
/* Transmit the packet */
if (pd_start_tx(port, pd[port].polarity, off) < 0) {
pd[port].send_error = -5;
return -5;
}
pd_tx_done(port, pd[port].polarity);
/* Keep RX monitoring on */
pd_rx_enable_monitoring(port);
return 0;
}
Without this CL, the receiving samus times out and ends
up causing equivalent of hard reset. With this CL, we receive
cable reset and drop it.
Also used twinkie to measure goodCRC delay. No measureable
change in delay on samus and zinger. Samus delay is ~70us and
zinger delay is ~65us.
Change-Id: Ic0e871c8cf96502b861f430e05ee145881fb55fa
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
mec1322 only has 96KB program memory, vs 256KB
flash space on lm4.We no longer have enough program
memory to load both RO and RW at boot. We'll want to
implement a small loader program that will load either
RO or RW from flash, and then jump to the loaded image.
CONFIG_FW_INCLUDE_RO is enabled to include RO image into
the build.
pack.py script is altered to load the (lfw + R)O on boot.
Software sync is not added.Distinguish between
RO/RW is yet to be added.
flash_ec is altered to support padding 0xFFs to 256k ec.bin
to match the size of the SPI flash of the board.
BUG=chromium:37510
BRANCH=None
TEST=Make -j buildall,Verified ec.bin to be 256k.
Verified RW image at offset 0h and (lfw + RO) at offset 2000h.
On boot sysjump to lfw. lfw checks in shared SRAM (currently RO)
and jumps to RO image.
Change-Id: Ib9b114e2f24a615d5e5bd8b3803be621d1e5bd17
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265807
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
lfw is a customized boot loader with max targeted code size of 4k
and data size of 2k.It supports minimal functionalities required to
support chromebooks RO/RW architecture.It is placed in the
write porected section with RO image .
Capabilities include SPI,DMA,UART with minimal debugging support.
Currently sysjump support is missing and exception handling is very basic.
BUG=chromium:37510
TEST=make buildall -j, flashing and booting on strago
BRANCH=None
Change-Id: I803998d489297dfe0745dcccbb54412035d73f78
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mec1322 bootloader looks for a CRC TAG at the xFF00 boundary of the
flash before it loads the ec onto SRAM for execution. Code for EC will
be packed to occupy the last 256k of Flash. That way the binay generation
is independent of the flash size. The last 20000h is RO + lfw followed by
20000h space for RW.
BUG=chromium:37510
TEST=make -j buildall
BRANCH=None
Change-Id: Ie75bd8a40826d630b3022b5b3ecb2d6ad3aa2471
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265885
Reviewed-by: Shawn N <shawnn@chromium.org>
mec1322 I2C controller 0 has two attached ports. Modify the I2C driver so
that both ports are usable.
BUG=chrome-os-partner:38335,chrome-os-partner:38945
TEST=Manual on strago. Verify that i2cscan is functional.
BRANCH=None
Change-Id: I18d9d516984d041a38c86fd4ec1b0bfa4e885c9f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265951
Reviewed-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Previously for the mec1322 chip an ec.bin file was created in the normal way
and then it was "packed" in a post-processing stage to produce ec.spi.bin.
This change allows a chip or board build.mk file to specify the rules used to
produce ec.bin, and uses this for the mec1322 to do the packing. This means
that we can use the standard "ec.bin" name, and do not need to alter other
scripts, such as the script which creates chromeos-firmwareupdate.
BUG=None
TEST=buildall -j, flash on strago and see it still works.
BRANCH=NONE
Change-Id: I3f880d64e60d14f82cb1d21c8b3f2d4ae5e0dfef
Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265544
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
Interrupt Source register is R/WC, so |= should not be used.
BUG=none
TEST=Verified LPC_RESET# is detected by interrupt handler via EC console.
BRANCH=none
Change-Id: Ib553c839e1311538b17a4d9fbc10c9df5b7e6b44
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265502
Reviewed-by: Shawn N <shawnn@chromium.org>
This allows switch status to be updated to EC MemMap.
BUG=none
TEST=Verified mmapinfo console command is reporting the correct info.
BRANCH=none
Change-Id: I3b6683be8b92b59dffb3227e0a72a122dcda56a2
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265493
Reviewed-by: Shawn N <shawnn@chromium.org>
The memcpy like routines for moving to and from usb packet
RAM couldn't deal with all unaligned uses, this fixes their
behavior. In particular, a previous caller might assume
that the packet RAM addresses were contiguous and attempt
to break up a call into two separate chunks (as the queue
insertion/removal code does). But this can lead to invalid
pointers passed to these memcpy routines. A much cleaner
solution is to make the packet RAM address space contiguous.
To do so the memcpy routines take packet RAM addresses
instead of AHB address space mapped addresses and
__usb_ram_start needed to change to be of type usb_uint so
that pointer arithmatic on it worked correctly on all platforms,
this also allowed the usb_sram_addr macro to be simplified.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USB still works on Ryu and discovery-stm32f072
Change-Id: I479461f07a3203f1e6e0cf9705f512a5a43c4646
Reviewed-on: https://chromium-review.googlesource.com/264764
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously the TX and RX queues were being accessed from two
different locations without locking, which is wrong. This
moves the access to a single location in a deffered hook and
calls that hook from the old locations. The result is
correct, simpler, and not much slower. It also reduces time
in the USB interrupt handler by moving the memcpy from packet
to queue out to the deferred hook.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USB streams still work on Ryu and discovery-stm32f072
Change-Id: I6ea53d7c40b42c6112e86a7886f3b888408f72b7
Reviewed-on: https://chromium-review.googlesource.com/264763
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
The ADC watchdog is about 2/3 of the ADC code size and it is not
optimized out when not used because adc_read_channel() needs to
stop/restart the watchdog if somebody is using it.
The feature is enabled by default to keep the current behavior on
STM32F0 platform, and it is turned off on samus_pd :
This is saving 448 bytes of flash (and 8 bytes of RAM).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall and check the firmware size before and after.
when CONFIG_ADC_WATCHDOG is disabled, adc_enable_watchdog() is not
compiled if there is any user the build will fail.
Change-Id: Ie2450bc2a8fd97662322fd3ce87e93c3fece6c6f
Reviewed-on: https://chromium-review.googlesource.com/265303
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When using the Twinkie dongle without a protocol decoder on the host,
add a simple text tracing mechanism, so the user can get the timestamped traces
of the packets on the wire (in a best effort fashion).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=On Twinkie command-line, type "tw trace on"
then plug a DingDong to Samus through Twinkie and
see the PD message traces on the console.
Change-Id: I4fa35d6783cc6279c95209c86f37e6d717de7301
Reviewed-on: https://chromium-review.googlesource.com/237222
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
We need to clear DMA status before starting another transaction.
Otherwise, we get incorrect values.
Same fix as the one Vic did in CL 240282 for STM32F1xx and STM32F3xx.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38902
TEST=On the twinkie USB console (without anything connected), do "tw res
rd rd" then "adc". We now always get "CC1_PD = 0 CC2_PD = 0" rather than
some fancy values for CC2_PD such as "CC2_PD = 29097".
Change-Id: I065b2f8f74ba39f805445bab96b45819322a7da3
Reviewed-on: https://chromium-review.googlesource.com/264981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: 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>
This turns on hardware controlled update of bit 5 (AUXOBF) in Keyboard
Status Read Register. Previously, this bit was in user-defined mode and
not reliable.
BUG=None
TEST=Tested that keyboard becomes functional on Braswell Ref Design.
BRANCH=None
Change-Id: I192383ebebb25a027d58da9fc1ef7f3bb3e8da66
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/263948
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
MEC1322 KSO00~03 pin has an alternate JTAG function. For board that needs JTAG
function, this #define allows hardware to use a different set of KSO pins.
For example - Uses KSO04~16 instead of KSO00~KSO12.
BUG=none
TEST=Verified keyboard is functional with all keys detected
BRANCH=none
Change-Id: I1e3c1c2b6a4420cb6296b6bc921affa8c0ed5800
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264610
Reviewed-by: Shawn N <shawnn@chromium.org>
- Changed TX BIST mode so that it transmits for 50 msec instead
of transmitting forever.
- Added console command to initiate TX BIST mode.
- Fixed an issue with circular DMA mode which was causing watchdog.
- Modified RX BIST to account for shorter TX BIST duration.
BUG=chrome-os-partner:36335
TEST=Manual on Samus to Samus, manual on Zinger to Samus
BRANCH=Samus
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Change-Id: I666347de47c81b5b7a1e82c2b99345ff3ebbb7d4
Reviewed-on: https://chromium-review.googlesource.com/256194
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Trybot-Ready: Alec Berg <alecaberg@chromium.org>
Commit-Queue: 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>
I2C Block reads were split into two i2c_xfer() calls. However, i2c_xfer() implementation for MEC
does not maintain state in between calls. This was causing block read failures because the
settings for the Control Register got corrupted. Fix this by calling i2c_xfer() only once. This
retrieves both string size and string. Only return the string back to the user.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: Ife8fcb66425c6198d0dcf10f74e89c001ccac49a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260627
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
