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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
