Hi Peter, > From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > Sent: Tuesday, 12 January 2016 16:44 > On Tue, Jan 12, 2016 at 3:53 PM, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > >> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > >> Sent: Monday, 11 January 2016 19:58 > >> > + /* Allocate and map RAM */ > >> > + memory_region_allocate_system_memory(&s->ram, > >> OBJECT(machine), "ram", > >> > + machine->ram_size); > >> > + memory_region_add_subregion_overlap(get_system_memory(), 0, > >> &s->ram, 0); > >> > >> I thought the SoC handled this now? Why do you need to add to > >> system_memory? > > > > If I don't map it here, how do RAM accesses from the CPUs work? > > > > Do the CPUs not have their AS'es connected to your custom ASes by the SoC > layer? > > > Or are you saying that I should still do this, but do it in the SoC not the > board level? > > > > I was hoping we could get away with 0 use of system_memory.
On further investigation, I don't think it's possible to wire up CPU ASes explicitly. There's no obvious property to set. Each cpu->as is initialised to point to address_space_memory at the top of cpu_exec_init(), and there is no way I could see to override that. I think what I have now is pretty clean, but if you'd prefer to do the mapping at into the global AS at SoC level that's fine with me too. Thanks, Andrew
