Building and installing
There is one tested installation method for your Motorola Moto G5 Plus. It relies on flashing one or more partitions on your device and creating a filesytem for the boot image.
|
Warning
|
All installation methods can lead to data loss. Flashing a partition will erase everything on the partition. Additionally,
the common backups methods, e.g. TWRP, will not backup the Make backups. |
Using Fastboot
This will produce a folder with the partition images for your Motorola Moto G5 Plus.
$ nix-build --argstr device motorola-potter -A build.android-fastboot-images
Alternatively, you can build a specific partition image:
$ nix-build --argstr device motorola-potter -A build.android-bootimg $ nix-build --argstr device motorola-potter -A build.rootfs
The device requires the
"[lk2nd](https://github.com/msm8953-mainline/lk2nd)" secondary
bootloader to be installed in the boot partition. This runs after
your existing bootloader and does some hardware setup required to
allow mainline kernels to run on your device - as well as providing a
"fastboot" interface for devices that don’t already have one.
You can build lk2nd for your device as foilows:
$ nix-build --argstr device motorola-potter -A pkgs.lk2ndMms8953
To install it, reboot into the bootloader (fastboot mode), then run
$ fastboot flash boot result/lk2nd.img
Now you can boot into lk2nd - press Volume Down while booting to enter Fastboot mode. If your stock bootloader uses the same key combinations, you need to wait a bit before pressing the volume keys. Usually, waiting until the screen turns on and/or the device vibrates should be enough to make the stock bootloader ignore the keys.
The suggested filesystem arrangement is to put the Mobile NixOS
system.img into the userdata partition, and use the system
partition for the stage-1 boot.img which on some devices is too
large for the boot partition. Once running lk2nd you can do this
as follows
$ fastboot flash userdata result/system.img $ fastboot flash recovery result/recovery.img
Now use the up/down keys and power key to select "Recovery mode", then connect to the device with adb
$ adb shell ~ $ mke2fs /dev/disk/by-partlabel/system ~ # mkdir /mnt2 ~ # mount /dev/disk/by-partlabel/system /mnt2 ~ # exit
$ adb push result/boot.img /mnt2 $ adb reboot
Device-specific notes
Hardware Revisions
This device has been through several hardware revisions: the kernel
describes P0A, P1A, P1B, P2A, P2A2, P2B, and P3A but
that’s not an exhaustive list. Each of these revisions corresponds to
a separate hardware configuration description (device tree) in the
vendor kernel, but on examination it turns out that several are
identical to each other.
According to the commit messages, the two hardware changes that required device tree changes were
-
(U) "Change usbid-gpio from 66 to 59" (git sha 305e2610c598dc4e)
-
(D) "boost clock use pdm clock instead" (git sha c42744ebf80da79a0)
| hwrev | board-id | (mis)features |
|---|---|---|
P0A |
<0x44 0x80a0> |
U D |
P1A |
<0x44 0x81a0> |
U D |
P1B |
<0x44 0x81b0> |
D |
P2A |
<0x44 0x82a0> |
D |
<0x45 0x82a0> |
D |
|
P2A2 |
<0x45 0x82a2> |
|
P2B |
<0x45 0x82b0> |
|
P3A |
<0x46 0x83a0> |
|
P3B |
<0x46 0x83b0> |
Thus we can describe the complete range of hardware using only three variations instead of seven, which represents a significant space saving on the boot partition
-
msm8953-potter-p0a-p1a.dtb (contains U and D fixes)
-
msm8953-potter-p1b-p2a.dtb (contains D fix only)
-
msm8953-potter-p2a2-plus.dtb (contains no fix)
What about P3B?
The vendor kernel does not include a device tree source with
appropriate board-id for hwrev P3B, but empirically (by consulting
/proc/device-tree/board-id on a device running Android) it looks like
the bootloader chooses the P3A DTB instead. As far as I understand it
this goes against the documented rules
for choosing a device tree - according to
sources
the platform subtype is the lowest 8 bits of the second element of the
board-id, and clearly 0xa0 != 0xb0, but it seems to do it anyway.
If you have a device with a hwrev after P3B, I’d love to hear from
you about how it behaves in this regard.
Firmware for Wi-Fi
This particular phone keeps the firmware files on a partition named
modem.
To make use of the Wi-Fi capabilities of this phone you will need to make them available to the firmware derivation.
The files can be acquired through different methods. You can use an
alternate recovery like TWRP, mount the partition (identified using
blkid) and copy the files.
Another way is to do it using an installed Mobile NixOS system, where, too, you mount the partition and copy them:
$ sudo mount -o ro /dev/disk/by-partlabel/modem /mnt
$ cp -r /mnt ./modem
$ sudo umount /mntThe copy of the firmware files will be in the modem directory, in the current working directory, ready to be referred to.
Touchscreen
There seem to be three distinct versions of the Synaptics DSx
touchscreen driver in the vendor kernel: one in
drivers/input/touchscreen/synaptics_*.[ch]/, plus two others in
subdirectories drivers/input/touchscreen/synaptics_dsx/
Since commit 219587de9e92a in the vendor kernel, the touchscreen is
declared in the device tree as compatible = "synaptics,dsx-i2c"
which corresponds to the code in
drivers/input/touchscreen/synaptics_dsx_2.6/, but the kernel config
options specify a weird mismash of that code and and some of the files
in the parent folder. I tried cleaning this up but it broke more than
it fixed.
The option for CONFIG_SCREEN_OFF_GESTURES is disabled because it is
incompatible with CONFIG_FB