The new toolchain is putting again the __enter_hibernate function in
flash (.text) rather than in SRAM (.iram.text) after inlining both the
hibernate() and __enter_hibernate() function.
Workaround this issue by forcing "noinline" on __enter_hibernate().
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=make BOARD=samus dis
and check the disassembly, the __enter_hibernate is called in SRAM
through a veneer.
Change-Id: I015928ebe18ba8fd93252eece3e8a0fcf4b2a037
Reviewed-on: https://chromium-review.googlesource.com/242691
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
If the AP ignores the LPC_ST_BUSY bit (which is software-defined) and
tries to send a second host command while the first one is still
processed, we discard it.
This doesn't prevent the host to re-write the command arguments stored
in LPC shared mem (aka LPC_POOL_CMD_DATA) but when we will call
host_packet_receive, we will have either the old arguments or the new
arguments (or even a mix of both, which is less unlikely to pass the
checksum check), and we will copy them once before calling the HOSTCMD
task. So the host command task will have a single coherent (not
changing) view of the arguments when performing its input validation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31492 chrome-os-partner:23806
TEST=Boot Samus and play with ectool
Change-Id: I9aa1b8cdac05e323b91998188bd873826e83c274
Reviewed-on: https://chromium-review.googlesource.com/242593
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Reviewed-by: Kees Cook <keescook@chromium.org>
The current header location is too large for small SPI flash chips.
Since this value is only used for private EC SPI, it doesn't really
matter what it is. Let's just move it to 0x0.
Note that this doesn't affect shared SPI case, as we need a more
sophisticated packer for that.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Build for Glower and check the size of ec.spi.bin.
Change-Id: I96871d1677999e7cc1c7385b749563b8c09a318a
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241114
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Before enabling GPIO interrupts on boot, we should clear pending
interrupt status to make sure the interrupts don't fire unexpectedly.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Boot on Glower and make sure GPIO interrupts aren't triggered on
boot.
Change-Id: I2729b4a5046063e4ee4c08dcb7084a329bfdf042
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241112
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Chipset sometimes needs I2C, therefore i2c_init should have a higher priority
than power_common_init so i2c is available by the time the chipset might be
talking to the battery.
BUG=chrome-os-partner:35502, chrome-os-partner:35173
TEST=There is no "battery not responding" message at startup on veyron
TEST=EC boot takes less than 1 second on veyron
BRANCH=none
Change-Id: Ib10b653decc7703e706d4dd1976abf0fdbc25ac2
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241102
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The RTC delay is always less than a day (see the assert at the beginning
of set_rtc_alarm), so remove the useless module to save a few bytes of
flash.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
and see the zinger firmware is smaller by 16 bytes
(more than the 8 bytes I need to submit the following CL)
Change-Id: If0374ff5897f13e69574018d2123428075b2264e
Reviewed-on: https://chromium-review.googlesource.com/240564
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The check for overflow was originally in __hw_clock_source_read()
If it got interrupted, it would frequently see an overflow, because
"prev_read" would be less than "now".
1 - Use the comparator to check for overflow.
2 - Only check for overflow in the interrupt handler.
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
use the keyboard code to type
use a console command "forcetime", to force the system time to overflow soon.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I7005724222289ba967e89af0ce8b9ef8f90a4ae4
Reviewed-on: https://chromium-review.googlesource.com/239967
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
If the RO firmware has a different view of the protection than
the RW copy, we should not change the option bytes (write protection
settings) in RW else we will trigger a reboot loop : RW protects and reset,
then RO unprotects, resets and jump to RW, RW protects and reset again ...
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35383
TEST=craft a firmware image whose RO partition doesn't include commit
42d0104 (no virtual WP, no RDP set) and RW partition has everything
including this patch, see that HoHo no longer reboots in a loop.
Change-Id: I4cbdbf25a96cb6fb7cbabc7f2d1dc76d3a2a9e36
Reviewed-on: https://chromium-review.googlesource.com/240561
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Fix potential junk at end of PD TX transmit by adding to the DMA
transmit complete interrupt a blocking wait for SPI to finish and
then immediately disable SPI clock. This means we block in an
interrupt function for approximately 45us at the end of every
transmit. But, this is the highest priority thing going on anyway.
Note, there is still a potential for junk if both ports are
transmitting at the same time and finish very close to the same time.
BUG=chrome-os-partner:34600
BRANCH=samus
TEST=load onto samus and test communications with zinger. tested
specifically with an old zinger CL,
https://chromium-review.googlesource.com/#/c/226118/11,
which watchdogs when samus has junk at end of transmit. Tested
without this CL and verified we could never successfully flash zinger
over PD due to this watchdog and verified on scope presence of junk.
Then tested with this change and was able to successfully flash
zinger using ectool on both ports in both polarities.
Change-Id: If0cd9ab0551d36a7d7dc10232b6476dd56735972
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239244
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ensure that we can re-etablish a proper USB communication after a
sysjump by properly disabling the USB stack before jumping.
So the host sees a USB disconnection and can properly re-initialize the
device when it re-appears.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=On Twinkie, use the "sysjump RW" command on the USB console
and see the prompt coming back after a few seconds.
Change-Id: Iaf4498333eb4e7a1dda0f51ee8be19a0c9f10349
Reviewed-on: https://chromium-review.googlesource.com/239227
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
It's not safe to sysjump with a DMA enabled as it can led to memory
corruption after we have landed in the new image before that piece of
hardware is re-configured.
Implement and call dma_disable_all() on all platforms with generic DMA.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:34865
TEST=on various boards, call "sysjump rw".
Change-Id: I2a6b63ff19c2d932a5e31bc375bf468bc8ae5125
Reviewed-on: https://chromium-review.googlesource.com/237340
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
These USB type-C accessories don't have a write-protect GPIO.
Add a configure flag (CONFIG_WP_ALWAYS) to force the flash
write-protection on the dongles.
Also set the read protection (by elevating RDP to level 1),
so trying to unprotect the flash will trigger a full erase.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35088
TEST=boot Hoho,
check the flash OBR and WRPR registers:
"rw 0x4002201c" / "rw 0x40022020"
and the option bytes write-protect bits: "rw 0x1FFFF808"
dump the logical state with "flashinfo" command.
> rw 0x4002201c
read 0x40022020 = 0xffff0002
> rw 0x40022020
read 0x40022020 = 0xffff0000
> rw 0x1FFFF808
read 0x1ffff808 = 0xff00ff00
> flashinfo
Physical: 128 KB
Usable: 128 KB
Write: 2 B (ideal 2 B)
Erase: 2048 B (to 1-bits)
Protect: 4096 B
Flags: wp_gpio_asserted ro_at_boot ro_now
Protected now:
YYYYYYYY YYYYYYYY ........ ........
Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d
Reviewed-on: https://chromium-review.googlesource.com/238893
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Previously there was just a memcpy_usbram that copied to
USB packet memory, and no routine to copy out. This adds
the "from" version and renames and improves to "to" version.
The improvement is that the new "to" version correctly
handles unaligned beginning and endings of the region to
be copied. These need to be read/modify/write accesses since
the USB packet ram has to be manipulated in 16-bit chunks.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that discovery-stm32f072 still enumerates and communicates
correctly over USB.
Change-Id: I94353e66ad0248d4e674abb29f9a88e979767655
Reviewed-on: https://chromium-review.googlesource.com/238764
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
The recent change to decrease the time to wake up from deep sleep when
not using LFIOSC was too agressive. Increase the time to wake up based
upon the worst observed case.
BUG=chrome-os-partner:35184
TEST=Manual on Samus. Go to deep sleep, verify that no "overslept by
Xus" prints are seen.
BRANCH=Samus
Change-Id: Ib9fe2eba5e29a112e03fffaedbc5ae53d6d650ff
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239242
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Currently, we are seeing problem with adc_read_all_channels() for
STM32F, and thus 'adc' console command reports incorrect values. Before
that's fixed, read ADC channels one by one to work around this problem.
BRANCH=Ryu
BUG=chrome-os-partner:33971
TEST='adc' on Ryu
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: Iae92b82b24f6a843b9d46a8804da1e51d33ed7cb
Reviewed-on: https://chromium-review.googlesource.com/231125
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Decrease the time to wake up from deep sleep when not using
LFIOSC (when using PIOSC in deep sleep). This helps keep us
in deep sleep longer and therefore save power.
BUG=none
BRANCH=samus
TEST=Load onto samus and run for a couple of hours, varying from
S0 to S5, with and without EC. Use idlestats to check that closest
we get to missing deadline is 86us away.
Change-Id: I3eee908e9f42a1c5b549e93d63588a3cb6e29a5d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238412
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Check the flash protection at startup, if the RDP is still at level 0
(no read protection) or if the RO partition is not write protected :
- set the write protection on the first 16KB of flash (4 LSB of WRP0)
- push the RDP to level 1, so SWD/serial monitor needs to fully erase
the part before re-writing the code or the write-protection.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34935
TEST=dump the content of the option bytes.
Change-Id: I11af64365a6fbc34327b2e463eb8e2d369ffacd2
Reviewed-on: https://chromium-review.googlesource.com/238262
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>
Use the PORT event for keyboard inputs.
Make a column mask for driving all outputs at once.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Used hadoken and the Ryu base keyboard to check that the keys are all
functional, that the keyboard polls while keys are held, and that it waits
for interrupts when the keys are released.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: Ie1dd1ca17b21ed76b2d412bf25fe87e45c5ba757
Reviewed-on: https://chromium-review.googlesource.com/234394
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Add structures to keep track of which interrupts are associated with which pin.
There are IN[] events, and one PORT event. The IN[] events have an array.
The PORT event can be used for multiple pins at once.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Configured pins as IN[] events and PORT events, and saw console output.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I129a6586dca4d5eb141c86fd92fbfbb70080bc2a
Reviewed-on: https://chromium-review.googlesource.com/234392
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Updated to use parameters for GPIOTE_OUT, GPIOTE_IN, and GPIOTE_CONFIG
Updated with NRF51_GPIOTE_IN_COUNT to remove the magic number.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Configured IN[] events and PORT events and checked that they triggered
events and wrote to the console.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I2021ecbee67c39571f277c97082378dce4de024f
Reviewed-on: https://chromium-review.googlesource.com/234289
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Add support for alternate functions for nrf51.
Add more register definitions for the nrf51.
Use assertions for conditions that should never happen.
Use BUILD_ASSERT to keep the sources in sync.
Add three more GPIOs to hadoken.
BQ27621_GPOUT - Configurable output from the fuel gauge.
LID_PRESENT_L - The input for the hall sensor.
IND_CHRG_DISABLE - The output to control inductive charging.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Used gpioget and magnets for LID_PRESENT_L
Used fuel gauge console commands to trigger BQ27621_GPOUT
Tested the assertions with gdb
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I508f79ae45127104fa14f9f75fbf545f226387e4
Reviewed-on: https://chromium-review.googlesource.com/234286
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
With the type-c connector, it's common for VBUS to make contact before
D+/D-, which can lead to charger misdetection. To work around this, add
a 200ms delay and trigger re-detection when a charger is inserted. This
should fix most misdetects due to unintentional slow plug (though it's
still possible to misdetect if insertion is deliberately very slow).
BUG=chrome-os-partner:34584
TEST=Manual on Samus. Plug in Apple charger 20 times, verify that it is
always detected correctly. Deliberately plug in slowly, verify it is
detected as 500mA SDP port. Repeat tests with various other CDP / SDP
ports to verify detection never over-currents and always indicates a
charger is plugged (or not plugged) correctly.
BRANCH=Samus
Change-Id: I8a776f516d8e7f0cedcb9d8579239eba641cab09
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237241
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add EC2I control module for emulation board.
The EC2I bridge enables the EC to access the host controlled
module registers (e.g., host configuration module(PNPCFG) and SWUC)
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=EC2I read: Read a logical device page, the results are correctly.
EC2I write: Initialize PNPCFG success.
Change-Id: I900450d4a8c49182c438b69b5e738c12dc437fe4
Reviewed-on: https://chromium-review.googlesource.com/230410
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
STM32 seems to actually measure the rising and falling time of the I2C clock, so
if one uses a really small resistor the timing will go faster than with a bigger
resistor.
This commit makes it so the I2C frequency is limited to max 100kHz (respecting
the spec) no matter what size resistor (essentially we assume 0 rise and fall
times). While this will make stuff slower on boards with big resistors (where
they might have been under 100kHz anyway) this is the best compromise (since the
spec does not specify min frequency) without getting config defines for the
fall/rise times.
The TSCLH of some boards would be too short with the recommended timing
settings from spec, so increases the TSCLH would be better for everyone.
This patch does not touch the higher frequencies since the rise and fall times
do contribute a lot more to clocks, if the same method was used for those
frequencies, the speeds would have to be a lot slower.
BUG=chrome-os-partner:34375
BRANCH=None
TEST=on any EC, note how frequency does not go above 100kHz
TEST=As per tSCL = tSYNC1 + tSYNC2 + { [(SCLH+1) + (SCLL+1)] x
(PRESC+1) x tI2CCLK } from datasheet
Change-Id: Ibbeecac7f3da1b22d2ba3bca29ee3c17bfe997f5
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234077
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the EC is busy enough to start missing RX characters an ORECF might come
(Overrun error), we never check for this bit, so that means the interrupt
handler will be called in a loop because it never clears that bit.
This disables the overrun detection feature.
BUG=chrome-os-partner:33451
TEST=get firmware to poll the EC for keyboard presses, type really fast on the
keyboard, note how system does not watchdog reset anymore but loses the
occasional character instead.
BRANCH=None
Change-Id: I711483768e4ba80aaeb4a324c7dee790b3a23682
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236088
Reviewed-by: Randall Spangler <rspangler@chromium.org>
According the STM32L RM, when writing to RCC_CFGR to change HSI or MSI
clock source, SWS bits of RCC_CFGR register have to be checked if the
new clock source is taken into account. Also, when writing ACC64 bit and
LATENCY bit to FLASH_ACR register, those bits have to be checked too.
Also changed in this CL is to disable MSI if HSI is enabled, and disable
HSI if MSI is enabled.
BUG=chrome-os-partner:32936
BRANCH=none
TEST=passed suspend_stress_test on big, blaze and nyan
Change-Id: I3ec660d149ecdec3ca3097239612bf2c542d0548
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234490
Reviewed-by: Kary Jin <karyj@nvidia.com>
Tested-by: Kary Jin <karyj@nvidia.com>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
(cherry picked from commit 400d9dca8c41f74cf0c2587e881707b80bb17d3d)
Reviewed-on: https://chromium-review.googlesource.com/236050
Added check for collision just before transmitting on CC line.
To check for collision, RX monitoring is left on all the time
(except when in the act of receiving or transmitting, or in
between receiving and sending a goodCRC), and a
simple check for RX transmission started is used to see if the
CC line is idle or not.
RX monitoring is also changed to only trigger on 3 edges within
20us, as per the PD spec.
When a collision is detected by seeing that CC is not idle, the
transmitting packet is dropped.
BUG=chrome-os-partner:30135
BRANCH=samus
TEST=load onto samus and zinger. make sure we negotiate and make
sure custom VDMs succeed. enabled pings and made sure we stay
alive with pings for a few min.
Also added code to pd_rx_handler to toggle a test point on EVT
board to verify the timing of when we get RX interrupts:
Change-Id: I22d172163319437d3d901e019eda79d4d592f6b8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226118
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Ryu sensor hub has asymectric RO/RW images. The first one is very limited
(not i2c master, no sensor drivers, gesture recognition).
Image size is alter to offer more space for the RW firmware image,
compiled with ryu_sh board.
To write RO image and basic RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w /tmp/ryu_sh_loader/ec.bin
To write the expected RW image:
flashrom -V -p ec:type=sh,block=0x800 --fast-verify -w -i EC_RW:/tmp/ryu_sh/ec.bin
BRANCH=ToT
BUG=chrome-os-partner:33908
CQ-DEPEND=CL:231970,CL:233233
TEST=load on Ryu, confirmed limited operation.
Change-Id: Ib976e2b048935adfb9b2b072c071db5be2bc1c09
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231984
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The task based approach made sense when it looked like
there would be a case closed debugging task to handle
multiple bridges (SPI/I2C/USART...). I'm not convinced
anymore that that task will be needed, so this
simplification seems good.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ic431c287c28d10252246fe9f507d9c5fcc64a077
Reviewed-on: https://chromium-review.googlesource.com/232733
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This allows the USB SPI bridge to be controlled from the
host at a larger timescale than a single SPI transaction.
This allows the host to signal that many transactions
will take place and that the device should keep the SPI
bridge enabled across them. This allows the device to
hold the AP or other possible user of the SPI bus in
reset while the bridge is enabled.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ifd6f96b0ff47f35d853735d44e255a205b0e677a
Reviewed-on: https://chromium-review.googlesource.com/232732
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Build the hardware version string from the register definitions,
so I no longer forget to update it.
Check it at runtime against the build version registers.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=On the console command line,
type "version" and see the following string:
"Chip: g cr50 A1 20141203_224409"
Change-Id: I6d902780d42f2dd18a57ccc08fd4ba4fee5ebc7c
Reviewed-on: https://chromium-review.googlesource.com/233582
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
- record and display reset cause
- add the hard reset option
- add the scratchpad to store values across reboots.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33818
TEST=On the console command line, chech the "[Reset cause: xxx]" string
- for the initial reset cause
- use "waitms 4000" to trigger a watchdog reset
- use "reboot soft"
- use "reboot hard"
The "utils" test is now building and passing.
Change-Id: I68c7096e5b7bfd102be89fd8eef6fe20da37a6f8
Reviewed-on: https://chromium-review.googlesource.com/233581
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
