Most parts work, still not sure why Bluetooth gives me errors in dmesg, audio out works, microphone input not yet… I’m getting there.

But graphics, charging, low standby power consumption, LTE, wifi… those all work already.

The fact that postmarketOS has support and also that there are people working on mainline support, makes this a task that is not as difficult as I thought, as most work was already done for another distro.

Otherwise it runs more fluid than Android ever did on it and it has a great standby time (forgot to turn it off at around 80 % and a few days later it was at 58 %).

For now stuck on merging the Kernel patches from the sdm670-mainline project with those from Mobian, not really something I can do without knowing C. I just hope someone with the right skills does it at some point.

Then I just need to make some smaller merge requests, like one to add a udev rule for vibration support and so on.

Not much missing before I can finally use it as a daily driver.

  • poVoqM
    link
    fedilink
    142 months ago

    Excellent! As nice as PmOS is, Mobian seems more at home for me and I am definitely looking forward to try it on my Fairphone 5 sometimes in the nearish future.

  • @lemmy_user_838586
    link
    11
    edit-2
    2 months ago

    Awesome work! If you don’t mind me asking, what help/sources did you use to get this far in porting efforts? I have some free time on my hands and would like to try porting a newer phone such a pixel 4a or similar

    • @erebion@lemmy.sdf.orgOP
      link
      fedilink
      162 months ago

      Oh, I don’t mind questions. :)

      Help: A lot via the Mobian Ports ( #mobian-ports:matrix.org ) Matrix room and the postmarketOS offtopic ( #offtopic:postmarketos.org ) Matrix room.

      Sources: Not much there yet. As soon as there are official builds for the Pixel 3a, I will start writing docs. I already have a lot of notes on what I had to do. But first I need to have someone merge the Kernel patches, as I don’t know C, which makes resolving merge conflicts really hard, it turns out. Once that is done, there are just a few smaller merge requests left and builds will appear magically.

      The whole process is not that difficult if there are already Kernel patches available. In the case of the Pixel 3a, I only had to clone the sdm670-mainline repo ( https://gitlab.com/sdm670-mainline/linux-patches ) , compile the kernel (two commands) and get a .deb, which I used with mobian-recipes ( https://salsa.debian.org/Mobian-team/mobian-recipes/ ) to build an image. I then wrote a config file for droid-juicer ( https://gitlab.com/mobian1/droid-juicer/-/merge_requests/4 ) which tells it what files on the vendor and modem partitions it should get, then those are copied to /usr/lib/firmware/updates/.

      That was easy as dmesg will just tell you what files it cannot load because they are missing. Just find those, write the config, run droid-juicer, reboot… boom. Display, Wifi, LTE and so on working.

      Then smaller stuff like udev rules for vibration and an initramfs hook ( https://salsa.debian.org/DebianOnMobile-team/qcom-phone-utils/-/blob/debian/latest/initramfs-tools/hooks/qcom-firmware?ref_type=heads ) so that firmware files get integrated into initramfs and components start to work early during boot.

      The most difficult part would be merging the Kernel patches with other patches and resoving the merge conflicts… At least to me, as I don’t know C.

      If there are no mainlining efforts for a phone yet, then I don’t know what to do, as that requires a Kernel dev.

      For the Pixel 4a you mentioned, there is a postmarketOS port. So this should be doable. ( https://wiki.postmarketos.org/wiki/Google_Pixel_4a_(google-sunfish) )

      That’s all not that hard, my main difficulty was finding out what to do. Everything I did so far would be an afternoon of work, if I had just found the necessary information much quicker. Instead I spent two weeks, of which 95 % was finding info, lol.

      Just join the Mobian Matrix room, we should be able to help you, even though I know far less than the others there…so far. :p

      I do hope that’s helpful and I’ll happily try to answer more questions. :)

      Kernel mainlining effort for the SoC in thr Pixel 4a: https://github.com/sm7150-mainline/linux

      • @version_unsorted@lemm.ee
        link
        fedilink
        32 months ago

        I know C and I have a pixel 3a. I could probably help out with the kernel patches if you want. I’m not totally clear what work needs to be done. You just need someone to help get those patches merged against the mobian upstream kernel?

        • @erebion@lemmy.sdf.orgOP
          link
          fedilink
          21 month ago

          Cool! Well, it’s just a merge conflict. I don’t knoe how to combine the patches. Should be pretty easy for someone that does not need to google for every line of C.

          I can give you notes* later on what to do to get to the conflict, then maybe you can resolve it and push the result to some repo? :)

          *Just 3 or 4 commands, I think, including the Debian gbp command

          • @version_unsorted@lemm.ee
            link
            fedilink
            21 month ago

            Yeah sure. I’ll pull it all down and reproduce and try to get the conflicts sorted out and push the repo up somewhere. I’ve never built a Debian kernel before but I’m sure I can figure it out!

            • @erebion@lemmy.sdf.orgOP
              link
              fedilink
              2
              edit-2
              1 month ago

              So, a lot of commands, but not very complicated:

              git clone https://gitlab.com/sdm670-mainline/linux
              cd linux
              git remote add mobian https://salsa.debian.org/Mobian-team/devices/kernels/qcom-linux
              git remote add kernelorg https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
              git fetch mobian
              git fetch kernelorg
              git checkout mobian-6.7
              git checkout -b mobian-6.7.2
              gbp pq import             # so you end up on the `patch-queue/mobian-6.7.2` branch with all the patches in debian/patches applied
              gbp pq switch             # switch to patch-queue/mobian-6.7.2
              git rebase v6.7.2
              gbp pq rebase             # (rebases the patch-queue branch on the now-rebased `mobian-6.7.2` branch)
              
              git checkout origin/on-stable
              git checkout -b temp-sdm670
              git rebase patch-queue/mobian-6.7.2
              # this is where I got and get the conflict, the rest *should* be correct
              git checkout patch-queue/mobian-6.7.2
              git merge temp-sdm670
              gbp pq export # switches to mobian-6.7.2
              #all new patches should be straight under `debian/patches`, create `debian/patches/sdm670` and move them all there
              mkdir -p debian/patches/sdm670
              mv debian/patches/*.patch debian/patches/sdm670
              #edit `debian/patches/series` to:
              #1. reflect that files have been moved to `sdm670/`
              #2. ensure patches from the `ath10k`, `debian` and `mobian` folders come last in the list 
              # commit changes (this commit will be amended afterwards)
              vim debian/patches/series
              git add -A
              git commit -m "added patches from the sdm670-mainline repo"
              gbp pq drop
              gbp pq import
              gbp pq export --drop --renumber
              
              # push the branch somewhere
              

              I’ve added some comments to hopefully make it easier to figure it out

  • @lemmeee@sh.itjust.works
    link
    fedilink
    72 months ago

    Impressive! I’m looking at postmarketOS wiki and it’s amazing how many phones are supported now. But it seems they are not working as well as PinePhone or Librem 5 yet.

    forgot to turn it off at around 80 % and a few days later it was at 58 %

    Damn, I wish my PinePhone was this energy efficient!

      • @PowerCore7@lemm.ee
        link
        fedilink
        42 months ago

        A64 (the SoC for PinePhone) is mostly intended for set-top boxes (i.e. smart TV), so it is really not designed for power efficiency.

        It’s really a bummer that most “smartphone” SoCs cannot easily be purchased, and have no proper documentations. Thinkers and smaller manufacturers are stuck with mostly Allwinner and Rockchip SoCs (most of which are engineered as embedded processors) if they want to design something from starch at all.

        • @lemmeee@sh.itjust.works
          link
          fedilink
          3
          edit-2
          2 months ago

          That’s what I thought and it seems like even those SoCs didn’t have very good mainline Linux support.

          Edit: I wonder if it would be possible to take some newer Rockchip SoC and underclock it so that it uses less power? Maybe that would help a little and it would still probably be faster than PinePhone Pro.

      • @lemmeee@sh.itjust.works
        link
        fedilink
        12 months ago

        The keyboard addon helps a lot, but it makes the phone big and heavy. I wonder what it’s like with those extended battery cases that you can buy or 3D print.

  • Brad Boimler
    link
    fedilink
    English
    62 months ago

    Wish more newer pixels could get support I have tried and failed many times outside of my skills unfortunately.

    • @erebion@lemmy.sdf.orgOP
      link
      fedilink
      4
      edit-2
      2 months ago

      You could join the Mobian Matrix room or the PostmarketOS room I have mentioned in another post on this thread (or whatever the right term is… Comment on a post? Sub-post?). I did not know anything about porting two weeks ago, but asking dumb questions helps learning.

      • Brad Boimler
        link
        fedilink
        English
        32 months ago

        I have joined it and asked like I said above my skills at least for now I’ll give a go again when I get time busy with college right now.

  • @mrshy
    link
    42 months ago

    Really interesting install here. I’m keen on developments to Mobian and related hardware.

    • @smileyhead@discuss.tchncs.de
      link
      fedilink
      3
      edit-2
      2 months ago

      Phosh was created from scratch, while Gnome Mobile is attempt to port existing Gnome to well… mobile and ultimately share same binaries.

      • maryjane :fediverso:
        link
        fedilink
        22 months ago

        @smileyhead

        Both use the underlying stack:
        gnome-session, g-c-c, network and modem manager, etc.
        And both follow the gnome design patterns for mobile.
        But the shell’s themselves, gnome-shell and phosh are different, phosh is written in gtk and gnome-shell is not.
        So sharing code between the two shells is hard.

        @Cwilliams

    • @linmobM
      link
      English
      22 months ago

      Very much not. GNOME Shell Mobile was funded by the German Prototype Fund in 2022 IIRC, way later than Phosh was created (funded by Purism for their Librem 5). GNOME Shell Mobile will eventually be part of GNOME proper (meaning it’s Mutter, and GNOME Shell, patched to work on small devices), currently it’s a patch set on top of multiple GNOME components that’s packaged in postmarketOS and the AUR (if you consider AUR stuff packaged).

      Phosh was created on based on wlroots (which is also used in Sway and other wayland-native window managers) and GTK3, as a Mobile Shell. Ironically, this way was pursued because Purism developers where told by the GNOME Shell people that an adaptation of GNOME Shell for Mobile would not be feasible.

      Both rely on designs created by (at least then) Purism-employed designer Tobias Bernard IIRC, and thus may seem quite similar despite being based on a different tech stack, and both are hosted on GNOME’s Gitlab, using all the same apps.

  • thejevans
    link
    12 months ago

    Excited for this! I already have a Pixel 3a on the way to try out Ubuntu Touch.

      • @erebion@lemmy.sdf.orgOP
        link
        fedilink
        12 months ago

        Not exactly. But while UBPorts has a good looking user interface, they don’t have many UBPorts apps yet. A regular distribution can often be more useful, but as always it depends on the use-case.

    • @erebion@lemmy.sdf.orgOP
      link
      fedilink
      72 months ago

      Those are impossible to hard brick in my experience, you would need to break both bootloaders and recoveries. See if this helps:

      https://flash.android.com/welcome

      Also, Pixel 3 has different hardware, but is supported by pmOS and I’ve spotted some commits in Mobian, so there might be people working on it there.