CentOS6: AVRStudio 5.1 toolchain + avr-libc 1.8.0

Ha valaki használ ilyet, összeraktam Bingo csomagja alapján (azt jelentősen módosítva) és az AVRStudio 5.1 patchek felhasználásával egy buildscriptet centoshez. Szerencsére ennyit azért nem küzdöttem vele, de hasznos olvasmány volt. :)

  1. a binutils-devel és glibc-static csomag legyen telepítve
  2. létrehozod az /opt/tools/atmel könyvtárat vagy a scriptben a prefix= sort módosítod és ehhez a könyvtárhoz adsz írási jogot a felhasználódnak
  3. ./getfiles.sh
  4. ./get-patches.sh
  5. ./buildavr-toolchain-centos.sh

Természetesen nem kell root jog a fordításhoz. Igény avr-libc 1.7.1 is választható, ekkor csak annyi a teendő, hogy a "getfiles.sh" előtt át kell írni az avr-libc verziószámát a konfigfájlban. Az AVRStudio binutils patcheket egy helyen módosítottam, hogy AVR-Eclipse kompatibilis legyen a compiler. Talán Ubuntu-n is lefordul, azt nem próbáltam, az részemről nem támogatott.

A csomag fordít avrdude-t is, azzal csak annyi bajom van, hogy dragonon keresztül xmega-ba letöltés után nincs automatikus reset, az xmega nem indul el csak táp ki/be után. De lehet, hogy az AVRStudio 5.1 dragon firmware frissítése az oka.

A csomag link.


./avr-gcc --target-help -mlist-devices

at90s2313, at90s2323, at90s2333, at90s2343, attiny22, attiny26, at90s4414,
at90s4433, at90s4434, at90s8515, at90c8534, at90s8535, ata6289, attiny13,
attiny13a, attiny2313, attiny2313a, attiny24, attiny24a, attiny4313, attiny44,
attiny44a, attiny84, attiny84a, attiny25, attiny45, attiny85, attiny261,
attiny261a, attiny461, attiny461a, attiny861, attiny861a, attiny43u, attiny87,
attiny48, attiny88, attiny80, at86rf401, at43usb355, at76c711, atmega103,
at43usb320, at90usb82, at90usb162, atmega8u2, atmega16u2, atmega32u2, attiny167,
attiny1634, atmega8, atmega8a, atmega48, atmega48a, atmega48pa, atmega48p,
atmega88, atmega88a, atmega88p, atmega88pa, atmega8515, atmega8535, atmega8hva,
at90pwm1, at90pwm2, at90pwm2b, at90pwm3, at90pwm3b, at90pwm81, at90pwm161,
atmega16, atmega16a, atmega161, atmega162, atmega163, atmega164a, atmega164p,
atmega164pa, atmega165, atmega165a, atmega165p, atmega165pa, atmega168,
atmega168a, atmega168p, atmega168pa, atmega169, atmega169a, atmega169p,
atmega169pa, atmega16hva, atmega16hva2, atmega16hvb, atmega16hvbrevb, atmega16m1,
atmega16u4, atmega26hvg, atmega32, atmega32a, atmega323, atmega324a, atmega324p,
atmega324pa, atmega325, atmega325a, atmega325p, atmega325pa, atmega3250,
atmega3250a, atmega3250p, atmega3250pa, atmega328, atmega328p, atmega329,
atmega329a, atmega329p, atmega329pa, atmega3290, atmega3290a, atmega3290p,
atmega3290pa, atmega32c1, atmega32m1, atmega32u4, atmega32u6, atmega406,
atmega64, atmega64a, atmega640, atmega644, atmega644a, atmega644p, atmega644pa,
atmega645a, atmega645p, atmega645, atmega6450, atmega6450a, atmega6450p,
atmega649, atmega649a, atmega649p, atmega6490, atmega6490a, atmega6490p,
atmega64c1, atmega64m1, atmega64hve, atmega64rfa2, atmega64rfr2, atmega32hvb,
atmega32hvbrevb, atmega48hvf, at90can32, at90can64, at90pwm216, at90pwm316,
atmega16c1, atmega32c1, atmega64c1, atmega16m1, atmega32m1, atmega64m1,
atmega16u4, atmega32u4, atmega32u6, at90scr100, at90usb646, at90usb647, at94k,
m3000, atmega128, atmega128a, atmega1280, atmega1281, atmega1284, atmega1284p,
atmega128rfa1, atmega128rfa2, atmega128rfr2, at90can128, at90usb1286,
at90usb1287, atmega2560, atmega2561, atmega256rfa2, atmega256rfr2, atmxt224,
atmxt224e, atmxt336s, atxmega16a4, atxmega16a4u, atxmega16c4, atxmega16d4,
atxmega16x1, atxmega32a4, atxmega32a4u, atxmega32c4, atxmega32d4, atxmega32x1,
atxmega64a3, atxmega64a3u, atxmega64a4u, atxmega64b1, atxmega64b3, atxmega64d3,
atxmega64d4, atxmega64a1, atxmega64a1u, atxmega128a3, atxmega128a3u,
atxmega128b1, atxmega128b3, atxmega128c3, atxmega128d3, atxmega128d4,
atxmega192a3, atxmega192a3u, atxmega192c3, atxmega192d3, atxmega256a3,
atxmega256a3u, atxmega256a3b, atxmega256a3bu, atxmega256c3, atxmega256d3,
atxmega384c3, atxmega384d3, atxmega128a1, atxmega128a1u, atxmega128a4u, attiny4,
attiny5, attiny9, attiny10, attiny20, attiny40, at90s1200, attiny11, attiny12,
attiny15

