QMI service versions in different devices
Bjørn Mork
bjorn at mork.no
Wed Sep 18 05:18:06 PDT 2013
Aleksander Morgado <aleksander at lanedo.com> writes:
>> eQMI_SVC_WDA, // 026 Wireless data administrative service
BTW, this service is very interesting on devices supporting it. It has
a replacement for the eQMI_CTL_SET_DATA_FORMAT command, along with the
previously missing GET_DATA_FORMAT:
/*=========================================================================*/
// eQMIMessageWDA Enumeration
// QMI Qualcomm Wireless Data Addministrative Message ID Enumeration
/*=========================================================================*/
enum eQMIMessageWDA
{
eQMI_WDA_ENUM_BEGIN = -1,
eQMI_WDA_GET_MESSAGES = 30, // 30 Get supported messages
eQMI_WDA_GET_FIELDS, // 31 Get supported fields
eQMI_WDA_SET_DATA_FORMAT, // 32
eQMI_WDA_GET_DATA_FORMAT, // 33
eQMI_WDA_ENABLE_PKT_FILTER, // 34
eQMI_WDA_DISABLE_PKT_FILTER, // 35
eQMI_WDA_GET_PKT_FILTER_STATE, // 36
eQMI_WDA_ADD_PKT_FILTER_RULE, // 37
eQMI_WDA_DELETE_PKT_FILTER_RULE, // 38
eQMI_WDA_GET_PKT_FILTER_RULE_HANDLES, // 39
eQMI_WDA_GET_PKT_FILTER_RULE, // 40
eQMI_WDA_SET_LOOPBACK_STATE, // 41
eQMI_WDA_GET_LOOPBACK_STATE, // 42
eQMI_WDA_ENUM_END
};
I believe eQMI_WDA_SET_DATA_FORMAT should be used instead of
eQMI_CTL_SET_DATA_FORMAT when supported. Primarily because the matching
GET command allow you to test whether a change is necessary at all. But
it's also interesting because it allows more fine tuned format settings,
adjusting the aggregation protocol (not that I can think of any reason
why we'd want to change this away from the firmware defaults):
// Enum to describe QMI WDA Data Aggregation Protocols
enum eQMIWDADataAggregationProtocols:UINT32
{
eQMIWDADataAggregationProtocols_TLP = 1,
eQMIWDADataAggregationProtocols_NCM = 2,
eQMIWDADataAggregationProtocols_MBIM = 3,
eQMIWDADataAggregationProtocols_RNDIS = 4,
eQMIWDADataAggregationProtocols_QMAP = 5,
};
// Enum to describe QMI WDA Link Protocols
enum eQMIWDALinkProtocols:UINT32
{
eQMIWDALinkProtocols_Ethernet = 1,
eQMIWDALinkProtocols_IP = 2,
};
You may wonder why we'd want to support something like MBIM frame
aggregation. I don't see any use case, but the real nerds among us can
have some fun playing with it using the QMI-inside-MBIM service on
e.g. a MC7710 :-)
Note that I am unable to get any WDA CID allocated when this device is
in MBIM mode - I assume there is only one available and that it is used
internally by the firmware. But cheating and stealing CID #1 without
allocating it works...
Here's the MC7710 reply to a eQMI_WDA_GET_DATA_FORMAT command in MBIM
mode:
03 00 00 80 72 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 d1 a3 0b c2 f9 7a 6e 43 bf 65 c7 e2 4f b0 f0 d3 01 00 00 00 00 00 00 00 42 00 00 00 01 41 00 80 1a 01 02 01 00 21 00 35 00 02 04 00 00 00 00 00 10 01 00 00 11 04 00 02 00 00 00 12 04 00 03 00 00 00 13 04 00 03 00 00 00 14 04 00 49 50 53 00 15 04 00 00 00 00 00 16 04 00 00 00 00 00
---
MBIM_MESSAGE_HEADER
MessageType: 0x80000003 (MBIM_COMMAND_DONE)
MessageLength: 114
TransactionId: 1
MBIM_FRAGMENT_HEADER
TotalFragments: 0x00000001
CurrentFragment: 0x00000000
EXT_QMUX (d1a30bc2-f97a-6e43-bf65-c7e24fb0f0d3)
MBIM_CID_QMI (1)
MBIM_STATUS_SUCCESS (0)
InformationBuffer [66]:
(decoded as QMUX):
QMI frame #0
>>>>>> QMUX:
>>>>>> length = 65
>>>>>> flags = 0x80
>>>>>> service = "(null)"
>>>>>> client = 1
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 53
>>>>>> message = (0x0021)
>>>>>> TLV:
>>>>>> type = 0x02
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x10
>>>>>> length = 1
>>>>>> value = 00
>>>>>> TLV:
>>>>>> type = 0x11
>>>>>> length = 4
>>>>>> value = 02:00:00:00
>>>>>> TLV:
>>>>>> type = 0x12
>>>>>> length = 4
>>>>>> value = 03:00:00:00
>>>>>> TLV:
>>>>>> type = 0x13
>>>>>> length = 4
>>>>>> value = 03:00:00:00
>>>>>> TLV:
>>>>>> type = 0x14
>>>>>> length = 4
>>>>>> value = 49:50:53:00
>>>>>> TLV:
>>>>>> type = 0x15
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x16
>>>>>> length = 4
>>>>>> value = 00:00:00:00
Sending the same command after changing from MBIM configuration to QMI
configuration results in:
QMI frame #1
>>>>>> QMUX:
>>>>>> length = 65
>>>>>> flags = 0x80
>>>>>> service = "(null)"
>>>>>> client = 1
>>>>>> QMI:
>>>>>> flags = "response"
>>>>>> transaction = 1
>>>>>> tlv_length = 53
>>>>>> message = (0x0021)
>>>>>> TLV:
>>>>>> type = 0x02
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x10
>>>>>> length = 1
>>>>>> value = 00
>>>>>> TLV:
>>>>>> type = 0x11
>>>>>> length = 4
>>>>>> value = 01:00:00:00
>>>>>> TLV:
>>>>>> type = 0x12
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x13
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x14
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x15
>>>>>> length = 4
>>>>>> value = 00:00:00:00
>>>>>> TLV:
>>>>>> type = 0x16
>>>>>> length = 4
>>>>>> value = 00:00:00:00
As you can see, TLV 0x11 has changed from 2 to 1 so I assume this is the
Link Protocol changing from IP in MBIM mode to Ethernet in QMI mode.
TLVs 0x12 and 0x13 have both changed from 3 to 0. I assume this is
ingress/egress MBIM frame aggregation vs no frame aggregation.
I have no idea what TLVs 0x15 and 0x16 are, but it could be the QoS
header setting we know from the eQMI_CTL_SET_DATA_FORMAT command?
TLV 0x14 is interesting if you have read a bit of MBIM spec: 49:50:53:00
is the 16bit NCM datagram signature for IP session #0 (decode it as
ascii and get "IPS\0"). I wonder if it's possible to change it to
e.g. 49:50:53:01 to test multiple IP sessions, or will the firmware will
go bananas then?
Bjørn
More information about the libqmi-devel
mailing list