On 4 June 2015 at 19:17, Liviu Ionescu <i...@livius.net> wrote: > >> On 04 Jun 2015, at 16:03, Peter Maydell <peter.mayd...@linaro.org> wrote: >> >> ... Splitting out Systick definitely makes sense. > > as a first step, I would try to define a separate object (armv7m-systick) and > copy/paste the access code. > > then refer it inside the existing NVIC, to avoid affecting existing > functionality.
Sounds good -- systick should be fairly small and self contained. Eventually the container bit should probably move out to be hw/arm/armv7m.c (which then instantiates separate system regs, NVIC and systick and assembles them into the right places in the memory map). That will require converting armv7m.c into a proper QOM container device, though, so we can do the systick bit first. > it would be a real time saver if you could provide a hint on the best > approach to map the SysTick memory range (E010-E0FF) over the existing NVIC, > inside the current code. The basic approach is to use memory_region_add_subregion() to add the MemoryRegion for the systick object in the right place in the container region. We do this already in armv7m_nvic_realize() for the GIC region, though that's a bit funny because we have direct access to its MemoryRegions. Look at hw/cpu/a9mpcore.c for an example of building up a container using MemoryRegions exposed by SysBus devices. (The sysbus device uses sysbus_init_mmio() in its realize function to export memory regions. Then the container device's realize function can create and realize the smaller devices, and use sysbus_mmio_get_region() to get the MemoryRegion* it needs to pass to memory_region_add_subregion().) >> On the MPU... > > I would use a similar approach, a separate object, at first mapped > over the ED90-EDEF range inside the existing NVIC. My strong initial impression is that we should do this by having the CPU object expose a MemoryRegion, which you can then map over the right range in the NVIC. I don't think it makes sense for the MPU to be a completely separate device object, because all the actual implementation is (and must be) in the CPU. -- PMM
