qemu-arm
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]