On 10/2/18 6:12 PM, Peter Maydell wrote: > On 2 October 2018 at 16:48, Cédric Le Goater <c...@kaod.org> wrote: >> On 10/2/18 12:56 PM, Peter Maydell wrote: >>> Rather than having the DMA device directly grab the system_memory >>> MR like this, it's better to have the device have a MemoryRegion >>> property, which the SoC sets with whatever the DMA device should >>> be able to see. >> >> ok. I see, but it seems I have a chicken & egg problem. >> >> The MemoryRegion I would liked to grab is the bmc->ram one in aspeed.c >> but it is initialized after the SoC is. I don't know how to lazy bind >> this region in the Aspeed SMC model using the Aspeed SoC model as a >> proxy to pass the region property through a link or/and alias. >> >> If I could find a way, the model would be much cleaner. > > Usually what you want to pass is not the RAM region directly but > some container object (which contains the RAM region among > other things). This is often a container that you're passing > to the SoC anyway so it can put its devices in it. > > (The direct answer to your chicken-and-egg problem is that you > can create a container before creating the SoC, pass that to > the SoC, then create the RAM afterwards and put it in the > container after. But that feels a bit like a workaround for > a less than ideal structure, somehow.)
couldn't we just initialize the RAM under the SoC ? We don't need it at the machine level AFAICT, nor does the raspi model I think. What is the rational behind putting the RAM region in a state structure at the machine level ? Thanks, C.
