On Thu, Jan 14, 2016 at 4:43 PM, Andrew Baumann <andrew.baum...@microsoft.com> wrote: >> 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 :) >
Agree Regards, Peter > Andrew