Peter Maydell <peter.mayd...@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
signature.asc
Description: PGP signature
