I tried to bringup cortex m33 with QEMU, and I used board MPS2-AN505, but QEMU always abort with HardFault error, so I checked system registers with GDB and I found that the T bit of ESPR reg is 0 after CPU boot, and the pc/sp is 0 too, but I have already write SP value and PC value into memory word offset 0/1
I also checked VTOR which defines the vector tables and it is 0, so sp /pc should be read out from word offset 0/1
But if I used GDB to load elf files again, the T bit of ESPR is 1 but pc/sp still not be loaded. so the program start from address 0.
I also tried with board type MPS3-AN547 which used corte-m55 with the same software code and vector table, and it works fine. PC / SP can be loaded correctly from word offset 0/1.
the QEMU version that I used is 6.2.0, and I used option -kernel xxx.bin to load my software image.
qemu error
as described above ...
qemu error debug info
Related
I am new to arm architecture.
In my testing program, there is an assembly code to read PMCR_EL0 register. (like below)
mrs x0, pmcr_el0
But when I execute the program, it occurs exception with "Illegal instruction".
I searched "ARM a53 technical reference manual", then I found following sentence.
This register is accessible at EL0 when PMUSERENR_EL0.EN is set to 1.
and EL1 was required to write a value to PMUSERENR_EL0.EN.
So, I wrote kernel module which set PMUSERENR_EL0.EN bit to 1 when it upload by insmod shell command.
But after the kernel moduel upload, when I execute my testing program there is still occuring exception with "Illegal instruction". So, I checked the value of PMUSERENR_EL0 register via additional assembly code mrs x0, PMUSERENR_EN0, and its value is still 0.
I'm not sure what went wrong. How can I set the PMUSERENR_EL0.EN bit to 1 and finally read the PMCR_EL0 register value in user space application?
My computing environment is Raspberrypi 3 B v1.2(ARM cortex A53) and raspabian 64 bit OS.
I am currently using CodeViser Jtag debugger connecting to a FPGA for debugging firmware for an Armv8 processor. From within the CodeViser GUI client (called CVD64 on windows) I can set break points at absolute addresses.
One thing I noticed that, when I set a break point at some functions in u-boot, I use the address as shown in u-boot.map, which reflects the initial loading address of u-boot. In my case, the u-boot text section is initially loaded to 0x20408000.
When the break point I set hits, the actual address the PC stops is not what I specified from GUI, but another address, which is the relocated one (i.e., after u-boot relocation).
For example, I set break point from GUI at 0x20413040, and CVD64 stops at 0x207ae040, the offset is 0x39b000. This offset is exactly the same as u-boot itself printed to serial port:
Relocation Offset is: 0039b000
Relocating to 207a3000, new gd at 2075edf0, sp at 2075ede0
This is nice. I am just wondering how CVD64 knows the relocate offset and automatically place HLT instruction in relocated address?
Thanks!
Hi I’m newbie to ARM and am using a SAM3S4A ARM processor, with the IAR compiler.
Understanding that the flash code is from 0x00400000 – 0x0043FFFF and that the processor start at address zero (0x00000000), how does the PC jump to 0x00400000 as the VTOR register is zero at default.
From what I could understand from the document, ARM proc goes to 0x0 on reset. The 4K address space at 0x00000000 can be mapped to either ROM or FLASH using GPNVM register. So at reset ARM starts executing code either from ROM or FLASH. (ROM contains some proprietary bootloader and you can have your own OS/Bootloader at Flash). Once control reaches the code you have written to flash, you can setup a new Vector Table and update VTOR so that new exceptions are routed there.
My goal is to let my own kernel start an application cpu. It uses the same mechanism as the linux kernel:
Send asserting and level triggered init-IPI
Wait...
Send deasserting and level triggered init-IPI
Wait...
Send up to two startup-IPIs with vector number (0x40000 >> 12) (the entry code for the application processor lies there)
Currently I'm just interested in making it work with QEMU. Unfortunately, instead of jumping to 0x40000, the application cpu jumps to 0x0 with the cs register set to 0x4000. (I checked with gdb).
The Intel MultiProcessor Specification (B.4.2) explains that the behavior that I noticed is valid if the target processor is halted immediately after RESET or INIT. But shouldn't this also apply to the code of the linux kernel? It sends the startup-IPI after the init-IPI. Or do I misunderstand the specification?
What can I do to have the application processor jump to 0x000VV000 and not to 0x0 with the cs register set to 0xVV00? I really can't see, where linux does something that changes the behavior.
It seems that I really misunderstood the specification: Since the application cpu is started in real mode 0x000VV000 is equivalent to 0xVV00:0x0000. It is not possible to represent the address just in the 16 bit ip register. Therefore a segment offset for the code segment is required.
Additionally, debugging real mode code with gdb is comparable complicated because it does not respect the segment offset. When required to see the disassembled code of the trampoline at the current position, it is necessary to calculate the physical location:
x/20i $eip+0xVV000
This makes gdb print the next 20 instructions at 0xVV00:$eip.
I'm trying to use usermode and SVC in my ARMv6 bare metal application, but for this I need to set up the SVC entry of the ARMv6 interrupt vector table to branch to my interrupt handler. But, I can't find a good example on how to do this (ie: what memory address exactly I need to set, and to what). I have done similar things in the past, but always with a more comprehensive bootloader (RedBoot) that set up some of this for me. Any help would be appreciated.
I am testing my application using:
qemu-system-arm -M versatilepb -cpu arm1176
Are you talking about the SWI interrupt? Or one of the others (FIQ, IRQ). In either case I think I know what the problem is. Qemu is for running linux, your binary is not loaded at address 0x00000 so your entry points are not used by qemu for handling exceptions.
I have an example that uses qemu and implements a solution. Go to the qemu directory of http://github.com/dwelch67/yagbat. The qemu example is not really related to the gba thing in the yagbat repo, the gba is a 32 bit ARM thing so it was easy to borrow code from so I stuck it there.
The example was specifically written for your question as I tried to figure out how to use qemu in this manner. It appears that the address 0x00000000 space is simulated as ram, so you can re-write the qemu exception table and have the exceptions call code in the 0x10000 address space that your binary loads.
A quick and dirty solution is to make the entry point of the binary (that qemu loads to 0x10000) resemble a vector table at address 0x00000. The ldr pc instruction is relative to the program counter, the disassembly might show that it is loading an address at 0x10000 but it is really relative to the pc and the disassembler used the pc assuming the linked address being used.
.globl _start
_start:
ldr pc,start_vector_add
ldr pc,undef_vector_add
ldr pc,swi_vector_add
start_vector_add: .word start_vector
undef_vector_add: .word undef_vector
swi_vector_add: .word swi_vector
Then before you want to cause any interrupts, in the example I use the swi instruction to cause an swi interrupt. You copy enough of the code from 0x10000 to 0x00000 to include the exception table and the list of addresses that it loads into the pc. by linking your program to 0x10000 those addresses are in the 0x10000 range. When the interrupt occurs, the exception handler that you have now modified will load the 0x10000 based address into the pc and your handler in the 0x10000 range will get called.
Using this command line to run the binary in my example
qemu-system-arm -M versatilepb -m 128M -kernel hello_world.bin
and then ctrl-alt-3 (not F3 but 3) will switch to the serial console and you can see the output, and close that window to close out of qemu and stop the simulation.