We continue to clean up the port, and are to the point that we once again have ethervirtio10 on qemu, and the same kernel boots on bpi-f3 and, although the ethervirtio10 is not found, it does not crash :-)
We also continue to "narrow down" the set of differences from 9front, and had a great discussion at IWP9 on how to move forward. This time around, changes to virtio are quite minimal, and can be dropped once we get an interrupt controller working -- at the moment, virtio is polled via a clock interrupt (adclock0link ..) DHCP works fine from the guest. I have been able, from qemu, to mount 9p, using my "centre" program as the 9p server. Thanks to everyone at IWP9 (and on the video conference) who took the time to chat! On Sun, Apr 26, 2026 at 9:35 PM ron minnich <[email protected]> wrote: > > one last note: I've cleaned up a lot of the spew that was printing. From > entering the kexec command on the bpi-f3 to a command prompt is 20s, but I > think when I get rid of one last bit of mess (trying to get entropy) it will > be much less time. > > This iteration is about getting it to work at all, getting it faster is next. > > One other person has repro'ed the process on qemu, and it works for them. > > ron > > On Sun, Apr 26, 2026 at 8:06 AM ron minnich <[email protected]> wrote: >> >> OK, as of this morning: >> >> Await 1 0:01 0:10 10K 10 bootrc >> >> Idle 3 0:00 0:10 13K 0 pager >> >> Wakeme 5 0:00 0:10 13K 0 alarm >> >> Pread 7 0:02 0:08 10K 0 paqfs >> >> Wakeme 9 0:00 0:07 13K 0 closeproc >> >> Await 12 0:01 0:06 10K 10 rc >> >> Pread 17 0:00 0:00 10K 0 ps >> >> on the bpi-f3 >> >> >> So the next step is finding some way to get to network >> >> >> Note that the qemu and bpi-f3 continue to behave the same. >> >> >> The more recent fix was, because the 9front kernel is running as kexec >> purgatory, to be sure to zero all the memory we intend to use :-) >> >> >> >> >> On Sat, Apr 25, 2026 at 9:12 AM ron minnich <[email protected]> wrote: >>> >>> update: >>> https://github.com/rminnich/9front/tree/lkg-before-ethervirtio-bpi-f3 >>> is a bit of a reset. I drove the ron branch off a bridge, I could not make >>> sense of what it was doing on hardware, so I backed out a bit and restarted. >>> >>> For every change I make, I test on both the bpi-f3 and qemu, since I've >>> learned the hard way it's really easy to break one or the other. >>> >>> on qemu you do get to an rc prompt. >>> >>> On bpi-f3, the exec in initcode fails. The second argument is -1, instead >>> of a proper pointer. Tracking register values, all looks ok. But ... >>> >>> There seems to be *something* scribbling on the stack page on the bpi-f3. >>> That's as far as I've gotten. >>> >>> But, I've fixed a few issues that come up when kexec 9qemu, such as the >>> need in main() to zero bss explicitly, since kexec does not know where bss >>> is. >>> >>> Getting there. There is one other person testing on qemu, who has reported >>> some success, so that is a bit of good news. >>> >>> On Tue, Apr 21, 2026 at 9:19 PM ron minnich <[email protected]> wrote: >>>> >>>> yes, bpi-f3 has been a good target for me to work with. Right now, I'm >>>> hitting a weird problem, but qemu and the bpi-f3 behave identically, which >>>> is helpful. >>>> >>>> as to stimecmp, it's there and I've no idea what genode is talking about. >>>> >>>> On Tue, Apr 21, 2026 at 7:07 PM Frank D. Engel, Jr. <[email protected]> >>>> wrote: >>>>> >>>>> That article appears to be fairly old; apparently from somewhere around >>>>> 2016 if I am reading it correctly? >>>>> >>>>> Going by the official RISC-V documentation site >>>>> (https://docs.riscv.org/reference/isa/priv/sstc.html) it looks like what >>>>> they did was left MTIMECMP in the core architecture and moved STIMECMP >>>>> to an extension which makes it optional for processors to implement. >>>>> >>>>> >>>>> >>>>> On 4/21/26 16:21, Dave Eckhardt wrote: >>>>> >> Things like the STIMECMP were a major improvement and I don't want >>>>> >> to work without them. >>>>> > Given a strong endorsement like that, and knowing very little about >>>>> > RISC-V, I figured maybe it would be good to read up on STIMECMP. >>>>> > >>>>> > One of the first things I found was this: >>>>> > >>>>> > https://genode.org/documentation/articles/riscv#Timer >>>>> > >>>>> > ...which appears to be a claim that STIMECMP is already deprecated, >>>>> > or am I misreading it? >>>>> > >>>>> > Dave Eckhardt > > 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T80b1175a2d9b4e96-M805e79874b8199df8fe37703 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
