Avarice für Atmel AVR JTAGICE3 unter Cygwin(64Bit) bauen

[Sebastian W. (braindog)]

Als Fortsetzung unter neuem Titel nach neuem Thema zum Ende des Threads 
Beitrag "Re: Zu viele Symbole werden gestrippt (Code zu klein)"

Nach einigen Schwierigkeiten bei dem Thema wollte ich diese Lösung zur 
Diskussion präsentieren.

@ Volker: Ich wechsele hier in einen neuen Thread, da das Topic zu 
unserem Thema nicht mehr ganz passend war ;-)

"Kurz" umrissen sieht meine derzeitige Lösung wie folgt aus:

Mein frisch installiertes Cygwin Version 2.852 (64bit) mit letztlich 
folgenden Paketen samt ihrer Abhängigkeiten:

# autoconf 13-1
# automake 9-1
# make 4.0-2
# cygwin32-gcc-core 4.8.3-4
# cygwin32-g++-core 4.8.3-4
# gcc-core 4.8.3-5
# g++-core 4.8.3-5
# w32api-runtime-debuginfo 3.2.0-1
# mingw64-x86_64-gcc-core (4.8.3-1)
# mingw64-x86_64-gcc-core-debuginfo (4.8.3-1)
# mingw64-x86_64-g++-core (4.8.3-1)
# cygwin32-libbfd (2.23.51-1)
# gdb (7.8-2)

Der in Cygwin verwendete GCC meldet bei "gcc -v":

Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/lto-wrapper.exe
Ziel: x86_64-pc-cygwin
Konfiguriert mit: /cygdrive/i/szsz/tmpp/gcc_old/gcc-4.8.3-5.x86_64/src/gcc-4.8.3/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc_old/gcc-4.8.3-5.x86_64/src/gcc-4.8.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread-Modell: posix
gcc-Version 4.8.3 (GCC)

Zusätzlich noch ein MinGW(x86_64-w64-mingw32) von 
http://sourceforge.net/projects/tdm-gcc/
Der verwendete GCC meldet bei "gcc -v":

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 4.9.2 (tdm64-1)

In ein extra Verzeichnis wurden folgende Pakete direkt von Sourceforge 
aus dem Code-tree heruntergeladen und entpackt:

avarice-code-347-trunk
libusb-win32-code-413-trunk

Den sehr häufig wiederholten Bauprozess des avarice hab ich in ein 
Skript gebannt.
Hier hatte ich erst die gleichen Aufrufe wie auf der Seite verwendet 
(relative Pfade): 
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Dann habe ich es, wegen Ungereimtheiten beim auffinden der 
libusb-Sourcen, mit absoluten Pfaden angegeben, Ausschnitt:

...
# export startdir=$HOME/build/libusb-win32-bin-1.2.6.0
# export CPPFLAGS=-g" -I$startdir/include"
# export CFLAGS=-g" -I$startdir/include"
# export LDFLAGS="-static -L$startdir/lib/gcc "

export startdir=$HOME/build/libusb-win32-code-413-trunk/libusb
export CPPFLAGS=-I"$startdir/src"
export CFLAGS=-I"$startdir/src"
export LDFLAGS="-static -L$startdir "
...

Wegen folgender Fehlermeldung habe ich eine Änderung an den 
Avarice-Sourcen vorgenommen (gekürzter Ausschnitt):

...
In file included from ../../src/jtag2usb.cc:51:0:
/usr/include/w32api/usb.h:29:9: Fehler: »PVOID« bezeichnet keinen Typ
 typedef PVOID PIRP;
         ^
/usr/include/w32api/usb.h:30:9: Fehler: »PVOID« bezeichnet keinen Typ
 typedef PVOID PMDL;
         ^
In file included from /usr/include/w32api/usb200.h:23:0,
                 from /usr/include/w32api/usb.h:36,
                 from ../../src/jtag2usb.cc:51:
...

Anpassung in "...\avarice\src\jtag2usb.cc": "usb.h" raus, dafür 
"lusb0_usb.h" rein

