Re: [PATCH] hw/riscv/virt: add dram-base machine property

> 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.