> From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] > Sent: Thursday, 14 January 2016 15:35 > > On Thu, Jan 14, 2016 at 3:04 PM, Andrew Baumann > <andrew.baum...@microsoft.com> wrote: > > 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. > > > > If it cant be done yet, what is here is a preferable approach. PMM has > some work on list for CPU ASes that may be realted, moreso for the > secure attributes though I think.
Ok. It looks like the patch you CCed me on would enable this. But I don't really want to wait for that with Pi, and honestly I don't think this is too bad -- there are only a handful of things in the system_memory space (the RAM, the peripherals blob, and the 2836 multi-core controller on pi2), and it seems unlikely to be of great benefit unless some future madman starts building multi-pi boards with bizarre mapping schemes. Let's hope not :) Andrew