#ifdef HAVE_LIBUSB_2_0
#  include <libusb20.h>
#  include <libusb20_desc.h>
#  include <poll.h>
#else
#  include "lusb0_usb.h"
//#  include <usb.h>
#endif

Das Bauen von "libusb-win32-code-413-trunk/libusb" per Cygwin schmeißt 
folgenden Fehler:

$ make
gcc -O2 -Wall -DWINVER=0x500  -DLOG_APPNAME=\"libusb0-dll\" -DTARGETTYPE=DYNLINK -c ./src/usb.c -o usb.2.o  -I./src -I./src/driver -I.
In file included from ./src/usb.c:14:0:
./src/usbi.h:10:23: Fehler: In Konflikt stehende Typen für »uint32_t«
 typedef unsigned long uint32_t;
                       ^
In file included from /usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include/stdint.h:9:0,
                 from /usr/include/cygwin/types.h:20,
                 from /usr/include/sys/types.h:481,
                 from /usr/include/stdio.h:48,
                 from ./src/usb.c:10:
/usr/include/stdint.h:34:22: Anmerkung: Vorherige Deklaration von »uint32_t« war hier
 typedef unsigned int uint32_t;
                      ^
Makefile:139: recipe for target 'usb.2.o' failed
make: *** [usb.2.o] Error 1

Dafür baut es mittels MinGW(x86_64-w64-mingw32) durch einen Aufruf per 
mingw32-make.exe in einer separaten Konsole (normale Windows-Shell, 
nicht Cygwin) durch.

Jetzt kann ich Avarice wie zuvor beschrieben in Cygwin per Configure und 
make durchbauen.

Meine Fallstricke waren:
- Der verwendete native Compiler gcc (x86_64-pc-cygwin-gcc.exe) konnte 
beim Configure-Aufruf des Avarice nicht die libusb.a einbinden.

- bei den Pfadangaben für den Configure-Aufruf wurden relative Pfade ( 
../../Ziel) verwendet und haben zusätzlich zur Verwirrung beigetragen.

- Fehlende Datentypbeschreibungen, vermutlich durch fehlender 
"windows.h", daher Änderung des Include in jtag2usb.cc" aus "usb.h" wird 
ein "lusb0_usb.h".

- Der Compiler x86_64-pc-cygwin-gcc.exe in cygwin baut bei mir nicht die 
"libusb-win32-code-413-trunk" -> Bauen durch MinGW(x86_64-w64-mingw32)

- Kollision mit einem make.exe aus einer anderen GNU-Toolchain, -> 
Aufruf mingw32-make.exe im Verzeichnis

Somit erhalte ich folgende Datei-Details:

$ Datei=~/install/bin/avarice; ls -l $Datei;echo;file $Datei; echo ;ldd $Datei

-rwxr-xr-x 1 user Domain Users 1472325 13. Mrz 16:05 /home/user/install/bin/avarice