( hrgy84 | 2012. 04. 27., p – 00:59 )

Itt annyi okos crosscompileres emberke van, nekem meg van egy related kerdesem, hat felteszem.

Van az openwrt-hez adott sdk, amiben van egy toolchain. En ezt anno kirippeltem, es gyonyoruen fordit MIPSEL architekturara, mint a WRT54GL eszkozom, mind pedig a BluePanther Syvio 200A-mon gyonyoruen futnak az ezzel a toolchainnel generalt progik.
Viszont, ez a toolchain a gcc 3.4.6-os verziojara epit, ami, valljuk be, kisse odivatu mar. Viszont, a gcc -v altal kiirt konfiguracios opciokkal, illetve a tobbi progibol kibanyaszott es a netrol osszeollozott infok segitsegevel forditott gcc 4.x toolchainnel forditott binarisok egyszeruen nem futnak az eszkozeimen, egyaltalan.
Valtozott valami? Hogyan lehetne kideriteni, mi lenne a helyes konfig a GCC4 szerint?

Amit biztosan tudok, hogy a gcc3 egy ilyen binarist kop ki magabol: 


mc: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), stripped

A libc minden esetben uclibc ha jol tudom, szoval itt tul sok vicc nem lehet.

Mar tobbszor nekifutottam a dolognak, de midnig feladtam, mert egyszeruen tobb orai munkaval sikerult mindig egy olyan toolchaint osszerakni, ami totalisan nem mukodott.

Nekem mar egy valamilyen kiindulasi alap is jo lenne, hogy egyaltalan mi alapjan lehet beloni ezeket az architekturakat, eleg sok opcioja van a gcc-nek, nem biztos, hogy en ezzel szeretnek hosszu heteket szorakozni...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A gcc4 fordítása az új függőségei miatt macerás, de ettől még mennie kéne. Ha jól látom az eszközeid firmware-je 2.4-es kernelt használ, pontosan ugyanazt az uclibc verziót használod a 4-es GCC-hez is vagy újabbat? Ha újabbat akkor ott lehet a gond, mert az újabb uclibc és a 2.4 kernel ABI az uclibc faq szerint nem barátok.

