5 ms·

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,

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.

ironmagma 5y ago
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?
magicalhippo 5y ago
> 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.
capableweb 5y ago
> 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 5y ago
  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 5y ago
    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 5y ago
      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 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 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.narinfo https://cache.nixos.org/6py525nywqdbyjs7jy1rm9vw53hmm5f1.nar... That gives us the download URL, e.g. https://cache.nixos.org/nar/087ljdm30k8wqgdhdjdhc15bmkk01g69zqvr3gv13sra8pkgk387.nar.xz 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 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 :)
goombacloud 5y ago
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.
- rjsw 5y ago
  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 5y ago
    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).
- ac29 5y ago
  > 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 5y ago
  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.
Underphil 5y ago
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 5y ago
  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 5y ago
    That's a fair and measured answer. I sit corrected. Hadn't considered it from that point of view.

ironmagma 5y ago

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?

magicalhippo 5y ago

> 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.

capableweb 5y ago

> 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 5y ago
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 5y ago
  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 5y ago
    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 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 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.narinfo https://cache.nixos.org/6py525nywqdbyjs7jy1rm9vw53hmm5f1.nar... That gives us the download URL, e.g. https://cache.nixos.org/nar/087ljdm30k8wqgdhdjdhc15bmkk01g69zqvr3gv13sra8pkgk387.nar.xz 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 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 :)

goombacloud 5y ago

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.

rjsw 5y ago
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 5y ago
  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).
ac29 5y ago
> 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 5y ago
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.

Underphil 5y ago

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 5y ago
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 5y ago
  That's a fair and measured answer. I sit corrected. Hadn't considered it from that point of view.