Kategorie-Archiv: Gebastel und Gelöt

Wikileaks Cable Mirror aufsetzen

Beim Kaffee heute morgen konnte ich die Meldung lesen, dass die wikileaks.org Domain vom US Provider wg. angeblicher DDOS Attacken abgeschaltet wurde. Mittlerweile kann man die von der Schweizer Piratenpartei gehostete Domain wikileaks.ch verwenden oder wikileaks.nl.

Nach dem lesen der Meldung hatte ich dann eben die Schnautze voll und habe einen mirror für die bisher releasten cable Dokumente aufgesetzt – Freiheit statt Angst.

Da viele Nachfragen über Twitter rein kamen wie das geht, hier eine kurze Anleitung:

  1. kummolativen Torrent File mit der Cable Site saugen.
  2. Auf webserver legen

Eine wichtige Anmerkung. Die Links in den Webseiten beziehen sich alle auf das webserver root. Daher kann man die Dateien nicht ohne weiteres in ein Unterverzeichnis legen.

Wenn ihr einen eigenen Mirror aufgesetzt habt, postet es doch kurz in den comments, dann nehme ich ihn in die Liste auf:

Update 6.12.2010: Wikileaks bietet nun auch die Möglichkeit an, einen Mirror anzumelden. Sie schieben dann die Daten aktiv auf den eigenen Server. Hat den Vorteil, dass man sich nicht mehr drum kümmern muss.

Update 7.12.2010: Mittlerweile gibt es hier eine 7z Datei mit den Torrents für alle jemals bei Wikileaks veröffentlichte Dokumente.

bei wikileaks.ch: http://wikileaks.ch/file/wikileaks_archive.7z

lokaler Mirror: http://wl.alios.org/wikileaks_archive.7z

Mehr Informationen dazu auch bei Uppercase.

Cortex-M3 On Chip Debugging unter Linux

Im letzten Eintrag habe ich berichtet wie man sich die GNU ARM Cortex-M3 Compiler Toolchain baut. Heute möchte ich kurz dokumentieren wie ich On-Chip-Debugging (OCD) ans laufen gebracht habe.

On-Chip-Debugging

Beim On-Chip-Debugging geht es darum, ein compiliertes Stück Software auf der Zielhardware auszuführen (in meinem Fall auf einem Keil MCBSTM32E Board mit einem Cortex-M3 Controller von STM) und der Möglichkeit es vom Entwicklungsrechner aus zu debuggen.

Die meisten modernen Controller bieten eine JTAG Schnittstelle. Über diese kann der Prozessor angehalten werden und Speicher und Register können ausgelesen und beschrieben werden. Früher hat man die JTAG Pins des Controllers über direkt über die IEEE 1284 Schnittstelle (Drucker Schnittstelle) des Entwicklungsrechners angeschlossen. Da die meisten PCs diese nicht mehr haben und diese zudem aus Timinggründen nicht immer optimal war, werden mittlerweile meist USB JTAG Adapter eingesetzt. Ich habe hier einen J-Link ARM-KS von Segger (von IAR gebranded).

Keil SMT32 Eval mit JTAG am Notebook
Keil SMT32 Eval mit JTAG am Notebook

OpenOCD selber kann entweder über eine eigne TCL basierte Sprache gesteuert werden, stellt aber auch ein GNU Debugger (GDB) kompatible Schnittstelle zur Verfügung. Über das GDB Interface kann man dann z.B. den Debugger der C/C++ Development Tools (CDT) für Eclipse verwenden, um Software direkt auf dem Target System zu debuggen.

Installation gdb

Als Erstes benötigt man einen für die Zielarchitektur (arm-elf) gebauten GDB:


$ cd /home/alios/src/toolchain
$ cvs -d :pserver:anoncvs@sourceware.org:/cvs/src login
{"anoncvs" als Passwort eingeben}
$ cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb
$ mkdir build-arm-elf/gdb
$ cd build-arm-elf/gdb
$ ./configure --target=arm-elf --prefix=/usr/local/arm-elf
$ make all
$ make install

