> On Aug 12, 2026, at 18:13, Alistair <[email protected]> wrote: > > On Fri, 2026-08-07 at 14:26 +0300, lists wrote: >> Ping. >> >> Do you have a different solution to emulate memory layouts of actual >> boards? > > The ideal answer is to model the board
OK; that’s more work, and then there is an expectation that it will be actively maintained, right? Banana Pi F3 is already out of production AFAICT; and it remains to be seen how many K3 boards will physically come into existence: there are already several designs so far, with different peripherals. Since I have theoretically bought the Deep Computing III Framework-based laptop (and it hasn’t shipped yet), I hope I will be able to use it for a good long time, but maybe I won’t need emulation very often. There is no demand for a distinct emulator for every known PC motherboard, despite often having different peripherals, but there is such a demand for embedded boards. Hmm. It seems like the idea to “model the board” every time and then maintain all those models doesn’t really scale. I would rather hope that riscv becomes more of a standard platform, rather than ending up with a zoo of less-compatible devices like the ARM ecosystem does. Not that there’s much evidence for such a movement so far, but IMO there should be. The point of the patch was to make the base address of virt adjustable, because it’s one thing that a particular kernel may be least able to deal with, if its data segment (or worse, some code) contains absolute pointers. For a while it seemed that we would need to build separate kernels for each board. But I changed the linker to emit a relocation table, and the kernel to fix up the data-segment pointers at boot, and now we have a kernel that boots on the bpi-f3, a couple of K3 boards and qemu. So changing qemu’s base address is no longer necessary to get it to boot, but just enables testing high-memory paths where some bugs were found. >> For me this is necessary for the Plan 9 porting work: a Banana Pi F3 >> has a different base address than one of the K3 boards, and both >> different than the QEMU default. > > The Banana Pi F3 and the K3 will also have different hardware blocks at > different addresses. The starting address of memory isn't the only or > even the main difference. > > I don't see how just changing the memory address fixes an issue for > you. It was just that certain bugs manifested in the case when the base address is at 0x100000000. So I suppose abandoning this is fine, if nobody else needs it. > RISC-V SoCs can locate their DRAM at any address, that is true. But I > don't see how just changing the virt machine address allows you to > suddenly test a K3 kernel on the virt board. The rest of the hardware > is still different I don’t necessarily need to emulate all the hardware, at least to begin with.
