On Fri, 25 Apr 2025 at 21:23, Daniel Henrique Barboza <dbarb...@ventanamicro.com> wrote: > > > > On 4/24/25 6:51 AM, Joel Stanley wrote: > > On Wed, 23 Apr 2025 at 20:37, Daniel Henrique Barboza > > <dbarb...@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?
I'd be interested in Coner's thoughts on this. 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. 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. These are things that some common code would need to handle, not show stoppers for the idea. > In this refactor we could then create FDTs by passing along a memmap pointer > and > a fdt pointer, as you've suggested. > > All this said, there's no need to do such FDT refactory all at once. I think > I'll > start with the most common devices between RISC-V boards and go from there. Agreed! It was just something to keep in mind when deciding what pointers to pass around. Cheers, Joel
