<djdelorie>
davidlt[m]: unmatched.delorie.com is up again, in theory...
davidlt has joined #fedora-riscv
<davidlt[m]>
djdelorie: cool, did you just flashed all new images, or just updated a kernel on existing rootfs?
<davidlt[m]>
djdelorie: ah, what temperatures do you see reported by sensors?
<djdelorie>
reflashed everything, then copied the koji files
<djdelorie>
currently 43.6 M/B, 47.1 CPU (and 54.5 VGA)
<davidlt[m]>
cool, I have qemu now compiling on rwmjones board (still some hours to go)
<davidlt[m]>
Interesting, that my temps are quite low :)
<djdelorie>
I'd suggest some small test build on a fresh install, just to make sure it's set up correctly before committing
<davidlt[m]>
Planning to do that
<djdelorie>
I have no case fans on that case, just the power supply fan. However, it's in my basement, which is relatively cool
<davidlt[m]>
Mine in about -10C cooler, but I am using 3A0 (pre-production board)
<davidlt[m]>
Technically production board has a better heatsink, but I think, I just got lucky in silicon lottery :)
<djdelorie>
they might have pushed the silicon harder in the production board, once they knew the limits
<davidlt[m]>
Could be, 3A0 and 3B0 have very minimal changes
<davidlt[m]>
perfect, QEMU just finished building! Tests probably will start within an hour or so
<davidlt[m]>
I am considering building a new glibc from Rawhide to test the board
<davidlt[m]>
That shouldn't break anything
* djdelorie
recalibrates "small" to "glibc-sized"
<davidlt[m]>
Well, it's a good test :)
<davidlt[m]>
A bit of a stress test :)
<davidlt[m]>
I can always back it out if something is wrong (the benefits of having access to admin powers on Koji)
<davidlt[m]>
It takes 7-8 hours
<davidlt[m]>
2.32 -> 2.35 or 2.36, hm...
<davidlt[m]>
glibc-2.35-14.fc36 is a good candidate instead of Rawhide glibc-2.35.9000-29.fc37
<djdelorie>
we sync glibc to rawhide every week
<djdelorie>
but you want the builds that passed CI
<djdelorie>
or at least basic functionality
<davidlt[m]>
This last build has f37 tags so it's in the repository
<djdelorie>
2.36 should be released in a few weeks
<djdelorie>
the latest rawhide would be helpful to test for the release :-)
<davidlt[m]>
I see glibc-2.35.9000-26.fc37 has no tags, so it didn't went into Rawhide repos
<davidlt[m]>
That's a plan, I man to fly close to the sun again :)
<davidlt[m]>
But I need a stable disk image, so I don't need to fix boards/VMs the whole days most of the week
<davidlt[m]>
VMs were easy as I simply nuked them based on Koji pings and recreated, but the boards is all manual labor (no BMC)
<davidlt[m]>
Testing PiKVM is on the list. It has IPMI 2.0, Redfish, KVMD API via REST. Also it has some interesting thing like GPIO support (various modes, e.g. switch)
<djdelorie>
I haven't had to fresh install a rawhide vm in a while now...
<davidlt[m]>
But that almost doubles Unmatched price
<djdelorie>
assuming you can get a Pi at all :-)
<davidlt[m]>
Yeah, the 8G model seems to hard to get
<djdelorie>
I have an 8G for development, on my desk, but the Pi3B that runs the garage doors might need replacing soon...
<davidlt[m]>
i.e. glibc-2.35-14.fc36
<davidlt[m]>
If nothing breaks too much, we can consider 2.36 too
<davidlt[m]>
cooking
<djdelorie>
hey look, stuff in kojid.log :-)
<davidlt[m]>
Talking about cooking, I need some breakfast :/
<davidlt[m]>
glibc is building and qemu tests are running
<davidlt[m]>
djdelorie: note, that if we build glibc 2.36 now for testing reasons, we will have a bit older toolchain (gcc and binutils), that might be a common testing setup :)
davidlt has quit [Ping timeout: 272 seconds]
davidlt has joined #fedora-riscv
<davidlt[m]>
I think QEMU testing is now at that stage were it hanged on djdelorie board
<davidlt[m]>
722/744 qemu:qtest+qtest-xtensaeb / qtest-xtensaeb/qmp-cmd-test OK 15.92s 60 subtests passed
<rwmjones>
davidlt[m]: so if I was crazy enough to want to run a VM on one of the riscv machines (using tcg of course), what -cpu, -machine would be suggested?
<rwmjones>
I tried no -cpu and -machine virt, and it gets into opensbi but then seems to hang before getting to the kernel
<rwmjones>
(or maybe the serial console is broken ...)
* davidlt[m]
thinking...
<rwmjones>
(it's possible it just being very very slow)
<davidlt[m]>
IIRC OpenSBI within QEMU supports only JUMP mode?
<rwmjones>
what is JUMP mode?
<davidlt[m]>
Yeah, instead of DYNAMIC mode
<davidlt[m]>
In old times we used JUMP variant because OpenSBI was the 1st thing booting after ZSBL
<davidlt[m]>
These days OpenSBI is within U-Boot proper image, U-Boot SPL launches it and tells it to load U-Boot proper
<davidlt[m]>
This is because U-Boot SPL fills the structure and pass that information to OpenSBI about the next boot stage
<davidlt[m]>
IIRC (didn't check) QEMU OpenSBI is only compiled as a JUMP variant, so it expects to jump into specific address (like we did some years ago)
<davidlt[m]>
Maybe that changed
<davidlt[m]>
I do know that OpenSBI is loaded by default unless -bios none is passed
<rwmjones>
let's try -bios none ..
<davidlt[m]>
I am looking at my old emails, QEMU did switch OpenSBI to DYNAMIC variant in 5.2 version
<davidlt[m]>
We will need to figure out new libvirt and QEMU instructions for F37