I am trying to add the QMI support to FreeBSD, but having trouble.
To begin, I sent QMI_DMS_GET_DEVICE_MFR wrapped in CDC over endpoint 0 of QMI interface (8 for MC7354) as below
usb device request
RequestType = UT_WRITE_CLASS_INTERFACE (0x21)
Request = CDC_SEND_ENCAPSULATED_COMMAND (0x00)
value = 0x00
Index = 0x08
length = 0x0d
followed by byte string of
01:0c:00:00:02:01:00:01:00:21:00:00:00
I am expecting some response from h/w, but there is not any response, not even an error message.
When the h/w is powered on, the driver receives following byte string
01:0b:00:08:00:00:02:00:27:00:00:00
(receives CDC_N_RESPONSE_AVAILABLE, then fetch the byte string with CDC_GET_ENCAPSULATED_RESPONSE) So, I believe usb transfer part is working properly.
The message looks fine to me, but where did you get the DMS client ID from if this is the first message you send?
A client ID is required for all QMI subsystems except CTL. This has to be allocated using a CTL “Allocate CID” request. You seem to be using DMS client ID #1 without having allocated it. The normal response to that will be complete silence.
For a simple start testing basic QMI transport, I’d recommend using the CTL “Get Version Info” request. This should always work for all QMI devices.
Yes, that is normal and indicates that the transfer is indeed working. The message is a CTL “Sync” indication, which QMI devices seem to send when booting. The exact meaning is unknown to me as the docs are not public, but I’m guessing that it’s just informing the host about the device reboot. Saying somthing like “all state has been reset”.
Sending a CTL “Sync” request to the device will have pretty much the same effect: It resets all state.
Actually, can you tell me what documents tell about CTL service, so I can ask Sierra’s liaison for the document? I went though all the documents I have received, and I can find the details of different types of services but of CTL.
The CTL support is the main difference between the GobiNet driver which Sierra documents and the qmi_wwan driver. The GobiNet driver handles all the necessary CTL in the driver, so the SDK does not have to care. The driver provides a pair of ioctls for allocating and releasing CIDs, but it does not provide any generic access to the CTL subsystem. So there is no need for Sierra to provide any documentation for it. But they are probably documenting some way to call the ioctls? Or maybe that’s implicit when you access a new subsystem?
Qualcomm has documented the CTL system of course. Their document number is 80-VB816-3, titled “QMI Control Service (QMI_CTL)”. But that’s all I know about that. My request for a copy was politely denied
So for now, all the CTL documentation we have is what we can scrape from the GobiNet driver and the CodeAurora project. You can find some docs, in the form of headers and code, inside the open source GobiAPI: codeaurora.org/patches/quic … 347.tar.gz
But I guess that one of the first things you should decide for a new FreeBSD driver is whether to make the userspace API compatible to GobiNet or qmi_wwan. Or both? Or something completely different?
