On Tue, 2026-08-18 at 10:30 +0200, Shawn Rutledge wrote: > > > 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
Correct > 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 seem to be a few K3 boards shipping. I have one on my desk now :) > > 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. There are attempts at RVI, things like the server reference platform. But that is up to them and the RISC-V ecosystem, not us in QEMU land. > > 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 Yeah, I get that. But it is extra complexity for us to maintain and doesn't really align with the goal of the virt board. > 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. Great! > > > > 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. It doesn't seem like something that anyone else needs Thanks for the patch though! Alistair > > > 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.
