edcragg has quit [Read error: Connection reset by peer]
edcragg has joined #nixos-aarch64
orivej has joined #nixos-aarch64
pat_h has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
pat_h has quit [Quit: Connection closed]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
wavirc22 has quit [Ping timeout: 272 seconds]
wavirc22_ has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
pbb has quit [Ping timeout: 272 seconds]
pbb has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
nschoe has quit [Ping timeout: 244 seconds]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 264 seconds]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
2020-05-19 09:41:20 < Tenkawa> Anyont tried out the mainline 5.7rc kernel yet? its great
<clever>
2020-05-19 09:45:54 < Tenkawa> clever: ok happier topic... cant believe mainline actually works un patched yay :)
<clever>
samueldr: 5.7rc apparently works on an rpi4 now
<srk>
nice!
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
<gchristensen>
I don't suppose anyone has a recommended "build a stack of pi's" kits?
<hexa->
clever: hm, 5.7rc4 doesn't
<simpson>
gchristensen: I found a cute little set of shelves that is perfect for holding Pis at Muji. I figure that some sort of Muji/IKEA plastic dish is going to work reasonably.
<simpson>
I also recall great success with Lego, but I was not running things very hot; I don't know how well Lego stands up to heat.
<hexa->
lack of generations on the rpi4 is annoying
<clever>
hexa-: i have been considering a custom arm bootloader to solve that
<clever>
hexa-: probably something LK based
<clever>
hexa-: though mobile-nixos also has a kexec based one
<hexa->
cool
<hexa->
contemplating on how to recover that pi
<hexa->
copying over the cmdline.txt didn't do the trick
<hexa->
probably too many changes in /boot
<gchristensen>
simpson: hmm cool
<clever>
hexa-: my current problem with handling generations on my open firmware, is the lack of long filename support
<hexa->
oh yeah, vfat limitations </3
<clever>
hexa-: the filesystem supports them just fine, the fs drivers dont
<clever>
hexa-: here is where i load the zImage, initrd, and cmdline.txt for linux
<hexa->
looking forward to this :)
<clever>
hexa-: i could easily run read_file on something else, and then do some kind of parsing to deal with generations and such
<clever>
but without fat32 write, i cant automate rollback on failure
<clever>
and without long filenames, having multiple kernels with names that still make sense would be difficult
<hexa->
agreed
<clever>
if i get fat32 write solved, i can change the default generation before i boot
<clever>
and then after booting, change it back forwards again
<clever>
and then if it fails, whack reset, and it goes backwards on its own
lordcirth has joined #nixos-aarch64
<simpson>
gchristensen: I've got https://www.muji.us/store/4547315296286.html or so, and it fits three Pis or similar, although it's not perfect and I'm not sure if I'm actually happy with it.
<hexa->
acrylic for the heat dissipation of the rpi4 … hmm
<gchristensen>
oh cool
<gchristensen>
thanks!
<simpson>
hexa-: Yeah, acrylic isn't a great material, but there's actually a lot of room in those bays, and Pis are designed to be passively cooled. Also I've never really spun everything up to see what happens on full tilt.
<gchristensen>
are the prolific-based serial cables any good? I've been trained to only trust ftdi
<clever>
gchristensen: ive also exclusively been using ftdi stuff
<hexa->
lately been using cp1202 and pretty happy with that as well
<simpson>
hexa-: Huh, now I'm wondering about making little cloth mat-trays.
<hexa->
simpson: huh, for the rpi?
<simpson>
Yeah. I've done this sort of thing before; when I used a Pi as a synthesizer for a keyboard, I needed a way to tape the Pi onto the keyboard, without scratching the keyboard's finish or damaging the Pi's exposed pins.
<simpson>
My compromise was to use a piece of foam to mount the Pi while leaving it half-exposed to air, and to tape the mount to the keyboard. If I redid this today, maybe I'd use a piece of thick fabric instead.
<clever>
simpson: most of my plastic cases have mounting keyholes in them
<simpson>
clever: Right. These bays are completely open on one side, but I could imagine drilling holes in the other sides too.
<gchristensen>
hmm it doesn't look like the rpi is actually compatible with the FTDI adapter, and requires some extra mucking about with cables
<hexa->
rpi4 rev 1.2 might give out serial over the usb-c port
<simpson>
ISTR that IKEA had similar little bay-trays, maybe made out of wicker, but I can't find them in their online catalog.
<hexa->
with older revisions you'd have to go GND, TX, RX
<clever>
hexa-: the rpi4 usb-c is wired to the legacy usb2.0 controller, and runs in gadget mode by default
<clever>
hexa-: once linux has started, you could modprobe g_serial and turn it into a serial port
<clever>
or g_ether, and do ethernet over usb
<hexa->
but gadget mode won't work before the rev 1.2 fixes, no?
<clever>
hexa-: gadget mode should work on any mode, the fix is just for certain usb-c chargers to even turn on
<hexa->
oh, i thought that affected the usb-c smartness in general
<clever>
hexa-: if you use a C->A adapter, all that smartness is ignored
<clever>
and the C port is only 1.0 and 2.0, so you never had any 3.0 to loose
<clever>
the bigger problem though, is that linux cant even boot, when powered over usb-c from my desktop
<ashkitten>
Valodim: wow, that pi4 case looks nice
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Valodim>
it's pretty sweet yeah :)
<Valodim>
sadly it seems I'll have to wait until for a restock to get more I can send to people
zupo has quit [Ping timeout: 256 seconds]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
orivej_ has quit [Read error: Connection reset by peer]
evils has quit [Quit: Lost terminal]
evils has joined #nixos-aarch64
spacekookie has joined #nixos-aarch64
<spacekookie>
I'm trying to build an android app on nixos that has some native code and it's failing to find "aarch64-linux-android21-clang". I checked with {^_^} but it couldn't find any package that provided it. Is there some cross compling setup I'm missing to make this work?
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<samueldr>
clever: I'll need to take a look I guess
<clever>
samueldr: Tenkawa also reports that MMIO via /dev/mem works just fine, which makes my problem even weirder, how can it work on mainline linux, but fail on the fork? lol
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
* clever
heads off to bed
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 256 seconds]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
pat_h has joined #nixos-aarch64
pat_h has quit [Client Quit]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
zupo has joined #nixos-aarch64
<ashkitten>
hmmmmmm
alp has quit [Ping timeout: 272 seconds]
<ashkitten>
google-marlin doesn't have an sd slot so i'm trying to see if somehow i can boot to mobile-nixos via usb otg... doesn't really seem to be booting, though the drive light is flashing a lot
<ashkitten>
this is very silly because i have to quickly swap to the usb otg cable after `fastboot boot` before the nixos logo shows up
<samueldr>
pretty sure usb otg should work
<samueldr>
yeah, silly you're right... but it waits until the partition is available, so even if you were slow, it should be fine
<ashkitten>
well the logo disappeared and soon after the drive stopped flashing
<ashkitten>
oh, that's good
<ashkitten>
hmm the screen's still black
<ashkitten>
and it rebooted to the qcom charging screen
<samueldr>
that should mean it kernel panic'd
<samueldr>
you should figure out how to get the console ramoops using adb
<ashkitten>
i need twrp for that
<ashkitten>
what's the file path?
<samueldr>
in theory the running android rom should also have those, but you might not be able to access them
<ashkitten>
oh huh
<samueldr>
it's somehwere like /sys/fs/pstore and from there on it should be obvious
<ashkitten>
thanks
<ashkitten>
uhhhh i have a file pmsg-ramoops-0, but it looks corrupted to all hell
<ashkitten>
so that's not useful
<samueldr>
yeah, I have trouble here in getting those consistently
<samueldr>
but I don't know if I'm doing something wrong
<samueldr>
and I don't know if booting into that battery charging bootimg can affect it
<samueldr>
pro-tip: that's a "full" linux system that's used to show those images!
<samueldr>
it's basically running the bootimg with a command line parameter
<ashkitten>
i need a faster flash drive
<ashkitten>
i don't know where my gf's usb 3 flash drive is
<samueldr>
if it kernel panic'd, that means that something happened, as the boot process doesn't handle the partition never showing up and it would have instead been stuck on the boot logo
<ashkitten>
nah i think it's actually booting, it's just incredibly slow because it's off a crappy 2.0 drive
<samueldr>
it could also be that the linux kernel somehow resets the otg port on which it's reading files from!
<ashkitten>
maybe
<ashkitten>
i will try to find out if it does it again
<ashkitten>
i see a mouse cursor 👀
<ashkitten>
ayyyy
<samueldr>
nice!
<ashkitten>
tiny mouse cursor tiny gui
<samueldr>
first confirmed OTG boot, never tried it beforehand, but assumed it should work
<ashkitten>
hell yeah
<ashkitten>
now i can test things for you if you want
<ashkitten>
i probably won't do much in-depth stuff like i was trying before, but we'll see
<samueldr>
at least now you know it's possible
<samueldr>
or, more to the point, know *how*
<samueldr>
theory and practice, in theory is the same, in practice...
<ashkitten>
it'd be nice if i had an otg adapter that didnt need power
<samueldr>
that didn't need power?
<samueldr>
are you using a type-c usb hub, with type-c PD input?
<samueldr>
in my experience they don't require power, but at least it's transmitted to the device when used
<samueldr>
(well, they require power for the display out to work when they have display out)
<ashkitten>
this 100% needs power
<samueldr>
hm, not nice
<ashkitten>
whether or not it should, is a different question
<ashkitten>
i wish this phone had an sd card
<samueldr>
I was wondering if it was rather that you were using one of those A-to-C adapters, which those can't allow charging at the same time
<samueldr>
it gets annoying fast when you're racing with the battery power to debug :)
<ashkitten>
no, this one has external power and apparently the phone can't provide power through it
<samueldr>
type-c is fun
<ashkitten>
lol, yep
<ashkitten>
welp, back to android
<ashkitten>
fun experiments
<ashkitten>
samueldr: you haven't done anything with hybris or halium or anything right? i don't know when you said you were looking into that
<samueldr>
it's coming up, but I'm stuck shaving a yak that regrew its hair
<ashkitten>
uh oh
<samueldr>
I wanted to reduce the amount of C I've written, by using libffi to interact with a library instead of C bindings
<samueldr>
but just now I've realised one fatal flaw
<samueldr>
pkgsStatic
<samueldr>
and I'm not sure there's a good solution
<ashkitten>
not sure i understand fully
<samueldr>
still need to test things out here
<ashkitten>
but that sounds rough
<samueldr>
libffi will dlopen and use symbols from a .so file dynamically
<ashkitten>
oh, i see
<ashkitten>
so you can't statically link *and* use libffi
<samueldr>
so you can say "this .so has a function foo with signature void foo(x, y, z)"
<samueldr>
and then you can just use it
<samueldr>
but yeah
<samueldr>
I'm still looking in what's going on
<samueldr>
though I have some hopes that it's as dumb as stripping
<samueldr>
and use symbols in the current executable rather than dlopening
<samueldr>
but I'm kinda flying by the seat of my pants for that right now
<samueldr>
I really want to go through libffi instead as it reduces the risks of me doing more bad things
<ashkitten>
samueldr: would you consider adding support for dual booting android with mobile nixos?
<samueldr>
I have thought about it a bit, and I would like it for it to be possible, but I don't have a clue how to make that work nicely
<ashkitten>
ah yeah
<ashkitten>
maybe could replace the recovery image with mobile nixos bootloader?
<samueldr>
"boot as recovery" is annoying here
<samueldr>
newer devices, like pixel2 onward for google's own, there is no more recovery partition
<ashkitten>
i'm not sure how to install just a recovery with that, yeah
<ashkitten>
pixel1 even
<samueldr>
oh
<ashkitten>
i'm using google-marlin
<samueldr>
I assumed
<samueldr>
the way it works, the android bootimg holds the kernel, and the recovery initrd; it directly mounts system
<samueldr>
on a normal boot it doesn't use the initrd
<ashkitten>
twrp somehow patches the boot image for that, but i don't know what it does
<samueldr>
flagrantly replaces the initrd :)
<ashkitten>
can we do that?
<samueldr>
possibly, but we'd be stuck with the android-platable kernel
<ashkitten>
oh, but we can't use a normal android kernel, so we'd need to kexec
<ashkitten>
right
<samueldr>
so that one needs to *at least* allow kexec
<samueldr>
it could be done
<samueldr>
but then, *what* does it kexec?, userdata is encrypted!
<ashkitten>
assuming we can't fit another kernel in the patched boot.img?
<samueldr>
I'm sure there are solutions, it's simply not trivial :)
<samueldr>
I think it could fit, but we need to fit a recovery initrd + a mobile nixos initrd in there I guess
<ashkitten>
er, a stock initrd and mobile nixos initrd?
<ashkitten>
we'd want to still boot android
<samueldr>
stock (recovery) initrd and mobile nixos yeah
<samueldr>
remember, normal boot skips recovery
<samueldr>
oop
<samueldr>
oops*
<samueldr>
I see
<samueldr>
no need for a recovery initrd I guess
<ashkitten>
we want normal boot, recovery is mobile nixos
<ashkitten>
right
<samueldr>
(there is no stock initrd then, as normal boot skips initrd)
<ashkitten>
okay, got it
<samueldr>
might be possible, though I guess the last thing to fight with is userdata
<samueldr>
can't touch system, can't touch any other partition
<samueldr>
though I guess we could support that encryption scheme if we wanted to support dual booting
<ashkitten>
i was assuming we would use an sdcard or otg device
<samueldr>
oh
<samueldr>
then it's less of an issue I guess
<ashkitten>
yeah
<samueldr>
the main things missing would be kexec in the android kernel into the mobile nixos one, with the same initrd, or something similar
<ashkitten>
in theory we could probably support loopback mounting from a file on userdata if we wanted to mess with decryption, i guess
<samueldr>
yeah, loopback is what I was thinking would be a solution if we wanted to mess with decryption
<ashkitten>
many phones have sdcard slots though, so i assume the majority of people will use that scheme
<samueldr>
I don't know what's the distribution of phones with sd card slots really
<samueldr>
though yeah, for those that can, it would be usable that way
<ashkitten>
also, if the android kernel doesn't support kexec maybe we should flip that around and kexec android from the mobile nixos kernel?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
that's another possibility
<ashkitten>
then we could even present a boot selection gui or set a default boot option
<samueldr>
yeah
<ashkitten>
much more friendly than making the user select recovery whenever they want to use nixos
<samueldr>
one issue, though, is applying OTAs AFAIK happens through recovery
<samueldr>
not entirely sure for "pure aosp", but at least for LineageOS
<samueldr>
so you're kinda stuck unable to update from Android unless we get into a convoluted scheme where recovery also sits within the image
<ashkitten>
not on a/b, but boot does get overwritten
<ashkitten>
i'm assuming we can do kexec entirely inside the boot partition even on non-boot-as-recovery devices, without touching recovery
<samueldr>
I thought that on A/B too it ended up being installed through recovery, but I'm possibly off
<ashkitten>
a/b it never boots to recovery, you install from inside the booted os and reboot to the new slot
<samueldr>
the issue with kexec entirely inside the boot image with non-boot-as-recovery is that we need to fit the android kernel, its initrd, and our initrd contents :)
<ashkitten>
yeah, and those partitions will be much smaller
<samueldr>
yeah
<samueldr>
motorola-addison has 16MiB to fit everything into
<samueldr>
the kernel takes a bit over 8MiB since it's almost impossible to strip it down further
<samueldr>
I think it's one of the worst case scenario
<samueldr>
but still something to consider
<ashkitten>
maybe we could offload the android kernel to somewhere else?
<ashkitten>
or whichever kernel is booted second
<samueldr>
that's what multirom manager did
<samueldr>
but it was also using the fact userdata wasn't encrypted IIRC
<samueldr>
(btw, it's probably a good starting point to see what are the issues)
<ashkitten>
and we'd want android to be bootable without a nixos sdcard or otg storage, presumably, so we can't put it there
<samueldr>
yeah
<ashkitten>
very annoying problems, lol
<samueldr>
just saying, I don't think I am going to implement it, it's not part of what's on schedule, but I am definitely open in getting a contribution that does this, and can help figure some things out even
<ashkitten>
understandable
<samueldr>
it would be really helpful for some
<ashkitten>
for non boot-as-recovery devices it's as easy as replacing the recovery partition with mobile nixos, you just have to replace it with an android recovery in order to update that
<ashkitten>
although, it might be possible to do something sneaky and figure out how to update android from mobile nixos to circumvent all of that
<ashkitten>
or maybe we could kexec twrp from mobile-nixos
<ashkitten>
lots of possibilities but i'm not sure i can actually implement it