Re: [Qemu-devel] [RFC] armv7m_nvic

[Peter Maydell]

On 4 June 2015 at 13:45, Liviu Ionescu <address@hidden> wrote:
> while working on the Cortex-M framework, I noticed that the current
> armv7m_nvic implementation is a bit old, and, to my opinion, not
> very fortunately structured.
>
> first, it is named NVIC, but implements not only the NVIC registers,
> but some other register groups, like SysTick, system control, some IDs.
>
> if the QEMU rule is to implement a physical contiguous memory space
> (0xE000E000 - 0xE000EFFF) in one file, then probably the file should
> be named armv7m_scb.c (System Control Block), and it must implement
> all registers.
>
> the modular alternative (that I generally favour) would be to split
> the memory space into functional slices (SystemControl, SysTick,
> NVIC, CPUID, MPU, Debug, SW Triggers, MCUIDs) and implement them as
> separate objects, probably in separate files.

Yes, the current structure is not the ideal one. It dates back to
before we had support for constructing memory regions by overlaying
multiple different devices, which is why it combines more things
than it ought to. I split some of the GIC memory regions out a
few years back, but there are more parts that could also be
separated. Splitting out Systick definitely makes sense.
Some of the rest should probably be part of the CPU object itself:
if the implementation is just reading and writing fields in
the ARM CPU state struct then probably the memory-mapped
register interface should be in the CPU object.
(We can now have the CPU object provide memory regions, because it's
a device object itself. This is another bit of API that wasn't
available to the original armv7m_nvic author.)

On the MPU, if you need an emulation of that you should look
at Peter Crosthwaite's Cortex-R5 patchset, which needs a v7PMSA
for the R profile core. The interface is obviously different
(cpregs rather than memory-mapped registers) but the underlying
code for doing address translation should be the same I think.

> the changes that I might need in QEMU might also require some
> updates in the exception processing and might also affect NVIC,
> so if you have any comments on how the current structure should
> be improved, I'm open to suggestions.

The current code borrows heavily from the ARM GIC implementation,
presumably because it was convenient at the time. I don't think
this is actually correct, because the M profile exception handling
is much more tightly coupled to the CPU and includes assigning
priorities to exceptions (BusFault, UsageFault and the like) and
dealing with those in the same way as external interrupts.
Depending on how accurate you need your emulation to be, it may
turn out to be necessary to bite the bullet and reimplement the
NVIC properly as an independent bit of code. (Of course if you
don't need to fix the problems our current implementation causes
you can leave it the way it is.)

thanks
-- PMM