libqmi-devel Digest, Vol 63, Issue 6

[E:V:A]

Dear Wolfgang,

Date: Sun, 05 Feb 2017 22:53:18 +0100
From: Wolfgang Wiedmeyer
> Hi,
>
> I'm trying to port the LTE variant of the Galaxy S3 (i9305) to
> Replicant[1]. The non-LTE variant (i9300) is already supported. After
> backporting cdc-wdm and qmi_wwan drivers to the 3.0 kernel[2] and
> cross-compiling libqmi and its dependencies for Android, I was able to
> talk to the modem with qmicli.

This is a very ambitious and brave enterprise as Replicant has only
been available for Intel/XMM basband processors (BP).
So the use of the Qualcomm MDM + Exynos AP-BP combo on the device
would open the doors to all other
Qualcomm devices.


> But I'm facing the problem that I don't know how to load the firmware
> files to the modem and reboot the modem. For now, I use the proprietary
> tool qcks which normally runs as a daemon on the device. It relies on
> another binary called ks (kickstart) to upload the firmware and later
> spawns another tool called efsks. I'm not sure what efsks actually
> does. If I abort qcks at the right moment, the modem is correctly
> booted and the cdc-wdmX nodes are accessible. If I let it run, it's not
> really usable as the device reboots at a sudden moment. I attached the
> relevant parts from logcat and kernel log below.

Yep, that is a good observation and typical for the AP-BP combo from
Qualcomm. The same happens on the Galaxy Note 4, but without the
reboot. The reboot is due to a subsystem reset request being sent to
or from modem, depending how the AOS being set to reset/reboot after
changes to BP. As the name "efsks" implies, it is the EFS (embedded
file system) kickstarter, it is used to copy the entire partitions
to/from the 3 modem partitions. Usually, AFAIK, 1 of these is a
"golden" copy that should be never written except for complete
firmware updates. The other 2 are alternatively toggled after each
reboot, to make sure the phone boots. When you make changes to the
device related to modem behavior or settings, these 2 partitions
seemingly need to be completely rewritten. The way it's written is by
using their new (proprietary) Qualcomm high-speed USB (QHS-USB)
protocol called Sahara. Some details about that can be found in [1]
and an old version of efsks.c in [2].

[1] https://forum.xda-developers.com/showpost.php?p=54829011&postcount=73
[2] https://defuse.ca/b/dEM7LGyPYZrcGk1CX0pqL2

// efsks.c : A wrapper around the Kickstart utility to perform EFS sync
// qcks.c : A wrapper around the Kickstart utility
// kickstart.c: A utility for uploading MSM images using the "DMSS-DL"
and Sahara protocols


> It looks like the protocol is SAHARA. I didn't find any documentation on
> this protocol. Would qmi-firmware-update be usable in this case? I also
> found two other tools[3][4] that claim to be compatible with this
> protocol. I went through Harald Welte's and Holger Hans Peter Freyther's
> talk "Dissecting modern (3G/4G) cellular modems" and other osmocom
> resources, but I couldn't figure out if a tool already exists that can
> do this.
>
> Thanks and best regards,
> Wolfgang

As it looks, I don't believe you need a QMI firmware update. Why do
you think you need one? Or more importantly, what do you think you can
replace it with? Surely the most recent Qualcomm firmware images are
signed and perhaps even encrypted to prevent modification.

To have it said, don't take all what I have said as a truth, I doubt
I'm fully correct on all points, and I no longer have any similar
device to test on. But I'm sure you can find the sources of some of
the Qualcomm binaries you mentioned, as they were leaked years ago
while being occasionally available at the code aurora repositories.