Re: How is the arm 'virt' machine reset vector determined?

[Peter Maydell]

On Tue, 16 Feb 2021 at 06:34, <ckim@etri.re.kr> wrote:
> I’m trying to run a simple baremetal program and I tried to put the program 
> in 0x00000000 (flash).
>
> But using debugger, I found the PC value is starting from 0x40000000. (start 
> of RAM area)
>
> How is this reset vector determined in ‘virt’ machine? (I understand in 
> armv8, it is configured by H/W).

The initial starting address depends on your command line options:
 * if you pass a Linux kernel with -kernel, then we boot it as
   the Linux kernel requires, which includes setting the CPU state
   up to match the kernel boot protocol, and starting it via a little
   stub bootloader a few instructions long at the base of RAM.
   The -kernel option assumes that anything it is handed that is
   not an ELF file is a Linux kernel.
 * if you pass an ELF file either via -kernel or via the "generic
   loader" device, then we start at the entry point specified by
   the ELF file
 * otherwise, we start the emulation in the same way that hardware
   does, with a CPU reset to the reset vector at address 0.
   Unless you have passed QEMU a firmware image to be loaded into the
   flash that is at address 0 (using either -bios or -drive if=pflash)
   then this will cause the emulated CPU to either execute NOPs or to
   go into an infinite loop of exceptions, depending on whether it's
   32-bit or 64-bit...)

So for a bare metal program you want to load it via either:
 * -bios
 * -drive if=pflash...
 * as an ELF file where you have made sure the ELF entry point is
   set to the address you want execution to start from

thanks
-- PMM