tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 260 seconds]
tilpner_ is now known as tilpner
rajivr has joined #nixos-aarch64
lafka has joined #nixos-aarch64
lafa has quit [Ping timeout: 272 seconds]
<
lovesegfault>
samueldr: When packaging the driver, where does `dtc` come from?
<
lovesegfault>
Or should I not be calling this by hand, and the package should just provide the dtc file
<
lovesegfault>
s/dtc/dts/
<
samueldr>
I'm not sure
* lovesegfault
tries
<
samueldr>
I don't know how that bit of NixOS works yet
<
samueldr>
you might need to compiled the dtbo first
<
lovesegfault>
Yeah, I'm trying that
<
samueldr>
and well, `dtc` provides `dtc`
zupo has joined #nixos-aarch64
<
lovesegfault>
samueldr: alright, I got the dtbo applied
<
lovesegfault>
time to tackle that init thingy
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
<
lovesegfault>
Think I got it, tackling the service
<
lovesegfault>
done
<
lovesegfault>
cross fingers
jumper149 has quit [Quit: WeeChat 2.9]
jumper149 has joined #nixos-aarch64
<
lovesegfault>
samueldr: eh, where does the python RPi bindings live in Nix?
<
samueldr>
I don't know :)
* lovesegfault
goes spelunking
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
<
lovesegfault>
not packaged, it seems
* lovesegfault
dives in
<
clever>
i tried packing a c and haskell library for it, only to discover it was missing like 90% of the features i needed
<
clever>
so i just wrote my own in pure haskell :P
<
samueldr>
I'm annoyed!
<
samueldr>
this device has the kernel running
<
samueldr>
but I don't know what's keeping anything from happening
jumper149 has quit [Client Quit]
<
samueldr>
and for some reason it seems that piping to /dev/kmsg doesn't work on that device
jumper149 has joined #nixos-aarch64
<
clever>
samueldr: any dmesg at all?
<
samueldr>
only from console-ramoops, and not all the time
<
clever>
does it say init is exiting?
<
samueldr>
when it doesn't hang yes
<
samueldr>
but when it hangs I figure it's actually init "hanging"
<
clever>
i had something similar, with no ability to debug
<
samueldr>
most likely waiting for something
<
clever>
because i didnt enable the FPU
<
clever>
and the very first thing printf does is touch the FPU
<
clever>
so anything passing thru printf was fatal
<
samueldr>
the config is heavily based off of the OEM's
jumper149 has quit [Client Quit]
<
clever>
i had to build a c program that used raw write() and open() for armv6, to get any debug at all
jumper149 has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 272 seconds]
jumper149 has quit [Client Quit]
juliosueiras has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
justanotheruser has quit [Ping timeout: 244 seconds]
knerten1 has joined #nixos-aarch64
knerten2 has quit [Ping timeout: 246 seconds]
<
samueldr>
aaand now what once booted doesn't :/
<
samueldr>
yeah, that one's a hard black box to figure things out from
justanotheruser has joined #nixos-aarch64
lafka has quit [Remote host closed the connection]
<
lovesegfault>
Hm, the display is powering on at least
<
lovesegfault>
alas no image
<
lovesegfault>
derp, forgot the config lines
<
samueldr>
you had three jobs to do
<
lovesegfault>
deploying
<
lovesegfault>
Trying....
<
lovesegfault>
it flashed, maybe that's a good sign? :P
<
lovesegfault>
alas nothing on the screen
<
lovesegfault>
Hm, the dtbo isn't in /boot
<
lovesegfault>
Yeah, I don't get how the new deviceTree works
<
samueldr>
it should be pre-bundling the device tree overlays on top of the base FDT
<
samueldr>
but I don't know whether the one in config.txt will be the right one
s1ng0c has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 272 seconds]
cole-h has joined #nixos-aarch64
CyberManifest has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
<
clever>
samueldr: square and widescreen variants available
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
zupo_ has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
zupo has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 265 seconds]
s1ng0c has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 260 seconds]
juliosueiras has joined #nixos-aarch64
codyopel has quit [Quit: Idle for 30+ days]
juliosueiras has quit [Ping timeout: 256 seconds]
CyberManifest has quit [Quit: Leaving...]
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 272 seconds]
lafa has joined #nixos-aarch64
zupo has joined #nixos-aarch64
goibhniu has quit [Quit: Idle for 30+ days]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<
samueldr>
clever: cool
<
samueldr>
but I'm not really interested in that :)
rajivr has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
bennofs has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]
lafa has quit [Remote host closed the connection]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
<
lovesegfault>
I'm going to try stuffing the dtbo in /boot manually and seeing if that works
<
lovesegfault>
nope, hmm
<
lovesegfault>
Something funky is going on here
juliosueiras has joined #nixos-aarch64
<
samueldr>
one option is to use dtc to uh... do something with /proc/device-tree...
<
samueldr>
IIRC you can transform that back into a .dts so you could look whether things are present as expected
<
lovesegfault>
Right, the `hardware.deviceTree.overlays` seems to accept dts
_and_ dtbo files
<
samueldr>
at least checking first whether the running system is using what you expect will close down some avenues
<
lovesegfault>
How do I do that?
<
samueldr>
if you see the stuff from the .dts you are applying as an overlay, then that part is working fine
<
samueldr>
I don't know off the top of my head
<
samueldr>
dtc /proc/device-tree
<
samueldr>
well, you want to redirect that somewhere
<
lovesegfault>
right, my grep for "hyper" yields nothing
<
lovesegfault>
so I'd expect that the dtbo isn't even getting loaded to begin with
<
samueldr>
so first, is the FDT (.dtb) that those options build used in the config.txt?
<
samueldr>
because it might be built, but end up not being used
<
lovesegfault>
Well, I added it
<
lovesegfault>
That's my /boot/config.txt
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Read error: Connection reset by peer]
evalexpr_ has joined #nixos-aarch64
evalexpr_ has quit [Client Quit]
evalexpr_ has joined #nixos-aarch64
evalexpr has quit [Quit: Bye]
evalexpr_ is now known as evalexpr
<
lovesegfault>
got it working!
<
samueldr>
lovesegfault: do you know what you did to get it working?
<
samueldr>
(I mean, sometimes you could be doing 10 things at the same time and not be sure)
<
lovesegfault>
Yeah
<
lovesegfault>
flokli taught me how to load the dtbo by hand, so that helped
<
lovesegfault>
I then got it to segfault, which was due to the dts file being borked
<
lovesegfault>
loaded those dtbo's by hand
<
lovesegfault>
and barabim-barabom
evalexpr has joined #nixos-aarch64
<
lovesegfault>
so, loading manually works
<
lovesegfault>
however:
<
lovesegfault>
1. it doesn't load on boot
<
lovesegfault>
2. placing the dtbo in /boot also doesn't load by default
<
lovesegfault>
so I think we're back to "how does hardware.deviceTree" works :D
<
lovesegfault>
6c9df40a4bc819fcab0836ad28ee944c8ce66db0
<
lovesegfault>
I think this is the commit that changed the behavior
<
lovesegfault>
so base -> kernelPackage
<
{^_^}>
#79370 (by sorki, 32 weeks ago, merged): Improve device-tree overlay support
* lovesegfault
reads through it
<
lovesegfault>
interesting, looking at the output of the device-tree-overlays there are
_no_ dtbo files there at all
<
lovesegfault>
I really must be doing something weird
<
samueldr>
if it works like I think, it should overlay the given overlays into the output FDT
<
lovesegfault>
I would expect to be seeing something in the build log at least
<
lovesegfault>
because it should be applying this to brcm and/or bcm2835
<
lovesegfault>
let me try an invalid overlay
<
lovesegfault>
well, it failed so that's reassuring
<
lovesegfault>
I think the `dtoverlay=` line in config.txt is not doing anything
<
clever>
lovesegfault: does the overlay exist in /boot/overlays/ ?
<
lovesegfault>
nyet
<
lovesegfault>
moved it there, rebooting
<
lovesegfault>
it works :D
<
lovesegfault>
so applying by hand like this works
<
lovesegfault>
but not using hardware.deviceTree alone
<
samueldr>
clever: using /boot/overlays/ is not declarative though :/
<
clever>
samueldr: it is if nixos is updating the dtoverlay='s in config.txt
<
clever>
and copying the overlays in
<
clever>
but you wont have rollbacks
<
clever>
some overlays also have side-effects at boot time, outside of the arm
<
clever>
and wont function right if you apply them yourself
<
samueldr>
clever: we have
*another* method to create an FDT with the overlays pre-applied
<
samueldr>
that's what that was about at first
<
samueldr>
and using config.txt and /boot/overlays is a bad idea
<
samueldr>
since once u-boot support is merged, it won't work (on images made with u-boot)
<
lovesegfault>
Right, I agree it's not a shippable solution
<
samueldr>
we should stop recommending using vendor-specific ways to fix things
<
samueldr>
otherwise we may as well tell them to get a macbook and install windows on it
<
samueldr>
(overexagerating much)
<
samueldr>
but yeah, recomending the vendor-specifics methods is not good
<
lovesegfault>
eh, can someone remind me what the right way to do `someNixOSOption.foo = previousValue ++ [newThing]`
<
samueldr>
it only matters if you're "overriding" an option, like let's say mkForce
<
samueldr>
otherwise, depending on the option type, generally it'll merge automatically
* lovesegfault
tries
<
lovesegfault>
Sweet, that worked
<
samueldr>
so what was it?
<
lovesegfault>
Oh, no, the "just set it and it will append worked"
<
lovesegfault>
`hardware.deviceTree` is still borked
<
{^_^}>
#79370 (by sorki, 32 weeks ago, merged): Improve device-tree overlay support
<
lovesegfault>
hopefully sorki shows up and explains how this stuff works
<
lovesegfault>
I know this stuff
_used_ to work, so I'm confident that PR broke it