| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
When enumerating USB 3.x devices, an extra 6-byte SuperSpeed
companion descriptor follows each standard endpoint descriptor.
The loop parsing the descriptors will stumble if they're not
handled. Since they're not needed once the bulk endpoints are
identified, we can simply skip over them.
Change-Id: I7e73bcf9135f23c3059cd7c55b432557b28cb6ef
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For Linux, the USB code was only looking at the first
descriptor when searching for the fastboot interface
which caused some devices to not be found.
Also clarify some code by using the actual USB structures
instead of void or char pointers.
Change-Id: I9e4871c4d477ac10ba75bb17a955f176809af289
Signed-off-by: Patrick Tjin <pattjin@google.com>
|
| |
|
|
|
|
|
|
|
| |
- Deal with a missing initializer issue
- Deal with some -Wunused issues
- Deal with some signed/unsigned issues
- switch to usleep from sleep to facilitate win_sdk compile
Change-Id: I64e32a5b0782aeed9582f489e866173c4df1afbf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Linux only for now) With fastboot reading serial numbers from sysfs, it had
become possible for a fastboot command issued immediately after rebooting
the bootloader to fail, because sysfs still thought the device was online.
To prevent this, after reboot-bootloader we wait for the device to disconnect.
Also made usb_read and usb_write fail immediately if the descriptor has been
closed; this prevents an incorrect error message ("Bad file descriptor")
when errors from fb_getvar are ignored (e.g., by fb_format_supported).
Also removed unused fd param from filter_usb_device, and simplified logic
in usb_write by using do/while instead of a special case for len == 0.
Change-Id: I799b857eab411fd8ad25f5777fc61c685152ea86
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of sending control requests to all devices to read their serial
numbers, read the cached strings from sysfs. This fixes two problems:
1) The control requests sometimes timed out, causing devices to show up
as "????????????????", and 2) a control request could mess up devices
which were in the middle of being flashed.
Also enumerate by walking sysfs rather than devs so that we can avoid
opening host controller devices, which can be slow. On a system with 10
EHCI controllers, fastboot devices now takes 7 msec instead of 700 msec.
Change-Id: I2ad2d58b48268d7950bd279fd6a6753dc2f79514
|
| |\
| |
| |
| | |
Change-Id: I631e466fc53e9b0f4a39f24f959b4ae9b626bdda
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For manufacturing and testing, there is a need to talk to
whatever device is connected to a given port on the host. This
change modifies fastboot's "-s" option to take either a serial
number or a device path. The device paths of the connected
devices can be listed using "fastboot -l devices" whose output
will resemble:
016B75D60A00600D usb:2-5 fastboot
AD3C12020173 usb:1-4.3 fastboot
The second column lists the device paths. If the -l option is
not given, the output from "fastboot devices" will be the same as
it used to be (i.e. the paths will not be printed).
Finally, note that the format of the device paths are platform
dependent. The example above is from Linux. On OS-X, the paths
will be "usb:" followed by hex digits. For Windows, the device
paths will be printed as "????????????" and the -s option will
not be able to select a device until someone implements the
underlying functionality in usb_windows.c.
Change-Id: I1f01b8f47acd32edb0ac18db107316a2c923bbde
Signed-off-by: Scott Anderson <saa@android.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some devices will fail to return the requested data if the final
URB len of the request to > 255.
So shrink the current data buffer from 128 to 127 in the acse of getting
the serial number seems to work just fine.
Change-Id: Ic24e6c86ec93f002dc721d92309b3f880f281f20
|
| | |
| |
| |
| | |
Change-Id: I6f83333a6ee0fbc562a12bb9555c43a44c98768e
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Set the language local string to 0x409 (English US / en-us) such that
fastboot will successfully read the usb descriptor serial number string.
The usbdevfs ioctl fails when the wIndex is not initialized with the
local for the unicode of the usb descriptor string. usbdevfs is an
obsolete interface and fastboot probably needs a re-write to use libusb
like what is in adb.
Change-Id: I3687f84643f53c736f14b3ae7793185d9b5cccc0
Signed-off-by: Mark D Horn <mark.d.horn@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default USB transfer bulk is fixed as 4096 in fastboot util code for
Windows and Linux. Enlarging the bulk size can greatly improve the image
download speed via USB.
For Windows, adjust the max bulk size to 1MB to maximize the USB transfer
speed. With this change, the USB transfer speed can be doubled to 20MB/s.
For Linux, adjust the max bulk size to 16384 to maximize the USB transfer
speed according to MAX_USBFS_BUFFER_SIZE definition in drivers/usb/core/devio.c.
For OSX, the maxLenToSend is already 1MB in code.
Change-Id: If6af8c6301f6f6c2ef345e37241706f16d8f5cda
|
| |
|
|
|
| |
This attempts to solve the intermittent issues with serial number
showing up as all question marks when issuing "fastboot devices"
|
| |
|
|
| |
We need to reset 'writable' each time round the loop (i.e. for each device).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch, "adb devices" will say "no permissions" when it sees
a device it can't write to, but "fastboot devices" will silently ignore it.
This is confusing to n00bs, especially since it doesn't seem to be widely
known that a device's USB id might be different in the bootloader (meaning
two udev rules are needed). It can also be confusing if you're sshed in,
when you can't access the device because you won't be in the "plugdev"
group, but "fastboot devices" won't make this clear.
I'm not sure about the Mac OS and Windows changes. AIUI, devices are always
writable on those platforms, but I don't use either, so I can't test this.
This patch shouldn't alter the behavior on either of those platforms.
|
| |
|
|
|
|
|
|
|
|
|
| |
If the USB connection to the device is reset but is still there
the code should retry to re-connect the device and continue.
This is a short term fix for a bootloader issue.
We should revisit and look for a better solution.
Signed-off-by: Dan Murphy <D.Murphy@motorola.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
|
| | |
|
| | |
|
| |
|
