[poleguy]

I bought a PinePhone hoping to be able to start using it and developing on it. But until it can reliably make it through the day, stay connected to the network, and not miss calls and texts, I have to use my android phone and I don't have two sim cards, so I can't really use it and develop on it.

I'm a electrical hardware design engineer.

I agree, that if Pine64 has enough money to fund a full time engineer, that's a much better use than giving any money to the distros. They should be funding an embedded specialist who should focus on board bring up, because clearly we're not out of that stage yet.

I've built lots of high-volume electronics hardware that is easily as complex as a cell-phone, and the order of development is very important. I'm in the middle of such development right now... Working on software and UI is a dead last on that priority list every time.

[goombacloud]

A question to you as someone from the hardware side: Why is it not a focus for hardware devs to build hardware that works with existing software? Why do I always need a special kernel for every arm64 board out there?

Often it's that there are hardware components chosen without mainline drivers, then there is also the problem of each board having a different layout. With arm64 EFI things get better but it's still a difference compared to x86 where you can boot almost any old OS on your newest laptop, thanks to PCI and other standard interfaces.

[ac29]

> A question to you as someone from the hardware side: Why is it not a focus for hardware devs to build hardware that works with existing software? Why do I always need a special kernel for every arm64 board out there?

Because the SoCs used in these sort of boards originally went into things like cheap Android set top boxes and the like. Those customers just need an image that can boot to Android and work well enough, and it is easier for the hardware vendors to hack at their in house kernel branch than to get everything upstream.

[avianlyric]

Cost and power efficiency. If you want cheap portable electronics that have batteries that last forever, then you need to build SoCs that have exact features needed for a specific application and no more.

Maintaining software compatibility would mean sacrificing either price or power consumption. So a manufacturer can choose between spending money rewriting the software, or having to pay anywhere between 15¢ to $100 more per unit. If you’re making millions of units, then savings from using more limited SoCs will quickly pay for an army of software engineers.

[rjsw]

NetBSD builds one kernel for all supported ARM64 devices, there is no reason why Linux can't do the same. The devicetree selected by the firmware provides the description of a particular board.

[tremon]

supported really is key in that sentence. Does NetBSD build one kernel to rule them all because they only support a limited number of very similar ARM64 devices, or is their kernel just more flexible in adjusting itself at runtime?

Also, ARM64 is only one ISA. 32-bit has at least v5, v7 and thumb in wide circulation (though I may be off-target on what's exactly referred to as an ISA on arm).

[capableweb]

> I bought a PinePhone hoping to be able to start using it and developing on it. But until it can reliably make it through the day, stay connected to the network, and not miss calls and texts, I have to use my android phone and I don't have two sim cards, so I can't really use it and develop on it.

I recently also looked at the PinePhone but felt it was too early for me to get involved, because it's very, very clear that you can't actually use it as a day-to-day phone yet, at least that's from what I gathered, but somehow you ended up with the idea that you could actually use it as a phone. I'm wondering if you never looked at their official resources for PinePhone as they make it kind of clear it's not ready to be used in any normal fashion yet?

[chriswarbo]

Not sure what your experience has been, but I've been using mine as my only phone for over a year and it's been fine. Running Manjaro, which it came with (although I've been tinkering with NixOS on an SD card).

It's been a smoother ride than my previous phone, an OpenMoko FreeRunner which I got around 2008. The default OS on that was already abandonware by the time I got it!

[choward]

What's the NixOS experience like? I haven't tried in a while but my phone would get stuck on the NixOS splash screen. How did you install yours? So you have a public repo I could look at?

[chriswarbo]

I used a pre-build image from Hydra. The mobile-nixos project site links to their Hydra jobs:

https://hydra.nixos.org/jobset/mobile-nixos/unstable

That links to the latest build for pinephone aarch64, e.g. https://hydra.nixos.org/build/164693256

That gives the output path, e.g. /nix/store/6py525nywqdbyjs7jy1rm9vw53hmm5f1-pine64-pinephone_full-disk-image.img

We can look up that hash on cache.nixos.org, e.g. https://cache.nixos.org/6py525nywqdbyjs7jy1rm9vw53hmm5f1.nar...

That gives us the download URL, e.g. https://cache.nixos.org/nar/087ljdm30k8wqgdhdjdhc15bmkk01g69...

We can unxz that, then trim the leading bytes according to the Nar file format (described in Dolstra's PhD thesis, figure 5.2, page 93 https://edolstra.github.io/pubs/phd-thesis.pdf ). Since this .nar only contains one file, we can just ignore the header bytes (they're padded to multiples of 8 bytes; I think in this case we need to skip the first 96 bytes). We can do this while dd-ing the image to our SD card, e.g.

    sudo dd if=087ljdm30k8wqgdhdjdhc15bmkk01g69zqvr3gv13sra8pkgk387.nar of=/dev/my-sd-card bs=96 skip=1

This is quite convoluted, but I did this while stuck on a crappy Chromebook ;)

Note that the above images have no usable user accounts. I mounted the resulting SD card and edited the /etc/shadow file to enable root login without a password. I could then log in to a text console, using an external keyboard :)

