Discussion:
[Qemu-devel] [ARM]: Adding support for Cortex-M4
aurelio remonda
2015-05-05 12:52:47 UTC
Permalink
Hi, i would like to to add support for cortex-m4 on qemu. Most features of
the Cortex-M3 and M4 are the same with the significant difference that
Cortex-M4 has DSP extensions and optional FPU. Even so, i really need some
pointers for this (im a newbie on qemu devel). I found out that qemu can
manage dsp instructions such as ADD16, ASX, SAX, etc. and all their
combinations with suffixes (u, s, sh, etc.), so half (if not all) of the
work is done.

How should I go about this? What's the standard procedure for adding a new
CPU, even if it's so similar to the existing ones? That is, which are the
relevant functions/files that I should modify, and so on.

Thanks a lot!
Peter Maydell
2015-05-05 13:04:01 UTC
Permalink
Post by aurelio remonda
Hi, i would like to to add support for cortex-m4 on qemu. Most features of
the Cortex-M3 and M4 are the same with the significant difference that
Cortex-M4 has DSP extensions and optional FPU. Even so, i really need some
pointers for this (im a newbie on qemu devel). I found out that qemu can
manage dsp instructions such as ADD16, ASX, SAX, etc. and all their
combinations with suffixes (u, s, sh, etc.), so half (if not all) of the
work is done.
To quote something from the mail I wrote last time somebody
asked about Cortex-M4:

The instructions themselves are generally supported for
the A profile cores, so getting that part right would mostly
involve enabling those feature bits for the new M4 CPU class.
The difficult bits are going to involve:
* correct trapping when fp is disabled
* getting the exception handling right, including lazy
exception frame population
* bits where M profile FP differs from A profile (eg fp
status and ID registers being memory mapped)
Post by aurelio remonda
How should I go about this? What's the standard procedure for adding a new
CPU, even if it's so similar to the existing ones? That is, which are the
relevant functions/files that I should modify, and so on.
For a new ARM CPU, the files you want are all in target-arm/.

-- PMM
aurelio remonda
2015-05-12 12:46:23 UTC
Permalink
Im using lm3s6965evb stellaris board, trying to make it "work as an M4", i
would like to separate them, adding an dsp feature (i.e ARM_FEATURE_DSP)
could work? the problem is if this feature is added it has to be set on all
the cpus that use dsp instructions.
Peter Maydell
2015-05-12 12:58:03 UTC
Permalink
Post by aurelio remonda
Im using lm3s6965evb stellaris board, trying to make it "work as an M4", i
would like to separate them, adding an dsp feature (i.e ARM_FEATURE_DSP)
could work? the problem is if this feature is added it has to be set on all
the cpus that use dsp instructions.
You need to create a new Cortex-M4 CPU model, which can then set
the correct feature switches for the instructions and functionality
that that CPU has. If there's something that only exists on a
subset of CPUs but which we're currently providing everywhere
then we need to add a new feature bit and set it on the CPUs
which have it but not the ones which don't.

-- PMM
aurelio remonda
2015-05-26 15:29:28 UTC
Permalink
Im working on the ARM_FEATURE_DSP. I could use some help to add it to the
other CPUs that use it, maybe if someone can
provide me with a list of them i could add the feature.
Peter Maydell
2015-05-26 15:36:07 UTC
Permalink
Post by aurelio remonda
Im working on the ARM_FEATURE_DSP. I could use some help to add it to the
other CPUs that use it, maybe if someone can
provide me with a list of them i could add the feature.
Can you explain what behaviour you're turning on and off
with this feature bit? (Ideally with a reference to the M
profile architecture reference manual). Then I can probably
answer the question about what other CPUs have the feature.

