Manjaro ARM Beta32 with Phosh (PinePhone / PinePhonePro)

ARM Releases
, ,
1

Manjaro ARM Beta32 of Phosh for PinePhone!

The Manjaro ARM project is proud to announce our Thirtysecond BETA release for the PinePhone running Phosh!

image

Those images run the 6.1 or 6.2 kernel from Megi.

Features:

  • Camera app with access to back and front camera, including autofocus
  • Auto-Rotate function and manual rotate
  • Welcome wizard for easy setup of the device
  • We have now a working Torch in the quick-access-menu
  • Prime phone functions working, including resume from deep-sleep and free speaking
  • Recording of audio works
  • Most applications got added to scale-to-fit
  • Haptic feedback functions are given
  • Optimized keyboard layout for terminal
  • Maps working with geolocate
  • Volume buttons working
  • Sensors fully functional
  • Easy access to Bluetooth, Wlan, Rotate and Mobile functions via quick settings
  • Default branch is arm-stable. This can be changed by editing /etc/pacman-mirrors.conf
  • usage of callaudiod for better audio experience with calls
  • This image uses a Crust enabled uboot (Pinephone only)

Changes since Beta 31

  • Kernel is now at 6.1.28 for the Pinephone.
  • Chatty is at 0.7.3
  • callaudiod got renewed to 0.1.9
  • feedbackd is at 0.2.0
  • Gnome Apps got updated to latest 43 or 44 series
  • Firefox is renewed to 112.0.2
  • phosh is at 0.27.0, phoc at 0.27.0 and phosh-mobile-settings at 0.27.0
  • pipewire got renewed to 0.3.70
  • Mesa got updated to 23.0.3
  • Pamac is at 10.5.1 and libpamac at 11.5.3

A detailed list of package changes can be found here.

Currently broken:

  • GPS may not work as it should

Known issues

  • During a Call the Mic can’t be muted on Pinephone and PinephonePro
  • UI becomes unresponsive after a while.
  • Doing a recording may result in noisy audio savings
  • Lots of apps are still missing or are not mobile friendly yet.

Download:

Device Phosh
PinePhone (Pro) Beta32
PinePhone (Pro) Nightly

About the device:
PinePhone:
Perhaps you’re in a line of work where security is a must, or a hard-core Linux enthusiast, or perhaps you’ve just got enough of Android and iOS and you’re ready for something else – the PinePhone may be the next Phone for you. Powered by the same Quad-Core ARM Cortex A53 64-Bit SOC used in our popular PINE A64 Single Board Computer, the PinePhone runs mainline Linux as well as anything else you’ll get it to run.

The purpose of the PinePhone isn’t only to deliver a functioning Linux phone to end-users, but also to actively create a market for such a device, as well as to support existing and well established Linux-on-Phone projects. All major Linux Phone-oriented projects, as well as other FOSS OS’, are represented on the PinePhone and developers work together on our platform to bring support this this community driven device.

Order

Pinephones Beta Edition are still on stock. Visit the Pine64 Store

How to install:

Download the image/xz file from the download location. Verify that the download completed successfully.

After that, install Etcher (sudo pacman -S etcher if on Manjaro) and burn the to an SD card (8 GB or larger).

The PinePhone should recognize the SD card as a bootable device and boot from it.

The premade users are:
User: manjaro
Password: 123456

User: root
password: root

Donate!

Please consider supporting Manjaro ARM directly via Patreon, Ko-Fi or Open Collective.
You can also donate to our upstream, which is Arch Linux ARM.

Bugtracker

If you face issues with this editon, please open a new issue on our bug-tracker

Development Changelog

We will list our progress to Beta33 here

  • Beta32 (2023-05-27) Download
    • based on stable branch
  • Bonus (2023-05-29)
    • we worked with Megi on DRAM frequency scaling for the Pinephone Pro which saves 0.5W of power!
      • you need the following packages: kernel, firmware
      • switch to unstable branch and update your software or try with a daily-build
      • install both after extraction to your PPP and reboot
  • Dev (2023-05-30) Download
    • based on unstable branch
    • Known issue: xdg-desktop-portal-gnome gets installed as a dependency. Remove it as applications may start slower than needed.
    • Gnome Shell and Mutter got updated to 44 series
      • most applications are now ported to GTK4
    • Kernels got updated to 6.3 series
    • alsa-ucm-conf 1.2.9 included a broken PP UCM config.
      • We are using the working from Mobian still
    • Firefox is renewed to 113.0.1
    • Megapixels gained support for newer kernels
    • Python got updated to 3.11
    • Systemd is now at 253.4
  • Dev (2023-05-30) Download
    • based on unstable branch
    • Kernel got updated to 6.3.5
      • fixed regression in Pinephone power consumption during sleep (touchscreen was not disabled properly, consuming a lot of power)
      • added DRAM reclocking support to Pinephone Pro (needs Rockchip TPL/TF-A)
    • updated uboot to 2023.07-rc2 from megi-branch
    • Phoc got updated to 0.28.0
    • Phosh and Phosh-Mobile-Settings got updated to latest git-master commits to match phoc
    • Gnome-Control-Center is at 43.6
    • Megapixels now supports newer kernels and got updated to 1.6.1
  • Dev (2023-05-02) Download
    • based on unstable branch
    • Phosh got updated to 0.28.0
    • Phosh-Mobile-Settings got renewed to 0.28.0
  • Dev (2023-05-06) Download
    • based on unstable branch
    • updated uboot to 2023.07-rc2 from megi-branch
