pine64-pinephone: get eg25-manager to work

[Artturin]

Theres no /dev/ttyS2 on the default kernel configuration or the manjaro configuration (with =m replaced with =y)

https://gitlab.com/mobian1/devices/eg25-manager

hardware.usbWwan.enable is needed to get /dev/ttyUSBX

[Tofee]

I just had the same issue yesterday with LuneOS, when upgrading to 5.12 kernel, and I saw your similar issue during my search for a solution... Consider applying this patch to the kernel: https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/linux-postmarketos-allwinner/0010-dts-pinephone-drop-modem-power-node.patch

For me, it did make the /dev/ttyS2 node appear.

[Artturin]

it worked! i tried to get it to work for a couple weeks previously but i didn't think of applying that patch facepalm

[tomfitzhenry]

Looks like there are two alternative solutions

1. Use megi's builtin driver that reuses kernel abstractions https://xnux.eu/devices/feature/modem-pp.html
2. eg25-manager, a GPIO-oriented userspace application, introduced in https://forum.pine64.org/showthread.php?tid=12511&pid=85802#pid85802

The simplicity and reuse of kernel abstractions of (1) is appealing.

[Artturin]

Megis is already enabled but eg25-manager works better

[tomfitzhenry]

https://xnux.eu/devices/feature/modem-pp.html lists some of the benefits of megi's driver.

How does eg25-manager compare to that? In what ways does it work better?

[Artturin]

I don't know the details but other mobile distros have switched to it and it seems to work better

[fx-chun]

I'm not sure it's necessary to port eg25-manager over to NixOS if we're already using megi's modem driver, there's not a lot more it does in terms of configuration IMO. One thing I'd like to see added from eg25-manager are these udev rules for the modem, which reportedly help a lot in terms of USB resets and probing when resuming from suspend:

https://gitlab.com/mobian1/devices/eg25-manager/-/blob/master/udev/80-modem-eg25.rules https://gitlab.com/mobian1/devices/eg25-manager/-/merge_requests/5

Quectel advises to configure the USB autosuspend feature as:

power/control: auto
power/autosuspend_delay_ms: 3000

Futhermore, the following settings are also needed:

power/wakeup: enabled
power/persist: 0
avoid_reset_quirk: 1

This certainly makes a difference in terms of modem resets, I haven't got any since I applied these changes.

[sergei-mironov]

I flashed my pinephone's modem with a stable 01.002.01.002 firmware and it looks like megi's driver doesn't put modem to sleep, at least by itself. The phone is still warm and drains battery quickly. I have looked at the kernel sources and actually it is not clear to me how it is supposed to work. Some places look suspicious

Edit: most likely, the driver exposes it's suspend functionality via some generic kernel interface here I don't know much about it, if someone have ideas how to check if it works or not please share!

Edit 2 Okay, It seems that the megi's modem-power driver listens for system suspend events and puts the modem into the appropriate state when the system is about to sleep. The modem is able to wake the system back on incoming calls. So If I understand it correctly, one shouldn't expect any userspace tools to manage the modem via this driver, besides the generic power on/off knob.

[sergei-mironov]

Investigation shows that my modem shows zero on its wakeup counter. It could be that the system doesn't have a right userspace to use the power management functionality..

[root@nixos:/home/nixos]# cat /sys/class/modem-power/modem-power/device/power/wakeup
enabled

[root@nixos:/home/nixos]# cat /sys/class/modem-power/modem-power/device/power/wakeup_count 
0

Should the ModemManager send the modem to sleep automatically? Does it works correctly in this aspect in the current version of mobilenixos?

*Edit: also I see a suspicious

# cat /sys/class/modem-power/modem-power/device/power/autosuspend_delay_ms 
cat: /sys/class/modem-power/modem-power/device/power/autosuspend_delay_ms: Input/output error

Does anybody know how to interpret this error? Could it be incorrectly configured gpios in the kernel?

[sergei-mironov]

I have reviewed the eg25-manager sources. Some first-glance points are (please correct me if I am wrong)

• Regarding the power management, the eg25 seems to behave in a similar way to megi's modem-power driver: it listens for system suspend events and does some magic to properly suspend the modem. It is able to run the configurable AT- and hardcoded GPIO command sequences before the suspend and resume events. For pinephone-1.2, the AT sequence is empty.
• Also it has some GPS-related functionality which we probably wouldn't have with a bare kernel. It downloads something from https://xtrapath4.izatcloud.net in the process.

The autosuspend_delay_ms thing is still bothering me. From what I see, the software implements a kind of smart-suspend strategy, that is, suspend the whole system, but wake it up on incoming calls (and it seems to work for me). But what about suspending the modem alone while keeping the system running?

[fx-chun]

@grwlf

• Regarding the power management, the eg25 seems to behave in a similar way to megi's modem-power driver: it listens for system suspend events and does some magic to properly suspend the modem. It is able to run the configurable AT- and hardcoded GPIO command sequences before the suspend and resume events. For pinephone-1.2, the AT sequence is empty.

