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>
Add Apple VGA charge-through adapter PID to dual-role charging
white list so that we automatically charge through it.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=make -j buildall
Change-Id: I5de757a9e97824a2b488a45497c73ab53cc1899c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267300
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As a source, when we detect Open/Ra (active cable with no UFP)
then do not transition to debounce CC line, instead continue
dual-role toggling as if nothing is connected.
BUG=chrome-os-partner:35652, chrome-os-partner:39486
BRANCH=samus
TEST=test with samus and twinkie. on twinkie, simulate Open/Ra
with: "tw res ra nc" and verify that we continue dual-role toggling.
Then plug in zinger and verify we negotiate and start charging.
Also, tested case where we initially detect Open/Rd and start
debouncing, but then it turns into Open/Ra:
echo "tw res rd nc" > /dev/ttyUSB0; sleep 0.05; echo "tw res ra nc" > /dev/ttyUSB0
In this case, samus transitions to SRC_DEBOUNCE briefly, then goes
back to disconnected state and continues dual-role toggling.
Change-Id: Idabac60b9e2f54639d7a6305d96e9984b0600519
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267087
Reviewed-by: Vincent Palatin <vpalatin@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>
We allow reading the EC console via case-closed debugging on locked
systems, so we should also allow reading it via host command. The
original reason for denying this (EC printing keystrokes) no longer
exists; we don't print keyboard matrix changes by default anymore.
BUG=chromium:479223
BRANCH=none (well, could apply this anywhere...)
TEST=on a system with both hard and soft WP enabled in the EC,
'ectool console' works instead of failing with access denied.
Change-Id: Ie111bc130dd3f17cd4b658718d00d299786e3434
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266701
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Update the BQ2589x charger driver to configure properly the boost
used as a VBUS 5V source.
Define the bits used for I2C registers configuration.
Return success in unused charger callbacks to avoid blocking the
charge state machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38603
TEST=On Ryu P4 reworked with BQ25892, plug a C-A receptacle adapter and
see the 5V VBUS coming up, un-plug it and see VBUS going away,
try several PD/type-C charger and check the selected current limit.
Change-Id: I24b832b6d130ff6dfda1ce47f5e445d65279fa7d
Reviewed-on: https://chromium-review.googlesource.com/266063
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
For the driver functions get_range and get_data_rate, each call would
end up executing an i2c transaction even if the value had not
changed. Therefore, I modified the lsm6ds0 driver to cache the output
data rate as well as the range. This prevents unecessary i2c
transactions from occuring.
BUG=chromium:476226
TEST=Flashed EC on samus and verified that the accelrange and accelrate
commands still worked and that the sensors were functional.
TEST=Verified Double Tap still worked.
TEST=make -j buildall tests
BRANCH=none
Change-Id: Ie432979266dc4e4892978005de5d1df62cc0654f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/265933
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Move "-fno-delete-null-pointer-checks -fconserve-stack" to the
target-only portion of the CFLAGS as they are no needed for host tools
(and not supported by clang).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:475960
TEST=make utils-host V=1
make BOARD=samus_pd V=1
and manually check the compilation flags
Change-Id: I001359621d60b5ad4e020f41fe2e97d4b7edec2a
Reviewed-on: https://chromium-review.googlesource.com/266212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This frees up 4KB of space for EC_RO, so both it and EC_RW can expand
to 64KB instead of 60KB.
Note that if a EC-RW with this change is written on a system with an
old EC-RO without this change, the new EC-RW will be unable to
enable/disable flash protection (because it won't be able to change
the pstate in the separate block used by the old EC-RO). So this
should NOT be picked to the samus branch.
BUG=chromium:476659
BRANCH=none
TEST=sudo fmap_decode build/samus_pd/ec.bin
Note that EC_RO is now 0x10000 bytes, not 0xf000 bytes.
Add a bunch of dummy printf()'s and see that EC_RO code size can go
past 0xf000 bytes, where without this change it overflows the .rodata
segment and fails to build.
Change-Id: I67ec3e2c787a467f87e52a83d3bd81b79f1ffa61
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266115
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
Export what the PD protocol stack thinks about the port connection
state. This simplifies getting a meaningful data role/power role from the
host (eg we are not really a UFP if we are simply dual-role toggling but
not connected).
Do not increment the command version as this is mostly
backward-compatible and currently no client actually uses that field.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug and unplug various accessories on the port and check the result.
Change-Id: Ief3e0d47b6a288bcfc5b8fbb8156f29fd09dd336
Reviewed-on: https://chromium-review.googlesource.com/266120
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Certain chips have I2C ports mapped to the same controller. In this
case, it's necessary to lock out access to the controller during use.
This configuration can be supported by adding CONFIG_I2C_MULTI_PORT_CONTROLLER,
which can be defined at the chip level, along with an API function to
map port index to controller index.
BUG=chrome-os-partner:38335,chrome-os-partner:38945
TEST=Manual with subsequent commit. Verify that i2cscan is functional on
strago.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I37ffa661a2ad6cd2235cef2ee77637cc3ab92523
Reviewed-on: https://chromium-review.googlesource.com/265942
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Rather than hardcode a specific mips toolchain, do a build-time test to
see if the target is x86 based.
BUG=chromium:443783
TEST=link still includes comm-lpc
TEST=arm64 omits comm-lpc
BRANCH=none
Change-Id: I0253df6cbe89bee231ec643dd6bb3498eb040708
Reviewed-on: https://chromium-review.googlesource.com/265793
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@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>
This was causing the amount of data sent to be larger than the
total size of the descriptors.
Before this CL, connecting the Cr50 through USB gave this kernel
message:
usb 2-1.4.7: config 1 descriptor has 1 excess byte, ignoring
When the host requests the descriptor, the code in chip/*/usb.c
that handles it looks like this:
case USB_DT_CONFIGURATION: /* Setup : Get configuration desc */
desc = __usb_desc;
len = USB_DESC_SIZE;
break;
But include/usb.h has this:
#define USB_DESC_SIZE (__usb_desc_end - __usb_desc)
And both __usb_desc and __usb_desc_end come from the linker
script.
BUG=none
BRANCH=none
TEST=manual
Before this change, I built the Cr50 firmware from m/master,
tried it, and got the dmesg complaint on the host.
After this change, the dmesg complaint doesn't show up anymore.
Change-Id: I83ae2333a9e76af7acb18bd2f0e4cef5c095862a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265765
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If UFP sends invalid VDM responses to the DFP its possible that modep
pointer may be NULL. CL qualifies all uses of modep to guarantee that
these invalid responses don't cause samus_pd to crash.
BRANCH=samus
BUG=chromium:476773
TEST=manual,
1. Still successfully negotiate alternate mode (both DP & GFU) with
hoho.
2. passes usbpd_DisplayPortSink autotest.
Change-Id: If4a611182b5e659c5534c2206132ef76d4e023db
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265620
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Unaligned memory access would not cause reboot on some
processors. Additional condition was needed.
BUG=none
TEST=Verified that "crash unaligned" causes a panic on mec1322.
BRANCH=none
Change-Id: Icdc1b5e11634b14890755301346183e0dba723c9
Signed-off-by: li feng <li1.feng@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/263949
Reviewed-by: Shawn N <shawnn@chromium.org>
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>
Host's single lane training algorithm in kernel (intel_dp_is_reversed)
appears to confuse the re-driver's auto training algorithm. If
however its manually configured the algorithm succeeds.
NOTE, this does present risk on the DPsrc (re-driver) to DPsink
(external monitor) side as voltage levels & pre-emphasis will NOT be
adjusted.
This may be acceptable in the short-term while determining if
additional functionality needs to be added on host side to account for
re-driver's presence
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:35153
TEST=manual, plankton drives 4K monitor in both polarities
Change-Id: I83ea80c44d36ad1afad56528c80ec5b8a138b5be
Reviewed-on: https://chromium-review.googlesource.com/263138
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@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>
Support VCONN swap on samus and always accept VCONN swap when in
S0 or S3. In S5, we can't provide VCONN, so reject VCONN swap
requests.
BUG=chrome-os-partner:34978
BRANCH=samus
TEST=load on two samus' and use "pd 1 swap vconn" to swap which
side is source vconn. also run in S5 and verify swap request is
rejected.
Change-Id: I04be8d1d910a2d6c5ad8b27a790f8e33121c86ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264856
Reviewed-by: Vincent Palatin <vpalatin@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>
The warm_reset_l signal is an open drain output on the servo side and
its input value can be read back as on (level 0) when the AP power rails
are off on the DUT side and not pulling it up.
So the current mechanism of reading the warm_reset input value with
dut-control at the beginning, then restoring it at the end is sometimes
broken because when the AP is OFF, we are reading input == on (while we
had actually set output to "off" but we have no pull-up) and then
restoring a "hard" on (drive low on the servo side).
In this workaround, just assume we don't want to pull warm_reset after
flashing the EC and restore it to off.
A better solution might be to have a mechanism in dut-control to read
the output register rather than the input value for GPIO, so we can save
and restore them safely.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:30738
TEST=On Ryu P5 with the AP off, run ./util/flash_ec --board=ryu
then boot the AP properly with the power button.
Change-Id: I96e65c2fec5e6d604445af3fe26fce73678b1d3b
Reviewed-on: https://chromium-review.googlesource.com/265223
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
The lightbar traces are quite verbose when going through AP power cycles
and prevent people from debugging the current power issues.
Let's turn them off by default, real lightbar lovers can still use
the "chan" command to re-enable them.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=mkae buildall
Change-Id: Ia91f1f9ea2c62a35a0d64e06d377f137ba69fc5e
Reviewed-on: https://chromium-review.googlesource.com/265145
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
When shutting down the MAX77620 PMIC by asserting its SHDN pin, the
EN_PP3300 output of the PMIC (GPIO3) is not driving low keeping the PP3300
rail up. Workaround that issue by removing the pull-up on EN_PP3300 when
we assert SHDN.
Revert the previous CL 263958 aka "ryu: workaround MAX77620 shutdown issue",
in order to use a better workaround which ensures that the power rails
sequencing at startup
Detect the PP1800 rail going up and down by reading the HPD_IN gpio
state (which has a pull-up tied to PP1800), then enable/disable
EN_PP3300 in sequence.
The code using an interrupt on HPD_IN is enabled only on P5,
and as a downside, it is killing the base charging on those boards.
Indeed HPD_IN(C1) is hijacking the EXTINT1 which used to be connected
to the LID_OPEN (E1) GPIO used for the base detection.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38689
TEST=on both P4 and P5 boards, do various power cycling sequences of the
AP using the "apshutdown" and "powerbtn" commands.
Change-Id: Icad6e9ae6a08d76cbfd19f97dd7c129bf43037d8
Reviewed-on: https://chromium-review.googlesource.com/265186
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Alec Berg <alecaberg@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>
When a platform is built without the common runtime to optimize for
flash size, remove the 64-bit support in printf to save more space
(mainly by getting rid of the uint64divmod helper).
This saves 376 bytes of flash on Zinger/MiniMuffin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall and compare flash size with and without the change.
the common runtime binaries are identical excepted the version
information.
Change-Id: I1e7237e693df9ea23291c8c0fe414c3b5c716848
Reviewed-on: https://chromium-review.googlesource.com/265052
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@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>
Combine source and sink data role swap states into one data
role swap state. This saves 128B of flash.
Also add DUAL_ROLE_IF_ELSE macro to clean up all the places
we check our role and need to know if we are DUAL_ROLE or not.
BUG=none
BRANCH=samus
TEST=load onto two samus' and try data swaps from both sink and
source sides and make sure they get rejected and go back to the
correct ready state. load onto zinger and make sure we successfully
data swap when connected to samus.
Change-Id: I57744593ce291e512cb254b08745115de365cab4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264855
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