2 Likes
2

Thanks again. Phosh (and Gnome apps) are better than ever once again.

With this release I do have lot of difficulties with apps “from other platforms” like Nheko, Angelgish, Pure-Maps, Kweather, Plasma calculator etc.
They tend to crash really easily - was there some big QT update as we speak?
I did have to poke around with official repo, aur, flatpak and git installations to find out working apps but they are okayish now. Far from Beta 31 because that was pure gold.

Now Manjaro comes with pulseaudio as a sound server. Have you considered if you ship it with pipewire-pulse, pipewire and pipewire-media-session? Afaik there would be no downsides to this (except that pipewire-media-session is not the future) and this way adjusting the volume during calls works trough volume buttons.

3

This release seems to fix the reproducible core dump with youtube video playback in ff i reported in beta31. I did not reflash simply updated.

It also seems that general video playback performance in ff has been improved, which is a very welcome update.

4

We are currently internally discussing if we should provide the uboot firmware with binary blobs from Rockchip to improve power consumption. Personally I’m totally for it if it improves usability for the users.

5

Never heard of this, care to provide any links? Is this some proprietary magic in addition to cpuidle support?

Improved power consumption is of course nice, but it should be noticeable if it means putting closed software running on the deepest level. Not a good show from rockchip if they require secret sauce to achieve designed power consumption.

6

2023–05–25: DRAM frequency scaling on Pinephone Pro saves 0.5W of power! Jobs · manjaro-arm / packages / core / uboot-pinephonepro · GitLab

7

much slower boot (just the DRAM init blob itself delays boot by 3s doing some training)
much slower TF-A startup

So not only is this a proprietary blob, it also slows down the boot significantly. I am not convinced this is an improvement. It might be better to wait for this to be reverse-engineered so the frequency scaling can work without running a blob that spends 3 seconds at bootup on who knows what.

8

I pushed it anyway to give it some wider testing. In the end having a better battery life is the benefit here, not the boot time, as mostly that happens only once.

9

I actually have to reboot my PinePhone quite often for various reasons. (It is an original PinePhone, so this change is not going to affect me, but it is going to affect the PinePhone Pro users.)

10

good to hear it is only ppp this relates to. One more reason to put it on the trash list and hope for a 3566 pp2 hopefully with open software.

11

I always don’t get it when people are against binary blobs or proprietary software. Sometimes the manufacturers want to save their intelligent property (IP) to stand out from the mass and market. Sure for Linux users it is better to have less blobs involved. However, if Nvidia hardware is used, most use the proprietary drivers to get the best out of the hardware.

Now why wait when there is a working solution by using the blobs to get longer and efficient battery life on the PPP. Give it a test drive and see what it brings to the table. If someone can figure it out what in the other code Rockchip provides in the T-FA code is missing, well even better. For sure if there is a FOSS solution on pair with the current one, we can switch to that. Also the used PKGBUILD is written in such a way that a pure FOSS firmware is possible to build.

12

If I wanted binary blobs, I’d get an Android phone.

13

I agree, even I do prefer full FOSS whenever I can, I also believe that having a functional hardware with good enough performance is important, after all, the more people using a device, the more attention it gets and the more devs will want to build software for it.

So why not to have both? Even when the blob requires a kernel patch to be applied, Manjaro ARM could simply provide 2 extra packages, being one for the uboot using the blob and another being the linux kernel with the patch applied as a dependency of the uboot one. That way each person can decide whenever to use the blob one or not, and just for the sake of the hard FOSS community members, the FOSS version could be kept as the default one just like it’s done with the Nvidia drivers :stuck_out_tongue:

Those who really needs the battery efficiency to daily drive the PPP (maybe as an upgrade of the original PP) will be able to have it, and those who prefers to wait for a FOSS improved driver can kept it as is.

It could even be set as an option on the first boot configuration wizard so non-technical users can decide by themselves and get the benefits of whatever option they prefer.

PS: If there is any way to get the hardware video decoding working on the original PP by doing something similar to this, sign me in! the most annoying thing on the original PP for me is that I can’t watch any youtube video on it without draining 1/3 of my battery with just a few minutes of video :confused:

