Something to try if you have a pinephone and want to experience sub-second boot times.
Anyway, if you like bringing up new hardware, or optimizing things, this is as good an opportunity as it gets to get pinephone and have fun. There are lots and lots of areas that can be optimized and improved in usersapce and in the kernel and you can do whatever you fancy or want to learn about. It's all being developed by random people on the internet. ;)
That is extremely cool. One point of hopefully constructive feedback: It's not clear to me how I can use this, or even if I can use it without re-engineering my system (i.e. can this be applied to an existing postmarketOS/ubports/whatever image, or does it have to be integrated into the image build process?). I'm perfectly comfortable using dd to overwrite a boot sector (heck, that's the syslinux install process on x86), but then do I just poke through my boot partition and build a config file that points at my existing kernel+initrd?
I'll add some tutorial file to the repository later on. Eventually yes, you'd also be able to use this the way you described if your boot partition will be a FAT partition.
ATM, p-boot uses its own filesystem format optimized for quick and simple loading of data from storage during boot.
So you'd have to either use some spare partition (for example if you have swap partition on eMMC) or replace the existing boot partition contents with this filesystem. (It must be a MBR style primary partition, not GPT)
Then it's just a question of writing p-boot.bin somewhere (preferably uSD card, so you can go back to your original bootloader easily) And writing a boot partition using the p-boot-conf command as is described in the README, with a single boot config file like (that you'd have to modify this to match your OS):
Actually, p-boot will search for the boot partition also on the uSD card if it doesn't find it on eMMC, so if you have your OS on eMMC, you can try p-boot without touching your eMMC OS installation at all. You'd just place p-boot.bin and its custom boot partition on SD card. You'll lose some boot speed this way, since uSD card read speed is 24MiB/s but eMMC is typically 84-88MiB/s
So in short:
- find a space for p-boot boot filesystem partition
- figure out a config file for your system's boot configuration
- format the boot partition using p-boot-conf tool
- dd the p-boot.bin to the boot location on SD or eMMC (or both)
- (you can do all this with just a spare SD card, while the booted OS is on eMMC, and roll-back by just removing the SD card)
^^ Well deserved self-promotion too. Quite a few of the mainline Linux patches for pinephone are written by megi, and iirc they were also one of the first to get calling working.
I haven't had a lot of time to invest in working with my PinePhone yet, though I've heard a ton of improvements have been made since the last build I tested.
It's still kinda crazy to me that you can just now finally buy a phone that you can just... install a bunch of different OSes on, and not encumbered out of the box by Android. It's an exciting future for phones again for the first time in nearly a decade.
I've argued that so far we've been in an era with smart phones that resembles early name brand closed PCs like the Commodore 64, Apple II, TI/99, etc.
We may be about to enter an era more reminiscent of the PC clone era, which was more boring from an aesthetic point of view but far more exciting in terms of innovation and opportunity.
New platforms usually start closed and then open over time.
I think a similar transformation is slowly building in the cloud space, but it's very quiet and nowhere near critical mass. I'd keep an eye on cheap bare metal hosts like packet.net and OVH, things that make it really easy to self-host and self-manage K8S clusters, and truly RAIN (redundant array of inexpensive nodes) ready databases like CockroachDB. Pretty soon you'll be able to combine those things and host at roughly 1/10th the cost of AWS or less, with absolutely zero lock-in. At the very least it will kick off a price war in conventional cloud.
Alternately if Starlink brings much faster connectivity to the edge while simultaneously kicking terrestrial broadband in the butt to offer competitive offerings, we could see a move of some hosting back to the edge where 99.9%+ uptime is not really needed. That could include batch processing, model training, analytics, and other stuff that doesn't directly power real-time customer API or UI interactions.
I have been waiting forever for phone manufacturers to finally standardize the booting process, hardware detection, and driver support for phone hardware. It's a decade overdue now. I would have thought the nightmare of supporting dozens of different phone models would push manufacturers to do this, but instead they just said "fuck supporting older models" and let them die young.
The old excuse that the hardware was too limited to support that kind of functionality is long since over. There is really no excuse anymore.
It's a problem on the whole ARM architecture and is one reason that ARM servers have not taken off. Every ARM board and chip is a special snowflake with its own weird boot and driver and hardware setup incantations. There's a bit of de-facto standardization but it's rough and not dependable at all.
The lack of proper boot and hardware standardisation is a huge issue. DTB tries to solve the fact different people put different peripherals on different ports, and there's no real hardware enumeration process to get around this.
But beneath this, one of the root issues at least in mobile devices is the system on chip nature of the design meaning you're at the mercy of the chipmaker to maintain appropriate drivers. These are invariably very very closed source on phones, as some areas like imaging and camera support were (and are now still, I guess) being bought in as super expensive IP blocks with serious NDAs and restrictions on what can be made available.
One reason Android is as fragmented as it was, was that they kept changing the system HAL, and chipset makers weren't providing upgraded drivers to support the new HAL as, from their perspective, the chip was end-of-life, old news, last year's model not making them any more money. I assume it isn't quite as bad on server, but single board computers running mainline Linux without patches, and with all peripheral and SoC component support are very rare, and noteworthy when they are found. Most still have pretty closed GPUs.
But when it's all on one chip, and you don't have any hardware discovery process, or even a standard way to boot the CPU, it's hard to see much of a generic future, as much as one would be great!
How were these early PCs any more closed than the IBM PC clones that followed? Some shipped with schematics and ROM listings. Smartphones have now been around longer than the entire pre-IBM PC era with no obvious movement towards any kind of opening outside of hobbyist devices. Game consoles have been around for decades without any such shift either.
They were more open than an iPhone, but they were not particularly open to anyone with less than a CE/EE level of computer and electronics expertise. They certainly were not designed to be modular and open like the clone PCs that came later.
I don't think that's accurate, just google up an Apple ][. But even if it were true, it wouldn't be strong evidence for your 'consumer hardware platforms become more open' theory given the reality of the longer-lasting smartphone era we live in now. Both the theory and the example used to support it seem starkly at odds with that reality, to me.
Game devices and smartphones were carefully designed to remain closed. Although the Pinephone and Librem 5 look like smartphones, and use many of the same components, they are far closer to phone-sized PCs. And so they're open from the start.
In addition to that concern, I would add that we've seen some of the opposite move happen - PCs change to be more like phones. The closed source OSes are all moving towards fenced off app marketplaces, with heavy sandboxing between apps. Even Ubuntu seems interested in this kind of move, with Snaps. We've also seen attempts to close the bootloader to "tampering", a restriction in place since the beginning of smartphones. We've also seen components like memory and batteries soldered into the computer instead of being replaceable. And so on.
I'm worried mobile phones are reducing the expectation that the average consumer has of being able to modify, upgrade, and repair their devices, and computer manufacturers are poised to take advantage of this, rather than the other way around.
Agreed that the barrier to entry for mobile app dev is high enough to the point of excluding vast swathes of developers from building tools for themselves.
Ive been an iOS dev for 5 years and I'm now looking to move into web dev for a few reasons;
* making any mobile app is by default harder and more frustrating than making a web based equivalent.
* You can’t easily ‘remix’ an app, Inspect Element style learning is impossible.
* Native doesn’t really give you much in perf over web anymore (navigation and state refresh is still bad on web - but you can work to make it passable).
* SwiftUI is a huge step in the wrong direction. Its a poor mix between React and standard HTML, without the benefits of a styling markup.
* I am a rookie web dev, but a senior iOS dev and I find making web apps easier than a similar native app. After 5 years. Now sure this could say something about me - but I don’t think so as there is so much evidence based on the current state of adoption for the corresponding technologies. I have skin in the game when it comes to native and I have no doubts when I say it’s easier to make products with web tech.
* Xcode is tragically poor to then point where it is a consideration for me to stop working in the ecosystem, it is simply appallingly bad.
This is a bit of a rant, sorry about that, but I feel like there is a general mood in the spaces I dwell in the native has lost its appeal. Year to year the SDK updates become less relevant (you could argue last years SwiftUI is the biggest change in years but its not ready yet, it doesn’t make the ecosystem any nicer to work in given how long it takes to get from farm to fork with a mobile app, and anecdotally 100% of the devs I’ve talked to that have made an app in it have given up on it for their next idea for the time being)
Things like this is when Firefox OS/Kai OS start to make sense. Make the OS a vehicle for web technologies. The application doesn't need to worry too much about OS specific quirks.
Unfortunately, Kai OS is such a huge departure in terms of interface so it doesn't really hit the sweet spot in terms of developer ease and user desires.
If you are interested in reviving the Firefox OS spirit on the PinePhone, join the #b2g channel on https://chat.mozilla.org/ . It's more active than ever these days :)
It seems to be some Ubuports related edition of the Pine Phone & that's seems to be the only Pine Phone in their store.
Still the price matches (~150$) and while I don't have much interest in UbuPorts, I guess nothing should prevent me from flashing the Sailfish OS port, Fedora port or something else I'm interested in on the device.
And the UbuPorts logo on the back can be fixed by the ~5$ plain back cover (or a Sailfish OS or Fedora sticker).:)
That's definitely the one you want as it has some hardware fixes based on learning from the Braveheart version. It's just vanilla PinePhone hardware with the UBPorts logo on the enclosure and should be shipping later this month.
I've already asked the question here and there but so far no good answer. I'm an old hacked : that is, I use a phone 99% of the time to send SMS and 1% of the time to give voice calls.
Everybody test various things : youtube, browser, camera, consoles, various OS'es, etc.
But does this pinephone can actually make phone calls (and receive phone calls) in a reliable way ? That's the only thing that prevents me from buying one.
(if you look on the web, you'll find a handful of comments about actually receiving phone calls and they are worrying at best)
Yes, the HW can do that, and I've made them personally. Ubports will be able to make/receive calls soon if it does not already.
Though if you just want a phone for calling, you can get a dumbphone. I have that and it beats any smartphone anytime, including pinephone. "Charge and forget about for a month" is an unbeatable feature for people who don't call much or receive many calls.
There's no single central development (aside from HW) effort, AFAIK. There are various individuals that work on particular aspects of the SoC/Phone support in the Linux kernel with some cross-over with linux-sunxi community.
And there are distribution/userspace efforts which I don't have much insight into, because I'm more focussed on the Linux kernel side of things. But from the edges it looks like a fairly small group of people pushing things forward.
I got originally interested in Linux kernel programming through various Xunlong Orange Pi boards (probably since Linux 4.6 times), Allwinner tablets, etc. I spent some years on it, and got to know a good bunch of Allwinner SoCs, and Linux driver development quite well. So when PinePhone got announced with Allwinner A64 in it, I was immediately interested. Pine64 community founder then offered me the developer unit, after noticing my interest. That was the start of it. ;)
I bought the Braveheart edition of the PinePhone and have played with various builds on it. I didn't try mobile nix, but I may give it a shot (though I've not used a Nix before so it might be a learning curve).
The PinePhone has a lot of potential IMHO. It's nowhere near ready to be your primary phone, but it's neat and at $150 it's a fun little toy.
IME, Fedora worked the best out of the box. I had issues with the battery not being recognized by postmarketOS (along with a few other things) though from what I've heard from others in chat rooms that's atypical (usually pmOS works great).
I'm super impressed with the PinePhone hardware wise. It looks and feels like a decent phone, and it's easy to remove the back and tinker or flip the hardware switches. You can tell they put a lot of thought and attention to getting it right. My only hope is that once things are working, I can buy one with specs comparable to the OnePlus 8 Pro (with similar price tag of course).
In addition to the issues like MMS not working, there are lots of papercuts that collectively add up to a really annoying experience. I kept having issues with the battery being recognized one minute and not the next. The touch detection needs some polishing, as does the keyboard. They are usable but have some metaphorical rough edges that need metaphorical sanding. Battery life isn't great yet either, I assume because it's not optimized yet.
That said, go ahead and get one. They're cheap enough that they are fun toys, and it's a way to vote with some dollars. Even tho it's not ready for daily driving, I think it will be in a few months, or sooner given how fast things are moving in the community now that there's real hardware people can buy. You can help with development by reporting bugs and such. Also you get to be a part of history!
The hardware should be solid as of the CE release (Braveheart was essentially the Beta release), it's the software that's a work-in-progress since there really hasn't been a widely used (open) Linux handset until now.
It sounds like the most important issues (i.e. battery life/suspend, camera support etc.) is getting resolved fairly quickly while sanding down the rough edges on the UI will probably take time. So it's usable, just not rock solid or feature complete from a software standpoint.
It doesn't run Android apps (well ... yet!), native apps are "meh", the UI quality is questionable and the battery life miserable. That's my last state of knowledge. Does anybody know how the power management stuff is going? I'm planning to build a mobile device with the very related SOPINE and think that project might profit from some lessons on that front.
And oh yeah, I'm totally planning to buy a PinePhone because because it's cool as hell.
Suspend to ram is working these days with crust firmware. It consumes some 150mW in suspend I think. So that should get a ~70h suspend time. That's most probably without a modem.
I still have to measure it a bit and play with it more. I've made a fake battery recently to measure power consumption in suspend independently: https://megous.com/dl/tmp/IMG_0047.JPG
Last I looked into that, most distros were able to run Crust on the embedded microcontroller, shutting down all cores and leaving it up to the uC to wake up the main CPU. This saves a substantial amount of power, and it seems that the device can now last around a full day.
So I'd say it can be used as a daily driver, unless you have strict requirements on app compatibility.
Speaking of which, I wonder how an emulated Android device (or even a real one) streaming video on my pinephone trough LTE would fare :)
Plainly put, none of the OSes do the basic features of a phone. Ubuntu Ports is the closest to being daily driver ready, and it cannot do MMS[0] (so group texts and picture texts are out). I cannot comment on the state of other OSes.
Even with that, most of them do not have a lot of basic features of what a vanilla smartphone would have either.
That isn't to say it will stay that way. I try out a few of the OSes about once a month or so, and the difference from when I first got it to now is astounding. I think (hope) that by the end of the year that I can use a Pinephone as my daily driver.
And upon reboot, a proper verified boot, as well as Auditor &or Attestation, lets you know, with cryptographic proof, whether your phone's firmware has been compromised by such a piece of hardware.
Would there be anything illegal about modifying a phone such that the location data it submits looks like some random person in Sheboygan, Wisconsin, instead of reporting where I actually am? Pretty much all I want in a phone is the ability to spoof location data and act as a hotspot for a smarter device (that doesn't have location awareness built in) so I can access richer apps over a VPN in greater privacy.
The cellular network always has to know your approximate location, or else it can't get your data to you. But that doesn't use GPS.
Offhand (and I'm very far from an expert) the only situation I can think of that spoofing GPS might have legal ramifications is when using E911. In general, it's probably better to spoof a "I don't see enough satellites to get a fix, sorry" status than to spoof a "I'm definitely in Sheboygan" status.
If you're talking about GPS location, then don't use application software that reports your location. MicroG+LineageOS will suffice.
If you're talking about tower based location, there is no way to significantly spoof your location since you can only connect to local cell towers.
To mitigate the latter, what you actually want is a phone with smarter software that will communicate over Wifi most of the time (rotating macaddr of course), perhaps with the option to turn on a cell radio in case you really need to communicate out of wifi connectivity. Hopefully the freshly built software stack inspired by new platforms will end up being conducive to this usage.
Not sure if it would be easy to determine the legality, but you might be able to check EULAs and TOS of the services you plan to use to see if they have a clause establishing their ok-ness with false data.
Pinephone feels like the closest I might get to a completely open platform that would see everyday use. My phone is of course the device that sees the most use.
It would be excellent to review the source code but its intractable to review everything.
An idea: how feasible would it be to either use static analysis or some kind of call tracing on this platform?
For a simple task like “boot phone”, one could reduce the source code down to the bare minimum needed to review for individual actions.
One could just delete code at will I suppose to make something that boots and does nothing else but I suspect getting it to compile would be very difficult. Tracing execution feels a bit more doable.
Really neat to see an application in the wild written in Zig, but it makes a lot of sense why it would be used for a cross-platform target. I've got my PinePhone on pre-order, I'll have to give doing something similar a shot when it gets arrives!
Imagine a board meeting at JP Morgan and the CEO pulls out a Pinephone. iOS and Android make up the vast majority of mobile devices and will for the forseeable future.
Think longer. Apple Inc. was founded 44 years ago. They were a PC company until 11 years ago. Can we be confident that in 2031 the libre phone will have gained no market share to the iPhone? What about in 2064?
It might not be the thing driving people to switch, but I'd be hesitant to claim that Desktop Linux is any worse than the competition. Like, I don't have the exposure to comment on Apple's products, but Windows is no better than XFCE, GNOME, MATE, or KDE these days, Android is a toy, and ChromeOS isn't better. Like... I know this is weak praise; Windows versions after 7 got worse as they fragmented (have they re-merged the control panels yet?), Android was born a mobile OS, and ChromeOS was always meant to be cut-down, but the result is that the playing field is level.
I don't know who the CEO of JP Morgan is, but I imagine he might be one of the few who would pull out a Pinephone with a his own custom software stack with encryption for all his communications and perhaps some other special tools.
A few days ago I've published my custom bootloader for PinePhone: https://megous.com/git/p-boot/about/
It's the one I use for a quick booting to Linux: https://www.youtube.com/watch?v=kxqdF7H_It8
Something to try if you have a pinephone and want to experience sub-second boot times.
Anyway, if you like bringing up new hardware, or optimizing things, this is as good an opportunity as it gets to get pinephone and have fun. There are lots and lots of areas that can be optimized and improved in usersapce and in the kernel and you can do whatever you fancy or want to learn about. It's all being developed by random people on the internet. ;)