[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Qemu ARM64 command line parameters

From: Peter Maydell
Subject: Re: [Qemu-discuss] Qemu ARM64 command line parameters
Date: Tue, 7 Feb 2017 17:12:38 +0000

On 5 February 2017 at 14:27, Hrishikesh Murukkathampoondi
<address@hidden> wrote:
> * a flash device at 0x0
> * RAM starting at 0x40000000

You can also get away with hardcoding the UART being at
0x09000000 (since UEFI hardcodes that too).

> He mentioned that all other values like -machine gic-version= <something> etc
> I dont know what values can be provided for gic-version. Are the
> possible values documented somewhere?

Not documented, I'm afraid, but the usage message if you get them
wrong will tell you:

$ ./build/x86/aarch64-softmmu/qemu-system-aarch64 -M virt -machine
qemu-system-aarch64: Invalid gic-version value
Valid values are 3, 2, host.

"host" is for KVM use only (and means "whatever this host machine
can provide"). You probably want 3 unless you know you'd rather
have a GICv2. Default is 2 (for back-compatibility reasons).

> I am unsure what else I should specify besides GIC. Are all
> -machine options documented somewhere ?

The other useful options you want will be
 -cpu cortex-a57    # default cpu is 32-bit
 -m 1024            # 1GB of RAM (more possible; default is 128MB)

and maybe
 -machine virtualization=on    # if you want to enable EL2
 -machine secure=on            # if you want to enable EL3
...but for your use case I would suggest leaving both these disabled
unless your intention is to play with these parts of the ARM
(secure=on in particular will enable split secure and nonsecure
address spaces and put some devices only in secure, like a
second UART.)

You can also use -device options to add virtio PCI devices if you want
networking, disk, etc. (They won't affect the device tree,

I would also suggest

which will enable the semihosting ABI. Semihosting is documented
here: https://developer.arm.com/docs/100863/0200
but basically it's a mechanism for allowing you to do things
like "debug print to console" via a simple "load values into
registers and execute magic HLT 0xf000 instruction" interface.
That's likely to be easier than talking to the serial port.
For instance you can print a message with something like
    ldr x1, =string
    mov x0, 4    // SYS_WRITE0
    hlt 0xf000   // semihosting call
string: asciz "hello world\n"

Note that the semihosting ABI contains functions like
"write to a host file" so don't enable it if the guest
code is not trustworthy. Also it will only work in QEMU
if the guest code is at EL1 (system), not at EL0 (user).

> What is the first memory address fetched by the processor in
> the virt machine? (ie where should I place the first instruction
> of my bare metal code)

As on real hardware, we start at address zero (the reset
vector in the vector table), which is in the flash.
Use -bios to specify a binary blob to put in the flash.
Note that the flash is not writeable memory :-)

(This assumes you aren't passing -kernel to QEMU: if
you ask us to load a linux kernel then we'll start
execution at the start of the kernel. For your use case
you should stick with -bios and not -kernel.)

-- PMM

reply via email to

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