thanks
-- PMM
aurelio remonda
2015-05-26 17:13:40 UTC
Permalink
There are 85 instructions labeled as DSP (all of them thumb2), im just
testing on disas_thumb2_insn if the feature is enabled before the
instruction is generated.i.e.
if (!arm_dc_feature(s, ARM_FEATURE_DSP)) goto illegal_op;
Im using DDI0439B_cortex_m4_r0p0_trm - Cortex-M4 Technical Reference Manual
(there's s table of dsp instructions on page 33) and this
Loading Image... as reference.
Post by Peter Maydell
Post by aurelio remonda
Im working on the ARM_FEATURE_DSP. I could use some help to add it to the
other CPUs that use it, maybe if someone can
provide me with a list of them i could add the feature.
Can you explain what behaviour you're turning on and off
with this feature bit? (Ideally with a reference to the M
profile architecture reference manual). Then I can probably
answer the question about what other CPUs have the feature.
thanks
-- PMM
Peter Maydell
2015-05-26 17:34:28 UTC
Permalink
Post by aurelio remonda
There are 85 instructions labeled as DSP (all of them thumb2), im just
testing on disas_thumb2_insn if the feature is enabled before the
instruction is generated.i.e.
if (!arm_dc_feature(s, ARM_FEATURE_DSP)) goto illegal_op;
Im using DDI0439B_cortex_m4_r0p0_trm - Cortex-M4 Technical Reference Manual
(there's s table of dsp instructions on page 33) and this
http://www.lpcware.com/system/files/1100969_Cortex-Inst.jpg as reference.
Ah, right. I suggest we call this
ARM_FEATURE_THUMB_DSP /* DSP insns supported in the Thumb encodings */
and in arm_cpu_realizefn() just after the bit where we set ARM_FEATURE_CBAR
you want:
if (arm_feature(ARM_FEATURE_THUMB2) && !arm_feature(ARM_FEATURE_M)) {
set_feature(env, ARM_FEATURE_THUMB_DSP);
}

because all A and R profile cores with Thumb2 have these instructions.
You'll also want to set the THUMB_DSP feature bit for your new M4
core in its cortex_m4_initfn(), and that should be enough.

(I think "THUMB_DSP" is better than "DSP" because in the ARM encoding
we won't look at this feature bit, because the presence of the insns
is determined by the architecture version -- some come in in v5 and the
rest in v6.)

For floating point, is it sufficient to turn on ARM_FEATURE_VFP4 for
the M4, or does that enable too much?

thanks
-- PMM
aurelio remonda
2015-05-28 15:28:29 UTC
Permalink
At first sight VFP4 is sufficient, im focusing on DSP instructions because
FPU is optional on Cortex-M4 (there is Cortex-M4 and Cortex-M4F) so on
cortex_m4_initfn im not adding ARM_FEATURE_VFP4 (right now I dont have the
time to fully check this).
I'd like to point out that i did not implement any board, so on armv7m_init
function of armv7m.c the cpu_model is still cortex-m3 as it should, as far
as i know the board will use this function to name cpu_model (i.e
stellaris.c will call armv7m_init and cpu_model will be "cortex-m3")
Post by aurelio remonda
Post by aurelio remonda
There are 85 instructions labeled as DSP (all of them thumb2), im just
testing on disas_thumb2_insn if the feature is enabled before the
instruction is generated.i.e.
if (!arm_dc_feature(s, ARM_FEATURE_DSP)) goto illegal_op;
Im using DDI0439B_cortex_m4_r0p0_trm - Cortex-M4 Technical Reference
Manual
Post by aurelio remonda
(there's s table of dsp instructions on page 33) and this
http://www.lpcware.com/system/files/1100969_Cortex-Inst.jpg as
reference.
Ah, right. I suggest we call this
ARM_FEATURE_THUMB_DSP /* DSP insns supported in the Thumb encodings */
and in arm_cpu_realizefn() just after the bit where we set ARM_FEATURE_CBAR
if (arm_feature(ARM_FEATURE_THUMB2) && !arm_feature(ARM_FEATURE_M)) {
set_feature(env, ARM_FEATURE_THUMB_DSP);
}
because all A and R profile cores with Thumb2 have these instructions.
You'll also want to set the THUMB_DSP feature bit for your new M4
core in its cortex_m4_initfn(), and that should be enough.
(I think "THUMB_DSP" is better than "DSP" because in the ARM encoding
we won't look at this feature bit, because the presence of the insns
is determined by the architecture version -- some come in in v5 and the
rest in v6.)
For floating point, is it sufficient to turn on ARM_FEATURE_VFP4 for
the M4, or does that enable too much?
thanks
-- PMM
Liviu Ionescu
2015-05-28 16:00:34 UTC
Permalink
... I'd like to point out that i did not implement any board
that's ok, I started from the other end, I'm working on implementing various boards and MCUs (for the list see http://gnuarmeclipse.livius.net/blog/qemu/#Supported_boards), but for now I compile all my tests with -mcpu=cortex-m3.

probably at some point in the future we'll meet at the middle :-)


regards,

Liviu
Liviu Ionescu
2015-05-30 19:27:28 UTC
Permalink
I could not follow the details of this patch, but since it touches the core of qemu, are there any tests available to check if these instructions are emulated correctly?


regards,

Liviu
Peter Crosthwaite
2015-05-30 20:10:20 UTC
Permalink
Post by Liviu Ionescu
I could not follow the details of this patch, but since it touches the core of qemu, are there any tests available to check if these instructions are emulated correctly?
I think the risu tool is able to do something. A quick look at the
readme shows it should have thumb support:

https://git.linaro.org/people/peter.maydell/risu.git/blob/HEAD:/README

Regards,
Peter
Post by Liviu Ionescu
regards,
Liviu
Peter Maydell
2015-05-30 20:54:30 UTC
Permalink
Post by Peter Crosthwaite
I think the risu tool is able to do something. A quick look at the
https://git.linaro.org/people/peter.maydell/risu.git/blob/HEAD:/README
It does rely on the remote end running Linux though, which is
a bit tricky for the M3.

-- PMM
Peter Crosthwaite
2015-05-30 20:58:33 UTC
Permalink
Post by Peter Maydell
Post by Peter Crosthwaite
I think the risu tool is able to do something. A quick look at the
https://git.linaro.org/people/peter.maydell/risu.git/blob/HEAD:/README
It does rely on the remote end running Linux though, which is
a bit tricky for the M3.
Yeh so it's not good for the new CPU, but the core changes touch all
the thumb world, so it may still be worth something as a regression
test for other thumb capable procs.

Regards,
Peter
Post by Peter Maydell
-- PMM
Liviu Ionescu
2015-05-05 13:12:33 UTC
Permalink
Hi, i would like to to add support for cortex-m4 on qemu. ...
For your information, I'm also planning to improve support for the Cortex-M family in my GNU ARM Eclipse QEMU fork. My first priority is fully supporting the Cortex-M system peripherals, then the main STM32F peripherals (like clocks), and later consider the M4 instruction set, so if you plan some work on this, perhaps it would be useful to coordinate our efforts.


regards,

Liviu
aurelio remonda
2015-05-07 18:00:26 UTC
Permalink
Im replying this cause i made a mistake asking to someones private mail,
OK, another question. How come if Cortex-M3 doesnt support DSP
instructions
qemu understand them? I tried some of them with an stellaris lm3s6965evb.
I
do understand that they were implemented for the A profile cores, but not
for M ones. Is this a bug or im missing something?
If our cortex-m3 model doesn't fault on an instruction that's not
implemented in the M3 then that's a bug, yes. If you provide more
detail we can fix it.
Hi, i would like to to add support for cortex-m4 on qemu. Most features of
the Cortex-M3 and M4 are the same with the significant difference that
Cortex-M4 has DSP extensions and optional FPU. Even so, i really need some
pointers for this (im a newbie on qemu devel). I found out that qemu can
manage dsp instructions such as ADD16, ASX, SAX, etc. and all their
combinations with suffixes (u, s, sh, etc.), so half (if not all) of the
work is done.
How should I go about this? What's the standard procedure for adding a new
CPU, even if it's so similar to the existing ones? That is, which are the
relevant functions/files that I should modify, and so on.
Thanks a lot!
Continue reading on narkive:
Loading...