On Fri, 26 Jun 2020 at 17:40, Keith Packard <kei...@keithp.com> wrote: > > 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.
You might find the user-mode qemu-arm sufficient for that kind of thing. I know some gcc tests run that way. You get a processor, semihosting, and whatever memory your ELF file's data segment says you have (plus anything you care to mmap()). > > 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. Sure, but "machine-that-works-for-keith-packard" isn't really a very clearly-defined concept :-) > > 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? I think that trying to weld M-profile into the A-profile virt board is likely to be more confusing than having a separate board. But I remain unhappy about defining a virtual board at all if I can avoid it. thanks -- PMM