AT commands to a Sierra Wireless EM9291

tom

@groupo I don't know of a way to get those files back without reflashing.

I just checked and it doesn't seem like there's a newer version available via. apt with the repos currently on there.

You may have to build and install it via. source

groupo

@tom I was just typing a msg up to relay apt isnt showing any of them available for updating. I will try to reflash.

I need to be able to connect to a private LTE network (MCC-MNC 001-01) which, as far as I have read, the EM9291 does not natively search for. I've read you can issue AT commands to tweak how the modem operates but am at a standstill trying to either install drivers to enumerate ttyUSB0 or update qmicli to the newest version so that I can issue AT commands that way. I think reflashing is necessary to get those files back and reestablish some ground truth with my drone. I should be able to go through those directions on my own. After that, are you able to assist me with either of the two avenues I discussed? I am grossly unfamiliar with the platform's architecture, but if I could get you on even a short call I think it would greatly accelerate this process for the two of us.

tom

@groupo I can't provide a ton of help as I haven't tried it myself but you should be able to build and install a newer version of libqmi by following the instructions from here:

https://modemmanager.org/docs/libqmi/building/building-autotools/

In terms of which AT commands are required to send I can't really help there, it may require reading through Sierra's AT command docs

groupo

@tom I am talking to a dev from Sierra Wireless who can help with the AT commands. there are some very useful forum posts there for connecting to 'test' LTE networks. I just need to send the AT commands to do so. I need your assistance in either installing that driver to enumerate the port or updating qmi. I will try to update qmi first, as that seems like the simpler approach. I need libqmi 1.34 which switched from GNU autotools to Meson. That means nothing to me, I will just follow the steps, more FYI

groupo

@tom need Meson to get newest libqmi. Tried installing that but ran into more errors, I hate feeling like I am asking to be spoonfed but I really could use some guided direction here - I am extremely out of my element

tom

@groupo You can install meson and ninja with

sudo apt install meson ninja-build

groupo

@tom I did that successfully, the error came with running the third line below

voxl2:/$ sudo apt install meson ninja-build
Reading package lists... Done
Building dependency tree       
Reading state information... Done
ninja-build is already the newest version (1.8.2-1).
meson is already the newest version (0.45.1-2ubuntu0.18.04.2).
0 upgraded, 0 newly installed, 0 to remove and 37 not upgraded.
voxl2:/$ cd libqmi
voxl2:/libqmi(main)$ meson setup build --prefix=/usr
The Meson build system
Version: 0.45.1
Source dir: /libqmi
Build dir: /libqmi/build
Build type: native build

meson.build:223:10: ERROR: lexer
test_env = {
          ^

A full log can be found at /libqmi/build/meson-logs/meson-log.txt

tom

@groupo Hmm meson isn't something I'm familiar with so I don't know how to debug that.

Do you know if the version of libqmi has to be newer than 1.30? Otherwise you could try the older way to build using make

groupo

@tom unfortunately, the ability to send AT commands via qmicli was introduced in 1.32. What about trying the drivers again? I goofed the symbolic linking earlier. I redid it and the make script gets farther, but still eventually fails.

How come PORT is initialized with certain modems in voxl-configure-modem but not with the em9291. It looks like you just set PORT to ttyUSB0 and echo to it to send AT commands. Can i not just add that into the em9291 logic flow?

tom

@groupo /dev/ttyUSB0 only enumerates if the driver recognizes the hardware of having said capability. In this case, the driver that controls that port doesn't recognize that modem hardware, likely the driver is from before that hardware existed.

In these cases we usually have to make custom tweaks to the linux kernel drivers in order to add the support for the hardware.

If you'd like to experiment with doing that you can, building custom kernels allows adding custom support for new or existing hardware.

You can read more about building a custom kernel here: https://docs.modalai.com/voxl2-kernel-build-guide/

groupo

@tom I will explore the kernel stuff.

Re updating qmicli, I need meson >= 0.53.0 which is not supported on drone's ubuntu version. Is upgrading to a newer ubuntu on the drone an option?

tom

@groupo It is not. Ubuntu 20 is on our road map but that's a while out

groupo

@tom If I solely wanted to update the driver that controls that port is making a custom kernel the only way to do that? If that is the case, what is the least invasive way to do that? Where does that driver exists and what is the process for updating it? Which driver is responsible for that port? It looks like the guide shows you the things to download if you wanted to make your own kernel, but where do you change stuff to make it your own?

groupo

@tom Found the drivers I believe I want to change. Do i change them inside or outside of the docker?

Alex Kushleyev

@groupo , all the source code for the kernel will exist on your host system. When you enter the docker container, it maps your current directory into the docker container. qrb5165-sync.sh and qrb5165-patch.sh commands (executed inside docker) will download all the required sources to the shared folder and will be accessible on host system and inside the docker container.

You should make sure you can build the original kernel according to the standard instructions (sync, patch, build). Then make change to your driver either manually or apply your custom diff / patch and build again (do not sync or patch the whole project again).

Alex

groupo

@Alex-Kushleyev @tom

Yeah I was able to sync, patch, and build successfully. When making those changes, is it done inside or outside of the docker? I can see the drivers I want to change in qrb5165-kernel-...sh, but that is outside the docker. I dont find the driver files insiede the docker.

For any driver I want to edit, my understanding is that I change it in the qrb5165-kernel-...sh folder outside the docker, then I go into the docker and build. Is that correct?

groupo

@Alex-Kushleyev @tom

hey have made some good progress on the drivers - still curious about the docker question but because they are mounted, does it not matter which side of the docker (inside or outside) I change them?

anyways other question:

I see in the repo README it discusses debug messages, and I can see debug msgs in the code for drivers like below:

How can I print these out/where are they printed so I can read thru them?

Alex Kushleyev

@groupo , it does not matter where you edit the files (inside the docker container or the host). On the host side, there will be a new folder created for the kernel source files (workspace), where you can find all the source files and build output. In the docker container, the same files will be in /home/user/build_mount, as specified here : https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel-build-docker/-/blob/qrb5165-ubun1.0-14.1a/docker-run-image.sh?ref_type=heads#L9

If you build the kernel in debug mode, you can use dmesg command to print out all the kernel messages. Even with non-debug kernel, there will be some essential messages from kernel there. If you are looking for a particular string, you can use grep to filter the messages:

dmesg -w | grep "Num Interfaces"

If the messages from your driver have some common string, you can use that string to filter the dmesg output.

Alex

groupo

@Alex-Kushleyev

Thanks for the explanation - I am still getting the hang of Docker.

I think logging was turned off in all the drivers I am curious about. I think I just turned it on.

Do i need to run ./qrb-clean.sh every time before I run ./qrb-build.sh? I see you use it in the example on the documentation, but I am unclear if its necessary for what I am doing (make changes -> build -> flash -> repeat if not working)

Alex Kushleyev

@groupo,

When in doubt, it is better to do a full clean before re-building. Especially when you are changing configuration like debug or non-debug version of the kernel.

For simple changes inside your kernel module / driver, you can test by trial and error to see if you need to re-build when you make a small code change. Once you have the debug prints working, this will be easy to test.

Alex