Skip to main content

[RTEMS/QEMU] boot RTEMS on ARM QEMU

Thanks for Heshame Almatary.
Now I am able to run RTEMS on QEMU-arm.

To prevent from any wrong setup, he recommended me to adopt RTEMS Source Builder(RSB) to build up the qemu and run with following commands:
"qemu-system-arm -no-reboot -net none -nographic -smp 2 -icount
auto -M realview-pbx-a9 -m 256M -kernel ticker.exe"  without debugger
"qemu-system-arm -S -s -no-reboot -net none -nographic -smp 2 -icount
auto -M realview-pbx-a9 -m 256M -kernel ticker.exe" with GDB

I mimicked this tutorial and build up my target.
[0] http://heshamelmatary.blogspot.de/2015/02/howto-5-run-rtems-on-qemu.html
[1] http://heshamelmatary.blogspot.co.uk/2015/02/howto-4-run-rtems-on-or1ksim.html

I remove some options, i.e., smp, from his recommendation and I get the result:
---dump---
./qemu-system-arm -no-reboot -nographic -M realview-pbx-a9 -m 256M -kernel

/home/khchen/development/build-rtems/arm-rtems4.11/

c/realview_pbx_a9_qemu/testsuites/samples/ticker/ticker.exe
*** 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
TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
*** END OF TEST CLOCK TICK ***
Hint: the building process of qemu with RSB will be longer since it build up all the supported target qemu for you.

khchen@khchen-All-Series:~/development/rtems/4.11/bin$ ./qemu-system-arm -no-reboot -net none -nographic -icount auto -M realview-pbx-a9 -m 256M -kernel /home/khchen/development/build-rtems/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/samples/ticker/ticker.exe

./qemu-system-arm -no-reboot -nographic -M realview-pbx-a9 -m 256M -kernel /home/khchen/development/build-rtems/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/samples/fileio/fileio.exe
The option icount auto will let QEMU become stuck.

arm-rtems4.11-gdb is able to debug the qemu with the default port 1234.
target remote :1234 and so on.

PATH=$HOME/development/rtems/4.11/bin:$PATH RTEMS_MAKEFILE_PATH=$HOME/development/rtems/4.11/arm-rtems4.11/raspberrypi

Comments

Post a Comment

Popular posts from this blog

RSB+RTEMS 5/6 with QEMU-SMP (ARM realview_pbx_a9_qemu as example)

Since I got a request regarding this blog  written in 2016, summarizing again the complete flow with the latest version of RTEMS could be a good idea. Prepare a suitable workspace according to the adopted operating system on your host ( https://docs.rtems.org/branches/master/user/hosts/index.html ):  sudo apt-get build-dep build-essential gcc-defaults g++ gdb git unzip pax bison flex texinfo unzip python3-dev libpython-dev libncurses5-dev zlib1g-dev Checkout RSB and build: git clone git://git.rtems.org/rtems-source-builder.git rsb change directory to rsb/rtems/ and type ../source-builder/sb-set-builder --prefix=<the path you like to store the built toolchains> <the name of bsp> For example, to use QEMU, I need toolchains for ARM, so: ../source-builder/sb-set-builder --prefix=/home/kh.chen/respository/build/. 6/rtems-arm This will take a while. Please ensure your connection is reliable. Add the built folder into your PATH. For example, you can add one line in ~/.bas...
Post a Comment
Read more

[LEGO nxt] Install the Enhanced NXT firmware and Upload the OSEK excutable file with Ubuntu 64bits 14.04 in 2015

This tutorial is referred from Install the Enhanced NXT firmware on NXT . I think this is the critical part to capture the idea from the tutorial for Windows. I have tried many ways to conquer the problem of libnxt3.0, however, I still have some problems on the compilation of fwflash or something else. Though the tutorial for Windows is doable, my preference is to build up everything with Linux environment. Fortunately, I notice that NxTTool in the tutorial for Windows is really powerful. We can handle the firmware updating by using NxTTool in Linux as well! I also refer to this Japanese Blog , which inspire me a lot. As usual, install the required packages: sudo apt-get install libusb-dev:i386 libusb-0.1-4 subversion fpc Please note, here is the case for 64bits user that I change libusb-dev to libusb-dev:i386 comparing to the original tutorial. Instead of using libnxt to do the uploading, here I follow that JP Blog to get the latest version of bricxcc: (The url in blog i...
Post a Comment
Read more

Virtualenv experience or alternatives

Today I have a project which requires several packages on my python. However, due to whatever reason, I have a lot of different versions of python. Before I thought, it was fine to just install and maintain each by each. Maybe it is time to learn how to use virtualenv. (alternatively, you can use module). I first got some quick ideas from here: https://stackoverflow.com/questions/10763440/how-to-install-python3-version-of-package-via-pip-on-ubuntu The magic virtualenv does is that, it copies a series of your python binaries, include, pip, etc., into a folder. The prepared activate script does that, add the export folder into the general variable PATH at its beginning. By doing so, the targeted version of python will be the first target that will be executed. To enable virtualenv, source the position of the above folder/bin/activate To leave the virtualenv, just type deactivate, as it is defined when you load the activate script. For example, I call virtualenv in my home ...
Post a Comment
Read more