some news:
interrupts are working (thanks Shawn Rutledge) and mounting from qemu
vm to a 9front system works as well (thanks José J. Cabezas Castillo).
We're using listen1 with telnetd atm. We need to test a drawterm in,
although I need to learn how to invoke drawterm such that it will
connect. I see services for all the stuff I'm used to, but not 17010.
But I know 9front improved the situation.
Lazy FPU support is on, which means nested interrupts had to work, and
they do. Floats seem to work.
And now to the part I don't understand. strtod on this string:
"2.997925e+8" never returns. This comes up when you run units.
It is calling frnorm and fpcmp and never seems to converge. I put it
down to something I've fouled up in kernel FPU support, I'm just not
sure what yet.
strtod does work on several other things ("4.14") but I think the
exponent is tripping it up, but I'm not sure.
Once this basic stuff is in, we'll want to get bpi-f3 ethernet going.
Thanks to Jacob Moody and other 9front folks for their encouraging
words. It's meant a lot to us.
On Thu, May 14, 2026 at 11:01 AM Ron Minnich <[email protected]> wrote:
>
> 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-M31ba5b92fcb9e44cff09cb33
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
