Re: Hello world example with qemu-system-arm

[Peter Maydell]

On Wed, 11 May 2022 at 20:50, James Gutbub <jgutbub@asu.edu> wrote:
> I am digging into qemu-system-arm to try and execute some simulation
> environment unit tests with no underlying board/device interaction,
> at most I need semihosting to print out some results.

> The intended target for my hello world using arm-none-eabi-gcc
> is Cortex-R5F (e.g. -mcpu=cortex-r5 -mfpu=vfpv3-d16 -mfloat-abi=hard).

> I am not finding a way to successfully execute my hello world example
> using ‘qemu-system-arm -cpu cortex-r5f -M none -nographic -semihosting’
> and the payload variants below:

You need to specify a real machine type. QEMU is not designed
to provide a "just the CPU" emulation environment. There are
two modes:

 (1) system emulation, with qemu-system-arm, which gives you
a model of some actual board. Your guest code usually needs
to be written to work on that board (at a minimum, linked to
an address where the board has RAM)
 (2) usermode emulation, with qemu-arm, which runs code at
emulated EL0 (userspace) with access to Linux syscalls and
also the semihosting ABI

You're also at a disadvantage in wanting Cortex-R5F : we have
no system emulation board models where that is the main CPU.
(We have it for some Xilinx board models which have Cortex-A72
cores for the main processors and also some auxiilary R5 cores.)

Depending on what your code is doing, you may be able to use
option 2. In particular your code would have to:
 * not touch any devices or other SoC or board hardware
 * be happy running only at EL0
 * only use memory which is in the ELF file's code/data/bss
   (unless you want to allocate more with Linux syscalls)

It's perhaps not impossible to get something executing with
the 'none' type, but this is definitely not a supported
use case, so you're on your own if you want to experiment.
As a starting hint, the 'none' board defaults to "no RAM",
so unless you tell QEMU to allocate some then there's nowhere
for your code to execute from.

Whichever way you want to go on this, for any kind of "I'm
not sure why my code is failing to start" question I recommend
the use of the -d debug options to tell you where the CPU
is trying to execute instructions from and what they are.
-d in_asm,exec,cpu,int,unimp,guest_errors,nochain is usually
a good set of options; but watch out that 'in_asm' shows
when insns are translated, not when they are executed.
-D file to dump to file rather than the terminal.

thanks
-- PMM