#archlinux-ports | Logs for 2026-11-03
Back
[00:01:33] -!- rossy has quit [Remote host closed the connection]
[00:02:30] -!- rossy has joined #archlinux-ports
[00:14:25] -!- ubitux has quit [Ping timeout: 266 seconds]
[00:15:00] -!- ubitux has joined #archlinux-ports
[02:18:46] -!- h|weechat has quit [Quit: WeeChat 4.10.1]
[02:21:37] -!- h|weechat has joined #archlinux-ports
[02:45:29] -!- jclsn has quit [Ping timeout: 247 seconds]
[02:47:38] -!- jclsn has joined #archlinux-ports
[02:54:44] -!- linkmauve has quit [Remote host closed the connection]
[03:02:58] -!- linkmauve has joined #archlinux-ports
[04:39:12] hcmb is now known as Guest5736
[04:39:12] -!- hcmb_ has joined #archlinux-ports
[04:39:12] -!- Guest5736 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
[04:39:12] hcmb_ is now known as hcmb
[04:43:30] -!- hrdl has quit [Remote host closed the connection]
[04:45:32] -!- hrdl has joined #archlinux-ports
[05:47:39] -!- greyltc has quit [Remote host closed the connection]
[05:50:12] -!- greyltc has joined #archlinux-ports
[08:18:32] -!- julemand101 has quit [Quit: WeeChat 4.10.2]
[08:18:54] -!- julemand101 has joined #archlinux-ports
[08:19:40] -!- nl6720 has quit []
[08:20:58] -!- nl6720 has joined #archlinux-ports
[08:32:00] -!- alkersan has quit [Quit: Connection closed for inactivity]
[09:12:09] -!- drathir_tor has quit [Remote host closed the connection]
[09:15:54] -!- drathir_tor has joined #archlinux-ports
[09:20:33] -!- drathir_tor has quit [Ping timeout: 247 seconds]
[09:20:54] -!- drathir_tor has joined #archlinux-ports
[11:09:38] -!- drathir_tor has quit [Remote host closed the connection]
[11:12:59] -!- drathir_tor has joined #archlinux-ports
[11:18:06] -!- drathir87 has joined #archlinux-ports
[11:20:37] -!- drathir_tor has quit [Ping timeout: 247 seconds]
[11:20:38] drathir87 is now known as drathir_tor
[12:02:02] -!- fermino has quit [Quit: ZNC - https://znc.in]
[12:03:26] -!- fermino has joined #archlinux-ports
[12:03:26] <solskogen|M> Jesus
[12:03:48] <solskogen|M> alkersan: Ofc. What for? If you have a PR or a diff, I'd take a look.
[12:06:55] -!- lynxy has quit [Remote host closed the connection]
[12:10:30] -!- lynxy has joined #archlinux-ports
[12:24:06] -!- fermino has quit [Quit: ZNC - https://znc.in]
[12:27:34] -!- fermino has joined #archlinux-ports
[13:11:37] -!- alkersan has joined #archlinux-ports
[13:36:39] <alkersan> solskogen|M: no need, I've found a way with the existing linux-rpi5 package. If UKI is made with ukify - it will detect that it's compressed and unzip it during assembly.
[13:38:29] <alkersan> how about the u-boot? I have a working build of it and a draft pkgbuild here https://github.com
[13:38:30] <phrik> Title: arch-rpi5/mkosi.packages/uboot-rpi5/PKGBUILD at main · alkersan/arch-rpi5 · GitHub (at github.com)
[14:26:56] -!- h|ignition has quit [Ping timeout: 274 seconds]
[14:28:31] <solskogen|M> Personally I have no need for it, but if it's tested and it works I'll gladly put it in the forge repo
[14:28:36] -!- h|ignition has joined #archlinux-ports
[16:03:29] -!- solsTiCe has quit [Quit: The Lounge - https://thelounge.chat]
[16:05:10] -!- solsTiCe has joined #archlinux-ports
[16:16:30] <alkersan> that would be nice
[16:17:56] <alkersan> I've simplified the pkgbuild to the bare minimum, it just adds the rpi5 usb/nvme patch on the top of latest 2026.10 uboot release, and stores it in /usr/lib/u-boot. No hooks, not post install, that all may or may not be sorted out later
[17:25:42] <solskogen|M> have you tried our normal kernel with it?
[17:27:38] <alkersan> normal kernel is ?
[17:34:10] <alkersan> well, from u-boot perspective the is not much difference - it will boot anything that looks like a proper kernel (using booti method), or if it's a kernel with EFI_STUB it will boot it too (using bootefi method)
[17:36:18] <alkersan> do you mean linux-7.2.14 from the core?
[17:50:05] <solskogen|M> Yes. As in the non-pi kernel :-)
[17:51:37] <alkersan> I'll try. For that i'll need dtbsync, right?
[17:52:49] <solskogen|M> I have no idea
[17:53:13] <solskogen|M> I don't use that on my Orion
[17:59:22] <clover|M> Alkersan: dtbsync is useful when not using uboot, since it will keep the dtb in the efi partition up to date automatically when you update linux(-dtbs)
[18:00:22] <alkersan> well not so simple for rpi5. There is a first stage bootloader, that is quite picky to what should be found in the first FAT32 partition
[18:01:51] <alkersan> so, as a simplest test - i'll just copy bcm2712-rpi-5-b.dtb to the root
[18:05:58] <alkersan> ah, I see now. Dtbsync will do just that
[18:07:08] <alkersan> clover|M "dtbsync reads /sys/firmware/fdt" - is this hard requirement? As i'm building the image on an x86 pc - can it be told exactly what to copy?
[18:11:27] <clover|M> It should find the dtb at runtime via /sys/firmware/fdt
[18:11:27] <clover|M> if you are building an image just copy it over manually?
[18:12:06] <clover|M> dtbsync is just a convinces when updating your linux packages so you dont have to cp from usr/lib/modules to /boot or whatever
[18:12:13] <clover|M> Convenience*
[18:13:26] <clover|M> That reminds me i need to update it for zig 0.17 :)
[18:13:44] <clover|M> I might wait until 0.17.1
[18:25:02] -!- ismailarilik has joined #archlinux-ports
[19:04:49] -!- iwuvmika has quit [Ping timeout: 243 seconds]
[19:06:37] -!- ismailarilik has quit [Quit: leaving]
[19:06:52] -!- ismailarilik has joined #archlinux-ports
[19:12:21] <alkersan> nope, vanilla kernel didn't work. It's seems a little bit alive, and even reached systemd in the initrd, but still didn't get to OS
[19:12:28] <alkersan> captured logs https://gist.github.com
[19:12:29] <phrik> Title: rpi5-linux-7.2.14 · GitHub (at gist.github.com)
[19:16:54] -!- ismailarilik has quit [Quit: leaving]
[19:18:34] -!- ismailarilik has joined #archlinux-ports
[19:30:19] -!- drathir_tor has quit [Ping timeout: 247 seconds]
[19:31:40] -!- drathir_tor has joined #archlinux-ports
[19:37:05] -!- bschnei has quit [Read error: Connection reset by peer]
[19:37:18] -!- bschnei has joined #archlinux-ports
[19:47:48] <alkersan> that's probably due to missing modules
[20:13:53] -!- titus_livius has joined #archlinux-ports
[20:30:28] -!- drathir_tor has quit [Remote host closed the connection]
[20:32:49] -!- ismailarilik has joined #archlinux-ports
[20:37:59] -!- ismailarilik has quit [Ping timeout: 269 seconds]
[20:38:21] -!- drathir_tor has joined #archlinux-ports
[20:46:34] -!- ismailarilik has joined #archlinux-ports
[20:54:25] -!- ismailarilik has quit [Ping timeout: 244 seconds]
[21:17:28] -!- iwuvmika has joined #archlinux-ports
[21:41:31] -!- marmis7 has joined #archlinux-ports
[21:43:51] -!- marmis has quit [Ping timeout: 271 seconds]
[21:43:51] marmis7 is now known as marmis
[21:51:02] <alkersan> with these modules "reset-brcmstb reset-brcmstb-rescal rp1-pci clk-rp1 pinctrl-rp1" it booted from NVME
[21:51:28] <alkersan> also, it seems getting mad at "CONFIG_ARM_PSCI_CHECKER" in the vanilla kernel, thus used initcall_blacklist=psci_checker to suppress it. Otherwise, it only single core was reported to be online
[21:54:12] <alkersan> with added "usb-storage uas" modules, expectedly, boots also from USB
[21:59:02] -!- marmis has quit [Quit: Bye!]
[22:00:38] -!- marmis has joined #archlinux-ports
[22:36:30] <alkersan> so, it seems that mainline kernel is already usable, as for a headless server at least
[22:49:01] <bschnei> alkersan: have you looked into whether you can leverage OF_CONTROL in U-boot to embed the dtb into the u-boot image itself for the pi5? https://docs.u-boot.org
[22:49:02] <phrik> Title: Devicetree Control in U-Boot — Das U-Boot unknown version documentation (at docs.u-boot.org)
[22:49:57] <alkersan> as far as I understand - that isn't good idea on rpi, as their own bootloader interacts with it quite somehow
[22:51:44] <alkersan> it parses the "config.txt" first, applies various tweaks, dt overrides, assembles kernel cmdline args, etc... and all that it passes to the "kernel.img", which in this case is u-boot, which in turn passes that down the line
[22:56:13] <bschnei> Ya you've pushed it further than I have. I didn't test it because I also saw all the .dtbo overlay files laying around and if you need to manage those files on disk then there is not much upside to eliminating just the .dtb from that mess of files you still have to deal with :/
[22:57:08] <alkersan> well, there is a possibility to disable that - https://www.raspberrypi.com
[22:57:30] <alkersan> but I'm not sure if its' a good idea in general
[22:58:36] <bschnei> This is why linux-rpi5 is what it is today. It works with the factory bootloader directly which means it also has to deal with all the device tree files. The original intention was that it would Just Work out of the box without the need to experiment with edk2/u-boot etc as a shim. Though there are definitely some advantages to having a shim in there...primarily in the form of UEFI support
[23:02:37] <alkersan> well, it does work, in some sense. Just not a very arch/systemd way.
[23:04:47] <alkersan> the few missing UAPI related things are hardly can be called critical: the automatic discovery of esp/root, auto resize on first boot. What else?
[23:10:19] -!- titus_livius has joined #archlinux-ports
[23:41:00] -!- moxie has quit [Quit: WeeChat 4.10.1]
[23:42:15] -!- moxie has joined #archlinux-ports