Re: RM500Q slow with qmi_wwan, fast with proprietary
I did some testing with this advice and have some results and a couple more questions. Bjørn, I realise now you were talking about cdc-mbim. I checked the values for tx_max and rx_max which are both 16384 by default on my device. I am able to change rx_max to 31744, which seems to improve upload slightly, but I cannot change tx_max (Permission denied, and after changing file permissions I just get an I/O error). Is that value supposed to be user accessible? Is this value tied to dwNtbOutMaxSize? Using cdc-mbim with these settings I get consistently 200Mbps, so my feeling is the bottleneck could be tied to these values, since I’m able to change their counterparts in the QMI driver. Using QMI QMAP it gets much faster than before, about 450Mbps. Another question more ModemManager related; is there a way to set up a connection using user-specified QMAP values like the ones Sebastian provided? >qmicli -p -d /dev/cdc-wdm0 --client-cid=1 >--wda-set-data-format="link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=32,dl-datagram-max-size=32768,ep-type=hsusb,ep-iface-number=4" > --client-no-release-cid Best, Nick > On 11 Aug 2022, at 17:47, Bjørn Mork wrote: > > Nick writes: > >> Hey, >> >> I am testing a Quectel RM500Q on OpenWrt master, and have noticed to >> my surprise that the speed is much slower when using the qmi_wwan with >> MM than it is when using qmi_wwan_q and quectel-CM (Quectel’s >> proprietary driver and connection manager). > > This is sort of expected since the qmi_wwan driver will use one USB > transaction per IP packet whereas the qmi_wwan_q will buffer a number of > packets per transaction. > > There is some built-in support for MAP (RMNET muxing, which implies > buffering) in qmi_wwan. But I recommend using the more recent rmnet > driver for that, with qmi_wwan in pass-throuh mode. This is supported > by recent ModemManager/libqmi. Ref > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/447 > >> Under good signal conditions the speed tops out at around 100Mbps on >> qmi_wwan + MM (and is a little bit faster when in MBIM mode with MM), >> but switching to qmi_wwan_q and quectel_CM it gets the expected >> 700Mbps+ where I am. Is there an easy explanation for this? Any >> suggestions as to what I can change to get speeds equivalent to the >> proprietary stack? > > I'm a little surprised that you don't get better numbers in MBIM mode. > It should have the same advantages as qmi_wwan_q or qmi_wwan+rmnet. I > must admit that I haven't done any seriuos testing of this theory myself > though. But "A little bit faster than 100Mbps" is unexpectedly slow. > I'm pretty sure we can do much better than that in MBIM mode. > > What kind of hardware is the host running? Maybe we have some alignment > issue punishing this hardware? Or maybe the buffers we use are > sub-optimal for thise host+device combo? You could try to adjust some > of the writable settings in /sys/class/net/wwan0/cdc_ncm/ (replace wwan0 > with your interface name) > > > > Bjørn
Re: MHI on 5G modems
Hi Koen,
Il giorno ven 12 ago 2022 alle ore 15:26 Koen Vandeputte
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
> > 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 :01:00.0: BAR 0: assigned [mem
> >> 0x0110-0x01100fff 64bit]
> >> [8.267488] mhi-pci-generic :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) _sierra_em919x_info },
> /* Telit FN980 hardware revision v1 */
> { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D, 0x2000),
> .driver_data = (kernel_ulong_t)
> _telit_fn980_hw_v1_info },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
> .driver_data = (kernel_ulong_t) _qcom_sdx55_info },
> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
> .driver_data = (kernel_ulong_t) _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 :01:00.0: MHI PCI device found:
> qcom-sdx55m
> [ 10.513847] mhi-pci-generic :01:00.0: BAR 0: assigned [mem
> 0x0110-0x01100fff 64bit]
> [ 10.522357] mhi-pci-generic :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
> [ 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
Re: MHI on 5G modems
On 12.08.22 10:55, Daniele Palmas wrote:
Hi Koen,
Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte
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 :01:00.0: BAR 0: assigned [mem
0x0110-0x01100fff 64bit]
[8.267488] mhi-pci-generic :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) _sierra_em919x_info },
/* Telit FN980 hardware revision v1 */
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0306, 0x1C5D, 0x2000),
.driver_data = (kernel_ulong_t)
_telit_fn980_hw_v1_info },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0306),
.driver_data = (kernel_ulong_t) _qcom_sdx55_info },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304),
.driver_data = (kernel_ulong_t) _qcom_sdx24_info },
01:00.0 Unassigned class [ff00]: Qualcomm Device 0306
Subsystem: Device 18d7:0200
hmz ..
Here are the logs:
[ 10.506776] mhi-pci-generic :01:00.0: MHI PCI device found:
qcom-sdx55m
[ 10.513847] mhi-pci-generic :01:00.0: BAR 0: assigned [mem
0x0110-0x01100fff 64bit]
[ 10.522357] mhi-pci-generic :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
[ 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
receive_len: 0
[ 132.007123] mhi_wwan_ctrl mhi0_QMI: mhi_dl_xfer_cb: status: -107
receive_len: 0
[ 132.014565] mhi_wwan_ctrl mhi0_QMI: mhi_dl_xfer_cb: status: -107
receive_len: 0
[ 132.021911] mhi_wwan_ctrl mhi0_QMI: 15: successfully reset
[ 132.027439] mhi_wwan_ctrl mhi0_QMI: 14: Updating channel state to: RESET
[ 132.039934] mhi_wwan_ctrl
Re: OpenWRT 22.03-rc6 / ModemManager not on 1.18.8 Version with the Dispatcher support
On Thu, Aug 11, 2022 at 2:30 PM Peter Naulls wrote: > > On 8/11/22 08:25, Aleksander Morgado wrote: > I was writing mostly the same response myself :) > > > > But wondering, are there any nightly builds from the master branch or > > similar for that specific architecture? Maybe there is already an > > existing .ipk for the MM version in master that could be installed in > > the 22.03 system. The MM deps will be the same at least. > > > > Probably, but it might be with a new toolchain/C library, so you end > up with runtime linker errors. Yeah, you're right. -- Aleksander
Re: MHI on 5G modems
Hi Koen, Il giorno gio 11 ago 2022 alle ore 15:24 Koen Vandeputte 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 :01:00.0: BAR 0: assigned [mem > 0x0110-0x01100fff 64bit] > [8.267488] mhi-pci-generic :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 > > > Thanks! > > Koen >
