Released with QEMU v5.2.0.
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1872237
Title:
SysTick reload behavior emulated
Merged:
https://patchew.org/QEMU/20201015151829.14656-1-peter.mayd...@linaro.org/
Commits:
https://gitlab.com/qemu-project/qemu/-/commit/68d59c6d8d85ae176d3cb2cd20a48d6a090ba288
https://gitlab.com/qemu-project/qemu/-/commit/32bd322a0134ed89db00f2b9b3894982db3dedcb
** Changed in: qemu
I believe this bug should be fixed by this patchset, which rewrites the systick
implementation to use a 'ptimer' down-counter instead of rolling its own buggy
version:
https://patchew.org/QEMU/20201015151829.14656-1-peter.mayd...@linaro.org/
** Changed in: qemu
Status: New => In
Other than the systick issue, I think the core M-profile emulation
should be pretty solid (bugs are always possible, of course). We have
support for v6M (cortex-m0), v7M (cortex-m3, m4) and v8M (cortex-m33,
including the security extension) and at least some board models for all
of those. No v8.1M
@pmaydell: Thanks for the quick response! For whatever it's worth, I think
that there's definitely a bunch of interest in the M-profile work: in the
embedded Rust space (for example) Cortex-M is very much the reference
platform. Viz. the Embedded Rust Book:
Yeah, our systick implementation is broken; I've known about this for
ages but never got round to trying to work through what the right way to
implement the behaviour is. I do have some more time to work on
M-profile stuff coming up at some point so I might get round to this if
nobody else does