Asszem ugyanazt, de eleve az a problema, hogy a rendszer nem azt mondja, hogy ezmegez nem fut, vagy segmentation fault vagy valami, hanem konkretan shell scriptkent probalja ertelmezni a binarist, tehat mintha az ELF detektalasig nem jutnank el.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A libc minden esetben uclibc ha jol tudom, szoval itt tul sok vicc nem lehet.

Elvben lehet: "uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries."

A Buildroot-ot szoktam hasznalni, azzal viszonylag egyszeruen elo lehet allitani egy toolchaint.

Azzal is probaltam mar, pontosan ugyanazt a verziot bokdostem be neki, de meg egy egyszeru, statikusan forditott hello world se fut vele. Tehat nem az a baj, hogy valami libet hianyol, hanem mintha tok mas ELF formatumot kopne ki magabol, a mediacenter konkretan scriptkent akarja futtatni a keletkezett fajlokat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( balagesz | 2012. 04. 28., szo – 01:54 )

Subscribe! :)

Az EPEL-ben van avr-gcc a 6-oshoz, bar hogy milyen peccsekkel van forgatva, az jo kerdes. Ezek az "AVRStudio 5.1 patchek" azok mik? Jol ertem-e, hogy ezeket az ATMEL csinalta, es ezzel a peccs-keszlettel forditott gcc van a Windows-os AVRStudio 5.1-ben? Elso olvasasra mar majdnem megorultem, hogy lett belole Linux port. (Mondjuk minek? :) ) Regen volt rola szo, talan az Eclipse alapjara volt tervben egy cross-platform fejleszto kornyezet, de ez ugy eltunt a hirekbol, mintha almodtam volna. Almodtam?

"Ezek az "AVRStudio 5.1 patchek" azok mik?"

Igen jól érted, telepítettem egy AVRStudio 5.1-et Windowsra, ott az egyik könyvtárban ott vannak a gcc és binutils patchek azaz amit ők módosítottak a gcc-n (GPL). Ezeket a patcheket (egy pici módosítással) használtam fel linuxon a gcc fordításához. Ezek a patchek benne vannak a zip-ben.

Így reményeim szerint az így készült avr-gcc linuxon ekvivalens az avrstudio 5.1 telepítőben lévő avr-gcc-vel. Feltéve, hogy tényleg minden patchet kiadott az atmel. Ennek az egésznek csak annyi célja volt részemről, hogy ha a projektet később majd esetleg Windowson kell folytatni, akkor nem akarok meglepetéseket. A célom tehát nem az volt, hogy a legújabb gcc-m legyen Linuxon, hanem az, hogy a lehető legkevesebb problémával átvihető legyen a projekt a két platform között, ha úgy alakul majd.

AVR Eclipse Plugin van, él és virul, használom, működik, kezeli az avrdude-t is, bugok persze vannak. :) Az atmel patchekbe azért kellett belenyúlnom mert ez az eclipse plugin nem ismeri az atmel patchekkel fordított gcc rejtelmeit, és alapállapotban atmel patchekkel fordított gcc esetén nem képes lekérdezni a támogatott MCU listát, mivel az atmel erre egy másik kapcsolót vezetett be, ráadásul a kimenete is más formátumú, tehát másik parser is kéne hozzá. Eredetileg egyébként nem is a gcc hanem a binutils (assembler) által támogatott MCU listát kérdezi le az Eclipse, mivel az eredeti avr-gcc-nél nincs mód a gcc által támogatott MCU-k lekérdezésére. Ezt (is) megoldja az atmel egy új opcióval csak az meg visszafelé nem kompatibilis, de azzá tettem.

Koszi a kimerito valaszt, igy mar vilagos minden. A .zip-et eltettem... :)

Az eclipsevel kapcsolatban csak halvany emlekeim voltak, ill. annyi, hogy utana "jo nagy csend" lett rola. De ezekszerint akkor ez egy "mezei" plugin formajaban "manifesztalodott"? Mondjuk az IDE nem annyira letszukseglet, egyedul az integralt debug tudna jo lenni szamomra, de az is csak neha. Mindenesetre a linket megjegyeztem!