Good news, I thought at least some of them were not implemented because
for instance I couldn't find where VRINTA is handled (I noticed code for
NEON_2RM_VRINTA, but I thought there should be something in vfp.decode
for VRINT[ANPM])
--
You received this bug notification because you are a member
They are implemented, because they also appear in A-profile.
We just need to set the corresponding MVFR field to enable them.
Setting MVFR2.FPMISC = 4 will do the job, I believe.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
It seemed "easy" to add cortex-m7 based on cortex-m4 (copy m4
description, update ID register values), but I realized that QEMU does
not support FPv5 which not only supports DP, but also adds new
instructions that QEMU does not handle yet (see section A2.5 of the
ARMv7-M ARM).
* Are there plans
You can't for an M-profile CPU. It would work without any further coding
beyond getting the ID register values right if we had a Cortex-M7 model,
though.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
How do I activate it since --cpu cortex-m7 isn't supported?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721275
Title:
Support more ARM CPUs
Status in QEMU:
Won't Fix
Bug description:
Hi,
Yes, QEMU supports DP (I actually had to go to some lengths to disable
the DP support for the M4 :-))
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721275
Title:
Support more ARM CPUs
Status in
Regarding Cortex-M7, I've noticed that unlike Cortex-M4, it supports
double precision floating-point. Is DP supported by qemu?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1721275
Title:
Support
We now support Cortex-M0 (v6M) and Cortex-M33 (v8M mainline). We don't
have Cortex-M7, Cortex-M23 (v8M baseline) or Cortex-A35.
In general, adding an extra CPU to QEMU really requires us to have a
decent use-case for it, probably including a board model for it,
especially for the M-profile CPUs.
On 16 October 2017 at 14:16, Christophe Lyon
wrote:
> Thanks for PS, I thought QEMU was stricter than that.
Well, I hope we get it right, and we'll treat cases where
we get it wrong as bugs, but we're not testing...
> Regarding v[68]M, are there any plans to
Thanks for PS, I thought QEMU was stricter than that.
Regarding M7 vs M$ or A35 vs A53/A57, even though there's no functional
difference, it would be convenient in Makefiles to have CPU=cortex-a53,
and use $(CPU) to expand GCC and QEMU options, without having to guess
which CPU I should use for
PS: in general I wouldn't unconditionally trust that QEMU emulating CPU
X definitely does not implement any instructions that CPU X doesn't have
-- no real world code will notice, and we don't have any mechanism to
automatically verify that we didn't accidentally forget to
conditionalize an
M0 is hard, because it's v6M which we don't support. M4 we already have
(but only the no-fpu variant). M7 we don't currently have -- what would
be the differences from M4? M33 is in the works (it's v8M). M23 is
harder, because it's v8M-baseline which is the v8M equivalent to v6M.
A53 and A57 we
12 matches
Mail list logo