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

[ckim]

 

On second thought, the 0x40000000 address had some instructions below.

0x40000000      ldr    x0, 0x40000018

0x40000004      mov    x1, xzr

0x40000008      mov    x2, xzr                                                                                                                       

0x4000000c      mov    x3, xzr

0x40000010      ldr    x4, 0x40000020

0x40000014      br     x4

This makes me think the CPU should have copied some code from the flush (addres 0) to the DRAM (0x40000000 ~ ) and jumped to 0x40000000. (because DRAM have garbage after reset).

So even though I gave “-kernel test.bin”, it runs the code in the flash (or does rom code copies code in the flash to DRAM?) probably.

I ran qemu with -s -S option and connected to the ‘program’ running on qemu using gdb-multiarch (through target remote:1234).

Doesn’t gdb show from the reset vector of the processor?

Please give me some advice.

Thank you.

 

Chan Kim

 

From: ckim@etri.re.kr <ckim@etri.re.kr>
Sent: Tuesday, February 16, 2021 3:32 PM
To: 'qemu-discuss@nongnu.org' <qemu-discuss@nongnu.org>
Subject: How is the arm 'virt' machine reset vector determined?

 

Hello, all

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).

Chan Kim