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>
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>
The mec1322 LPC / EMI comm driver is no longer functional due to recent
EC changes. Rather than re-implementing a working driver across user
space tools, the plan of action is to use the kernel device driver
(through comm-dev) for all access.
BUG=chrome-os-partner:38103
TEST=Manual on glower with pending kernel cros_ec_lpc changes. Verify
"ectool version" and "ectool gpioget" succeed.
BRANCH=None
Change-Id: I770cb06ca534a7c31794e6b37c226e952361ee32
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265031
Reviewed-by: Randall Spangler <rspangler@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>
Modify usbpdpower HC return args by adding a new current limit
field, and adding a new charger type (UNKNOWN). Note this
doesn't change the size of the return struct.
BUG=chrome-os-partner:38548
BRANCH=samus
TEST=make -j buildall
Change-Id: I51bb062a7e4fcd9ae6aea15204adb83b19882ac9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264641
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This replaces a special-purpose python script with futility, to
sign the firmware for those boards that require a signed RW image
instead of using software sync.
Currently, the only boards that do that use a signature scheme
that is somewhat opaque (refer to commit b5a439241f in the
vboot_reference repo for details). Futility calls that scheme
"--type usbpd1".
BUG=chromium:231574
BRANCH=ToT
CQ-DEPEND=CL:*212135
TEST=manual
To test, I obtained a reworked zinger that could be connected to
servo. I first flashed it with a dev-key-signed RO+RW image built
prior to this CL, then I applied this change, built a new image
(with a minor change to the startup message), and updated only
the RW half from Samus using
ectool --name=cros_pd flashpd 0 1 /mnt/stateful_partition/ec.RW.bin
Watching the zinger console when plugging and unplugging, I
confirmed that the RO firmware was still the original and the
verified-by-RO RW firmware was the new version.
Note: I also had to build a custom AP kernel without the cros_pd
driver, to prevent interference with the manual update.
Change-Id: I22d8e75c85dab7701af8fe98287f14ebe77dbbd4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264508
Reviewed-by: Mike Frysinger <vapier@chromium.org>
I2C ports initialized as per board design. Modules
assigned to its corresponding I2C port numbers
Altered the SPI flash size to match the Braswell Ref Design board
BUG=None
BRANCH=None
TEST=Tested all I2C modules on all ports using i2cscan and i2cxfer
console commands
Change-Id: I4158c1aeb29193b5bd07450ba28cdcdc2413926a
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264261
Reviewed-by: Shawn N <shawnn@chromium.org>
Create a USB PD device whitelist for allowing charging by default
from dual-role devices that don't set the externally powered bit.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=modify zinger and modify VID and PID to match white-listed
entry. also modify zinger to remove externally powered bit and
set dual-role power bits so that we treat as a dual-role device
by default. when you plug in this modified zinger into samus,
it still will not charge because the VID and PID are obtained
after deciding to treat it as dual-role, but when you issue
soft reset "pd 1 soft", it starts charging. the white-listed
device will always ask for a power swap if it is a sink, so
we will always get source cap after learning the VID/PID, which
should correctly trigger changing the device to be treated as
a dedicated charger.
Change-Id: Ibe7ec57f842a0b9bfb02447baf5b3327217a9516
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264015
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
