<samueldr> though I guess I'll first try "just" updating to latest nixos-unstable, getting it working, making a system closure to start from
bennofs__ has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 268 seconds]
cole-h has quit [Ping timeout: 265 seconds]
rajivr has joined #nixos-aarch64
orivej has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 250 seconds]
h0m1 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 240 seconds]
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 250 seconds]
apache8080 has joined #nixos-aarch64
<dxb[m]> domenkozar after booting to the image i'm seeing errors about the bluetooth hardware… tried ignoring them because i did get a shell, but then it fails to initialize the wifi driver interface when setting up wifi
apache8080 has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
justan0theruser has quit [Ping timeout: 250 seconds]
apache8080 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 252 seconds]
justanotheruser has quit [Ping timeout: 260 seconds]
cole-h has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 265 seconds]
apache8080 has joined #nixos-aarch64
cole-h has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 252 seconds]
nicoo has quit [Remote host closed the connection]
nicoo has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 252 seconds]
sphalerite has quit [Quit: WeeChat 2.9]
sphalerite has joined #nixos-aarch64
<domenkozar[m]> dxb what's the output of ifconfig?
<domenkozar[m]> and also if you can paste dmesg output somewhere
bpye has quit [Ping timeout: 268 seconds]
bpye has joined #nixos-aarch64
mvnetbiz_ has joined #nixos-aarch64
mvnetbiz_ has quit [Changing host]
orivej has joined #nixos-aarch64
<dxb[m]> domenkozar i've unhooked everything now. my pis are normally headless and not easy to get to so i'll have to see if i can make more time today/tonight to troubleshoot. i also don't have an easy way to hook this thing up via ethernet so getting text output somewhere isn't going to be easy without wifi going. i did run `ip a` while it was in this state and can confirm the wireless nic is there and is indeed called
<dxb[m]> `wlan0`. is there something specific i should be looking for in ifconfig or dmesg? if i can get back to it tonight i'll try looking over dmesg and see if i can find something interesting in there.
dev_mohe has joined #nixos-aarch64
<domenkozar[m]> dxb: cool thanks. Note that if you make a typo when running wpa_supplicant you have to kill it first so it releases access to the interface before you reconfigure it again.
<domenkozar[m]> That's all I can think of right now without going into details of what's the state on your rpi
dev_mohe has quit [Client Quit]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
HenrikK has joined #nixos-aarch64
<dxb[m]> domenkozar i even re-downloaded and wrote the sd card and tried again to be sure
<domenkozar[m]> With same result?
<domenkozar[m]> dxb oh, you have to run it as root!
<domenkozar[m]> sudo -i
HenrikK has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
HenrikK has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 265 seconds]
<dxb[m]> domenkozar: ah, i feel silly for not trying that lol
<dxb[m]> i'll try to find some time to try again and will report back
<domenkozar[m]> no problem, that's part of the tutorial to make sure common mistakes are accounted for
<domenkozar[m]> I've revised the wording and moved the sudo -i bit to a better place
<domenkozar[m]> thanks @dxb, much appreciated!
<dxb[m]> i see it now... where was it before?
<domenkozar[m]> it was at the end of the booting image section
<dxb[m]> oh ok
<dxb[m]> i'll try to read more thoroughly next time lol
<domenkozar[m]> if linux was built using capabilities, then it could just warn it needs one to access wifi
<domenkozar[m]> but let's not daydream :)
<dxb[m]> i have some 3b or 3b+ models too (not sure which?)... i see it says this can be done with those too, but with tweaks. do you want me to try that too?
<domenkozar[m]> yeah once we confirm that it works at least for 4, it would be great to try 3b(+)
<dxb[m]> one thing that i think would be nice is some more information on how you got that hydra url for the image in case i want to go find some other image on there. maybe in case this document is outdated or if i wanted to try to grab an older image or something
zupo has joined #nixos-aarch64
<domenkozar[m]> hmm, I like to keep tutorial focused on the goal and not give too much choice
<domenkozar[m]> that's the opposite of the common tendency, but that makes them effective and testable :)
<domenkozar[m]> I could start adding something like notes for such things, but I'm not sure that's really needed here, as the image should just make things work (or be updated for the tutorial itself)
<dxb[m]> that makes sense, but it'd be nice to know why we're using that particular image, and like i said, if something were ever wrong with that link, i'd really have no idea where to go to find out where the latest is
<domenkozar[m]> I hear you, let me try writing that up
HenrikK has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
HenrikK has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
HenrikK has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
zupo has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vikanezrimaya has quit [Quit: Connection closed]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
<samueldr> domenkozar[m]: I'll be trying your instructions as-they-are, now, and will check for fbdev at the same time
rajivr has quit [Quit: Connection closed for inactivity]
HenrikK has joined #nixos-aarch64
<domenkozar[m]> Wohoooo :) Thanks
zupo has joined #nixos-aarch64
<samueldr> it's small things (literally) like the micro HDMI connectors that makes it such a chore to test on the Pi 4
<clever> half the micro-hdmi adapters i have, are rather bulky, and i cant use 2 at once
<clever> but i recently got a micro to full cable, so the micro end is small enough to run dual-monitor
<samueldr> yeah
<samueldr> or worse
<samueldr> bulky enough that you can't connect to HDMI0 while having power in type-c
<samueldr> HDMI0 may or may have been required at some point
<clever> thats the old advice, but ive found both work now
<samueldr> I uh... can't test wi-fi
<samueldr> because my network name is not something I can type
<samueldr> ┻━┻ミ＼(≧ﾛ≦＼)
<samueldr> might be worth it, in the future, to include network-manager in the image instead, so a TUI can be used to select the network
<domenkozar[m]> :D
<domenkozar[m]> or name the SSID to be rpi inclusive :D
<samueldr> it's not a raspberry pi issue!
<samueldr> it's wpa_supplicant assuming ASCII for an SSID
<samueldr> while the spec **clearly** states it's just bytes :)
<samueldr> so any unicode, ascii, CP-whatever or ISO-whatever interpretations are... just that, interpretations
<samueldr> but those instructions look fine enough, and I verified Wi-Fi *should* work by listing networks
<samueldr> so even though it's technically untested, I have strong reasons to believe it works
<dxb[m]> i used to set my ssid to something like `\x73\x73\x64\x69` ...... i had it like that for years but ultimately changed it because there were just too many times when i would specify the ssid in some command and it would interpret the hex bytes and it was too much of a pain in the ass to figure out whether it needed to be escaped, and if so, what was the appropriate way to escape it in whatever i'm currently having
<dxb[m]> trouble with
<clever> echo 'WIFI:S:name;T:WPA;P:password;;' | qrencode -o wifi-test.png
<clever> dxb[m]: this lets you encode a wifi name/pw into a qrcode
<clever> if you scan it with android, it will just work
<clever> ive not tested it against non-ascii yet though....
HenrikK has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
<dxb[m]> noice
<samueldr> hah, hardware.deviceTree should probably almost always be paired with an appropriate `filter`
<samueldr> e.g. "bcm2711-rpi-*.dtb"
<samueldr> otherwise it's appplying the overlay to all dtb files in the directory, and failing when it can't apply
apache8080 has joined #nixos-aarch64
<domenkozar[m]> samueldr: is that what's missing for GPU support?
<samueldr> possibly
<samueldr> I had it working on an older Nixpkgs checkout
<samueldr> right now I'm looking into it
<samueldr> hmm! looks like it's not being applied correctly
<clever> domenkozar[m]: i am familiar with the gpu on the rpi, and the how the various drivers normally work on raspi-os
<samueldr> clever: if it helps, it's with the linux_rpi4 kernel
<samueldr> comparing the .dtb file, and the /proc/device-tree FDT tells me it's using the right dtb
<samueldr> but the dtb didn't end up having the overlay changes AFAICT
<samueldr> e.g. / { fb {}} is status okay still
<samueldr> conversely, other nodes that should be enabled by that overlay aren't
<clever> try decompiling the dtb in /boot and confirm the overlay is applied there?
<clever> since nixos pre-applies them at build time
<samueldr> >> comparing the .dtb file, and the /proc/device-tree FDT tells me it's using the right dtb
<samueldr> the .dtb file is the one in /boot :)
<samueldr> so what is booted agrees with what should be booted
<samueldr> the issue seems to have been at applying the overlay AFAICT
<clever> root@pi400:~# dtc /proc/device-tree | less
<samueldr> I've used dtc --sort on both
<samueldr> (helps with vimdiff)
<clever> for me, fb/status == disabled, hvs/status == disabled, and firmwarekms/status == okay
<clever> vc4.ko is loaded, and dmesg said [ 4.576768] vc4-drm gpu: bound fe600000.firmwarekms (ops vc4_fkms_ops [vc4])
<samueldr> yeah, but you've not booted NixOS through U-Boot I suspect
<clever> yeah, plain raspi-os
<clever> but now you have several checkpoints you can compare against
<clever> which of the above is true with nixos? which are missing?
<samueldr> right, thanks, but that was already what I had in mind :)
<samueldr> inverted statuses
<samueldr> (I just had the laptop again casually going to suspend because it's still sat on another laptop...<)
<samueldr> OH, this explains the unexplainable intermittent issues the other day!
<domenkozar[m]> samueldr besides the GPU support missing, the tutorial works?
<samueldr> oh, yeah, I was in XFCE
<samueldr> didn't check audio, it might require a device tree overlay to be applied too
apache8080 has quit [Ping timeout: 240 seconds]
<samueldr> haha!
<samueldr> cat /proc/device-tree/compatible | xargs -0n1 echo # raspberrypi,4-model-b brcm,bcm2711
<samueldr> it's "not compatible"!
apache8080 has joined #nixos-aarch64
<clever> samueldr: aha, that could explain why its not applying
<samueldr> exactly
<samueldr> the log also seems to agree
<samueldr> since there is no Applying overlay ... to ...
<clever> one sec
<samueldr> it's also somewhat wrong considering `compatible` can have multiple values
<samueldr> we're only comparing one of them
<clever> yeah, i think thats the right overlay
<samueldr> it is
<clever> i was thinking of a diff one
<clever> vc4-kms-v3d-overlay.dts vs vc4-kms-v3d-pi4-overlay.dts
<clever> when you cross into pi4, there are 2 different overlays for the same feature
<samueldr> >> compatible = "brcm,bcm2835";
<samueldr> it still wouldn't apply
<clever> the firmware aliases them into a single cfg
* samueldr tries from the source
<samueldr> >> Applying overlay wip-cma to bcm2711-rpi-4-b.dtb
<samueldr> somewhat success
<samueldr> it ends up with FDT_ERR_NOTFOUND... but that's progress
<samueldr> *rebooting*
<samueldr> so that's it, it's the "compatible" check
<clever> is there any anti-aliasing on that font? it feels a tad soft
<samueldr> (oh, interesting, the cheap capture card acts as if it was a 32" TV)
<samueldr> nah, bad capture card
<clever> ahh
<samueldr> "that" cheap usb capture card
<samueldr> it somewhat mitigates the annoyances of dealing with SBCs
<samueldr> I end up using both pinebooks (rk3399, A64) more than any other ARM targets simply because... they have a display and keyboard built-in
<samueldr> oof, not sure what the best strategy to use
<samueldr> clever: in the vendor ecosyste, fkms-v3d is good to use still, right?
<clever> yeah, fkms is recommended
<clever> real kms is still buggy
<samueldr> good, so that will be what we'll recommend
<samueldr> there might be another small issue
<clever> i also recently discovered, the firmware opengl is recommended for older models, like the pi0/pi1
<clever> because of cma issues
<samueldr> I would hazard a guess that it needs another overlay applied beforehand
<clever> firmware GL uses the gpu_mem partition, which can defrag, and co-exist with other firmware resources
<clever> the proper linux gl drivers, use cma, which defaults to nearly half your ram
<clever> and cant co-exist with a lot of other things
<samueldr> or, more probably, the firmware sets something up that is not in the dtb
<clever> so you wind up partitioning the ram into 3 chunks
<samueldr> "defaults to nearly half your ram" *citation needed*
* clever gets link
<samueldr> because cma "defaults" are everything but defaults :)
<samueldr> in most situations
<clever> > You'll also have memory issues with only 512MB of RAM as it will assign 256MB to the CMA heap (all textures and resources to be displayed must be contiguous).
<{^_^}> error: syntax error, unexpected WITH, expecting ')', at (string):494:32
<samueldr> ah
<samueldr> I see
<samueldr> >> The default size when using this overlay is 256 MB
<samueldr> so "yes, but no, but yes"
<samueldr> CMA is hard, let's go shopping
<samueldr> so that's how it can act when using dtparams
<clever> __overrides__ {
<clever> cma-512 = <&frag0>,"size:0=",<0x20000000>;
<clever> cma-448 = <&frag0>,"size:0=",<0x1c000000>;
<clever> i'm not sure exactly what this syntax is doing
<samueldr> not *sure* either
<samueldr> but tha maps with the params= values
<clever> yeah
<samueldr> frag0 is here
<clever> yeah
<samueldr> so it seems to set "size:0" (first element in the size array) to a value
<clever> > 0x20000000 / 1024 / 1024
<{^_^}> attempt to call something which is not a function but an integer, at (string):494:1
<samueldr> cute
<clever> no hex in nix? lol
<samueldr> irb(main):001:0> 0x20000000 / 1024 / 1024
<samueldr> => 512
<clever> so that is 512mb, in bytes
<samueldr> MB, in bytes :)
<samueldr> mb is millibits
<samueldr> ;)
<samueldr> so uh... huh
<samueldr> there is no &cma alias AFAICT in the DT
<samueldr> that must be added by the firmware
<samueldr> so it's why it can't apply this
<clever> *looks*
<samueldr> oh, I have the symbol
* samueldr checks what's the difference between a symbol name, and an alias
<clever> bcm283x.dtsi: cma: linux,cma {
<clever> bcm2711.dtsi:&cma {
<clever> bcm2711-rpi.dtsi:&cma {
<clever> there is a default over in the generic dtsi file, and then 2 overrides in more specific files
<samueldr> yeah, I see there's a symbol for cma, but no alias
<samueldr> but I don't know (yet) whether &cma refers to a symbol or an alias
<clever> same, i dont see any alias being created
<clever> i think its the name, the cma: part
<samueldr> if I interpret this right, then &xxx would be a reference to a symbol
* samueldr continues looking
<clever> that screenshot doesnt mention & however
<samueldr> yep
<samueldr> that's an excerpt about aliases
<samueldr> nowhere in the section it describes &, which are labels, chapter 6; 6.2
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<clever> the rpi docs also describe labels, fruther down on my link
cptchaos83 has joined #nixos-aarch64
<samueldr> right, so I assume FDT_ERR_NOTFOUND is not about this particular label
<clever> yeah, so bcm2711.dtsi will pull in bcm283x.dtsi
<clever> bcm283x.dtsi provides overall defaults
<samueldr> yep
<samueldr> so there is a label there
<clever> and then line 1036 of bcm2711.dtsi acts like an overlay, and changes things
<clever> bcm2711-rpi.dtsi also acts like an overlay, and changes it differently
<samueldr> just noting that it's 64MiB, but forced in a specific range
<samueldr> overlay shouldn't be the word to use when talking about dtsi
<samueldr> because it can get confusing with the actual "dtbo" type of overlays :)
<samueldr> hmmm... doesn't look like it works
<samueldr> I abhorr the error reporting of the device tree tooling
<samueldr> my operating assumption here is that labels refer to things in __symbols__
<samueldr> and `&firmwarekms` seems to agree
<clever> normally, the labels vanish after you compile a dts to dtb
<samueldr> yeah
<clever> but there is a special flag, to make it keep the labels around in __symbols__, i believe
<samueldr> well, except when symbols are kept
<samueldr> yep
<samueldr> but cma = is clearly in that file!!
<samueldr> ah!
<samueldr> I got it
<samueldr> it's the frag0 dtparam
<samueldr> uh
<samueldr> let me try before saying "got it"
<samueldr> can't wait to just build a GUI to edit those params in Tow-Boot
<samueldr> yep, somehow *declaring* a new symbol throws off fdtoverlay
<samueldr> fun!
<samueldr> I think I like device trees as much as I completely hate them
<samueldr> [ 0.000000] Reserved memory: created CMA memory pool at 0x000000002c000000, size 64 MiB
<samueldr> [ 0.000000] Reserved memory: created CMA memory pool at 0x0000000020000000, size 256 MiB
<samueldr> right, so we'll be able to get this configured per-generation now
dev_mohe has joined #nixos-aarch64
<clever> nice
dev_mohe has quit [Client Quit]
<samueldr> that's what I have now
<samueldr> doing maths in <> is valid as per the spec (and it works)
<samueldr> domenkozar[m]: how do you feel about having this as an option in the nixos-hardware repo for raspberry pi 4? something maybe turned off by default, that would configure modesetting and the device tree overlays accordingly
<samueldr> (I'm also not sure about adding options in nixos-hardware, whether desirable or not... I would say it is desirable)
<domenkozar[m]> Why have it off by default?
<samueldr> less opinionated
<samueldr> some users use the rpi4 headless
<samueldr> either default annoys probably a sizeable chunk enough of our users
<domenkozar[m]> It'd go for support all hardware by default, but submit a patch to turn things off
<samueldr> I don't follow about "submit a patch"
<domenkozar[m]> So that headless users can have a nixos option for it
<samueldr> I still don't follow, "a patch" where?
<samueldr> what I'd do is have those overlays as part of nixos-hardware
<domenkozar[m]> A PR for nixos-hardware to support headless rpi4.
<samueldr> the foundation doesn't turn it on by default, that's maybe a reason why turned off by default is better?
<samueldr> oh, you merged the PR I see
<domenkozar[m]> Time to sleep :)
<samueldr> n/p
<domenkozar[m]> Thanks for all the help!
<samueldr> I'll open a PR, with the option set to off by default so we keep the "same defaults", but for using gpu accel with good defaults it'll be a simple option, which we can also use to configure things like using the modesetting videoDriver for X11
<samueldr> and there's another option for opengl I still haven't looked into
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
apache8080 has quit [Ping timeout: 252 seconds]
superherointj has joined #nixos-aarch64