Daniele Palmas <dnlplm@xxxxxxxxx> writes:
> Unfortunately the application has a proprietary firmware flashing
> protocol under NDA, so I am not able to share it. I know that I will
> lose points for that...
I was afraid of that.
> I can confirm that it is not a stupid device name assumption, since
> the device name is an argument of the flashing application.
OK, thanks.
> Being the device an "Infineon" device, it would be really interesting
> what developers at Infineon think about that...
I guess you have to do s/Infineon/Intel/ now. Not sure that helps much,
though. The Intel modem division haven't been much more open about
their business than Infineon used to be (or Qualcomm is for that sake -
it looks like a radio modem related disease)
> But I see that Infineon flashing devices in newer chipsets have become
> an only bulk serial link device (see device 0x8087/0x0716 in
> usb-serial-simple), so maybe this has a meaning...
Yes. I have a Sierra Wireless EM7345 modem which is based on the same
chipset. I haven't really paid much attemtion to the flashloader
functionality before, but this is how that modem looks before it loads
its Sierra firmware:
Bus 003 Device 013: ID 8087:0716 Intel Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x8087 Intel Corp.
idProduct 0x0716
bcdDevice 0.00
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 500mA
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0001
Self Powered
There are a couple of oddities in the above lsusb output which I believe
supports the proposed patch: Note the use of a "CDC Data" class
interface for an assumed vendor specific function. There is no
"Communications" interface here. And do note the three unrecognised
descriptors. These are obviously CDC class specific functional
descriptors. You have the
Header: 05 24 00 10 01
Call Management: 05 24 01 00 00
ACM: 04 24 02 02
So this device looks very much like an ACM device, except that it is
missing the necessary control interface and status endpoint. And
without a control interface there is of course no way to send a properly
formatted CDC control request either.
I assume the different vendors also use the same Intel provided firmware
toolkit, making the firmwares share basic functionality like bootloader
and flashing. But the USB descriptors are likely configurable by the
vendor. Telit might have tried to "improve" the above into a proper ACM
device.
I believe this supports the assumption that Infineon Flash Loader
devices have some ACM descriptors without actually being ACM class
devices, and that it is best to just collect them all in the
usb-serial-simple "flashloader" driver.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
