Re: [Qemu-devel] Any progress with the Cortex-M4 emulation?

[Peter Maydell <peter.maydell@linaro.org>]

On 6 April 2016 at 22:54, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 06 Apr 2016, at 17:42, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On 6 April 2016 at 13:52, Liviu Ionescu <ilg@livius.net> wrote:
>>>
>>> I also have on my TODO list to implement the SCB registers used
>>> during exception processing (MMFAR, BFAR, CFSR); I checked and
>>> in version 2.5.1 apparently they are still not implemented.
>>
>> Those I think are covered by Michael's patchset.
>
> I updated my git and browsed the log records, the only commits
> of Michael were from Mov 3, and apparently did not include this
> functionality.
>
>> This will clash very badly with Michael's in-flight
>> patchset.
>
> you mean Michael's code is not yet in the master branch?

Yes; patches were posted to the mailing list but there were
code review comments which haven't yet been addressed.
We went through a couple of rounds of review; it was
looking promising but still needed some more work. The
last posted patchset was:
https://lists.nongnu.org/archive/html/qemu-devel/2015-12/msg00504.html
(the second half of that is adding MPU support so you
can ignore it.)

>> I think it would be much better to get that
>> complete and upstream first, because otherwise you'll
>> probably end up having to redo a lot of work.
>
> my intent is to isolate the Cortex-M code from the
> existing ARM implementation, practically it should be
> a fresh start of the Cortex-M code, with a NVIC that no
> longer inherits from GIC.

Michael's patchset does that already.

> if you plan to further maintain the existing code, fain,
> but for me it is a bit too messy and I cannot rely on it,
> I need a clean implementation of the system peripherals,
> with properly processed exceptions.

Michael's patchset handles exceptions properly (at
any rate much closer to architecturally than our
current code).

> if Michael code is not in, when do you think it will be,
> so I can make a decision to either continue to patch the
> existing code or to redo the system code?

Somebody needs to do the necessary work to fix the
code review issues. I'm guessing from not having seen
any mails from Michael since December that he's been
busy with other things. If I were in your position I
would start with Michael's patchset and make the
necessary fixes to it to get it upstreamable. That's
likely going to be faster than starting the same
thing from scratch.

thanks
-- PMM