<kyren_>
hey, I have a raspberry pi 3b running nixos and it's been working really well so far, I want to use it to create a bunch of little audio endpoints and it's working really well! However, I just bought a hifiberry DAC+ to try it out, and I'm having trouble applying a device tree overlay? I think this is what I'm supposed to be doing?
<samueldr>
I can't really *answer*, but can give pointers
<kyren_>
oh yeah sure, sorry I'm pretty familiar with nixos in general, just not at all with the raspberry pi or what a device tree is, or what kernels were available etc, so I wanted to make sure what the lniuxPackages_rpi3 package was
<kyren_>
but thank you!
<samueldr>
quick glossary about device trees: a .dtb file is an FDT, Flattened Device Tree
<samueldr>
so if you see .dtb or FDT, they should be interchangeable
<samueldr>
that's one thing that got me confused for a while before searching
<kyren_>
thank you haha that's super helpful, I was trying to find out what FDT was through google and I found a set of slides about the devicetree FDT format that didn't even define it lol
<samueldr>
I believe FDT is the more correct way to talk about a compiled device tree
<kyren_>
.dtbo = .dtb or is a .dtbo a compiled version somehow of a .dtb?
<kyren_>
okay maybe that's something more complicated, I'm just gonna try the rpi3 kernel now and report back!
<samueldr>
.dtbo is a pre-compiled FDT bit that can modify another FDT
<samueldr>
.dtbo can be applied at runtime even
<samueldr>
and not only when booting, but you could ask the kernel nicely and apply an overlay live!
<samueldr>
but to modify stuff, it has to *somehow* reffer to nodes, and that's why naming things is important (and hard)
kyren_65 has joined #nixos-aarch64
kyren_65 is now known as kyren__
<kyren__>
hey sorry about that, that's interesting re: dtbo, thank you for the explanation
<kyren__>
okay, so one thing that threw me off with this is that the rpi boot loader (uboot?) will actually fall back to other kernels until one works, which is neat but very surprising
kyren_ has quit [Ping timeout: 245 seconds]
kyren__ is now known as kyren_
<samueldr>
uh?
<samueldr>
well, our raspberry pi image uses u-boot *instead* of (booted from the) raspberry pi's own bootloader
<samueldr>
this is because it is a universal mainline image, which can boot on other platforms that use u-boot
<kyren_>
here I'll explain with the _rpi3 kernel actually, because it happens here too, I dunno which boot loader it is or where in the process it is though I'm unfamiliar
<samueldr>
but I don't think it should fall back *automatically* on other kernels?
<samueldr>
you have the choice during boot, with a number-based prompt
<kyren_>
the _rpi kernel is 4.19.75-1, and when it loads during boot I see Retrieving file: /boot/extlinux/../nixos/hash-stuff-4.19.75-stuff right
<kyren_>
yeah you do and it automatically tries others, I'll type what's going on here (roughly)
<kyren_>
then a few lines down, it says Retrieving file: /boot/extlinux/../nixos/hash-device-tree-overlays/broadcom/bcm2837-rpi-3-b-plus.dtb, then the next line is: Skipping nixos-default for failure retrieving fdt
<samueldr>
oooh
<samueldr>
I see
<samueldr>
I didn't know that
<samueldr>
I thought a failure would go to the next boot method, rather than the next option...
<kyren_>
then it tries nixos-56, which is the same obviously, and skips that, then nixos-55, which also fails because it also has a problem, then goes to 54 and succeeds
<samueldr>
... except that the reason I'm thinking that is because I probably have seen that when there is only one option in the menu
<samueldr>
that's neat
<kyren_>
I can't tell if it's trying other kernels or actually trying other nixos generations
<kyren_>
I guess it's actually trying other nixos generations
<kyren_>
it must be
<kyren_>
but anyway, that was the error I wanted to share and what happened when I tried the _rpi3 kernel before, presumably some error with bcm2837-rpi-3-b-plus.dtb
<samueldr>
both kernel and generations
<kyren_>
so yeah I guess if I mess up the kernel I'll know because none of my nixos changes will persist on restart, yeah I guess it's obvious it would be both I just wasn't thinking about how the boot process must work
<samueldr>
what happens here is that there is no file with the name broadcom/bcm2837-rpi-3-b-plus.dtb in the device trees as-compiled for the rpi3 kernel
<samueldr>
first off: you should have said 3B+ earlier! they differ enough to cause problems sometimes :)
<samueldr>
luckily it shouldn't really here... except maybe because of the defconfig used for the _pi3 kernel
<samueldr>
ah ha! bcm2710-rpi-3-b-plus.dts
<kyren_>
ohhhh I should have said 3b+ yes, I apologize
<kyren_>
I do have a 3b though, if that helps things along
<samueldr>
it would likely boot that generation
<samueldr>
but I don't think it should change the results for the actual issue, which is applying the .dtbo
<samueldr>
though to be fair it would be nice if the device tree compiler (dtc) could give more than a dumb error code
h0m2 has joined #nixos-aarch64
<kyren_>
okay so just pretending that I'm a dummy who doesn't know what they're doing, I could: take the hifiberry-dacplus-overlay.dts from the raspberrypi forked linux, then compile it with dtc, then make configuration.nix load that dtb(o?), oh man am I never going to get a good error out of it, hmmm
<samueldr>
if you did just what you described, you'd get the same .dtbo
<kyren_>
but if I can compile it myself and reference the overlay myself, then I can edit the dts file until it works, assuming I can figure out... by trial and error, something... what labels are wrong
<samueldr>
but yes, if you additionally edit it to refer to the same nodes, AFAIUI
<kyren_>
yes sorry, I realized I'd get the same .dtbo I meant that as the first step to make sure that I have it set up to edit
<samueldr>
oh, yes
<samueldr>
I jumped the gun, you weren't finished :)
* samueldr
waits on a git fetch
<samueldr>
I have reasons to believe it's &vdd_3v3_reg, which I somehow can't find on the mainline kernel... but it may be me doing my search wrong
<samueldr>
&i2s and &i2c1 should be fine
<samueldr>
&sound is defined in the overlay, as is hifiberry_dacplus
h0m1 has quit [Ping timeout: 256 seconds]
t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr>
AFAICT, yes, that's one that I can't find being defined
t184256 has joined #nixos-aarch64
<samueldr>
I don't know enough to give a solution, but I'm pretty sure those are the ones
<samueldr>
though I realise just now that even if you had the .dts it wouldn't help
<samueldr>
the hardware would be advertised, but you'd still need a driver
<samueldr>
so you'd need to port sound/soc/bcm/hifiberry_dacplus.c to the current version of the kernel
<kyren_>
okay so other strategy: boot the raspberry pi kernel fork
<samueldr>
more likely to work, I guess the first step is to verify what FDT files get generated
<samueldr>
you can look under /boot/
t184256 has left #nixos-aarch64 ["Error from remote client"]
<kyren_>
I can't boot the rpi3 kernel, but I assume I can see those in the nix store somewhere...
<samueldr>
there should be symlinks under /boot/
<samueldr>
you can look at the extlinux.conf file under /boot/ to know which symlink to look for
<samueldr>
or uh, would there be symlinks?
<samueldr>
no, just extlinux.conf, read it to know which store path to look into
<kyren_>
oh maybe there are sorry
<kyren_>
oh I guess there would be, ugh sorry I wasn't thinking that through there would be because there are multiple bootable generations
<kyren_>
yeah I got it now sorry
t184256 has joined #nixos-aarch64
<kyren_>
wow, okay so extlinux.conf has the FDTDIR set to ../nixos/hash-device-tree-overlays, this seems normal, if I look in that directory, that directory is present and has a single subdirectory called 'broadcom', which is empty
<samueldr>
oh, neat, something broke?
<samueldr>
:)
<kyren_>
I would assume so!
<samueldr>
can you generate a generation without applying the .dtbo?
<samueldr>
with the _rpi3 kernel
<kyren_>
ure
<samueldr>
I'm wondering if it's there or at the kernel build level
<kyren_>
*sure
<kyren_>
I can actually push it to the pi if that's more correct, but if I just build the system using e.g. nixos-rebuild, the output link has a 'dtbs' folder in it, is that the same?
<kyren_>
if so I can test it faster
<samueldr>
should be the same
rajivr has joined #nixos-aarch64
<kyren_>
oh wait I think this makes sense, I think during build there were also errors but it maybe improperly continued the build, I think I remember seeing FDT_NOTFOUND errors during build the first time
<kyren_>
nope never mind I commented out deviceTree.overlays and the dtbs folder is still empty (one 'broadcom' dir), hold on just a sec..
<kyren_>
ugh, wait no I'm getting versions of things mixed up, forget I said that about FDT_NOTFOUND that was from some other combination
<kyren_>
yeah sorry as best I can tell what I was talking about before is not true at least with this configuration, and commenting out hardware.deviceTree.overlays still produces a 'dtbs' folder with nothing in it
<kyren_>
I don't know if this is important, but I'm not building on the pi if that's a potential source of some error, I'm building on an x86_64 machine with boot.binfmt.emulatedSystems
<samueldr>
that's a details that's important to know about
<samueldr>
detail*
<samueldr>
but still, I don't think it would matter really here
<samueldr>
I'm waiting on a clone to be done, and I'll be looking at it
<kyren_>
okay, thank you for all your help here!
<samueldr>
so it looks like it should be present, as the kernel build itself has them
<samueldr>
does `nix log /nix/store/...` with the path of where you looked into show anything useful?
<kyren_>
let me make *sure* of what I said first, it could be that I'm just tired and need some coffee
<samueldr>
haha
<kyren_>
okay, so I was a liar, IF I comment out hardware.deviceTree.overlays, and actually save the file, and actually build it correctly, then the 'dtbs' folder has a broadcom folder in it, but that broadcom folder is full of .dtb files
<kyren_>
after I have done a nix-collect-garbage -d
<kyren_>
if I uncomment the overlas section and try to build again
<samueldr>
so without trying to apply the overlay it has FDTs named as expected?
<kyren_>
I *do* get repeated 'Failed to apply: '/nix/store/sha-raspberry-pi-firmware/stuff/hifiberry-dacplus.dtbo': FDT_ERR_NOTFOUND
<samueldr>
oh
<kyren_>
it repeats about 20 times, then the build succeeds, then the dtbs directory is empty
<samueldr>
and there are 20 FDTs in the other (successfullish) directory?
<kyren_>
lemme paste what the working version FDT files are named if you need that
<kyren_>
hold on checking
<samueldr>
or a divisor of 20
<samueldr>
10, 5, 2
<samueldr>
though I guess it would be either 10 or 20 :)
<kyren_>
I am using 20.03 not master, does that make a difference?
<samueldr>
it might
<kyren_>
hold on I need coffee, brb
<samueldr>
your paste makes me think you have a 32-bit kernel
<samueldr>
there's no reason to have the rpi zero, one and two stuff there
<kyren_>
it's definitely not 32 bit, uname -a says 5.4.61 aarch64 (but that's an old configuration), I'm even setting nixpkgs.localSystem.system to aarch64-linux
<kyren_>
would it help if I gave you the entire configuraiton?
<samueldr>
it could
<kyren_>
let me extract it from my pile of other configurations and also secrets which are improperly in git
cole-h has joined #nixos-aarch64
<samueldr>
oh, it could be fine to be in git... but you have to know your exposure surface that way :)
<kyren_>
https://bepasty.kyju.org/hzLjHv9K <- still has some unrelated stuff in it, but the configuration is in the 'miku' folder (machine name for the rpi)
<kyren_>
yeah it's a private gitlab instance it's not NOT secure, but I still don't like it very much
<kyren_>
well security isn't binary, it's not wide open
<samueldr>
bleh, that's an hostile page that bepasty page
<samueldr>
no link to the file
<samueldr>
so I can't copy link and wget on another machine
<kyren_>
does the download button work, oh yeah I hate that!
<kyren_>
I just tried that myself
<samueldr>
works to download
<kyren_>
it's my bepasty, I need to set up something else
<kyren_>
ah crap I left my wifi password in it oh no
<kyren_>
I think I'll live
h0m2 has quit [Ping timeout: 246 seconds]
<samueldr>
nix-build -I ~ '<nixpkgs/nixos>' --arg configuration ./configuration.nix -A system && find result/dtbs/ # -I ~ is to use the <nixpkgs> and <home-manager> I cloned in $HOME
<samueldr>
that's what you could use to build without making a generation and out of tree I guess
<kyren_>
oh I use the deploy.sh script and 'build'?
<samueldr>
yeah, just saying out loud how I'm testing
<samueldr>
didn't look at deploy.sh
<kyren_>
oh okay
<kyren_>
it's just nixos-rebuild + shell.nix
<samueldr>
ah!
<samueldr>
base = pkgs.device-tree_rpi;
<samueldr>
so you were never applying the .dtbo against the kernel-built FDTs
<samueldr>
I still haven't had to work with device trees overlays, so I'm not used to them
h0m2 has joined #nixos-aarch64
<kyren_>
yeah if I comment out 'base = pkgs.device-tree_rpi;' then I think I get something more like what you expected
<samueldr>
it's on the tip of my tongue, but IIRC there's something like an option to effectively "strip" FDTs that the kernel employs (by default?)
<samueldr>
and that's why you'd get FDT_ERR_NOTFOUND even on the rpi's own kernel
<samueldr>
:/ can't seem to find information confirming that
<kyren_>
it would really help if dtc would output better errors
<samueldr>
I don't think that'll help for mainline, but that might / should help for _rpi3
* colemickens
is drowning in <nixpkgs>
<samueldr>
colemickens: hm?
<kyren_>
hehe, substituteInPlace scripts/Makefile.lib, that's one way to do it
<samueldr>
I'm not looking into that anymore, but I think that should be the last piece of the puzzle
<kyren_>
yeah I really appreciate all your help, I'm currently trying to even get the _rpi3 kernel to boot at all
<kyren_>
I actually think once I get the _rpi3 kernel to boot I might not even *need* to apply a device overlay since it's kernel 4.19, I'm not sure
h0m2 has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
<samueldr>
I believe you'll need it
h0m2 has joined #nixos-aarch64
<kyren_>
yeah you might be right I was trying to understand what hifiberry.com was saying about it and maybe misunderstanding
<kyren_>
wow I cannot get the _rpi3 kernel to boot at all, do I need to be using the uh... older boot method or something, I don't know how any of this works but I vaguely remember something about that
<kyren_>
I bet I could set it up, I actually have a bunch of hardware, I have several ftdi cables and a bus pirate so ONE of those probably works
<samueldr>
not sure if and how it matters 3B vs. 3B+
<kyren_>
yeah still 3B+
<samueldr>
bus pirate surely can
<samueldr>
and it's really useful to have serial going
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
h0m2 has quit [Ping timeout: 272 seconds]
h0m2 has joined #nixos-aarch64
<kyren_>
samueldr++
<{^_^}>
samueldr's karma got increased to 262
kyren has joined #nixos-aarch64
kyren_ has quit [Remote host closed the connection]
disasm has quit [Ping timeout: 240 seconds]
disasm has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<kyren>
okay now that I understand what question I should have asked to begin with: how do I set up nixos on a raspberry pi such that it boots with boot.loader.raspberryPi? can I do that from the current aarch64 20.03 image from hydra?
<kyren>
ahhhhh, maybe I'm misunderstanding how that works too
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
juliosueiras has quit [Ping timeout: 258 seconds]
cole-h has quit [Quit: Goodbye]
stiell has quit [Ping timeout: 260 seconds]
<kyren>
okay, so on a fresh nixos 20.03 install on a raspberry pi 3b+, setting 'boot.kernelPackages' to 'linuxPackages_rpi3' does not boot, with almost no other changes
<kyren>
I naively believe that this is maybe because it is using the generic-extlinux-compatbile bootloader rather than the raspberry pi specific one, but I don't think that a fresh 20.03 install from the sd image from hydra is compatible with the old bootloader, because the old bootloader puts the kernel images and config.txt in a /boot partition
<kyren>
but the /boot partition no longer exists, it is only a firmware partition now
<kyren>
so now I'm stuck figuring out how to set up nixos 20.03 in the way I guess 19.03 was set up
stiell has joined #nixos-aarch64
<kyren>
I think I need to make my own sd image with a larger firmware partition size
stiell has quit [Ping timeout: 240 seconds]
justanotheruser has quit [Ping timeout: 246 seconds]
stiell has joined #nixos-aarch64
stiell has quit [Excess Flood]
stiell has joined #nixos-aarch64
* colemickens
almost wants an rpi3 to help out with questions
<kyren>
awwwww haha, I'm getting somewhere! I ran into a known bug building an rpi3 image on an x86_64 machine (https://github.com/NixOS/nixpkgs/pull/82718) so I'm trying actually to go from 19.03 forward, since 19.03 happens to have the right partition sizes, I'm still trying to get something to actually boot with the raspberryPi bootloader
<{^_^}>
#82718 (by misuzu, 24 weeks ago, merged): nixos/lib/make-ext4-fs: use mkfs.ext4 instead of cptofs
<colemickens>
how do I opt out of the cross-build stuff in mobile-nixos? I want to instantiate, copy to aarch64 builder, build and tehn copy back but I feel like the auto x86-64 detection is getting in my way
<kyren>
I'm not the person to answer it, but does setting both nixpkgs.localSystem and nixpkgs.crossSystem help?
<kyren>
or just actually localSystem
<kyren>
I guess if you're just using nixpkgs then it would be the localSystem argument to nixpkgs? I think think passing that makes it not be automatically detected?
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
yangm has quit [Quit: Idle for 30+ days]
jasom has quit [Ping timeout: 244 seconds]
jasom has joined #nixos-aarch64
<colemickens>
"but that the rendering might not be as expected depending on what renders it." wat
<kyren>
alright, I've been at this for nearly 12 hours and it works
<kyren>
so, unless anybody has any objections I'm going to explain what I did to make the hifiberry-dacplus work on nixos here, just so that it shows up in a google search somewhere
<kyren>
first, as previously discussed, you need to be running the raspberrypi patched kernel, so in nixpkgs it's linuxPackages_rpi3 (or 2 or 4 or whatever)
<kyren>
I've only tried this on a 3B+ but it does work
<kyren>
in order to boot the patched raspberrypi kernel, you must set boot.loader.raspberryPi.enable, but not be using u-boot so no boot.loader.raspberryPi.uboot.enable or boot.loader.generic-extlinux-compatiblre.enable
<kyren>
I did not know this, but the, I guess it's official? raspberry pi bootloader has a splash screen, it's really obvious when it's being used, there is no selection dialogue for different generations just a giant rgb colored square
<clever>
the rainbow? or the 4 raspberries?
<kyren>
it's a rainbow for me
<clever>
the rainbow is part of the firmware, it is always there
<kyren>
huh, it is not there when I use uboot (I think I have the terminology right I only barely know what's going on here)
<clever>
u-boot uses the mailbox to setup a framebuffer relatively quickly
<clever>
but when you skip u-boot, its up to kernel modules to do it
<clever>
and that delays things a lot more
<kyren>
ohhh okay, so yeah okay the boot is just very different then, yeah that makes sense
<clever>
you can `disable_splash=1` in `config.txt` though, to just not show anything until linux turns the display on
<clever>
when using the official firmware, you are ALWAYS using the rpi bootloader, even when your using uboot
<clever>
uboot just means the rpi bootloader loads uboot instead
<kyren>
anyway, I don't 100% know if this is true but in order to get the boot.loader.raspberrypi options to work, you seem to have to go back to the "old" partition scheme, where /boot is on a separate partition and also holds the firmware, which is not the current partition scheme in 20.03
<clever>
yeah
<kyren>
okay that makes sense now, and it makes sense why maybe the patched kernel can't boot from uboot
<clever>
i think its more a matter of the dtb files
<kyren>
I don't 100% know that's true but that's what it looks like
<clever>
and dtb patching
<kyren>
oh it might be, once you enable the other boot method it does put a lot of dtb files into /boot?
<clever>
yeah
<clever>
for the pi3, when you apply power, the ROM will load bootcode.bin into the L2 cache and execute it
<clever>
bootcode.bin must then enable the dram controller, then load and execute start.elf
<clever>
start.elf then reads config.txt, loads the "kernel" and a dtb for that model, and patches the dtb automatically, then runs the "kernel" on the arm
<clever>
boot.loader.raspberryPi.uboot.enable sets that "kernel" to be u-boot instead of linux
<kyren>
anyway, other stuff was in the way of me making a 20.03 image directly with a large enough NIXOS_BOOT partition (it would have been named FIRMWARE but as long as it was large enough it would have worked), I guess I could have done this other ways but I just installed via a 19.03 image that was better partitioned and upgraded
<clever>
and u-boot throws out the dtb that the firmware carefully prepared, and loads its own dtb files
<kyren>
I see okay'
<kyren>
this makes a lot of sense thank you for explaining it!
<clever>
i could probably make the hifiberry work under nixos with the forked kernel, but you may loose other critical features
<kyren>
so after I did that, linuxPackages_rpi3 will actually boot, and as a bonus boot.loader.raspberryPi.firmwareConfig will actually modify config.txt (it is otherwise broken right now)
<kyren>
that all sounds really cool and useful, I'm sorry I'm talking about stuff that's wildly less interesting, I'm just trying to make sure I type it into here so it at least shows up in chat logs
<kyren>
actually the only thing I want the hifiberry for is just audio so there's not too many other critical features other than wifi, but what I have does work now
<srk>
you can try with upstream kernel and #79370 (if you can craft the overlay for the upstream kernel)
<kyren>
but I ran into exactly that PR you just linked, #79370, not having that makes this not work specifically for the hifiberry-dacplus, but it happens to work for the hifiberry-amp
<kyren>
but at this point you can use boot.loader.raspberryPi.firmwareConfig and add 'dtoverlay=hifiberry-dacplus' and it will be loaded that way, I'm not sure what the difference is but I'm sure the nixos way is better
<clever>
dtoverlay= can trigger a lot of undocumented magic in the firmware
<srk>
yeah, that's the custom rpi bootloader functionality which can patch dt before boot
<kyren>
and then the hifiberry will actually work, AFTER you change power supplies because my power supply was not stronk enough and I kept boot looping and thinking it was software
Acou_Bass has joined #nixos-aarch64
<clever>
which can help
<kyren>
I dunno how it works because the overlays directory isn't on /boot
orivej has quit [Ping timeout: 256 seconds]
<clever>
as an example, enable_uart=1 does different things, based on other overlays you use
<kyren>
or maybe that's not important and it's loaded later than I'm thinking
<clever>
dtoverlay= loads from the fat32 fs before the arm even turns on
<kyren>
oh, then I 100% have no idea what it's doing, because the overlays directory isn't on boot
<clever>
check `mount`, is boot the fat32 fs?
<kyren>
yeah definitely
<kyren>
I didn't expect it to work and tried for a while to convince nixos to copy the overlays directory to /boot for that reason
<kyren>
but then I just tried it and it somehow works
<clever>
one min
<kyren>
anyway I think I've typed the whole procedure in for the next poor soul who wants to try this
<clever>
kyren: if you run both `vcgencmd help` and `vcgencmd commands`, do you see one to view logs? maybe it was under `vcdbg`
<kyren>
I am interested in doing this better though
<kyren>
also that tool to re-partition aarch64 images would have actually come in handy earlier
<Mic92>
kyren: thanks. did not found it for some reason
<Mic92>
Now I need to find which attribute this is.
<clever>
kyren: last night, the pi was refusing to boot, no matter what i did
<clever>
kyren: just now, i plugged it back in, and it booted instantly
<kyren>
earlier I had the pi in some kind of state where it would, uuugh I don't remember what the error but it was something like "waiting on mmc" or something like that, it would get to nixos stage 2 then do that nearly 100% of the time
<kyren>
then I accidentally got the same thing to boot by pressing keys during startup
<kyren>
then I figured out that it would boot if I held backspace during the rainbow splash
<clever>
heh
<kyren>
and only if I held backspace during the rainbow splash
<clever>
for me, it just gets stuck at this endlessly
<clever>
and /dev/mmcwhatever never appears
<clever>
Timed out waiting for device /dev/mmcblk0p2, trying to mount anyway.
<kyren>
uhhh, actually it might have been something really similar to that
<kyren>
it... went away question mark?
<clever>
same
<clever>
[ 258.874373] mmc0: read transfer error - HSTS:20 EDM:10804
<clever>
this error also happens randomly, but it still functions
<kyren>
you would think, oh okay I'm just noticing patterns where there are no patterns but I tried it like 8 times at one point
<Mic92>
clever: any idea why evaluating sd_image.aarch64-linux in nixos/release.nix locally results in a different has from what hydra produces for the same commit?
<clever>
Mic92: the path to nixpkgs gets embeded into the binary
<clever>
Mic92: so things like .git are an impurity
<Mic92>
clever: ok. so I need to import a channel?
<clever>
Mic92: you need to have <nixpkgs> at the exact same path hydra had it at
<Mic92>
mhm. I guess downloading build products from hydra would be easier in this case.
<clever>
Mic92: if you check the inputs for the eval, you can see that path, then just nix-store -r it, and -I nixpkgs=/that/path
<clever>
or just nix-store -r the whole image
<Mic92>
clever: I build some sort of nix module around uboot that creates new images from the images on hydra. I guess I need to use fetchTarball than instead.
<kyren>
actually come to think of it in my situation my weird transient errors might have been power related, and that's why they're not there now (knock on wood)
<kyren>
okay I admit it building with boot.binfmt.emulatedSystems is also slow
<kyren>
I think it would go faster if it would decide to use more than one core
disasm has quit [Ping timeout: 264 seconds]
disasm has joined #nixos-aarch64
<kyren>
okay clever, I get an error building '/nix/store/cdpdp6z580cq7p4y0r3j9kj1dsj95afj-glibc-2.30.drv' on my x86_64 machine
<pinage404[m]>
<clever "pinage404: on an rpi, the maskro"> i don't know what is a maskrom, bootcode.bin, dram, start.elf, uboot =/ so i didn't understood your answer
<clever>
pinage404[m]: the maskrom is read-only-memory, that gets configured by adjusting the mask when creating the silicon chip at the factory
<clever>
kyren: you may need to build glibc on the pi, then copy-closure it over
<clever>
kyren: but if you have a serial adapter, that can be faster
<kyren>
oh, I do have a serial adapter, I don't need to build this log viewer if I can hook up a serial connection?
<clever>
kyren: correct
<kyren>
okay I will do that instead
<clever>
kyren: if you set uart_2ndstage=1 in the config.txt, then the logs spew out the uart
<clever>
then you dont need closed-source junk to read it at runtime
<kyren>
gotcha
<kyren>
ugh, okay I guess I can't have a serial connection when I have a hifiberry plugged in
<kyren>
well, unless it's not used on the hifiberry
<clever>
kyren: check the traces on the pcb? check the schematics?
<kyren>
yeah its' fine I can see on their website, never mind I'm okay
FRidh has quit [Quit: Konversation terminated!]
<kyren>
ahhhhhhh connecting rx and tx correctly the first time might not be possible
<clever>
kyren: some usb adapters label things confusingly
<clever>
kyren: for my sparkfun ftdi board, its labeled sanely, you connect tx->rx always
<kyren>
nah this is a bus pirate it's just my brain being confusingly
<clever>
so the pi tx, to ftdi rx
<kyren>
I got it haha I just did it wrong the first time
<kyren>
when not using uboot, there's no automatic way to roll back generations right?
<kyren>
would I just open the sd card on another computer and copy things from the old/ directory?
<clever>
correct
<clever>
it may be possible to fix the uboot scripts to respect the firmware dtb, but ive not looked into exactly how yet
<kyren>
yep that's what I figured!
<clever>
i think uboot has the input dtb as a script variable
<clever>
so you can just forward that to linux as-is
<kyren>
yeah uboot is vastly preferable all things being equal
<clever>
rpi-open-firmware currently has its own custom bootloader, and getting generation support is one of my ideas
<kyren>
yep as expected it works just fine without the additions to config.txt, I think I was having a lot of transient errors which were confusing me that were all due to power
<clever>
gpio0/1 are for the hat eeprom, i2c based
<clever>
the firmware will query that, and load a dtbo from there, then apply it automatically
<kyren>
got it, so wait is that dtbo based off of the specific patched kernel, so the eeprom requires the patched raspberry pi kernel or does it not uhhhh, reference the kernel like that
<clever>
the dtbo assumes the nodes are named a certain way
<kyren>
I guess you could always ignore the dtbo on the eeprom and fix it it's just pretty gross
<clever>
so the root dtb file you load must have them named the right way
<clever>
it also tends to leave your questions un-answered, because irc users just see "sent a long message" and dont know what the subject is
<clever>
nobody will even know what the question is, without clicking every link they see
<kyren>
thanks for teaching me a bunch of stuff about how the raspberry pi works! I also have a working sound card finally!
<kyren>
I'm a lot less afraid of a bunch of this now and I think I could have gotten to a solution a lot faster without hitting some small roadblocks
<pinage404[m]>
i'm trying to follow this https://nixos.wiki/wiki/Move_Nix_Store_to_new_partition but i have this issue `tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options` when i try to do the `tar` command ; does it is specific for Raspberry Pi / Aarch64's version ?
<clever>
pinage404[m]: what args did you run tar with?
<pinage404[m]>
<clever "pinage404: what args did you run"> `tar -afp /nix.tgz /nix /nix.bak`
<clever>
pinage404[m]: you didnt tell it to create
<clever>
pinage404[m]: the example in the wiki looks wrong
<pinage404[m]>
should i add `-c` ?
<clever>
the /nix.bak part of the command doesnt even make sense
<clever>
pinage404[m]: are you running nixos or another distro?
<pinage404[m]>
nixos on Raspberry Pi
<clever>
pinage404[m]: you cant move /nix while nixos is running, so you must first boot into something else, or mount the card on another machine
<pinage404[m]>
sad
<pinage404[m]>
ok, thansk, i will do that
<kyren>
oh there's that stupid transient 'mmc0: timeout waiting for hardware interrupt.'
<clever>
kyren: ah, thats different from mine
<kyren>
yeah it is, I didn't remember it properly
orivej has joined #nixos-aarch64
<kyren>
do the scripts that set up the /boot partition copy the current generation's kernel twice, once into /boot and once into /boot/old?
<kyren>
I shouldn't whine about it I should try to get the patched kernel working with uboot instead
<clever>
not sure
fgaz has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<kyren>
clever++
<{^_^}>
clever's karma got increased to 501
<clever>
currently digging into the VC4 bootcode.bin, and i just learned something interesting
<clever>
there are disable_pvt and force_pvt options in config.txt
<clever>
and they enable/disable the dram refresh rate dynamically updating twice a second, based on ram temp
<clever>
and it seems to be configured pretty early in the boot process
<clever>
and is more set&forget then i thought it was
<Mic92>
I guess we should move this to nix-community?
<Mic92>
samueldr: do you want to help maintaining? You have access to more hardware.
juliosueiras has joined #nixos-aarch64
<samueldr>
I could, not sure if time will permit
cole-h has joined #nixos-aarch64
<samueldr>
though one thing you should optimize right away: make rock64 use a generic rockchip setting, where the only thing the rockchip thing doesn't define is the u-boot binary
<samueldr>
u-boot should be a setting to, so that it can be set once
* samueldr
thinks
<samueldr>
similar in spirit, completely different implementation
<samueldr>
but let's say all RK3328 and RK3399 for sure
greizgh_ has quit [Quit: greizgh_]
<samueldr>
RK3288 too, armv7l, I suppose, except the google version
greizgh has joined #nixos-aarch64
<samueldr>
I have literally only one RK3399 *board* and it's tied up, the pinebook pro kind of doesn't count either, and its SPI is flashed so I can't exactly test
<samueldr>
but from reading only, I'm pretty confident it would be fine
<Mic92>
samueldr: which uboot is this?
<Mic92>
I tested the image on rock64 itself, so if it is the same, it should work as well.
<samueldr>
ubootROCPCRK3399 (name: roc-pc-rk3399)
<samueldr>
though you also have ubootRockPro64, rockpro64
<samueldr>
I think that's it for what's in nixpkgs right now
<samueldr>
the pinebook pro was just merged, it's on master, not yet unstable
<samueldr>
though to be fair, I'd much rather NixOS pinebook pro users flash it to SPI
<samueldr>
(well, in fact, all SBC users that can should)
<Mic92>
samueldr: only pinebook pro, not the pinebook right?
<samueldr>
exact
<samueldr>
pinebook is A64
bennofs__ has joined #nixos-aarch64
<samueldr>
which requires either MBR partitioning scheme, or holey
<samueldr>
though it only has one "program file" to burn
<Mic92>
mbr should be supported too.
<Mic92>
I cannot test it though.
<samueldr>
well, you could make a rock64 MBR image :)
<samueldr>
I wonder if u-boot will UEFI boot from an MBR partitioned system
<samueldr>
I don't remember which criterias it looks for
bennofs_ has quit [Ping timeout: 256 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
FireFly is now known as Luciole
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
juliosueiras has quit [Ping timeout: 240 seconds]
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
Thra11 has quit [Quit: WeeChat 2.9]
Thra11 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]