OK, some sort of FPU support is "right", in the sense that a single program (units and another test) are back to working and giving right answers.
I don't want to claim, yet, that it's all solid, i.e., if a process is using FPU, and decides to hit its note handler, which uses the FPU, and ends up in the kernel, which decides to use the FPU, will all the nested traps and restores work correctly? Well, that's to be seen. The 9front nested FPU stuff is pretty interesting, took me a while to think I understand it, but do I really? Time will tell. On Sun, May 24, 2026 at 1:01 PM Ron Minnich <[email protected]> wrote: > > I've tracked the strtod problem to me not getting lazy fpu right, no > surprise there :-) > > On Thu, May 21, 2026 at 1:03 PM ron minnich <[email protected]> wrote: > > > > 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-Md6a27db90d99e45830e5c380 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
