pld embedded - port pld dla arm9

[Radosław Kintzi]

Pawel Sikora napisał(a):

>On Monday 08 of August 2005 11:40, Radosław Kintzi wrote:
>
>  
>
>>Wydaje mi się, że najlepszym rozwiazaniem byłoby stworzenie miniportu
>>PLD dla ARMa. Coś takiego jak [5]. Oto oprogramowanie jakie potrzebuję
>>(chciałbym w tym widzieć):
>>(...)
>> - gcc-3.3.5
>>    
>>
>
>seria 3.3.x sie nie nadaje dla ARM-a, bo ma skoszona obsluge
>__attribute__ ((interrupt ("IRQ/FIQ/etc."))) i jeszcze kilki
>innych rzeczy. jesli chcesz uzywac gcc na armie, to w wersji
>min. 3.4.latest. generalnie polecam doglebna lekture
>http://www.inf.u-szeged.hu/gcc-arm/index.php
>  
>
Dziwne bo buildroot (http://buildroot.uclibc.org/) potrafi zbudować 
serię 3.3.x w raz z uClibc. Ale nie chcę się kłucić i już przerzuciłem 
sie na 3.4

>  
>
>> - newlib lub uClibc (nie wiem czy to pierwsze się nadaje)
>>    
>>
>
>to pierwsze sie nadaje, ale jest dosyc duze jak na systemy
>micro-embbeded (z 32/64kB ram-u). dla takowych najlepsze jest
>chyba dietlibc+wlasna implementacja (badz zaslepienie) syscall-i linuxa.
>jesli zas masz juz te kilka MB zewnetrznej pamieci ram podpietej
>do arm-a + flash dysk, to spokojnie uzywaj newliba.
>  
>
Czy zatem taka kombinacja: crossarm-gcc.spec + crossarm-newlib.spec daje 
możliwość zbudowania wxWidget i zależności + kernel, a potem 
wygenerowania sobie jakiegoś rootfsa z linuksem? Próbowałem się tym 
posługiwać ale brakowało crt0.o (a może crt1.o) przy łączeniu.

>  
>
>>Mam teraz kilka pytań na temat cross-kompilacji i towrzenia portów
>>embedded (zaznaczam, że moje doswiadczenie w tym temacie jest raczej
>>żadne, a wiedza to kilka dni googlowania):
>>
>>1. Jak wygląda proces tworzenia cross-kompilatora?
>>    
>>
>
>crossarm-gcc.spec jest do wgladu. aktualnie wspiera tyko c/c++,
>albo mozna spokojnie wlaczyc jave i wykorzystac sprzetowy
>akcelerator jazelle.
>  
>
Widzę, że to jest budowane z nagłówkami uClibc. Czy to jest bootstrapowy 
kompilator, czy może już finalna wersja nadająca się do generowania kodu 
dla linuksa opartego o uClibc. Może niesłusznie zakładam, że jednak 
bootstrapowy, bo nigdzie w systemie nie mam zainstalwanej uClibc. Może 
nie musze mieć? Może wystarczy przekompilować nim uClibc.spec? Jak (są 
jakieś przełączniki dla rpmbuild, czy potrzeba przygotować nowego speca)?

Może nie potrzebnie ale przygotowałem swoje spece: arm-gcc.spec i 
arm-uClibc.spec. Przy ich pisaniu bazowałem na crossarm-gcc.spec, 
uClibc.spec, wiedzy wyciągniętej z googla oraz na 
http://buildroot.uClibc.org/ (skąd między innymi wziąłem patche na gcc). 
Oba spece załączam licząc na krytyczne uwagi i podopowiedzi.

Jak dotąd nie działają poprawnie. Bootstrapowy kompilator się buduje i 
raczej można z nim pracować - da się nim przekompilować arm-uClibc.spec. 
Ten niestety generuje takie kwiatki:

Package:        arm-uClibc-devel-0.9.27-1.1
Content:
/usr/arm-linux-uclibc/usr/bin:  addr2line -> /usr/bin/addr2line,
    ar -> /usr/bin/ar, as -> /usr/bin/as,
    c++ -> //bin/arm-linux-uclibc-uclibc-gcc,
    cc -> //bin/arm-linux-uclibc-uclibc-gcc, cpp -> /usr/bin/cpp,
    g++ -> //bin/arm-linux-uclibc-uclibc-gcc,
    gcc -> //bin/arm-linux-uclibc-uclibc-gcc,
    ld -> //bin/arm-linux-uclibc-uclibc-ld, nm -> /usr/bin/nm,
    objcopy -> /usr/bin/objcopy, objdump -> /usr/bin/objdump,
    ranlib -> /usr/bin/ranlib, size -> /usr/bin/size,
    strings -> /usr/bin/strings, strip -> /usr/bin/strip

Czyli odnośniki do nieistniejących plików (nie dość że mają złe ścieżki, 
to jeszcze błędne nazwy - może problem w tym, że bootstrapowy kompilator 
budowany jest  z tagetem=arm-linux-uclibc, zamiast arm-linux ?? - wydaje 
się jednak, że buildroot robi to dokładnie tak samo). Przy okazji - co 
to za kompilatory które budują się razem z uClibc?

Co do kompilatora finalnego, to budowanie się wykłada przy konfiguracji 
g++ (pełny log dostępny na zamówienie):
(...)
checking for float.h... (cached) yes
checking for stdint.h... (cached) yes
checking for main in -lm... configure: error: Link tests are not allowed 
after GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] Error 1
błąd: Błędny status wyjścia z /var/tmp/rpm-tmp.85910 (%build)

