On Tue, 16 Feb 2021 at 06:34, <c...@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
