avr-gcc und avr-libc für moderne xmega-devices (unter Linux)

[funkmaus (Gast)]

Hallo zusammen,

ich versuche derzeit möglichst schmerzfrei, eine aktuelle AVR-Toolchain 
auf meinem Rechner zu installieren (Debian Bullseye). Früher war das ja 
sehr einfach, da es out-of-the-box funktionierte:

apt install gcc-avr avr-libc avrdude

Der gcc-avr in Debian ist aber uralt. Die avr-libc sowieso.

Nun bin ich, auch (besser: vor allem) dank dieses Forums und Beiträgen 
insb. von Jörg, Veit D. und Johann, meinem Ziel gefühlt schon näher 
gekommen. Mein Vorgehen soweit:

1. Alten gcc-avr 5.4.0 installieren (s.o.)
2. Eine aktuelle avr-libc bauen:
2a. Klone https://github.com/avrdudes/avr-libc
2b. ./bootstrap (Achtung, das hat eine python2-Abhängigkeit!) && 
./configure ... && make && make install
3. Von https://packs.download.microchip.com/ die zu den gewünscht 
Controllern (d.h. von legacy gcc-avr nicht unterstützten Typen) 
"device-specs" nach /usr/lib/gcc/avr/5.4.0/device-specs/ kopieren.
4. Ebenfalls von dort die gewünschten *.o- und *.a-Dateien nach 
/usr/local/avr/lib/avrxmega3/short-calls/ kopieren. (Der restliche 
Inhalt unter /usr/local/avr/ kommt von der selbstgebauten avr-libc).

Das, so dachte ich, müsste genug sein, um ein Projekt für einen der 
neuen AVR-Typen zu bauen. Funktioniert aber leider nicht.

Konkretes Beispiel: Ich möchte ein Minimalprojekt "test.c" für einen 
attiny202 bauen:

avr-gcc -I /usr/local/avr/include/ -L /usr/local/avr/lib/avrxmega3/short-calls/ -mmcu=attiny202 test.c

Ergibt:

In file included from /usr/local/avr/include/avr/io.h:759:0,
                 from test.c:2:
/usr/local/avr/include/avr/lock.h:234:0: warning: "LOCKBITS_DEFAULT" redefined
 #define LOCKBITS_DEFAULT (0xFF)
 ^
In file included from /usr/local/avr/include/avr/io.h:438:0,
                 from test.c:2:
/usr/local/avr/include/avr/iotn202.h:4655:0: note: this is the location of the previous definition
 #define LOCKBITS_DEFAULT  (0xc5)
 ^
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: cannot find crtattiny202.o: Datei oder Verzeichnis nicht gefunden
collect2: error: ld returned 1 exit status

Die warnings bekomme ich bestimmt selbst in den Griff. Das Problem ist, 
dass er die crtattiny202.o nicht findet. Die ist aber da (siehe Punkt 4 
von oben):

ls /usr/local/avr/lib/avrxmega3/short-calls/

crtattiny202.o  crtattiny214.o  crtattiny414.o  crtattiny417.o  crtattiny816.o  libattiny202.a  libattiny214.a  libattiny414.a  libattiny417.a  libattiny816.a  libc.a  libprintf_flt.a  libscanf_flt.a
crtattiny212.o  crtattiny412.o  crtattiny416.o  crtattiny814.o  crtattiny817.o  libattiny212.a  libattiny412.a  libattiny416.a  libattiny814.a  libattiny817.a  libm.a  libprintf_min.a  libscanf_min.a

Was mache ich falsch?

Ich möchte bei dieser Gelegenheit ganz herzlich Jörg und Johann und 
allen anderen Beteiligten danken, dass sie die Arbeiten an der avr-libc 
wieder aufgenommen haben. Ich trage beizeiten gerne mal mit einer 
Aktualisierung der Dokumentation bei.

Viele Grüße,
funkmaus.

[Heiko L. (zer0)]

Ich schätze, dass die .o-Dateien analog zu zb crt0.o auf Linux 
funktionieren. Dafür gelten die normalen lib-Suchpfade nicht. -B<pfad> 
als zusätzlicher Parameter könnte funktionieren.

[Le X. (lex_91)]

Ich habe mir eine VM als buildserver eingerichtet. Die kann man notfalls 
auch zusammen mit dem Projekt archivieren und den build auch in 20 
Jahren noch nachvollziehen.
Musste dabei auch feststellen dass der avr-gcc unter Debian asbach-Uralt 
ist, deswegen bin ich in der VM dann zu Arch Linux gewechselt.

