<samueldr>
(I haven't rewrote it since the time I was learning about Nix)
<samueldr>
anyway, the point was that having such a system on Archlinux was painful, because of having to keep track of kernel updates
<samueldr>
now it just happens
<Cadey>
and you can make it a bootable ISO!
<samueldr>
I can make it part of my Mobile NixOS system!
<Cadey>
how long does it take for you to spin up new systems? it's about 20 minutes for me now
<samueldr>
to install NixOS on a new computer?
<Cadey>
and get it assimilated into your hivemind yeah
<samueldr>
I don't really know since I don't re-install and haven't had a new machine for a while :)
<samueldr>
though I would assume ~10-20 minutes to get things in order, then whatever time it takes to build/download
cole-h has quit [Ping timeout: 256 seconds]
<samueldr>
oh, completely forgot that I had made a POC fuse FS that merges the different /usr/share/applications folders, and mounted it a /Applications
<Cadey>
lol
<DigitalKiwi>
yeah i was wondering about that it should have more dirs
<samueldr>
it's not meant to be a direct copy of macOS, but only the good bits
<samueldr>
well, "good"
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.9]
<colemickens>
I have 5.4 on RPi4, with uboot 2020.10, usb works (as expected). I'm going to try out mainline once 5.10-rc1 is tagged.
<samueldr>
usb works as expected?
<samueldr>
because lovesegfault said it didn't IIRC
<colemickens>
your PR that switches to u-boot doesn't bump u-boot to latest.
<colemickens>
I assume lovesegfault didn't also bump u-boot when they tested.
<colemickens>
u-boot 2020.10 release notes specifically mention fixing up something related to rpi4+usb
<samueldr>
it was latest at that point i time
<samueldr>
in*
<samueldr>
now I see the difference
<samueldr>
is 2020.10 released?
<samueldr>
:/ speaking of u-boot
<samueldr>
not sure if it's in 2020.07 already, the merge commit is confusing me
<samueldr>
but there seems to be a usability regression
<{^_^}>
#82455 (by ertw, 30 weeks ago, open): Raspberry Pi 3 B+ doesn't boot on kernel 5.4.23
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<Mic92>
mhm. In my case it seems to be a combination of this hdmi issue combined with the RPI3 not booting when I have a USB harddrive connected to it.
Darkmatter66_ has quit [Ping timeout: 258 seconds]
CyberManifest has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
CyberManifest has quit [Remote host closed the connection]
<samueldr>
Mic92: it recommends _rpi for raspberry pi 1; the default expectation is to use mainline linux on raspberry pi 3 family
<samueldr>
(though this section is woefully out of date and over-generic in a land of non-generic boards :|)
rajivr has quit [Quit: Connection closed for inactivity]
justanotheruser has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
CyberManifest has joined #nixos-aarch64
<betaboon>
srk: is there any news on the device-tree overlay loading for especially for the pi4 ? :D
<betaboon>
got some time on my hand to play around with the vc4 loading today
cole-h has joined #nixos-aarch64
<Mic92>
The latest kernel does not boot at all on rpi3. Current lts is fine
<samueldr>
fun!
<samueldr>
though yeah, those instructions are quite old, they probably were written when mainline support for pi3 was not in the current LTS
<samueldr>
in the then now current LTS*
<betaboon>
samueldr: do you know if the device-tree-overlays should end up in NIXOS_BOOT ?
<samueldr>
I don't know
<samueldr>
I would assume that if the goal is to pre-apply them to the FDTs they won't
<betaboon>
i have the feeling that, since the whole `hardware.deviceTree.overlays` is somewhat defunct in this particular case it wont be pre-applied.
cole-h has quit [Quit: Goodbye]
<betaboon>
according to `dtc -I fs /proc/device-tree` the v3dbus ends up in `status = "disabled"`
<samueldr>
for the raspberry pi, especially, there can be device tree nodes that end up being setup by the firmware
<samueldr>
so it's possible that the overlay is only part of the solution
CyberManifest has quit [Remote host closed the connection]
cole-h has joined #nixos-aarch64
cole-h has quit [Client Quit]
<kyren>
what is the current status with hardware.deviceTree.overlays, that it works with the vanilla kernel and not the rpi fork kernel?
<kyren>
(for the rpi I mean)
<kyren>
I really tried to understand how it all worked but I ended up making a replacement that loads overlays later in boot at runtime via the /proc filesystem, but I really don't know what I'm doing that was just the only way I could get anything to work with the fork kernel (that or config.txt and placing overlays in the boot filesystem)
<betaboon>
kyren: i dont completly recall. sine way i run in FDT_NOT_FOUND error, another (providing the dts) it fails to compile the overlay because it includes `#include`. something along those lines. i think srk is more knowledgeable about that
<samueldr>
I don't know about that option really
<samueldr>
but one factor to remember is that the foundation's kernels has a different labels naming scheme than the mainline kernel
<samueldr>
so already references will not be the same
cole-h has joined #nixos-aarch64
<kyren>
betaboon: I dunno if you're running into the same issues that I had, but this is how I got it to work with the foundation kernel: https://bepasty.kyju.org/iADcvc9P/+inline?
<kyren>
I feel like that approach is probably very wrong somehow, but it works for making the hifiberry cards work 🤷♀️
<betaboon>
kyren: thanks. that looks like it tries to address the issue i am running into.
<kyren>
I just gave up on doing it at compile time (what hardware.deviceTree.overlays is trying to do?) or firmware boot time, and just do it early on at runtime
<kyren>
oh sorry not via /proc, via /sys
<clever>
kyren: last i looked into it, the hifiberry is a "proper hat" and includes a hat eeprom, so the firmware can apply overlays for you automatically
<kyren>
(those comments might be wrong too it might not work for lots of things)
<clever>
kyren: u-boot undoes all of that magic by default
<kyren>
clever: for SOME of them it works, for some of them the eeprom is too old and there's maybe a name mismatch or something, I dunno I haven't hooked it up to read the logs coming out of the uart yet
<betaboon>
(on a side-note: I'm not currently booting using u-boot)
<kyren>
for the one you helped me with, it's true it works via the eeprom, but I have two of them
<kyren>
the DAC+ADC board it doesn't for whatever reason
<clever>
kyren: the overlay on the eeprom assumes the foundation naming
<clever>
kyren: upstream linux uses different names in the .dtb file, breaking things
<clever>
kyren: so you want the foundation .dtb files, the kernel itself likely doesnt matter
<kyren>
betaboon: I am also not using u-boot, because I can't get the foundation kernel to boot using it (or at least I couldn't before, I haven't tried recently)
<kyren>
clever: I'm using the foundation kernel
<kyren>
there's a post in hifiberry about how the eeprom for some of their cards is wrong and how they require you to edit config.txt to load the overlay, which DOES work if the overlay is on the /boot partition
<kyren>
but there's no way to cleanly get the overlays onto the /boot partition from nix, so I made that thing I linked which does it at runtime and works okay
<kyren>
(I'm probably using imprecise language, by "the overlay" I mean the .dtbo file)
<kyren>
clever: I know you explained all this to me before and I've probably forgotten all of it, but for this specific case loading it at runtime works, there's maybe a better way to have achieved it but I only got the card to work by either 1) dtoverlay=xxx in config.txt + put the dtbo file in /boot OR 2) via /sys at runtime, and the first one is really hard to get nix to do because of the way the /boot directory is populated
<kyren>
in that script that populates it
<kyren>
but this was with an rpi4 and the dac+adc card and the foundation kernel, the one you helped me with was a rpi3+ and a different card, I'm making a bunch of these things to replace sonos hehe
<kyren>
The comment in https://bepasty.kyju.org/iADcvc9P/+inline? is probably wrong too, I don't know if dtoverlay=xxx would work with uboot also, maybe it would, I just wrote down my shakey understanding at the time, feel free to correct it
<kyren>
but I'm not having an issue I was just trying to provide a possible solution for betaboon, maybe I'm not the best person to try to give advice though haha
<betaboon>
kyren: I'll fiddle around here some more. when i get impatient i will give your approach a try. basically i am stuck on a project of mine for two weeks due to this, and at this point i would be happy with _a_ solution that unstucks me for the time being :D
<betaboon>
tho obviously i would prefer a proper and generic solution that we could integrate into nixos to solve it once and for all :D
<kyren>
betaboon: you can try it manually to see if it works first, by making that directory in /sys and catting the dtbo file, if that works then that's all this nix module is doing
<betaboon>
kyren: will do. thanks :D
<srk>
I haven't added back the old way of applying overlays yet, but soon. you can try reverting 6c9df40a4bc819fcab0836ad28ee944c8ce66db0 to get the old behavior back