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 <dnl...@gmail.com> wrote:
Hi Koen,
Il giorno ven 12 ago 2022 alle ore 15:26 Koen Vandeputte
<koen.vandepu...@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.vandepu...@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 m...@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
[...]
