When it came to debugging, I could not get hold of a tool to debug my Pi 2 directly. QEMU was the only resource at my disposal. It does not support Pi 2 as of now, but supports Pi 1 and some SMP capable BSPs. So, to solve my issues, I used QEMU to emulate the Pi 1 and Realview-pbx-a9 multicore BSPs as and when each of them was needed.
With QEMU I used the arm-rtems4.11-gdb to step through the code and set breakpoints.
https://github.com/Torlus/qemu/tree/rpi
Some help on how to build and run QEMU for Pi is present here
http://wiki.osdev.org/Raspberry_Pi_Bare_Bones
If the kernel executable does not run and you see QEMU has hanged (which happened with me ) then the kernel entry address needs to be changed. I used the mkimage tool to create an image with the correct load address and then run it with QEMU. This is how I got an RKI image ready for QEMU.
mkimage -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -C none -d rki.bin kernel.img
qemu-system-arm -M realview-pbx-a9 -m 256M -kernel hello.exe -serial stdio
The number of cores to be used can be specified with the -smp option, like the following will run QEMU for 2 cores
qemu-system-arm -M realview-pbx-a9 -m 256M -kernel smp01.exe -smp 2 -serial stdio
http://wiki.osdev.org/Kernel_Debugging
The same can be achieved using RTEMS tools (specifically the arm-rtems4.11-objcopy and arm-rtems4.11-gdb utilities)
While using gdb, the " thread N " command can be used to switch between cores and it will let you step through the thread which core N is running (N=1,2,3..)
With QEMU I used the arm-rtems4.11-gdb to step through the code and set breakpoints.
Using QEMU with Raspberry Pi(v1)
There is a modified QEMU source for Pi which can be obtained fromhttps://github.com/Torlus/qemu/tree/rpi
Some help on how to build and run QEMU for Pi is present here
http://wiki.osdev.org/Raspberry_Pi_Bare_Bones
If the kernel executable does not run and you see QEMU has hanged (which happened with me ) then the kernel entry address needs to be changed. I used the mkimage tool to create an image with the correct load address and then run it with QEMU. This is how I got an RKI image ready for QEMU.
mkimage -A arm -O rtems -T kernel -a 0x00008000 -e 0x00008000 -C none -d rki.bin kernel.img
Using QEMU with Realview-pbx-a9
An executable can be run easily here. This is how I ran an RTEMS "Hello World" applicationqemu-system-arm -M realview-pbx-a9 -m 256M -kernel hello.exe -serial stdio
The number of cores to be used can be specified with the -smp option, like the following will run QEMU for 2 cores
qemu-system-arm -M realview-pbx-a9 -m 256M -kernel smp01.exe -smp 2 -serial stdio
Debugging with QEMU
This is a nice reference for using gdb with QEMUhttp://wiki.osdev.org/Kernel_Debugging
The same can be achieved using RTEMS tools (specifically the arm-rtems4.11-objcopy and arm-rtems4.11-gdb utilities)
While using gdb, the " thread N " command can be used to switch between cores and it will let you step through the thread which core N is running (N=1,2,3..)
Hi Rohini ,
ReplyDeleteI was reading your blog and it's very great I learnt lot of things.
I found your blog by searching an error that I found when debugging rtems on zynq.
The debugging went fine until the line 278 of the start.S of ARM.
The gdb enter in a loop and never go out from there.
I did break points and this is what it shows me :
Breakpoint 7, arm_cp15_start_setup_translation_table (ttb=, client_domain=15, config_table=0x104348 ,
config_count=14) at ../../../../../.././xilinx_zynq_zedboard/lib/include/bsp/arm-cp15-start.h:133
133 for (i = 0; i < ARM_MMU_TRANSLATION_TABLE_ENTRY_COUNT; ++i) {
Breakpoint 8, arm_cp15_start_setup_translation_table (ttb=, client_domain=15, config_table=0x104348 ,
config_count=14) at ../../../../../.././xilinx_zynq_zedboard/lib/include/bsp/arm-cp15-start.h:134
134 ttb [i] = 0;
It is stuck in the arm-cp15-start.h in line 133 in this loop
/* Initialize translation table with invalid entries */
for (i = 0; i < ARM_MMU_TRANSLATION_TABLE_ENTRY_COUNT; ++i) {
ttb [i] = 0;
}
What do you think is the problem ? Your caching problem on the RPi2 was similar to this ?
Badr El H