cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dcabanis
Visitor
Visitor
2,517 Views
Registered: ‎04-23-2019

Running an assembly application on Cortex-R5 QEMU with GDB problem

Jump to solution

Hello, dear community,

I am having a problem running an assembly application on the Cortex-R5 implementation of the Ultrascale+ QEMU.

The application runs perfectly well on the Zynq7000 Cortex-A9 QEMU. I am also able to run an A64 based assembly on the Ultrascale+ Cortex-A53 but I simply cannot get the Cortex-R5 working.

Here are the detailed steps and various outcome. The two source files are written in ARMv7-r (UAL) assembly code. I am using the latest Xilinx-QEMU implementation compiled from source (already working for A9, A53).

 

# startup.S

.section .text
.syntax unified
.global _start

_start:
b _Reset

_Reset:
b _run

.end

 

# run.S

.section .text
.syntax unified
.global _run

_run:

ldr r0,=55
ldr r1,=88
add r2,r1,r0

spinlock:
b .


.section .data
_source: @ source data
.word 0xAAAAAAAA
.word 0xBBBBBBBB
.word 0xCCCCCCCC
.word 0xDDDDDDDD
.word 0xEEEEEEEE
.word 0xFFFFFFFF
.word 0x11111111
.word 0x22222222
_dest: @ destination data
.space 32 @ reserve 8 words of memory

.end

 

# Assemble and link

/opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g run.S -o run.o
/opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g startup.S -o startup.o
/opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-ld -Tarm.ld -o exec.elf startup.o run.o


# Run QEMU

qemu-system-aarch64 -M xlnx-zcu102 -smp 6 -serial mon:stdio -nographic -device loader,file=exec.elf,cpu-num=4 -global xlnx,zynqmp.boot-cpu="rpu-cpu[0]" -s -S

QEMU 2.11.1 monitor - type 'help' for more information

(qemu) info cpus

* CPU #0: (halted) thread_id=28597
CPU #1: (halted) thread_id=28598
CPU #2: (halted) thread_id=28599
CPU #3: (halted) thread_id=28600
CPU #4: thread_id=28601
CPU #5: (halted) thread_id=28602

(qemu) cpu 4

(qemu) info cpus

CPU #0: (halted) thread_id=28597
CPU #1: (halted) thread_id=28598
CPU #2: (halted) thread_id=28599
CPU #3: (halted) thread_id=28600
* CPU #4: thread_id=28601
CPU #5: (halted) thread_id=28602

(qemu) info registers

R00=00000037 R01=00000058 R02=0000008f R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00000014
PSR=400001d3 -Z-- A svc32
FPSCR: 00000000

# Run GDB

/opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-gdb ./exec.elf


