HI Aleksander, Thomas, On Thu, 14 Oct 2021 at 12:04, Aleksander Morgado <aleksander@xxxxxxxxxxxxx> wrote: > > Hey Thomas, > > > > > Otherwise, when responses are received, we also can observe strange > > > > things: unexpected messages, response to previous commands or queue > > > > buffer issue. > > > > > > > > > > Are you testing this with qmicli + mbimcli + ModemManager? And if so, > > > are you running the qmicli/mbimcli commands with the "-p" option in > > > order to always use the intermediate qmi-proxy/mbim-proxy? I'd > > > suggest > > > to always do that to avoid having multiple processes talking to the > > > ports at the same time. > > > > > > > In first, I'm testing with qmicli/mbimcli commands with the "-p" option > > in order to always use the intermediate qmi-proxy/mbim-proxy that that > > I run in debug mode beforehand. > > > > Ah, nice, that helps to clarify. When using the proxies, there should > be always one single process accessing the ports. > > > > > > > > I updated the topic opened on the Sierra Wireless forum, with our > > > > latest progress and as well as additional information. > > > > > > > > In addition, we observed some strange behavior of the EM919x after > > > > warm > > > > reboots. > > > > > > > > > > Is the log after the warm reboots similar to the one I showed in my > > > first email, i.e. with the 2 reported "firmware crashes"? Or does it > > > look totally different? > > > > After warm reboots, we observe no explain message indicating an error, > > but we use an old firmware version. > > > > Ok. > > > > And, do you always see the module booting properly on cold boots? Or > > > do you see failed boots like the one i showed in my first email? > > > > The module doesn't always booting properly, you see failed boots like > > the one you showed. > > This is good, because it confirms that our fully different platforms > running the same kernel driver show the same symptoms. So it shouldn't > be an issue of the platform, it's likely either the driver or the > module firmware. So it looks like the device is not in the state expected by MHI core, not sure however if it's a bad interpretation of MHI implementation or a specific issue in that firmware. Maybe one thing you could try is to call mhi_soc_reset(); msleep(1000); just after mhi_register_controller() in pci_generic probe() function... it is supposed to hard reset the modem CPU, and maybe getting it in better shape? Regards, Loic
