Hacker News Reader

> Added: I've noticed that Alpine seems to have dispensed with ARMv6 architecture support altogether in the upstream. Unfortunately, this cuts off a lot of the oldest AOSP devices from support - devices that used to run quite well with CyanogenMod, and that ought to still be usable in some way, if perhaps not in a truly general-purpose sense given how limited some of them are (512MB RAM/512MB "internal" storage, etc.). Is there any hope of pmOS picking up this support?

Alpine has support for armv6, it is called "armhf" in the arch list here: https://pkgs.alpinelinux.org/packages

There was some discussion if support for it should be removed, but no decision had been made: https://lists.alpinelinux.org/alpine-devel/6569.html

In theory it would be possible to keep armv6/armhf around in postmarketOS even if Alpine dropped it. But right now we don't have the resources to do that (and if we had, it would make more sense to help out in Alpine to keep the architecture alive there, if they are interested).

> The libhybris support that's mentioned near the end is the most interesting part

I'm more interested in having a device that doesn't require proprietary bits to work.

You can't achieve this without support from the free, mainline kernel, which I've also addressed in my comment; downstream kernels, by and large, depend on these proprietary blobs. Mainline kernel support is also hard; the LG Nexus 5, which is the "flagship" device for pmOS, still doesn't support mobile calls properly.

It just makes sense to split the job and work on the kernel vs. userspace bits independently. Compare with e.g. cyanogenMod or LineageOS; running a non-AOSP userspace gives you something that will run as smoothly as iOS does today, and that (barring kernel or driver bugs, of course) can be updated indefinitely.

Nexus 5 supports calls fine, that's neatly in mainline Linux and in ofono. The issue is that the audio codec in the soc isn't in mainline yet.

The solution for this isn't hybris, it's fixing mainline. Hybris is mainly useful for the impossible stuff like powervr graphics.

Is support for that codec in progress though?

From what I know, one person planned to look into it, but not much has happened since then.

Is there any specific list of things that still has to be done before voice calls are more or less functional for the N900? I looked around the Gitlab but couldn't seem to locate anything. The wiki[0] mentions a requirement of "libcmtspeechdata" but there doesn't seem to be any other information beyond that.

[0] https://wiki.postmarketos.org/wiki/Nokia_N900#Additional_inf...

Yes, I had intended on spending this month on the audio codec for nexus 5 but was deterred by the modem not working. I want to split my time between reverse engineering mediatek baseband and getting a pmos daily driver going with the shelli UI. So hope to come back to the audio codec in about a month. Hopefully somebody comes along and does it before me! :p ;)

There was a lot of progress on the codec part by opendata27 but as you can read in the blogpost, he dissapeared sadly.

The same audio codec is also used for a bunch of sony phones with the same soc (like the Sony Xperia Z2) and Sony does contribute to the mainline kernel so there's hope there.

Wow, that wasn't clear from the report. Getting the audio codec going seems like a much more tractable problem than calling.

I have a bunch of Nexus 5 phones. One even still works.

To my understanding armhf/armv6 is still supported; there was a time when armv7 was introduced where armv6 was dropped and restored shortly after. There was interesting thread in mailing list called "Should we drop armhf (armv6) support with 3.10 release?" but as for now they haven't decided yet if they want to drop it in 3.11 or keep it longer

libhybris is a complicated issue. It can easily be a crutch that sabotages the most key promising quality of the project -- of sustainability of the devices, due to maintainable mainline open source. People can argue about tradeoffs of compromises, but we've seen numerous earlier projects be killed by compromises like that. I'm currently thinking the best bet for PostmarketOS is to try to attract programmers who are committed to the mainline open source goal.