RTEMS on QEMU emulated RPi and RPi2

[Pavel Pisa]

Hello Mudit,

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
(branch merged-2.6)

  https://github.com/CTU-IIG/qemu/tree/merged-2.6

I start compiled QEMU as

~/repo/qemu/qemu-build/arm-softmmu/qemu-system-arm \
  -M raspi2 \
  -serial stdio \
  -s -S

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
command script

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
hbreak *0x0

# set breakpoint to the location where application
# is expected and QEMU jumps after initialization
hbreak *0x8000
c
# continue initialization till breakpoint at 0x8000
# is reached

# load RTEMS ELF application image
load
# set breakpoints to catch fatal exceptions
hbreak *0x0004
hbreak *0x0008
hbreak *0x000C
hbreak *0x0010
hbreak *0x001C

set $pc=0x8000
# set breakpoints of interrest for debugging
hbreak bsp_start_hook_0
hbreak bsp_start_hook_1
---------------------------------------------------------

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)
    at ../../../../../../../../../../git/rtems/c/src/../../cpukit/score/cpu/arm/armv7-thread-idle.c:32
32          __asm__ volatile ("wfi");

I am testing RTEMS build from my updated sources,
branch rtems-rpi-devel of

  https://github.com/ppisa/rtems/tree/rtems-rpi-devel

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

Best wishes,

              Pavel