Re: [PATCH 1/9] hw/riscv/virt.c: enforce s->memmap use in machine_init()

[Conor Dooley <conor.dooley@microchip.com>]

[-- Attachment #1: Type: text/plain, Size: 5389 bytes --]

Yo,

On Tue, Apr 29, 2025 at 02:55:44PM +0930, Joel Stanley wrote:
> On Fri, 25 Apr 2025 at 21:23, Daniel Henrique Barboza
> <dbarboza@ventanamicro.com> wrote:
> > On 4/24/25 6:51 AM, Joel Stanley wrote:
> > > On Wed, 23 Apr 2025 at 20:37, Daniel Henrique Barboza
> > > <dbarboza@ventanamicro.com> wrote:
> > >>
> > >> Throughout the code we're accessing the board memmap, most of the time,
> > >> by accessing it statically via 'virt_memmap'. This static map is also
> > >> assigned in the machine state in s->memmap.
> > >>
> > >> We're also passing it as a variable to some fdt functions, which is
> > >> unorthodox since we can spare a function argument by accessing it
> > >> statically or via the machine state.
> > >>
> > >> All the current forms are valid but not all of the are scalable. In the
> > >> future we will version this board, and then all this code will need
> > >> rework because it should point to the updated memmap. In this case,
> > >> we'll want to assign the adequate versioned memmap once during init,
> > >> in s->memmap like it is being done today, and the rest of the code
> > >> will access the updated map via s->memmap.
> > >
> > > I was writing a patch for a machine and came across the same
> > > inconsistencies. Nice clean up.
> > >
> > > Some of the device initlisation code could be refactored out to be
> > > shared by other machines within the riscv directory. Related, parts of
> > > the device tree creation could belong to the model, instead of to the
> > > machine, as the properties are a property (!) of the device.
> >
> > Yes, delegating the FDT creation to the device, instead of having each machine
> > to create the (mostly) same FDT code over and over again, is something that
> > I've considering for awhile.
> >
> > I keep postponing it mainly because I would like to verify with the DT folks if
> > there's a guarantee that a given device/CPU DT is always the same, i.e. a device
> > DT is always the same regardless of the machine. I have a guess that that this is
> > indeed the case but a confirmation would be nice .... Conor, care to comment?

Uhm, if the device node was always the same, regardless of "machine"
then there'd be no need for any properties other than
compatible/reg/links to provider nodes! But unfortunately that's not what
properties are limited to, there's properties for a whole host of other
elements of device configuration.

Generally speaking, properties will be fixed for a given "machine"/board,
but some could change depending on things like AMP affecting which
mailbox channel you're permitted to use or using a different firmware
(or version of said firmware) can change a node. For example, the
extensions supported by a CPU can change based on what version of OpenSBI
you're running. The latter might not affect QEMU, because you're providing
a DT for the firmware to edit, but from the OS point of view there's
different, but valid and complete, descriptions for the same physical
hardware.

Also, on the same machine you might have variation between two instances
of the same IP, other than just the reg/provider links changing, for
example if there's two different dwmac ethernet controllers configured
to provide different maximum speeds.

So yeah, I can't give you any assurance that even one specific IP/CPU on
a specific SoC on a specific machine/board will have the same device
node unfortunately.

> My understanding is bindings strive to specify the hardware
> independent of the machine it's part of. We have bindings in the
> kernel tree, and associated drivers that use those bindings, that work
> fine on different machines. The litex peripherals are an extreme case
> of this; peripherals defined in python that are attached to soft cores
> often running on a FPGA.

Yeah, FPGA stuff is an extreme case, but a great thing to use as a test
for the idea, since you could have properties that change from
compilation to compilation. Take a look at something like snps,dwmac.yaml
where there's about seven thousand different properties, many of which
could be varied if it were in an FPGA design rather than an ASIC..

The other kinda extreme case in variability is the stuff that's on a
board rather than an SoC, for example the same mmc/sd card controller
on an SoC can have different device nodes depending on how a board has
been designed. What Linux calls "IIO" devices are also impacted
massively by how a board is configured or use-case, since they're often
measurement devices with different analogue circuitry connected to them.

I'm not 100% sure how all that translates to a machine in QEMU, dunno if
running a different AMP context would require a different machine etc,
but I hope that gives a general impression of what could potentially
vary? LMK if not.
Conor.

> At a practical level generating the device tree for a given device
> does need to take into account specifics of the machine.
> 
> Things like interrupt properties depend on the interrupt device you're
> delivering to (some have two cells to provide a 'flags' parameter
> alongside the irq number). In general anything that contains phandles
> could end up being machine specific. Another case is the number of
> cells in reg properties, which depend on the bus the device is
> described to be on.

> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]