bennofs_ has joined #nixos-aarch64
bennofs__ has quit [Ping timeout: 256 seconds]
<samueldr> :| I might be having the worst of times trying to finish up a feature
<samueldr> where the kernel with kexec will fail to allocate `cma`, but no real output around it showing why and how
<samueldr> I need to validate, but I think it's only when `kexec` use `--dtb`
<samueldr> yeah :|
orivej has quit [Ping timeout: 256 seconds]
rajivr has joined #nixos-aarch64
<samueldr> argh!
<samueldr> I guess at least one node has been added in by u-boot
<samueldr> yes, all of those properties are added by u-boot
<samueldr> I don't think /chosen are of concern
<samueldr> nothing seems to rever to it in the kernel source code, in addition to u-boot specifically stating it's adding it for itself
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<samueldr> indeed, all under /chosen weren't needed
<samueldr> also, how the heck should I know that I need to forward *some* bootloader properties for some devices, like here mac address and serial
<samueldr> again it looks like the kernel wanting to be in control of the dtb files is going to cause much pain :/
cole-h has quit [Ping timeout: 272 seconds]
<samueldr> I guess I really need to check for a qemu-with-dtb target to test against
<samueldr> but it's that suspicious "memory" node
<craige[m]1> I know you're not leading users with UI's samueldr but ia there are sample set of a local.nix that ought to bring up a UI of anykind? (I've not found one and I'm just trying to rule out issues with mine, if there are any)
<samueldr> craige[m]1: do you mean for stage-2?
<samueldr> examples/demo, while it will not cross-compile, is a demo system using X11
<craige[m]1> Thanks samueldr - I'll revisit that file 😃
<samueldr> you do have stage-1 UI, right?
<samueldr> pinephone?
<craige[m]1> Yep, pinephone.
<samueldr> oh
<samueldr> examples/hello
<craige[m]1> I have a Librem 5 devkit in my draw that I'll get to at some point too.
<samueldr> which boots to stage-2 to a limited application, but is cross-compilable
<craige[m]1> I'll revisit that one too. Thanks 😃
<samueldr> is it the i.MxM8 SoC or was the devkit targetting i.MxM6?
<craige[m]1> 🤷‍♂️ - I'll look.
<samueldr> if it's i.MxM6 it might not be as useful as it'll be armv7
<craige[m]1> "Dev Kit v1.0.0"
<samueldr> >> The EmCraft SoM with a Quad iMX8M
<samueldr> right
<samueldr> and the modem board
<samueldr> so that looks like it could end up being useful
<craige[m]1> Yes, just found that, IMX8M
<samueldr> I would expect it'll be brought up exactly like the pinephone is
<samueldr> using their u-boot fork at first
<craige[m]1> I'm tempted to donate the IMX8M dev board to samueldr or clever as I've had it for 12 months now (got it from a mate) and it's just gathering dust. I suspect it will be of more use to the Mobile NixOS project in other hands.
patagonicus6 has joined #nixos-aarch64
patagonicus has quit [Ping timeout: 240 seconds]
patagonicus6 is now known as patagonicus
<samueldr> ugh, hopefully the libfdt API is better than the CLI tools
<samueldr> I'll need to transplant the node at /memory into a temporary dtb
<samueldr> and use that dtb to boot
<samueldr> (though I'll also forward other known desired entries)
<samueldr> that's really cumbersome though :(
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<samueldr> oh, and the kernel does not even export the full FDT as /proc or /sys entry??
<samueldr> it's going to look like a rube goldberg machine
<samueldr> first, decompile the dts form /proc/device-tree, then compile back into dtb
<samueldr> then use libfdt (maybe) to copy the node
<samueldr> oh, I can skip the dts bit by directly "compiling" to .dtb file
hexa- has quit [Quit: WeeChat 2.9]
hexa- has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 258 seconds]
h0m1 has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<colemickens> "this should be easy"->30 secs in hit inf recursion->30 mins in, still stuck on inf recursion
<colemickens> you'd think at this point I'd be better about figuring it out quickly
<samueldr> nah
<samueldr> sometimes they are hard to figure out
s1341 has quit [Read error: Connection reset by peer]
s1341_ has joined #nixos-aarch64
s1341_ has quit [*.net *.split]
hexa- has quit [*.net *.split]
Darkmatter66 has quit [*.net *.split]
Asmadeus has quit [*.net *.split]
s1341_ has joined #nixos-aarch64
hexa- has joined #nixos-aarch64
Asmadeus has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
hexa- has quit [Max SendQ exceeded]
sarcasticadmin has quit [Ping timeout: 240 seconds]
hexa- has joined #nixos-aarch64
hpfr has quit [Ping timeout: 246 seconds]
mica[m] has quit [Ping timeout: 268 seconds]
marijan[m] has quit [Ping timeout: 268 seconds]
kloenk has quit [Ping timeout: 246 seconds]
cornu has quit [Ping timeout: 246 seconds]
Ericson2314 has quit [Ping timeout: 246 seconds]
fgaz has quit [Ping timeout: 246 seconds]
Ke has quit [Ping timeout: 260 seconds]
bbigras has quit [Ping timeout: 260 seconds]
puzzlewolf has quit [Ping timeout: 260 seconds]
awaxa has quit [Ping timeout: 260 seconds]
chr0ma[m] has quit [Ping timeout: 260 seconds]
LinuxHackerman has quit [Ping timeout: 260 seconds]
archseer has quit [Ping timeout: 260 seconds]
Danct12[m] has quit [Ping timeout: 260 seconds]
roberth has quit [Ping timeout: 260 seconds]
thefloweringash has quit [Ping timeout: 244 seconds]
veleiro has quit [Ping timeout: 244 seconds]
manveru[m] has quit [Ping timeout: 240 seconds]
unclechu has quit [Ping timeout: 240 seconds]
danielrf[m] has quit [Ping timeout: 260 seconds]
l-as has quit [Ping timeout: 260 seconds]
colemickens has quit [Ping timeout: 260 seconds]
chr0ma[m]1 has quit [Ping timeout: 244 seconds]
noneucat has quit [Ping timeout: 244 seconds]
pinage404[m]1 has quit [Ping timeout: 265 seconds]
zuh0 has quit [Ping timeout: 260 seconds]
ejpcmac has quit [Ping timeout: 265 seconds]
leonardp has quit [Ping timeout: 240 seconds]
dtz has quit [Ping timeout: 265 seconds]
DavHau[m] has quit [Ping timeout: 246 seconds]
hiroshi[m] has quit [Ping timeout: 246 seconds]
mvnetbiz_ has quit [Ping timeout: 240 seconds]
artturin has quit [Ping timeout: 268 seconds]
siraben has quit [Ping timeout: 268 seconds]
Dandellion has quit [Ping timeout: 268 seconds]
Ox4A6F has quit [Ping timeout: 268 seconds]
submoo[m] has quit [Ping timeout: 240 seconds]
flo[m] has quit [Ping timeout: 265 seconds]
edrex has quit [Ping timeout: 265 seconds]
yangm has quit [Ping timeout: 265 seconds]
craige[m]1 has quit [Ping timeout: 268 seconds]
sarcasticadmin has joined #nixos-aarch64
marijan[m] has joined #nixos-aarch64
mica[m] has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
LinuxHackerman has joined #nixos-aarch64
puzzlewolf has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
Ke has joined #nixos-aarch64
Danct12[m] has joined #nixos-aarch64
l-as has joined #nixos-aarch64
colemickens has joined #nixos-aarch64
chr0ma[m] has joined #nixos-aarch64
archseer has joined #nixos-aarch64
roberth has joined #nixos-aarch64
awaxa has joined #nixos-aarch64
kloenk has joined #nixos-aarch64
noneucat has joined #nixos-aarch64
manveru[m] has joined #nixos-aarch64
pinage404[m]1 has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
fgaz has joined #nixos-aarch64
hpfr has joined #nixos-aarch64
unclechu has joined #nixos-aarch64
cornu has joined #nixos-aarch64
chr0ma[m]1 has joined #nixos-aarch64
Dandellion has joined #nixos-aarch64
siraben has joined #nixos-aarch64
yangm has joined #nixos-aarch64
zuh0 has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
dtz has joined #nixos-aarch64
artturin has joined #nixos-aarch64
ejpcmac has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
DavHau[m] has joined #nixos-aarch64
submoo[m] has joined #nixos-aarch64
flo[m] has joined #nixos-aarch64
edrex has joined #nixos-aarch64
craige[m]1 has joined #nixos-aarch64
hiroshi[m] has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
<edrex> patagonicus heey, i'm just about to attempt nixos install on an odroid hc1. Last time I tried (a few months back, following your instructions on the wiki), it wouldn't boot (and I don't have a TTL-USB cable to look at the UART rn). So if you're still around I might HYU with Qs..
<patagonicus> edrex: sure, I can help with that. I also woke up like 15mins ago, so I might not give the best advice for the next hour or so. :D
<edrex> :D
<patagonicus> The main problem I can see is that nixpkgs often doesn't compile on armv7l. I've already spent a week going from early December to something more recent and it doesn't work. And my current problem is that it doesn't boot …
<patagonicus> I think my recommendation would be to use nixpkgs at 26cc536edf2 and to cherry-pick b70430a3ddf8f9153606c4e5aa8034cf361c709b on top of that. That is roughly what I'm currently running on my HC2s.
<patagonicus> And I still haven't documented how to make the HDDs properly shut down when you reboot/power off …
<edrex> i am just tackling the first NixOS learning cliff this week, so I only 2/3 understand what you're talking about with nixpkgs. Do you mean a week compiling on device?
<edrex> they keep spinning when you halt the system?
<edrex> so you have an HC1 that currently doesn't boot and HC2s that work? You use the HC1 to test configs first?
<edrex> i have 2 HC1s
<patagonicus> Well, compiling, failing, then changing something and compiling again. Building my system on my devices takes about 24h or a bit less. I have four HC2s with distributed compiling, but a lot of the compile time comes from packages that are needed for all later packages, so I'm actually not sure how much faster it is compared to a single machine.
<patagonicus> I don't have any HC1s, but AFAIK the only difference is the metal they are mounted on, exactly the same board for the electronics.
<patagonicus> And they all boot, just not if I try to switch to a newer version of nixpkgs.
<patagonicus> For the HDDs it's a known problem that they don't automatically spin them down: https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script
<edrex> don't the HC2s run on 12V power?
<patagonicus> I've codified that into my configuration.nix
<patagonicus> Ah, yes. Ok, then they are different, I guess. But that shouldn't matter for nix.
<edrex> thanks! Adding to my notes
<edrex> but yeah, my impression that other than the drive power they are identical
<patagonicus> You are probably crosscompiling currently, right? Or are you building on the HC1 from a different Linux? As long as you find something to install Nix on it should work.
<patagonicus> Just note that it will take a decent amount of disk space (I wouldn't try it on a MicroSD card smaller than 32GB unless you put /nix on the HDD/SSD) and you'll need at least a few gigs of swap space.
<edrex> IDK yet. still figuring stuff out
<edrex> What about native compiling under QEMU on a fast amd64?
<patagonicus> Hmm, good question. It's probably slower than cross-compiling on the same machine, but on the other hand it would not be cross-compiling, so it would save you the trouble of having to recompile everything on the machine once you have it booted up and want to change the system.
<patagonicus> I haven't tried. I managed to bootstrap by cross compiling and since then only compiled natively on NixOS.
<edrex> I may not have the nix chops yet to execute this successfully. I was hoping to get it bootstrapped to the point where I can continue remotely over SSH (i leave arm NASes at my friends' houses like Johnny Homeserver-seed, and I'm only here till tomorrow eve)
<patagonicus> Oh, that's a bit short as compiling everything takes a while. I could see if I can build you an SD card image to get it booted up, but you'd still have to configure afterwards.
<edrex> I'll give it a go and see if it boots at least :D
<edrex> thanks
<patagonicus> And, yeah, I don't really trust the machines yet to run them without physical access, but I'm considering wiring up UART in a loop and getting some "smart" power plugs so I can power cycle them. It's unlikely to break so bad I can't just boot an older NixOS generation, so that should get me out of most problems.
<edrex> Did you resolve the "no SATA on reboot" issue mentioned on the wiki? Debian wiki says a firmware flash might fix it
<edrex> Yeah, I spent some time researching different auto-rollback options on different embedded linuxes a couple months ago. It would be cool if nixos knew how to roll back to the last successful boot if it didn't come all the way up to network. There are some issues discussing it.
<edrex> Watchdog timer
<patagonicus> Ah. The fix for that is to use the Hardkernel fork of the kernel, it's in nixpkgs, although not quite the newest version. But maybe it works in mainline by now? Haven't tried in a while.
<edrex> i was hoping to get mainline working. but maybe that's too much
cole-h has joined #nixos-aarch64
<patagonicus> Ok, I managed to slightly modify the multiplatform sd image from nixpkgs to not require a ton of (re)builds, but it'll still take a bit to build.
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever> ,stty
<{^_^}> echo "stty rows $(tput lines) cols $(tput cols)"
zupo has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cole-h has quit [Ping timeout: 256 seconds]
alpernebbi has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
alpernebbi has quit [Ping timeout: 240 seconds]
TheNumb has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
alpernebbi has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rosariopulella[m has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.8.2 - https://znc.in]
<patagonicus> Oh, no. I'm almost done with bisecting and I don't see anything in the remaining commits that should affecting booting at all. :(
<patagonicus> Wait. Could it be a uboot/kernel mismatch? Maybe because of dtbs or something? But I'm pretty sure I tried a fully clean install on the version that didn't work and that didn't help.
<patagonicus> Oof. I think I've been holding nix-build-status wrong. -_-
disasm has quit [Quit: WeeChat 2.0]
disasm has joined #nixos-aarch64
njd has quit [Ping timeout: 240 seconds]
njd has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
<patagonicus> Yay, found it: https://github.com/NixOS/nixpkgs/commit/9c213398b312e0f0bb9cdf05090fd20223a82ad0 Makes more sense now, since that one is changing stuff related to the kernel. Now I have something to diff. :)
rajivr has quit [Quit: Connection closed for inactivity]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
red[evilred] has joined #nixos-aarch64
<red[evilred]> oh wow, 5.6k messages since I've looked at this channel
<red[evilred]> it's been a while apparently :-(
<edrex> patagonicus: that's the commit that broke boot for you? great sluething!
<patagonicus> edrex: I just had to bisect a few ten thousand commits. :D
<patagonicus> It seems to lose the hostPlatform extraConfig, although I don't understand why. The hostPlatform extraConfig for armv7 has one markerd as "Odroid XU4 hangs without this" and I'm using Odroid HC2s, which are almost identical …
<edrex> what was your test procedure for each commit? fully generate an image, flash, try to boot?
<patagonicus> Yes, unfortunately.
<patagonicus> I'm not sure why I couldn't reproduce it by just replacing the kernel.
Cadey has joined #nixos-aarch64
<patagonicus> I did minimize the image a bit, but it still took forever to build - building just the kernel would have been … a bit faster.
<Cadey> where's the raspi 4 image again?
<samueldr> last successful build https://hydra.nixos.org/build/134720986
<Cadey> downloading, thanks
<samueldr> a change in Nixpkgs broke a lot of boot configuration except the basic ones :(
<Cadey> oh no
<samueldr> probably not an issue for nixos-rebuilding into a fresh generation though
* colemickens isn't even sure what doing a nixos-rebuild on it will do right now given the state of the bootloader installer
<colemickens> plus it will still try to generate an initrd?
* colemickens gets back to work on upstreaming that
<samueldr> don't know!
<samueldr> I don't know what issue you have in mind
<samueldr> but that image should be u-boot based
<samueldr> the issue I have in mind is the initrd modules list
<samueldr> which, annoyingly, breaks a crucial assumption
<samueldr> before the change, any module not found was warned-and-skipped
<samueldr> now it fails
<samueldr> except it uses a list, which in nixos options you cannot remove from
<samueldr> so if you include a profile that adds a module that is not present, now it fails
<samueldr> which is why it fails
<colemickens> yeah but if the channel updates and you nixos-rebuild, it's going to have those new modules that will cause fialure?
<colemickens> the same modules causing the current hydra fails?
<samueldr> it's because of an installer profile
<samueldr> your system rebuild shouldn't import those
* colemickens groans
<colemickens> okay
<colemickens> I guess that makes sense.
<colemickens> And is why as soon as I get done with this, I'm going to send a PR to nixos-hardware, so we can start pointing folks there.
<patagonicus> And since that's in a module and not in a package you also can't easily disable it in an overlay, right? I've fixed it for myself for now by manually changing the flag back, but I wanted to try to get away from patching nixpkgs and using overlays instead …
<colemickens> I think you basically have to mkForce override the entire list of modules.
<samueldr> patagonicus: pretty much yeah
<colemickens> or at least that's what I've been doing.
<samueldr> and yeah
<patagonicus> :/
<samueldr> and you can'y "mkForceFromPrevious (previous: /* here filter things out */"
<samueldr> can't*
<samueldr> colemickens: my main issue with nixos-hardare and pi is... what do you include in there?
<samueldr> mainline? foundation?
<samueldr> foundation sucks
<samueldr> mainline is incomplete
<samueldr> "incomplete"
<samueldr> if you want to use dtbo for random widgets made with the foundation kernel in mind
<samueldr> then, similarly, which bootloader?
<samueldr> that's not something that should be part of nixos-hardware!!
<colemickens> pffft
<colemickens> sorry, I let out my gut reaction
<colemickens> idk, maybe both!
<samueldr> imagine if importing dell-whatever forced grub on you!
<samueldr> but then foundation dtbo nonsense generally works better with config.txt
<samueldr> which also implies a bigger boot partition
<patagonicus> We could make that behavior depend on a config setting, couldn't we? I think I could make a PR for that, unless I'm missing something and it's not possible.
<colemickens> samueldr: I'm okay with it being piece-meal and well-documented and letting hte user choose
<samueldr> which we don't do
<colemickens> samueldr: honestly I just want this _Somewhere_ _documented_ not on someones blog
<samueldr> that's the issue, imo: document what!
<samueldr> the pi has a serious split personality
<samueldr> is it the foundation kernel machine, or the mainline-based machine?
<samueldr> and people will have assumptions for either of those
<samueldr> that's something that really stopped me from doing any documentation about it
<colemickens> I don't think that's an insurmountable problem to document around
<samueldr> there's a lot of upfront explanation that is hard to grasp
<edrex> samueldr Re: "mainline is incomplete" just talking about the pi4? I just installed with mainline on a pi3 so curious
<colemickens> and/or I dgaf about the foundation kernel and thus am unmotivated to document out that scenario :P
<samueldr> edrex: see the follow-up, it's about the dtbo for random hardware gizmos
<samueldr> edrex: you can't apply those on top of mainline
<edrex> i mean, it's incomplete in that the mesa driver sucks, but that's the same as for foundation afaik
<samueldr> yeah, I really was pointing out a foundation/mainline split here :)
<samueldr> that the dtbo for misc. hardware people get that are "in the open source ecosystem" of the foundation vendor stuff
<samueldr> that they won't work on mainline
<edrex> oh, ic
<colemickens> I guess I'm willing to sign up for documenting how to go from a blank rpi4 SD card + USB stick to having a functional, full computer, nixos-rebuild-at-will normal computer (that happens to be an rpi4)
<samueldr> colemickens: fwiw, I totally approve of mainline-first docs
* colemickens nods
<colemickens> frankly I'm just not qualified to try to speak on the other stuff anyway (I still don't have early boot hdmi working with mainline, but I also haven't tried)
<samueldr> but I think there should be caveat / warning somewhere linking to a lengthy rant^W explanation of the split from the vendor ecosyste
<samueldr> ecosystem*
<samueldr> (hands: please work together!)
<colemickens> for sure, agree, good to document what is undocumented too, so people know where to continue researching
<samueldr> ecosystem
<samueldr> oops
* colemickens was so naive, the rpi4 has been out so long, I would've guessed "foundation kernel" would be a relic by now.
<samueldr> it never became a relic for the previous boards because of that vendor lock-in
<samueldr> I still expect half people with a pi will end up wanting to run a random hardware thingy that requires an overlay that won't work with mainline
<colemickens> ah, wow. that's unfortunate.
<colemickens> like, really unfortunate for everyone
<colemickens> :/
<samueldr> imagine just using one of those fancy displays with touch
<samueldr> that can't happen with the mainline kernel as-it-is
<samueldr> (sure, you can do the legwork to make it work, it's likely there are drivers for it in mainline)
<samueldr> but no easy "just add water" where water is the dtbo
<samueldr> same for hats with device tree overlay described on a chip!
<colemickens> So, at least maybe in theory motivated communities could flesh out a better set of dtbo's for mainline.
<samueldr> no
<samueldr> in fact that's going backwards
<samueldr> imo the error is that mainline "owns" the "golden" device trees that will work with mainline
<samueldr> it should rely on vendor device trees and fix things *with kernel overlays*
<samueldr> well
<samueldr> in-kernel device tree overlays
<samueldr> the raspberry pi 4 firmware will load and apply dtbo *by itself* when HATs include the appropriate hardware
<samueldr> which is amazing!
<samueldr> that's exactly what device trees were designed to do!
<samueldr> but you can't use any of that with mainline
<colemickens> (just a warning, we're already veering over my head for what I understand dtb-wise, just so you know how much to invest here ;)
<samueldr> basically, the kernel decided it must own the hardware description of every aarch64 DT boards
<samueldr> and vendor DTs may or may not work
<colemickens> It's unclear to me if there's even a clean, agreed separation on how the pieces are even supposed to work, heh.
<samueldr> imagine if the kernel had to implement its own ACPI table for every laptop there is out there
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> but worse, imagine if the kernel expected you to load its own ACPI table it wants, without doing it itself
<samueldr> because that's what happens, as I understand it, with device trees
<samueldr> (oh, and I'm also mad because currently I have to deal with more nonsense caused by the ownership of device trees)
<samueldr> (and working with pieces that all assume other pieces will do the work)
<samueldr> see, the kernel wants a `/memory` node, that is assumed to be added by the bootloader
<samueldr> fine, u-boot does it
<colemickens> someone should really make a new simpler standard (/jokes, just jokes)
<samueldr> kexec --dtb=... # will load the dtb as-is for the next booting kernel
zupo has joined #nixos-aarch64
<samueldr> there won't be a `/memory` node
<samueldr> kexec itself has no facilities to forward the node over
<colemickens> lol
<colemickens> seems like a huge oversight
<samueldr> yes
<colemickens> or justifies a proper "linuxboot" I guess that is closely tied to kexec then? (I know there's already some sort of linuxboot project...)
<samueldr> so now I have to do something that takes the currently booted FDT, forward a few properties into a temporary copy of the dtb, which in turn will be booted from
<samueldr> oh
<samueldr> I could see if linuxboot even attempts to fix that
<samueldr> because as I've seen, everyone seems to assume some other piece will do the work
<samueldr> right, linuxboot doesn't have "supported" ARM boards
<samueldr> and AFAICT doesn't do device tree with OPENPOWER?
<samueldr> >> Graphics init and PCI Device Tree enumeration are already part of the linux kernel. System Management Mode can be integrated as well. ACPI table generation is currently not supported and should be done by the firmware instead.
<samueldr> it's about ACPI
<samueldr> but I assume the answer would be the same for DT
<samueldr> "should be done by the firmware instead"
* samueldr sighs
<colemickens> there are some hits for "device tree" in the source code? that look promising to a very naive Cole.
<samueldr> I'm thinking that this stage-0 for mobile nixos will be the best featured linux-based bootloader soon :(
<samueldr> colemickens: none AFAICT from github search
<samueldr> oh
<samueldr> I mixed petitboot and linuxboot right now
<samueldr> sorry
* samueldr looks at petitboot
<samueldr> ah!
<samueldr> petitboot does device tree things
* samueldr clones
<colemickens> !
<samueldr> building arguments for exec in C
<samueldr> name a more dynamic duo
<samueldr> at the very least they're not shelling out
<colemickens> uggh I'm going to have to test if my extra uboot patches were really necessary :(
<samueldr> alright, so nothing about --dtb and memory nodes in petitboot
<samueldr> and nothing I can see about forwarding nodes
monk has left #nixos-aarch64 ["Error from remote client"]
<colemickens> samueldr: not to tell you your business, is it worth pinging them?
<colemickens> but*,
<samueldr> engaging with mailing lists is... ugh
<samueldr> especially to ask "hi, I'm not using your thing, and I can't see if you do thing X, which you should probably do, but I don't even know"
monk has joined #nixos-aarch64
<samueldr> great, I think I found a strategy that doesn't involve writing C code or binding to an unergonomic library
<samueldr> (echo '/dts-v1/;'; fdtgrep --include-node "/memory" ./firmware.dtb ; fdtgrep --include-node "/" "serial-number" "local-mac-address" ./firmware.dtb) | dtc -o test.dtbo -O dtb
<samueldr> (not sure yet it's a valid overlay)
<samueldr> but it does compile to a dtb file, and decompiles to the expected
<samueldr> ugh, there might be an issue with one of the values, but that's something to look at later
<colemickens> to be clear, we're okay with switching from rpi4 -> latest in the interest of eliminating the rpi4 image, yes? we're not worried about "breaking"? (again, maybe it just doesn't matter, since we don't really tell people to include that installer module...)
<colemickens> and then I guess that wouldn't get backported, so we wouldn't need to worry about _latest being new-enough anywhere.
<samueldr> the rpi4 image, every time I was involved with it, was clearly advertised as being temporary
<samueldr> removing it from stable branches on forking
<samueldr> there are no stable branches with that temporary image
<colemickens> cool
<samueldr> it was all about getting a trustworthy image from hydra to get yourself started
<samueldr> instead of doing qemu-user stuff
<samueldr> (which in the end so many users seem to prefer :/)
<colemickens> oh I'm going to be blocked on this anyway due to the modules thing
<colemickens> oh well, I'll still get it ready
monk has left #nixos-aarch64 ["Error from remote client"]
<samueldr> might not be
<samueldr> if the mainline image still builds right
<samueldr> nice! the totally lazy way of applying that "overlay" through the CLI seems solid enough
<samueldr> so I guess I'm now writing some ergonomic tooling around that
<colemickens> draft here for just the u-boot part: https://github.com/NixOS/nixpkgs/pull/112677
<{^_^}> #112677 (by colemickens, 16 seconds ago, open): nixos rpi bootloader: install files for raspberry pi 4 (rpi4)
<colemickens> I need to rebuild without my extra u-boot patch, then I'll mark it ready.
<colemickens> There is a question in there about a fixup for older pis (but hasn't been necessary, so might be a pi4 difference)
<samueldr> answered in the PR
<samueldr> it's all about how there is already an FDT in-memory when u-boot boots
<samueldr> I'm not even sure who between the pi firmware and u-boot applies the dtb files we're copying over
<colemickens> also, less interesting, but maybe interesting to someone -> rpi4uefi+grub: https://github.com/NixOS/nixpkgs/pull/112681
<{^_^}> #112681 (by colemickens, 20 seconds ago, open): nixos boot rpi: add rpi4uefi+grub as rpi4 bootldr
<samueldr> with the pi 3, uefi was good
<samueldr> but still had the issue of ownership of the DTB files
<colemickens> I still don't understand if I should be able to plop the mainline dtbs here and expect it to still work.
<colemickens> I might try that for funsies.
<samueldr> a wild guess indeed
<samueldr> colemickens: mind marking the uefi one as draft?
<colemickens> I'm sorry, I don't think you can retroactively
<samueldr> yes you can :)
<samueldr> (did it)
<colemickens> oh hey, cool.
<colemickens> thanks
<samueldr> convert to draft
<samueldr> it wasn't always possible though
<colemickens> yeah, thanks for pointing it out, I wouldn't have looked ther
<samueldr> oh, colemickens, thing about documentation: if you are using the generic sd image, you *should not* use the raspberrypi.u-boot options
<colemickens> samueldr: anything I was writing was going to be clear about having separate install/target media
<colemickens> like with a regular nixos install
<samueldr> the distinction is quite important
<colemickens> there's someone on Discourse trying to inplace convert to GPT and it just sounds like a hassle compared to grabbing one more SD card or one more jump drive.
<samueldr> the sd image's FAT32 partition will be too small for using this
<samueldr> as AFAIUI this forces the u-boot install to live at /boot
<colemickens> yes
<samueldr> still, in my opinion, this shouldn't be done, we should prefer making an opaque blob that coincidentally is a FAT32 partition
<samueldr> and holds the firmware data, while NixOS' boot data is either on its own boot partition, or in the main partition
<samueldr> but this already exists, and is used
<samueldr> so it's not like we can really break user's setup
<samueldr> *and* there is no trivial way to install u-boot on a foreign drive as an opaque blob yet (for any platform)
<colemickens> can you specify why ou mean by "foreign drive as an opaque blob"
<samueldr> foreign drive: not the drive you booted from
<samueldr> opaque blob: not treating it as a discrete filesystem
<colemickens> Is that a one-time setup then, that you envision?
<colemickens> Or something that gets re-applied on rebuild?
<samueldr> u-boot is the bios
<samueldr> that's my opinion on things
<colemickens> yeah but there's the real world where users are going to want u-boot updates
<samueldr> it just turns out that for the pi family of devices, it's a FAT32 partition
<samueldr> really, the future would be a common interface to update u-boot on all boards
<colemickens> But I guess that answers my quesiton
<colemickens> but still, as a sort of manual thing, more akin to fwupdmgr updates, rather than daily nixos updates or whatever
<samueldr> yes
<samueldr> it should not be tied to generations
<colemickens> yeah
<samueldr> you cannot boot into your previous u-boot
<colemickens> that makes the bootloader infra of stuff "just work" too.
<samueldr> really the bigger picture issue is: boards that use the storage for their bios suck badly
<samueldr> it makes this harder to reason
<samueldr> when it's "somewhere else", e.g. SPI flash, things are much less cumbersome to deal with
<samueldr> no magical offset
<samueldr> the board just boots
<samueldr> (or doesn't, but let's assume the installed firmware boots and is valid)
<colemickens> well, using storage and using a magic hardcoded offset in storage are different even :P
<samueldr> yes
<samueldr> and both harmful for different distinct reasons!!
<samueldr> magic offset, sometimes impossible to represent as a discrete partition, might be accidentally written over
<colemickens> ah ok
<colemickens> yeah
<samueldr> discrete partition, you're tempted to poke into it and manage it... and you can't "just flash it on top of the image"
<samueldr> it needs to be in the partition table too!
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
zupo has quit [Quit: Textual IRC Client: www.textualapp.com]
orivej has quit [Ping timeout: 256 seconds]
<colemickens> random, another idea I've had: combine sdcard and netboot so that we can boot to ram and then install on the boot media
<colemickens> I think 4gb of ram should be plenty enough for that anyway
<samueldr> but there's the raspberry pi with only 1 GB!
<samueldr> but no need to go all netboot
<samueldr> squashfs from the usb media would work too
<samueldr> with copytoram