A key difference seems to be that it also interfaces with ModemManager to prepare the modem for suspend, while megi's driver lives entirely in the kernel. This may work better; I've had a lot of trouble with reliably picking the modem up in NixOS when waking up the last time I tried with modem-power.

• Also it has some GPS-related functionality which we probably wouldn't have with a bare kernel. It downloads something from https://xtrapath4.izatcloud.net in the process.

Yeah, that's the A-GPS information needed to get a quicker fix on location. If the eg25-manager handles the downloading of the A-GPS stuff & the uploading to the modem then I think it would be a valuable addition, it's a bit tedious to do by hand right now.

It's been a while since I've looked at eg25-manager, so my comments from August are probably out-of-date :)

Does anybody know how to interpret this error? Could it be incorrectly configured gpios in the kernel?

That does seem suspicious; I wonder if it happens in other distros? I can try to repro but it may be a while before I can since I don't have mine set up currently. For what it's worth, the settings are merely a suggestion from Quectel; it's very possible that it does not really matter.

[tomfitzhenry]

I have reviewed the eg25-manager sources. Some first-glance points are (please correct me if I am wrong)

Your understanding matches mine (but mine isn't particularly strong!)

Also it has some GPS-related functionality which we probably wouldn't have with a bare kernel. It downloads something from https://xtrapath4.izatcloud.net in the process.

Are there any projects that provide this GNSS functionality without also providing power management? (Should there be?)

Last time I looked at modem-power, and I have 50% confidence in my memory, I vaguely recall that one issue was that:

• modem-control.service is bound to modem-power: systemd will power the modem up when it's available, and power it down when not available.
• sometimes when the modem becomes available, and systemd powers it up, the modem doesn't power up fast enough for systemd to give up, at which point systemd issues its ExecStop directive, which then powers it down.

Perhaps either:

a. systemd can be configured to wait longer, or b. we could break the binding, and just do a one-shot power up on boot. This should be sufficient (per https://xnux.eu/devices/feature/modem-pp.html ) but we would lose that systemd tracks the state for us.

[sergei-mironov]

@tomfitzhenry @noneucat Thank you for your responses.

sometimes when the modem becomes available, and systemd powers it up, the modem doesn't power up fast enough for systemd to give up, at which point systemd issues its ExecStop directive, which then powers it down

I observe that modem-control is a very simple oneshot rule, at least in my version of the mobilenixos I assume that slow powerup will only result in ModemManager to discover the modem with a delay.

(per https://xnux.eu/devices/feature/modem-pp.html )

An interesting thing is this "it makes the modem sleep most of the time" feature in the list. Do you know what does author mean by this? Probably, he means some passive command asking modem to slow down if possible. But then how can I be sure that the modem takes it into account?

As far as I can see, there is no API available to userspace besides the power up/down and suspend handlers, but I would be glad to know how to send the modem asleep while keeping the rest of the system awake..

Overall, I think that I don't like eg25 approach very much. I would prefer to leave the suspend power management to the kernel and have a separate tool for doing the GPS business. I guess that a big share of suspend-related bugs which eg25-manager combats is due to the buggy modem's firmware by Quectel. But I see an almost-ready opensource pinephone_modem_sdk to replace it. So I think that eventually eg25-manager may became obsolete..

Edit I also checked that this "PrepareForSleep" event does indeed happen before the whole-system suspend, according to https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html . So eg25-manager will not probably behave very much smarter than the kernel in this sence, as I hoped before..

[sergei-mironov]

Well, I wrote to Megi and he revealed some hints. Now I think that I can answer my questions.

"it makes the modem sleep most of the time" feature in the list. Do you know what does author mean by this? Probably, he means some passive command asking modem to slow down if possible.

The answer seems to be yes, the driver sends a passive command asking the modem to slow down if possible. No further user interaction required. Namely, the procedure seems to be the following: 1) Send the AT+QSCLK=1 at startup to enable the possibility of low-power mode. Both modem-power driver and eg25-manager do it. 2) Pull DTR gpio to 1 to allow the modem to go sleep if it thinks it may sleep.

Now, an interesting part: the modem-power driver does it on resume but the eg25-manager does the opposite leaving the modem in the high-power mode. In other words, it seems that the modem-power allows the modem to sleep while the host is up and the eg25-manger allows it to sleep only when the host is suspended.

Ref Quectel_EC2x&EG9x&EG2x-G&EM05_Series_AT_Commands_Manual_V2.0.pdf, page 274

The autosuspend_delay_ms thing is still bothering me

It turns out that it is not enabled and is not important.

[sergei-mironov]

All in all, it seems that for my system (a Pinephone 1.2, stable modem firmware, megi's modem-power driver) all prerequisites for modem to be quite are met. But it doesn't want to sleep despite the driver's efforts and that probably means that something prevents it from sleeping. Maybe I should understand how to monitor the usb traffic between the host and the modem next. I am going to pause with this issue for now..

[tomfitzhenry]

Great work on looking into this, and thanks for writing it up!

[Luflosi]

I think this can be closed now that https://github.com/NixOS/mobile-nixos/pull/573 was merged.

[samueldr]

Don't hesitate to open fresh issues, whoever you are, if you're facing problems with the modem.