dgilmore changed the topic of #fedora-riscv to: Fedora on RISC-V https://fedoraproject.org/wiki/Architectures/RISC-V || Logs: https://libera.irclog.whitequark.org/fedora-riscv || Alt Arch discussions are welcome in #fedora-alt-arches
<dgilmore> I get tht with qemu-system-riscv64
<dgilmore> get that
<dgilmore> using u-boot obviously
<dgilmore> ed2k gives
iooi has quit [Read error: Connection reset by peer]
iooi has joined #fedora-riscv
davidlt has joined #fedora-riscv
<davidlt> dgilmore, that looks a bit strange, as it should not attempt to use "qemu-riscv.dtb"
<dgilmore> davidlt: removing the ftddir line I get the same error
<davidlt> Regarding EDK2. 1st we would need to move to GRUB2 (especially the upcoming release), and switch kernel target too (most likely, to self uncompressed one).
<dgilmore> Either the dtb qemu provides is bad or something is missing in the kernel
<davidlt> It should be something like this:
<davidlt> We are living ARMv7 life were we need to adjust image for each target.
<davidlt> Hopefully that ends once we get RISCV Platforms specification done and ratified.
<dgilmore> Will try tomorrow
<davidlt> Yeah, so for the UEFI/EDK2 the things I would like: (1) enabling GRUB2 (2) switching kernel to the latest new target (common with aarcg64 too), which will depend on UEFI to uncompress itself.
<davidlt> Also new GRUB (2.12-rc ?) is needed for LoadFile2 support (to load initramfs stage for riscv64) IIRC.
<davidlt> You can technically boot U-Boot -> kernel EFI directly (that was tested many years ago)
<davidlt> systemd bootloader might be an easier option too :)
davidlt has quit [Ping timeout: 256 seconds]
davidlt has joined #fedora-riscv
jcajka has joined #fedora-riscv
fuwei has joined #fedora-riscv
<Esmil> davidlt: sd-boot works great, but you'll need to backport this for kernel-install to support adding devicetrees: https://github.com/systemd/systemd/commit/2bca841137833edeaf3779542d6475f0dc3aa5a7
<davidlt> Esmil, thanks for the heads up.
<davidlt> From what I understand sd-boot is a working alternative on Fedora (but I never attempted it myself).
<davidlt> In general this should be better than dealing with GRUB2 + 200-300 patches (each distro seems to have them).
<Esmil> i'm actually running it on all my boards except the TH1520 that doesn't have an efi-enabled u-boot as far as I can tell
<davidlt> Esmil, is that what Ubuntu defaults to?
<Esmil> no
<Esmil> :)
<Esmil> i wish
<davidlt> Why is that?
<davidlt> It should be a sane option (at least for riscv).
<davidlt> I don't really want to touch GRUB2 package because of those 200-300 patches. I did look once at them trying to figure out how many needs adjustment for riscv64.
<Esmil> i guess nobody did the work to test it and implement support for it in installers and such
<davidlt> It Fedora it works out-of-the-box, but the instructions on how to switch GRUB2 -> sd-boot are not that well marketed.
<Esmil> yeah, you can manually switch to sd-boot in debian/ubuntu too. it's just not the default
<davidlt> I would "love" to spend more time on this one, but it's probably multi-day or multi-week project.
<davidlt> UKIs are also incoming
<davidlt> Here are systemd-boot Change request for Fedora 39: https://fedoraproject.org/wiki/Changes/cleanup_systemd_install
<Esmil> davidlt: that reminds me. i tried installing the standard fedora kernel on my unmatched, but the vmlinuz is not efi enabled :(
<davidlt> Esmil, the kernel should be
<davidlt> But again, we don't use EFI (yet) thus I don't check it manually anymore (for a long time)
<davidlt> Yeah
<davidlt> Well we should switch to EFI bootflow, but that would require X days of native build time to polish up
<davidlt> Once I start Fedora 39 mass rebuild there will be no time for that
<davidlt> (at least not on my side)
davidlt has quit [Ping timeout: 245 seconds]
davidlt has joined #fedora-riscv
zsun has joined #fedora-riscv
<davidlt> experiments with toolbox: https://pastebin.com/HcfjkV2d
sajcho has joined #fedora-riscv
sajcho has quit [Quit: Client closed]
sajcho has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
sajcho has quit [Quit: Client closed]
<davidlt> mock-core-configs is building, mainly to allow using podman container for bootstrap_image
<davidlt> v6.5 RC7 kernel is cooking too for testing
<davidlt> binutils 2.41 is finally landing in f39 (just for riscv64)
<davidlt> still no new GCC 13 build
<davidlt> I also launched by f39 hybrid builder with mock v5.0 to give a proper test via Koji
<dgilmore> [root@ryac images]# virsh start fedora38-riscv64 --console
<dgilmore> Connected to domain 'fedora38-riscv64'
<dgilmore> Domain 'fedora38-riscv64' started
<dgilmore> Escape character is ^] (Ctrl + ])
<dgilmore> 0
dgilmore has quit [Excess Flood]
dgilmore has joined #fedora-riscv
jcajka has quit [Quit: Leaving]
<davidlt> dgilmore, https://pastebin.com/WynXJjbP
<davidlt> QEMU 7.2.4, Fedora 38 as host
<davidlt> by default QEMU comes with it's own OpenSBI FW_DYNAMIC generic binary, so technically you don't need U-Boot SPL there.
<davidlt> and you don't need U-Boot ITB too (which incl. OpenSBI binary, U-Boot propper, and DTB from U-boot side)
<davidlt> it should be enough to pass U-Boot proper binary as the kernel
<davidlt> or -bios
<davidlt> You can check Gentoo wiki for libvirt VM XML : https://wiki.gentoo.org/wiki/RISC-V_Qemu_setup
<davidlt> You can find all the U-Boot binaries here: http://fedora.riscv.rocks/koji/rpminfo?rpmID=1038604
<dgilmore> qemu-7.2.4-2.fc38.aarch64
<dgilmore> I am using u-boot from koji
<dgilmore> in the <os> section of xml for libvirt using virsh edit I added
<dgilmore> <loader readonly='yes' type='rom'>/usr/share/uboot/qemu-riscv64/u-boot.bin</loader>
<dgilmore> that was the only binary that worked
<BryceII> Last time I messed with qemu/riscv64 I ended up having to embed a uboot FW into opensbi to get it all working... then I got real HW and haven;t looked back since
<dgilmore> everything else I got no output on the console
<dgilmore> I have a Lichee Pi 4A coming
<davidlt> dgilmore, you should get VF2 as it has a better support (incl. EDK2 port)
<davidlt> You might try to SSH into the VM
<davidlt> The console listed in extlinux.conf might be wrong for libvirt VMs
<dgilmore> It is booting
<dgilmore> <loader readonly='yes' type='rom'>/var/lib/libvirt/images/Fedora-Developer-38-20230519.n.0-u-boot-spl.bin</loader>
<dgilmore> <kernel>/var/lib/libvirt/images/Fedora-Developer-38-20230519.n.0-u-boot.itb</kernel>
<dgilmore> I had to use the SPL as a loader and then the u-boot.itb as a kernel
<davidlt> You don't need to do that IIRC
<davidlt> Listing U-Boot proper (i.e. not SPL) as -kernel (as in Gentoo instructions) should be enough
<davidlt> smode U-Boot
<dgilmore> that was what I was doing and getting the unhandled exceptions
<dgilmore> smode u-boto I got nothing out
<dgilmore> only u-boot.bin in /usr/share/uboot/qemu-riscv64 gave me any output
<davidlt> Ah yes, sorry, that's the one you should use
<davidlt> QEMU will create a struct and will pass information to OpenSBI to jump to it
<davidlt> ok, time to sleep.
<davidlt> I check channel logs in the morning, but we also have Matrix channel (currently not IRC/Matrix bridge is down)
<dgilmore> night
<davidlt> In the "old days" with libvirt + QMEU infra I used to host virt-builder repo to easily spin VMs in libvirt.
<davidlt> But I never added newer images (again, we switched to physical hardware)
<davidlt> Otherwise it was 1-2 commands to create/modify/spin a VM.
<dgilmore> I can also confirm with the u-boot combo from https://dl.fedoraproject.org/pub/alt/risc-v/disk_images/Fedora-Developer-38-20230519.n.0.SiFive.Unmatched.and.QEMU/ the disk image from koji boots
davidlt has quit [Ping timeout: 245 seconds]
jednorozec has quit [Ping timeout: 248 seconds]
jednorozec has joined #fedora-riscv