This repository has been archived by the owner. It is now read-only.

i9195/Qualcomm modem support #1314

Merged
merged 13 commits into from Mar 11, 2018

Conversation

Projects
None yet
5 participants
@scintill
Contributor

scintill commented Mar 10, 2018

I've tested with SMS. See f5e8e1f and
72bbfaf for an idea of the changes needed to incorporate this into a similar device. (I'd be willing to help someone port this to their device, if you're familiar with fetching source, compiling, and troubleshooting.) I've been testing with ofono like this:

sudo service ofono start

sudo dbus-send --print-reply --system --dest=org.ofono /gobi_0 org.ofono.Modem.SetProperty string:"Powered" variant:boolean:"true"
sudo dbus-send --print-reply --system --dest=org.ofono /gobi_0 org.ofono.Modem.GetProperties
sudo dbus-send --print-reply --system --dest=org.ofono /gobi_0 org.ofono.Modem.SetProperty string:"Online" variant:boolean:"true"
sudo dbus-send --system --print-reply --dest=org.ofono /gobi_0 org.ofono.MessageManager.SendMessage string:"$PHONE_NUMBER" string:"Hello world! -postmarketOS"

# receive SMS like this (might be spammy if you have other DBus apps):
sudo dbus-monitor --system

What next?

ofono mainline doesn't have support for QMI device voicecalls last I saw, but Sysmocom and Alexander Couzens have patches here that I've successfully used in my Android oFono-based RIL. I have a couple of relevant patches here too. There might be some audio device initialization that needs to be done to route the mic to the phone or something, but it's probably not too hard to figure out since my fully open-source Android stack was working.

I also had data connections working on my Android system, so I anticipate that wouldn't be far away either. We'll need a patch to set something like ofono_modem_set_string(modem, "NetworkInterface", iface_name);, maybe from udev properties. After that, I imagine there's pre-existing things (NetworkManager?) that can take care of a network connection that ofono provides.

And of course, we need a UI to use the phone features... I tried getting Plasma Mobile running on software rendering, but it was extremely slow and crashing or something. Maybe I will try again when I get voicecalls working - I know it has a dialer but I'm not sure about SMS support.

Ping #1054.

@scintill

This comment has been minimized.

Contributor

scintill commented Mar 10, 2018

I think the Travis build failed because androidfilehost.com expired the download link for the firmware. Thought it might happen... any thoughts on where else to find/host it?

@z3ntu

This comment has been minimized.

Member

z3ntu commented Mar 10, 2018

Wait, so that means you were able to send an SMS from postmarketOS?

@ollieparanoid

ollieparanoid suggested changes Mar 10, 2018 edited

@scintill: You did incredible work there, I am amazed and very grateful! Sending the first SMS with postmarketOS (on an Android device with ofono) is a great accomplishment! 🎉
The best part is, that this works without userspace blobs 😀

mkdir "$pkgdir"/boot
ln -s /dev/disk/by-partlabel/modemst1 "$pkgdir"/boot/modem_fs1
ln -s /dev/disk/by-partlabel/modemst2 "$pkgdir"/boot/modem_fs2
ln -s /dev/disk/by-partlabel/fsg "$pkgdir"/boot/modem_fsg

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

Which component expects these device nodes to be in /boot?
(This seems to be a bit uncommon to me, might be worth patching in that software?)

This comment has been minimized.

@scintill

scintill Mar 10, 2018

Contributor

qcom_rmtfs uses those paths here. (One is a string the modem sends in the request, the other is the actual Linux filesystem path; in this case, the same.) They are a bit weird. What path would be better? I don't want to embed the by-partlabel path into rmtfs, because it might differ by device.

This comment has been minimized.

@MartijnBraam

MartijnBraam Mar 10, 2018

Member

I guess this is for the modem firmware? The correct place is /lib/firmware/qmi which can be either provided by a firmware package or by a mount/symlink

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

