MHI on 5G modems
Loic Poulain
loic.poulain at linaro.org
Mon Aug 22 07:47:47 UTC 2022
On Tue, 16 Aug 2022 at 15:00, Koen Vandeputte
<koen.vandeputte at citymesh.com> wrote:
>
>
> 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?
Yes, the protocol is the same, which is QMI over QMUX.
> >
> > 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 cannot really comment on this, maybe you can contact the author of
Sierra change.
> > 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 ..
It's usually fine, the FN980 is known to work with generic sdx55.
>
> 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.
Right, do the sub ids also match what is defined in the driver's table?
Regards,
Loic
More information about the ModemManager-devel
mailing list