<colemickens>
that way users can "do a normal install" and just activate boot.loader.raspberrypi.uboot and things mostly work, and then I've tried to align the options there with what the sd-image-aarch64.nix sets for config.txt.
<colemickens>
I am even placing the dtb next to u-boot as you can see in that commit,
<samueldr>
really, I'd like to delete the boot.loader.raspberrypi.uboot stuff, and *then* figure out a good universal scheme to own the firmware configuration
<samueldr>
"owning" the firmware configuration here meaning with u-boot, NixOS-managed installation
<colemickens>
I assume I don't know it as intimately as you but throwing out all of it seems aggressive, the core bits around installing u-boot seem like a useful starting point
<samueldr>
I mean the whole option set
<samueldr>
not necessarily the methodoloy
<samueldr>
methodology*
<colemickens>
mm I see
<samueldr>
I don't care really how it's installed, but it shouldn't be a raspberry pi specific thing
<samueldr>
and it should be used to produce the sd image
<samueldr>
since, as you observe, it's drifted already
<colemickens>
You helped fill in the gaps for why we don't use it though, and the aspiration makes 100% sense to me.
<samueldr>
we don't use... not for those reasons I think
<samueldr>
I think the reason would be because it was implemented by someone else, or separately from the sd image generation
<samueldr>
and there's still the issue of config.txt configuration
<samueldr>
which *that* is another thorny bit, which really I'm not sure NixOS should manage
<colemickens>
I was trying to imagine something generic enough that nixos-hardware could come along and configure it with "extras" like config.txt.
<samueldr>
(1) there is no generation support for that [u-boot install either]
<samueldr>
(2) it's really more like changing a bios option
* colemickens
nods
<samueldr>
sure, nixos-rebuild can change it, but it makes it the new value for every generations
<samueldr>
I think it's one step too far to want to have NixOS manage bios options
<samueldr>
not that I don't want it, but because it's impractical
<samueldr>
mainly because of the generations issue
* samueldr
thinks
<samueldr>
if I were to produce a "super u-boot", with pc-firmware-like menus, the rasbperry pi version would have an additional menu to twiddle and fart around with config.txt options
<samueldr>
should overclock options be part of your nixos configuration.nix, or not?
<samueldr>
in a perfect world, yes, as in a perfect world your laptop's firmware would be aware of generations and load the profile with the generation
<samueldr>
but since that's not a thing really, that's not applicable
<samueldr>
still, this is really only my opinion
<colemickens>
to be fair this is true of all of our bootloaders, though, no?
rajivr has joined #nixos-aarch64
<samueldr>
kind of
<samueldr>
the bootloader "image" (e.g. .efi program) is sitting at the cusp
<samueldr>
the bootloaders are *configured* in a generation-aware manner
<samueldr>
mainly
<samueldr>
the bootloader "image", itself, isn't
<samueldr>
(continuing) and as I'm too busy to do things (but not busy enough not to gripe) anyone doing anything else I wouldn't stand in their way, even if it doesn't fit my vision
<samueldr>
but I would much rather they hear and understand my concerns before they continue, and if they continue understanding the issues, well more power to them
<colemickens>
Isn't that the same as u-boot being "the image" and it itself being generation aware via extlinux generations ?
<colemickens>
at least, in my head it seems like it is?
<samueldr>
a bit similar yeah, that's why "owning" u-boot into the nixos config is fine enough
<colemickens>
but I understand, in this case, it's a bit weird that we try to control config.txt from "inside" a generation
<samueldr>
it's a bit fuzzy because of how u-boot straddles between BIOS-like functions and bootloader functions
<samueldr>
thouhg, one thing I want to see go away are the vendor-specific options that are kind of incompatible with the other methods
<samueldr>
in my personal opinion, we shouldn't upgrade u-boot automatically
<samueldr>
since it's more of a bios-like thing
<samueldr>
but we should provide configuration and tooling to make it trivial to do so
<samueldr>
like `nixos-update-firmware` or something like that
<samueldr>
and similar to bootloaders, keep a stateful variable to stop the rebuild process if it is incompatible (where bootloaders installs automatically)
<colemickens>
hm, that seems like a lot :)
<samueldr>
how?
<samueldr>
it sounds like a lot, but really it's similar to bootloaders, except we never update it automatically
<samueldr>
or even there could be a default = false; option to do update it automatically
<samueldr>
and the bootloader image, already, it's not being updated automatically unless strictly needed
<samueldr>
so really it probably could work the same exact way and be fine enough
<samueldr>
though there is that issue where the raspberry pi's firmware config (config.txt) is part of the firmware "image", so it's not as simple as updating the firmware
<samueldr>
as users could have customized it
<samueldr>
which is maybe part of the reason to do this inside the nixos config
<samueldr>
really it would be easier if u-boot didn't, at all, support booting linux
<samueldr>
and instead always used an external program
<samueldr>
(e.g. grub)
<samueldr>
it would be much easier to get the distinction
<colemickens>
I didn't mean it as a negative or any thing like that. It just seems like a bit to do everything you're talking about. Especially compared to me just trying to hack it enough to work.
<samueldr>
oh, right, where is u-boot even installed??
<samueldr>
here I was thinking on storage
<samueldr>
but that's like the least nice way
<samueldr>
really u-boot should be on a dedicated area, like an SPI flash
<samueldr>
so at that point is there any point at "owning" that u-boot install?
<samueldr>
yeah, I'm also thinking out loud
<samueldr>
it's something that really needs to be looked at, but the solution is much much much more nuanced than it seems at first
<samueldr>
and really needs to consider "u-boot platforms" as a whole, and not "raspberry pi"
h0m1 has quit [Ping timeout: 265 seconds]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
<craige[m]1>
Thanks angerman - I'd seen the original rotary project but the kit was a new thing. I'm in 😀
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
superherointj has quit [Client Quit]
cole-h has quit [Ping timeout: 240 seconds]
Acou_Bass has quit [Read error: Connection reset by peer]
Acou_Bass has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
rajivr has quit [Quit: Connection closed for inactivity]
alpernebbi has quit [Quit: alpernebbi]
<LinuxHackerman>
red[evilred]: are you in the discord as well?
<Ke>
linus.heckemann: I am wondering, if the debug image you use should boot from sd or spi
<LinuxHackerman>
yeah, I'm surprised that it would matter though
<Ke>
so did you get it working from the proper media?
<LinuxHackerman>
I've been doing everything from SD so far
<Ke>
I would respond @there, but my client here is much more comfortable
<LinuxHackerman>
perfeclty fine by me. The less I use discord the better :D
<Ke>
in theory I could bridge matrix to discord, but might get banned
<Ke>
yes, I'll also use SD, until we get the EFI with the smmu support
<Ke>
some kernel patches also needed
<LinuxHackerman>
I do want to try SPI though, that's probably what I'll do next
<Ke>
it's a nice place to keep the consolidated bootloader, but doing recovery for a bad one requires physical poking obviously
<Ke>
I have already closed the case
<Ke>
still 4 components missing 2 of them I would need to 3d print and one design
<Ke>
I am not happy at all with the loose cooler
<samueldr>
for rockchip platforms, it matters how the final binary image is made, whether it will run on SPI or from mmc
<samueldr>
so I guess it could matter there too
<samueldr>
though AFAIUI the build itself is the same, it's more about how the final pieces are assembled
<LinuxHackerman>
Yeah, but it's definitely an SD image I built
<LinuxHackerman>
The only difference is debug vs release — in tianocore, i.e. after the point where that should matter
<LinuxHackerman>
(the difference is in the build of arm-trusted-firmware)
<Ke>
the spi is at least 64M, though obviously before raminit there is only sram
zupo has joined #nixos-aarch64
<Ke>
samueldr: anyway jnettle confirmed that currently the EFI image is built to run from either spi or mmc
<samueldr>
good to know
<Ke>
generic image will probably possible in the future, as it was possible before
<colemickens>
I wound up with a new strategy. I use Grub2 and use "extraFiles" to install the rpi4uefi binaries :)
<colemickens>
It boots the kernel, and I can see ZFS module load, but it still can't find my pool? So strange.
<colemickens>
I think this same strategy might work with u-boot+grub. I might try that today while trying to figure out what the deal is with the usb/zfs rootfs
<colemickens>
alright, same story with u-boot. I can get u-boot to load grub, grub boots kernel, initrd fails to mount my zfs pool. at least it's consistent?
<samueldr>
which bootloader is likely not going to matter much here
<samueldr>
but with EFI, *which* FDT is loaded for the kernel?
<samueldr>
and which kernel?
<samueldr>
by default, with u-boot, it keeps whatever was in used for u-boot
<samueldr>
which might not be what mainline wants (assuming mainline)
<samueldr>
IIRC the EFI codepath in u-boot allows loading an FDT
<samueldr>
BUT, it is only one FDT, not one FDT per generation
<samueldr>
so no way to have a pair of [FDT, kernel] like the extlinux compatible loader does
<samueldr>
colemickens: ^ if this ends up being true, this can load an FDT before loading an EFI program
<samueldr>
maybe it's related to your issue, maybe not
<samueldr>
but if you're mixing vendor FDT and mainline kernel, things may fail :(
<colemickens>
idk, I spent _all_ yesterday trying to get the raspberry pi uboot extlinux "loader" thing working like I'd described, and couldn't even get the kernel to load
<colemickens>
but I guess that jives with what you just said "which might not be what mainline wants"
<samueldr>
I had a thought recently about a way to solve this for EFI boot that could be implemented in a lesser or non-invasive manner
<colemickens>
The other thing is, when it's booting initrd, I see "usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd".
<samueldr>
u-boot could add an overlay to the FDT adding the field "u-boot,fdtfilename", or "linux,fdtfilename", which describes which filename from a defconfig build should be loaded
<colemickens>
so it seems like it even kind of sees the usb device?
<samueldr>
then an EFI program could read the FDT, read that filename, and load it
<LinuxHackerman>
oh yeah thefloweringash I've got lx2k uefi firmware building with nix, thanks for all the groundwork!
<colemickens>
(how do I access the dtbs from a mainline kernel? I can't remember what attribute/dir its in?)
<samueldr>
I believe it's in the same build output as the kernel itself
<samueldr>
I don't think we've had a "just build the dtb files" helper yet
<colemickens>
wrong window, yeah, I found where to copy it in the source derivation. If I use the mainline dtb nothing loads and uart output is gibberish
* colemickens
is kinda over it
<samueldr>
colemickens: if you use the mainline dtb where?
<samueldr>
as the pi-4.dtb file found at the root of the sd card?
<colemickens>
yes
<samueldr>
welp
<colemickens>
maybe that was wrong of me to try but I did :|
<samueldr>
I assumed it was a coin flip whether it'd work or not
<colemickens>
idk, maybe I need to try some other version of start4.elf since that seems to affect things at times ?
<samueldr>
you'd need to load the mainline .dtb after u-boot starts
<samueldr>
I *think* u-boot requires the vendor .dtb to init properly (which to me is hecking weird)
<colemickens>
I thought it seemed like u-boot was loading the dtb
<colemickens>
It "read" it at least and told me how many bytes it loaded
<samueldr>
AFAIUI u-boot first needs the .dtb file for itself
<samueldr>
(for the pi 4)
<colemickens>
based on what I read, that's what I understood too
<samueldr>
but once it initialized itself, it can load another one
<samueldr>
which is what I linked earlier would do
<colemickens>
similarly, rpi4uefi ships with it's own start4.elf and its own copy of DTBs that it needs to load with
<colemickens>
I wish u-boot were slightly more verbose about what it was doing
<samueldr>
you can build it with debug verboseness
<colemickens>
and I still don't get why uboot->grub->linux gets further than uboot(extlinux)->linux.
<samueldr>
but on some platforms it fails to boot due to messing timings :)
<colemickens>
alright, I might do that later
<samueldr>
I don't recall having a trivial to follow guide for that though
* colemickens
is tempted to just go buy a different SBC that has less hoops
* colemickens
isn't sure one exists at a similar power/price point
<samueldr>
depends what you want to do with it I guess
<colemickens>
sigh. at this point, make it a vpn gateway to a cloud hosted VM that my cat can't spill water on and is unlikely to have HW fail on me randomly.
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]