Modules that are enabled are listed below:
- Power Sequencing
- Keyboard Scan and Protocol
- LPC to support Keyboard
- Power Button Task
ec.spi.bin has to be generated manualy using
pack_ec.py
BUG=None
BRANCH=None
TEST=Tested on Stargo-Proto board
Change-Id: Ic5d504c3d6e9c7c5f3482fb7e9e37800b6274824
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226303
Reviewed-by: Vic Yang <victoryang@chromium.org>
The fans on samus have a recommended minimum duty cycle of 20%
while running, but 30% in order to start. We've been using the
EC's built-in fan controller for the start requirement, but it
has a minimum fast-start duty cycle of 50%. It turns out that
that speed is noticeably noisy.
This change handles the startup with logic in the EC instead, so
that the fan only tries to spin at 30% initially (or if it drops
too much below the minimum turning speed).
BUG=chrome-os-partner:33429
BRANCH=ToT,samus
TEST=make buildall -j
Boot the system, let it idle with the browser windows closed, the
browse a bit, then idle. Listen for changes to the fans.
Before, I could hear the fans kick in and out as the AP load
changed. Now it's much quieter.
Change-Id: Id35215520c064eb6843686ec8bb5f3618dac6cf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously the version string was special cased in the USB stack
because the build system prevented the inclusion of ec_version.h in
any file other than common/version.c. This lead to common/version.c
being the only place that the USB version string could be computed
and thus the special case of filling in the version string descriptor
at run time. This made the USB stack more complex, and lead to the
common/version.c file including usb.h, which is actually STM32
specific.
Now, the portion of ec_version.h that is deterministic is only
updated when something in the tree actually changes (by way of a
conditional in the makefile), and ec_version.h no longer has to
depend on all object files (other than the special version.o).
This allows anyone to include ec_version.h as needed. In particular,
each board that wants to define a USB version string can directly
include ec_version.h and do so.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
touch files and verify rebuilds happen correctly
Change-Id: Ic84d0b9da90f82ebb4630fb550ec841071e25a49
Reviewed-on: https://chromium-review.googlesource.com/227211
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
The serial console works. Nothing else is implemented yet.
BUG=none
BRANCH=ToT
TEST=make buildall -j
To build,
make BOARD=cr50 hex
Testing the result requires a development board. I have one. It
works with HW revision m3.dist_20140918_094011
Change-Id: I718d93572d315d13e96ef6f296c3c2796e928e66
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226268
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Per table 6-24 of USB PD spec an alternate mode adapter (AMA) should
include both product & AMA VDOs.
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
Connect hoho/dingdong to fpie/samus and see product VDO proceed the
AMA VDO in DFP_U console output:
Product VDO -----------------------------v
|------|
SVDM/5 [1] ff008041 340018d1 00000000 50100001 1100000b
Note, hoho's PID == 0x5010
And dingdong (0x5011)
SVDM/5 [1] ff008041 340018d1 00000000 50110001 1100000b
Also see bcdDevice field in descriptor match above data.
$ lsusb -v -d 18d1: | egrep -i "idproduct|bcddev"
idProduct 0x5011
bcdDevice 0.01
Change-Id: I4d898816a45c68c7ff75a54fd348fc11be408ae0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226125
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
USB Billboard class can be used to advertise an alternate mode capable
device that hasn't entered a mode. Additionally it can remain after
mode entry providing its Billboard capabilities descriptor is
updated.
This CL postpones enumeration which previously occurred after boot
until tAMETimeout has passed and alternate mode has NOT been entered.
Future CL could choose to also (re)enumerate with mode capabilities
although this is not required by the USB PD specification.
BRANCH=none
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
With DFP_U which does not enter mode see Billboard class enumerate
else it does not.
Change-Id: I59a0815cd0ea551ba9a878907c0184df4ba9480c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224663
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Now that the problem with UART in STOP mode is fixed, let's enable low
power idle for Ryu P2 boards.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Shut down the AP and unplug AC power. Check the EC goes into
deep-sleep by 'idlestat'.
TEST=Power up the AP and check the EC stays awake.
Change-Id: Ib8ad3763407315ec0f95551fa0fdd258a060e113
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226312
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
These names can be used to uniquely identify an interface
as being a console forwarded from the AP, or the EC's
console or some other console. This makes it possible to
connect to the correct console from servo without knowing
what board is attached. These strings could also be used
by udev rules to create appropriate symlinks.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I1abd36f952782a03606b09485917be8e154534ce
Reviewed-on: https://chromium-review.googlesource.com/225950
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This uses the newly allocated simple serial SubClass
and Protocol identifiers to make enumeration of serial
consoles over USB easier. The simple usb serial kernel
driver can select based on vid/class/subclass/protocol,
making it trivial to attach to serial consoles.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable USB console on discovery-stm32f072 and verify
that a new ttyUSB? device is discovered.
Change-Id: I6d3e414a20753573c2ee90a48fb1d5dce2c3972d
Reviewed-on: https://chromium-review.googlesource.com/225869
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously the USB console code used two separate
bidirectional endpoints. Using the STM32 USB perihperals
endpoints in this manner means that there are only 8 total
endpoints available. But the STM32 USB peripheral allows
for a single endpoint number to be used for both IN and
OUT transactions, and while this (re-using an endpoint
number for both IN and OUT endpoints) appears to be not
compliant with the letter of the law with respect to the
USB spec, it is supported by USB stacks, and is used in a
number of USB devices.
So this change makes the USB console driver share a single
endpoint number between the IN and OUT bulk endpoints used
to implement the console.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable USB console on discovery board and manually test.
Change-Id: I511e56de2162a6c04ddba80d26b37b4f0cd993fd
Reviewed-on: https://chromium-review.googlesource.com/225868
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
When calling the ep_undefined function, the linker was not considering
it as a Thumb function and not setting the LSB in the address pointer.
This was causing an exception at runtime.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=none
TEST=inspect assembly
Change-Id: I8f4d1e351081032e138f593f0b61294031fc09b1
Reviewed-on: https://chromium-review.googlesource.com/226093
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=master
BUG=chrome-os-partner:29139
TEST=Buiid an EC FW image and run on Rambi to test if key loss is
improved and any side effect somes with this change. Need more test
units to confirm this.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I2399e33d2ca3defe8cd9b1f94ab0af1db7f84635
Reviewed-on: https://chromium-review.googlesource.com/225557
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Previously the USB console code would wait for up to
30 ms for the USB packet buffer to become available
for transmission, even if it was called from an interrupt
context. This doesn't work because, even if we were OK
with waiting this long in interrupt contexts, which we are
not, we rightly assert that we are not in an interrupt
context in task_wait_event, which usleep calls.
This solution is a quick fix to only wait when not called
from within an interrupt context. The correct solution
is likely to decouple the printf code from directly calling
the console driver code, instead we should place a queue
between the driver and printf logic.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable USB console on discovery board and manually test.
Change-Id: I5b6f7bbb77f75132c75935f8fda01e652a236ae0
Reviewed-on: https://chromium-review.googlesource.com/225867
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
By default, UART wakes the chip up on RXNE interrupt. This means when
the chip wakes up, RDR is full and only the shift register is empty, and
this leaves us only the time of a single character to process the
character in RDR. On some system, this is not enough and the first (or
even the second) character is overrun, and thus any multi-character keys
(e.g. arrow keys) break.
To avoid this problem, let's change the wake source to wake on start bit
detection. This gives us the time for one more character to wake up and
process the console input.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Enable low power mode on Ryu P2. In STOP mode, hit up arrow key and
see the last command show up.
Change-Id: Idce4c0bdfcf3e04ad84152ba525f704a0909f115
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Before entering STOP mode, we need to ensure UART Tx has completed.
Otherwise, we may lose some characters or some bits within a character.
For Tx DMA mode, this is already done as we wait until TC (Tx complete)
is set before disabling Tx. However, when not using DMA, we enable sleep
when TXE is set. At this moment, the last character is still in the
shift register and going into sleep causes loss of the whole or part of
the last character.
To avoid this, let's enable TC interrupt and enable sleep only if we
have no more characters to send and TC is set.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Enable low power mode on Ryu P2. Type when the EC is in STOP mode
and check there is no broken character.
Change-Id: Ife42671882b7f1d1d17734d7d20fb4ba7dffb371
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225283
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds the option to use one 16-bit timer for watchdog helper when
using 32-bit hwtimer. With this, a debug message is dumped before
watchdog fires and we can easily see the task hogging the processor.
BRANCH=None
BUG=None
TEST=On Ryu P2, 'waitms 3000' and see debug message before the EC
reboots.
Change-Id: I498f63a105a0ba1ab7ec7d274dc8b1f16a44140f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225253
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This modifies the stray hard-coded DMA channel for UART Rx to the
correct config flag.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=On Ryu, enable UART Rx DMA and check console is still responsive
Change-Id: Icec2de6ad4d34c6e0f8df2a1d51d9fefd982c9f4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225239
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On STM32F0, a single IRQ is used for all RTC events, including RTC_ALARM
and RTC_WAKEUP, and this IRQ is named RTC_WAKEUP. We use RTC_WAKEUP IRQ
in our code while we actually meant to capture RTC alarm event. On
STM32F3, RTC_WAKEUP and RTC_ALARM are separate IRQs and thus we're
having problem. Let's make it explicit which RTC IRQ we want to use and
fix our code to use RTC_ALARM.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Run 'rtc_alarm' on Ryu and verify the EC gets interrupted after a
second.
Change-Id: Ib1a14a5da49d709a4d071d44fbfa46544cc5929b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224998
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Simple control of SPI for flashing over USB.
This driver is working, and using the discovery board
with a W25Q16 flash chip attached flashrom can read,
erase, write, and verify the whole chip in 45 seconds.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I224f1f87cd6adc8b64c17de1df98dae0a9cfa6a5
Reviewed-on: https://chromium-review.googlesource.com/218740
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Updating the fan speeds according to the manufacturer's specs.
The fan vendor recommends that the minimum fan speed be a 20%
duty cycle. Since the built-in fan controller has a tach-based
feedback loop, I'm using the RPM value instead of the duty cycle
(20% is 2286 RPM, according to the vendor).
The vendor also wants a 30% duty cycle to start turning, but the
built-in fan controller provides support for fast-start too. The
controller's minimum fast-start duty cycle is 50%, but it also
has a programmable number of revolutions that it will wait before
backing off.
Holding my ear down close to the fans while they start and stop,
it seems that the minimum 2 revolution start period is sufficient
and provides the least noise. Of course, since I've never had any
problems starting the fans directly at 1000 RPM this noise is a
little more noticeable than that. It's quite possible that the
built-in controller is smart enough to make 1000 RPM work by
bumping the duty cycle up until the fans turn even if the fans
don't like it.
BUG=chrome-os-partner:32892
BRANCH=ToT,samus
TEST=manual
Listen closely and run the EC console "faninfo" command to see
the fans start and stop as the system boots and idles.
Change-Id: I47c9e7cef3f9f4bd815a13032fe10234decd62ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224830
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Unlike STM32F0, we need to configure alternate function for USB module
on STM32F373. Adds the pin configuration for ryu_p2 and also adds the
proper configuration step in USB module.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With changes to enable USB on ryu_p2, see the device enumerated
Change-Id: I5e2cb7cfc44a1bb88bae69804021c783c8d17968
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224789
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new build target ryu_p2 is mostly based on ryu. On ryu_p2, we have a
new EC chip with bigger flash, so make the corresponding changes:
- Pinout changes
- HW Timer: TIM5
- USB PD Tx Timer: TIM3_CH4
- USB PD Rx Timer: TIM2_CH4
- Use UART2 for EC console
- Disable UART Tx DMA as it conflicts with USB PD Tx DMA
- Use 24MHz HSE x2 = 48MHz for SYSCLK
BRANCH=None
BUG=chrome-os-partner:32660
TEST=Sanity check on a new board:
- i2cscan
- PD negotiation
- UART console
- gettime
Change-Id: I4ef6b53a928a2777721e3874032aeb0e6b2b4c92
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221404
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds the DMA channel definition for UART2 and allows selection of
DMA channel for UART.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With the CLs to enable the new Ryu boards, check the console is
working.
Change-Id: I964c284899777dda67c264e622aea6aba752ea76
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224176
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Seems like we were setting outputs too early during boot, sometimes causing a
power leak. SPI should only turn on power levels more active than S3, not on the
S5->S3 transition.
BUG=chrome-os-partner:32824
BRANCH=None
TEST=Pinky powers on, Scope VCC33_PMUIO and VCC33_IO, note that they're smooth
Change-Id: I05c3622d124c2539222b883b895bc9092c5f0b12
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224508
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We already have interrupt handlers for channel 4 to 7. We need channel 3
for the new Ryu boards. Add the handlers for channel 1 to 3. Also,
instead of copy-pasting interrupt handlers, define a macro and declare
interrupt handlers with it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Check PD communication on the new Ryu board (with other CLs to
enable the new boards.)
Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224175
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
So far, we always use channel 1 of the Tx timer and the configuration
code is hard coded. We need to support other channels for new Ryu
boards. Let's make this a configurable bit.
BRANCH=samus
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Plug in Zinger to Ryu and see 20V come up.
Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223836
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The valid and writable flags the EC sends back to the AP are incorrect.
They are a little bit different on differnt chips, so let's move it to
flash physical layer. This is not any causing problem, but we should fix
this.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222661
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On STM32F0, we cannot work around the hard fault triggered when trying
to protect the whole flash. Therefore, we need to go with the
ALL_AT_BOOT approach. When write protect is enabled, instead of setting
ALL_NOW flag to immediately lock down the entire flash, we need to set
ALL_AT_BOOT and then reboot to have the protection take effect.
BUG=chrome-os-partner:32745
TEST=Along with the next CL. On Ryu:
1. Enable HW WP. Check the output of 'ectool flashprotect' and see
correct flags.
2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set.
3. Reboot EC and check RO_NOW is enabled.
4. Boot the system and check ALL_NOW is set.
5. Update BIOS and reboot. Check software sync updates EC-RW.
6. 'flashrom -p ec --wp-disable' and check it fails.
7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared.
8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared.
TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set
properly.
BRANCH=samus
Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a preparatory work for the following change for write protection
support on STM32F0.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ic4deea06e26c4a6ac024a5388e1a5783b40e9876
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove the meaningless version string in iSerialNumber, which was incorrect
since this string should be unique to a device if it exists.
Export the firmware version string as the configuration string, so it's
traceable to a given firmware build/sources.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
from a workstation, do "sudo lsusb -v" and see the full version string
exported as the configuration name.
Change-Id: I557df2936421e2926ac0fc0003888370cec3e201
Reviewed-on: https://chromium-review.googlesource.com/222877
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The BOS (Binary Device Object Store) descriptor was added to the USB
specification (3.0) to allow a richer set of device capability
specific descriptors.
The Billboard class is meant to expose (read-only) the status of USB
devices capable of alternate mode functions. It's required to use the
BOS descriptor type and at a high level looks like:
- BOS Device Descriptor (5bytes)
- Container ID Device Capability Descriptor (20bytes)
- Billboard Device Capability Descriptor (44byte + 4 * numSVIDs)
This CL adds:
1. Ability for Get Descriptor on BOS descriptors. Note hidden behind
CONFIG_USB_BOS as these descriptors change USB device requirements
to:
- bcdUSB >= 0201
- no interface descriptors
2. structures for all BOS, Container & Billboard descriptor elements
complete w/ CamelCase.
BRANCH=none
BUG=chrome-os-partner:32652
TEST=compiles with CONFIG_USB & CONFIG_USB_BOS enabled.
Change-Id: I1b24bc728f2ebba7d91840801d2ebe576e240e7c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221570
When a control transfer requests a descriptor larger than 64 bytes, we
need to do several IN transfers to get the proper packet sequence :
SETUP IN IN IN .. IN OUT(null)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32652
TEST=set USB_STR_VERSION to "012345678901234567890123456789ABCDEF",
then do "lsusb -v" on the host and check the USB transfers
with the protocol analyzer.
Change-Id: I6940095008cb2a34c6896b337c5eda4fa267adc1
Reviewed-on: https://chromium-review.googlesource.com/222700
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Fix bug that can cause ADC initialization to hang and eventually
watchdog. Problem was that you need at least 4 ADC clock cycles
between end of ADC calibration and enabling ADC (setting ADEN).
Fix is to (1) move some ADC configuration to between end of cal
and setting ADEN, and then just to be safe, (2) continually set
ADEN until we see ADRDY (ADC ready).
See bug report for more information.
BUG=chrome-os-partner:32561
BRANCH=samus
TEST=load onto a samus that regularly has ADC problems on boot.
Using power+refresh verify that without this change PD hangs
some of the time, and with this change it never hangs.
Change-Id: Ifa4c3240ad7e1612647cc74e2105e6545ed19db4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221984
Reviewed-by: Vic Yang <victoryang@chromium.org>
This mostly reuses chip drivers for STM32F and STM32F0. Since this chip
doesn't fit either STM32F or STM32F0, let's use symlink to specify which
drivers to use for STM32F3.
This is just the preparatory work and it's not verified on a chip yet.
BUG=chrome-os-partner:32660
TEST=make buildall to make sure this doesn't break anything
BRANCH=None
Change-Id: I709ed49265e8f84552251a97d03b9b98496de99e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221412
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Correct frequency + duty cycle register calculations according to
datasheet.
BUG=chrome-os-partner:32089
TEST=Manual on Samus. Set 50% duty cycle and probe on scope, verify that
duty cycle is actually 50% and frequency is exactly 100 Hz.
BRANCH=samus.
Change-Id: I1e2c0bb7e53110367c38987b369fbef44af90a7d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Minimuffin is identical to zinger, same MCU, same gpio, same
circuitry aroundt the MCU with two differences:
- Rated current is 2.25A instead of 3A
- USB PD hardware device ID needs to be different so that host
can differentiate between the two.
Due to the similarity between the two, minimuffin is defined
as a symlink to the zinger board.
BUG=none
BRANCH=samus
TEST=make BOARD=minimuffin
load onto a zinger and verify that samus reads device ID correctly
and limits input current limit to 2.25mA.
Change-Id: Ie39ec43262c7d14663eb68abff073bfeec451a24
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220689
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Silego variant in pinky rev2 require the signal to be inverted.
BUG=None
TEST=on pinky-rev2: all keys from col2 work correctly
BRANCH=None
Change-Id: I83a029b4e9c6b4770e83f30b170595d45ea40cca
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/220314
Enabled deep sleeping during S0. This was previously inhibited by
SLEEP_MASK_AP_RUN but the new config option (CONFIG_LOW_POWER_S0) will ignore it.
SPI needed a sleep mask, it essentially gets enabled and disabled whenever the
CS changes. Warning: waking up when the CS falls takes a little time, if the AP
sends fast data before the 48MHz clock is enabled characters will get corrupted;
leave about 30uS time for the clock to start.
CQ-DEPEND=CL:219997
CQ-DEPEND=CL:220243
CQ-DEPEND=CL:220461
BUG=chrome-os-partner:32223
BRANCH=none
TEST=load onto pinky, boot the AP(S0), use idlestats command to verify
that we are going into deep sleep (STOP mode). Verify that everything works
normally during S0(SPI, keyboard, anything that requires the EC to wakeup).
Change-Id: I81c4fa472332f1ad8ad93301089a99dcdb108948
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219555
Reviewed-by: Alec Berg <alecaberg@chromium.org>
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>