W config.log znalazłem taki błąd:

configure:2356:  
/home/users/radek/rpm/BUILD/gcc-3.4.3/obj-arm-linux-uclibc/gcc/
xgcc -B/home/users/radek/rpm/BUILD/gcc-3.4.3/obj-arm-linux-uclibc/gcc/ 
-B/usr/ar
m-linux-uclibc/bin/ -B/usr/arm-linux-uclibc/lib/ -isystem 
/usr/arm-linux-uclibc/
include -isystem /usr/arm-linux-uclibc/sys-include -o conftest -g -Os -g 
-Os  co
nftest.c  >&5
/usr/arm-linux-uclibc/bin/ld: crt1.o: No such file: No such file or 
directory
collect2: ld returned 1 exit status

Problem w tym, że crt1.o leżą nie w -B/usr/arm-linux-uclibc/lib/ tylko:

Package:        arm-uClibc-devel-0.9.27-1.1
Content:
(...)
/usr/arm-linux-uclibc/usr/lib:  crt0.o, crt1.o, crti.o, crtn.o,
    libc.so -> ../../lib/libc.so.0, libcrypt.so -> ../../lib/libcrypt.so.0,
    libdl.so -> ../../lib/libdl.so.0, libm.so -> ../../lib/libm.so.0,
    libnsl.so -> ../../lib/libnsl.so.0,
    libpthread-uclibc.so -> ../../lib/libpthread-uclibc.so.0,
    libresolv.so -> ../../lib/libresolv.so.0,
    librt.so -> ../../lib/librt.so.0,
    libthread_db.so -> ../../lib/libthread_db.so.1,
    libutil.so -> ../../lib/libutil.so.0

Teraz sobie uzymysłowiłem, że błąd jest też w -isystem/sys-include - 
takiego katalogu nie ma. Zrobiłem taki link do 
/usr/arm-linux-uclibc/usr/include, ale to oczywiście to brzydki i - jak 
widać - mało skuteczny workaround, który tylko odroczył to co 
nieuniknione - poprawne skonfigurowanie gcc. Czy ktoś wie jak to zrobić? 
A może problem leży jednak nie w gcc, tylko w arm-uClibc.spec? Gdzie 
powinny leżeć te pliki?

Buildroot wkłada je do .../staging_dir/lib, gdzie .../staging_dir to 
odpowiednik mojego /usr/arm-linux-uclibc? Jakby kotś chciał rzucić okiem 
to mogę przygotować wyciąg z Mejkfailów buildroota oraz z logów 
budowania (ew. udostępnić te ostatnie w całości).

Pozdr,
Radosław Kintzi