[Qemu-devel] [RFC] Cortex-M different revisions

[Qemu-devel] [RFC] Cortex-M different revisions

[Liviu Ionescu]

while studying the details of cortex-m cores, I ran into the many differences between existing revisions, especially for cortex-m3, which are numerous and some significative, like stack alignment. for example for m3, the changes from r0p0 to r1p0/r1p1 are one full page of details, like "	• the NVIC Configuration Control register includes the STKALIGN bit, 	• r1p1 includes the new AUXFAULT (Auxiliary Fault) status register...", changes from r2p0 to r2p1 include "	• The Vector Table Offset Register (VTOR) has been increased by two bits to enable more flexible placement of the vector table. ...", etc

at first sight these differences would require special care when implementing an accurate emulation.

for this I'm considering extending the naming scheme for cortex-m cores, to include the revision, like "cortex-m3-r2p1", which will define the fields in CPUID correctly.

as per Joseph Yiu (The Definitive Guide to ARM Cortex-M3 and M4, Third edition, p. 765), "The revisions for the Cortex-M3 processor include: r0p0, r1p0, r1p1, r2p0, and r2p1. The revisions for the Cortex-M4 processor include: r0p0, r0p1."


any comments? 

Liviu

Re: [Qemu-devel] [RFC] Cortex-M different revisions

[Peter Maydell]

On 21 June 2015 at 09:17, Liviu Ionescu <ilg@livius.net> wrote:
> while studying the details of cortex-m cores, I ran into the
> many differences between existing revisions, especially for
> cortex-m3, which are numerous and some significative, like
> stack alignment. for example for m3, the changes from r0p0 to
> r1p0/r1p1 are one full page of details

Our usual approach is "implement a recent revision". We don't
attempt to accurately emulate the foibles of earlier revs,
and definitely don't try to emulate the errata. Similarly,
we often emulate to an "architecturally correct" level
rather than "match the IMPDEF behaviour of a particular
implementation".

> for this I'm considering extending the naming scheme for
> cortex-m cores, to include the revision, like "cortex-m3-r2p1",
> which will define the fields in CPUID correctly.

I think these should probably be cpu object properties, if
we do them at all. Non-buggy guest code should not care whether
it is running on an r2p1 or an r2p0, so mostly trying to provide
lots of rev/patchlevel variations just means we get an accumulation
of very similar CPUs, which we then don't actually emulate
to a level of accuracy that would mean they make a difference
to the guest.

Do you have real-world guest code that breaks?

thanks
-- PMM

Re: [Qemu-devel] [RFC] Cortex-M different revisions

[Liviu Ionescu]

> On 21 Jun 2015, at 17:09, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> Non-buggy guest code should not care whether
> it is running on an r2p1 or an r2p0,

probably not, but code developed on an emulated r2 might very well break on a physical r0. 

> I think these should probably be cpu object properties, ...
> we get an accumulation
> of very similar CPUs, which we then don't actually emulate
> to a level of accuracy that would mean they make a difference
> to the guest.

I was considering to differentiate them only by cpu->midr, this should be easy.

later, when implementing accurate exception handling, I would need just to test the midr bits; I'm not sure it is worth to define properties for these things alone.

> Do you have real-world guest code that breaks?

yes, early M3 cores (for example the venerable STM32F1xx devices) have such issues that need to be addressed, usually at RTOS level, otherwise faults are raised.

I cannot confirm (because it was quite a while ago when I had to deal with these issues) that it is possible to write code that works an all versions without checking the actual version and acting differently.

my cortex-mcu object is now prepared for dealing with different versions, but for the moment I'll postpone extending the list of cpu's until really needed.


regards,

Liviu

Re: [Qemu-devel] [RFC] Cortex-M different revisions

[Peter Maydell]

On 21 June 2015 at 15:42, Liviu Ionescu <ilg@livius.net> wrote:
>
>> On 21 Jun 2015, at 17:09, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> Non-buggy guest code should not care whether
>> it is running on an r2p1 or an r2p0,
>
> probably not, but code developed on an emulated r2 might
> very well break on a physical r0.

There's lots of code that will run on QEMU but break on
real hardware. Emulation is not a substitute for testing
on the real thing.

> I was considering to differentiate them only by cpu->midr, this should be easy.
>
> later, when implementing accurate exception handling, I would need
> just to test the midr bits; I'm not sure it is worth to define
> properties for these things alone.

If you want to emulate them then please use properties. Tagging
things off the MIDR is not something we do for any other
CPU property.

>> Do you have real-world guest code that breaks?
>
> yes, early M3 cores (for example the venerable STM32F1xx devices)
> have such issues that need to be addressed, usually at RTOS level,
> otherwise faults are raised.
>
> I cannot confirm (because it was quite a while ago when I had to
> deal with these issues) that it is possible to write code that works
> an all versions without checking the actual version and acting
> differently.

It should be -- just write to the architecture's specifications,
not to the variations between specific revisions.

-- PMM

Re: [Qemu-devel] [RFC] Cortex-M different revisions

[Liviu Ionescu]

> On 21 Jun 2015, at 23:58, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> There's lots of code that will run on QEMU but break on
> real hardware.

no doubt about it.

however, this shouldn't be the rule, if the efforts are reasonable, I see no reasons for not improving the emulation quality and make code that breaks on real hardware break on qemu too.

>> I cannot confirm (because it was quite a while ago when I had to
>> deal with these issues) that it is possible to write code that works
>> an all versions without checking the actual version and acting
>> differently.
> 
> It should be -- just write to the architecture's specifications,
> not to the variations between specific revisions.

I'll investigate when these details will become relevant, probably when my branch will be ready for running some RTOS tests. 

regards,

Liviu