Re: [PATCH] hw/arm: Add 'virtm' hardware

["Keith Packard" via <qemu-devel@nongnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]

Peter Maydell <peter.maydell@linaro.org> writes:

> 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()).

Thanks for the pointer; I've spent a bit of time checking out whether
that might work, and it looks like I could get some testing done there,
but I couldn't get the chip startup code tested (things like enabling
the FPU, setting up the stack, data and bss segments).

I had always assumed that qemu-arm was designed to run user-mode Linux
applications on top of another Linux system (given that it's called
'arm-linux-user' in the qemu configuration code). That's why I hadn't
even tried using it for this work.

> Sure, but "machine-that-works-for-keith-packard" isn't really
> a very clearly-defined concept :-)

It seems well defined to me at least? An ARM core plus memory. That's
sufficient to run tests with semihosting to validate compilers,
libraries and the like. It would also serve as a model for people
developing new QEMU boards to start from; here's a processor and memory,
now you add peripherals and you've got a complete system.

This is all in service of a pretty easily explained goal -- a free
software C library designed for embedded systems that gets tested on the
target processors.

With QEMU, I'm able to incorporate all of the code necessary right in
the library to execute tests on simulated hardware that starts from the
reset vector. That same code can run on native hardware, allowing
developers to get past the usual embedded development startup hurdle of
creating a linker script, writing NVIC interrupt vector table and
initializing RAM.

I'd like to make the memory parameters configurable so that a developer
could set qemu to match their particular SoC. Then they'd be able to run
their application under QEMU and at least ensure that it gets to main()
before flashing it on the target hardware.

> 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.

Ok, that was my thinking for doing this as a separate board; the
existing virt board seems complex enough without attempting to wedge
something very different into it.

I'll experiment with the arm-linux-user mode of QEMU a bit more to see
how much testing that would enable; it should at least allow testing of
the libc and libm functions, although not the crt0 implementation and
sample linker scripts.

I'd love help in creating a better definition of what the 'virtm' board
should be, and figure out a way to explain it so that you appreciate the
value it brings to the ARM ecosystem.

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]