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
bkeys has joined #fedora-riscv
nirik has joined #fedora-riscv
bkeys has quit [Ping timeout: 240 seconds]
davidlt has joined #fedora-riscv
<davidlt> djdelorie, is the board still alive?
<davidlt> The pings are fine, just wondering...
<davidlt> I don't see much happening on the logs, but hopefully it's just long executing test.
davidlt has quit [Ping timeout: 244 seconds]
djdelorie has quit [*.net *.split]
iooi has quit [*.net *.split]
oaken-source has quit [*.net *.split]
Esmil has quit [*.net *.split]
davidlt has joined #fedora-riscv
djdelorie has joined #fedora-riscv
iooi has joined #fedora-riscv
oaken-source has joined #fedora-riscv
Esmil has joined #fedora-riscv
jcajka has joined #fedora-riscv
davidlt has quit [Ping timeout: 272 seconds]
jcajka has quit [Ping timeout: 244 seconds]
jcajka has joined #fedora-riscv
<rwmjones> davidlt[m]: nufive looks like it is idle, so I'm going to upgrade it first
<rwmjones> so I think I just need to copy
<rwmjones> Fedora-Developer-Rawhide-20220705.n.0-mmc-firmware.raw.img
<rwmjones> to /dev/mmcblk0 and reboot, or do I need to upgrade the kernel as well?
<rwmjones> currently I have:
<rwmjones> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
<rwmjones> mmcblk0 179:0 0 7.4G 0 disk
<rwmjones> ├─mmcblk0p1 179:1 0 1M 0 part
<rwmjones> └─mmcblk0p2 179:2 0 4M 0 part
<rwmjones> zram0 252:0 0 4G 0 disk [SWAP]
<rwmjones> nvme0n1 259:0 0 465.8G 0 disk
<rwmjones> ├─nvme0n1p1 259:1 0 700M 0 part /boot
<rwmjones> └─nvme0n1p2 259:2 0 465.1G 0 part /
<rwmjones> with /boot/extlinux/extlinux.conf listing the 5.14.16 kernel
<rwmjones> so my theory is that by just updating mmcblk0 it will use the new uboot and still boot into the old kernel
<rwmjones> biab
organizedglobals has joined #fedora-riscv
masami has joined #fedora-riscv
masami has quit [Max SendQ exceeded]
masami has joined #fedora-riscv
bkeys has joined #fedora-riscv
masami has quit [Quit: Leaving]
zsun has joined #fedora-riscv
zsun has quit [Quit: Leaving.]
<djdelorie> davidlt[m]: just slow, still running
<djdelorie> qemu hppa and sparc64 tests currently
jcajka has quit [Ping timeout: 272 seconds]
davidlt has joined #fedora-riscv
<davidlt[m]> rwmjones: yes, mmc-firmware is just opensbi, uboot spl and uboot proper
<davidlt[m]> That should work just fine
<davidlt[m]> djdelorie: are you sure? The logs didn't change for hours, but the board continues to ping
<davidlt[m]> I wonder if the test just got stuck in some loop
<davidlt[m]> djdelorie: could you check exact tests being run? maybe there is something in the spec about them.
<rwmjones> ok
davidlt has quit [Ping timeout: 240 seconds]
<djdelorie> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
<djdelorie> 2306913 kojibui+ 20 0 1475428 31480 15772 S 100.0 0.2 1327:34 ./qemu-system-sparc64 -qtest unix:/tmp/qtest-2306906.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-2306906.qmp,id=char0 -mon chardev=char0,+
<djdelorie> 2304614 kojibui+ 20 0 1848668 30060 15868 S 100.0 0.2 1332:26 ./qemu-system-hppa -qtest unix:/tmp/qtest-2304603.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-2304603.qmp,id=char0 -mon chardev=char0,mod+
<djdelorie> that's a stupid amount of time, even for a qemu test I think
<djdelorie> but they've only been running since yesterday
<djdelorie> top
<djdelorie> they're not stuck, still using 100% cpu each
davidlt has joined #fedora-riscv
<davidlt[m]> djdelorie: strace?
<davidlt[m]> What are they actually doing. That's what I am wondering.
<davidlt[m]> If that's stuck you might as well update your board and I could relaunch, see what happens.
<djdelorie> looks like it's looping on polling and futex
<davidlt[m]> djdelorie: update your board instead and I will relaunch the task
<djdelorie> ok. Won't be immediate though
<davidlt[m]> rwmjones: are your boards updated? I could send the task to yours, that should give some stress testing.
<rwmjones> davidlt[m]: sorry, not yet
<rwmjones> let me do the mmc on nufive right now ...
<rwmjones> $ sudo dd if=Fedora-Developer-Rawhide-20220705.n.0-mmc-firmware.raw.img of=/dev/mmcblk0 bs=1M
<rwmjones> seems to be booting the old kernel ok
<rwmjones> is there any file in /sys (eg) which shows the uboot version?
<rwmjones> anyway, let me try updating the kernel
<davidlt[m]> No, just on the serial
<rwmjones> it wants to install 5.18.8-200.0.riscv64.fc33
<davidlt[m]> Updating the kernel will not work, well it works, but new extlinux.conf is not created
<rwmjones> understood, I'm expecting to hand edit that after the update
<rwmjones> is that a good version?
<davidlt[m]> Yes, manually update that, or just write a new disk image into NVMe and configure things again.
<rwmjones> sure
<davidlt[m]> The kernel version is good.
<rwmjones> ok here goes
<rwmjones> after that I'm going to play with temp sensors
<davidlt[m]> Something broke with extlinux.conf update, but I cannot recall what. Anyways we should switch to GRUB2 instead, but that one is missing a couple of patchsets in upstream (LoadFile2 and UEFI boot hard id EFI protocol which was just ratified).
<rwmjones> tbh I prefer extlinux (even more if it was still maintained)
<rwmjones> it's so much less crazy than grub
<davidlt[m]> Those should work out-of-the-box, but if you want to identify better which is CPU which is MB, just use that snippet from the README.md
<davidlt[m]> Yes, it is, but we cannot use as all other arches use GRUB2.
<rwmjones> sure :-(
<davidlt[m]> systemd-boot is an option too, Fedora supports it IIRC.
<davidlt[m]> We have 260+ patches in Fedora for GRUB2 :)
<davidlt[m]> I think OpenSUSE has 220+ patches.
<davidlt[m]> Fu Wei showed it works with Fedora/RISCV, but two things missing: LoadFile2 protocol for initrd and EFI call for boot hard it (Fu Wei used /chosen node to communicated that to GRUB2 IIRC).
<davidlt[m]> Now we have something ratified by RVI, but no one yet sent a patch, I think.
<rwmjones> davidlt[m]: is there a point to using the watchdog?
<davidlt[m]> rwmjones: no, it's broken, well not broken, but that's how DA9063 OTP is configured
<davidlt[m]> It cannot reboot, just power down
<davidlt[m]> sensors, heartbeat LED and using firmware from the SPI might be the most interesting bits
<davidlt[m]> Note that if you remove fdtdir from extlinux entry it will get a DT from the firmware instead, but that one is not fully up to date
<rwmjones> we seem to be updated
<rwmjones> I see the green light on the motherboard giving a kind of "double flash"
<rwmjones> is that the heartbeat?
<rwmjones> Linux nufive.home.annexia.org 5.18.8-200.0.riscv64.fc33.riscv64 #1 SMP Wed Jun 29 15:09:53 EDT 2022 riscv64 riscv64 riscv64 GNU/Linux
<davidlt[m]> If you configured it, yes :)
<rwmjones> Linux nujive.home.annexia.org 5.18.8-200.0.riscv64.fc33.riscv64 #1 SMP Wed Jun 29 15:09:53 EDT 2022 riscv64 riscv64 riscv64 GNU/Linux
<rwmjones> M/B Temp: +42.9°C (low = +0.0°C, high = +85.0°C) (crit = +85.0°C, hyst = +75.0°C)
<rwmjones> CPU Temp: +47.0°C (low = +0.0°C, high = +85.0°C) (crit = +85.0°C, hyst = +75.0°C)
<rwmjones> M/B Temp: +42.2°C (low = +0.0°C, high = +85.0°C) (crit = +85.0°C, hyst = +75.0°C)
<rwmjones> CPU Temp: +53.5°C (low = +0.0°C, high = +85.0°C) (crit = +85.0°C, hyst = +75.0°C)
<rwmjones> the bottom one is using the case fan, the top one is using the supplied CPU fan
<rwmjones> I am planning to fit a heatsink (received a few weeks ago) on the CPU and try the case fan on both
<davidlt[m]> Those are some high temps compared to mine
<rwmjones> so having temps is good for monitoring
<rwmjones> also the office is a sauna ..
<rwmjones> I'll keep an eye on the temps and try playing with heatsinks
<rwmjones> kojid up again on nufive
<davidlt[m]> I am redirecting QEMU build to the nufive
<rwmjones> nujive kojid is behaving a bit oddly
<rwmjones> ok nujive is up
<rwmjones> I see builds on both now
<davidlt[m]> Nope, there is only one build cooking now, that's QEMU
<rwmjones> yes you're right, I misunderstood the status message on nujive
<davidlt[m]> Hm... I don't see anything on the logs yet
<davidlt[m]> What is kojid doing? Still cleaning up old buildroots?
<davidlt[m]> Finally something is moving
<rwmjones> working afaict
<davidlt[m]> Ok, I will check in the morning what happens to it.
davidlt has quit [Ping timeout: 240 seconds]