They are a bit weird. What path would be better?

From reading up on FHS, the best fit I can find is somewhere in /etc:

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary.

After all, the symlinks are there for configuring the device path for qcom_rmtfs. It isn't perfect, but it fits much better than /boot in my opinion (which is on a different partition in postmarketOS actually).

So how about something like:
/etc/qcom_rmtfs/partition-symlinks/modem_fs1

(If someone has a better idea, don't be shy to post it here.)

This comment has been minimized.

@scintill

scintill Mar 11, 2018

Contributor

@MartijnBraam Those partitions aren't firmware. I don't know much about what specifically is in them, but they're partitions the modem can read or write to, to store persistent data. I don't know if they can be packaged (as files in the Linux filesystem rather than raw partitions on the MMC), since they might contain IMEI, and I don't know what a good initial value for them is.

@ollieparanoid That /etc path makes sense to me.

nonfree_firmware() {
pkgdesc="Modem firmware"
depends="firmware-samsung-i9195-modem qcom_rmtfs libqipcrtr4msmipc libsmdpkt_wrapper"
# these other packages are here so that they don't get installed if the firmware isn't (because they're not very useful in that case)

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

How about placing the comment on top of the depends line and shortening it?
# Non-firmware packages placed here, because they aren't useful without firmware

url="https://forum.xda-developers.com/galaxy-s4-mini/general/modem-samsung-galaxy-s4-mini-gt-i9195-t3390780"
arch="noarch"
license="proprietary"
# build system wants to strip binaries, so stop that, and thinks they are wrong arch, so ignore that

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

For consistency with other packages, I would omit describing why the options are used here. If you feel like that should be included somewhere, how about writing it in the commit message instead?

options="!strip !archcheck"
makedepends="p7zip"
source="$_ver.tar::https://wa1.androidfilehost.com/dl/gMdb8sYfl8Zy2_daybpA-Q/1520163411/889964283620758806/I9195XXUCQG1.tar.md5

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

any thoughts on where else to find/host it?

People have uploaded extracted files to their GitHub account, that seems to be fairly stable.

makedepends="p7zip"
source="$_ver.tar::https://wa1.androidfilehost.com/dl/gMdb8sYfl8Zy2_daybpA-Q/1520163411/889964283620758806/I9195XXUCQG1.tar.md5
SHA512SUMS.modem"

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

I guess the idea was, that you have one good set of SHA512sums, and you're comparing from wherever the files come from with that set of checksums. That makes sense, but since the link needs to be switched anyway, I would suggest to just go with using the usual checksum over the whole tarball as this makes the APKBUILD much cleaner. If you like to, we could add a note in the commit message about additional verification measures you have done to make sure that the files are legit, and that the checksum in the APKBUILD is the right one.

This comment has been minimized.

@scintill

scintill Mar 10, 2018

Contributor

Ok. I have not done verification really. I understand the files are signed, so hopefully that's enough verification.

pkgver=0.1_git20180304
pkgrel=0
pkgdesc="LD_PRELOADable library to emulate AF_QIPCRTR socket on devices with only AF_MSM_IPC"
url="https://github.com/scintill/libqipcrtr4msmipc"

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

It's awesome that you wrote wrappers to get this working \o/

I'm playing with the idea of introducing a new aports/modem subfolder, where all modem specific aports (qcom_rmtfs, libqipcrtr4msmipc, libsmdpkt_wrapper, qrtr, msmipc-dev and the temporary ofono fork) could reside. The reason is, that from reading the package names it is not super obvious that this is all modem related. What do you think about that?

This comment has been minimized.

@scintill

scintill Mar 10, 2018

Contributor

aports/modem sounds good. I considered device too, but something separate would probably be better.

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

Just in case it's not obvious: there's no code change needed in pmbootstrap, just move the files to the other folder and it will work out of the box.

@@ -0,0 +1,23 @@
pkgname=libqipcrtr4msmipc
pkgver=0.1_git20180304

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

Since this is your own repo, how about tagging releases and using them here?

}
package() {
install -Dm644 "$builddir"/libqipcrtr4msmipc.so "$pkgdir"/usr/lib/preload/libqipcrtr4msmipc.so

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

@NotKit: here's a good preloading example 😄

This comment has been minimized.

@scintill

scintill Mar 10, 2018

Contributor

Is the path prefix /usr/lib/preload good? I wanted something that wouldn't conflict with things, and would be clear this was not a normal lib.

I've gone back and forth on whether to use preload or to patch the packages. For now, I like preload because it can apply to several different programs and doesn't have maintenance overhead when upgrading package versions.

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

Is the path prefix /usr/lib/preload good? I wanted something that wouldn't conflict with things, and would be clear this was not a normal lib.

Yeah, that's a good name!

I've gone back and forth on whether to use preload or to patch the packages. For now, I like preload because it can apply to several different programs and doesn't have maintenance overhead when upgrading package versions.

This sounds reasonable for now. From what I understand it probably makes sense to upstream these changes in the long run to ofono/qcom_rmtfs, so the wrappers are not needed and we can use the vanilla sources from upstream without carrying patches.

@@ -0,0 +1,45 @@
# Based on https://git.alpinelinux.org/cgit/aports/tree/testing/ofono/APKBUILD?id=014ae282b4a9152a5b64451f2815f34fcb53507c
# Thanks to upstream maintainer, Francesco Colista <fcolista@alpinelinux.org>

This comment has been minimized.

@ollieparanoid

ollieparanoid Mar 10, 2018

Member

We don't mention the upstream maintainers in our APKBUILDs, so they don't get annoyed with questions for postmarketOS packages. But they could be credited in the commit message. See also: https://wiki.postmarketos.org/wiki/Create_a_package#General_information

Ideally we would only fork ofono temporarily anyway, until the changes are upstreamed into ofono and then we could use the upstream package from Alpine again.

@scintill

This comment has been minimized.

Contributor

scintill commented Mar 11, 2018

Thanks for the feedback. I'm also really happy there are no blobs (other than baseband firmware.) The latest push should address all issues. I also made the qcom_rmtfs symlinks be a subpackage that only gets installed if qcom_rmtfs is installed.

@z3ntu Yes, I was able to send and receive SMS, albeit from the command line. Now someone package a UI for oFono SMS 😉 (or tell me if there is one that works on my device.) I've looked at the messaging app for Ubuntu Touch a bit.

scintill and others added some commits Mar 5, 2018

Qualcomm MSM modem: 'rmtfs' support packages
* qcom_rmtfs: Server that talks to modem over IPC to allow it
read/write data for its persistent storage. This is needed for it to
boot, as well as periodically during usage.
* qrtr: IPC library for rmtfs
* libqipcrtr4msmipc: adapter library to make qrtr work on kernels with
AF_MSM_IPC support. AF_QIPCRTR is the mainline equivalent since Linux
~4.7.
* msmipc-dev: Header files for qrtr and libqipcrtr4msmipc.

Thanks to Bjorn Andersson <https://github.com/andersson> for rmtfs and
qrtr.
libsmdpkt_wrapper: adapter lib for QMI clients
The SMD serial packet driver in Qualcomm kernels has, AFAICT, a bug
in poll(); this works around it so that qmicli et al can work.
add ofono (with patch for MSM devices)
Based on Alpine's package.
qcom_rmtfs: use storage paths in /etc
Also, don't install symlinks if qcom_rmtfs isn't installed.
firmware: update hosting, don't SHA-check final files
Host just the extracted files, which also simplifies packaging.
mark libqipcrtr4msmipc only for arm arches
Apparently it wants -fPIC for x86_64, but I won't bother since
it's not going to be used on that arch anyway.
Use pkgname in source tarball, not pkgrel
* pkgname avoids collisions
* pkgrel causes the source to get downloaded again even if the source
  did not change (pkgrel indicates that only the APKBUILD changed)
@ollieparanoid

Thanks for making all the changes! I've rebased to master and removed the pkgrel in the distfile names. Ready to go in my opinion, just waiting for Travis to finish with CI.

@ollieparanoid

This comment has been minimized.

Member

ollieparanoid commented Mar 11, 2018

And of course, we need a UI to use the phone features... I tried getting Plasma Mobile running on software rendering, but it was extremely slow and crashing or something.

Yeah, that doesn't work properly without hardware acceleration. The best fix we have is running the mainline kernel on it, and using and open source userspace drivers (together with the GPU blobs, no way around that right now, just like cellular modem firmware). This works well for the Sony Xperia Z2 Tablet for example. But of course mainlining is not an easy task (I would like to streamline the process and put up a step by step guide for that in the wiki in the future).

But basically if your SoC is supported in mainline already, and the peripherals are as well, then you would "only" need to write a device tree file that enables the peripherals properly. If you want to go down that path, people in #postmarketOS know about the process, and we have some information in the wiki.

Now someone package a UI for oFono SMS 😉 (or tell me if there is one that works on my device.) I've looked at the messaging app for Ubuntu Touch a bit.

I don't know on which stack that is based. If it is also QML, I guess we would run into the same performance problems (@bhush9, you probably know this?). Launchpad is down right now, so I can't look it up easily. However, packaging it shouldn't be much of a problem in either case.

@pavelmachek worked on a general phone functionality demo interface called unicsy_demo. It is not aimed at end users like the ones from Plasma Mobile, ubports, Hildon, LuneOS UI and I have not tested it myself (might be that it only works with the N900). But we have it packaged in postmarketOS (as unicsy-demo), and I'm pretty sure it works without hardware accelerated graphics. So you could simply try that one out if you like to (e.g. by running apk install unicsy-demo on the phone as root after installing postmarketOS). apk info -L unicsy-demo gives you the list of installed files afterwards.

@andersson FYI: Your rmtfs and qrtr are packaged in postmarketOS now.

@ollieparanoid ollieparanoid merged commit 263578e into postmarketOS:master Mar 11, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls First build on master at 78.886%
Details
@z3ntu

This comment has been minimized.

Member

z3ntu commented Mar 11, 2018

Yes, the messaging app is written in QML. See the ubports fork: https://github.com/ubports/messaging-app

@pavelmachek

This comment has been minimized.

Member

pavelmachek commented Mar 11, 2018

@pavelmachek

This comment has been minimized.

Member

pavelmachek commented Mar 11, 2018

fooforever added a commit to fooforever/pmbootstrap that referenced this pull request Mar 14, 2018

i9195/Qualcomm modem support (postmarketOS#1314)
* Qualcomm MSM modem: 'rmtfs' support packages
* qcom_rmtfs: Server that talks to modem over IPC to allow it
  read/write data for its persistent storage. This is needed for it to
  boot, as well as periodically during usage. Added a patch that
  it expects the storage path symlinks in /etc instead of /boot.
* qrtr: IPC library for rmtfs
* libqipcrtr4msmipc: adapter library to make qrtr work on kernels with
  AF_MSM_IPC support. AF_QIPCRTR is the mainline equivalent since Linux
  ~4.7.
* msmipc-dev: Header files for qrtr and libqipcrtr4msmipc.
  Thanks to Bjorn Andersson <https://github.com/andersson> for rmtfs and
  qrtr.
* libsmdpkt_wrapper: adapter lib for QMI clients
  The SMD serial packet driver in Qualcomm kernels has, AFAICT, a bug
  in poll(); this works around it so that qmicli et al can work.
* i9195: firmware (modem only right now)
* add ofono (with patch for MSM devices)
  Based on Alpine's package.
* i9195: add modem support
* move all modem related packages to aports/modem
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.