(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: while parsing target description (at line 149): Target description specified unknown architecture "aarch64"
warning: Could not load XML target description; ignoring
Remote 'g' packet reply is too long (expected 168 bytes, got 268 bytes): 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c5030040

It seems that QEMU identifies itself to gdb as an aarch64 (ARMv8-A execution state) machine although the info cpu command inform that only one cortex-R5 (arm execution state) is out of reset mode and the list of registers (info registers) is clearly the Cortex-R5 set. Has anyone managed to run QEMU (Cortex-R5) along with gdb? I have seen a similar question but no answer was provided.

Kindly,

David Cabanis.

1 Solution

Accepted Solutions
dcabanis
Visitor
Visitor
2,337 Views
Registered: ‎04-23-2019

Hello Abdallah,

Here is a summary of what I did to get this to work. I hope this will be helpful to others.

 

Running bare metal code on the Zynq Ultrascale+ Cortex-R5 QEMU

Tools

This configuration runs on Ubuntu 16.06 (64bit) with the standard C build tools (binutils) installed.

GNU Compiler toolchain (cross-compiling)

gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi

Found here:

https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-eabi/

gdb multi-architecture

gdb needs to be manually configured to support multiple architectures (arm /aarch64)

git clone --branch gdb-8.3-branch git://sourceware.org/git/binutils-gdb.git
cd binutils-gdb/
./configure --enable-targets=all

QEMU

QEMU emulator version 2.11.1 (v2.6.0-13192-g29ed507-dirty)

Found here:

https://github.com/Xilinx/qemu

Running the session

  1. Compile (assemble) and link the various source files.

  2. QEMU is started first in a terminal window.

  3. gdb is started second in a new terminal window.

Sample source files

startup.S

.section .text
.syntax unified
.global _start

_start:
b _Reset

_Reset:
b _run

.end

run.S

.section .text
.syntax unified
.global _run

_run:

ldr r0,=55
ldr r1,=88
add r2,r1,r0

spinlock:
b .

.section .data
_source: @ source data
.word 0xAAAAAAAA
.word 0xBBBBBBBB
.word 0xCCCCCCCC
.word 0xDDDDDDDD
.word 0xEEEEEEEE
.word 0xFFFFFFFF
.word 0x11111111
.word 0x22222222
_dest: @ destination data
.space 32 @ reserve 8 words of memory

.end

arm.ld

ENTRY(_start)
SECTIONS
{
. = 0x0;
.startup . : { startup.o(.text) }
.text : { *(.text) }
.data : { *(.data) }
.rodata : { *(.rodata) }
.bss : { *(.bss) }
. = . + 0x1000; /* 4kB of stack memory */
stack_top = .;
}

Assembling and linking

<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g run.S -o run.o
<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g startup.S -o startup.o
<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-ld -Tarm.ld -o exec.elf startup.o run.o

QEMU launch

<install_dir>/aarch64-softmmu/qemu-system-aarch64 -M xlnx-zcu102 -smp 6 -serial mon:stdio -nographic -device loader,file=exec.elf,cpu-num=4 -global xlnx,zynqmp.boot-cpu="rpu-cpu[0]" -s -S

gdb session

<install_dir>/binutils-gdb/gdb/gdb
(gdb) target extended-remote :1234
(gdb) add-inferior
(gdb) inferior 2
(gdb) file ./exec.elf
(gdb) attach 2

And voila! Thank you very much for your help, Abdallah.

Kindly,

David Cabanis

View solution in original post

0 Kudos
Reply
7 Replies
abouassi
Moderator
Moderator
2,459 Views
Registered: ‎03-25-2019

Hi @dcabanis ,

You need to use the multiarch version of GDB "gdb-multiarch" to be able to connect to our Qemu Stub properly in order to debug either A53 or R5 cores.
Please refer to this link for further details on how to use GDB multiarch to connect properly to the R5 core.

 

Best regards,
Abdallah
-------------------------------------------------------------------------------
Please don't forget to reply, kudo and accept as a solution
0 Kudos
Reply
dcabanis
Visitor
Visitor
2,440 Views
Registered: ‎04-23-2019

Hello Abdallah,

Thanks you for your response.

In the original message I had tried to keep it short and sharp. I had however tried the gdb-multiarch solution with the same outcome. Here is the result of the gdb-multiarch session:

For information I installed gdb-multiarch via: apt on Ubuntu 16.04

I have invoked QEMU in the exact same way as before, specifying the use to the Cortex-R5 and the executable exec.elf

qemu-system-aarch64 -M xlnx-zcu102 -smp 6 -serial mon:stdio -nographic -device loader,file=exec.elf,cpu-num=4 -global xlnx,zynqmp.boot-cpu="rpu-cpu[0]" -s -S

(qemu) info cpus
* CPU #0: (halted) thread_id=5935
CPU #1: (halted) thread_id=5936
CPU #2: (halted) thread_id=5937
CPU #3: (halted) thread_id=5938
CPU #4: thread_id=5939
CPU #5: (halted) thread_id=5940


(qemu) cpu 4


(qemu) info cpus
CPU #0: (halted) thread_id=5935
CPU #1: (halted) thread_id=5936
CPU #2: (halted) thread_id=5937
CPU #3: (halted) thread_id=5938
* CPU #4: thread_id=5939
CPU #5: (halted) thread_id=5940

gdb-multiarch exec.elf
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from exec.elf...done.
The target is assumed to be little endian
Breakpoint 1 at 0x0: file startup.S, line 6.


(gdb) target extended-remote :1234
Remote debugging using :1234
warning: Selected architecture arm is not compatible with reported target architecture aarch64
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c5030040


(gdb) add-inferior
Added inferior 2


(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]


(gdb) attach 2
Attaching to process 2
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.


(gdb) info threads
No threads.

As you can see, the gdb-multiarch program detected the binary to be 'arm' (A32) code, which it is. However when it connects to the target (QEMU). The target identification is an aarch64 target. Since I have only taken a single cortex-R5 out of reset, the target should not be an aarch64 target.   

Does this make sense to you?

 

Kindly,

David.

abouassi
Moderator
Moderator
2,419 Views
Registered: ‎03-25-2019

Hi David (@dcabanis),

It seems to be that the gdb-multiarch version that you have installed is not compatible with the Qemu stub.
It is not parsing the received RSP packets from the Qemu GDB stub correctly:
>Remote 'g' packet reply is too long:
>00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Thus the failure when attaching to the process.

So, I recommend to try to build your gdb client yourself and test again.
Here they are the steps to do so:

git clone --branch gdb-8.3-branch ssh://sourceware.org/git/binutils-gdb.git
cd binutils-gdb
./configure --enable-targets=all
make

The built gdb client executable will be named "gdb" and you can find it under "binutils-gdb/gdb/". This should be used instead of the gdb-multiach that you have installed.

If the issue still persists, please try to activate the remote debugging:

(gdb) set debug remote 1

This will allow us to see the exchanged RSP packets. Then try to connect to QEMU:

target extended-remote :1234
add-inferior
inferior 2
attach 2
info threads

and send me all the output to check what's going on under the hood.

 

Best regards,
Abdallah
-------------------------------------------------------------------------------
Please don't forget to reply, kudo and accept as a solution
0 Kudos
Reply
dcabanis
Visitor
Visitor
2,410 Views
Registered: ‎04-23-2019

Hello Abdallah,

Thank you very much for your detailed answer. I really appreciate it.

Had also tried to manually compile gdb 8.x manually in an earlier effort but I had similar problems attaching gdb onto QEMU (R5).

I have just tried your solution but it seems that the error message ramains the same.

For information, I used :

git clone --branch gdb-8.3-branch git://sourceware.org/git/binutils-gdb.git

ssh did not seem to work, there was some public/private key issue. Once compiled, gdb --version gives me:

GNU gdb (GDB) 8.2.91.20190503-git

I am not sure if this should be 8.3 instead?

I have to admit I am not very knowlegeable in the gdb communication messages but I have put them in the message just in case you or another reader can make sense of it.

I still can't understand why the target is defined as aarch64 since I configure QEMU to only take one of the Cortex-R5 out of reset. All of the other cores are left in a reset state. Interestingly, when I start QEMU and enquire about what are the registers available, it reports the registers available in the first core of the C-A53 as you can see here:

(qemu) info registers
PC=0000000000000000 SP=0000000000000000
X00=0000000000000000 X01=0000000000000000 X02=0000000000000000 X03=0000000000000000
X04=0000000000000000 X05=0000000000000000 X06=0000000000000000 X07=0000000000000000
X08=0000000000000000 X09=0000000000000000 X10=0000000000000000 X11=0000000000000000
X12=0000000000000000 X13=0000000000000000 X14=0000000000000000 X15=0000000000000000
X16=0000000000000000 X17=0000000000000000 X18=0000000000000000 X19=0000000000000000
X20=0000000000000000 X21=0000000000000000 X22=0000000000000000 X23=0000000000000000
X24=0000000000000000 X25=0000000000000000 X26=0000000000000000 X27=0000000000000000
X28=0000000000000000 X29=0000000000000000 X30=0000000000000000
PSTATE=400003c5 -Z-- EL1h
q00=0000000000000000:0000000000000000 q01=0000000000000000:0000000000000000
q02=0000000000000000:0000000000000000 q03=0000000000000000:0000000000000000
q04=0000000000000000:0000000000000000 q05=0000000000000000:0000000000000000
q06=0000000000000000:0000000000000000 q07=0000000000000000:0000000000000000
q08=0000000000000000:0000000000000000 q09=0000000000000000:0000000000000000
q10=0000000000000000:0000000000000000 q11=0000000000000000:0000000000000000
q12=0000000000000000:0000000000000000 q13=0000000000000000:0000000000000000
q14=0000000000000000:0000000000000000 q15=0000000000000000:0000000000000000
q16=0000000000000000:0000000000000000 q17=0000000000000000:0000000000000000
q18=0000000000000000:0000000000000000 q19=0000000000000000:0000000000000000
q20=0000000000000000:0000000000000000 q21=0000000000000000:0000000000000000
q22=0000000000000000:0000000000000000 q23=0000000000000000:0000000000000000
q24=0000000000000000:0000000000000000 q25=0000000000000000:0000000000000000
q26=0000000000000000:0000000000000000 q27=0000000000000000:0000000000000000
q28=0000000000000000:0000000000000000 q29=0000000000000000:0000000000000000
q30=0000000000000000:0000000000000000 q31=0000000000000000:0000000000000000
FPCR: 00000000 FPSR: 00000000

Additionally, when I ask to display the available CPUs it shows that the default selected CPU is the Core0 of the C-A53 cluster, as you can see here:

(qemu) info cpus
* CPU #0: (halted) thread_id=17723
CPU #1: (halted) thread_id=17724
CPU #2: (halted) thread_id=17725
CPU #3: (halted) thread_id=17726
CPU #4: thread_id=17727
CPU #5: (halted) thread_id=17728

It is only when I manually select the Cortex-R5 that I can then see the Cortex-R5 registers:

(qemu) cpu 4
(qemu) info registers
R00=00000000 R01=00000000 R02=00000000 R03=00000000
R04=00000000 R05=00000000 R06=00000000 R07=00000000
R08=00000000 R09=00000000 R10=00000000 R11=00000000
R12=00000000 R13=00000000 R14=00000000 R15=00000000
PSR=400001d3 -Z-- A svc32
FPSCR: 00000000

Nevertheless, when I start gdb, it still reports that the CPU architecture is aarch64 instead of arm (used for cortex-R5).

Obviously, I am largely ignorant in these matters but it looks to me as if QEMU is always indicating that it's current architecture is aarch64 regardless of the active (selected) CPU.

What do you think?

Here is the dump of gdb (8.2) session:

./binutils-gdb/gdb/gdb exec.elf
Python Exception <type 'exceptions.ImportError'> No module named gdb:
/home/doulos/Downloads/binutils-gdb/gdb/gdb: warning:
Could not load the Python gdb module from `/usr/local/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (GDB) 8.2.91.20190503-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from exec.elf...


(gdb) set debug remote 1
(gdb) target extended-remote :1234
Remote debugging using :1234
Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+;xmlRegisters=i386#6a...Ack
Packet received: PacketSize=1000;qXfer:features:read+;qXfer:osdata:read+;multiprocess+
Packet qSupported (supported-packets) is supported
Sending packet: $vMustReplyEmpty#3a...Ack
Packet received:
Sending packet: $!#21...Ack
Packet received: OK
Sending packet: $Hgp0.0#ad...Ack
Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><xi:include href="aarch64-core.xml"/><xi:include href="aarch64-fpu.xml"/><xi:include href="aarch64-el1.xml"/><architecture>aarch64</architecture></target>
Sending packet: $qXfer:features:read:aarch64-core.xml:0,ffb#31...Ack
Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2009-2012 Free Software Foundation, Inc.\n Contributed by ARM Ltd.\n\n Copying and distribution of this file, with or without modification,\n are permitted in any medium without royalty provided the copyright\n notice and this notice are preserved. -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.aarch64.core">\n <reg name="x0" bitsize="64"/>\n <reg name="x1" bitsize="64"/>\n <reg name="x2" bitsize="64"/>\n <reg name="x3" bitsiz[1036 bytes omitted]
Sending packet: $qXfer:features:read:aarch64-fpu.xml:0,ffb#d3...Ack
Packet received: m<?xml version="1.0"?>\n<!-- Copyright (C) 2009-2012 Free Software Foundation, Inc.\n Contributed by ARM Ltd.\n\n Copying and distribution of this file, with or without modification,\n are permitted in any medium without royalty provided the copyright\n notice and this notice are preserved. -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.aarch64.fpu">\n <vector id="v2d" type="ieee_double" count="2"/>\n <vector id="v2u" type="uint64" count="2"/>\n <vector id="v2i" type="[1534 bytes omitted]
Sending packet: $qXfer:features:read:aarch64-fpu.xml:7fd,ffb#a4...Ack
Packet received: l />\n <reg name="v7" bitsize="128" type="aarch64v" />\n <reg name="v8" bitsize="128" type="aarch64v" />\n <reg name="v9" bitsize="128" type="aarch64v" />\n <reg name="v10" bitsize="128" type="aarch64v"/>\n <reg name="v11" bitsize="128" type="aarch64v"/>\n <reg name="v12" bitsize="128" type="aarch64v"/>\n <reg name="v13" bitsize="128" type="aarch64v"/>\n <reg name="v14" bitsize="128" type="aarch64v"/>\n <reg name="v15" bitsize="128" type="aarch64v"/>\n <reg name="v16" bitsize="128" type="aarch64v"/>\n <reg [822 bytes omitted]
Sending packet: $qXfer:features:read:aarch64-el1.xml:0,ffb#8a...Ack
Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2009-2012 Free Software Foundation, Inc.\n Contributed by ARM Ltd.\n\n Copying and distribution of this file, with or without modification,\n are permitted in any medium without royalty provided the copyright\n notice and this notice are preserved. -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.aarch64.el1">\n <reg name="elr_el1" bitsize="64"/>\n <reg name="esr_el1" bitsize="64"/>\n <reg name="spsr_el1" bitsize="64"/>\n <reg n[81 bytes omitted]
warning: Selected architecture armv7 is not compatible with reported target architecture aarch64
warning: Architecture rejected target-supplied description
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: T05thread:p1.1;
Sending packet: $qfThreadInfo#bb...Ack
Packet received: mp1.1
Sending packet: $qsThreadInfo#c8...Ack
Packet received: mp1.2
Sending packet: $qsThreadInfo#c8...Ack
Packet received: mp1.3
Sending packet: $qsThreadInfo#c8...Ack
Packet received: mp1.4
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
Sending packet: $qAttached:1#fa...Ack
Packet received: 1
Packet qAttached (query-attached) is supported
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[24 bytes omitted]
Remote 'g' packet reply is too long (expected 168 bytes, got 268 bytes): 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c5030040
(gdb)

 

Kindly,

David

0 Kudos
Reply
abouassi
Moderator
Moderator
2,391 Views
Registered: ‎03-25-2019

Hi David (@dcabanis),

You are welcome!

Could you please try to run gdb without specifying a file (gdb ./exec.elf). After attaching to the second inferior, you can specify your file by the command:

(gdb) file ./exec.elf

This should fix the issue.


You have said "QEMU is always indicating that its current architecture is aarch64 regardless of the active (selected) CPU.", this is the normal behavior as you are getting these messages at the beginning when the GDB is connected to the first inferior which contains the A53 cores. But as soon as you connect to the second inferior, which contain the R5 cores, the QEMU GDB stub will identify itself as an ARM32 bit (by sending an XML description file) and with this the GDB will be aware that the architecture has been changed and it will change to the ARM 32bit mode. This is why we actually need the gdb-multiarch because it is capable to switch from architecture to another.

 

Best regards,
Abdallah
-------------------------------------------------------------------------------
Please don't forget to reply, kudo and accept as a solution
0 Kudos
Reply
dcabanis
Visitor
Visitor
2,379 Views
Registered: ‎04-23-2019

Hello Abdallah,

This looks promissing! I am able to step through some code.

I'll write up a detailed set of instruction when I had a chance to digest what's happening.

Thanks for now,

David.

0 Kudos
Reply
dcabanis
Visitor
Visitor
2,338 Views
Registered: ‎04-23-2019

Hello Abdallah,

Here is a summary of what I did to get this to work. I hope this will be helpful to others.

 

Running bare metal code on the Zynq Ultrascale+ Cortex-R5 QEMU

Tools

This configuration runs on Ubuntu 16.06 (64bit) with the standard C build tools (binutils) installed.

GNU Compiler toolchain (cross-compiling)

gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi

Found here:

https://releases.linaro.org/components/toolchain/binaries/latest-7/arm-eabi/

gdb multi-architecture

gdb needs to be manually configured to support multiple architectures (arm /aarch64)

git clone --branch gdb-8.3-branch git://sourceware.org/git/binutils-gdb.git
cd binutils-gdb/
./configure --enable-targets=all

QEMU

QEMU emulator version 2.11.1 (v2.6.0-13192-g29ed507-dirty)

Found here:

https://github.com/Xilinx/qemu

Running the session

  1. Compile (assemble) and link the various source files.

  2. QEMU is started first in a terminal window.

  3. gdb is started second in a new terminal window.

Sample source files

startup.S

.section .text
.syntax unified
.global _start

_start:
b _Reset

_Reset:
b _run

.end

run.S

.section .text
.syntax unified
.global _run

_run:

ldr r0,=55
ldr r1,=88
add r2,r1,r0

spinlock:
b .

.section .data
_source: @ source data
.word 0xAAAAAAAA
.word 0xBBBBBBBB
.word 0xCCCCCCCC
.word 0xDDDDDDDD
.word 0xEEEEEEEE
.word 0xFFFFFFFF
.word 0x11111111
.word 0x22222222
_dest: @ destination data
.space 32 @ reserve 8 words of memory

.end

arm.ld

ENTRY(_start)
SECTIONS
{
. = 0x0;
.startup . : { startup.o(.text) }
.text : { *(.text) }
.data : { *(.data) }
.rodata : { *(.rodata) }
.bss : { *(.bss) }
. = . + 0x1000; /* 4kB of stack memory */
stack_top = .;
}

Assembling and linking

<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g run.S -o run.o
<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-as -march=armv7-r -g startup.S -o startup.o
<install_dir>/gcc-linaro-7.4.1-2019.02-x86_64_arm-eabi/bin/arm-eabi-ld -Tarm.ld -o exec.elf startup.o run.o

QEMU launch

<install_dir>/aarch64-softmmu/qemu-system-aarch64 -M xlnx-zcu102 -smp 6 -serial mon:stdio -nographic -device loader,file=exec.elf,cpu-num=4 -global xlnx,zynqmp.boot-cpu="rpu-cpu[0]" -s -S

gdb session

<install_dir>/binutils-gdb/gdb/gdb
(gdb) target extended-remote :1234
(gdb) add-inferior
(gdb) inferior 2
(gdb) file ./exec.elf
(gdb) attach 2

And voila! Thank you very much for your help, Abdallah.

Kindly,

David Cabanis

View solution in original post

0 Kudos
Reply