This short article will show you how to quickly setup cross-toolchain for C/C++ RV32IMAC binaries that runs on x86_64 host Linux PC.
git clone https://github.com/riscv/riscv-gnu-toolchain.git
cd riscv-gnu-toolchain/
git submodule update --init --recursive
mkdir build; cd build/
../configure --prefix=/opt/riscv32 --with-arch=rv32imac --with-abi=ilp32
make -j$(nproc)
Please note that /opt/riscv32 directory should be writable by the user running make. This command is the last step here, it will also install compilation results in –prefix directory. You might want to add bin directory to your PATH:
export PATH=/opt/riscv32/bin:$PATH
As a result we will get tools with riscv32-unknown-elf triplet.
I will show the quickest way of running your own-built Linux system in QEMU emulator. Did I say quickest? Let’s start then:
$ git clone git://git.buildroot.net/buildroot
$ cd buildroot/
$ make qemu_arm_versatile_defconfig
Where qemu_arm_versatile_defconfig is file & defconfig name from buildroot/configs directory. Next:
$ make menuconfig
And menu similar to Linux kernel menuconfig shows up. Since we preconfigured it with the defconfig file, there is almost nothing to change here. Be sure to have all tools from Build options —> Commands menu installed in your host system.
In Build options check Enable compiler cache which will save compiler output files and make consequent compilations faster. It is not necessary though.
Now type this and get some coffee:
$ make
We have now the time to chat a bit. So, what we have just done is we run a massive process of downloading core packages and compiling them into toolchain, kernel and root filesystem that will became our own, small Linux OS. Ever heard that making Linux for embedded devices is hard? Well, it is. But we have taken three huge shortcuts.
First, by using Buildroot which is a big set of Makefiles that configures and compiles GCC, C library and whole OS ecosystem (BusyBox). What it produces in the end are the Linux kernel and the image of root filesystem.
Second shortcut is configuring Buildroot with qemu_arm_versatile_defconfig. There is nothing to change within the kernel thanks to this. This configuration file along with buildroot/board/qemu/arm-versatile/linux-4.9.config tells Buildroot to set kernel configuration to suit ARM Versatile boards template. This is one of the development platforms supported both by Linux and QEMU out of the box.
The last one is the use of QEMU. Because of that, we do not have to configure any bootloader (like U-Boot for instance). All we need to do is to run one command right after the compilation ends:
Update-even-more: Binwalk has just moved to GitHub.
Update: Second half of this tutorial refers to the binwalk version 1.2.1 only. It appears that with 1.2.2 release, problem with setup.py has been resolved. Diff here.
Firstly, a few dependencies.
There is a package “file” in Slackware but it doesn’t have it’s Python bindings installed. You need to download appropriate source file from here: ftp://ftp.astron.com/pub/file/. Choose version that you have in your system. In my case it is 5.14.
# tar xzf file-5.14.tar.gz
# cd file-5.14/python
# python setup.py install
At this point you should run something like this without getting an exception:
# python
Python 2.7.5 (default, May 29 2013, 02:28:51)
[GCC 4.8.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import magic
>>> magic.MAGIC_NO_CHECK_TEXT
131072
>>>
Next, you may want to get matplotlib working. This is not required to and if you don’t want it you can fall back to regular binwalk install procedure (docs/README in binwalk sources) and quit reading this text. From now on, I assume you want to have fancy plotting option in your binwalk.
There is a bunch of packages to install. My preferred way to do this is by getting them from SlackBuilds. You can also use sbopkg tool, to speed up whole process. Install following packages in order: pysetuptools, six, python_dateutil, pytz, numpy and matplotlib.
Before we proceed there is a test to perform. Switch to non-root user and type:
$ python
Python 2.7.5 (default, May 29 2013, 02:28:51)
[GCC 4.8.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.pyplot
>>>
If you don’t get anything more serious than some fontconfig warnings, It’s OK to proceed.
# tar xzf binwalk-1.2.1.tar.gz
# cd binwalk-1.2.1/src
Now it’s tricky part. You want to have your binwalk installed globally since this is how setup script works, but installer (matplotlib.pyplot, actually) needs X server and you don’t have it in root’s python session. Because you verified that matplotlib.pyplot works on non-root user, where one usually runs software from, you can make little ugly hack to binwalk’s setup.py file. Let’s change the way how installer checks if matplotlib is present. This is a diff of original and modified file in patch format:
This is application running in ChibiOS/RTRTOS with addition of µGFX framework. It mimics screen unlocker known from Andriod smartphones. It was tested on Embest DM-STF4BB board with DM-LCD35RT LCD display, but should run on any other supported by µGFX. It works properly in ChibiOS/RT simulator also. For details how to run it there, please visit simulator introduction (link is dead, I’ll update this once it appears somewhere).
It allows to configure number of columns and rows you want to have, colors of the “rings” and few other options. The distance between rings is calculated automatically based on screen size and number of columns and rows. There are two functions to handle unlocker. displayUnlockerSetup() is used to draw and save unlock sequence. displayUnlocker() simply displays unlocker and exits if user drew proper pattern, either set by setup function or hardcoded. There is no persistence mechanism to store patterns.
Or how to debug embedded devices with Kate editor, GCC toolchain, OpenOCD and JTAG. Or, how to replace Eclipse in embedded developer’s work.
I do most of my work with open source software, including this running on PC desktop. Few years ago my environment of choice became KDE (KDE SC nowadays). One of areas in which this choice (not ideal) shows its superiority over other desktops is multitude of accompanying applications. And the most useful for me are text editors. This backyard is dominated by indissoluble duo: KWrite and Kate. As it appears, these tools (more precisely, Kate – as it is “bigger brother”) can be used to do much more than editing.
So if you sit with KDE and some embedded stuff in front of your eyes why not give Kate a try? Curiously enough, it took me a while to hit on this idea;)
I assume that you:
have working GCC toolchain,
know how to use GDB (most preferably),
have proper Makefile(s), sources, linker scripts, vectors tables etc.,
have hardware to play with (hardware debugger and target).
Kate setup
Start with regular Kate setup. Make new session, choose directory for it and import some source files – let us have something to play with. After that enable two plugins that Kate comes with: “Build Plugin” and “GDB”.
Kate Plugin Manager
First one can execute “make” inside project directory, second gives actual ability to debug. Both of them extend interface of Kate a bit. This is how my editor looks now:
Kate main window
At top toolbar area appeared a bunch of unsurprisingly familiar buttons. I had to manually add first one (“Start debugging”). At the bottom there are two new activators: “Debug View” and “Build Output”. Open the first one and go to “Settings” tab, then click “Advanced Settings”.
GDB advanced settings dialog
This is where your desired setup may start to diverge from mine, but general guidelines should be the same for any case. In “GDB command” field put GDB executable name. Full path here is preferred, I didn’t manage to make it work relying on PATH. From select choose “Remote TCP”, set “localhost” as a host and “3333” as a port that GDB will connect to. OpenOCD usually binds there. In “Custom Startup Commands” type all instructions that GDB have to execute before start debugging. This is important step, as Kate doesn’t know anything about debug server and your target. Every initialization step you have to undertake should go here or to OpenOCD scripts. Most common are loading binary to flash, remapping memory, setting clocks. To program flash you can use either GDB commands (if they work) or pass OpenOCD instructions as argument of “monitor” (or shortly: “mon”) command – as I do. Note last line of my input: I make GDB automatically break on “main” function.
GDB plugin settings
Back to Settings tab, set path to executable file (usually in ELF format). If you set working directory, executable can be just a file name. The nice thing about Kate GDB plugin is that apart from controlling GDB it gives you its command prompt (GDB output tab). To keep focus on GDB console, select “Keep focus”. If your setup handles IO redirection properly, you should be able to control it in tab “IO”, which appears after checking “Redirect IO”. Mine doesn’t, so I did not test it. I saved this setup under “openocd” name; use whichever you like. Configurations are easily selectable in “Debug > Targets” top menu.
Build settings tab
Next, configure build add-on settings. Hit “Build Output” activator at the bottom and select “Target Settings” tab. Fill in working directory, and next three inputs. I chose “Build” command to run both clean and make so the “Quick compile” executes only make and “Build” rebuilds entire project. Again, you can save this configuration under arbitrary name and load it later in “Build > Targets”. Build plugin doesn’t have its own toolbar so commands will be available in “Build” top menu.
Let’s run it!
Having this done we can move into action. Build your project using menu “Build > Build”. Then go to “Terminal” activator and type OpenOCD startup command. This activator shows up after enabling “Terminal tool view” plugin.
For my target I execute:
openocd -f board/stm32f4discovery.cfg
Example:
Kate terminal window
Click “Start Debugging” button. GDB Output tab should appear:
GDB console
This is just a GDB console. Debugger stopped at “main” function as we told it to do. You can type “c” (continue) directly in highlighted input box, or hit “Continue” button from toolbar. Before doing that set cursor in editor to certain place in main() and make there breakpoint with “Toggle breakpoint” button.
Breakpoint inserted
Breakpoint line gets light red background. Inserting breakpoints is possible only when program is not being run.
Local variables view
Toggling activator to the right of main window, we get local variables preview.
To sum up
There are few more options that both described plugins provide, but most of “the meat” ends here. This is no equivalent to Eclipse-based toolchain setup (not to mention others), but makes nice distinction (faster! not Java! …and not Java!). And also gives very good quality of text editing, something what KatePart is known of. There is even vi-like mode:) Should you happen to consider improving current state of GDB plugin, maybe to push it more towards embeded world or to contribute to Kate itself – do not hesitate, it’s authors will welcome your efforts warm. So do I!
I uploaded one of my student projects to GitHub: Canny algrithm implementation. This is popular method of finding edges in the image invented in 80’s: http://en.wikipedia.org/wiki/Canny_edge_detector. What you will find here is extremely naive approach, possibly with bugs and certainly not written with memory consumption issues in mind. But that’s just student project, it served well for its purpose:) Make sure to see README:
Embedded systems gurus always repeated: don’t use floating-point numbers in your firmware! But what if you have processor with a FPU? Well, then you simply can. Do not forget, however, to carefully look at your disassembly file, as always.
So this is what we get with GCC 4.6.2 on Cortex-M3:
And this is output from the same GCC version on Cortex-M4F (compiled with flags -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffast-math -fsingle-precision-constant):
There is a great aricle (and blog) on solving problems with running VMware on Linux hosts: http://weltall.heliohost.org/wordpress/2012/01/26/vmware-workstation-8-0-2-player-4-0-2-fix-for-linux-kernel-3-2-and-3-3/. What is not said there is that sometimes you are unable even to install Workstation itself. The cause is that installer tries to build modules and it fails to do this, so the installation is reverted and you end up with nothing. The cure, which solved the case for me were following parameters:
After installation of fresh copy of PostgreSQL database server it is often required to configure proper localization settings. This helps to avoid messages like this:
ERROR: invalid locale name en_GB.utf8
where en_GB.utf8 is setting you want to have. In order to create a database with custom locale there are few steps one has to follow.
The first is to enable all locales you might want to use in PostgreSQL in your system config. On Debian, edit file /etc/locale.gen and uncomment lines with your locales names. In my case it looks like this:
Then run command locale-gen which will generate system localization files.
# locale-gen
Generating locales (this might take a while)...
en_US.UTF-8... done
pl_PL.UTF-8... done
Generation complete.
I have two locales enabled: en_US.UTF-8 and pl_PL.UTF-8. Both of them should be available in PostgreSQL. To check that, switch user to postgres and run SQL console, psql:
# su - postgres
$ psql
psql (8.4.9)
Type "help" for help.
postgres=#
Create user (if you haven’t done this yet):
postgres=# CREATE ROLE myuser WITH PASSWORD 'secret' LOGIN;
CREATE ROLE
postgres=#
Most of this is self-explanatory. Purposes of all parameters are explained in the documentation: CREATE DATABASE. Note, that there is template0 database used as a template. More on this you will find in the manual: Template Databases.
Note: above example was successfully tested also on PostgreSQL 9.1.2.