On 5 February 2017 at 14:27, Hrishikesh Murukkathampoondi <hris...@gmail.com> 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 gic-version=help 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 architecture. (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, though.) I would also suggest -semihosting 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.) thanks -- PMM