[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/arm: Add 'virtm' hardware
From: |
Keith Packard |
Subject: |
Re: [PATCH] hw/arm: Add 'virtm' hardware |
Date: |
Fri, 26 Jun 2020 09:40:42 -0700 |
Peter Maydell <peter.maydell@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