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

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

[Liviu Ionescu]

(I know that from time to time this question pops up, but) is there anyone working or planning to work on the M4 emulation?

If not, I might give it a try, perhaps it is not as mission impossible as it looks like. Except the lazy processing of exception save/restore which must be implemented, is everything else related to the instruction set already in? (because I would not venture into this territory).

Any suggestions/encouragements are welcomed.


Regards,

Liviu

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

[Peter Maydell]

On 5 April 2016 at 22:57, Liviu Ionescu <ilg@livius.net> wrote:
> (I know that from time to time this question pops up, but) is
> there anyone working or planning to work on the M4 emulation?

Not that I'm aware of; Michael Davidsaver had some patches for
improving the v7M interrupt/exception emulation, but I don't
think I've seen anything for the FPU side of things.

> If not, I might give it a try, perhaps it is not as mission
> impossible as it looks like. Except the lazy processing of
> exception save/restore which must be implemented, is
> everything else related to the instruction set already in?
> (because I would not venture into this territory).

It's not impossible, it's merely that it's more work than
just flipping a feature bit. I haven't checked but I expect
that the actual instruction emulation should all be there.
Lazy-restore will be the most complicated part. My initial
thoughts would be that you'd want to do it by treating
"lazy state preservation active" as similar to "fp disabled",
so it's a TB flag that causes an exception to be taken
(in this case a qemu internal one that we handle by doing
the necessary state-save and then resuming the instruction).

thanks
-- PMM

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

[Liviu Ionescu]

> On 06 Apr 2016, at 15:02, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On 5 April 2016 at 22:57, Liviu Ionescu <ilg@livius.net> wrote:
>> (I know that from time to time this question pops up, but) is
>> there anyone working or planning to work on the M4 emulation?
> 
> Not that I'm aware of; Michael Davidsaver had some patches for
> improving the v7M interrupt/exception emulation,

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.

> but I don't
> think I've seen anything for the FPU side of things.

