alp has quit [Ping timeout: 272 seconds]
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
mla has quit [Remote host closed the connection]
cole-h has quit [Quit: Goodbye]
tilpner_ has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
lafa has quit [Read error: Connection reset by peer]
alp has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
LnL- has joined #nixos-aarch64
LnL- has joined #nixos-aarch64
LnL- has quit [Changing host]
AmandaC has quit [*.net *.split]
alexarice[m] has quit [*.net *.split]
flokli has quit [*.net *.split]
flokli has joined #nixos-aarch64
alexarice[m] has joined #nixos-aarch64
AmandaC has joined #nixos-aarch64
<lovesegfault> heh
<lovesegfault> could've saved us some time
<clever> lovesegfault: that alos has some extra pins in the list!
<lovesegfault> yep
<clever> this claims that hsynv and vsync are connected
<clever> but the config.txt says to disable hsync/vsync
<clever> i can also see that they squeezed the touch stuff onto unused pins in the middle of color, 10, 11, 27
<clever> i would still like to know which controller is on the chip
<lovesegfault> touch controller?
<clever> display controller
<lovesegfault> Ah
<clever> what is that hyperpixel-init talking to?
<lovesegfault> right, I imagine some controller on the display
<lovesegfault> which needs to be told how to start
<clever> i did find this earlier, when researching a different display
<clever> thats an lcd driver chip for a 320x480 panel
<clever> but this is the kind of chip you would find directly on the glass, it over over 1000 pins
<clever> one for every single row and column
<lovesegfault> I think the controller chip is on the ribbon cable
<clever> oh
<clever> is there some kind of model# on the ribbon?
justanotheruser has joined #nixos-aarch64
<lovesegfault> let me see
<lovesegfault> Yes
<lovesegfault> copying
<lovesegfault> TXW397017(S or 5)2-RGB-02
<lovesegfault> it's very hard to read
<clever> lovesegfault: it looks like they have a paste with a lot of tiny balls of metal, and then they just shove the chip onto the glass, thru the paste
<clever> and then the bumps on the chip complete the circuit in spots
<lovesegfault> that's bananas
<clever> the paste likely also acts as an epoxy, to glue things together
<lovesegfault> clever: in that code `fsel[regnum]` is the same as rawaddr.offset(0x200000).offset(regnum * sizeof(c_void))?
<lovesegfault> (L16)
<clever> lovesegfault: it looks like they are exposing the i2c bus for the touchscreen, so you can put your own i2c devices onto the pi
<clever> its 32bit fields
<lovesegfault> I don't want to have to cast to volatile ptr to a slice
<clever> but you must cast to volatile, or it wont work
<lovesegfault> right, this is volatile
<clever> at offset 0x200000, you have 6 (i think) 32bit registers, 4 bytes between each
<clever> each of those registers, is a packed array of 10 x 3bit
<clever> and that 3bit int, says what model the pin should be in
<clever> mode*
<lovesegfault> annoying thing is offset is by counts of sizeof T
<lovesegfault> b/c it enforces alignment
<clever> that should be what we want
<clever> make T a 32bit int, and then just offset by regnum
<lovesegfault> well, we offset by 4096 instead of by 0x20000
<lovesegfault> right?
<lovesegfault> b/c it's 0x20000 / 0x20
<clever> nope, offsets of +0 +4 +8 +12 +14 +16 bytes
<clever> in addition to the 0x20000
<clever> one sec
<lovesegfault> Right, I'm talking just about the 0x20000 right now
<clever> #define GP_FSEL0 HW_REGISTER_RW( 0x7e200000 )
<lovesegfault> I mean that it won't be `.offset(0x20000)` but rather `.offset(0x1000)` b/c sizeof(T) is 0x2
<clever> #define GP_FSEL1 HW_REGISTER_RW( 0x7e200004 )
<clever> #define GP_FSEL2 HW_REGISTER_RW( 0x7e200008 )
<clever> oh, you can entirely get rid of the `0x200000` by just changing the mmap
<clever> mmap takes an offset, just add to that
<clever> and then reduce the size to 4096
<lovesegfault> right, so my offset is arm_phys + 4096?
<clever> nope
<clever> rawaddr = (void*)mmap(NULL, 16 * 1024 * 1024, PROT_READ | PROT_WRITE, MAP_SHARED, fd, arm_phys);
<clever> arm_phys + 0x200000
<lovesegfault> derp
<lovesegfault> right
<clever> and reduce the size from 16mb to just 4096 bytes
<lovesegfault> b/c that one is raw bytes
<lovesegfault> got it
<clever> rawaddr = (void*)mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, arm_phys + 0x200000);
<lovesegfault> yep
<clever> #define GP_FSEL6 HW_REGISTER_RW( 0x7e200018 )
<lovesegfault> what does "fsel" stand for?
<clever> function select
<clever> at 16mb chunk of MMIO is remapped from 0x7e00_0000 to bcm_host_get_peripheral_address()
<clever> so if you want to access 0x7e200004 then you need to access bcm_host_get_peripheral_address() + 0x200004
<clever> lovesegfault: oh, also, this code could be changed to eliminate the loops
<clever> lovesegfault: if you want to set pins 0-9 into alt2, you dont need 10 seperate writes
<clever> you dont even need a read, because thats all 10 pins in the bank
<clever> you can just fsel[0] = kBCM2708Pinmux_ALT2 | kBCM2708Pinmux_ALT2 << 3 | kBCM2708Pinmux_ALT2 << 6 | kBCM2708Pinmux_ALT2 << 9 .... | kBCM2708Pinmux_ALT2 << 27;
<clever> but for FSEL1, you want to leave 10&11 as inputs, so you have to read then write
veleiro has quit [Ping timeout: 260 seconds]
<clever> lovesegfault: ok, first, the register variable, the 7 FSEL registers are used to configure the function for 64 gpio pins
<clever> 0-9 in FSEL0, 10-19 in FSEL1, .... 60-63 in FSEL6
<clever> if you do pin/10, then you get which fsel register you want
<clever> lovesegfault: following so far?
<lovesegfault> Oh, I see
<clever> next, each FSEL register is a packed array of 3bit ints, 10 in total
<clever> so pin 17 % 10, gives you 7, the pin within the bank
<clever> then 7 * 3, gives you the bit that pin7 starts at
<lovesegfault> each pin is one byte within these fsel banks?
<lovesegfault> wait, no, 4 bytes?
<clever> nope, each pin is 3 bits, within a 4 byte register
<clever> a 4 byte register has 32 bits
<lovesegfault> Oh, most is just unused?
<clever> nope
<clever> 30 bits are used, to assign the function for 10 pins
<lovesegfault> 2 bits are unused
<lovesegfault> *?
<clever> yep
<lovesegfault> at the end?
<clever> yeah, bits 30 and 31 are unused
<clever> page 92
<clever> next problem is here on line 66
<clever> you must read the current value of FSELn from MMIO
<clever> then clear the 3 bits your about to modify
<clever> and ! is bit invert, right?
<lovesegfault> Oh, yep
<clever> so that will take a 0x7 (3 1 bits), and shift it over to align with the given pin
<clever> then invert it, so those 3 bits are 0, and all others are 1
<lovesegfault> got
<lovesegfault> *got it
<clever> then & will clear just the 3 bits in question
<clever> then the | will slot the new mode into those 3 bits
<clever> and write the result back to mmio
<lovesegfault> we need to offset self.addr still right
<clever> also, self.addr isnt being offset by register yet
<clever> yeah
<clever> could also change the type of register
<clever> and pin could be a u8 even
<lovesegfault> I made everything u32 to avoid a ton of casts in :68
<clever> technically, pin could be a u6, lol, but i dont think rust has that
<clever> the reg is 32 bits
<lovesegfault> oops
<clever> i need to use binary in c more, heh
<clever> it makes things like this more clear
<lovesegfault> does C do 0bxxxx too ?
<clever> i think so
<clever> where is PinMode defined?
<clever> yep, that looks good
<clever> now we just set the mode for all the pins
<lovesegfault> all of them?
<lovesegfault> just 0..27 = alt2?
<clever> 0-9, 12-17, and 20-25
<lovesegfault> *0..28
<lovesegfault> ah, yeah
<clever> 10/11 are the touchscreen data/clock
<clever> so you dont want to set 10
<lovesegfault> .. is exclusive at the end
<clever> ah
<lovesegfault> you need ..= to make it go brrr
<clever> same as c then, it just looks more confusing
<clever> can you do 2 at once, like 0..10 12..17 ?
<lovesegfault> I thought I could
<lovesegfault> but now I can't find how
<lovesegfault> well
<lovesegfault> I can be nasty
<clever> and then page 102 says what alt2 does for each pin
<clever> we are setting it to a lovely bank of <reserved> because broadcom wants to keep secrets :P
<clever> thats the more up to date docs, for vc4 and vc6
<lovesegfault> broadcom :(
<clever> 18, 19, the chip select for something, and backlight control
<clever> can be left as input
<lovesegfault> let's try this out!
<clever> one other thing as well
<clever> if you ssh into the pi, does it have /dev/gpiomem ?
<lovesegfault> yep
<clever> if you mmap that at offset 0, you get the GPIO registers
<lovesegfault> :O
<clever> so you dont need bcm_host_get_peripheral_address() or the other offset
<clever> also, the permissions on it, what group is gpiomem in?
<clever> but youll want an if statement
<clever> because gpiomem may not exist in the mainline linux
<clever> under raspbian, /dev/gpiomem is in a special gpio group, which pi is a member of
<clever> so you can mess with gpio, without having root
<clever> so, if you can open /dev/gpiomem, mmap offset 0, your done
<clever> if you fail to open it for any reason, fall back to /dev/mem with the bcm_host_get_peripheral_address() + gpio offset
<lovesegfault> on it
<lovesegfault> ta-daa
* clever gets next link
<clever> lovesegfault: these 5 functions can do most gpio actions you would want to do
<lovesegfault> what happens if you setPin on a pin that is not in hi/lo mode?
<lovesegfault> oh, wait
<clever> not sure, i think it does nothing
<clever> only kBCM2708PinmuxOut lets you use it as gpio
<clever> kBCM2708PinmuxIn basically just does nothing
<clever> and input always works, in any mode
<lovesegfault> interesting
<clever> so you can use the input path to spy on the DPI activity
<lovesegfault> I wrote this cursedness to get it to cross
<clever> you want to look into naersk
<clever> that can cross-compile rust
* lovesegfault fiddles
rajivr has joined #nixos-aarch64
<lovesegfault> clever: do you know how to do it handy?
<clever> you want to use pkgsCross to tell naersk that your cross-compiling
<clever> as-in, make an overlay that puts hyperpixel into nixpkgs
<clever> then do pkgsCross.aarch64.hyperpixel
<clever> and naersk will magically just do the right thing
<clever> your still requesting an x86 build
<lovesegfault> yep
<clever> also, that wont work at all
<clever> the buildInputs vs nativeBuildInputs only works if you use callPackage
<clever> yes, its very misleading
<lovesegfault> hm?
<lovesegfault> I'm using callPackage on naersk itself
<clever> lines 7&8 will always be the same arch, even when you cross-compile
<clever> you must use callPackage to load this default.nix
<lovesegfault> Oh
<clever> and callPackage must be the thing to give you cargo and raspberrypi-tools
<clever> if you `with pkgs;` the magic goes away
<clever> now the magic works once more
<clever> pkgs.pkgsCross
orivej has joined #nixos-aarch64
<lovesegfault> O.O
<lovesegfault> I will be blown away if this works
<clever> but it can be better to use an overlay to put it into nixpkgs
<clever> then you can just pkgsCross.aarch64-multiplatform.hyperpixel to get a 64bit one, or pkgsCrpss.arm6.hyperpixel to get an arm6 one
<lovesegfault> wonder how long binutils takes to build
<lovesegfault> and whether it's worth copying to the phat box
<clever> installPhase
<lovesegfault> noice
<lovesegfault> well, but now it's building gcc
<clever> oh, you should maybe look into `--option builders`
<lovesegfault> hehehe
<clever> it ssh's as root
<clever> so it needs to be in roots ~/.ssh/config
<clever> or use an IP
<lovesegfault> these boxes don't root ssh
<clever> from root, not to root
justanotheruser has quit [Ping timeout: 260 seconds]
<lovesegfault> oh, I see
<lovesegfault> let me show you this
<lovesegfault> it's doing magicfuckery
<clever> ah, search domains
<lovesegfault> b/c it's our company's machine
<clever> i just did that via /etc/resolv.conf
<clever> it may help if you shove it into /etc/ssh/config instead
<lovesegfault> I had tried doing something like that before but it always goes kaboo,
<clever> programs.ssh.extraConfig
<lovesegfault> it also _requires_ an ssh agent running
<clever> ah, that complicates it a bit
<lovesegfault> b/c it adds certs to it
<clever> you have to `sudo nix build`, so the build isnt forked out to nix-daemon, but is a child of sudo, and inherits your agent vars
<lovesegfault> and that's how you ssh in
<lovesegfault> so I have this whole setup to get it to kind of work
<lovesegfault> uh
<lovesegfault> yep
<clever> qemu-user lets you cheat!
<clever> boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; on the host
<clever> but its been patchelf'd improperly
<lovesegfault> Hm
<clever> try not-nightly?
lafa has joined #nixos-aarch64
<clever> and this is why i dont let my code rust :P
<lovesegfault> :D
<clever> export DRV=$(nix-instantiate ...) ; nix-copy-closure --to $HOST $DRV ; ssh $HOST nix build $DRV ; OUT=$(nix-store --query --binding out $DRV) ; nix-copy-closure --from $HOST $OUT
<clever> lovesegfault: try making a shell script like this?
<lovesegfault> good idea, I do this enough it's worth making a script
<clever> nix-copy-closure -s --include-outputs, may also help
<clever> 1st part lets the source use caches, 2nd part will copy any pre-built stuff over too
<clever> s/source/dest/
<clever> the script could do `HOST=$1 ; shift ; ... nix-instantiate "$@"
<clever> then you can just do `script host default.nix -A foo`
<lovesegfault> I always build on the same host :P
<clever> ah, then just "$@" without the shift
<clever> the drv variable should be exported, for gc reasons
<clever> you can do the query locally
<clever> since you have the drv locally
<clever> when nix does a GC, it will peek at the env vars for every proc
<lovesegfault> that's pretty cool
<lovesegfault> TIL
<clever> and if it finds a storepath, it will treat it as in-use
<clever> name the pid of something thats unlikely to have secrets in its env
<lovesegfault> this calculator I just opened
<clever> and scroll up to see how i did it
<clever> xargs -0 -n1 echo < /proc/13464/environ
<lovesegfault> :O
<clever> that file contains a \0 seperated list of key=value pairs
<lovesegfault> that is awesome
<lovesegfault> so it does this for /proc/* and finds store paths within?
<clever> yeah
<clever> and this directory, shows all open file descriptors
<clever> this one then shows flags, and seek position
<lovesegfault> Oh, I can see _how_ it opened the file and where it's seek'd to!
<clever> and this is the executable behind a pid
<clever> and its working dir
<clever> that was a symlink, but your ls followed it!
<lovesegfault> :D
<clever> also useful, /proc/PID/root, is what / maps to for that proc
<clever> you can use that to spy inside containers
<clever> and if /proc isnt setup right, even escape the container
<clever> also, all of those /proc symlinks are magic, you can open the symlink, even if the link's target doesnt exist
<clever> lrwx------ 64 bemeurer 22 Sep 22:35 /proc/13464/fd/11 -> /memfd:wayland-cursor (deleted)
<clever> for example, that filename doesnt exist
<clever> but if you try to just blindly open /proc/13464/fd/11, youll get a valid handle to the same object
<clever> in this case, its likely shared memory for the framebuffer
<lovesegfault> lol
<lovesegfault> it froze
<clever> thats what happens when you cat binary files :P
<clever> xoff probably
<clever> and i dont know the tmux binding to kill a window
<clever> next handy trick
<lovesegfault> it's x apparently
<clever> gdb /proc/13464/exe 13464
<clever> that attaches to a given pid, without you needing to know what the binary actually is
<lovesegfault> :O
<clever> `cat /proc/13464/maps` and that one is all mmap()'d things
<lovesegfault> is this how htop works?
<clever> status and stat, are what then feed into `top` and `ps`
<clever> yeah
<clever> status is human readable, stat is machine readable
<clever> not sure what syscall does
<lovesegfault> seems odd that I don't need sudo to go spelunking like this?
<clever> and that pagemap file, tells you the physical page for a given virtual page
<clever> you can only dig into procs in your own user
<clever> viins ❯ ls -l /proc/1/fd/
<clever> "/proc/1/fd/": Permission denied (os error 13)
<lovesegfault> Ah, I see
<lovesegfault> that makes perfect sense
<clever> root is special as always, and can spy on anybody
<clever> thats how nix-daemon can find gc roots for other users
<lovesegfault> Right, makes sense
<clever> and /proc/self is another magic symlink, it always points to the current pid
<lovesegfault> how tf does this stuff work behind the scenes?
<clever> got a clone of the linux source?
<clever> https://github.com/raspberrypi/linux is the one ive mainly been refering to
<clever> line 31 sets up what to call when you try to read the symlink
<clever> 16 then gets the pid for whatever is trying to read the symlink
<clever> and 25 will printf it into a buffer, and return that buffer
<clever> `current` is a special pointer in linux, that refers to the current thread
<lovesegfault> what's `unlikely`?
<clever> a hint to the compiler
<lovesegfault> Oh, branch prediction
<clever> yeah
<clever> it basically makes it `if (fail) goto handle_failure;
<clever> instead of `if (!failure) goto skip_error_handler;
<lovesegfault> got it
<clever> the idea is to not branch in the more likely case, so the next opcode is just the next one in ram
cole-h has joined #nixos-aarch64
<clever> ah, and here is the fdinfo file
<lovesegfault> "return !!file"
<lovesegfault> wat
<clever> it was a pointer
<clever> that turns any non-zero value into a plain 1
<lovesegfault> I see
<lovesegfault> why not just `return 1`?
<clever> the first ! turns 0->1 and nonzero->0
<clever> the second ! inverts again, so 0->1->0 and nonzero->0->1
<clever> since it has to return if file was nonzero or zero
<lovesegfault> Ah, I see
<lovesegfault> also I don't understand why it's building rustc again...
<lovesegfault> ugh
<lovesegfault> what
<lovesegfault> idk what naersk is doing
<clever> same, lol
<lovesegfault> I have an idea
<lovesegfault> boom
<lovesegfault> just force it to build on the aarch64 remote builder
<lovesegfault> and call it a day :P
<clever> doing it on the remote system is pretty easy
<clever> just `import <nixpkgs> { system = "aarch64-linux; }`
<clever> then it knows its arm64->arm64, and finds the nearest arm64 box
<lovesegfault> ugh, I need to point it to libclang
<lovesegfault> does the usual envvar thing work?
<clever> dont remember
<clever> llvmPackages goes into the callPackage line
<clever> oh, and because we turned on qemu-user, it can do "native" aarch64 builds locally
<lovesegfault> so it's using the remote & my local machine
<lovesegfault> noice
<lovesegfault> is that a static bin?
<lovesegfault> I doubt it
<clever> dynamic, but you could use pkgsStatic.callPackage to force static
<lovesegfault> while that runs let's try it out like so
<clever> ah, the rpi tools are pre-compiled dynlibs
<clever> no static available
<lovesegfault> ;-;
<lovesegfault> wth
<clever> some of them are closed-source, some are just a lazy package
<clever> > > ah, so that part would still be waiting on a proper ISP driver in linux
<{^_^}> error: syntax error, unexpected '>', at (string):324:1
<clever> > Broadcom IP - there won't be a native Linux driver for it.
<{^_^}> error: syntax error, unexpected ')', expecting ID or OR_KW or DOLLAR_CURLY or '"', at (string):325:1
<clever> lovesegfault: anoyingly, some parts of the pi can be made public, and get drivers, while other parts are "Broadcom IP" and will never get proper drivers
<clever> its not really clear where the line gets drawn
<lovesegfault> That's... super annoying
<clever> but i can see how the ISP has all of their secret sauce
<clever> it deals with the de-bayering the camera images, color correction, and lense distortion correction
<clever> lots of complicated image stuff, that has to be done at high frame rates
<lovesegfault> alright, so, display is down
<lovesegfault> DISPLAY
<lovesegfault> IS
<lovesegfault> UP
<clever> :D
<lovesegfault> :D
<clever> does rust have #ifdef ?
<lovesegfault> yeah, kind of
<lovesegfault> why?
<clever> if you use it to comment out the support for /dev/mem, you dont have to link to the broadcom libs
<clever> then your static problem goes away
<clever> but it only works if /dev/gpiomem exists, so youll want to keep the /dev/mem code as a option you can turn back on
<lovesegfault> What's the scenario where gpiomem _doesn't_ exist?
<clever> it may not be in the upstream linux kernel
<clever> so things would rely on using the rpi fork of linux
<lovesegfault> I see
orivej has quit [Ping timeout: 256 seconds]
<lovesegfault> clever: do we have the source for that _one_ function we end up using?
<clever> lovesegfault: thats where it lives
<lovesegfault> let's see what get_dt_ranges does
<clever> the file contains a series of 32bit or 64bit ints
<clever> getting an example...
<lovesegfault> let's just impl this in rust, looks not-bad enough
<lovesegfault> no more binden, no more linking anything
alp has joined #nixos-aarch64
<clever> lovesegfault: this says that 0x7e00_0000 is mapped to 0x2000_0000, length 0x1000000
<lovesegfault> I see
<clever> lovesegfault: but on pi4, it gets a bit more complicated, because DT only supports 32bits, so you need 2 32bit ints to represent a 64bit int
orivej has joined #nixos-aarch64
<clever> #address-cells = <0x01>;
<clever> #size-cells = <0x01>;
<lovesegfault> how can dts' not end up stepping all over each other?
<clever> this says how many 32bit ints make up an addr and size
<lovesegfault> (when applied)
<clever> can you ssh into the pi?
<clever> this says that all adresses for the parent side are 2 32bit ints long
<clever> 00000000 00 00 00 02 |....|
<clever> [root@aurelius:~]# hexdump -C /proc/device-tree/#address-cells
<clever> [root@aurelius:~]# hexdump -C /proc/device-tree/#size-cells
<clever> 00000000 00 00 00 01 |....|
<lovesegfault> what's this |....| stuff
<clever> but lenghts are 1 32bit long
<clever> thats the char for each int
<lovesegfault> ah, I see
<clever> [root@aurelius:~]# hexdump -C /proc/device-tree/soc/#address-cells
<clever> 00000000 00 00 00 01 |....|
<clever> then for the child bus, an addr is 1 32bit
<clever> [root@aurelius:~]# hexdump -C /proc/device-tree/soc/#size-cells
<clever> 00000000 00 00 00 01 |....|
<clever> and a size is also 1 32bit
<clever> [root@aurelius:~]# hexdump -C /proc/device-tree/soc/ranges
<clever> 00000000 7e 00 00 00 00 00 00 00 fe 00 00 00 01 80 00 00 |~...............|
<lovesegfault> oh, just like what we saw on the dts file
<clever> so first you have a child addr, 1 32bit wide, 7e 00 00 00
<clever> then you have a parent addr, 2 32bits, 00 00 00 00 fe 00 00 00
<clever> then a length, not sure which size (but both are 1), 01 80 00 00
<clever> so if you want to access 0x7e20_0000, you must instead access 0xfe20_0000
<clever> bcm_host_get_peripheral_address() just blindly assumes the 1st entry is for 0x7e00_0000, and it ignores #address-cells entirely
<clever> it winds up reading the upper 32bits of the parent addr, gets a 0, then tries again in 64bit mode
<lovesegfault> *chefs hands*
<clever> on pi0/pi1, it always maps to 0x2000_0000
<clever> pi2/pi3, 0x3f00_0000
<clever> pi4, its usually 0xfe00_0000
<clever> they keep moving it out of the way of ram, then ram gets bigger :P
* lovesegfault looks at his 8GB Pi4
<clever> you might be loosing 16mb of ram, due to the placement
<clever> i havent investigated how the 4 changes thingsfully
<clever> but, there is also an MMU at play
<lovesegfault> Pi3 doesn't have an MMU?
<clever> all of them have multiple MMU layers
<clever> basically, there is a 64 slot page-table, that maps 16mb chunks of "arm physical" to 16mb chunks (but 2mb aligned) chunks of the vpu bus
<clever> that is what maps 0x20/3f/fe to 0x7e
<clever> and because of that, i can put MMIO at 0x20 on a pi3
<lovesegfault> vpu is the video proc?
<clever> yeah
<clever> mapBusToArm(VC4_PERIPH_BASE, ARM_PERIPH_BASE);
<lovesegfault> which is responsible for early boot right?
<clever> yeah, but all IO hw also lives in the vpu space
<lovesegfault> O.O
<clever> so the arm has to go thru this MMU to access anything
<clever> #define VC4_PERIPH_BASE 0x7E000000
<clever> #define ARM_PERIPH_BASE 0x3F000000
<clever> this code will configure the MMU to map 0x7e to 0x3f, to make it function like a pi2/pi3
<clever> lovesegfault: but this part is some fancy stuff i added
<clever> that will patch the soc/ranges at boot time, to match where the firmware put it
<clever> so i can freely change just ARM_PERIPH_BASE (as long as its 16mb aligned), rebuild 2 tiny blobs (under 128kb total), and linux will magically boot
<lovesegfault> ah, nice
<clever> did you delete my source from ~/src? or am i on the wrong system again? lol
<lovesegfault> :D
<clever> and theres all the src
<lovesegfault> how are you enforcing the alignment?
<clever> i dont, lol
<lovesegfault> :D
<clever> but
<clever> line 169 will divide by 16
<clever> so it rounds down to the next alignment
<lovesegfault> I see
<clever> but then the field in the dts will be wrong, and everything fails
cirno1000 is now known as cirno999
<clever> but line 83 wont match, so it will hang on boot
<clever> rather then doing whacky things
<lovesegfault> Ah, I sww
<lovesegfault> *see
<lovesegfault> so, to round up: all that fn is doing is reading of the mapping from /proc/device-trees and almost guessing at the right one?
<lovesegfault> that fn = the one we are linking in
<clever> yeah
<lovesegfault> RIIR!
<clever> page 15
<clever> lovesegfault: if you want to be really really correct, you need to find the node with compatible = brcm,bcm2711-gpio or brcm,bcm2835-gpio
<lovesegfault> so it's (child-bus-address, parent-bus-address, length)
<clever> lovesegfault: then find recursively translate the reg= on it, as you go up the tree
<clever> so that would be the soc/ranges in this case (its only one deep)
<clever> but now we are just making it overly complicated :P
<clever> i dont think they will ever move the gpio block on the vpu side
<lovesegfault> Right
<lovesegfault> how do they know to seek 4 bytes on L153 (which is used on L143)
<lovesegfault> i.e. how to set offset
<lovesegfault> are they just assuming the child-bus-address size?
<clever> the child-bus-address is 32bits (because #addr-size is 1)
<clever> the code we referenced just assumes its 1
<lovesegfault> right
<clever> and then 32bit vs 64bit, you have to refer to the #addr-length on the parent node
<lovesegfault> the correct way of doing this is to parse size-cells, which will tell you that it's 4 bytes
<clever> yeah
<lovesegfault> where's #addr-length?
<lovesegfault> wait
<lovesegfault> why are those different?
<clever> bottom right screen, the child is 32bits, the parent is 64bit
<clever> because the child addr space only uses 32bit addresses
<clever> 2020-09-23 04:05:58 < lovesegfault> so it's (child-bus-address, parent-bus-address, length)
<clever> so child-bus-address is 32bit, parent-bus-address is 64bit
<clever> and length is 32bits, because it uses the child's #size-cells
<lovesegfault> I see
<lovesegfault> ok on step 1?
<clever> find and parse the #address-cells, soc/#address-cells, and soc/#size-cells
orivej has quit [Ping timeout: 265 seconds]
quinn has quit [Ping timeout: 260 seconds]
<clever> you can just read it as a 4 byte buffer, and then parse as a big-endian u32
<clever> that should be easy in rust
* lovesegfault goes check
<lovesegfault> ye
<lovesegfault> it's nice
<clever> that says that #address-cells will always be u32
<clever> If missing, a client program should assume a default value of 2 for #address-cells, and a value of 1 for #size-cells.
* lovesegfault reads
<lovesegfault> goddamn it's different
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
<lovesegfault> clever: part 1 is done
<clever> now you need to read an array of 3 ints from the ranges file
<lovesegfault> ints = i32?
<clever> a child addr (soc/#size-cells says the size)
<clever> a parent addr (#address-cells says the size)
<clever> oops no
<clever> a child addr (soc/#address-cells says the size)
<clever> a parent addr (#address-cells says the size)
<clever> then a length, (soc/#size-cells says the size)
<clever> page 15 of the pdf
<clever> because the parent is 64bits, that would be a u32, u64, and u32
<lovesegfault> but that changes if the parent is 32bit
<clever> yeah
quinn has joined #nixos-aarch64
<clever> so you need to read a child addr, auto-detect how many bytes to consume, and increment your read pointer
<clever> then repeat
<lovesegfault> > auto-detect how many bytes to consume
<{^_^}> undefined variable 'auto-detect' at (string):324:1
<clever> if size is 1, read a u32, increment by 4
<clever> if size is 2, read a u64, increment by 8
<clever> each slot uses a different size
<lovesegfault> if size is 3 it's an alien computer
<clever> yeah, lol
<lovesegfault> can I just return (u64, u64, u64)?
<clever> yeah
<clever> but also, its an array
<clever> the hexdump i see in bottom-right, is 3 sets of that
<lovesegfault> right
<clever> once youve parsed it, you need to go over the array, and check (between child-addr and child+length) to see which one contains 0x7e20_0000
aforemny has joined #nixos-aarch64
<lovesegfault> clever: is it safe to use this https://doc.rust-lang.org/std/io/trait.Read.html#method.read_to_end
<lovesegfault> os is there a scenario where this thing is _HUGE_
<clever> it will likely be small
<clever> i wouldnt expect it to even pass 1kb
<lovesegfault> alright, then I'm going to read_to_end into a vec of u8
<clever> oh, that gives me an idea
<clever> for (int i=0; i<(size*4); i++) { temp = (temp << 8) | buffer[pos++]; }
<clever> that will consume size*4 bytes, in big-endian order, and increment pos as it consumes
<lovesegfault> nice
<lovesegfault> eh, I think I'll do it like this
<clever> once your done parsing, can you print it as 3 lines of 3 hex numbers?
<clever> like, printf("0x%x 0x%x 0x%x
<clever> \n");
<lovesegfault> yep
<lovesegfault> wait
<lovesegfault> the size of child_addr should come from soc/#address-cells
<clever> yeah
<clever> same for the size of the length field, soc/#size-cells
<lovesegfault> grr
<lovesegfault> I'm diggin myself into a smol hole with these matches
<clever> lovesegfault: the take function may also be of use
<clever> lovesegfault: is there any function to turn a vector of 4 u8 into a u32?
<lovesegfault> in the stdlib no
<lovesegfault> you can do `BigEndian::read_u32` here though
<lovesegfault> b/c I have the crate
<clever> ah
kiren has quit [Remote host closed the connection]
<lovesegfault> I want drain
<lovesegfault> aha!
<lovesegfault> clever: there we go
<lovesegfault> I think this is correct
<lovesegfault> it does some alloc nonsense, but ala
<lovesegfault> it does some alloc nonsense, but alas
<clever> give it a run thru the printf above, and lets see what the results are!
<lovesegfault> g.d. old rust
juliosueiras has quit [Ping timeout: 260 seconds]
<lovesegfault> 1.46 is from a month ago...
<clever> i think you need some cleanSource
<lovesegfault> oh god
<lovesegfault> yes
<lovesegfault> lol
<clever> ah, just removing target would help a lot
<lovesegfault> boom
<clever> now it doesnt have to copy 400mb of junk
<lovesegfault> :D
<clever> nix copy can take attrs
<lovesegfault> wait
<lovesegfault> eh
<lovesegfault> wait
<lovesegfault> huh
<clever> nix copy is like nix build, no -A
<clever> but it wants an attr
<clever> so your file must return a set
<clever> also, copy can take ./result
<clever> let me try typing something when its built
<clever> or just on irc...
<clever> nix copy --no-check-sigs --to ssh://ip ./result && ssh ip -t sudo $(realpath ./result)/bin/something
<clever> lovesegfault: try like that
<clever> i hate it when tab-completion expands exprs
<lovesegfault> lol it's preferring gpiomem
<clever> break the path
<clever> gpiomem-404
<clever> and stick a nix-build at the start of the previous cmd
<clever> now its just 1 step to test
<lovesegfault> no way
<lovesegfault> it works
<clever> 0x7e00000000000000 is wrong
<clever> it should be 0x7e000000
<lovesegfault> it's padded to u64
<clever> the padding is on the wrong end
<clever> 0x000000007e000000
<lovesegfault> ah, right, because I did it in little endian universe
<clever> and the host addr is also wrong
<clever> i think thats right?
* lovesegfault is confused
<clever> hmmm
<clever> size isnt right
<lovesegfault> right
<clever> why is that hard-coded to 2? lol
<clever> oh, the default
<lovesegfault> bingo
<clever> size-cells, not size_cells
<clever> i could tell that it was the size, because the host addr had 2 fields
<clever> so the read was mis-aligned
<lovesegfault> noice :D
<clever> now, you need to loop thru things, and check if 0x7e20_0000 is between child and child+length
<clever> until you find the right range in rangeS
<clever> or just assume 0x7e00 is always the start
<clever> add all 3 sizes, then *4
noneucat has left #nixos-aarch64 ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
<clever> once you find the right range, compute (0x7e20_0000 - child) + parent
<clever> and that will be the offset you should mmap from /dev/mem
<clever> and those are the ranges for all MMIO, any peripheral
<clever> 0x7e20_0000 is the addr for gpio
<lovesegfault> let's try :D
<clever> hyperpixel_init-unknown> warning: unused import: `ReadBytesExt`
<clever> lovesegfault: does rust ignore the _ in the hex number? what does the && do to it?
<lovesegfault> it ignores _ yeah
<lovesegfault> && is making it into a ref of a ref because the iterator is being wonky
<clever> we are looking for an instance where child < 0x7e20_0000 and (child+length) > 0x7e20_0000
<lovesegfault> lol
<clever> filterSource can exclude target automatically
<clever> without having to rm it
<lovesegfault> ayoooo
<clever> > (4263510016).toString(16)
<clever> 'fe200000'
<{^_^}> value is an integer while a set was expected, at (string):324:1
<clever> yep, looks right
<clever> just needs some hex encoding to save you some sanity
<lovesegfault> let's try it out
<lovesegfault> screen is off
<lovesegfault> SCREEN
<lovesegfault> IS
<lovesegfault> ONNNNNN
<lovesegfault> will it blend?
<clever> and for your next challenge, the init sequence!!
* lovesegfault dies
<lovesegfault> what's /dev/gpiochip0?
<clever> the linux api for accessing gpio, but it can only do plain gpio, no alt functions
<clever> you can either use the same api, or you can keep using raw MMIO
<lovesegfault> How does this look with raw mmio?
<lovesegfault> I'm already this deep into it
<clever> the same as youve done for FSEL
<clever> just ~4 more registers
<clever> first, we want to implement setup_pins
<clever> it should set the 3 pins to output mode, using the existing set_pin function
<clever> 27, 26, and 18, in that order
<clever> next, we need to write a way to set gpio level
<clever> page 95
<clever> GPSETn and GPCLRn
<clever> #define GP_SET0 HW_REGISTER_RW( 0x7e20001c )
<lovesegfault> I see it
<clever> #define GP_CLR0 HW_REGISTER_RW( 0x7e200028 )
<clever> each is an array of 3 u32 registers
<clever> which then contains 32 bits each, for 32 pins
<clever> so pin/32 tells you which register, and pin%32 tells you which bit
<lovesegfault> so I want two methods: set_pin(pin) and clear_pin(pin)
<clever> you can also make it one function
<clever> just gpio_set_level(pin, level)
<lovesegfault> got it
<clever> if (level == 0) GPCLR, else GPSET
<clever> level can be a bool
<clever> true == high
<clever> reg and bit offset first
<clever> same as how the top of the screen does it, but with 32
<clever> 1 bit per pin this time
<lovesegfault> got it
alp has quit [Ping timeout: 272 seconds]
<clever> next, u32 *foo; if (level) foo = GPSET; else foo = GPCLR;
<clever> then foo[register] = 1 << pin_shift;
<clever> GPSET and GPCLR being offsets into the mmap'd area
<clever> of +0x1c and +0x28
<lovesegfault> I see
<clever> ah, and page 95 answers a question you asked earlier
<clever> if you poke SET or CLR, it will take effect when the pin is set to output
<lovesegfault> huh
<lovesegfault> cool
<clever> so now we need to decide between set or clear, based on level
<clever> lovesegfault: ok, now we offset into level, based on register
<clever> level is an array of 3 u32, and we have to volatile write to the right one
<clever> lovesegfault: does offset work in units of u32 or byte?
<lovesegfault> by sizeof(T)'s
<clever> and what is self.0's T?
<lovesegfault> so by u32's
<clever> then the 1c and 28 have to /4
<clever> ok, now pin_level is the addr of the exact reg we want
<clever> volatile write to that, with 1 << pin_shift
<clever> ok, next up
<clever> do you see the ,0 and ,1 in setup_pins?
<lovesegfault> yep
<clever> * @param default_val Initial line value.
<clever> so you need to set clk and mosi to 0, and cs to 1, before you set them to output
<clever> a constant for clk, mosi, and cs may help
<lovesegfault> which is which?
<clever> and that is just 1 line of main()!
<lovesegfault> :D
<clever> ok, now copy/paste that whole commands array over
<clever> ok, now we need to loop over each entry in there
<clever> if the entry if -1, we delay for WAIT usec and go to the next one
<clever> if its not -1, we pass it to write_9bit, but cast it to a u32
<clever> u16*
<clever> can just make the array i16's
<lovesegfault> is set_value == set_level?
alp has joined #nixos-aarch64
<clever> yep
<clever> and those are pointers created when you reserved each pin
<lovesegfault> ah
<clever> so the mask starts out at (1 << 8), which would be 0x100
<clever> the 1st big, in big-endian order
<clever> ah, that code looks a bit sloppy
<clever> they setup mask to select the right bit
<clever> then instead of moving the mask, they move the data, lol
<clever> and you still need the clock pin
<lovesegfault> ha
<clever> yep, that should also work
<clever> now we pulse clock low for DELAY usec, then high for DELAY
<clever> 100usec == 10khz i think?
<clever> but probably 5khz, because its 200usec per cycle, 100 low 100 high
<lovesegfault> right
<clever> and set mosi back to low when your done sending data
<clever> and if we did it right, that entirely replaces the init program
<clever> oh, but cleanup
<lovesegfault> that's all this did?
<clever> one sec
<clever> clk is on gpio27
<clever> but touch interrupt is also 27
<lovesegfault> ah
<clever> we have to set clk/mosi/cs back to input when we are done
<lovesegfault> got it
<clever> i'm also curious
<clever> the screen is 800x480
<clever> thats 0x320 x 0x1e0
<clever> ehhh, nothing obvious in the commands
<lovesegfault> DISPLAY IS ON
<lovesegfault> HAHAHAHAHA
<lovesegfault> WE DID IT
<clever> now shove it all in github and call it done!
<clever> also, test it on the pi3 too :P
* lovesegfault makes github repo
<lovesegfault> alright, it's on GH
<lovesegfault> for tomorrow:
<lovesegfault> 1. clean up the code a bit
<lovesegfault> 2. rpi3 test
<lovesegfault> 3. shove it into nixpkgs :D
<clever> :D
<clever> 4: closure size??
<lovesegfault> it's smol
<clever> it depends on glibc, try building it with pkgsStatic
<lovesegfault> it explodes
<clever> 38mb before
<lovesegfault> glibc ;-;
<clever> it exploded because of the broadcom libs
<clever> which we dont use anymore
<clever> you put a result symlink into the github repo
<lovesegfault> lol
<clever> config.toml needs some musl stuff
<lovesegfault> oh, it's failing to build rustc for aarch64 musl
<lovesegfault> hm
<clever> also, we are taking things to go levels of extreme :P
<clever> dont import anything, rewrite it all
<lovesegfault> I WANT IT STATIC
<lovesegfault> noooo
<clever> i think you need to turn off c++ exceptions?
<clever> to google!
<clever> oh, it might be libunwind
<lovesegfault> try it, I need to brush my teeth real quick
<{^_^}> rust-lang/rustup#2213 (by thedrow, 34 weeks ago, open): Rustup should warn if libgcc is not installed on Alpine
<lovesegfault> huh
<clever> i see some of the issue, but not fully
<clever> Error loading shared library libgcc_s.so.1: No such file or directory (needed by /nix/store/9lg5i8inybsgwsajzjk2s2214rfnbvsq-rust-aarch64-unknown-linux-musl/lib/librustc_driver-57cbb596dfda8c41.so)
<clever> lovesegfault: why are these .so files, we asked for static?
<clever> but theres more, let me show in the shell...
<lovesegfault> maybe naersk doesn't obey
<clever> ah wait, wheres libgcc_s ...
<clever> we have only a libgcc here
<lovesegfault> I think this is the root issue
<clever> there is still dynamic musl
<clever> > pkgsMusl.hello
<{^_^}> "<derivation /nix/store/a0xf5c8lr7nc745cnj8l432qwj765g47-hello-2.10.drv>"
<aforemny> Hi, I am trying to cross-compile xorg-server for aarch64. The build fails for me on current Nixpkgs master. I then searched Hydra and found that it built successful three days ago: https://hydra.nixos.org/build/127668628 Is this a aarch64 native build?
<clever> aforemny: yeah, thats a native build
<clever> aforemny: the inputs tab tells you which nixpkgs rev it came from
<lovesegfault> clever: I gotta sleep :(
<lovesegfault> We'll find out if it works tomorrow :P
<clever> lovesegfault: can continue tomorrow
alp has quit [Ping timeout: 272 seconds]
<lovesegfault> Thanks again for all the help :)
<clever> yep
<lovesegfault> it's been an a coding adventure :D
<lovesegfault> gnight!
alp has joined #nixos-aarch64
betaboon has quit [Quit: ZNC - https://znc.in]
Valodim has quit [Quit: ZNC 1.8.0 - https://znc.in]
betaboon has joined #nixos-aarch64
Valodim has joined #nixos-aarch64
<aforemny> clever: Thanks! Are there any information channels that I should know that deal with cross-compiling for aarch64? I am checking Issues on GitHub, but things do not seem to be extremely active there.
<clever> aforemny: this irc channel is the main one i think
<aforemny> I am specifically trying to get my system configuration running on Pinebook Pro, thanks to the amazing samueldr/wip-pinebook-pro. I have read people running some kind of system which I presume includes a working xorg. So I guess they compile things natively.. maybe I should go that route for now as well.
<clever> aforemny: i believe mobile-nixos uses a cross-compiled stage1 (kernel+initrd) but a natively build stage2 (everything in the rootfs)
<clever> aforemny: and can boot to a full desktop env
<aforemny> clever: I guess it makes sense to rent a aarch64 EC2 instance for now and compile the system natively. I think I will try that next. Thanks for the information! :)
<clever> aforemny: you can also use something like an rpi3 or rpi4 as a build system too
<aforemny> clever: Good idea! But I don't have one lying around and I want to use my Pinebook with NixOS ASAP ;-D
noonien has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<srk> I'm wondering why nixos-rebuild --build-host localhost --target-host rpi switch tries to rebuild the whole world when nix-build -A config.system.build.sdImage was done previously. with nixpkgs.crossSystem
<clever> srk: run nix-diff on the 2 drv files, what differs?
<srk> hmm, good idea
<srk> • The platforms do not match
<srk> - x86_64-linux
<srk> + armv7l-linux
<srk> first one is from nix-build, second from nixos-rebuild, weird
<clever> srk: the 2nd one is a native arm->arm build, the 1st is cross
<clever> cross and native cant share products
<srk> I know
<clever> to make nixos-rebuild cross compile, you have to set nixpkgs.crossSystem
<srk> yup, that's set for both builds
<srk> hah
<srk> setting localSystem fixes it
<srk> btw binary ghc8.10.2 works on armv7l
<srk> says
<srk> You are using an unsupported version of LLVM!
<srk> We will try though...
<srk> Currently only 9 is supported. System LLVM version: 10.0.1
<srk> ... which is nice :D
<srk> also unhappy about 'libtinfo.so.6: no version information available' but I've managed to compile xmonad with it
<srk> now I wonder if it can be used to bootstrap itself or one of the older ghcs
alp has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
<clever> lovesegfault: this claims that its doing i2c over gpio 2/3, possibly for the touchscreen, and also the i2c header on the back
<clever> lovesegfault: my gut, says that the rpi firmware cant not-configure 2/3 as vsync/hsync, so they are instead disabled (causing them to just idle high i think), and then something else forces them into i2c mode later
aforemny has quit [Ping timeout: 258 seconds]
evax has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
evax has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
aforemny has joined #nixos-aarch64
aforemny has quit [Read error: Connection reset by peer]
kloenk has quit [Quit: WeeChat 2.9]
juliosueiras has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 258 seconds]
kahiru has quit [Ping timeout: 272 seconds]
kahiru has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
NinjaTrappeur has quit [Quit: WeeChat 2.8]
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
cole-h has joined #nixos-aarch64
juliosueiras has joined #nixos-aarch64
<lovesegfault> clever: Oh, interesting!
<clever> lovesegfault: if you enable arm i2c (check the config.txt docs), and then setup the overlay right in uboot as well (since it undoes the enable), then edit the rust code to put gpio 2/3 into alt0 mode, you might see the touch controller with i2cdetect -y
<lovesegfault> Nice, I'll try that today
<lovesegfault> just kicked off the musl build
<lovesegfault> before I go get my haircut, maybe it'll be done when I'm back :D
superherointj has joined #nixos-aarch64
aforemny has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
bennofs_ has joined #nixos-aarch64
bennofs has quit [Ping timeout: 240 seconds]
aforemny has quit [Ping timeout: 272 seconds]
aforemny has joined #nixos-aarch64
alp has joined #nixos-aarch64
taktoa[c] has quit [Ping timeout: 244 seconds]
elvishjerricco has quit [Ping timeout: 244 seconds]
blackriversoftwa has quit [Ping timeout: 244 seconds]
NekomimiScience has quit [Ping timeout: 260 seconds]
cstrahan has quit [Ping timeout: 244 seconds]
chessai has quit [Ping timeout: 240 seconds]
chessai has joined #nixos-aarch64
angerman has quit [Ping timeout: 260 seconds]
cstrahan has joined #nixos-aarch64
elvishjerricco has joined #nixos-aarch64
angerman has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
blackriversoftwa has joined #nixos-aarch64
taktoa[c] has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lafa has quit [Remote host closed the connection]
jackdk has quit [Ping timeout: 260 seconds]
jackdk has joined #nixos-aarch64
blackriversoftwa has quit [Ping timeout: 258 seconds]
blackriversoftwa has joined #nixos-aarch64
<lovesegfault> clever: coreutils fails to build :(
Acou_Bass has quit [Ping timeout: 240 seconds]
Acou_Bass has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
feepo has quit [Ping timeout: 244 seconds]
prusnak has quit [Ping timeout: 244 seconds]
davidtwco has quit [Ping timeout: 244 seconds]
c00w has quit [Ping timeout: 240 seconds]
NekomimiScience has quit [Ping timeout: 240 seconds]
chessai has quit [Ping timeout: 240 seconds]
alunduil has quit [Ping timeout: 240 seconds]
TheNumb has quit [Ping timeout: 260 seconds]
cstrahan has quit [Ping timeout: 260 seconds]
angerman has quit [Ping timeout: 260 seconds]
jackdk has quit [Ping timeout: 272 seconds]
elvishjerricco has quit [Ping timeout: 272 seconds]
noonien has quit [Ping timeout: 272 seconds]
c00w has joined #nixos-aarch64
prusnak has joined #nixos-aarch64
angerman has joined #nixos-aarch64
blackriversoftwa has quit [Ping timeout: 272 seconds]
blackriversoftwa has joined #nixos-aarch64
TheNumb has joined #nixos-aarch64
noonien has joined #nixos-aarch64
feepo has joined #nixos-aarch64
chessai has joined #nixos-aarch64
cstrahan has joined #nixos-aarch64
elvishjerricco has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
davidtwco has joined #nixos-aarch64
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
Thra11 has quit [Quit: WeeChat 2.9]
mla has joined #nixos-aarch64