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>
A change to the toolchain or environment surfaced an issue where the writes to
packet RAM were being split into two 16-bit writes. This was interacting
poorly with the AHB2APB bridge.
Marking the packet RAM destination pointer volatile forces the compiler to use
full 32-bit writes.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Check that Ryu's console is accessible over USB
Change-Id: I0c3db08c704389a627570b90ef97bce81ab553fa
Reviewed-on: https://chromium-review.googlesource.com/248840
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
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>
A non-zero error code returned by the callback causes EP0 to STALL.
This is the common mechanism used in USB to indicate an error while
processing a control request. This simplifies the implementation
of interface callbacks.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I89ceb4892f9f810fcaf6e975e6982fc5b2ae447b
Reviewed-on: https://chromium-review.googlesource.com/232368
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For USB console, we wait for USB host to grab the data before writing
the next chunk of characters. However, if the USB peripheral is
disabled, the current implementation is confused as to whether the host
has grabbed the previous chunk of data.
Fix this by explicitly checking for USB peripheral enabled.
BRANCH=ryu
BUG=None
TEST=Boot on Ryu and check console isn't slow.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I438c95835e56707b7ca1796734f2e47062799f44
Reviewed-on: https://chromium-review.googlesource.com/231115
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously enabling USB would automatically (using an
init hook) initialize the USB peripheral. This would
take over the GPIO lines assigned to the USB module.
This is not OK on Ryu for Case Closed Debug because it
interferes with the AP's access to the USB 2.0 lines
even when not in Case Close Debug mode.
This change adds a configuration option to inhibit this
default initialization of the USB peripheral. It also
renames the existing CONFIG_USB_INHIBIT to
CONFIG_USB_INHIBIT_CONNECT now that there are two
possible inhibitions.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable console on ryu_p2 and discovery-stm32f072 board
Verify that it works on both
Change-Id: I6734357131b4356e3d4164349d6c74deac196ce5
Reviewed-on: https://chromium-review.googlesource.com/229138
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Previously the usb driver used #ifs to select a mechanism to
enable and disable the DP pullup. This doesn't scale well,
especially when the knowledge of how to do this is not known
to the chip specific code, but instead is board specific (as
it is with the STM32F373).
This change uses the build systems ability to build chip family
specific files per build to select the appropriate behavior.
And on the STM32F3 family of parts it just calls out to a board
specific pair of connect/disconnect functions.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable console on ryu_p2 and discovery-stm32f072 board
Verify that it works on both
Change-Id: I976e02fbc7acbb0f85817d7295b26ee9ecab0711
Reviewed-on: https://chromium-review.googlesource.com/229040
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
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>
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>
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>
for interface specific requests, the interface number is equivalent to
(wIndex & 0xff). this corresponds to ep0_buf_rx[2], since the setup
packet has format: bmRequestType (1), bRequest (1), wValue (2),
wIndex (2), wLength (2).
BUG=none
BRANCH=none
TEST=verify stm32 does not panic with multiple interfaces
Change-Id: Ied7750035f87fa81f9a6c03c6e73ae606c110398
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209903
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
