<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
<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>
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…]
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. -_-
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.
<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>
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>
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]