bennofs has quit [Remote host closed the connection]
bennofs has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zfnmxt has quit [Quit: Bye!]
zfnmxt has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ryantrinkle>
samueldr: it looks like armbian is maintaining quite a lot of stuff for pine64 hardware; is there a way we can make use of that from nixos?
<ryantrinkle>
e.g. would it make sense to apply some/all of their kernel patches?
<ryantrinkle>
they've also got a ton of boot scripts and such
<ryantrinkle>
(i have no idea how much work any of that is, just wondering if it is even a logically coherent idea)
<samueldr>
ryantrinkle: I know for sure they're using vendor source trees for some devices
qyliss has quit [Quit: bye]
<samueldr>
that's not something I am interested in, and not something nixpkgs should strive to package
<samueldr>
though they *also* have patch sets for mainline for some devices
<clever>
samueldr: ive hit some roadblocks with the pi4, but also found new ways to attack the problem
<samueldr>
those would be better suited for packaging in an overlay repo (of flake for whenever)
<samueldr>
or flake*
<clever>
there is some undocumented validation on recovery.bin, to make sure the file isnt corrupt before execution
<samueldr>
but still, patch sets like those are not something well-suited for nixpkgs imo
<clever>
and that is rejecting my custom .bin files
<clever>
but, they did point me towards this, which claims to make a valid start.elf file
<clever>
thats a stage too late, but it still opens the door to poke around
<samueldr>
if I had more time, I would setup a repository like nixos-hardware, but something like nixos-sbcs, with prepared setups and options for each boards
qyliss has joined #nixos-aarch64
<samueldr>
clever: could that validation be a cryptographic signature?
<samueldr>
if so, it's almost guaranteed to be toast :(
<clever>
samueldr: i checked to see if a hash was just blindly appended on the end, but nothing obvious
<clever>
samueldr: i also tried hashing the first N bytes, then searching for the hash within the entire file, for every possible N, but nothing
<clever>
and repeated the above with md5, sha1, sha256, and sha512
<samueldr>
wondering if the hash is on-die, and the recovery.bin itself only has one valid variant
<clever>
this comment just says "appears to be valid"
<clever>
samueldr: i have 5 or 6 recovery.bin files, and they are still updating it
<clever>
its either a checksum to guard against corruption, or a full pub/priv signature
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 258 seconds]
bennofs_ has joined #nixos-aarch64
bennofs_ has quit [Client Quit]
bennofs_ has joined #nixos-aarch64
bennofs has quit [Ping timeout: 248 seconds]
<ryantrinkle>
samueldr: ok, yeah, that makes sense
<ryantrinkle>
as much as I would like to play with the hardware I have, my overall goal is to move nixos forward, so I don't want to do anything that isn't pushing in the same basic direction as the work you're doing
<samueldr>
my philosophy with it is that arm, just as x86_64, should work with the generic images
<samueldr>
but since reality doesn't match, something needs to be done :/
<ryantrinkle>
what i was hoping to get working next is the LCD that I've got on my pine64-lts
<samueldr>
with the way nixos composes, we are free enough to just put it to the side in another repo :D
<ryantrinkle>
yeah :)
<samueldr>
more and more I'm thinking NixOS on ARM (the wiki page) should be moved to a repo with discrete files that you would import
<ryantrinkle>
that sounds reasonable
<samueldr>
like, every device has its folder, with all quirks implemented
<ryantrinkle>
right
<samueldr>
and let's say all allwinner has quirk X, set it as an import to all allwinner devices
<samueldr>
(basically, the general idea I'm working on with Mobile NixOS)
<samueldr>
(but I'd like to see another person's implementation of that!)
<ryantrinkle>
well, my current status is that a good amount of stuff works "out of the box" with nixos-19.09 and linux kernel 4.19.89
<ryantrinkle>
and the mipi-dsi bus *shows up*, but has no devices
<samueldr>
my experience with additional hardware on those platform is extremely lacking
<ryantrinkle>
ah, i see
<samueldr>
I'm thinking that the fact that you need to edit device trees for all that to work is simply extremely dumb :(
<ryantrinkle>
hahahaha yeah
<samueldr>
device trees should have been a simple description of the basics, not a place to shove all your options you don't want to put as kernel options
<ryantrinkle>
well i'm glad "edit device trees" is what you said, because that's what i've been learning about
<samueldr>
I feel there's like an impedence mismatch, and there's a layer missing that would be like a device tree, but not an overlay you build it into
<samueldr>
I think it exists
<samueldr>
but lack time and drive to continue looking into it
* samueldr
digs up link
<ryantrinkle>
oh, another related question: do you have any suggestions on how to make the dev cycle time more reasonable? right now i'm doing a full cross nixos build and pushing that to the machine
<ryantrinkle>
takes about 15 mins to build linux
<ryantrinkle>
it seems a bit sad to have to do that just to edit device trees
<samueldr>
`not really
<samueldr>
make your build machine beefier :)
<ryantrinkle>
hahaha
<samueldr>
I don't really want to invest in impure hacks, even though it's detrimental to the dev cycle
<samueldr>
or even just building the kernel impurely
<ryantrinkle>
yeah, i completely agree
<ryantrinkle>
what i was wondering was more along the lines of splitting up the kernel build into multiple derivations
<ryantrinkle>
and/or wasn't there some kind of recursive nix stuff that came out recently?
<samueldr>
that would be interesting to see what's possible with those things coming up
<samueldr>
I think eelco worked on some ccache-like thing with flakes
<samueldr>
not sure if it's impure or pure enough
<samueldr>
but yeah, splitting the kernel per-makefile into discrete derivation "caches" could help I guess