Sorry, forgot to mention, it is tested on bpi-f3, and qemu. On Mon, May 25, 2026 at 8:21 AM ron minnich <[email protected]> wrote: > > 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-Mcc609ffcb6e7ea43b8793015 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