[choward]

Thanks! I'll try it out again soon and see what happens.

[jcun4128]

Some notes from a Pinephone owner:

Wondering if the thoughts in this thread factor in the Pinephone Pro yet or no? I am looking to get one of those eventually. I think it just started doing pre-orders.

I got a second basic text/call line for my Pinephone but I don't use it as a phone right now. The modem is finicky when it works, seems to need a certain battery charge (like near full). I also have to restart it several times to get the modem to work. I'm using Mobian/Phosh. I'm not 100% a fan of the Phosh look/how it works multi-task wise but it does work out of the box more than a couple other "front ends" I tried. KDE Plasma was pretty but I couldn't just plug in an external monitor and have it work. Overall I like the idea of the phone/want to learn to develop for it. Unfortunately my screen is falling apart/peeling near the top edges. Also the battery even in airplane mode will die within a day or so.

What was neat was running ARM VS Code but it was slow as hell eg. 5 second click lag.

Old screenshot https://i.imgur.com/a7OHjcZ.png

[jcun4128]

Here's a mini rant. Samsung Galaxy Buds. Bluetooth Headphones. I had to accept/enable like 10+ permissions just so I could turn off the default equalizer that makes everything sound bassy. That is annoying.

I can't deny that my $300 Android phone I'm using now would run circles around Pinephone Pro but I still look forward to that idea one day.

[Underphil]

I can't quite understand what you're saying here. A PS5 devkit can't make calls but it's still developed for. Why does a phone need to be your daily driver to be able to develop for it?

I call tell I'm obviously missing something here and happy to be called out.

[spicybright]

A PS5 dev kit functions as a full PS5 though, so you can be reasonably certain a game developed for it will work on a real PS5. You can test it like someone playing a PS5 would by sitting in front of it with a controller.

A phone that has trouble with basic features you're expecting a final product to get right is much more effort. If you're not going to be using it like a normal phone daily, you won't find certain bugs.

What if your map app crashes when the GPS location jitters too much like in the real world? Or gives inaccurate results when you walk next to high current power line that screws with it's internal compass? It's nearly impossible to simulate day to day usage to catch these things.

But sure, you can develop for it now. But when bugs with basic features you rely on happen, you'll have to make a guess whether it's your code or the phone's bug.

Then when bugs are either fixed or deemed not OS issues, you'll have to re-test and re-develop parts of your code to cope with that over and over.

A proper working dev kit that works as a day to day phone is much more worth developing for, unless you're REALLY into the pinephone and don't mind extra work.

[Underphil]

That's a fair and measured answer. I sit corrected. Hadn't considered it from that point of view.

[magicalhippo]

> I don't have two sim cards

Having a twin SIM card is rather cheap here, and would be a decent option for something like that. I've gotten one for tinkering with a Raspberry Pi 4G module.

I totally agree with your point though.

[ironmagma]

Are these firmware-level issues that can be fixed by flashing a ROM somewhere? Or something endemic to the chip that has no hope of being fixed?