MHI on 5G modems
Koen Vandeputte
koen.vandeputte at citymesh.com
Tue Aug 16 08:43:52 UTC 2022
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!
>>> [ 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