Das beantwortet deine Frage zwar nicht direkt, gibt dir aber vielleicht 
neue Anregungen.
Ich persönlich mag mir das Hostsystem nicht so verbasteln.
Und wild eigene Compiler und libs zu bauen und auf dem System zu 
verteilen läuft für mich unter "Basteln". Ich finde es schwierig, nach 
einigen Monaten Abstand noch nachzuvollziehen was man damals gemacht 
hat.

[Kaj (Gast)]

Le X. schrieb:
> Ich finde es schwierig, nach
> einigen Monaten Abstand noch nachzuvollziehen was man damals gemacht
> hat.

Es steht dir frei, dein Vorgehen, in einer dir angenehmen weise, zu 
dokumentieren.

[Stefan F. (Gast)]

funkmaus schrieb:
> Der gcc-avr in Debian ist aber uralt. Die avr-libc sowieso.

Ja, zum Glück war das für mich bisher noch kein Showstopper.

Mich wundert allerdings, dass solche Programmpakete überhaupt 
Bestandteil der Distribution sind. Vermutlich nutzen es weniger als 1% 
der User.

Meine SMS Server Tools (smstools) hat auch irgendwer zur Distribution 
hinzugefügt - weiß der Geier warum. Wer benutzt das noch?

[funkmaus (Gast)]

Hallo zusammen,

danke für die Antworten. Die Lösung von Heiko L. funktioniert bestens. 
Mir war in meinem bisherigen Leben schlicht noch nie die -B-Option 
untergekommen. Bei den ARM-Cortex-Prozessoren bzw. deren Toolchain liegt 
der Startup-Code meist als Quelldatei vor und wird beim Build direkt 
mitverwurstet, sodass ich bisher noch nie in die Bredouille gekommen 
bin, mich mit -B auseinanderzusetzen. Also

avr-gcc -I /usr/local/avr/include/ -L /usr/local/avr/lib/avrxmega3/short-calls/ -B /usr/local/avr/lib/avrxmega3/short-calls/ -mmcu=attiny202 test.c

funktioniert bestens, vielen Dank!

Damit ergibt das oben beschriebene Vorgehen eine, wie ich finde, ganz 
akzeptable Lösung für eine Toolchain für die "neuen" AVR-Prozessoren.

Ideal wäre es natürlich, wenn Debian direkt einen aktuellen gcc für AVR 
mitliefern würde. Upstream scheint es den ja zu geben. Und die aktuelle 
avr-libc tut ja auch bereits vieles (obiges Repository).

Vlt. noch eine Frage zum Schluss: Ich dachte bisher immer, dass die 
avr-libc den Startup-Code mitliefern würde. Warum ist das in diesem Fall 
nicht so? Ist das schlicht noch nicht implementiert oder habe ich hier 
etwas missverstanden?

Vlt. noch eine blöde Frage: Gibt es mittlerweile eine Zukunftsaussicht 
für das AVR-Target ab gcc 11 bzw. 12?

Besten Dank noch einmal und einen heiligen Restabend noch (Kind schläft, 
ich darf wieder basteln),
funkmaus.

[funkmaus (Gast)]

Vlt. doch noch einen Nachtrag:

Le X. schrieb:
> Ich persönlich mag mir das Hostsystem nicht so verbasteln.

Kann ich durchaus nachvollziehen. Allerdings empfinde ich einen Haufen 
VMs im Archiv auch irgendwie belastend. Ich will aber auch auf gar 
keinen Fall für jedes Projekt bzw. jeden Controller einen Haufen Mist 
installieren und/oder irgendeinen proprietären Kram benutzen, der es 
beim nächsten Systemupdate unnachvollziehbarerweise nicht mehr tut.

Die oben skizzierte Lösung ist für mich akzeptabel. Ich müssen lediglich 
für jeden Controller, der nicht von den Repository-Quellen unterstützt 
wird, drei Dateien von Microchip heruntergeladen und ins System abgelegt 
werden. Dort dürfen sie dann schlummern. Der avr-gcc- bzw. -libc-Rest 
ist ja auch nur ein einziges Mal da.

Viele Grüße,
funkmaus.

[900ss (900ss)]

Man könnte auch die Toolchain aus Arduino nutzen wenn der verwendete 
Controller unterstützt wird. Hab ich auch schon probiert und 
funktioniert. Da ist dann auch die avr-libc gleich dabei.
Am Ende hab ich mir aber auch mit -B geholfen :) Das ging auch klaglos.

[Heiko L. (zer0)]

