[gggtt]

Because this era of "separate parts" comes to an end. Now everything is single SoC that are only compatible with big tech proprietary OS.

Google has on purpose made Android different enough so that no Android SoC could run mainline Linux.

Today, no decent SoC can run real Linux, the "best" SoC that can run mainline Linux are :

- Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.

- NXP (Librem 5) which are thick power hungry slow SoC (because they are made for automobile I guess)

- Broadcom (Raspberry Pi) which is still super slow compared to most modern smartphone.

In any case the manufacturers of decent SoC don't give a crap about Linux, they only support Android and any Linux support must be done by someone else, often through reverse engineering.

This is a totally anticompetitive situation which is far from what we had on the desktop side.

But even on the laptop/desktop side, this is also coming to an end : Microsoft custom chip & Surfaces, Apple M1, etc. Soon this will be the same as on mobile.

FairPhone makes no special effort about the choice SoC, they just use a SoC which supports Android and which obviously doesn't support Linux.

On the other hand Librem & PinePhone use the only SoC that have Linux support, and they often must develop support themselves through reverse eng. because the manufacturer doesn't care.

Unless we pass laws about it or unless Pine64/Purism become very successful, it is the end of any hope for alternative as no mobile device is able to run anything else than IOS & Android (or HarmonyOS, Fushia or whatever next privacy hell OS is coming from those big tech)

Even in Planes & Cars , the entertainment systems are now powered by Android and not Linux.

Mainline Linux will disappear until it only exist in a emulated VM running on a M1 mac, or on a headless datacenter server.

Purism & Pine64 are currently our only hope for alternative and I encourage anyone to support them. They represent the ugly reality of what is available to the competition, it is slow, thick, power hungry and old but that's all we have.

[mswann]

> Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.

PinePhone has Allwinner A64. [0]

And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).

[0] https://wiki.pine64.org/wiki/PinePhone#Specifications

[StillBored]

But the point is your looking at a SoC with A53's, which is a 9 year old in-order design. Or for that matter, the rk3399's A72's which is a 5 year old design. That puts them at somewhere between an 6x->4x (geekbench) slower per core vs a modern smartphone depending on which benchmark you compare.

Then you add in the overhead of not being a mobile optimized OS, and your also burning massively more power.

The market share for these phones will remain geeks who want to have a more "open" phone and are willing to deal with a slow, buggy, inefficient device.

Frankly, this won't change until Qualcomm/etc decide to make their SoC's more open, so that smaller companies can build products like these without signing piles of NDAs and shipping android BSP kernels. But then again, that might cut into their business because they won't be able to deprecate 2 year old phones by simply refusing to provide security updates.

Most geeks would be better off picking up a year or two old phone and running lineageOs. At least the devices tend to work, even if they have a dozen or so proprietary blobs.

[mswann]

Yes, unfortunately you're right in that there's lots of room for improvement. Nevertheless I'd call the rk3399 a decent SoC, but then for me the fact that it runs without proprietary firmware is certainly more important than pure performance. What I'd really like to have though, is more RAM - I run my desktop on the rk3399. And I already use the PinePhone as a daily driver although I see that it's not there for most of the people.

But maybe this could not only change at the big vendors' whim, but also if more people express their wish for systems that are less locked in by changing their priorities.

[CameronNemo]

Rockchip certainly does not have access to the smaller processes or newer designs like Qualcomm and Samsung do.

But at least their new SoCs will have A55 and A76s! It's progress, no matter how slow.

Maybe we will see an rk3566 tablet out and about one day.

[megous]

> And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).

Last time I tried, RK3399 was dog slow to boot on Pinebook Pro (only thanks to https://gitlab.com/DeltaGem/levinboot is this changing) and development once Google stopped doing it seems almost entirely stagnant. Just look at ATF history, or U-Boot history, etc.

Pinebook Pro doesn't suspend to ram to this day. Only whatever Google implemented for their chromebooks works.

[CameronNemo]

My PBP with mostly stock uboot and kernel boots in ~15 seconds.

Not great (especially without s2ram) but not 'dog slow' in my opinion.

No altmode typec in mainline is a big issue for me. Very sad that there is no usable video output.

[megous]

U-Boot has no business taking > 1-2s to boot PBP. More than that is kinda ridiculous. I was shocked seeing it take 8s when I first booted Manjaro. (My allwinner boards boot in ~2s, and those are all way slower than RK3399) With some older levinboot version, PBP boots to initramfs FDE password prompt in ~4s [1]. It's probably even faster now. I wish it would take 2s to that prompt, because then I can open PBP, enter password right away, and then just do something else waiting for the desktop to load. But 3-4s is already pretty nice.

[1] https://xnux.eu/log/#015

At least suspend to idle works as a sort of replacement for suspend to ram. PBP can stay for long enough in that state, so it's usable on the go even without suspend to RAM.

[mswann]

Haven't heard of levinboot yet, LGTM, thanks for the hint! Where do you get your entropy from? Does levinboot provide some (enough?) to the kernel? Right now I delay booting via a sleep in the initramfs so that I have time to randomly press as many keys as possible to get crng initialized before cryptsetup is called. Configuring my U-Boot build to provide entropy to the kernel is still on my to do list, haven't looked into it yet and don't know whether it already does or not. At least last time I checked I observed that KASLR didn't work due to missing entropy (the artificial delay won't work here as KASLR happens way before calling init).

[megous]

It's in the feature list: https://gitlab.com/DeltaGem/levinboot

> providing entropy to the kernel (KASLR and RNG seeds) via the DTB

I might as well add this feature to p-boot too. :)

[fsflover]

> Purism & Pine64 are currently our only hope for alternative and I encourage anyone to support them.

Detailed comparison: https://forums.puri.sm/t/comparing-specs-of-upcoming-linux-p...

[gcblkjaidfj]

> Google has on purpose made Android different enough so that no Android SoC could run mainline Linux.

daily reminder that this is only possible because the very people in this site, "did not care about GPL or tainted kernel" as long as they had their nvidia GTX working to play quake.

ha!

[dgfitz]

We must have different definitions of “real Linux” if you think this. For example NXP makes arm chips [1] and I have put a bitbake OS on there that I absolutely considered “real Linux,” 4.18 kernel, coreutils etc.