Wenn alles geklappt hat und /usr/local/arm-elf/bin im Pfad ist, sollte man $ arm-elf-gdb starten können.

Installation OpenOCD

Als Nächstes muss dann noch das OpenOCD Paket gebaut werden:

$ cd /home/alios/src/toolchain
$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
$ mkdir build-openocd
$ cd build-openocd
$ ../openocd/configure --enable-jlink --disable-httpd --disable-doxygen-html

In dem Aufruf des configure Scripts sage ich, mit --enable-jlink, dass die Unterstützung für den von mir verwendeten JLink JTAG Adapter mit gebaut wird. Eine Liste aller Optionen für das configure Script und damit auch für eine Liste aller unterstützter JTAG Adapter erhält man mit ../openocd/configure --help.
Nun muss OpenOCD nur noch gebaut und installiert werden:

$ make all
$ make install

Nach der Installation sollte sich openocd starten lassen.

Konfiguration OpenOCD

Eine Standard Konfiguration für OpenOCD wird beim Start von OpenOCD u.A. in $HOME/.openocd/openocd.cfg Gesucht. Meine Konfiguration sieht so aus:


set WORKAREASIZE 0xffff
source [find interface/jlink.cfg]
source [find interface/stm32.cfg]
source [find cpu/arm/cortex_m3.tcl]
source [find chip/st/stm32/stm32.tcl]
reset_config srst_only
target cortex_m3 little run_and_init 0
flash bank stm32 0x08000000 0x00010000 0 0
flash auto_erase on
gdb_flash_program enable

Zunächst wird die maximale Größe der Workarea festgelegt. Dies ist die maximale RAM Menge, die z.B. vom Flash Programm auf dem Controller verwendet werden kann. Da der von mir verwendete STM32F103 über 64kB RAM verfügt, habe ich sie auf 0xffff gesetzt. Als Nächstes verweise ich auf einige der mit OpenOCD mitgelieferten Konfigurationsdateien (finden sich unter im Normalfall unterhalb von /usr/local/share/openocd/scripts). Mit den letzten 3 Zeilen wird das Flashen konfiguriert. Eine ausführliche Beschreibung der Konfigurationsmöglichkeiten findet sich im OpenOCD User’s Guide.

Ist alles richtig konfiguriert, der JTAG Adapter mit Entwicklungsrechner und Target Board verbunden und das Target mit Spannung versorgt, sollte man durch Eingabe von $ openocd den OpenOCD Daemon starten können. Dieser lauscht sowohl auf TCP Port 4444 (telnet Verbindung), wie auch auf TCP Port 3333 (gdb Verbindung).

GDB verwenden

Nun kann man sich mit dem GDB zum OpenOCD Verbinden. Die folgenen gdb-Befehle können sowohl im gdb Prompt eingegeben werden, oder in einer Datei zusammengefasst werden, die dem GDB beim Start übergeben wird:


target remote localhost:3333
set remote hardware-watchpoint-limit 4
set remote hardware-breakpoint-limit 6
monitor reset

Wenn alle geklappt hat, sollte man mit dem Target verbunden sein und kann mit dem Debuggen anfangen. Weiterführende Infos zum GDB findet ihr im GDB User Guide.

GNU ARM Cortex-M3 Toolchain selber bauen

Die GNU Toolchain unterstütz u.a. auch die neue Cortex-M3 Familie von ARM. Ich möchte hier kurz vorstellen, wie man sich selber die entsprechende Crosscompiler Toolchain baut.

Um eine vollständige Toolchain zu erhalten werden 3 Pakete benötigt:

Zunächst legt man sich ein Verzeichnis an, in dem der gesamte Buildprozess und die Sourcen liegen werden. Bei mir ist dies /home/alios/src/toolchain.
Die Toolchain wird vollständig nach /usr/local/arm-elf installiert. Für ein anderes Verzeichnis einfach den Parameter --prefix= bei den configure Aufrufen entsprechend abändern.

binutils installieren

