<samueldr>
the gauntlet is over, I got the ports kick started well and proper
<samueldr>
adisbladis is going to give me whiplash with the quick fire PRs :)
orivej has joined #nixos-aarch64
ris has quit [Ping timeout: 240 seconds]
<andi->
samueldr: just *NOW* my Opo3 is in an android boot loop. I wasn't gonna recover it and instead use a dumb phone (phone calls work much better on them anyway). Might be able to review this.
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
ris has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ris has quit [Ping timeout: 246 seconds]
ris has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
sphalerite has quit [Quit: rebooting]
sphalerite has joined #nixos-aarch64
ris has quit []
ris has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
<samueldr>
heh
<samueldr>
if it's a oneplus3t, that woul allow verifying it works too on it, which it might / should
tilpner has quit [Quit: tilpner]
<sphalerite>
ah damn, my chromebook's stopped booting.
<samueldr>
:/
<samueldr>
stopped going past the emmc thing on boot or stopped like starting?
<samueldr>
with the suzyqable a bit of `reboot` action in the third serial console may unstick some sticky situations
<sphalerite>
when I press ctrl-d on the boot screen, the screen goes black for a couple of seconds then it says I didn't insert a chromeos recovery device
<sphalerite>
maybe the kernel image is too big with the 19.09 upgrade
<sphalerite>
weirdly though, it doesn't boot from the SD card where I have an older kernel either
<samueldr>
could be, does it still boot from your known working SD card?
<samueldr>
ah
tilpner has joined #nixos-aarch64
<samueldr>
when you set boot up, did you use gbb flags or just the usual switch to dev mode?
<samueldr>
I think the latter *can* be lost in some situations, but I have no tangible proof
<sphalerite>
ah crap
<sphalerite>
the sd card does work after all, after ejecting and reinserting it
<sphalerite>
buuuuuuuut
<sphalerite>
the system referred to by it has been gc'd
<samueldr>
:/
<samueldr>
yeah, my mobile-nixos thing on dumo is likely to be more convenient in the end :|
<samueldr>
(setting gbb flags also allowed me to set a short and no-beep boot to internal storage)
<sphalerite>
at least I think that's what's happening. There's a kernel panic and the text scrolls by too fast.
<sphalerite>
Now if only I had a way of setting kernel params :)
<samueldr>
suzyqable to the rescue!
<samueldr>
uh
<sphalerite>
ooh that sounds nice
<sphalerite>
how can I rescue it with the suzyqable?
<samueldr>
it won't allow you, sorry
<samueldr>
just to see the console, if configured :)
<samueldr>
but I think you should be able to `dd` the kernel partition from your sd card and edit it there
<samueldr>
with some of the vboot utilities
<samueldr>
not 100% positive though
<sphalerite>
meh
<sphalerite>
maybe I should flash a new firmware that's more friendly, now that the boot is hosed anyway.
<samueldr>
also, I think I said it already, but just saying it again for new eyes: the suzyqable does *not* work on pixel 2 devices as stated elsewhere on the internet; probably doesn't for 3/3a either
<samueldr>
I thought you would be sharing more; which new firmwares are there?
<samueldr>
while I intend to try and support depthcharge for those devices that won't work with a new firmware (mediatek chrome devices maybe?), I think it's still a good idea to graduate from depthcharge into something more generic
<sphalerite>
not sure exactly how to go about this yet, besides 1. make a firmware image 2. flash it
<sphalerite>
:p
<samueldr>
yeah, but which firmwares are there for the gru platform?
<sphalerite>
I'll probably be trying for coreboot+petitboot based on hanetzer's work
<samueldr>
or is that yet an unknown?
<samueldr>
right
<sphalerite>
but really, it's more likely I'll just stick thefloweringash's sd image on a USB stick and recover my nixos from there :p
orivej has quit [Ping timeout: 240 seconds]
<andi->
samueldr: I was able to boot stage one and play with the adb shell and then needed a telephone so I had to flash android again
<samueldr>
great :)
<samueldr>
andi-: oneplus3t or oneplus3?
<andi->
3t
<samueldr>
amazing!
<samueldr>
it was expected, they share the same source tree
<andi->
yeah, they are almost the same
<samueldr>
AFAIK only the SoC changes, 821 instead of 820
<samueldr>
but still, things like the pixel 2 are causing me headache
<andi->
Is there a reason not to have "fat" boot images for testing of hardware support (e.g. including stage2 into the fastloadable image)?
<samueldr>
work in progress :)
<samueldr>
I thought the stage-2 wasn't fastboot flashable, but it is
<andi->
alright, feel free to ping me if you need further hardware testing on the phone
<samueldr>
though fastboot *boot* stage-2 will hardly be, there's a limit to the size
<samueldr>
I'm also making a clear cut between stage-1 and stage-2 since I intend stage-1 to always be cross-compilable
<samueldr>
while stage-2 is basically nixos
<andi->
I am also expecting the librem5 soon(tm). If that arrives before NixCon I'll bring it in case you want to play around with it.
<samueldr>
and, as it turns out, it looks like stage-2 images might be universal for now
<samueldr>
if I can keep them universal, bootstrapping will be easier for other devices
<andi->
yeah, that would be nice
<samueldr>
right now I have used only two disk images
<samueldr>
and one of them is to add a hack to the xf86fbdev driver
<samueldr>
hack should run on the device that's not using it
<samueldr>
and, I haven't had time to stabilize things yet :)
<andi->
Any idea how compatible the graphics stack would be with wayland?
<samueldr>
none at all yet
<samueldr>
but that's because my knowledge of wayland is basically nil
<samueldr>
none being no knowledge
<andi->
isn't android using EGL most of the time?
<samueldr>
I think that with adisbladis' PR it may be working with acceleration
<samueldr>
I think so yeah
<andi->
if so that might just work (tm)
<samueldr>
that's what I think is gonna happen
<samueldr>
on my asus-z00t, on pmOS it just worked
<samueldr>
right now it's basically not a thing I tried, banging my head against port to devices to make a good palette of example devices
<samueldr>
I'm pretty sure with the palette I have I won't be accidentally making things to dependent on one device
<samueldr>
journald/journalctl is quite amazing
<samueldr>
I can just pull one file/folder from the phone (through TWRP and adb!) and read the log from a phone on which I can't have console access yet
<andi->
What do we do about the bootloader in the long rung? I am thinking about multiple system generations
<samueldr>
I wanted to have a talk with you since it touches something we spoke about briefly beforehand
<samueldr>
making a linux-based bootloader thingy
<andi->
Oh, I've discussed with more people about that.. Should really get around to do that. Your stage1 work might be nice for that.
<samueldr>
I would much rather work on something more generic, and useful also outside of phone environments
<andi->
Also I've been working on NixBMC (an OpenBMC spin-off) briefly last year where I had to do the same ground work…
<samueldr>
so that's the plan for generations
<samueldr>
you'd have the boot partition be a tertiary bootloader
<samueldr>
that either kexecs or switches into stage-1 loaded from another partition
<samueldr>
I *think* it's possible some older devices will not be able to kexec, though no certainty here
<samueldr>
and I'm still thinking about those devices with "blobby" kernels, without appropriate sources
<andi->
My current blocker with linux as an EFI executable (for UEFI systems) is embedding an initramfs seems to be only possible while building the kernel and not afterwards. The way NixOS currently builds a stage1 expects the kernel to exist already.
<samueldr>
hmm, not afterwards?
<andi->
I haven't dug very deep but so far I couldn't figure out how to combine it afterwards.
<samueldr>
something I'll need to check, but it'd be surprising to me if it's simply impossible to just have the pieces and assemble it ourselves afterwards
<samueldr>
right
<samueldr>
then I think we're mostly agreeing :)
<andi->
Yeah, that is what I wanted to do. The binaries the kernel makefiles create weren't really making sense to me from that perspective.