so because the laptop developed that problem we had to deal with, we never actually did finish getting the phone updated. maybe we'll work on that a bit.
we imagine this must be what it's like to have a bunch of project cars in the yard. nothing ever actually gets finished but there's always plenty of stuff to do that matches whatever mood you're in.
okay, good news. by examining git reflog carefully and doing some test builds, we were able to determine which point in the git history the currently-running system is based on
that's important because it's the only thing we can successfully build without doing a few thousand packages, since they're all already built
in the effort that failed, a week or two ago, we had hoped to skip this work, but we really need to turn off our automated garbage collection so that we don't have the pressure of needing to make the build finish within 24 hours
it's always frustrating repeating stuff we already did, but this should be the last time
yay it downloaded 2912 cached binaries and now needs to build 1171 things locally
the phone is running a very stripped-down package set compared to the laptop; we tried hard to turn off everything that's large or takes a long time to build. unfortunately, modern development practices include web engines in fucking everything, so we're still expecting it to have to do a lot of those.
the laptop failing was an extremely https://xkcd.com/349/ moment, we're glad we got it working again heh
the phone rebuild has been quietly ticking along. it has built 935 packages and has only 230 to go. here's hoping all the big ones are already done.
because this is mobile-nixos, after we switch into the new system we will also need to build a new stage1 disk image and dd it into place. mobile-nixos has its own stage1 that completely replaces the regular one.
that's necessary because the kernel becomes part of that image, and kexec isn't reliable enough on ARM to use for this, so you wind up running whatever kernel stage1 has, regardless of what the nix system derivation has.
@ireneista wait nixos stage1/stage2 is literally doing a kexec on x86??? no way
@cas oh, no, not at all. the key difference between regular nixos and mobile-nixos is that on regular nixos, your bootloader, not nix itself, is responsible for offering a selection of fine kernels to boot from. then once it has done that, stage1 runs within that kernel and prompts you for any boot credentials you need, such as for LUKS
@cas on mobile-nixos, however, there's no way to do that because there aren't any EFI-based or bare-metal bootloaders that can handle the devices (LCD power-on and on-screen input are frequent pain points). so that stuff has to run in user space, which means it can't ask you to pick a kernel, it has to already be in a kernel
@cas if kexec worked, it could hand you off to a different kernel later. but, alas! it does not. so you're stuck
@ireneista ah ok i see
on the qualcomm phones we have all the fancy efi uboot stuff working, but yeah its more of an issue on the pinephones and others... shame nobody has enabled this stuff but tbf it is a lot of work to do display bringup (we only have it by luck - handed over by the prior stage)
@cas ah! so, that gets into the other thing we mentioned. the pinephone with Tow Boot does have EFI, and in fact is using it for mobile-nixos. what it doesn't have is a working LCD, because for some reason that we have not been able to determine despite our best efforts, u-boot doesn't run code to initialize it, despite using the exact same DTB the Linux kernel does.
@cas we've talked quite a bit with samueldr about this, if you have expertise in that sort of thing we don't doubt your help would be appreciated
@cas do you have an on-screen keyboard running inside EFI, on the qualcomm devices?
@ireneista no just button navigation (i added an option in u-boot to remap power/volume keys to arrows and enter)
i have looked into touchscreen drivers, even wrote one for the oneplus 8t (since i was wrote the linux driver and it was dirt simple) but i didnt get around to implementing the EFI "absolute positioning" protocol (for touchscreens), that would have made it possible to use rEFInd (which supports touch) and i absolutely would have hacked up some kind of OSK for U-Boot
the downside is we would have to write/port drivers for every touchscreen for every phone (even multiple since some phones have different hardware variants)
but it is something i want to get back to eventually! maybe i should bump it up my project ideas list since it would be such an awesome tech demo if nothing else :D
@cas we do think it's a really important piece of what we hope will someday be a linux smartphone experience that's suitable for a wider audience
ramble about immutable pmOS and direction of the project
ramble about immutable pmOS and direction of the project
ramble about immutable pmOS and direction of the project
ramble about immutable pmOS and direction of the project
@dos @cas well, that's good to hear. our own interest is primarily in the Pinephone Pro, and despite several years of intermittent attention to it, and reading through a lot of background research on the chip itself, we still don't feel sufficiently oriented in the u-boot codebase to know where to start.