Peter Maydell <peter.mayd...@linaro.org> writes: > So, I'm really dubious about adding more "virtual" > not-real-hardware boards. We have "virt" because we > absolutely have to have it for KVM purposes; but otherwise > "emulate real hardware" gives us a concrete specification > of what we're trying to do and tends to lead us into fewer > messy swamps than making up virtual platforms does.
It depends on what you're using qemu for. I'm using it for C library tests, where I need memory and a processor, plus the ability to make semihosting calls and that's it. It seems like it should be possible to construct a virtual platform that is limited to just these elements without getting too far into the weeds? > For instance, this board model claims to handle the M33 > but makes no attempt to set up any of the TrustZone > related components like the IDAU, so it isn't really > a useful platform for that CPU. It's sufficient for my purposes, if adding those things would make it suitable for more people, that'd be awesome. > You also enable bitband, which is maybe plausible for Cortex-M3/M4 but > not for the others. Thanks for the bug report; bits of this code came from the stellaris code, including that part. I'll review the code in more detail to make sure it doesn't expose any features which aren't supposed to be. That will catch toolchain bugs which attempt to use features not present in the hardware, which is critical to successful validation. > This is the kind of area where having a real hardware system to check > against means we make the right choices about what does or doesn't > need to be present. I have tried every single 32-bit ARM emulation provided by qemu and none of them offer enough memory along with the ability to select an arbitrary processor. The stellaris code is the closest as it allows overriding the CPU type, and I've been able to run most of the C library tests using that. However, both boards supported by that code have a small fixed memory size, which isn't large enough to run the full test suite (the math tests require over 1M of ROM and RAM). Instead of creating another virtual platform, should I be working on the existing virt code to add cortex-m support? Ideally, I'd be able to emulate the full set of configurations that the embedded ARM GCC port does. I'm currently using the 2019-q3 release, which offers 18 configurations. Before I included 'virtm', I was able to test only one of them using the mps2-an385 emulator. With virtm, I'm covering 11 of them. The 'virt' emulator should cover the cortex-a7 cases, leaving only four cases untested (I haven't figured out the right configuration to run bare metal code on that yet). I can't find any ARM processors which implement v8-m with DP support, and the only QEMU module with v5te support appears to be digic, which I haven't experimented with at all. Architecture FPU QEMU -cpu Picolibc tests ---- ----- ------ --------- -------------- arm v5te softfp arm946 arm v5te hard arm946 thumb v7 nofp cortex-a7 thumb v7+fp softfp cortex-a7 thumb v7+fp hard cortex-a7 thumb v6-m nofp cortex-m0 yes thumb v7-m nofp cortex-m3 yes thumb v7e-m nofp cortex-m4 yes thumb v7e-m+fp softfp cortex-m4 yes thumb v7e-m+fp hard cortex-m4 yes thumb v7e-m+dp softfp cortex-m7 yes thumb v7e-m+dp hard cortex-m7 yes thumb v8-m.base nofp cortex-m33 yes thumb v8-m.main nofp cortex-m33 yes thumb v8-m.main+fp softfp cortex-m33 yes thumb v8-m.main+fp hard cortex-m33 yes thumb v8-m.main+dp softfp thumb v8-m.main+dp hard -- -keith
signature.asc
Description: PGP signature