VoLTE Implementation For Google Pixel 3a/3a XL

Fuseteam

@JayH said in VoLTE Implementation For Google Pixel 3a/3a XL:

Granted, I'm not keeping completely current but I didn't think halium was the current/accepted/approved/supported/??? method of porting any more? I thought it was all being compiled into the kernel and done?

fwiw Halium is still used, It is just that it is no longer needed to build halium itself

mr_growl

@atarilinux I suspect it's because I skipped the step in the documentation about setting up the fixup-mountpoints script. I could not find that script anywhere so skipped it just to try to get something booting.

Here's the part I'm talking about:

Include your device in fixup-mountpoints

Fixup-mountpoints replaces the aliases of block device nodes in /dev/block/by-name with their literal nodes under /dev/block. This prevents issues caused by by-name not being populated by systemd.

First check if the codename of your device is already included in the <BUILDDIR>/halium/hybris-boot/fixup-mountpoints script.

If it’s not already included, you will need to add it. Your device should be running LineageOS or another ROM where you can get root access over ADB.

    Find the fstab file for your device. For my Moto G5 Plus, this was fstab.qcom in device/motorola/potter/rootdir/etc

    Enable adb root access

    Create the skeleton for your device in fixup-mountpoints, right before the *):

    "[codename]")
        sed -i \
            [replacements, one per line]
            "$@"
        ;;

    For every line in fstab where the type is not auto, emmc or swap, run readlink -f [src] on the target device over ADB. [src] is the leftmost colum in fstab.

    Write all of our replacements, one for every mountpoint. Here’s the bones of one:

    -e 's [src] [return] ' \

Replace [src] with what you input into readlink and [return] with what it returns. The space after [return] is important. The build fails without it.

I don't have that in the location they mention. I found a fixup-mountpoints script in another project but I don't know that it'll actually be run if I put it in that location as that location doesn't currently exist.

So that's what I'm investigating currently.

mr_growl

I tried the halium-install script, too, with a ubports rootfs tarball but it stalled while pushing the system.img over adb (stopped at 5% and stayed there).

atarilinux

@mr_growl

That makes sense, and it does seem like that's the error. The good news is that it booted to recovery! Let me know if there is anything you need me to look at or research. I'll try my best to assist in any way that I can!

atarilinux

@JayH

Thanks for keeping an eye on the project! I likewise would like to make the switch. I'm sure others may be in the same boat. Definitely send your thanks to @mr_growl for all his hard work! I'm still learning, but helping when and where I can. Being new at this, I know I can't do this on my own in a resonable amount of time. There is a lot to read up on. With the community involved, I'm sure we can make something great!

mr_growl

Current state of affairs:

