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-Mac6c998b683f36728d0ba420 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
