https://gitlab.com/qemu-project/qemu/-/commit/330ef14e6e749919c5c
https://gitlab.com/qemu-project/qemu/-/commit/1df0878cff267128393
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscrib
These fixes are now in master and will be in rc4 and the eventual 6.0
release.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923861
Title:
I tried your fix. Yes, the fpscr and mvfr0/1/2 values do match the FVP,
now (except for the MVE bit which is explained above).
Thx for the updates.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/19238
https://patchew.org/QEMU/20210416104010.13228-1-peter.mayd...@linaro.org/
should fix the "not actually an M55" bug which will then give you the
double-precision and FP16 (and the right FPSCR value).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
Yes, MVE is next on my todo list; it will probably be in 6.2, or maybe
7.0 depending how long it takes to implement it all.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923861
Title:
Hardfault wh
I changed the compile options to single precision, only. Then, my small
FP example works. Ok for my purposes, I don't need double.
But I would need MVE. Are there any plans to implement MVE?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
Oops -- we were giving the AN547 a Cortex-M33 rather than the -M55 it
ought to have :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923861
Title:
Hardfault when accessing FPSCR register
Status
Some of those ID register differences are expected; some I'm surprised by. The
differences are:
* no MVE (expected, we don't implement it yet)
* no double-precision
* no FP16
So the missing double-precision is why your vcvt UNDEFs. Those last two
ought to be present, but something is squashing
Thanks for the fix. I applied it and
1. yes, the hard fault when reading FPSCR is gone.
2. yes, I also see the UNDEF. Note that on the Corstone-300 MPS3-AN547 FVP I
can access mvfr0 via vmrs.
I changed the vmrs to ldr. Now I can read the registers. The values differ from
what the FVP tells me:
f
The bug fix for the QEMU part of this is
https://patchew.org/QEMU/20210415182353.8173-1-peter.mayd...@linaro.org/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923861
Title:
Hardfault when accessi
Thanks. This is a bug in the AN547 model -- we were accidentally turning
off the FPU. I'll write a patch.
NB that with that bug fixed your code then hits an UNDEF trying to do:
0x0996: eef7 1a10 vmrs r1, mvfr0
Only A-profile CPUs have MVFR0 accessible via the vmrs instruction. For
M-p
Command line is
qemu-system-arm -machine mps3-an547 -nographic -kernel test.elf -semihosting
-semihosting-config enable=on,target=native
Binary is attached. It does
int main(int argc, char* argv[])
{
SCB->NSACR |= (3U << 10U);/* enable Non-secure access to
CP10 and CP11 copr
Do you have a guest binary and QEMU commandline I can use to reproduce
the issue ?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1923861
Title:
Hardfault when accessing FPSCR register
Status in QE
Yes, I think I did:
SCB->NSACR |= (3U << 10U);/* enable Non-secure access to
CP10 and CP11 coprocessors */
__DSB();
__ISB();
SCB->CPACR |= ((3U << 10U*2U) | /* enable CP10 Full Access */
(3U << 11U*2U) ); /* enable CP11 Full A
Does your code enable the FPU (via the CPACR and, if running in
NonSecure) the NSACR? If not then a fault is exactly what you should
expect. (I believe the FVP has a non-standard behaviour where it will
enable the FPU by default even though real hardware does not behave that
way.)
--
You received
** Description changed:
QEMU release version: v6.0.0-rc2
command line:
qemu-system-arm -machine mps3-an547 -nographic -kernel .elf
-semihosting -semihosting-config enable=on,target=native
host operating system: Linux ISCNR90TMR1S 5.4.72-microsoft-standard-WSL2
#1 SMP Wed Oct 28 23
16 matches
Mail list logo
