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