MHI on 5G modems
Koen Vandeputte
koen.vandeputte at citymesh.com
Tue Aug 16 13:00:38 UTC 2022
On 16.08.22 10:43, Koen Vandeputte wrote:
>
> On 13.08.22 11:06, Loic Poulain wrote:
>> Hi Koen, Daniele,
>>
>> On Fri, 12 Aug 2022 at 16:16, Daniele Palmas <dnlplm at gmail.com> wrote:
>>> Hi Koen,
>>>
>>> Il giorno ven 12 ago 2022 alle ore 15:26 Koen Vandeputte
>>> <koen.vandeputte at citymesh.com> ha scritto:
>>>>
>>>> On 12.08.22 10:55, Daniele Palmas wrote:
>>>>> Hi Koen,
>>>>>
>>>>> Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte
>>>>> <koen.vandeputte at citymesh.com> ha scritto:
>>>>>> Hi All,
>>>>>>
>>>>>> I'm currently working on adding MHI support within OpenWRT.
>>>>>> (kernel 5.15.59)
>>>>>>
>>>>>> I have a few modems laying around here:
>>>>>>
>>>>>> - Sierra Wireless EM9191
>>>>>> - Telit FN980
>>>>>> - Fibocom FM150-AE
>>>>>>
>>>>>> On all 3 of them, MHI seems to enumerate correctly:
>>>>>>
>>>>>> [ 8.258921] mhi-pci-generic 0000:01:00.0: BAR 0: assigned [mem
>>>>>> 0x01100000-0x01100fff 64bit]
>>>>>> [ 8.267488] mhi-pci-generic 0000:01:00.0: enabling device
>>>>>> (0140 -> 0142)
>>>>>> [ 8.276817] mhi mhi0: Requested to power ON
>>>>>> [ 8.288905] mhi mhi0: Power on setup success
>>>>>> [ 8.341370] mhi mhi0: Wait for device to enter SBL or Mission
>>>>>> mode
>>>>>>
>>>>>> Exposed devices:
>>>>>>
>>>>>> /dev/wwan0mbim0
>>>>>> /dev/wwan0qcdm0
>>>>>> /dev/wwan0qmi0
>>>>>>
>>>>>> And a network device:
>>>>>>
>>>>>> mhi_hwip0
>>>>>>
>>>>>>
>>>>>> Following kernel SYMS are enabled:
>>>>>>
>>>>>> CONFIG_MHI_BUS=m
>>>>>> CONFIG_MHI_BUS_DEBUG=y
>>>>>> CONFIG_MHI_BUS_PCI_GENERIC=m
>>>>>> CONFIG_MHI_NET=m
>>>>>> CONFIG_MHI_WWAN_CTRL=m
>>>>>> CONFIG_MHI_WWAN_MBIM=m
>>>>>> CONFIG_WWAN=m
>>>>>>
>>>>>>
>>>>>> Now the problem is, when sending QMI traffic towards wwan0qmi0, I
>>>>>> never
>>>>>> get a reply back on any of them.
>>>>>> When using cdc-wdm or when wwan0qmi0 is exposed over usb, it works,
>>>>>> but as soon as wwan0qmi0 is exposed over pcie, it fails.
>>>>>>
>>>>>> Does anyone have any clue what is missing here?
>>>>>>
>>>>> I suggest you enable dynamic debugging on mhi and wwan to get more
>>>>> information about what's going on.
>>>>>
>>>>> My experience is that some hosts have issues with runtime power
>>>>> management (e.g. the modem is not able to exit M3) and the symptoms
>>>>> seem to be the same as the ones you describe.
>>>>>
>>>>> Regards,
>>>>> Daniele
>>>> Hi Daniele,
>>>>
>>>> Thanks for the reply.
>>>> Well .. this is interesting. Looks like my EM919x is always
>>>> detected as
>>>> a generic "qcom sdx55"
>>>>
>>>> All looks well-defined within mhi/pci-generic.c and lspci -v
>>>> reports the
>>>> proper ID's:
>>>>
>>>>
>>>> static const struct pci_device_id mhi_pci_id_table[] = {
>>>> /* EM919x (sdx55), use the same vid:pid as qcom-sdx55m */
>>>> { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x18d7,
>>>> 0x0200),
>>>> .driver_data = (kernel_ulong_t)
>>>> &mhi_sierra_em919x_info },
>>>> /* Telit FN980 hardware revision v1 */
>>>> { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D,
>>>> 0x2000),
>>>> .driver_data = (kernel_ulong_t)
>>>> &mhi_telit_fn980_hw_v1_info },
>>>> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
>>>> .driver_data = (kernel_ulong_t)
>>>> &mhi_qcom_sdx55_info },
>>>> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
>>>> .driver_data = (kernel_ulong_t)
>>>> &mhi_qcom_sdx24_info },
>>>>
>>>>
>>>> 01:00.0 Unassigned class [ff00]: Qualcomm Device 0306
>>>> Subsystem: Device 18d7:0200
>>>>
>>>>
>>>> hmz ..
>>>>
>>> Yeah, that's odd.
>>>
>>>>
>>>> Here are the logs:
>>>>
>>>>
>>>> [ 10.506776] mhi-pci-generic 0000:01:00.0: MHI PCI device found:
>>>> qcom-sdx55m
>>>> [ 10.513847] mhi-pci-generic 0000:01:00.0: BAR 0: assigned [mem
>>>> 0x01100000-0x01100fff 64bit]
>>>> [ 10.522357] mhi-pci-generic 0000:01:00.0: enabling device (0140
>>>> -> 0142)
>>>> [ 10.532198] mhi mhi0: Requested to power ON
>>>> [ 10.536490] mhi mhi0: Attempting power on with EE: PASS THROUGH,
>>>> state: RESET
>>>> [ 10.547145] mhi mhi0: Power on setup success
>>>> [ 10.547293] mhi mhi0: Handling state transition: PBL
>>>> [ 10.556541] mhi mhi0: Device in READY State
>>>> [ 10.560738] mhi mhi0: Initializing MHI registers
>>>> [ 10.565457] mhi mhi0: Wait for device to enter SBL or Mission mode
>>>> [ 10.633687] mhi mhi0: local ee: MISSION MODE state: READY device
>>>> ee:
>>>> MISSION MODE state: READY
>>>> [ 10.657015] mhi mhi0: State change event to state: M0
>>>> [ 10.662281] mhi mhi0: Received EE event: MISSION MODE
>>>> [ 10.667577] mhi mhi0: Handling state transition: MISSION MODE
>>>> [ 10.673524] mhi mhi0: Processing Mission Mode transition
>>>> [ 10.684850] mhi_net mhi0_IP_HW0: 100: Updating channel state to:
>>>> START
>>>> [ 10.707859] mhi_net mhi0_IP_HW0: 100: Channel state change to START
>>>> successful
>>>> [ 10.715374] mhi_net mhi0_IP_HW0: 101: Updating channel state to:
>>>> START
>>>> [ 10.737501] mhi_net mhi0_IP_HW0: 101: Channel state change to START
>>>> successful
>>>>
>>>> // start talking QMI to wwan0qmi0
>>>>
>>>> [ 131.173212] mhi_wwan_ctrl mhi0_QMI: 14: Updating channel state
>>>> to: START
>>>> [ 131.187781] mhi_wwan_ctrl mhi0_QMI: 14: Channel state change to
>>>> START
>>>> successful
>>>> [ 131.195303] mhi_wwan_ctrl mhi0_QMI: 15: Updating channel state
>>>> to: START
>>>> [ 131.207145] mhi_wwan_ctrl mhi0_QMI: 15: Channel state change to
>>>> START
>>>> successful
>> The below line is suspicious, it looks like MHI channels are closed
>> just after being started (successfully), could it be that user side
>> program closes the file descriptor? what program/daemon are you
>> running to talk over the QMI character device? The device should stay
>> open as long as your 'session' is running.
>>
>> I would suggest to CC mhi at lists.linux.dev .
>
> Hi Loic,
>
> Thanks for joining in.
>
> You are right: the flow is following:
>
> - Open a file descriptor
> - Send the simplest possible qmi command (client_sync or get_imei,
> tried both)
> - Check for reply and close fd if no reply received. (If a valid reply
> is received, the FD stays open forever until app closure)
>
>
> The code used is an internally made C variant of uqmi which are a few
> source files which is included in our main application.
> This code has been working for a few years now and works nicely on all
> usb-flavor QMI interfaces (cdc-wdm..)
> I also get the same behaviour using uqmi itself.
>
> Other libs/executables like libqmi and/or modemmanager are not useful
> due to the size and dependencies (we run on low-spec embedded hardware)
>
> Am I correct that the qmi protocol should be identical between usb and
> pcie interfaces?
>
> The kernel in use is pretty simple (openwrt based)
> - plain 5.15.59 + backport of the em919x patch (which is a fairly
> simple patch)
>
> If required i'm more than happy to file an issue on the mailinglist.
>
>
> Any idea also why the modem does not get properly detected even while
> all PCIe ID's are present? (see above logs)
> I tried by adding it on top and bottom if the table within pci-generic.c
>
> All MHI source gets loaded as modules also to give enough time for the
> modem to boot.
>
> All power management is also disabled on the host board to avoid the
> dreadful "Registers Hidden" issue.
>
> Thanks!
Last addendum:
I got it working by switching to a Telit FN980 (v1.0)
This one also gets detected as a generic sdx55 tough ..
So it looks like in kernel 5.15, detection of the device does not work
properly.
i'll post this issue to upstream MHI ML for further follow-up.
Thanks
>
>>>> [ 131.966531] mhi_wwan_ctrl mhi0_QMI: 15: Updating channel state
>>>> to: RESET
>>>> [ 131.980574] mhi_wwan_ctrl mhi0_QMI: 15: Channel state change to
>>>> RESET
>>>> successful
>>>> [ 131.988018] mhi mhi0: Marking all events for chan: 15 as stale
>>>> [ 131.993887] mhi mhi0: Finished marking events as stale events
>>>> [ 131.999704] mhi_wwan_ctrl mhi0_QMI: mhi_dl_xfer_cb: status: -107
>> [...]
More information about the ModemManager-devel
mailing list