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