funkmaus schrieb:
> Vlt. noch eine Frage zum Schluss: Ich dachte bisher immer, dass die
> avr-libc den Startup-Code mitliefern würde. Warum ist das in diesem Fall
> nicht so? Ist das schlicht noch nicht implementiert oder habe ich hier
> etwas missverstanden?

Da drin muss nicht unbedingt StartUp-Code sein - es können auch 
allgemein Hilfsfunktionen vom Compiler sein. Zum Beispiel Floating-Point 
Operationen für Controller ohne Hardware CPU Support oder sowas. Das 
Zeug liegt sozusagen also eine Ebene tiefer als die libc und enthält 
das, was man zur Realisierung des Sprachstandards braucht. Die Grenze, 
was davon direkt im Compiler mit eingebacken und was so extern 
bereitgestellt wird, ist vermutlich nicht ganz so leicht zu ziehen.

Ich weiss aber auch nicht definitiv, was da jetzt genau drin ist: Mit 
readelf oder objdump könnte man in die .o Dateien reinschauen, ob das 
irgendwelche Hinweise gibt.

[Veit D. (devil-elec)]

funkmaus schrieb:
> Vlt. noch eine blöde Frage: Gibt es mittlerweile eine Zukunftsaussicht
> für das AVR-Target ab gcc 11 bzw. 12?

Nach damaliger Spendenaktion wird die AVR Unterstützung im gcc 
fortgesetzt. Für den avr-gcc Nutzer ist alles unverändert.

[Johann L. (gjlayde)]

funkmaus schrieb:
> Das Problem ist, dass er die crtattiny202.o nicht findet.
> Die ist aber da (siehe Punkt 4 von oben):
>

ls /usr/local/avr/lib/avrxmega3/short-calls/

>

crtattiny202.o  ...
>

Hier bin ich mir nicht sicher, ob avr-gcc die CRTs in diesen Pfaden 
sucht, weil avrxmega3 und avrxmega3/short-calls erst mit v8 zu 
Multilib-Pfaden wurden, siehe

https://gcc.gnu.org/gcc-8/changes.html#avr

Zur allgemeinen Vorgehensweise:

1) -I /usr/local/avr/include/ -L 
/usr/local/avr/lib/avrxmega3/short-calls/ würde ich weg lassen.  Diese 
Pfade kennt gcc von --prefix bei configure, und den Multilib-Anteil vom 
specs-File.  Dieses wiederum gibt man an per -B <pfad>, wobei <pfad> den 
Ordner device-specs enthält.

2) Falls das Device bereits nativ dem Compiler bekannt ist (was seit v5 
lediglich bedeutet, dass device-specs ein entsprechendes specs-<mcu> 
enthält) dann natürlich kein -B angeben.

3) Include-Pfade kann man sich anzeigen lassen mit -v:

avr-gcc -v ...
...
#include "..." search starts here:
#include <...> search starts here:
 <install>/bin/../lib/gcc/avr/8.5.0/include
 ...

3b) Auch verwendete lib-Pfade kann man mit -v anzeigen lassen, 
vorausgesetzt es kommt bis zum Linken.

4) Ob avr-gcc den richtigen Multilib-Pfad kennt (abhängig von Version) 
kann man testen mit

> avr-gcc -mmcu=attiny202 --print-multi-directory
avrxmega3/short-calls

> avr-gcc -mmcu=attiny202 --print-multi-directory
avrxmega3/short-calls

> avr-gcc -mmcu=attiny202 --print-file-name libgcc.a
<install>/bin/../lib/gcc/avr/<version>/avrxmega3/short-calls/libgcc.a

> avr-gcc -mmcu=attiny202 --print-file-name libc.a
<install>/bin/../lib/gcc/avr/<version>/../../../../avr/lib/avrxmega3/short-calls/libc.a

Wegen diverser Bugs wie PR90706 würde ich maximal v8 nehmen.  Und 
minimal v8 wegen neuer Features, siehe die obigen Release Notes.

5) Falls avrxmega3 noch nicht unterstützt wird, kann man ATtiny202 etc. 
auf avrxmega2 abbilden mit den offensichtlichen Nachteilen, dass z.B. 
Flash-in-RAM-Address-Space noch nicht unterstützt wird.  Die Abbildung 
erfolgt im specs-<mcu>.

Prinzipiell sind specs-Files nicht komplett unabhängig von Compiler- und 
Binutils-Version, auch wenn das wünschenswert ist.  Neue Features wie 
-mgcc-isr sollen aber auch nicht blockiert werden, so dass sich solche 
Features auch im specs-File niederschlagen.