justanotheruser has quit [Ping timeout: 260 seconds]
rajivr has joined #nixos-aarch64
cole-h has quit [Ping timeout: 268 seconds]
cole-h has joined #nixos-aarch64
patagonicus183 has joined #nixos-aarch64
patagonicus18 has quit [Ping timeout: 245 seconds]
<elvishjerricco>
Good news, I tried `enableParallelBuilding = true;` for tow-boot, and it looks like it didn't break anything
<samueldr>
when it hit issues, it was an obvious build failure due to erroneous dependencies in the makefiles
<samueldr>
so either you were lucky, or it was fixed
<samueldr>
but the good thing is that it shouldn't cause weirdly broken builds
h0m1 has quit [Ping timeout: 250 seconds]
<elvishjerricco>
clever: If I wanted to mess around with helping to get log output, where should I start?
<clever>
elvishjerricco: lists_bind_fdt
h0m1 has joined #nixos-aarch64
<clever>
elvishjerricco: that function deals with parsing the DT that came in from the firmware
<clever>
elvishjerricco: it then calls driver_check_compatible to search all registered drivers, and load any it finds
<clever>
i think the root problem, is that this process is what enables the uart
<clever>
so the uart wont work until after this has finished
<clever>
cmd/log.c may let you recover the logs after the fact, but i didnt see how to turn it on yet
<elvishjerricco>
Oh right I was going to try bisecting the firmware real quick
<elvishjerricco>
But I don't have a known good commit so... where do I start?
<clever>
dumb idea, the first commit to introduce a start4.elf!
<elvishjerricco>
might as well :P
<clever>
it will definitely lack netboot support, but the eeprom should clearly tell you so
<clever>
you can just wrongly claim to bisect that its good (enough), and it will find the rest for you
<elvishjerricco>
So I'm at the last bisect step. So far, I've only encountered files that aren't new enough to even run, and files that exhibit the config.txt issue.
<clever>
there might also be files that can netboot on a pi4, but dont support the cm4
<clever>
a middle zone
<clever>
but the error wont tell you the difference
<elvishjerricco>
But with these last ones, the pi downloads start4.elf and fixup4.dat, says it's starting start4.elf, and then nothing happens.
<elvishjerricco>
Like no more tftp access
<clever>
i would classify that as good, because skip tends to be too slow
<clever>
it feels like is too old, and not detected as such
<elvishjerricco>
Well there's 0 revisions left to test after this one
<clever>
ack!
<clever>
you could throw a fat32 with config.txt and uart_2ndstage=1 onto the emmc, just incase its looking in the wrong place
<clever>
got a pi4 by chance?
<elvishjerricco>
I do not :/
<clever>
i should try the same bisect on mine
<clever>
its one of the original revs, so it should support any start4.elf
<clever>
oh right, and one other thing
<clever>
boot_load_flags
<clever>
if you add boot_load_flags=1 to config.txt, then you disable the "is it supported" check in the bootcode.bin
<clever>
so it will run unsupported start4.elf files
<clever>
those may ignore the netboot situation, and then load from the emmc
<clever>
which could still give some extra info
superherointj has quit [Quit: Leaving]
<elvishjerricco>
Well, I put a config.txt on an sd card and now things are very different.
<clever>
that would be the start4.elf debug logs, enabled by uart_2ndstage=1
<elvishjerricco>
figured
<elvishjerricco>
"No compatible kernel found"
<elvishjerricco>
I think it's looking at the sd card
<clever>
yeah
<clever>
genet is the name of the gigabit ethernet controller
<clever>
so lines 29-31 are it turning back on, after the previous stage stopped it
<elvishjerricco>
clever: It is still trying to netboot i think
<elvishjerricco>
because I put back kernel8.img on the tftp server and it changed behavior
<clever>
ah
<clever>
try repeating the bisect in that situation then?
<elvishjerricco>
Well the whole point of the bisect was to find one that didn't need a kernel8.img wasn't it?
<clever>
having logging is still useful
<elvishjerricco>
looks like this loaded kernel8.img, but shouldn't u-boot be outputting on serial, now that we got it to respect enable_uart=1?
<clever>
not exactly
<clever>
uart_2ndstage=1 is handled by the 1st stage (bootcode.bin)
<clever>
enable_uart=1 is handled by the 2nd stage
<clever>
but if the 2nd stage is loading kernel8.img, its not loading config.txt
<elvishjerricco>
ah
<clever>
there are 4 seperate passes thru different config files
<clever>
first, bootcode.bin (in spi flash), will parse bootconf.txt (also in spi flash), and do whatever those options say
<clever>
if booting from something with partitions (usb, sd), it will parse autoboot.txt, which can only have one config option, boot_partition=<int>
<clever>
the boot_partition parameter, re-directs which fat32 partition it uses for the next steps, so your config.txt + start4.elf can be on the 2nd fat32
<clever>
the 3rd pass, is bootcode.bin parsing config.txt for basic paramaters (start_file changes which .elf it loads), this pass does not support include statements
<clever>
all 3 passes, also support a range of conditional statements, like [pi3] or [gpio21=0]
<clever>
elvishjerricco: following so far?
<clever>
the 4th pass, is start(4).elf re-parsing config.txt, this time, with support for include statements
<clever>
the first 3 passes, all have a very clearly defined list of valid options, and ignore all others
<elvishjerricco>
sorry, stepped away for a min
<clever>
the 4th pass is more fuzzy, there is just a function to get a config entry, so listing them is tricky
<superherointj>
samueldr, is UEFI available on my RockPro64?
<samueldr>
superherointj: what do you mean here?
<samueldr>
if it's about virtualization, the board doesn't matter
<samueldr>
the "initial boot firmware" is handled by the virtualization system entirely
<samueldr>
if you want to know whether you can boot your board using UEFI
<samueldr>
yes you could
<samueldr>
but RK3399 has two known issues with U-Boot (and thus Tow-Boot) and mainline linux
<samueldr>
(1) rockchipdrm won't work if efifb is used, so you won't get the VT consoles
<samueldr>
(2) poweroff will hang
<superherointj>
On my workstation, I use virt-manager to connect to RockPro64 libvirtd server, it connects. But when I attempt to create a new VM, it sasys: "Warning: Failed to setup UEFI: Did not find any UEFI binary path for arch 'aarch64'. Instal options are limited."
<superherointj>
I think this might be related to lack of OVMF, or it being misconfigured?
<superherointj>
Libvirtd is referencing OVMF_CODE.fd not AAVMF_CODE.fd
<superherointj>
(On NixOS)
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr>
yeah, that's unrelated to the board
<samueldr>
if it's virtualization, it's independent
<superherointj>
Right.
<samueldr>
and you basically have it understood: it's because OVMF is not configured correctly somewhere for the UEFI firmware
<samueldr>
"poweroff hangs" is only if you *booted* the RK3399 SBC with UEFI with U-Boot (or derivative), and try to poweroff
<superherointj>
Is that poweroff hanguing issue a hardware issue?
<samueldr>
shouldn't be
<samueldr>
since poweroff works fine with the same software, but not running through UEFI
<samueldr>
and works fine with basically the same firmware/software combination, with UEFI on other SoC families
<superherointj>
I have manually patched the path to AAVMF, I think it worked.
* superherointj
is testing...
<superherointj>
If I get this right, this will be my first non trivial patch. I've come a long way since I first met you here. Do you realise you taught me to use GIT? :D
<superherointj>
(I bet you have forgotten.)
<samueldr>
I uh forgot... I don't remember teaching anyone git since I probably should have done due diligence and told them: DON'T GIT IS GOING TO RUIN YOUR LIFE ;)
<superherointj>
I still laught at the idea of having my hands sweating because of cherry pick.
<superherointj>
My first PR in Nixpkgs was a mess.
<superherointj>
Lately I've been able to fix/submit packages quite often. Just saying, I'm improving, thanks for the patience and kindness.
<elvishjerricco>
So I retried my bisect with `boot_load_flags=1`, and landed at the same "first bad" commit; I only ever saw start4.elf files that didn't try to net boot, or ones that did it wrong
<elvishjerricco>
Annoyingly, that commit is d5b8d8d, which doesn't say anything about netboot
<clever>
let me check around that commit...
<clever>
elvishjerricco: thats something like 20 commits after adding start4.elf, right??
<clever>
or is gitk messing up
superherointj has quit [Quit: Leaving]
HenrikK has joined #nixos-aarch64
Venom668 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<Venom668>
hello
<Venom668>
samueldr, have you managed to get suspend to ram working on mainline linux and u-boot with tf-a patch on rk3399?
<samueldr>
Venom668: not tested in depth, but on the PBP yeah
<walkah>
Can someone explain how to load dtbo files? (Specifically I’m looking to get rpi-poe working on my raspberry pi 4s)
<walkah>
As far as I can tell boot.loader.raspberryPi.firmwareConfig doesn’t update anything and mounting the FIRMWARE partition and hand-editing config.txt doesn’t seem to work either. But I can see the dtbo file is there (under /boot/nixos)
zupo_ has joined #nixos-aarch64
<clever>
walkah: the default on nixos, is that the firmware partition and config.txt are never used
<clever>
walkah: you instead pre-apply the overlays to a dtb within a nix build, and uboot loads the final merged result
<clever>
but there are some complexities to pre-applying them
<walkah>
Ahh, that makes sense… and I seem to be lost in the complexities
zupo has quit [Ping timeout: 240 seconds]
<walkah>
clever: I’ve read what’s on the wiki & nix.dev and something’s not clicking. Is there somewhere I can read up on how this is supposed to work?
<clever>
walkah: hardware.deviceTree.overlays is the default way to apply overlays
<samueldr>
walkah: there's still some things to figure out
<{^_^}>
nixos-hardware#262 (by samueldr, 5 days ago, open): Support for additional "dtparams" for Raspberry Pi
<samueldr>
the PR here shows how to apply a dtbo from the source files, which we have to do since the `compatible` string is checked
<samueldr>
and upstream doesn't actually fill that in correctly
<samueldr>
(or we don't check it correctly, maybe)
<samueldr>
it *also* shows how one could replace a "dtparam" with a NixOS option
<samueldr>
considering "dtparams" are not really a thing, they are something the raspberry pi foundation has done, but is not standard
<samueldr>
the issue, second link, is an open question about looking at other dtparam options
dev_mohe has quit [Quit: dev_mohe]
<samueldr>
BUT
<samueldr>
there may be some more complexity
<samueldr>
clever says that *some* dtparams options *may* also make the vendor firmware turn things on/off
<samueldr>
so it may be necessary to *also* change things in the config.txt file to make the hardware work if only changing the device tree isn't enough
<walkah>
I was looking at this PR earlier but it looked like this was adding new overlays … when the rpi-poe.dtbo file seems to be there just … not loaded
<clever>
i think the poe overlay wont do that
<samueldr>
walkah: it's re-implementing the overlay because of the `compatible` string not matching
<walkah>
Under raspian, these things “just worked” … no dtparams required
<samueldr>
it's basically a copy/paste of the dts for hte overlay
<samueldr>
I might have used the wrong terminology
<clever>
walkah: yeah, adding uboot into the mix is what broke a lot of the dt stuff
<samueldr>
I'm not exactly 100% familiar with the vendor ecosystem
<samueldr>
I meant overlays, maybe, for some uses of dtparams
<clever>
walkah: there are ways to switch a nixos install back to the non-uboot route, and i recently discovered something that would make that far simpler
<samueldr>
note that going non-uboot has issues, e.g. you won't really have generation selection
<samueldr>
and it can't load the files from the main partition
<clever>
so /boot must be on fat32
<samueldr>
and is an "unsupported" state, as we only "support" generic U-Boot based images for aarch64
<walkah>
But there’s already a fat32 partition here
<samueldr>
(but unsupported does not mean it'll be broken)
<walkah>
gotcha.
<walkah>
Well, I’m happy to test / try either way… i have a handful of rpi4’s with PoE hats that I’d love to have running nixos :)
<samueldr>
ideally it would be preferrable to make it work with the U-Boot-based boot flow since it means generations work
<walkah>
Yeah. That makes sense.
<clever>
walkah: the default setup, is that the firmware and uboot sit on a firmware fat32 partition, which never gets mounted or updated
<samueldr>
walkah: so basically you just dtoverlay=rpi-poe and it works, right?
<clever>
walkah: then an extlinux.conf, kernels, initrds, and dtb files, all live in the /boot dir of your rootfs (typically ext4)
<samueldr>
(in a vendor-ecosystem based setup)
<walkah>
samueldr: in raspian you don’t even need to do that…
<samueldr>
that's odd
<clever>
there is a hat eeprom on the board
<clever>
and the firmware auto-loads overlays on its own