/home/user/install/bin/avarice: PE32+ executable (console) x86-64, for MS Windows

        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x76ed0000)
        kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x76b90000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/system32/KERNELBASE.dll (0x7fefd420000)
        libusb0.dll => /cygdrive/c/WINDOWS/system32/libusb0.dll (0x6a480000)
        msvcrt.dll => /cygdrive/c/WINDOWS/system32/msvcrt.dll (0x7feff140000)
        SETUPAPI.dll => /cygdrive/c/WINDOWS/system32/SETUPAPI.dll (0x7fefd9e0000)
        CFGMGR32.dll => /cygdrive/c/WINDOWS/system32/CFGMGR32.dll (0x7fefd600000)
        RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x7fefd890000)
        ADVAPI32.dll => /cygdrive/c/WINDOWS/system32/ADVAPI32.dll (0x7fefee70000)
        sechost.dll => /cygdrive/c/WINDOWS/SYSTEM32/sechost.dll (0x7fefd9c0000)
        GDI32.dll => /cygdrive/c/WINDOWS/system32/GDI32.dll (0x7fefebf0000)
        USER32.dll => /cygdrive/c/WINDOWS/system32/USER32.dll (0x767d0000)
        LPK.dll => /cygdrive/c/WINDOWS/system32/LPK.dll (0x7fefef70000)
        USP10.dll => /cygdrive/c/WINDOWS/system32/USP10.dll (0x7fefdd30000)
        OLEAUT32.dll => /cygdrive/c/WINDOWS/system32/OLEAUT32.dll (0x7fefef80000)
        ole32.dll => /cygdrive/c/WINDOWS/system32/ole32.dll (0x7fefec60000)
        DEVOBJ.dll => /cygdrive/c/WINDOWS/system32/DEVOBJ.dll (0x7fefd6e0000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
        IMM32.DLL => /cygdrive/c/WINDOWS/system32/IMM32.DLL (0x7feff110000)
        MSCTF.dll => /cygdrive/c/WINDOWS/system32/MSCTF.dll (0x7fefd700000)

Ein Aufruf sieht dann so aus:

$ avarice.exe -r -3
AVaRICE version 2.13svn20141210, Mar 13 2015 16:22:38

Defaulting JTAG bitrate to 250 kHz.

JTAG config starting.
Found a device, serial number: J30200028833
Reported device ID: 0x9403
Configured for device ID: 0x9403 atmega16
JTAG config complete.

Reading Fuse Bytes:
      High Fuse byte -> 0x10
       Low Fuse byte -> 0x6f

Feedback und Verbesserungsvorschläge sind gern gesehen.

Gruß
Sebastian

[Volker (Gast)]

Freut mich, dass Du es auf anderem Wege auch alleine geschafft hast. Es 
ist ohnehin super, wenn mehrere Wege veröffentlicht werden, der eine 
geht vielleicht beim einen, der andere beim anderen, aber eben nicht bei 
beiden... So ist allen am besten geholfen.

[Günter (Gast)]

Mit Cygwin32 funktioniert ./configure fuer version 2.13, aber nicht fuer 
die letzte version im trunk (r350), weil die Dateien Makefile.in und der 
Ordner config-aux fehlen. Ist da SVN ein Fehler unterlaufen oder mache 
ich etwas falsch?

[Günter (Gast)]

Sebastian,

vielen Dank fuer die Bauanleitung. Ich konnte alle Schritte bis auf den 
letzten erfolgreich nachvollziehen. Mein so gebautes avarice kann mein 
JTAGICE3 leider nicht finden. Also habe ich ein paar printfs 
eingefuehrt, die mir die Resultate der usb_find_busses, 
usb_find_devices, usb_get_busses, und usb_get_devices ausdrucken. Die 
Aufrufe finden nur einen Bus und keine Bauteile (bus->dirname: usb-0). 
Ich vermute daher, dass irgend etwas in der libusb0.dll oder zwischen 
dieser DLL und Windows 7 64-bit nicht funktioniert. (lsusb listet alle 
USB Teile auf. ldd gibt mir das gleiche Ergebnis wie bei Dir.)

Kannst Du mir Dein avarice.exe schicken / an einen Beitrag anhaengen?

Gruss
Günter

[Jim M. (turboj)]

Günter schrieb:
> Aufrufe finden nur einen Bus und keine Bauteile (bus->dirname: usb-0).
> Ich vermute daher, dass irgend etwas in der libusb0.dll oder zwischen
> dieser DLL und Windows 7 64-bit nicht funktioniert.

Diese DLL funktionier nur, wenn der LibUSB-Win32 (Filter-)Treiber für 
das betreffende Gerät installiert wurde. Was bei Hersteller Treibern 
eher selten der Fall ist. Installieren tut man den am Besten mit Zadig.

[Jörg W. (dl8dtl) (Moderator)]

Günter schrieb:
> Ist da SVN ein Fehler unterlaufen oder mache
> ich etwas falsch?

Die SVN-Version ist nicht „gebootstrappet“ (schönes Denglisch ;),
d. h. es gibt keinen configure-Script und all die anderen Dinge,
die aus autoconf/automake so heraus gepurzelt bekommen.

Der mit herumliegende Script namens Bootstrap würde dies erledigen,
allerdings benötigt man dazu natürlich logischerweise autoconf und
automake (die zum eigentlichen Bauen dann nicht mehr nötig wären).