ok, actually I did not expect much :-(

> .. I expect
> that the actual instruction emulation should all be there.

sounds better.

> Lazy-restore will be the most complicated part. My initial
> thoughts would be that you'd want to do it by treating
> "lazy state preservation active" as similar to "fp disabled",
> so it's a TB flag that causes an exception to be taken
> (in this case a qemu internal one that we handle by doing
> the necessary state-save and then resuming the instruction).

I need to study the code more thoroughly to understand exactly what you mean.

but before addressing the M4, I decided to restructure the rest of the Cortex-M system code, that now is all together in the NVIC object.

the current plan is to create a new object (probably called SCS - System Control Space), that will cover the 0xE000E000-0xE000EFFF area and inside it to map SysTick, NVIC, SCB, MPU, Debug and FPU as separate objects.

I'll use the Peripheral/Peripheral-Register/Register-Bitfield objects that I already use for the rest of the STM32 objects. these are table driven objects, that automatically handle storing/retrieving register data, shifting, masking, alignment, endianness, etc.

in addition to the detailed tables (which in the future I plan to generate automatically from ARM CMSIS SVD files), the application needs only to add *_pre_read()/*_post_write() callbacks, to handle actions associated with registers/bitfields.

the entire story is still quite complex, but at least it is very systematic, and should improve the emulation accuracy and reduce the risk of errors.

once I have this again functional, I'll try to address the M4 configuration, and let you know if there is any progress.


regards,

Liviu

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

[Peter Maydell]

On 6 April 2016 at 13:52, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 06 Apr 2016, at 15:02, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On 5 April 2016 at 22:57, Liviu Ionescu <ilg@livius.net> wrote:
>>> (I know that from time to time this question pops up, but) is
>>> there anyone working or planning to work on the M4 emulation?
>>
>> Not that I'm aware of; Michael Davidsaver had some patches for
>> improving the v7M interrupt/exception emulation,
>
> 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.

> but before addressing the M4, I decided to restructure the
> rest of the Cortex-M system code, that now is all together
> in the NVIC object.
>
> the current plan is to create a new object (probably called
> SCS - System Control Space), that will cover the 0xE000E000
>-0xE000EFFF area and inside it to map SysTick, NVIC, SCB, MPU,
> Debug and FPU as separate objects.

This will clash very badly with Michael's in-flight
patchset. 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.

thanks
-- PMM

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

[Liviu Ionescu]

> 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?

> 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.

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.

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?


regards,

Liviu

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

[Peter Maydell]

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

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

[Liviu Ionescu]

> On 07 Apr 2016, at 01:04, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> ... Somebody needs to do the necessary work to fix the
> code review issues. ...

in this case I'll probably wait for this process to be completed and reevaluate the situation by then.


regards,

Liviu

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

[Michael Davidsaver]

On 04/06/2016 06:23 PM, Liviu Ionescu wrote:
> 
>> On 07 Apr 2016, at 01:04, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> ... Somebody needs to do the necessary work to fix the
>> code review issues. ...
> 
> in this case I'll probably wait for this process to be completed and reevaluate the situation by then.

Liviu,

I haven't had time to complete a revision of my patch set so far this year.  I've been busy with other work (good for me, bad for qemu), and don't see this situation changing for an least the next two months.  It sounds like you have time and inclination to do part of what I've started.  I hope my having done half of a too big job won't keep you from finishing part of it.

If you decide to work on this problem, please don't hesitate to appropriate, or ignore, what I've done so far.

For what it's worth, I did start another revision back in February.  It does include the change Peter requested to the storage of priorities wrt. prigroup, but doesn't break up the big "rewrite NVIC" patch.

https://github.com/mdavidsaver/qemu/tree/fixirq2

Separately, I have a set of target test programs which I can run both with qemu and a real board.  They mostly agree.  Aside from test8.c (MPU) they might be of interest.

https://github.com/mdavidsaver/baremetal/tree/qemutest



Michael

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

[Liviu Ionescu]

> On 07 Apr 2016, at 03:46, Michael Davidsaver <mdavidsaver@gmail.com> wrote:
> 
> ...  don't hesitate to appropriate, or ignore, what I've done so far. ...
> https://github.com/mdavidsaver/qemu/tree/fixirq2

from what I see here, the nvic is still one big monolithic device.

as I said before, I like modular things, and, even if this might be a little slower, I'd split nvic:

"the current plan is to create a new object (probably called SCS - System Control Space), that will cover the 0xE000E000-0xE000EFFF area and inside it to map SysTick, NVIC, SCB, MPU, Debug and FPU as separate objects."

another difference is that I have a very elaborated infrastructure to manage registers, and I'd like to use it for the system registers too.

fyi, a simple device is:

	https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/gpio/stm32-gpio.c

a more complicated device (in terms of tables, otherwise the additional actions are minimal) is the 

	https://github.com/gnuarmeclipse/qemu/blob/gnuarmeclipse-dev/hw/misc/stm32-rcc.c


this table-driven way of implementing peripherals is specific to GNU ARM Eclipse QEMU and I plan to further improve it, with an automated tool to generate the tables.

Peter expressed concerns that this infrastructure will clash very badly with your work. actually it shouldn't, because it is completely separated, there are 3 objects (Peripheral/Peripheral-Register/Register-Bitfield).

in general none of the changes I did in GNU ARM Eclipse clash with existing code, because I use separate objects, from separate "cortex-m*" mcus, to separate peripherals and separate boards.

unfortunately nobody else expressed any interest in this new infrastructure, so it is available only in GNU ARM Eclipse QEMU.

> Separately, I have a set of target test programs which I can run both with qemu and a real board.  They mostly agree.  Aside from test8.c (MPU) they might be of interest.
> 
> https://github.com/mdavidsaver/baremetal/tree/qemutest

ok, good to know.

however projects generated by GNU ARM Eclipse use a distinct trace infrastructure, I'll probably create a separate test inspired by your code.


regards,

Liviu