{`-`} has joined #nixos-aarch64
disasm has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 268 seconds]
gerschtli has quit [Quit: WeeChat 2.0]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
disasm has joined #nixos-aarch64
orivej has joined #nixos-aarch64
duncan^ has quit [Ping timeout: 276 seconds]
Sonarpulse has joined #nixos-aarch64
disasm has quit [Ping timeout: 240 seconds]
disasm has joined #nixos-aarch64
duncan^ has joined #nixos-aarch64
Sonarpulse has quit [Ping timeout: 244 seconds]
Sonarpulse has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
srk has joined #nixos-aarch64
<srk> o/
<clever> srk: i took the top half of the case off, and laid the naked pi ontop of a desk fan, and it can now boot once more
<srk> how is that even possible :)
<clever> srk: at one point, it crashed in linux, which booted kgdb, and it showed an overheat from the GPU overlay
<clever> "2018-07-10 18:35:49 bedroom temp: 27.44c(81.39f), kitchen: 26.38c(79.47f), living room: 26.56c(79.81f), outdoor: 21.25c(70.25f), server: 29.75c(85.55f) VCC: over 4.5 volts portb: 00000000"
<clever> srk: and it is about 85f where i was previously keeping the rpi
<srk> not that high, I'm running one lorawan gateway with pi3 on top of the roof where sun is shining on the box constantly
<srk> didn't notice any problems due to temperature
<srk> need to record that tho
<clever> srk: it was also sitting ontop of a cisco switch that lacked any of its original fans
<srk> ah, yeah, that might explain it
<srk> still wondering about that device tree overlay
<clever> 23 cp -r ${./../../overlays} overlays
<clever> 22 cp ${./../bcm2710-rpi-3-b.dtb} bcm2710-rpi-3-b.dtb
<clever> srk: both are just naked files i copied from *somewhere*
<clever> i was naughty :P
<clever> now for the fun task of trying to reproduce what i did 2 years ago
<srk> you can get these from uboot or kernel
<srk> I think they are the same in both repos
<srk> but to make a proper image which can nixos-rebuild switch requires patching kernel
<clever> there are also utils to convert between binary and text
<srk> for just single dtc run :)
<clever> and you could make a custom derivation to just run those utils to make your own dtb's
<srk> so I'm thinking about creating a derivation that would just build dtbs from uboot or kernel
<srk> ^^
<srk> would be nice to be able to say which dtb to use, provide and so
<clever> dtoverlay=pi3-disable-bt
<clever> srk: this entry in config.txt tells it to load an overlay
<clever> Jul 10 21:30:04 router tftpd[31324]: tftpd: trying to get file: 9080d9b6/overlays/pi3-disable-bt.dtbo
<clever> srk: which is in the overlays directory of the "boot partition"
<srk> right but that's custom stuff done by rpi firmware, right?
<srk> afaik there's no support for overlays in uboot nor kernel
<clever> i believe you can just make your own overlays with any name you want
<clever> and the firmware will apply the overlays before passing the dtb to the kernel
<srk> I see
<srk> but that again only works for rpi :)
<clever> yeah
<clever> for other systems, you may need to use the CLI tools to merge things yourself, before setting up /boot/
<srk> I'm all for standard way to do things (mainline linux + uboot) if possible, although quite painful at times
<clever> linux can also load overlays at runtime
<srk> managed to hit some fun issues - GPS connected to uart stopping uboot, then stopping extlinux.. :D
<Dezgeg> someone could write a nixos module for applying the overlays, I guess
<srk> hmm
<srk> interesting
<clever> Dezgeg: dynamicaly loading them at runtime works in a stack based system
<clever> Dezgeg: so you can only unload them in the reverse order they had been loaded
<Dezgeg> I mean you could compile the final .dtb from the base .dtb + overlays at system build time
<clever> yeah, thats still an option
<Dezgeg> but yeah, maybe this dynamic dtbo stuff works, haven't tried that myself
<srk> also recent kernel on pi3 exposes two gpiochips (one for the expander) and my tool that I wrote few years ago when struggling with this didn't pick the right one .. https://github.com/sorki/ail_gpio/
<srk> Dezgeg: thanks for the armv7 and aarch64 images btw, managed to run them on bunch of boards now, my hydra is now crunching armv7l as well
<Dezgeg> I think nowadays there is some userspace tool to use the gpio ioctl interfaces
<srk> probably, mine is pure bash, from times we've managed to build first armv6 fedora images and there was no way to compile stuff on it :D
<clever> the rpi also has its own tools, that list off the pins, ordered by how they are laid out on the header
<srk> they just make it more confusing :)
<srk> with most of their added cruft sadly
<srk> Since linux 4.8 the GPIO sysfs interface is deprecated. oO :D
<srk> that's new
<clever> 2018-04-28 22:41:18<@clever> bash-4.4# iscsiadm -m discovery -t sendtargets -p 192.168.2.61
<clever> 2018-04-28 22:41:22<@clever> bash-4.4# iscsiadm -m node -T iqn.2015-10.com.c2d-swap1 -p 192.168.2.61 -l
<clever> srk: some notes i left myself, on how to enable swap on my not-os image
<srk> :D
<srk> I'm taking notes of our conversations .. :D
<Dezgeg> swap on iscsi? hope you don't deadlock
<clever> that creates a /dev/sda, which maps to a file on the c2d machine
<clever> [ 1670.526918] Out of memory: Kill process 6563 (cc1) score 38 or sacrifice child
<clever> Dezgeg: its better then this :P
<clever> Dezgeg: and swap on iscsi is far more stable then swap on a zvol
duncan^ has quit [Ping timeout: 268 seconds]
duncan^ has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
duncan^ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
duncan^ has joined #nixos-aarch64