shawn and jose have been busy. We are now running at tip of 9front tree, and shawn reports he can drawterm in when it's running on qemu.
The set of changes we've had to make has gotten dramatically smaller. Something in this broke the bpi-f3 port, still digging. It also boots on the spacemit k3, which is nice. Current best branch is shawns' riscv64-rebase2. On Mon, May 25, 2026 at 9:12 AM ron minnich <[email protected]> wrote: > > 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-Md1bcc9258cca83bf9d8c4e89 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
