RTEMS on QEMU emulated RPi and RPi2
ppisa4lists at pikron.com
Thu May 26 15:57:21 UTC 2016
On Thursday 26 of May 2016 16:06:52 Mudit Jain wrote:
> This mail is also a follow up from the IRC chat yesterday, in context of
> configuring QEMU to emulate RPi2. This email thread can be used to
> communicate the information regarding the same.
I have used my build of qemu-system-arm 2.6.0 from GIT.
In the fact it is a little modified version with can-pci and some
our other HW added but there is no change in RPi related parts
I start compiled QEMU as
-M raspi2 \
-serial stdio \
The last two options enable GDB support and stop QEMU
after initialization. I redirect serial line I/O
to console to ease capture and copy pasting.
I have not succeed with RTEMS application load through -kernel
option nor from SDcard (-sd qemu/rpi2-sd.img). I have tried plain
binary. But I have no problem to debug RTEMS start by
GDB which loads ELF application image
I start GDB with application image and qemu-debug-rpi2-app.gdb
arm-elf-gdb -x qemu-debig-rpi2-app.gdb rtems/arm-rtems4.12/c/raspberrypi2/testsuites/samples/ticker/ticker.exe
The "qemu-debug-rpi2-app.gdb" script content is
target remote localhost:1234
# set breakpoint to the location where application
# is expected and QEMU jumps after initialization
# continue initialization till breakpoint at 0x8000
# is reached
# load RTEMS ELF application image
# set breakpoints to catch fatal exceptions
# set breakpoints of interrest for debugging
GDB starts, sets breakpoint at 0x8000 and releases QEMU
from initial wait for GDB. QEMU/ARM CPU initializes and executes
till it jumps to 0x8000 and stops on breakpoint.
This returns control back to GDB. It loads application
image and sets breakpoints and waits for user.
You can step through code (si,s,ni,n commands) or let
it run at "full" emulated speed (c). It stops
at predefined breakpoints and state can be examined.
Ticker runs for me till output
*** BEGIN OF TEST CLOCK TICK ***
TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988
TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988
Then nothing happens, interrupts seems to not propagate to the
CPU. When I break application from GDB then it waits on
0x00012876 in _CPU_Thread_Idle_body (ignored=0)
32 __asm__ volatile ("wfi");
I am testing RTEMS build from my updated sources,
branch rtems-rpi-devel of
But I do not expect that there is significant difference
to the mainline which could make things worse.
I have debugged on RTEMS and on QEMU side that my interaction
with emulated VideoCore goes well. My changes could help
in case of startup of application with cache enabled
which lead to fail/stuck on RTEMS mainline etc.
It would be very usesfull to find where RTEMS
sucks with newer firmware on the real hardware
and if my version runs with older firmware on real
More information about the devel