Add low power mode for zinger. This uses stop mode in task_wait_event(),
the non-runtime equivalent of the idle task.
BUG=chrome-os-partner:28335
BRANCH=samus
TEST=load onto zinger and plug and unplug into samus a bunch of times
to make sure it negotiates to 20V every time. also send custom vdm's
from samus_pd and make sure those always succeed.
Change-Id: I626365e7d22e030792d28dbf7eafaeb8f54f8a74
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219933
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
i2cdetect -q was broken on the AP. The way it works is by sending a 0 length
write request and checking for NACK. The stm32f0 driver had to be fixed to
actually return non-success if there was a NACK. i2cdetect -r worked so far
because it relied on a 1-length read and we indirectly detected NACKs by the
lack of data.
The error catching also had to be moved(in both drivers) before the success
returns, because it is possible to transmit something successfully(buffer got
emptied) without getting an ACK. We want this to be an error.
BUG=None
BRANCH=None
TEST=veyron: i2cdetect -y -r 20 0x09 0x0b should display -- on the 0x0a spot
since there's no device there. i2cdetect -y -{r,q} 20 should display the same
thing.
Change-Id: Id6cadb798e4d972dea089f15742e5b30888a038b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220185
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove 4kB reserved flash for pstate since we don't use persistent
state flash on zinger and flash space is limited.
BUG=none
BRANCH=none
TEST=make -j buildall. load and run zinger.
Change-Id: Id0020932ed47873d22e81516abf97b4279a7deae
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219932
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enable flash prefetch buffer for stm32f0 chips to make for
faster CPU execution.
BUG=none
BRANCH=none
TEST=load onto samus_pd and zinger. let run for a while.
connect/disconnect AC a few times. boot samus.
Change-Id: I88c0ae67a3205987344552f5b44952f9890c8177
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219921
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Fix potential bug in ADC initialization. After setting ADEN bit to
enable ADC module, we must wait for ADRDY (ADC ready) bit before
continuing. This bug only affects a few chips, and only some of
the time.
BUG=chrome-os-partner:31978
BRANCH=none
TEST=Used a samus board where the PD MCU fails ADC initialization
quite often. Without this fix, if you reboot the PD MCU, it will
sometimes come up with all ADC's reading 0 and ADEN reading 0.
With this fix, it always boots with the ADC's working
Change-Id: Iba1d0e56006ba1ad6d9f0eee964a70ef2d0f8dcf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219522
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
RX DMA seems to get misaligned sometimes yielding to extra bytes before the
first byte on the wire.
in_msg=[00 00 00 03 f4 09 00 00 ...]
^ real first byte
To fix this we want to reset and reinit the SPI peripheral after every packet,
in the same place where setup_for_transaction() is called.
This bug applies to the STM32F0 line but resetting the peripheral on other STM32
ECs should not break anything.
BUG=chrome-os-partner:31390
TEST=On STM32F0:
ap# cd /sys/class/power_supply/sbs-20-000b/; while true; do grep "" * >/dev/null 2>&1; done
You should not see "SPI rx bad data" with in_msg packets that have extra bytes
in the beggining. Wait though, it might take up to a few minutes for stuff to
break.
BRANCH=None
Change-Id: If9ab93c5c9040a2c7bda33d7cc990603f1121f3f
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217527
Reviewed-by: Randall Spangler <rspangler@chromium.org>
STM32F and STM32F0 series require an MOE bit to be set to enable PWM
output. In addition, require that the PWM alternate function # be
manually specified for STM32F0 -- there seems to be no logical mapping
here, unlike other STM32* parts.
BUG=chrome-os-partner:32089
TEST=Manual on samus-pd. Set ILIM PWM output to 50% duty cycle with pwm
driver functions, probe and verify avg. 1.62V on pin.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Icb13a153fa3eee52be938d76a6c980fe6fd2bb3e
Reviewed-on: https://chromium-review.googlesource.com/219570
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Tested-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The warning should only warn if there's an actual danger(in order to give a
clue to developers that something might be amiss). Messages like "Overriding
SPI1_NSS with SPI1_NSS on EXTI4" are just spammy. This patch makes it so it only
warns if the interrupt is different.
BUG=chrome-os-partner:31390
TEST=spam gpio_enable_interrupt(GPIO_SPI1_NSS); in a bunch of places (like
spi_event), it should not complain about the interrupt being set to the same
thing before. Whereas before it was so spammy it did not even have time to reply
to SPI.
BRANCH=None
Change-Id: I786a821eb8167e3568d0be371c4de26bb124431a
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218563
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just after a bad data error the EC will print the packet(pretty much the whole thing):
in_msg=[02 00 0f 03 f4 09 00 00 ]
I found it very helpful when debugging SPI TX/RX to know what the EC sees.
BUG=chrome-os-partner:31390
TEST=Load spidev and send the EC bytes manually(malformed packets)
BRANCH=None
Change-Id: I037ab909076dc454379040e2e927dc6a0b5c5ea9
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218442
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Enable low power idle for samus_pd. Low power idle is only
entered when no USB PD device is connected.
BUG=chrome-os-partner:31226
BRANCH=none
TEST=load onto samus_pd, use idlestats command to verify
that we are going into deep sleep (STOP mode). Run 30 min.
and verify no watchdog reboots or anything out of ordinary.
Also, verify that host commands from EC work when going into
deep sleep by sending host commands on the EC console with
pdcmd 0 0.
Change-Id: I3e2e04e6c4c0a84e291286dbed90945847e0dfdd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218957
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This driver can be used to access multiple usarts using an abstract
stream interface. The stream interface can also be used in drivers
for the host interface and USB console interface, providing a
consistent API across all character stream style IO.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Icf567f0b0fa4eb0e9ad4cdb0be8edc31c937a7de
Reviewed-on: https://chromium-review.googlesource.com/209671
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Add low power idle task to stm32f0. This can be enabled
by defining CONFIG_LOW_POWER_IDLE. This low power idle
uses STOP mode to conserve power.
BUG=chrome-os-partner:31226, chrome-os-partner:28335
BRANCH=none
TEST=add #define CONFIG_LOW_POWER_IDLE to samus and use
idlestats console command to verify using deep sleep.
also #define CONFIG_FORCE_CONSOLE_RESUME and make sure
serial console works without problems when going into
deep sleep.
Change-Id: I76b0ceb8587a139faa74353d3d8efb4f689fc669
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218956
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Bug fix. Recently changed to use HSI 8MHz clock as clock source
for console UART, but the clock register was set incorrectly
for the case that the console UART is UART2.
BUG=chrome-os-partner:32170
BRANCH=none
TEST=Tested on fruitpie which is using UART2 for console.
Verified that console works.
Change-Id: Ied629eb3828e5fab911acb6a8e5f4087563ddb32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219312
Reviewed-by: Vic Yang <victoryang@chromium.org>
When waking up from sleep, the real CPU_CLOCK is a lie for a moment(since we
cannot switch to the real clock during the first character) so the first
character will be corrupted.
The UART clock is now sourced from HSI(8MHz) which is available from the first
moment after the cpu wakes up from sleep.
BUG=None
TEST=Console should work.
When waking up(not implemented yet) it will also not lose a character
BRANCH=None
Change-Id: Ia12ed0634290f3edadfe3471b311759c3176260e
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218728
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Implement RTC alarm, with resolution 50us, for stm32f0. This
is useful for using low power modes and waking up after set
period of time.
BUG=chrome-os-partner:31226, chrome-os-partner:28335
BRANCH=none
TEST=tested on samus_pd with CONFIG_CMD_RTC_ALARM defined and
used rtc_alarm console command to test various timeout periods.
Change-Id: Ibabd8662cfbea654c7de387669f7be83af4fd79d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218322
Reviewed-by: Todd Broch <tbroch@chromium.org>
Previously there was no way to remove multiple units at a time
from the queue, and the queue was wasting an entry to disambiguate
full from empty. There was also no way to get the free entry
count from the queue, only the ability to query if it was above
a required amount. The queue was also storing its constant
compile time configuration as well as its dynamic state in the
same structure. This wasted RAM on configuration information
that doesn't change.
This refactor fixes these issues, making the queue suitable for
use in the new USART stream driver.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I284cee52d8189928dbc4c499f87ab34e14019e5a
Reviewed-on: https://chromium-review.googlesource.com/210533
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Change erase page size from 1kB to 2kB. The datasheet
specifies that the page size is 2kB.
This was causing occasional failures in flashrom because
flashrom only erases and writes pages where the flash
contents don't match the new binary.
BUG=none
BRANCH=factory-ryu-6212.B
TEST=Load onto samus_pd, and verify that flashrom
works successfully.
Also added console debugging to verify that the actual erase
page size is 2kB. I left the CONFIG_FLASH_ERASE_SIZE at 1024
and added the following code.
static int command_flash_is_erased(int argc, char **argv)
{
int offset = -1;
int size = CONFIG_FLASH_ERASE_SIZE;
int rv;
rv = parse_offset_size(argc, argv, 1, &offset, &size);
if (rv)
return rv;
ccprintf("Offset %d, size %d, is erased: %d\n", offset, size,
flash_is_erased(offset, size));
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(flashiserased, command_flash_is_erased,
"",
"",
NULL);
Then:
> flashiserased 2048
Offset 2048, size 1024, is erased: 0
> flashiserased 3072
Offset 3072, size 1024, is erased: 0
> flashiserased 4096
Offset 4096, size 1024, is erased: 0
> flasherase 2048
Erasing 1024 bytes at 0x800...
> flashiserased 2048
Offset 2048, size 1024, is erased: 1
> flashiserased 3072
Offset 3072, size 1024, is erased: 1
> flashiserased 4096
Offset 4096, size 1024, is erased: 0
You can see when it tries to erase 1kB at 2048, it actually erases
2kB.
Change-Id: I02772d4671784930765df63fa99968a07b15882e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217475
Reviewed-by: Vic Yang <victoryang@chromium.org>
Whenever we're sending raw status bytes from the EC(while the we're not DMAing)
the bytes kinda get garbled, and not get sent in the right order. Sometimes we
want the last byte sent to keep repeating, the problem is that it doesn't.
Seems like the tx fifo doesn't play nice with the DMA. The way we fix this is by
sending bytes 4 times, effectively bypassing the TX fifo.
Protocol v2 was not fixed yet. It just displays a warning if one tries to use it
on F0.
BUG=chrome-os-partner:31390
BRANCH=None
TEST=ectool version should work in the most recent kernel(with the v3 protocol
version). spidev/python "s.transfer("\xdc\x02\x00\xde"+"\x00"*100)" should
return a deterministic packet(the only variation between calls should be the
number of \xfa recieved(40 vs 41 or so)).
"flashrom -p ec -l /tmp/layout.txt -i rw:/tmp/rw.bin -w -V" now works properly.
Change-Id: Ia2772277428bd45013f5721a6bedab13d0591423
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217083
Reviewed-by: Randall Spangler <rspangler@chromium.org>
As a short term workaround for the I2C problem of PI3USB9281, we're
gating its SCL input when it's not addressed. This workaround will be
removed once we have the silicon fix.
BUG=chrome-os-partner:31526
TEST=Sanity check on P0 boards.
BRANCH=None
Change-Id: I57daf25f2ad2d94ac7e4192050b4d6bbdae9d51d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214064
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added atomic or/clear when modify a share register
LM4_SYSTEM_SRI2C_ADDR among different i2c ports.
BUG=None
BRANCH=ToT
TEST=Verified on Samus.
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: Ibf64b05a800ce2b8ddf9735bd3a762ab02031bc8
Reviewed-on: https://chromium-review.googlesource.com/213196
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Host i2c driver in ryu does not allow to snoop the byte
stream to abort the transaction. This make host i2c
driver to be in the dead state if the response message from
ec is shorter than host expected length.
This patch will make ec to send 0xec after end of response
message until get the 'NAK' answer from host to fixed this
issue which occur in these 2 situations.
1. When ec encounters host command error.
2. When response message is a null terminated string.
BUG=chrome-os-partner:31367
TEST='ectool version' runs fine on ryu
BRANCH=none
Change-Id: Icad0f0fde6cca4abd9c833c6d179143e4c5c0561
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213177
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
implement USB mass storage class using the bulk-only transport
protocol with the transparent SCSI command set.
BRANCH=none
BUG=none
TEST=verify that usb mass storage functions on windows xp, 7, 8, mac os x, goobuntu precise
Change-Id: Ideecad55bd275df7b30aa4a3ed263304a3a109cd
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206303
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During flash erase operation, read is stalled and thus interrupt might
be serviced later. This can cause PD communication to fail and thus the
board reboots if there is no battery. Print a warning message in this
case.
BUG=chrome-os-partner:31127,chrome-os-partner:31207,chrome-os-partner:31362
TEST=Boot Ryu, on software sync, see warning message before board
reboots.
BRANCH=None
Change-Id: If327a4f533fd2dfa83f92531148bd52ace927e03
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212264
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Certain i2c host drivers don't allow one to snoop the byte
stream to abort a transaction. Allow those devices to make
forward progress by sending out the '0xec' byte for any
requests coming through after an EC host command error.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Ran on ryu. Allowed passthru probing which normally hung
the system because of there not being a passthrue device
on ryu -- error returned. Instead the command returns
successfully by returning 0xec for the unfilled bytes.
Change-Id: Ibcab5ade1f727f3852995437105eb9fa693caadf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212165
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c_packet structure wasn't always being initialized
in the error path. It's possible to crash the EC if the first
command processed hit this error path. Instead, unconditionally
set all the i2c_packet fields.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: Ic6d7c63f61d59c4449fbb20f656c1bfb835db8be
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212164
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The wrong define was being used when checking the I2C ISR status.
The wrong define just so happened to be the correct bit.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: I6c7aad34f5e7c7ace4db4442147023346b6285bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212163
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Seems like STM32_SPI_CR2_FRXTH from 5d208b99(STM32F0 SPI Fixes) was not enough
to "disable" RX FIFO from the F0 series. There were still a few bytes stuck in
the FIFO just after a command with a long sequence of 00 bytes.
This increases the dummy bytes read just before a DMA transfer to 4(size of the
FIFO).
BUG=none
BRANCH=none
TEST=Veyron with the new EC should survive the AP booting. ectool version will
work right away after boot. This change should not affect other STM32 chips
because reading dummy bytes from an empty register is essentially a NOP.
Change-Id: I812208622a75ecce82433eb6c12595fee3c1428b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212297
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
Reviewed-by: Alec Berg <alecaberg@chromium.org>
After sending a message, we wait for up to 2.7 ms for reply. If we don't
get one, we retry for up to twice. Therefore, a undelivered message
could take up to >8ms. To prevent starving other tasks, let's yield to
other tasks on retries and rely on interrupt to wake us.
BUG=chrome-os-partner:28341
TEST=Plug in zinger on port 0 and C-to-A dongle on port 1. Check that
port 0 drops connection less frequently.
BRANCH=None
Change-Id: If85a70fd1140fef69d79243b198703ce601f8030
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211281
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
HAS_TASK_HOSTCMD is not a good indicator that we intend to use I2C Host Commands
On platforms such a veyron we use an STM32F0 with SPI HC for example however
i2c-stm32f0.c was very eager to still provide host commands via I2C.
If one wants to use I2C host commands they need to define
CONFIG_HOSTCMD_I2C_SLAVE_ADDR anyway, so the presence of that is a better
indicator.
The boards that want I2C host commands are ryu and samus_pd.
veyron/pinky needs SPI host commands, so this patch makes this case possible.
The rest of the boards that use STM32F0 do not have HAS_TASK_HOSTCMD set.
BUG=None
TEST=make buildall -j
BRANCH=None
Change-Id: Ia5561afdc6e72019c24c5c4b775944b2b88cb950
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211434
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The STM32F0 has a fancier SPI than the L1 series we've been using so far.
Notably it supports 16 bit data packing. This mode is activated automatically
by reading/writing to the SPI_DR register as 16 bits. We do not want this
feature since we only do 8 bit operations. This change prevents a misalignment
of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit
transfers.
Another unwanted feature is the FIFO. We rely on DMA and some buffers instead.
Keeping the FIFO enabled causes extra characters. The way this patch disables
the fifo is by changing the FIFO reception threshold to only 1 byte (which is
the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1
chips should not affect anything as that area of the register is reserved.
BUG=none
BRANCH=none
TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and
STM32F0(new support/veyron)
Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211476
Reviewed-by: Doug Anderson <dianders@chromium.org>
Packets can be 128 bytes, and are preceded by a prefix byte. So we
need a 129-byte buffer, not a 128-byte buffer.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=do pd software sync; see that 128-byte packets transfer correctly
Change-Id: Ic1e6cfec2c042537768d1cd0eecea509cc90c052
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210502
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Board bring up. GPIO / UART / timer / console / task / hook are
working now.
BRANCH=tot
BUG=none
TEST=run on evaluation board and see LED 0/1 are blinking.
Console commands are available to use.
Change-Id: If93a2c94b8abe1c2c931c03a7a12ddd2bed9d9f6
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209403
Reviewed-by: Vic Yang <victoryang@chromium.org>
The interrupt handler is hardcoded to I2C1. We should choose between
I2C1 and I2C2 based on I2C_PORT_EC.
BUG=chrome-os-partner:30707
TEST=On Ryu, ectool hello and see ACK.
BRANCH=None
Change-Id: I07055b0ee7459e6cac5585737e200ff2d5814a34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209960
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