New Build Method (the one here: https://gitlab.com/mr-growl/ubports-ubuntu-touch-google-bonito-volte)

Builds successfully
boot.img doesn't boot to anything

What I'd like to research regarding this is:

has any other community port used that method to make a successful android 12 port?
if so, I'd want to compare their repo to mine and see what I've missed.
how are the binary blobs being included in this build method

Old Build Method (the one from the video and the halium website, steps documented here: https://gitlab.com/mr-growl/ubports-ubuntu-touch-google-bonito-volte/-/wikis/Building-halium-12-for-bonito

Builds successfully
boots into recovery
very clear where the vendor blobs need to be added

For this method I need to figure out:

is the fixup-mountpoints script still relevant and if so, why isn't it in the build folder anywhere
are there any obvious flaws with using this method over the new one?

Droidian

Documentation is straight forward
they provide api 32 (android 12L) rootfs zips that can be side loaded
their deployment instructions are more like lineage (which is a good thing)

What I'd like to find out with them is:

has anyone in their community done a successful halium 12 port to any device
why do they have a separate sargo rootfs zip?
will an api 28 rootfs work with halium 12 (12.1 should be api 32)

I think my next step is to do a droidian build following their docs and see what happens. I'm presuming that the boot.img produced should also work for ubports.

Anyways... off to work

Eric H

@mr_growl said in VoLTE Implementation For Google Pixel 3a/3a XL:

New Build Method

It seems you used the standalone kernel method.
Then to install to your phone, you have to apply the process described in Building, installing and running

The boot.img will be flashed onto the boot partition of the phone. The system.img and rootfs.img are interchangable. rootfs.img is pushed to the data partition as ubuntu.img if you didn’t include systempart in deviceinfo’s cmdline. Otherwise, system.img is flashed to your system partition.

About vendor blobs, in your case, they are already installed in a separate partition by android/lineage. UT will find this partition automatically (if you have not modified it)

mr_growl

@Eric-H I had wondered if that was the case (about it just using what was already on the phone). Thanks for that info!

With the stand alone kernel method, I flashed the boot.img but it would not boot into recovery. When i flashed the boot.img from the halium build it did boot the recovery, so I think I've missed something with the stand alone kernel method. I'll have another go at it, keeping in mind what you've said, and see if anything becomes apparent.

Thanks again!

Eric H

@mr_growl
Accordind to the deviceinfo file in your repo, you set systempart, thus you need to flash boot.img to boot and system.img to system (fastbootD might be needed).
And maybe flashing dtbo.img to dtbo is needed too...

Have you access to Telegram? You will find help in the group linked in the porting documentation.

mr_growl

@Eric-H I tried a build without the systempart section (the droidian porting doc said to remove it) and then tried flashing just the boot.img and rootfs.img in fastbootd mode using these commands:

fastboot flash boot boot.img
fastboot flash userdata rootfs.img

Also tried flashing the sytem.img using

fastboot flash system system.img

But that always fails saying it can't resize the partition.

If anyone wants to play with the boot.img, it's in the artifacts from my latest build: https://gitlab.com/mr-growl/ubports-ubuntu-touch-google-bonito-volte/-/jobs/11808428371

But it doesn't seem to do anything useful.

I'll try to get on to telegram (it's not letting me in currently). I'm just guessing on the android stuff at the moment. Trying various combinations of images and commands, re-flashing android 12 inbetween attempts.

Thanks all for suggestions on things to try. Much appreciated.

mr_growl

Might just go back a step and try getting a halium 9 build working, since I know that should actually work. Then maybe increment from there.

Eric H

@mr_growl
I think halium 12 is required for VoLTE.

according to the porting doc and the history of the porting group, without the systempart option you have to

flash boot img to boot, that's ok.
rename root.img to ubuntu.img
push ubuntu.img to userdata with adb
adapt and launch these command in recovery mode
```
adb shell mount /data; adb push ubuntu.img /data/
```
maybe flash dtbo.img to dtbo is required (I suggest to test first without flashing, then flash it if phone does not boot.
do NOT flash system.img

Eric H

@mr_growl said in VoLTE Implementation For Google Pixel 3a/3a XL:

Might just go back a step and try getting a halium 9 build working

The full system method will be discouraged/deprecated very soon
https://gitlab.com/ubports/docs/docs.ubports.com/-/merge_requests/675

atarilinux

@mr_growl

To verify, you want me to see what I can find out on a Halium 12 stand-alone kernel method port. Is that correct? Again, thanks for all your hard work on this!

atarilinux

@Eric-H

Your comments and insight are always appreciated! Thanks for all the help!

Eric H

For information, documentation has been updated.
The "install“ page can be found at
https://docs.ubports.com/en/latest/porting/build_and_boot/standalone_kernel_install.html

mr_growl

@Eric-H Thank you for the detailed instructions. I very much appreciate it.

Here's what I did:

boot into android recovery and do factory reset (to remove encryption)
boot into twrp (fastboot boot twrp.img) and go into terminal
unmount /data (/dev/block/mmcblk0p72)
format /data as ext4 (mk2sfs -t ext4 /dev/block/mmcblk0p72)
remount /data (mount /dev/block/mmcblk0p72 /data)
confirm it is now mounted at ext4 (mount)
push renammed rootfs.img to /data (adb push ubuntu.img /data/)
reboot into bootloader from twrp
boot into fastbootd (fastboot reboot fastboot)
flash boot (fastboot flash boot boot.img)
reboot... this takes me straight to the boot loader
flash dtbo (fastboot flash dtbo dtbo.img)
reboot... still goes back to boot loader

I'm doing the formatting to ext4 bit as I read somewhere that it is required (please let me know if this was a mistake)

I'm pushing ubuntu.img before flashing boot.img because flashing boot.img gets rid of recovery and fastbootd.

I'm still feeling like there's a problem with my boot.img, as if I flash the boot.img from my halium build, it actually boots to recovery and fastbootd.

Eric H

@mr_growl
userdata
yes formating /data to ext4 is required at first installation
Just in case maybe retry with fastboot

fastboot format:ext4 userdata

you can wipe cache partition too

fastboot format cache

What does dmesg -w return on your host computer ?

https://docs.ubports.com/en/latest/porting/build_and_boot/Boot_debug.html

When your device boots it will likely stay at the bootloader screen.
[...]
To confirm that your device has booted correctly, on your host computer, run dmesg -w and watch for “GNU/Linux device” in the output. This confirms that you can establish an ssh connection to the device (see below). If you instead get something similar to “Halium initrd Failed to boot”, skip to telnet connection.

mr_growl

@Eric-H Thank you again!

Here's what dmesg has to say after my last flash attempt:

[ 9780.171034] usb 1-2: new high-speed USB device number 40 using xhci_hcd
[ 9781.164612] usb 1-2: New USB device found, idVendor=18d1, idProduct=4ee0, bcdDevice= 1.00
[ 9781.164633] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9781.164641] usb 1-2: Product: Pixel 3a XL
[ 9781.164648] usb 1-2: Manufacturer: Google
[ 9781.164654] usb 1-2: SerialNumber: XXXXXXXXX

I'll wipe it again and try again with your last message in mind later. I completely forgot to check to boot debug documentation, so I'll have a read through that again as well.

Eric H

@mr_growl
Which kernel do you use ?
in device info,on one of your gitlab repositories, I see
deviceinfo_kernel_source="https://github.com/mr-growl/android_kernel_google_msm-4.9.git"