14

Well we are talking about firmware here. If we look at the license Rockchip provides for the linux-firmware “sources” you see that all those firmwares are in binary form, even they only provide one blob there. On their own repo they have more blobs provided. The license for that repo you have to look for in clones.

Here are some licenses from AMD for ucode, amdgpu and sev. If you take a look at the tree just for amdgpu you see a lot of blobs. People know that AMD is heavily invested in opensourcing their drivers, but their secret sauce is still in their firmware binaries. For a distribution the following lines of a license is very important to be able to redistribute it without any law suits happening: ... Permission is hereby granted by Advanced Micro Devices, Inc. ("AMD"), free of any license fees, to any person obtaining a copy of this microcode in binary form ... So it must be always clear on how you may been able to ship those needed parts of the software to your users.

In each licenses you may also find this, like Rockchip has for its rkbin, which is forbidden: decompile, reverse-engineer, dissemble, or attempt to derive any source code from the Software;

Lets take a look at TF-A: Trusted Firmware-A (TF-A) is a reference implementation of secure world software for Arm A-Profile architectures (Armv8-A and Armv7-A), including an Exception Level 3 (EL3) Secure Monitor. It provides a suitable starting point for productization of secure world boot and runtime firmware, in either the AArch32 or AArch64 execution states. In our case BL31 is the code we should look at. Since it is a platform many projects and companies can reuse given code and don’t have to start from scratch. Since the license is BSD with reference to GPL2 and MIT for some components, companies don’t have to publish their code if they add something on top. This makes sense to protect their intelligent property (IP). So as long as a company provides something in binary form without license fees, which they could do also, all is fine from a distribution point of view. Otherwise you need to count your users, create stats of which version is used and have to track users to have the needed figures for paying fees correctly. Some may assume those fees are already paid by the hardware manufacturer, which is mostly wrong as the software distribution entity most likely have to pay it, as it is the last entity providing the software product to the end users.

Which means, having it in the free reference code is always a plus to have, but not always given. Another aspect is to have the source code for security fixes and validation. Companies tend to fork something once, put their own code on top but don’t want to maintain code changes upstream does. In the end a binary blob can be still based on outdated reference code which may have security issues not fixed, even those are in upstream code.

So it is always a tricky question what to provide as default, as you have many aspects. At Manjaro we always tend to be practical and make the more logical software part default, which has the most benefits for the end users, regardless of binary blobs or available source code.

The PKGBUILD is now designed to default to the binary blob but it can also compile the FOSS TF-A reference code as needed. Our kernel has a patch applied to work with the binary blobs, when found and also works without it. So by installing the firmware the user decides which functions he enables or not. However we didn’t decide yet if we provide both ways of the firmware. For now we have only the binary blob combo in our unstable branch.

15

I agree in general, if hardware requires binary blobs to function properly, better use them and better manjaro provides them. This does not change the fact that we should strive away from such with projects like the pp. AFAIK it only needs binary ADSP and camera firmware. ppp is a step towards the worse, as it also needs a blob for power management.

ADSP blob is not a security issue on same level as power management blob as first runs on modem signal processor, second on main SOC. camera firmware runs on the camera, so it also has no security implications.

16

Well, we can debate this as long as we want. The alternative modem firmware shows that the given modem can be tweaked to a better state by using a different approach. If that firmware is legal in all countries depends. As long as you’re able to redistribute a software in source or binary form you are fine as a distribution. The user can do whatever he wants, if he is able to do so.

Sure, the approach should be always targeting the open software code and avoid binary blobs. Also for security reasons as stated before. But if you aim the PPP to be your daily driver, every Watt you gain brings that more to a reality. Linux on phones is still early stages and hopefully a vendor with a more open mindset will choose hardware components which are more open also on the software side.

PP uses Allwinner SoC, PPP is using Rockchip. Both companies act differently regarding FOSS and Linux in general.

Maybe check the history of PP and how that started regarding firmware and what changed over time.

We have now two packages:

  • uboot-pinephonepro (full FOSS with reference TF-A compiled from source)
  • uboot-pinephonepro-rockchip (includes the binary blob from Rockchip to enable power savings)
17

Unfortunately, both companies act quite poorly in that respect. (See, e.g., GPL Violations - linux-sunxi.org .)

18

Well, don’t get me started on Qualcomm :small_airplane:. Linaro and Collabora are both companies partly paid by the manufacturers to open source things to the mainline kernel and other upstream projects. However there are always binary blobs for some IP parts involved. It is a common practice and mostly ignored by FOSS and the Linux Foundation. Having 80% already opensourced is better than none it seems to some of them. Also more and more companies join those foundations which “control” the violations …

19

8 posts were split to a new topic: What implementation of xdg-desktop-portal should be used? Is it -gtk for phosh?