Eine aktuelle Version der binutils kann hier heruntergeladen werden: ftp://sourceware.org/pub/binutils/snapshots

Die Version sollte im Prinzip egal sein, ich habe Version 2.20.51 gewählt. Im Anschluss werden die Sourcen entpackt, gebaut und installiert.


$ mkdir /home/alios/src/toolchain
$ cd /home/alios/src/toolchain
$ wget ftp://sourceware.org/pub/binutils/snapshots/binutils-2.20.51.tar.bz2
$ tar -jxf binutils-2.20.51.tar.bz2
$ mkdir build-arm-elf
$ mkdir build-arm-elf/binutils
$ cd build-arm-elf/binutils
$ ../../binutils-2.20.51/configure --prefix=/usr/local/arm-elf --target=arm-elf
[ ... configure output ... ]
$ make all
[ ... build output ... ]
$ sudo make install

GCC Teil 1 bauen

Der gcc wird in 2 Schritten gebaut. Zunächst wird der C und der C++ Compiler gebaut. Die libstdc++, die auch zum GCC gehört, kann allerdings erst gebaut werden,
nachdem eine libc installiert wurde (die newlib in diesem Fall). Daher wird der Build Prozess nach einer Weile mit einem Fehler abbrechen – davon nicht irritieren lassen.

Als Version habe ich mich für den aktuellen 4.4 Branch aus dem GCC subversion repository entschieden.


$ cd /home/alios/src/toolchain
$ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch
$ mkdir build-arm-elf/gcc
$ cd build-arm-elf/gcc
$ ../../gcc-4.4-branch/configure --target=arm-elf --prefix=/usr/local/arm-elf --disable-nls --disable-shared --disable-threads --with-gnu-ld --with-gnu-as --disable-multilib --disable-libssp --disable-libmudflap --disable-libgomp --with-dwarf2 --with-newlib -v --disable-werror --with-cpu=cortex-m3 --with-tune=cortex-m3 --with-mode=thumb --enable-target-optspace --with-float=soft --enable-languages=c,c++
[ ... configure output ... ]
$ make all
[ ... build output ... ]

checking for type equivalent to int8_t... configure: error: no 8-bit type
exit: Illegal number: please
exit: Illegal number: please
gmake[1]: *** [configure-target-libstdc++-v3] Error 1
gmake[1]: Leaving directory `/usr/home/alios/src/toolchain/build-arm-elf/gcc'

$ sudo make install

Nun sollte der GCC installiert sein. Ggf. muss das Verzeichnis bevor es weiter geht noch in den Pfad mit aufgenommen werden ($ export PATH=/usr/local/arm-elf/bin:$PATH ).

Ein Aufruf von $ arm-elf-gcc --version sollte funktionieren.

newlib installieren

Die Newlib ist eine für embedded System optimierte Implementierung der C Standard Bibliothek (libc). Die aktuellste Version erhält man aus dem CVS.


$ cd /home/alios/src/toolchain
$ mkdir newlib-cvs
$ cd newlib-cvs
$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src login
Als Passwort "anoncvs" eingeben
$ cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/src co newlib
[ ... auschecken des Sourcecodes ... ]
$ cd ..
$ mkdir build-arm-elf/newlib
$ cd build-arm-elf/newlib
$ ../../newlib-cvs/src/configure --with-newlib --disable-newlib-io-float --disable-newlib-supplied-syscalls --prefix=/usr/local/arm-elf --target=arm-elf
[ ... configure output ... ]
$ make all
[ ... build output ... ]
$ sudo make install

GCC Teil 2 bauen

Nun ist auch die libc installiert und es fehlt nur noch die libstdc++. Dazu wird in das gcc Build-Verzeichniss zurrück gekehrt und der Build Prozess fortegesetzt.


$ cd /home/alios/src/build-arm-elf/gcc
$ make all
[ ... build output ... ]
$ sudo make install

Eine vollständige C/C++ Toolchain für den Cortex-M3 ist nun installiert.

In einem weiteren Artikel erkläre ich wie man OpenOCD mit GDB zum On Chip Debugging einsetzt.