Re: [Qemu-devel] [RFC] armv7m_nvic

[Peter Maydell]

On 4 June 2015 at 19:17, Liviu Ionescu <address@hidden> wrote:
>
>> On 04 Jun 2015, at 16:03, Peter Maydell <address@hidden> 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