<samueldr>
working on "behind the scenes" stuff last few weeks
<samueldr>
and it looks like I'll be able to finish that stuff before the new year
pie_ has quit [Ping timeout: 240 seconds]
<samueldr>
Church-: any reason you ask?
<Church->
Just curious, getting my pine phone soon. And eager to see if I can do some porting work
<samueldr>
it's untested on the final device, but I have my reasons to assume it'll work as good as it works on the devkit right now
<samueldr>
nothing in Mobile NixOS is figured out for telephony and stuff (integration-wise)
<samueldr>
working on more general foundational stuff
<samueldr>
which will be as useful on the pinephone as android devices; as there will be no trivial way to select a generation at boot
<samueldr>
unless things changed in the last few days, u-boot still had no gfx init and no one was working on improving u-boot for pinephone a bit
endformationage has quit [Quit: WeeChat 2.6]
rardiol has quit [Ping timeout: 265 seconds]
drakonis has quit [Quit: WeeChat 2.6]
<Church->
samueldr: Well there's already a ofono service at least. Which is good
<Church->
But yeah integration might be a pain
<ashkitten>
samueldr: i wonder if you could make a small "stage 0" bootstrap to display a boot menu
<ashkitten>
also my indiegogo contribution still hasnt been locked >> hopefully it is by tomorrow
<samueldr>
ashkitten: that's *exactly* what I'm working on
<samueldr>
well, the foundation for that
<ashkitten>
samueldr: oh, haha
<Church->
Wondering if I should use plasma mobile or Ubuntu touch...
<Church->
Hmm
<samueldr>
the yak I had to shave for this is... tiny, but feels like a ton of hair
<ashkitten>
i get that..
<samueldr>
I didn't want to continue investing in the ash (busybox sh)-based stage-1 scripts
<ashkitten>
these new-fangled breadth first yaks
<samueldr>
I don't want to write C or C++
<samueldr>
and the desired solution needs to cross-compile
<samueldr>
oh, it needs to be smol
<samueldr>
the minimum requirement for a recent enough device is 16MiB for kernel+initrd
<samueldr>
it's possible to trim the kernel to 8MiB easily enough without losing too much
<samueldr>
that makes it ~8MiB compressed total for the init, which needs systemd-udev
<samueldr>
a next step will be figuring out a way to make it smaller
<ashkitten>
cool!
Irenes[m] has joined #nixos-chat
<Church->
Neat
<Church->
I'll try and find some papers I remember seeing on super-minimal systems installs
<samueldr>
the thing is there's a bunch of tricks that can't be done really
<samueldr>
sometimes they'll ditch udev and rely on knowing the hardwae
<samueldr>
hardware*
<samueldr>
we can't, we don't know the hardware
<samueldr>
the kernels are bad smelly spaghetti code piles; disabling something will sometimes make a seemingly irrelevant part stop compiling
<samueldr>
(all in vendor code)
<samueldr>
so it's not trivial to make an ultra-minimal kernel
<samueldr>
and furthermore, the device needs to work still with that kernel! (until we get kexec going)
<ashkitten>
oh yeah, i figured you'd just put together a barely functional stripped down kernel for stage 0 and kexec into the barely functional vendor kernel
<ashkitten>
but if you can't do that i guess it complicates things
<samueldr>
it gets invasive quickly :)
<samueldr>
though AFAICT that 16MiB boot partition is an outlier
<samueldr>
it's a 64 bit device that shipped with a 32 bit kernel/system build
<ashkitten>
heh
<samueldr>
all other 64 bit devices seem to have a bigger boot partition, at least 32MiB
<samueldr>
at such small sizes, from 16 to 32MiB is a great improvement for our needs
<Church->
samueldr: What device is this?
<samueldr>
Moto Z Play
<Church->
Hmm, remember that one well
<samueldr>
hm?
<samueldr>
nice, first device boot using the new init
<Church->
Nice
<Church->
samueldr: You've got a pine phone right? How is it? Probably only given it a quick glance over I assume
<samueldr>
nope, no pine phone, but the don't be evil devkit
<Church->
Ah that's right. Nod nod
<Irenes[m]>
the Bravehearts haven't shipped yet
<samueldr>
holy baloney, it wasn't an actual goal of the endeavour, but I shaved ~5s from the init script with that POC
<samueldr>
right, there is stuff that isn't implemented where it would make sense it adds 5 seconds
<samueldr>
mostly usb networking in initrd for debugging
<samueldr>
oof +1,942 −145
<samueldr>
(though to be fair I haven't remove most existing shell initrd bits)
psyanticy has joined #nixos-chat
__monty__ has joined #nixos-chat
pie_ has joined #nixos-chat
pie_ has quit [Ping timeout: 265 seconds]
pie_ has joined #nixos-chat
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-chat
pie_ has quit [Ping timeout: 258 seconds]
rardiol has joined #nixos-chat
pie_ has joined #nixos-chat
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-chat
pie_ has quit [Quit: No Ping reply in 180 seconds.]
pie_ has joined #nixos-chat
<MichaelRaskin>
I have a feeling that RFC#36 describes a process which is noticeably different from what is going on in reality. It looks like RFC gives Shepherds less responsibility for personally polishing each corner than a typical Shepherd team ands picking up (by RFC, it looks like the point of unanimity is to make a binding decision whether the points raised — whether by the ST or by others — have been properly addressed)
<MichaelRaskin>
I wonder if clarifying this would either make RFCs#36 clearer, or alternatively make it easier to find willing shepherds.