joehh has joined #nixos-aarch64
<joehh> is there any documentation mapping rapberry pi kernel gpio stuff to upstream kernel gpio stuff?
<joehh> I'm trying to get a serial port working using a raspberry pi (running aarch64 nixos image) without any success and wanting to know where to look for guidance
<samueldr> hmm, for serial on the raspberry pi I did things as usually described
<samueldr> do you mean accessing the raspberry pi from serial, or using it to access something else over serial?
<samueldr> accessing the raspberry pi over serial worked out of the box using https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi#Serial_console
<samueldr> the latter, I wouldn't know for sure, but pretty confident it would work like on other raspberry pi distros
<joehh> using pi to access other hardware over serial devices
<joehh> ie I've a custom board with rs232 chips hooked up to the places expected when using raspian
<joehh> I guess my next step is to boot in raspian, see what modules etc are loaded and then look to nixos to see similar
<clever> joehh: dtb overlays are likely to play more of an impact
<clever> thats all handled in config.txt
<joehh> same stuff as for "standard" raspbian?
<clever> yeah
<joehh> great thanks - will give that a go
<clever> thats handled by the firmware, before nixos loads, so its pretty much the same
<samueldr> clever: doesn't u-boot load other dbts from the mainline folders with the generic distro configuration?
<samueldr> dtbs*
<clever> samueldr: rpi needs some config.txt flags to set the gpio secondary features, and matching dtb's to tell linux about the hardware it has enabled
<samueldr> clever: wouldn't you need u-boot to load the right mainline dtb in that case?
<clever> yeah, i'm not sure how u-boot plays into that...
<samueldr> I don't have the experience and knowledge to be sure about my assumptions here :/
<joehh> me either (yet :) ) my starting assumption is it will look similar, but be subtly different
<samueldr> hmmmm, the ext4 image *could* go from 2.0G to 1.6G AFAICT, but resize2fs's estimation of minimum size doesn't want to go that low :(
<samueldr> (in our case it's find since it's expanded at boot)
<samueldr> fine*
<gchristensen> omg what if we shipped "ISOs" which were ZFS with dedup and compression
<samueldr> not sure if it'd make a difference compared to squashfs
<samueldr> here it's for the sd-image which gets kinda installed in-place
<gchristensen> probably not :( :)
<samueldr> so can't do too much funny stuff :/
<samueldr> e.g. not sure things like reducing block size would be a good thing
<samueldr> though from a cursory glance, instead of 64ZiB, the fs max size would be 16ZiB
<gchristensen> O.o
<samueldr> 64 bit
<samueldr> I'm not sure what "File Size, Block Maps" means
<gchristensen> finally
<samueldr> because from 4TiB to 16GiB there *are* issues
<samueldr> e.g. if it means a max filesize of 16GiB
<clever> gchristensen: ive got a nix expression to generate a disk image with zfs and a nixos install
<gchristensen> nice
<clever> its currently rigged up for generating an AMI, but could also just ignore aws
* samueldr wonders if we shouldn't just `xz` the image
<samueldr> from 2.2G to 311M
<samueldr> the closure size sure wouldn't change, but the hydra build would work
<gchristensen> O.O
<gchristensen> ..yes?
<clever> samueldr: how much free space is on the disk image?
<samueldr> oh, and I didn't use -e or -9
<samueldr> clever: ~800MB, but resize2fs won't resize smaller
<samueldr> (without forcing its hand)
<clever> ah
<samueldr> oh, ~600MB*
<clever> and that doesnt explain how you shaved more then 600mb off, there must be a lot of compressible stuff
<samueldr> still would leave us with a ~1.6GB artifact instead of... 311MB
<samueldr> guess it's really compressible
<clever> samueldr: does zfs work on aarch64?
<samueldr> it probably does
<samueldr> but doesn't it use more ram?
<samueldr> if we're talking 512MB ram target device, it's going to hurt
<clever> the cache size will dynamically adjust, based on how much is in use
<clever> and by default, it will never use more then 50%
<clever> 32mb is the default min
<samueldr> (I know next to nothing about ZFS)
<samueldr> (I mean, actual experience)
<clever> gchristensen: if i had some ssh on the community box, i could try adapting the above gist to aarch64
<gchristensen> send a PR! :)
<clever> to which repo?
<gchristensen> /topic :)
<samueldr> though I'm not sure if there would be much of an impact in the final size
<clever> zfs has native compression
<clever> so it could be compressed and not need an unxz step
<samueldr> but then the FS is compressed, which could reduce perfs on lower-powered arm devices?
<clever> depends on the algo you use
<clever> and the part of it hogging ram, is where it caches the uncompressed variant
<samueldr> (though I'm sure if there was a ZFS image in addition to ext4 it would be liked by many)
<{^_^}> nix-community/aarch64-build-box#43 (by cleverca22, 9 seconds ago, open): add clever to aarch64 build box
<samueldr> HM, I missed something *obvious* here
<samueldr> or maybe I'm not
<samueldr> output limit exceeded, my fine hydra experts, is the build still complete or does hydra somehow kill as soon as the size is exceeded?
<samueldr> looking at the log the build seems to finish
<samueldr> (I had the impression minutes ago that I would have been killed the moment it exceeded the output limit)
<samueldr> hmm, and `xz` wouldn't help here as the ext4 fs itself is too big :/
<samueldr> 1.9G !!
<gchristensen> woot!
* samueldr realized he missed a step
<samueldr> I *so* want to point people towards a hydra-built 18.09 image :)
<gchristensen> meee toooo thank you for hacking on this!
<samueldr> at a glance, the closure seems "unfixable"
<samueldr> like, nothing wholly wrong specific to the aarch64 image
<samueldr> (still, things like not shipping gcc or binutils in there would help)
disasm has quit [Ping timeout: 240 seconds]
<samueldr> #51207 is the safe-to-do (AFAIK) image trimming
<{^_^}> https://github.com/NixOS/nixpkgs/pull/51207 (by samueldr, 46 seconds ago, open): sd-image: Slims the ext4 filesystem even more.
* samueldr tries it out
* samueldr just got gc'd
<samueldr> I think?
<globin> ugh cups needs an absolute path to AR for cross..
<globin> that took far too long to debug
orivej has joined #nixos-aarch64
joehh has quit [Ping timeout: 250 seconds]
<sphalerite> samueldr: but distributing images with linux+zfs is a GPL violation :/
orivej has quit [Ping timeout: 250 seconds]
<samueldr> who spoke of distributing it?
<samueldr> but yeah, not my issue at that point, and as I said previously: still working on making the ext4 one not-so-huge
<gchristensen> sphalerite: I have it on good authority we're in the clear to do so
<{^_^}> #51090 (by grahamc, 2 days ago, open): Revert "zfs cannot be distributed. Disabling it in the isos."
<sphalerite> ah fair enough
<globin> nice!
<globin> gchristensen++
<{^_^}> gchristensen's karma got increased to 48
<globin> sphalerite: (we were "distributing" images on our hydra btw)
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 1.9.1]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]