Hallo zusammen!
Ich habe hier das ICnova ADB1000 als OEMplus Variante, also mit viel
FLASH und den 1/4VGA Display inclusive Touch.
Ausgepackt, eingeschaltet: Bootet brav sein Linux und nach einstecken
einer USB-Tastatur kann ich mich auch gleich einloggen.
Soweit so gut. Die Buildroot Umgebung ist auch schnell unter Ubuntu aufs
Notebook kopiert und ein einfaches make produziert etwas, was wie ein
neues Image aussieht, aber testen werde ich das erst morgen.
Leider geht ein make menuconfig nicht, weil es mit
package/x11r7/Config.10:15: can't open file
"package/x11r7/xserver_xorg-server/COnfig.in"
abbricht. Nagut, habe da schon einige Links gesehen, die sich zwar auf
den Grasshopper beziehen, aber das schau ich mir dann mal an.
Aber eigentlich bin ich von dem ganzen etwas enttäuscht. Ich dachte,
dass etwas mehr Grafik dabei wäre, nicht nur ein kleiner Pinguin, der
einem 1/3 des Displays klaut. Auch ein wenig 'Touch' wäre schick
gewesen. Aber es ist außer einem Kernel und einer Busybox ( die mit den
mit Abstand wenigsten Befehlen, die ich je gesehen habe!) nix dabei und
auch im Netz nur wenig zu finden. Oder schaue ich an den falschen
Stellen?
Nein, mir soll keiner meine Arbeit abnehmen, aber etwas mehr
Grundausstattung in der Software hätte ich mir schon gewünscht. Gerade
wo ATMEL doch auch mit der Sound/Video-Fähigkeit dieser CPU so wirbt.
Gibts nicht irgendwas, das man sich zum Ansehen oder als Startpunkt für
eigene Entwicklungen schon mal runter laden und ausprobieren kann? Ich
wollte schon mal eine kleine grafische Anwendung schreiben, aber muss
ich dafür erst QT Gnome KDE portieren?
Auch ein kleines von einer SD Karte laufendes Video wäre so zum ansehen
oder Vorführen schon mal eindrucksvoll...
Oder bin ich 'der Eine', der das Board gekauft hat?
Gruß, Ulrich
ans Inet anschließen, mit wget <URL des Videos> Video laden und mit
mplayer <Videofilename> abspielen. Vorausgesetzt mplayer ist im build
vorhanden und der framebuffer aktiviert. Bilder kannst du dir mit
fbv(iewer) anschauen, wenn im build vorhanden.
Sound? Keine Ahnung ob das ADB1000 einen Videocodec drauf hat oder die
DA-Wandler Ausgänge des AP7000 herausgeführt hat, aber auch da brauchst
du dann erst mal Hardware um die zu nutzen.
Touch? Du kannst dir unter QT eine Anwendung schreiben, oder die Demos
verwenden, die den Touch unterstützen, dazu muss natürlich auch QT im
build eingebunden sein.
Die busybox kannst du im buildroot mit make busybox-menuconfig
einstellen.
Der Rest ist auch nicht vorhanden und ein make menuconfig funktioniert
wg. oben angeführtem Problem auch noch nicht.
Alles etwas mager für 300€. Ich schau mich mal um. Hat schon jemand mit
der T2 Distribution Erfahrung gemacht? Da soll wenigstens im Kernel
alles Multimediale bereits vorhanden sein.
Siehe http://www.t2-project.org/
Ein AC97 Codec wird unterstützt, ist aber nicht auf dem Board, was
irgendwie etwas zusammenhangslos ist. Aber ich habe einen passenden auf
einem anderen Dev-Kit und kann das sicherlich zusammen fädeln.
Video-Beschelunigung hat der AP7 Prozessor von ATMEL in der Hardware,
daher sollte Video gehen.
Gruß, Ulrich
>Die Buildroot Umgebung ist auch schnell unter Ubuntu
Hallo Ulrich,
kannst Du mir sagen welche? Ich habe ein gepacktes File runtergeladen,
in dem sich ungefähr 10 *.dep befinden. Muss man die alle einzeln
installieren?
Auf der Atmel Seite gibt's ja das Image einer DVD mit Entwicklungstools:
>AVR32 Linux BSP 3.0.0 DVD Image (809 MB, updated 1/09)>The AVR32 Linux Board Support Package (BSP) 3.0.0 supports AVR32 Linux >development for all AP7 development boards. This currently includes >ATSTK1000,
ATSTK1002, ATSTK1003, ATSTK1004, ATSTK1005, ATSK1006 and >ATNGW100.
Ist das ein Live-System, also ohne Installation? Hat jemand Erfahrung
damit?
Hi!
Ich habe das Kit bestellt und da war eine CD dabei. Einfach das ICnova
Verzeichnis kopiert und make menuconfig laufen lassen wollen. Das ging
nicht wg. o.g. Fehler. Aber ein make hat dann wenigstens mal die ganze
Umgebung erstellt und auch einen Kernel gebaut. Wie gesagt, ob der geht,
werde ich heute Abend ausprobieren.
Ein Livesystem ist das nicht.
Ich habe das ICnova System genommen, weil es augenscheinlich keinen
Boardsupport für das ICnove Board darin gibt.
Leider liefert ICnova auf der Downloadseite nur ein CD-Image, ich habe
noch nicht nachgesehen, ob das Image aktueller ist, als die
mitgelieferte CD, deren Buildroot aus 03/2009 ist.
Ein Ubuntu 8.04 habe ich nicht und will ich eigentlich auch nicht. Klar
kann ich das auch noch irgendwo installieren... Aber muss das sein?
Leider ist es in der Linux-Welt üblich, dass die, die sich mit dem
Frontend beschäftigen, also die Tools nutzen wollen, häufig nur 'geht
nicht' melden, und die Insider, die die Tools dann fixen nur ellenlange
Patches mit 'jetzt gehts' verbreiten. Die einzige Möglichkeit, zu
verstehen, was unterwegs passiert, ist sich in die diversen Quellcodes
der Tools einzuarbeiten bevor man diese nutzen kann um seine eigentliche
Aufgabe zu erledigen. Das ist vermutlich der Grund warum es Windows CE
überhaupt noch gibt.
Gruß, Ulrich
>Leider ist es in der Linux-Welt üblich, dass die, die sich mit dem>Frontend beschäftigen, also die Tools nutzen wollen, häufig nur 'geht>nicht' melden, und die Insider, die die Tools dann fixen nur ellenlange>Patches mit 'jetzt gehts' verbreiten.
Na schade. Bei einem Live-System wäre der Vorteil, dass man gar nichts
zu installieren braucht und einfach alles schon im System vorhanden ist.
Der Nachteil: man müsste jedes mal die DVD booten.
Eine Möglichkeit ist, Ubuntu unter VM laufen zu lassen. Ubuntu 8.04
deshalb, weil darauf alles von Atmel im Buildroot abgestimmt ist. Mit
höheren Versionen wirst du keine Freude haben.
> Hat schon jemand mit der T2 Distribution Erfahrung gemacht?
Die unterstützt das ATNGW100, das kannst du nicht direkt auf die
OEMplus-Variante übertragen. Stichwort andere Speichergröße, andere
Speicherbereiche. Fängt schon bei Uboot an.
Ok, das mit dem LiveImage war ein Missverständnis. Natürlich könnte ich
mir ein LiveImage auf meinem PC oder Notebook starten :) Ich dachte, ein
LiveImage für das ICnova Board. Wäre eine aufwändigere Fädelarbeit da
ein DVD Laufwerk dran zu bekommen, aber es hat ja auch USB Host.
Ich verstehe aber nicht, warum das Buildroot mir ein saubere Image baut
mit make, aber das make menuconfig streikt und warum das mit der Version
des Ubuntu zusammen hängt. Das ist es ja, was ich meine, mir fehlt da
der Zusammenhang und der wird leider bei diversen Patches, die dann
alles wie von Zauberhand reparieren auch nicht ordentlich erklärt.
Uboot anzupassen ist kein Thema, Flash, SDRAM und I/Os im Kernel korrekt
implementieren oder einen Treiber für den AC97 Codec anpassen ist auch
kein Problem. Low-Level Programmierung ist meine Welt. Aber bevor ich
mich an diese Arbeit machen kann, muss ich mich nun mit
Installationsorgien und Toolchain-Analyse herumschlagen...
Nein, ich will kein CE installieren und ich werde mich da wohl
durchbeißen. Aber es ist nun mal so, dass das, was hier mit Spielerei
anfänt einen gewissen Hintergrund hat. Ich möchte diese CPU gerne in
einem kommerziellen Projekt einsetzen, aber habe dabei momentan
Gegenwind aus dem Management. Also möchte ich ganz schnell die
Leistungsfähigkeit des Systems unter Beweis stellen, bevor jemand irgend
etwas beauftragt, was wir dann hinterher pflegen müssen, obwohl wir es
nicht gewollt haben.
Wenn ich nun Wochen mit Tools verbringe, dann ist das ganze gelaufen.
Schade drum. Kann das Ding also getrost mit nach Hause nehmen und zum
Spielen verwenden, denn bis dann wieder ein Nachfolger gesucht wird, ist
der AP7000 auch wieder Geschichte.
Also nun packt doch mal aus: Was kann man mit dem AP7000 Out Of The Box
schon mal anfangen? Hat denn niemand ein Image herumliegen, dass auf dem
ADB1000 ein wenig Touch-Oberfläche hervorbringt und ein paar Photos
anzeigt? Oder eine Linksammlung?
Nee, Buildroot kenne ich zur genüge, da habe ich schon mal drei Monate
mit verbracht eine AT91RM9000 ans Laufen zu bekommen mit Kernel
2.6.16... Gruselig! Kernel läuft, Busybox startet bis heute nicht.
Hat jemand Erfahrung mit dem o.g. T2 Projekt?
Weiß jemand, wann avr32linux.org wieder an den Start geht? Dort soll
nach meiner Recherche alles vorhanden sein, was ich suche...
Gruß, Ulrich
So, hab mal ein bisschen herum probiert.
In dem mitgelieferten Buildroot gibt es im x11r7 einige Bezüge auf
darunter liegende Verzeichnisse und deren Config.in, die einfach nicht
existieren. Habe also zum Teil einfach die Verzeichnisse und leere
Config.in Dateien erstellt. Andere habe ich in der Bezug nehmenden
Config.in einfach auskommentiert.
make menuconfig schmeißt nun einige Fehlermeldungen aus, startet aber
und bastelt nach einigen Probeänderungen auch ein Kernel und ein rootfs.
Die in dem Datenblatt angegeben UBoot Änderungen um von NFS zu booten
sind unverständlich, unvollständig und unkomfortabel. Also habe ich mal
die Dinge von der AT91RM9200 und einigen Threads hier über den AP7000
zusammen gesammelt und was auf die Beine gestellt.
Auch das NFS ist immer wieder ein Spaß:
Buildroot baut unter /home/ulrich/ICnova/binaries/oemplus/ die Dateien
zusammen, als uImage und das rootfs.ext2.
Also loope ich das rootfs mit mount -o loop rootfs.ext2
~/ICnova/binaries/rootfs und exportiere den Pfad ~/ICnova/binaries.
Denkste!
Das Verzeichnis serverip:/home/ulrich/ICnova/binaries/rootfs bleibt
leer!
Es hilft nur zwei separate NFS exports zu definieren und schon ist der
Inhalt des rootfs auch da.
Nun bin ich schon mal da, wo andere auch schon gelandet sind:
Der Kernel wird fast vollständig via NFS geladen, bricht dann aber mit
einem Fehler ab:
1
File transfer via NFS from server 192.168.10.106; our IP address is 192.168.10.80
## Booting kernel from Legacy Image at 10400000 ...
10
Image Name: Linux-2.6.28.4
11
Image Type: AVR32 Linux Kernel Image (gzip compressed)
12
Data Size: 1458946 Bytes = 1.4 MB
Hatte dazu schon was gefunden, aber zu viele Tabs auf :)
Der installierte Kernel sollte mit meinen UBoot Parametern auch schon
vom NFS booten, also schau mer mal....
1
usbcore: registered new interface driver usbhid
2
usbhid: v2.6:USB HID core driver
3
TCP cubic registered
4
NET: Registered protocol family 10
5
IPv6 over IPv4 tunneling driver
6
port 1 high speed
7
NET: Registered protocol family 17
8
RPC: Registered udp transport module.
9
RPC: Registered tcp transport module.
10
cpufreq: AT32AP CPU frequency driver
11
usb 1-1: new high speed USB device using isp176x and address 2
Sending DHCP requests .<6>eth0: link up (100/Full)
18
..<7>eth0: no IPv6 routers present
19
... timed out!
20
IP-Config: Retrying forever (NFS root)...
21
ADDRCONF(NETDEV_UP): eth0: link is not ready
22
Sending DHCP requests ...... timed out!
23
IP-Config: Retrying forever (NFS root)...
24
ADDRCONF(NETDEV_UP): eth0: link is not ready
25
Sending DHCP requests ...... timed out!
26
IP-Config: Retrying forever (NFS root)...
27
eth0: link down
28
ADDRCONF(NETDEV_UP): eth0: link is not ready
29
Sending DHCP requests ...... timed out!
Hmmm... IPV6... Wat soll'n dat??
Naja, ich experimentier mal weiter... Über Anregungen freue ich mich
sehr.
Vielleicht wirds ein gemischt Thread mit Anleitung, Hilfe und den
üblichen Motzereien :)
Und das Buildroot macht wohl erst auf einem 16-Kern Rechner spaß.... Zum
Glück gibt es noch eine ungelesene c't und das Fernsehen :)
Gruß, Ulrich
Sorry, aber ich kann den vorherigen Beitrag nicht mehr editieren, daher:
Wer sich mit buildroot versucht, sollte unter allen Umständen
verhindern, dass er ein make als root oder super-user durchführt. Das
händische auseinander pflücken der Dateien und Verzeichnisse, die
nachher Berechtigungsprobleme haben ist.... naja, neu installieren ist
einfacher :)
Gruß, Ulrich
Wegen des angeblich fehlenden x11r7 kleiner Tipp: schau mal auf deiner
CD-ROM nach ob die o.g. Datei tatsächlich nicht existiert, ich vermute
du hast nicht alle Daten sauber kopiert !?
Ansonsten wunder ich mich gerade über deine Erwartungen, ich weiß nicht
warum die so gesteckt sind - das ist ein Developer(!) Board und dafür
wird doch alles notwendige geliefert und die Anwendungsmöglichkeiten
sind sehr vielfältig.
Wenn ich so schaue was sonst solche Dev-Boards kosten können... ist es
bei dem Umfang eher preiswert !
Ich bin jedenfalls auch erst seit kurzem neuer Besitzer dieses Kits und
meine Erwartungen sind voll erfüllt. Na ja, dass der vorinstallierte
Kernel weges eines Bugs kein NFS kann(siehe anderer Thread), ist ein
bisschen unglücklich aber mit der gelieferten Buildroot Umgebung läßt
sich das alles beben. Kernel & rootfs per Bootloader starten ging bei
mir ziemlich schnell(abgesehen von anfänglichen Tippfehlern).
2. Tipp: Statt avr32linux.org versuch mal test.avr32linux.org da zZ wg.
eines Hackers offline.
Viel Erfolg noch !
Ulrich P. schrieb:
> Sorry, aber ich kann den vorherigen Beitrag nicht mehr editieren, daher:>> Wer sich mit buildroot versucht, sollte unter allen Umständen> verhindern, dass er ein make als root oder super-user durchführt.
Na, das ist doch ein allg. Linux Grundsatz ;-)
Jens K. schrieb:
> Wegen des angeblich fehlenden x11r7 kleiner Tipp: schau mal auf deiner> CD-ROM nach ob die o.g. Datei tatsächlich nicht existiert, ich vermute> du hast nicht alle Daten sauber kopiert !?>
Ich habe das ganze einmal per cp und einmal per Dolphin gemacht. Aber
jetzt wo Du es sagst, habe ich nachgeschaut. Und es sind wirklich nicht
alle Unterverzeichnisse mit kopiert worden. Warum denn das?
> Ansonsten wunder ich mich gerade über deine Erwartungen, ich weiß nicht> warum die so gesteckt sind - das ist ein Developer(!) Board und dafür> wird doch alles notwendige geliefert und die Anwendungsmöglichkeiten> sind sehr vielfältig.
Ja/Jein. Wenn ich was raus bringe, dass bestimmte Erwartungen weckt,
dann muss ich das doch wenigstens ansatzweise auch zeigen, dass ich das
kann. Das Kit kommt mit einem farbigen LCD mit Touch und es ist nicht
mal mplayer oder ein mini-QT oder etwas ähnliches mit eincompiliert. Der
Kernel startet wie auf meiner uralt AT91RM9200 im Terminalfenster. Dabei
bewerben alle diesen Chip wegen seiner geringen Stromaufnahem und
geringen Frequenz und seiner Fähigkeit trotzdem Audio / Video decodieren
und darstellen zu können.
> Wenn ich so schaue was sonst solche Dev-Boards kosten können... ist es> bei dem Umfang eher preiswert !
Jein, der Kernel ist ja angeblich schon in voller Ausstattung da und
alles wird unterstützt und Buildroot und T2 und so weiter können den
Prozessor voll unterstützen. Das ganze muss man sich aber leider erst
zusammen bauen, und dazu muss man erst mal rausfinden, wie man die
configs von ATMEL mit den Patches von ICnova und Buildroot zusammen
unter einen Hut bekommt.
Das ist etwa so, als wenn ich mir bei Ikea einen Schrank kaufe und die
mir dazu einen Akkuschrauber liefern, der einem in Einzelteilen aus
aller Welt Stück für Stück ohne Bauanleitung zugeschickt wird.
Ja ich kann einen Ikea-Schrank auch mit einem normalen Schraubendreher
zusammen bauen und das ohne Anleitung, das wäre also so, als würde ich
jetzt einfach Nut/OS auf den AP7 portieren. Kein Problem.
>> Ich bin jedenfalls auch erst seit kurzem neuer Besitzer dieses Kits und> meine Erwartungen sind voll erfüllt. Na ja, dass der vorinstallierte> Kernel weges eines Bugs kein NFS kann(siehe anderer Thread), ist ein> bisschen unglücklich aber mit der gelieferten Buildroot Umgebung läßt> sich das alles beben. Kernel & rootfs per Bootloader starten ging bei> mir ziemlich schnell(abgesehen von anfänglichen Tippfehlern).
Jaja, da isses wieder.... Sie können Probleme lösen und sagen, dass sie
sie gelöst haben. Aber erklären was, wie und wo und warum....
Was hat denn der Kernel, weswegen er kein NFS kann? Was sollte ich denn
da im config machen, damit das NFS funktioniert? Oder kann er es einfach
nur nicht, weil vergessen wurde den NFS Support zu aktivieren?
>> 2. Tipp: Statt avr32linux.org versuch mal test.avr32linux.org da zZ wg.> eines Hackers offline.>
Der Tip war allerdings Gold wert, danke! Ich hatte schon Links auf
diesen Server gesehen, die führten aber alle ins Leere.
Ich baue gerade parallel ein ICnova Buildroot und einen original
buildroot. Mal sehen, welcher der Beiden läuft. Die fehlenden Dateien
werde ich dann erst hinterher kopieren, wennn der ICnova Buildroot
fertig ist, was auf einem Celeron Notebook etwas dauern kann...
Die test.avr32linux.org hat leider immer wieder timeouts... Ich geh
jetzt ins Bett :)
Gruß, Ulrich
Sorry, ist schon spät, Du schriebst ja, dass es in einem anderen Thread
schon um das NFS Problem ging. Ich schau da mal nach. Danke aber schon
mal für den Tip.
Bei mir startet der neue Kernel noch nicht via NF, wie die Übertragung
kurz vo Ende abbricht und der bereits geflashte Kernel startet IPV6,
IPV4 erst, wenn man das Netzwerkkabel zieht und wieder steckt und dann
habe ich vermutlich genau Dein angesprochenes NFS Problem.
Gute Nacht!
Gruß, Ulrich
Ok, es geht weiter :)
Zunächst mal eine kleine Entschuldigung an ICnova, wenn man das
Kleingedruckte liest, funktioniert der Buildroot auch perfekt.
Es ist unglaublich, dass der Dolphin einfach Dateien beim Kopieren weg
lässt!
mit einem
cp -a /media/cdrom/ICnova .
werden alle Dateien kopiert und ein make menuconfig funktioniert
perfekt.
Um den eigenen Kernel auch zu erkennen, habe ich in make menuconfig
lediglich zwei Dinge geändert:
Target Options -> hostname gesetzt von icnova auf ADB1000
Target Options -> banner gesetzt auf Welcome to Astralix AP7000
exit, make, warten...
Nun zum UBoot:
Der vorhandene UBoot will bei mir nicht via NFS den Kernel laden. Die
Übertragung bricht irgendwann nach etlichen erfolgreichen Blöcken ab.
Egal, nehmen wir tftp:
Nach der Anleitung von
http://www.davidsudjiman.info/2006/03/27/installing-and-setting-tftpd-in-ubuntu/
habe ich schnell den tftpd installiert und folgende Änderungen im UBoot
gemacht:
Da ich die originalen Einstellungen behalten wollte und der UBoot mit
langen Befehlszeilen Probleme haben soll, habe ich das ganze etwas
komfortabler gestaltet:
Zunächst sichern wir den bootcmd:
setenv bootcmdold $(bootcmd)
Wichtig hierbei ist, dass keine Hochkomma angegeben werden, dann löst
die Kommandozeile die tokens $() auf.
Dann definieren wir das ganze IP Zeug:
setenv ipaddr 192.168.10.80
setenv serverip 192.168.10.106
dann bauen wir den tftp boot zusammen:
setenv tftpboot 'tftpboot $(serverip):$(bootfile);bootm'
Hier sind die '...' wichtig, denn sonst würde das UBoot den bootm Befehl
gleich nach der Eingabe ausführen und es würde die Platzhalter auflösen.
Ändert sich eine IP, so müsste man alle env Variablen mit dieser ip
abändern müssen. So muss nur serverip oder ipaddr geändert werden.
Anstelle von bootcmdold wäre ein bootflash angebracht. Möchte man wieder
vom Flash booten, muss man nur den bootcmd per setenv bootcmd 'run
bootlfash' abändern. Oder man kann das ganze auch wahlfrei auf der UBoot
Konsole von Hand eingeben.
Nachdem die für das tftp notwendigen Daten gesetzt sind, alles per
saveenv sichern.
Wenn buildroot fertig ist, kopiert man den Kernel
cp ICnova/binaries/oemplus/uImage /srv/tftp
oder wo immer man sein tftp Verzeichnis hin gelegt hat.
Nun kann man per run tftpboot den neuen Kernel starten und sehen was
passiert:
Wie man hier sehen kann:
Linux version 2.6.28.4 (uprinz@delli)
ist es der Kernel, der auf dem eigenen Rechner erzeugt wurde.
Leider sehen wir die Änderungen des hostname und des Banners erst, wenn
auch das neue rootfs eingebunden wurde und das funktioniert bei mir noch
nicht über NFS...
1
Sending DHCP requests .<6>eth0: link up (100/Full)
2
..<7>eth0: no IPv6 routers present
3
... timed out!
4
IP-Config: Retrying forever (NFS root)...
5
eth0: link down
6
ADDRCONF(NETDEV_UP): eth0: link is not ready
7
Sending DHCP requests ...... timed out!
Hier startet jemand IPv6 statt IPv4...
Die Jagd geht weiter :)
Gruß, Ulrich
Hmmm... Ja, da war es wieder, was mir nicht einfallen wollte.
Trotzdem sollte der Kernel das mit den richtigen Parametern auch so tun,
denn er bootet ja auch im Original mit IPv4 hoch....
Aber schu mer mal...
Leider sind die verschiedenen Beschreibung sich nicht ganz einig, wie
man die kernel-parameter übergeben muss:
denn die kann nur das UBoot auseinandernehmen. Dem Kernel stehen die
nicht zur Verfügung!
Ich würde jetzt das jetzt noch gerne etwas automatisieren, aber das
kommt dann später. Jetzt funktioniert es jedenfalls schon sehr viel
besser:
1
usb 1-1.1: configuration #1 chosen from 1 choice
2
input: USB Keyboard as /class/input/input1
3
generic-usb 0003:1241:1503.0001: input: USB HID v1.10 Keyboard [ USB Keyboard] on usb-isp176x.0-1.1/input0
4
input: USB Keyboard as /class/input/input2
5
generic-usb 0003:1241:1503.0002: input: USB HID v1.10 Device [ USB Keyboard] on usb-isp176x.0-1.1/input1
VFS: Mounted root (nfs filesystem) on device 0:12.
14
Freeing init memory: 80K (90000000 - 90014000)
15
Populating /dev using udev: done
16
Starting portmap: done
17
Initializing random number generator... done.
18
Starting Network Interface Plugging Daemon: eth0.
19
Starting network time protocol daemon: ntpd.
20
Starting httpd
21
22
nfs: server 192.168.10.106 not responding, still trying
23
nfs: server 192.168.10.106 not responding, still trying
24
nfs: server 192.168.10.106 not responding, still trying
Naja, ich habe schon ein wenig im Kernel und so herum gebastelt, kein
Wunder, dass es nicht komplett durch läuft....
Irgendwann geht im der NFS dann wohl verloren...
Ich fand den ifplugd irgendwie interessant, vermutlich schlägt der mir
in die bestehende NFS Verbindung, wenn er das interface neu
konfiguriert...
Gruß, Ulrich
Ok, habe in etc/init.d/*s40ifplugd einfach mal ein exit 0 oben rein
geschrieben und siehe da: Es funktioniert!
Die im Datenblatt verheimlichten Grafik-Demos habe ich auch gefunden,
wer das Kit hat, sollte mal nach /usr/bin/avr32-linux-* sehen, da ist
einiges dabei.
Nun möchte ich auch mal den mplayer sehen, aber leider bekomme ich weder
eine SD-Card noch einen USB-Stick gemountet.
# cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: Model: Rev: 0.00
Type: Direct-Access ANSI SCSI revision: 02
# mount /dev/sda1 /tmp/usb
mount: mounting /dev/sda1 on /tmp/usb failed: Invalid argument
# mount -t fat32 /dev/sda1 /tmp/usb
mount: mounting /dev/sda1 on /tmp/usb failed: No such device
# mount -tfat32 /dev/sda1 /tmp/usb
mount: mounting /dev/sda1 on /tmp/usb failed: No such device
# mount /dev/sda1 /tmp/usb
mount: mounting /dev/sda1 on /tmp/usb failed: Invalid argument
Da klemmt doch schon wieder was :)
Macht nix, werde es schon hin bekommen. Jens und Gast hatten schon
recht. Eine Nacht und ein halber Tag mit vielen Unterbrechungen und die
Liste der Arbeiten ist schon sehr kurz geworden:
Kernel / rootfs bauen geht
TFTP/NFS laufen
Grafik-Applikation von ICnova gefunden und gehen
Da kann ich mich ja bald auf das konzentrieren, was ich kann: Treiber
schreiben :)
Hat jemand noch einen Tip bzgl. USB / SD Card?
Ich halte das hier mal am Laufen und bei Interesse für die anderen
Kit-Besitzer kann ich dann später auch einen Artikel draus machen.
Gruß, Ulrich
Ok, nehmen wir einfac -t vfat statt fat und schon geht es. Als ich mit
Linux angefangen habe, gab es noch fat und fat32 separat... Hätte mir
auch einfallen können.
Also: Video per mplayer läuft auch, leider ohne Ton, denn den AC97Codec
habe ich noch nicht dran gefriemelt.
Gruß, Ulrich
Nach anfänglichen Enttäuschungen aufgrund mangelnder Beschreibung,
gehackter Server und sicherlich auch etwas Unwissenheit und weil es
eigentlich gestern viel zu spät für so ein Projekt war, muss ich jetzt
den Thread-Titel mal ändern.
Gruß, Ulrich
wenn du dir git im Ubuntu installierst kann du dir das aktuellste
buildroot mit letztem Kernel auch hier runterladen.
git clone git://git.buildroot.net/buildroot
etwas die Speichergrößen und Speicherbereiche vom atngw100-board
anpassen und die setup.c patchen.
Bei meinem GH funktioniert das.
Ja, den git habe ich drauf und auch schon einen entsprechenden
buildroot. Aber die Version von der CD hat etliche patches und ich
wollte da erst mal nach und nach durch steigen.
Auf meinem SAM7X Entwickler Kit habe ich einen TI codec drauf, den ATMEL
auch für seine AT91 Internet-Radios verwendet, insofern hatte ich die
Hoffnung, dass der bereits unterstützt wird. Wenn nicht, selber
schreiben.
Aber es geht mir vorerst nicht um Sound, sondern um GUI und Messwerte
und http uns RS422 und CAN.
Gruß, und danke für die Tips!
Ulrich
Hallo Ulrich P.,
hab mit das ADB1000 Starterkit gekauft, leider kann ich meine 4GB Sd
Karte nicht mounten. Kannst du mir ma sagen wie du sie mountest und wie
du sie formatiert hast?
Vielen Dank
Gruß
Uboot unterstützt in der normalen Version keine SDHC-Karten.
In diesem Thread hat aber jemand das Uboot für den Grasshopper
gepatched.
Beitrag "Grasshopper und SDHC-Karten"
Für das OEM-base oder plus -Board musst du Uboot aber zusätzlich an die
geänderten Speicherbereiche anpassen.
Psykoman schrieb:
> Hallo Ulrich P.,>> hab mit das ADB1000 Starterkit gekauft, leider kann ich meine 4GB Sd> Karte nicht mounten. Kannst du mir ma sagen wie du sie mountest und wie> du sie formatiert hast?> Vielen Dank>
Ich nehme mal an, dass Du die Karte im laufenden Linux mounten willst,
und nicht als Boot-Device für Kernel und / oder rootfs. Ich habe eine
1GB SD-Card gemountet mit
mkdir /mnt/sd
mount -t vfat /dev/mmcblk0p1 /mnt/sd
Einen 4GB USB-Stick habe ich entsprechend mit
mkdir /mnt/usb
mount -t vfat /dev/sda1 /mnt/sd
Beide Medien waren vorher schon formatiert und mit Daten bespielt. Die
Karte stammt aus meinem Handy und hat Videos im 4gp Format, der
USB-Stick Videos im MPG und MP4 Format. Der nachträglich im buildroot
aktivierte mplayer hat alles tadellos wiedergegeben.
Ich habe keine SDHC Karten, daher kann ich nicht sagen, ob der Kernel
damit ein Problem hat. Ich vermute, dass es kein Problem gibt,
vermutlich auch nicht, wenn das rootfs auf der SDHC Karte liegt.
Das UBoot muss, wie Gast schon gesagt hat, gepatcht werden.
Gruß, Ulrich
Danke Ulrich,
hab das -t vfat vergessen gehabt. Bei SDHC Karten gibt es keine Probleme
diese zu mounten, jetzt stellt sich nur das Problem, warum ich mein
eigenes C Programm nicht ausführen kann. Soll einfach nur "Hallo Welt"
auf der Konsole ausgeben, leider kommt immer " ./test: line 1: syntax
error: "(" unexpected". Jemand einen Idee warum dies nicht ausgeführt
wird?
Gruß
Hi!
Ja, genau das Problem habe ich auch. Habe das ser2net nach Anweisung
compiliert und trotzdem kommt der von Dir genannte Fehler. Also lass uns
mal suchen :)
Habe den Verdacht, dass der falsche Compiler genommen wird. Aber das von
ICnova bereitgestellte Buildroot hat die im Original genannten Pfade für
den Compiler nicht. Das liegt wohl daran, dass die Dokumentation beim
Name 'output' von einem Default ausgeht und ICnova dort etwas verwendet,
das dem Target entspricht:
Ich habe nun schon einige Monate nichts mehr mit buildroot versucht,
waren ein paar schwierige Projekte in der Zwischenzeit, da fällt auch im
Hirn schon mal einiges hinten über :)
Also folgendes machen:
Ins Buildroot-Verzeichnis wechseln und dann:
1
$>find . -name avr32-linux-gcc
2
./build_avr32/staging_dir/usr/bin/avr32-linux-gcc
Also haben wir den schon mal...
1
mkdir test
2
cd test
3
touch hello.c
Mit einem Editor Deiner Wahl hello.c mit etwas Code befüllen:
Die zweite Zeile funktioniert natürlich nur, wenn man das rootfs image
via loop device gemountet hat. Ich fand es sehr praktisch, das rootfs
via NFS and den AP7000 zu verbinden. Damit kann ich vom Entwicklungs PC
und vom ADB1000 darauf zugreifen. Aber DU kannst die hello Datei auch
auf einen USB-Stick oder eine SD-Card kopieren und dann ausführen.
1
#>hello
2
Hello World!
3
#>
Fein! Nun habe ich mal, ganz nach Docu des buildroot, den
avr32-linux-gcc in den Pfad mit aufgenommen:
Nun bin ich mal in mein ser2net Verzeichnis gewechselt und habe das neu
kompiliert:
1
$>cd ~/avr32test/ser2net-2.6
2
$>make clean
3
...
4
$>./configure --host=avr32-linux
5
...
6
$>make
dann die generierte ser2net auf mein rootfs kopiert und gestartet:
Schau mer mal... Naja, der daemon läuft und er nimmt Verbindungen an,
aber ich kann nicht sehen, ob da was drüber geht, weil ich an den
anderen Schnittstellen nichts dran hängen habe, oder die ser2net.conf
noch nicht angepasst ist. Aber es geht!
Gruß, Ulrich
Und weil dieses Forum ein ständiges Geben und Nehmen ist, darf ich jetzt
noch mal was fragen :)
Ich würde gerne ein nette grafische Oberfläche gestalten. Es gibt da
scheinbar tausend Wege das zu tun. Mir gefällt QT ganz gut, weil es
gleich mit einer passenden Oberfläche und ähnlichem geliefert wird.
Allerdings bekommen ich es nicht hin, etwas darunter für den AVR32 zu
entwicklen.
Was hab ich:
QTcreator unter Windows und unter Linux
Buildroot config mit QT-Unterstützung in der Target-Package Selection.
Jetzt finden sich viele Hinweise, dass man neben dem QT für den
Entwicklungs-PC auch ein Library Paket für das Target runter laden,
dieses für den AVR32 patchen und dann compilieren muss.
Leider sind alle Links dazu noch mit Bezug auf die Trolltech Seite, aber
Nokia hat das ja alles eingesackt und ich finde die entsprechenden Links
dort nicht wieder.
Auch beziehen sich die Anleitungen in den verschiedenen Foren auf die
Versionen 2.2.x bis 2.4.x, ebenso die Patches. Nokia bietet aber schon
die Version 2.5.x
Nun bin ich etwas verloren....
Kann mir mal jemand bitte die Schritte von nach dem Runterladen des
QTcreators bis zum ersten Demo-Programm erklären? Also wie generiere ich
welche Library für den AVR32, damit dieser mal einen leeren QT-Desktop
anzeigt, oder eine Message-Box mir Hello World?
Das ist absolutes Neuland für mich, da ich eher der Low-Level Freak bin,
also Treiber und so. Ich will aber nicht immer nur im Verborgenen
existieren :)
Gruß Ulrich
Hallo Zusammen,
im Moment beschäftige ich mich gerade mit dem NGW100. Da Ihr die
Experten seit und ich Neuling auf dem Gebiet "embeded Linux" wage ich es
jetzt einfach mal in diesem Thread ein paar grundsätliche Fragen zu
stellen:
Ich konnte das NGW100 in Betrieb nehmen, mit dem Webbrowser die
vorinstallierten Seiten darauf anschauen, via telnet und ftp Kontakt zum
System aufnehmen. Nun, das ging relativ einfach, also dachte ich mir,
schön, jetzt schreibe ich mal die ersten Programme dafür.
Da fangen die Probleme an: erst einmal einen Compiler für eine AVR32
installieren. Dazu gibt es ja ein ToolChain für Ubuntu 8.04. d.h musste
ich erst mal einen meiner Rechner von Ubuntu 9.04 auf 8.04 downgraden.
So weit so gut, das "Hello World" Programm mit
avr32-gcc hello.c
kompiliert ( ein a.out entsteht ), per ftp auf das NGW100 geschoben und
dort noch mit chmod 777 a.out ausführbar gemacht.
Ergebnis der Ausgabe anstatt "hello world"
killed
Das Programm scheint nicht zu passen, warum zur Hölle nicht?
Vielleicht könnt Ihr was dazu sagen?
Hi!
Also ich verwende die Toolchain von ic-board.de sprich ICnova. Die haben
eine buildroot Version von Mitte dieses Jahres für ihr ADB1000
DeveloperKit zusammen gestellt, und die funktioniert gut.
Daher kann ich Dir bei AVR32-Studio oder selbst zusammen gestellten
Toolchains wenig helfen. Ich selber entwickle Software grundsätzlich mit
dem SourceInsight Editor. Der Läuft unter Windows oder in einer
Emulation.
Aber, bei mir funktioniert der Buildroot von ICnova einwandfrei, ich
musste, wie oben angegeben, nur noch den PATH um das Verzeichnis
erweitern, das die Toolchain enthält.
Das HelloWorld habe ich übrigens im mc geschrieben.
Compiliert habe ich es aber mit avr32-linux-gcc hello.c -o hello
das hello wurde gleich als executeable erstellt und ich musste es nur
noch übertragen und ausführen. Allerdings erzeugt ein Aufruf ohne -o
hello bei mir eine a.out, die exakt identisch mit der hello ist, das
kann es also nicht sein.
Etwas ist mir aber auch aufgefallen. Ich hatte das ser2net zuerst mit
den auf einer Seite angegebenen Optionen übersetzt, ich glaube
./configure --host=avr32-unknown
Das lief einwandfrei durch. Auch das anschließende make warf keine
besonders auffälligen Informationen aus. Es wurde auch eine ser2net
erstellt. Die funktionierte aber auf dem Target nicht.
Heute habe ich dann den richtigen Compiler gefunden und der heißt
avr32-linux-gcc und damit muss der configure Lauf eben so heißen:
./configure --host=avr32-linux
Das anschließende make erzeugte eine einwandfrei laufende ser2net für
das Target.
Ich fange mit dem AP7 Prozessor aber auch gerade erst an, daher kann ich
Dir nicht sagen, ob es dafür mehrere Toolchains gibt, die ihren compiler
auch noch unterschiedlich benennen.
Ein Problem bei Dir könnte aber auch sein, dass Du es vielleicht per FTP
überträgst. Da musst Du schon darauf achten, dass es im binary-mode
übertragen wird. Vergleiche mal die Größe der beiden Dateien.
Gruß, Ulrich
> avr32-gcc hello.c
falscher Compiler, du musst avr32-linux-gcc verwenden. Den findest du
unter //build_avr32/staging_dir/usr/bin/avr32-linux-gcc.
QT sollte, wenn man im menuconfig QT aktiviert hat, laufen.
Um den Touch zu aktivieren evtl. noch
export QWS_MOUSE_PROTO=Tslib:/dev/input/event0
eingeben.
Ok, danke für eure Antworten.
Mich wundert es, dass mit dem Compiler AVR32-gcc nichts läuft und man
statt dessen AVR32-linux-gcc verwenden muss, warum?
Mit ist aufgefallen, dass bei der Verwendung von AVR32-gcc beim
compilieren des "hello world" ein File von 140KByte entsteht. Wenn man
das mit der Größe bei einem AVR vergleicht ... Immerhin will ich ja kein
Windows System komplieren.
Aber ich vermute mal, dass mit dem AVR32-gcc kein Linux-Programm sondern
ein eigenes, ohne Betriebssystem lauffähiges Programm erzeugt wird.
Was bedeutet "build root" ganz konkret?
Ich muss hier die selbe Frage für das NGW100 wie Ulricht für sein Board
stellen: Wie bekomme ich ohne größere Installationsorgie eine Umgebung
hin, mit der Ich C-Programme für das NGW100+Linux schreiben kann?
> QT sollte, wenn man im menuconfig QT aktiviert hat, laufen.> Um den Touch zu aktivieren evtl. noch> export QWS_MOUSE_PROTO=Tslib:/dev/input/event0> eingeben.
Äh, ja, aber was, wie wo?
Ich muss ja eines der Examples aus dem QTcreator irgendwie kompilieren
und auf das Target bringen. Dort führe ich es dann aus und sehe (
hoffentlich) mein Ergebnis. Dachte ich.
Wenn ich im QTcreator etwas gebastelt habe, z.b. das Map Beispiel, dann
kann ich das ja nicht im QTcreator einfach per GO starten, sondern ich
muss es irgendwie compilieren und dann vorher auf das Target bringen,
bevor ich es starten kann.
Ich habe hier ein anderes Beispiel, das angeblich für den AVR32 gedacht
ist. Im makefile stehen aber nur Referenzen auf den normalen gcc. Auch
die Pfade sind mit /usr/share/qt3/lib u.s.w. angegeben.
Normalerweise müsste doch die avr32-linux-* Toolchain referenziert
werden und auch die Pfade des buildroot Enviroment angegeben werden.
Da ist halt die Frage, wie ich das hin bekomme.
Übrigens läuft der QTcreator unter Windows sofort. Unter Linux wirft er
nur:
Error while building map
When executing build step make
aus.
Naja, ich hab noch viel zu lesen in der gefundenen Doku, aber wenn einer
ne Abkürzung weiß, dann immer her damit
Gruß, Ulrich
> Was bedeutet "build root" ganz konkret?
Ich zitiere mal:
"Buildroot is a set of Makefiles and patches that makes it easy to
generate a cross-compilation toolchain and root filesystem for your
target Linux system using the uClibc C library."
Die Quelle findest du hier: http://buildroot.uclibc.org/> Mich wundert es, dass mit dem Compiler AVR32-gcc nichts läuft und man> statt dessen AVR32-linux-gcc verwenden muss, warum?
Auch hier würde ich gern zitieren:
"Ein Compiler (auch Übersetzer oder Kompilierer genannt) ist ein
Computerprogramm, das ein in einer Quellsprache geschriebenes Programm –
genannt Quellprogramm – in ein semantisch äquivalentes Programm einer
Zielsprache (Zielprogramm) umwandelt."
Quelle: http://de.wikipedia.org/wiki/Compiler
Die Betonung liegt auf semantisch. D.h. der Compiler übersetzt dein
geschriebenes Programm für einen Zielprozessor oder auch Betriebssystem.
mit make menuconfig unter "Package Selection for the Target"/"Graphic
libraries and applications"/"qtopia4" und die "GPL-licenze" und evtl.
noch compatiblity with QT3" auswählen. Alles als fest auswählen, nicht
als modul. Dann wieder make. Lange warten :(
Buildroot bindet dann QT ein, baut aber die Demos nicht.
Unter
/buildroot-avr32-v2.3.0/build_avr32/qt-embedded-linux-opensource-src-4.4
.3/demos findest du dann die Demos.
Hmpf...
Lieber Gast, ich finde, der erste Teil der Antwort hätte gelangt.
Die Frage von chris war ja nicht, warum er avr32-linux-gcc nehmen muss,
sondern warum er einen avr32-gcc hat und der auch noch nicht
ausführbaren Code erzeugt, oder wozu der avr32-gcc gut ist. Ich kann
diese Frage nicht beantworten.
Ich habe übrigens nichts gegen ein paar Zwischenfragen in meinen
Threads, man kann ja immer was dazu lernen.
Gruß, Ulrich
... schrieb:
> mit make menuconfig unter "Package Selection for the Target"/"Graphic> libraries and applications"/"qtopia4" und die "GPL-licenze" und evtl.> noch compatiblity with QT3" auswählen. Alles als fest auswählen, nicht> als modul. Dann wieder make. Lange warten :(> Buildroot bindet dann QT ein, baut aber die Demos nicht.> Unter> /buildroot-avr32-v2.3.0/build_avr32/qt-embedded-linux-opensource-src-4.4
.3/demos
> findest du dann die Demos.
Genial!
Danke! Äh, melde Dich doch mal an, Gast, dann hab ich einen ( gerne auch
phantasievollen) Namen :)
Deine Demos werde ich auch gleich mal ausprobieren. Bin schon dabei....
Ok, da isses wieder, mein Problem.
Bei den originalen Beispielen sind keine Makefiles dabei. Bei Deinem
Demo ist einer dabei, aber der passt natürlich garnicht, weil meine
Pfade anders liegen.
Also lese ich mal die ganzen Hinweise bzgl qmake -project und so
weiter...
Deinem Beispiel lag ja schon ein exe bei, aber mein AP7 beschwert sich,
dass kein qt server laufen würde. Also textedit -qws, aber dann mault
er, dass eine screen depth von 24 nicht unterstützt wird.
Gruß, Ulrich
ja, ok, das ist für einen GH compiliert.
Was ich noch vergessen habe zu erwähnen, alle Grafikformate sollten auch
im menuconfig ausgewählt werden, also jpeg, tif etc.
Unter "Graphics driver" kannst du evtl. " Qt Virtual Framebuffer"
auswählen um das Problem mit der screen depth zu vermeiden.
Hi!
Jo, versuch ich gleich mal. Irgendwie ist mit mein KDE gerade auf die
Nase gefallen...
So, also ich hatte eh schon alle unterstützten Pixel-Tiefen aktiviert,
auch 24bit. Aber nun sind alle aktiv. Auch die Grafik-Formate waren alle
schon aktiv.
Ich mache noch irgendwas richtig falsch... :)
BusyBox v1.13.2 (2009-10-29 23:06:15 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# testedit -qws
-sh: testedit: not found
# textedit -qws
solidFill_setup(): Screen depth 24 not supported!
Aborted
So, habe auch mal die Optionen bzgl. -nomake.
Ich bin mir nicht sicher, ob die demos des qt übersetzt wurden. Zum
einen hat sich der make Durchlauf nicht merklich verändert und zum
Anderen finde ich hinterher keine der Applikationen im target
Filesystem.
Das textdemo beharrt immer noch darauf, dass es 24bpp nicht unterstützt
:)
Das Teilchen ist aber hartnäckig. Oh, sehe gerade, dass das ET035009DH6
Display auch nur ein 18Bit Display ist. Da müsste ich also die Farbtiefe
irgendwo mal ändern...
Naja, es ist an sich schon deswegen unübersichtlich, weil es an mehreren
Stellen die gleichen Optionen anbietet. Es gibt mind. zwei Stellen, um
tiff Support zu aktivieren und auch drei für Framebuffer Sachen.
So, nun ist ein weiterer Lauf am Ende, also wieder das rootfs ins nfs
bringen und reboot :)
Und nein, keine Ausführbaren Dateien im demo oder example Verzeichnis.
Ich hatte aber in die qtopia.mk einen Fehler eingebaut... Das hätte zu
einem Abbruch führen müssen...
Jetzt ist er raus und keine Executables.
Muss ich denn jetzt wirklich ein make clean && make machen.... Das
dauert doch immer so lange....
> Eine Einstellung der bpp finde ich nicht.
weiter unterhalb von wo du QT im menuconfig aktiviert hast.
sieht ungefähr so aus: (-24,18,8, )
auf die Zeile gehen und return, dann öffnet sich ein Textfenster, dort
kannst du dann die Farbtiefe eintippen.
> Ich muss doch für die Verwendung von qt auf dem fb keinen xserver starten, oder?
Nein
Auch basicdrawing meldet sich wie folgt:
# basicdrawing
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
QWSSocket::connectToLocalFile could not connect:: Connection refused
No Qt for Embedded Linux server appears to be running.
If you want to run this program as a server,
add the "-qws" command-line option.
# basicdrawing -qws
solidFill_setup(): Screen depth 24 not supported!
Aborted
#
Grmpf... Ich mach noch was ganz entscheidendes falsch...
Aber ich bin sehr froh für die Unterstützung, Gast :)
Zu spät, make clean && make schon abgeschickt :)
Ist immer noch beim clean :(
Finde das mit der Pixeltiefe aber weder im menuconfig von ICnova, noch
im make xconfig von einem originale buildroot...
Hast Du mal das Token dieser Variablen? Das gibts doch via help.
Dann kann ich per / danach suchen.
ja, gerne, aber im Moment baut er gerade die Demos, das dauert noch.
Grundsätzlich reicht für Neu bauen, wenn man die
zugehörigen.configure-files bzw. das was man neu gebaut haben möchte,
löscht.
ich habe mir gerade auch QTcreator unter Linux installiert. Leider kann
man damit auch die Demos nicht kompilieren, weil die pathvariablen nicht
stimmen. Aber grundsätzlich läuft es unter meinem Ubuntu8.04, welches
auf einer VM unter XP läuft. ;)
Hm, kleiner Bug in meinem buildroot :) er kann das openssh nicht
cleanen, aber bauen kann er es :)
So, neuer Versuch... Die Pixeltiefe habe ich immer noch nicht gefunden,
aber mal sehen...
Das ist schon etwas krank, keines der demos wurde gebaut. Die examples
auch nicht.
Beim nächsten make werde ich die Ausgabe mal umleiten und mir das Log
mal ansehen.
Hm, kann es sein, dass er die Examples nicht baut, weil er diesen
QMAKESPEC conf file nicht findet? Wenn ich manuell im examples Ordner
qmake -o makefile examples.pro eingebe, dann beschwert er sich
jedenfalls darüber.
so, ich make mal abgebrochen. Das Token ist:
config BR2_PACKAGE_QTOPIA4_DEPTHS
81 string "color depths to support"
82 default "-depths 8"
83 depends on BR2_PACKAGE_QTOPIA4
84 help
85 Which color depths to support for the library. Default
is "-depths
86 8". Is specified by a comma separated list, i.e.
-depths 24,16,8.
überprüf mal ob dort -depth 24,16,8 steht.
So, aber ich muss jetzt ins Bett.
Gute Nacht
Jep, das wollte ich auch vorschlagen.
Vielen Dank schon mal, ich hoffe, wir sehen uns wieder, aber ich glaube
ich werde morgen Abend mal eine Auszeit nehmen. :)
Gute Nacht!
Kleiner Nachtrag noch,
Das BR2_PACKAGE_QTOPIA4_DEPTHS
existiert bei mir nicht im aktuellen Buildroot. Es wurde wohl durch eine
Selektionslidte ersetzt, die jeder Farbtiefe ein eigenes Token zuweist.
Hier hatte ich alle und nur die verfügbaren Tiefen mal ausprobiert, ohne
Erfolg.
So, nun gute Nacht.
Hi!
Habe nach dem Zähneputzen gestern noch gesehen, dass da fleißig QT4
Sachen compiliert wurden. Heute Abend werde ich dann doch wenigstens die
Ergebnisse kurz ausprobieren.
Gruß, Ulrich
>Habe nach dem Zähneputzen gestern noch gesehen, dass da fleißig QT4>Sachen compiliert wurden.
Das ist übrigens auch meine sehr erfolgreiche Arbeitsstrategie:
zwischendurch Aufstehen und etwas anderes machen, dann funktionieren die
Dinge plötzlich ...
Ja, da hast Du recht. Wie viele Fehler fallen einem ein, wenn man an der
frischen Luft einfach mal darüber nachdenkt, als zum 1000sten Mal die
gleiche Zeile Code durch zu ackern :)
Hmpf...
War klar, dass das nicht auf Anhieb funktionieren würde :)
Erst bricht es ab, weil es in den demos oder examples Bezüge zu svgview
nicht auflösen kann, nun bricht es ab, weil es in svgview.cpp einen no
matching function call to 'SvgNativeView::connect(QSvgRenderer*&...
meldet, nachdem ich das SVG in den target packages aktiviert hatte.
Das sind wohl ein paar Demos drunter, die nicht auf dem buildroot hier
funktionieren... Grmpf, wie löse ich denn jetzt schon wieder diese
Zusammenhänge auf.
Guten Abend,
svg im menuconfig deaktivieren. Wahrscheinlich ist es das Demo textedit,
was das Problem hervorruft.
Unter /build_avr32/qt-embedded-linux-opensource-src-4.4.3/demos den dort
vorhandenen "Makefile" editieren---> sub-textedit \ in # sub-textedit
\
Hi,
mit dem Link zum Compiler hat es gut geklappt hatte vergessen den PATH
zu setzen. Jetzt lässt sich da Programm gut übersetzen. Wenn ich jedoch
nun teile des Codes in uart.c auslagere und uart.h dazu anlege und diese
dann in meiner main.c aufrufe, meint der Compiler, dass er dir Funktion
UartInit nicht finden konnte. Ich glaube, dass es trotz den #include
"uart.h" die uart.h nicht findet. Hat jemand eine Idee wie ich dies so
einfügen kann, dass er alles findet und ohne Porbleme durchläuft?
Gruß
!Respekt! dauert ein clean /build /make den ganzen Tag??
Ihr seid krass ;))
Ich lese mit Vergnügen und [Be..Ver]wunderung mit.
Das bekommt man als Hardwerker ganricht so mit, was die Kollegen
Softwerker so für K*cke am Hacken haben:) Mein Herren
Viele Grüße und viel Erfolg
Axelr.
Wow, wow, alles Nachtgeister :)
Ich wollte gerade ins Bett und nur mal reinschauen, ob sich noch was
getan hat.
Also der Reihe nach:
An ... (Gast) ( He, bitte erfinde einen Namen und melde Dich an. Für
Deine Hilfe brauchst Du Dich wirklich nicht schämen)
Ich werde das ausprobieren.
@Psykoman:
Der Compiler compiliert nur, was man ihm vorsetzt. Wenn Du also Teile
der Software in uart.c/h auslagerst, dann muss auch uart.c compiliert
werden. Da der Compiler diese Dateien aber nur Datei für Datei
übersetzt, kommen die Beiden nicht zusammen. Der Compiler übersetzt die
Dateien in dem Beispiel von mir auch in einem Modus, in dem er sie
direkt in einen Ausführbaren Maschinencode umwandelt. Das kann er nicht
mehr machen, wenn er mehrere Dateien übersetzen muss, die mit einander
noch verknüpft werden müssen. Schließlich weiß er, wenn er eine Datei
übersetzt nicht, wo die Funktionen aus den anderen Dateien sind. Also
muss er alle Dateien in Object-Code übersetzten. Im Grunde ist das
Ausführbarer Code, der aber noch keine festen Adressen für die
Funktionen und Variablen hat, die aus anderen Dateien benötigt werden.
Er weiß nur aus dem Inhalt der .h (Header-) Dateien, dass es sie geben
muss.
Da kommt dann der Linker ins Spiel. Er baut aus den Object-Dateien eine
ausführbare Datei zusammen.
Da man nun wenig Lust hat, alle Dateien von Hand zu compilieren und
hinterher noch mal alle Dateien zu linken, sollte man sich mal ein paar
einfache Makefiles ansehen. Schau mal nach einfachen kleinen Programmen
und klau Dir davon ein Makefile. Tausche die Namen der Projektdateien
gegen die Deines Projektes aus und schau was passiert, wenn Du dann make
eingibst.
Für kleinere Systeme (AVR) verwende ich seid vielen Jahren ein Derivat
des hier im Tutorial liegenden Makefiles. Alle meine Projekte rund um
den AVR basieren auf einem einzigen Makefile :)
Hi Axel!
Ich mache zum Glück beides, Hardware und Hardware-nahe Software. Wenn
man das eine Leid hat, bleibt einem immer noch das Andere. Auf der
anderen Seite kann man Systeme komplett aus einem Stück gießen und hat
für eine Aufgabe die (hoffentlich) optimale Kombination aus Hardware und
Software.
Das ein Build mal ein paar Stunden dauert, das ist nicht so
ungewöhnlich, aber es kommt auch nicht so oft vor. Ich hatte weiter oben
ja beschrieben, dass das buildroot eigentlich nur ein 'paar' Scripte mit
sich bringt, die dann, je nach Konfiguration erst alles notwendige
downloaden und dann aus Quellen Compiler, Linker, Assembler, Kernel,
Shells, Beispiele, Treiber, u.s.w. zusammen bauen. Hat man das Gröbste
hinter sich, geht alles weitere relativ schnell.
Ich hatte den Tip vergessen in einem neu zu übersetzenden Teil dieses
System einfach eine configure.status zu löschen. Dann hätte das System
eben nur diesen Teil auch in 2min übersetzt. Also hatte aich mit make
clean so ordentlich aufgeräumt, dass vielen neu übersetzt werden musste.
Also alles halb so schlimm und ich glaube, wenn man den Quellcode von
Windows mal neu übersetzen würde, ginge es auch nicht schneller :)
Linux hat halt den Vorteil, dass ich mir eben mal selber ein LCD oder
einen FLASH Baustein anpassen kann, oder eine Taste, ohne einen Treiber
auf einen Treiber über ein API auf einem unverständlich dokumentierten
HAL .... Ne, einfach ab in die Kernel-Quellen, ein passenden Board
kopiert, umbenannt und ein paar Zeilen geändert. Kernel kompilieren,
läuft, fertig.
Gruß, und gute Nacht Euch allen!
Wie jeden Abend, noch ein Nachtrag:
@...(GAST)
Wie bist Du darauf gekommen? Würde die Zusammenhänge gerne verstehen,
denn nach Auskommentieren der Zeilen läuft es zumindest mal weiter mit
dem buildroot.
Irgendwie verwendest Du die gleiche Version des buildroot, wie ich das
tue. Wir hatte nicht in den letzten paar Tagen schon mal eMail-Verkehr?
Up, da hat sich irgendwie gettext aktiviert... Autsch, das braucht viel
zu viel Flash. Naja, ist jetzt egal, rootfs kommt ja via NFS und auf dem
Notebook sind noch 70GB frei :)
Gruß, Ulrich
Ok, jetzt will er die glibc bauen und scheitert an einer fehlenden
/usr/bin/glib-genmarshal
Wieso baut der denn jetzt eine gnome Desktop zusammen? Wer will das
denn?
Ok, gqview war wohl aktiviert...
Dafür klemmt es jetzt wieder beim svgview.... Das hatte ich doch
deaktiviert!
... Ja ist auch noch deaktiviert.
Hmpf, also doch morgen weiter machen, jetzt ist zu spät :)
Gute Nacht!
Hallo Ulrich,
> Wie bist Du darauf gekommen?
Naja, beim builden stoppte er mit einer Fehlermeldung beim compilieren
von der Demo textedit.
Buildroot arbeitet mit makefiles und projektfiles .pro.
Im Hauptordner der Demos finden sich solche, als auch im jeweiligen
Demoordner.
Das Problem bei buildroot ist, dass es "fehlerhafte" Demos nicht
überspringt, sondern stoppt. Also habe ich versucht, das compilieren des
"fehlerhaften" Demos zu unterbinden.
> Dafür klemmt es jetzt wieder beim svgview.... Das hatte ich doch deaktiviert!
Nein, du hattest SVG Module im menuconfig deaktiviert, weil wir dachten,
deshalb würde das Demo textedit nicht gebaut. Dem ist aber nicht so.
svgview klemmt jetzt, weil SVG Module im menuconfig deaktiviert ist.
Da du aber im makefile das compilieren des Demos textedit unterbunden
hast, kannst du SVG Module wieder im menuconfig aktivieren.
> An ... (Gast) ( He, bitte erfinde einen Namen und melde Dich an. Für> Deine Hilfe brauchst Du Dich wirklich nicht schämen)
Da ich auch von anderen Rechnern aus poste, kann ich mich nicht immer
anmelden.
> Irgendwie verwendest Du die gleiche Version des buildroot
Ich verwende gerade das Atmel buildroot 2.3.0 mit dem Patch für den
Grasshopper von hier: Beitrag "AVR32 grasshopper patch für ATMEL buildroot 2.3.0"
Das IC Nova Buildroot basiert auch auf buildroot, genauso wie das Atmel
buildroot, nur mit den zugehörigen Patches für das OEM+ Board.
Leider sind die Patches für den Grasshopper oder das OEM+ Board noch
nicht in den mainstream eingeflossen, so dass man immer noch darauf
angewiesen ist, oder man patched das git buildroot selbst.
> Wir hatte nicht in den letzten paar Tagen schon mal eMail-Verkehr?
Nein, hatten wir nicht.
Gruß
Udo
PS. wäre schön, wenn ein Admin den Thread mal in AVR32 verschieben
würde, da es ja um den AP7000 geht. Da geht er dann nicht immer unter.
Hi!
So, ich bin durch. Es gab noch ein Problem beim install des qt-trees.
Das make für desktop durfte ein Verzeihcnis nicht anlegen. Nachdem ich
es manuell angelegt hatte (/usr/examples) lief der build durch.
Das svgview und noch ein weiteres demo haben Probleme gemacht, u.a. aus
den von Dir genannten Gründen. Ich habe diese Demos dann in den
jeweiligen Makefiles und *.pro gesucht und ebenfalls auskommentiert.
Danach lief der build durch.
Jetzt wird dann mal das loop fürs rootfs gemacht, per nfs exportiert und
dann sehen wir weiter...
Hmpf...
Da hat das Teil mich bis in die Puppen wach gehalten und nun gleich zwei
dicke Brummer:
1. Keines der Demos wurde in irgendein Verzeichnis auf dem rootfs
kopiert. Sie gondeln alle noch im build_avr32 herum.
2. Keines der Demos startet, weil sie sagen, dass 24bit nicht
unterstützt werden, obwohl ich ab 24bit Farbtiefe nach oben alles
abgeknipst habe.
Auf dem SAM7 mit einem 24-Bit Oled hatte ich in der gleichen Zeit schon
meine selbst gestrickte Oberfläche am laufen...
Also meine Meinung zu dem Farbfehler ist, dein QT ist nicht mit einer
Farbtiefe von 24bit compiliert worden.
Da die Einstellungen in deinem Buildroot anders sind als in meinem, mach
doch mal bitte mal einen screenprint davon.
Ansonsten aktiviere dort mal verschiedene Farbtiefen, also 24bit, 16bit
und 8bit.
Dann lösche im Ordner
/build_avr32/qt-embedded-linux-opensource-src-4.4.3 mal alle .xxxx
Dateien, also .configure etc. und dann führ dann wieder make aus.
buildroot hatt manchmal die unangenehme Eigenschaft, Änderungen im
menuconfig nicht umzusetzen.
Hmmm... Wenn ich mal folgendes mache:
cat /sys/class/graphics/fb0/bits_per_pixel
Dann erscheint eine 24!
Mein Linux ist also der Meinung, dass 24 bit per pixel unterstützt
werden.
Das Display selbst, hat aber nur 18. Elektrisch wäre das ja sogar egal,
denn die unteren Pixel sollten verloren gehen, nicht die oberen.
Laut Datenblatt ist das ET035009DH6 auch ein 24Bit Display...
In der Beschreibung des ADB1000 steht, dass der LCD Verbinder entweder
für
1x 18Bit kompatibel mit ET035009DH6
oder
1x 24Bit kompatibel mit ET050000DH&
ist.
Ok, also bei den verschiedenen rudimentären Datenblättern im Netz ist
beim ET035 264k Farben angegeben, also 18-Bit.
Muss ich jetzt irgendwie die Farbtiefe des fb0 umstellen....
Kennt jemand die passenden Kernel-Parameter dafür? Ich finde nur Listen
mit den Parametern für die großen GraKarten.
Gruß, Ulrich
ja, dein Kernel ist für 24bit gebaut. Aber dein QT nicht....
mplayer arbeitet doch, oder hast du da Farbverfälschungen gesehen? Also
ist deine Hardware i.O. und dein Kernel auch.
Das ET035009DH6 Display ist ein 24bit Display. Siehe Datenblatt-Anhang.
Das Datenblatt vom ADB1000 scheint zu irren. Denn im Stromlaufplan vom
ADB1000 sind beide Displayslots als 24bit-Slots ausgelegt.siehe Anhänge.
Es sind beide Slots auf der Leiterplatte auch 50pol.
Sorry, bin vor dem Fernseher kleben geblieben...
Vielen Dank für die Datenblätter, Udo!
Ist mir übrigens gerade eingefallen, dass bits_per_pixel irgendwie
missverständlich ist. Das Display hat 24 Bit für RGB zusammen, also sind
es 8 Bit pro Pixel.
Im Kernel habe ich keine Einstellung für die Pixel gefunden, nur im QT.
mplayer läuft perfekt, keine Farbverfälschungen.
Die Schaltpläne zum ADB1000 habe ich auch, Display steckt im richtigen
Slot und auch richtig herum :)
Also muss ich das QT noch mal für 8bbp bauen, dann sollte es passen,
oder?
Gruß, Ulrich
Also ich muss vermutlich erst mal wieder die ganzen config.status
dateien löschen, bevor er das qt neu übersetzt. Hatte jetzt schnell mal
einen Versuch mit 8bpp im menuconfig gemacht, aber das ging viel zu
schnell durch.
Im Kernel muss ich auch mal nach der Auflösung suchen, falls es da eine
gibt.
Aber das mache ich dann morgen Abend, da bin ich früher am PC und laufe
auch nicht weg :)
Gruß, Ulrich
Ok, mach ich, heute Abend, wenn ich wieder zu Hause bin.
Aber natürlich wären 18, oder wenn das LCD 24 bit emuliert, auch 24 Bit
pro Pixel richtig und nicht 8. Da war ich wohl in den Bohnen...
Eigentlich kann man doch bei den bits per Pixel nix verkehrt machen. Nur
die Art der Einstellung unterscheidet sich anscheinend bei uns beiden.
Du hast ein Textfeld, in dem man die Auflösungen ageben kann: 8,16,24
Bei mir ist es eine Liste zum Abhaken:
O 1
O 2
O 4
X 8
O 12
u.s.w.
Aber, ich habe gelesen, dass QT ohne den -depth Parameter annimmt, dass
es 24 Bit sein sollen. Ich fürchte nun, dass das in meinem Buildroot
anders, aber nicht vollständig gemacht wurde. D.h. für QT selbst wurden
die Einstellungen vielleicht schon verändert, aber für die Examples /
Demos wurde die Generierung des Strings noch nicht angepasst.
Aber mal noch eine Frage zum Qt selbst. Wenn man eine der Demos aufruft,
erhält man eine ganze Reihe Fehlermeldungen : Cannot Connect to ...
Dann hat man wieder die Kommandozeile. Erst wenn man eine Demo mit dem
Parameter -qws aufruft, will es starten.
Bedeutet das, dass eine QT-Applikation als Server laufen muss und die
anderen sich dann darauf verbinden können?
Gruß, Ulrich
> Bedeutet das, dass eine QT-Applikation als Server laufen muss ..
Ja, jedenfalls lt. dem Dokument hier:
http://doc.trolltech.com/4.3/qtopiacore-running.html> und die anderen sich dann darauf verbinden können?
wer sind "die anderen" und wie sollen sich die verbinden?
Gruß
Udo
> oder wenn das LCD 24 bit emuliert
Wie ich oben schon ausgeführt habe:
Die müssen sich bei IC-Nova in dem Datenblatt geirrt haben.
Da ist nichts mit 18bit!
Beide Displays, die sie dort aufführen sind 24bit RGB Displays.
Auch im Stromlaufplan sind an beiden Sockeln die 24bit herangeführt.
Die Anschlussbelegung der Sockel sind nur an die unterschiedliche
Anschlussbelegung der beiden Displays angepasst.
Gruß
Udo
SO, nun hab ich mal wieder Zeit dafür.
Im Anhang gleich mal der Snapshot von meiner buildroot bpp Einstellung.
Sieht also merklich anders aus, als die von Dir, Udo.
Ok, es geht voran!
Ich habe auf dem ADB1000 kein ScreenCapture laufen, daher kein Bild
ABER! Ich habe die ersten QT-Demoa am rennen!
Ich habe noch mal nachgeschaut und ein ein sehr hilfreiches Tool
gefunden, dass im buildroot gleich mit einkompiliert wird:
fbset
1
# ls
2
images interview styledemo
3
# ./styledemo -qws
4
solidFill_setup(): Screen depth 24 not supported!
5
Aborted
Also wie immer. Nun gut, versuchen wir mal was anderes:
Juchuu! Es geht bei 8bpp, jedenfalls sehe ich ein paar sehr nette
Bedieneroberflächen.
Nur kann ich die leider nicht bedienen, weil der touch nicht geht, oder
moment...
Doch ,aber nicht mit Qt. Bei den lite-Beispielen funktioniert der Touch.
Also mal meine Gedanken sortieren....
Aufgabe 1) Qt auch mit 18/24bpp ans Laufen bekommen.
Aufgabe 2) Touch unter QT ans laufen bringen
Aufgabe 3) QTcreator so verbaseln, dass er dann auch Oberflächen für
meinen Zwerg hier erstellt.
Aber zwischendurch schon mal vielen Dank an alle fleißigen Helfer hier,
die mich unterstützt und bei Laune gehalten haben!
Na, dann forsche ich mal weiter....
für die Touchunterstützung kannst du das mal ausprobieren:
export QWS_MOUSE_PROTO=Tslib:/dev/input/event0
wobei, ich weiß nicht ob du die Tslib aktiviert hast im buildroot.
kannst du mal die Datei setup.c aus dem Pfad:
/buildroot-avr32-v2.3.0/project_build_avr32/grasshopper/linux-2.6.27.6/a
rch/avr32/boards/grasshopper (grasshopper bitte gegen deine
Boardbezeichnung tauschen)
posten? Ich hab da eine Vermutung.
1) Tslib ist drin, export gemacht, QT schert sich nicht drum.
Habe das auch mal so ausprobiert:
./mainwindow -qws -g 320x240x0x0 -mouse -keyboard
Hupe jeht, kiek mal Licht... Oder Bild da, Maus nur als unbeweglicher
Pfeil.
2) Wenn ich das mal in meine Pfade übersetze:
.../project_build_avr32/oemplus/linux-2.6.28.4/arch/avr32/boards/icnova
Dann gibt es da einen ganze Sack voller Dateien, aber keine die mit
setup anfängt. Allerdings eine icnova.c oder eine icnova_base.c.
Da mein buildroot den grasshopper nicht kennt, kann ich jetzt auch
schlecht sagen, was welche der Dateien der setup.c entsprechen könnte...
Wow, wenn man in gogle 'icnova +touch' eingibt, dann ist dieser Thread
bereits auf Platz 2! Ich brech ab...
Muss diesen Thread mal dem Admin melden, damit er den Titel ändert.
?? Was?
Ich habe Dir den kompletten Ordner icnova aus dem kernel/boards/ in das
icnova.tar.gz einen Post zuvor gepackt.
Wenn Du mir sagst, was Du suchst, dann schau ich mal nach.
Ich habe in einem anderen Thread auch einige Hinweise von Dir gefunden,
die sich auf Touch und Qt beziehen. Dort hing aber der SPI fest, das ist
bei mir nicht der Fall:
1
TFTP from server 192.168.10.106; our IP address is 192.168.10.80
> Ich habe Dir den kompletten Ordner icnova aus dem kernel/boards/ in das> icnova.tar.gz einen Post zuvor gepackt.
ok, sorry, sieht bei mir etwas anders aus.
> input: ADS784x Touchscreen as /class/input/input0
Touch sollte funktionieren.
export QWS_MOUSE_PROTO=Tslib:/dev/input/event0
hast du gemacht?
touch solltest du auch so testen können:
chmod +x /usr/bin/ts_test
ts_test /dev/input/event0
gibt es in deinem Verzeichnis /usr/bin/ die Datein ts_calibrate,
ts_test?
vielleicht erst mal ts_calibrate aufrufen.
Dann passiert beim ersten mit /dev/input/event1 nix, ich muss das
abbrechen.
Bei ts_finddev /dev/input/event0 10 reicht es den Schirm kurz zu
berühren und das ts_finddev beendet sich umgehend.
Ein /dev/touchscreen gibt es nicht
Ach so, ja habe ich:
ich hatte die Stelle gesucht:
struct atmel_lcdfb_info __initdata icnova_lcdc_data = {
.default_bpp = 24,
.default_dmacon = ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
.default_lcdcon2 = (ATMEL_LCDC_DISTYPE_TFT
findest du in der vga.c
Aber da sind 24bit eingestellt.
Wenn dein Display auf 8bit eingestellt ist, müsste man das doch sehen.
Das sind gerade mal 256 Farben.
Kopier dir mal das angehangene Bild und stell das mal fbv dar.
Da dürften keine Kanten bei den Farbverläufen zu sehen sein.
Ich habe mir jetzt meinen ADB1000 mal angesehen. Qt läuft bei mir.
Ulrich P. schrieb:
> Habe mal mit den ts_* herum gespielt:>> Das sieht doof aus, aber wenn ich nun folgendes mache:>
1
> # ts_finddev /dev/input/event1 10
2
> Probe device /dev/input/event1, Please Touch Screen Anywhere in 10
3
> seconds! ...
4
>
5
> # ts_finddev /dev/input/event0 10
6
> Probe device /dev/input/event0, Please Touch Screen Anywhere in 10
7
> seconds! ...
8
>
> Dann passiert beim ersten mit /dev/input/event1 nix, ich muss das> abbrechen.> Bei ts_finddev /dev/input/event0 10 reicht es den Schirm kurz zu> berühren und das ts_finddev beendet sich umgehend.>
/dev/input/event0 ist der richtige.
Bei ts_test sollte so etwas wie hier heraus kommen
1
# ts_test
2
tslib: Unknown event type 0
3
1167610157.433086: 169 127 1342
4
1167610157.438374: 167 125 1342
5
1167610157.438374: 167 124 1342
Funktioniert aber erst nach einem calibrate.
Das sich ts_finddev beim berühren beendet ist richtig.
> Ach so, ja habe ich:>
Das ts_calibrate funktionierte bei mir nicht, ich habe mousecalibration
aus
ICnova/build_avr32/qt-embedded-linux-opensource-src-4.5.1/examples/qws
verwendet.
Im Buildroot habe ich mir eingestellt.
1
Package Selection for the target --->
2
Graphic libraries and applications (graphic/text) --->
3
Mouse drivers --->
4
5
6
[*] tslib
1
Package Selection for the target --->
2
Graphic libraries and applications (graphic/text) --->
3
Graphics drivers --->
4
5
[*] Linux Framebuffer
6
[*] Transformed
7
[*] Qt Virtual Framebuffer
8
[ ] VNC
9
[ ] multiscreen
Es müsste Linux Framebuffer reichen. Transformed wird benötigt um den
Bildschirm zu drehen.
Udo S. schrieb:
> ich hatte die Stelle gesucht:> struct atmel_lcdfb_info __initdata icnova_lcdc_data = {> .default_bpp = 24,> .default_dmacon = ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,> .default_lcdcon2 = (ATMEL_LCDC_DISTYPE_TFT> findest du in der vga.c> Aber da sind 24bit eingestellt.> Wenn dein Display auf 8bit eingestellt ist, müsste man das doch sehen.> Das sind gerade mal 256 Farben.> Kopier dir mal das angehangene Bild und stell das mal fbv dar.> Da dürften keine Kanten bei den Farbverläufen zu sehen sein.
Also der fb läuft auf jeden Fall mit mehr als nur 256 Farben. Ich hatte
ja schon erfolgreich den mplayer am Laufen und das Video sah sehr gut
aus. Klein aber gut.
Ich nehem sehr stark an, dass die Umstellung der Vorgaben im buildroot
von String auf Liste das Problem ist. Vermutlich bekommt qt diese neue
Liste nicht zugestellt und geht von einem Default aus. Und der scheint 8
zu sein.
Udo S. schrieb:
> kopier dir mal die Dateien in dein /usr/bin/ Ordner.
Beide funktionieren. Zuerst war das ts_test nicht bedienbar. Nach einem
ts_calibrate funktioniert es nun wunderbar.
Qt scheint das aber nicht weiter zu beeindrucken.
Hi Woody!
Bei mir sieht es nach einem fbset -depth 24 auch genau so aus. Dann
quittiert aber Qt mit dem o.g. Fehler jeden Versuch.
mit fbset -depth 8 funktioniert dann wieder Qt.
Woody P. schrieb:
> Ich habe mir jetzt meinen ADB1000 mal angesehen. Qt läuft bei mir.>> /dev/input/event0 ist der richtige.>> Bei ts_test sollte so etwas wie hier heraus kommen>>
1
> # ts_test
2
> tslib: Unknown event type 0
3
> 1167610157.433086: 169 127 1342
4
> 1167610157.438374: 167 125 1342
5
> 1167610157.438374: 167 124 1342
6
>
>> Funktioniert aber erst nach einem calibrate.
Das ist korrekt und auch bei mir jetzt so.
>> Das sich ts_finddev beim berühren beendet ist richtig.
Klar, aber nur, wenn man das richtige Device angibt. Das habe ich ja
gefunden.
>> Ich habe in /etc/profile eingetragen>>
>
Das ist ne gute Idee, das hole ich gleich noch nach... Dann vergesse ich
es nach einem Reboot auch nicht.
Habe das unter project_build_avr32 abgelegt, dann kommt es bei einem
neuen build auch gleich mit drauf. Habe auch die ts.conf aus dem rootfs
zurück auf das bproject_uild_avr32/.../root/etc kopiert. Das Original
scheint eher für ein größeres Display gewesen zu sein. SO sollte ich mir
jedenfalls die Klaibrierung ersparen können. Oder?
> Das ts_calibrate funktionierte bei mir nicht, ich habe mousecalibration> aus> ICnova/build_avr32/qt-embedded-linux-opensource-src-4.5.1/examples/qws> verwendet.>
Mein ts_calibrate funktionierte auch nicht, aber das von Udo schon. Er
müsste mir bei Gelegenheit mal stecken, was er daran verändert hat.
> Im Buildroot habe ich mir eingestellt.>>
1
> Package Selection for the target --->
2
> Graphic libraries and applications (graphic/text) --->
3
> Mouse drivers --->
4
>
5
>
6
> [*] tslib
7
>
Habe da auch noch den qvfb, aber das sollte ja nicht stören. Touch geht
ja, nur Qt mag ihn nicht.
>>
1
> Package Selection for the target --->
2
> Graphic libraries and applications (graphic/text) --->
3
> Graphics drivers --->
4
>
5
> [*] Linux Framebuffer
6
> [*] Transformed
7
> [*] Qt Virtual Framebuffer
8
> [ ] VNC
9
> [ ] multiscreen
10
>
>> Es müsste Linux Framebuffer reichen. Transformed wird benötigt um den> Bildschirm zu drehen.
Das ist identisch, nur habe ich den Transformed nicht. Mein Display
steht nicht auf dem Kopf :)
Ulrich P. schrieb:
> Hi Woody!>> Bei mir sieht es nach einem fbset -depth 24 auch genau so aus. Dann> quittiert aber Qt mit dem o.g. Fehler jeden Versuch.> mit fbset -depth 8 funktioniert dann wieder Qt.
Ich glaube den Fehler mit der 24 Bit Farbtiefe bei Qt hatte ich auch.
Ich meine ich hätte vergessen die Farbtiefe bei Qt einzustellen.
Sieht bei mir so aus
1
Package Selection for the target --->
2
Graphic libraries and applications (graphic/text) --->
3
Pixel depths --->
4
5
*** Deselecting each option leads to Qt's default (8,16,32) ***
6
[ ] All supported depths
7
[ ] 1 bpp, black/white
8
[ ] 4 bpp, grayscale
9
[*] 8 bpp, paletted
10
[ ] 12 bpp, rgb 4-4-4
11
[ ] 15 bpp, rgb 5-5-5
12
[*] 16 bpp, rgb 5-6-5
13
[*] 18 bpp, rgb 6-6-6
14
[*] 24 bpp, rgb 8-8-8
15
[*] 32 bpp, argb 8-8-8-8 and rgb 8-8-8
Aber das hast du bei dir schon eingestellt. Die 18 Bit sind eingestellt
weil ich der IC Nova Dokumentation glaubte.
Ich kann mich nicht daran erinnern noch etwas anderes eingestellt zu
haben.
Die Konfiguration von Qt hat bei mir auch einige Durchläufe benötigt.
Zuletzt hatte ich das generierte Qt nochmal komplett gelöscht und alles
nochmal neu bauen lassen. Bei mir läuft auch Qt Version 4.5.1.
In package/qtopia4/qtopia4.mk die Versionnummer von 4.4.3 auf 4.5.1
erhöhen. Das Paket sollte dann automatisch aus dem Internet geladen und
gebaut werden.
Die Konfigurationsdateien in boards/icnova habe ich nicht angefasst.
Hmpf... Hatte jetzt mal das Display mit fbset -depth auf 24 bit zurück
gesetzt. Nun funktionieren ts_calibrate und ts_test nicht mehr.
Mit fbset -depth 16 funktionieren dann wieder beide.
Ich kann auch ohne ts_calibrate zwischen 8 und 16 hin und her schalten.
Die Kalibrierung beeinflusst das nicht.
Bei 24 habe ich bei ts_test kein Bild, aber der Touch wirft korrekte
Koordinaten raus.
Moment, ich probier mal noch was...
Habe mal alles hin und her kopiert und dafür gesorgt, dass auch das
profile synchron ist. Dann Neustart des ADB1000 und probiert:
ts_test funktioniert in 8 und 16bpp aber nur ohne Bild in 24bpp
Qt demos funktionieren nur in 8bpp und ohne Touch. Auch Parameter wie
-mouse oder -keyboard interessieren Qt wenig. Und ein Keyboard hängt
dran! COnsol geht damit einwandfrei. Oh, gelogen. Wenn ich das Qt Demo
über die USB-Tastatur starte, die am ADB hängt, dann kann ich im
spreadsheet Demo auch Text eingeben und navigieren. Aber Mausen kann ich
nicht, äh, Touchen meine ich :)
Ok, was solls, ist ja nur zum Spaß....
Qt4.5.1 rollt gerade herein. Ich habe aber einen der letzten Abende
damit verbracht alle möglichen Pakete innerhalb der Demos und Examples
zu deaktivieren, bis der buildroot durch lief. Mal sehen, wie das
diesmal wird. Aber wenn ich an die Laufzeit von buildroot denke, die für
Qt benötigt wurde, dann wird das heute nix mehr... Ne, heute ist ja nur
noch 5min...
So ganz passt das buildroot wohl nicht zum Qt, denn ich wurde von Qt
gerade gefragt, ob ich die commercial oder die open source Version
installieren möchte. Das war im buildroot klar definiert. Dass ich die
Lizenz bestätige, hat er aber wieder gewußt.
So, da das dauert, werde ich mal meine Workstation rebooten und auf
Linux wechseln... muss mal ubuntu updaten auf die 9.10. Melde mich dann
von da aus wieder :)
also ich habe an meinem Board einen PS2-Anschluss, wenn ich da eine
Mouse anstecke kann ich sowohl über den Touch, als auch über die Mouse
QT bedienen.
Versuch doch mal eine USB-Mouse oder USB-Tastatur.
> Er müsste mir bei Gelegenheit mal stecken, was er daran verändert hat.
Sorry, aber das kann ich nicht mehr, da mir der Sourcecode durch einen
Festplattencrash abhanden gekommen ist. Ich weiß nur noch, dass ich den
Code etwas aufgeräumt habe, dabei ist aber auch das Justier-Bild im
24bit-Modus verloren gegangen. Das kann man aber durch Anzeigen des an
gehangenen Bildes beheben. Die Punkte müssen im Uhrzeigersinn berührt
werden, zuletzt der in der Mitte.
So, da bin ich wieder. Hatte ganz vergessen, dass ich das XP ja
nachträglich drauf installiert hatte, also musste ich Grub erst mal
wieder reaktivieren...
Also das ts_test und ts_calibrate funktionieren ja. Wenn das Bild
abhanden gekommen ist, kein Problem. Andere mitgelieferte Anwendungen
funktionieren ja unter jeder bpp auch 24bpp. Also scheinen Hardware und
Kernel zu passen.
USB Tastatur funktioniert in der Shell, in den anderen Demos und in Qt.
Touch funktioniert überall aber nicht in Qt.
Eine angesteckte USB Maus wird vom USB Subsystem sofort erkannt, bewegt
den Cursor in Qt aber auch nicht. Welche andere (nicht Qt) Anwendung
kann denn noch mit der Maus umgehen? KDE / Gnome habe ich ja nicht auf
dem System :)
Bin ich froh, dass ich den openssh schon drauf habe. Hatte mir über den
Seriellen Zugang noch keine Gedanken gemacht... Muss ich wohl mal
schauen, wo sich unter Linux mein openocd-usb versteckt.
event3 reagiert wild und entschlossen :)
(1115 Pakete werden installiert, 29% abgeschlossen....Uff!)
buildroot kompiliert noch fleißig an Qt 4.5.1 herum
Nee, das hatte ich schon.
Qt mag keine Mäuse, jedenfalls nicht das 4.3.x, das da noch läuft. Bin
mal gespannt wer schneller ist, Ubunut update oder buildroot... Ich muss
ins Bett!
Keine Panik, buildroot läuft auf dem Notebook links neben mir. In der
Mitte läuft das Update und recht hängt ein Cursor fest auf dem Display
des ADB1000.
Komm mir vor wie in einem Raumschiff :)
Murks!
make install kanllt wieder auf die Nase:
make[4]: ENtering diorectory
`/home/uprinz/ICnova/build_AV32/qt-embedded-linux-opensource-src-4.5.1/e
xamples/desktop/screenshot'
mkdir: cannot create directory `usr/examples': Permission denied
Das hatte ich unter 4.3.x auch schon mal... Ich bin mir fast sicher,
dass da einfach vor dem /usr/examples was fehlt...
Morgen ist auch noch eini Tag...Gute Nacht.
Ulrich P. schrieb:
> Murks!>> make install kanllt wieder auf die Nase:> make[4]: ENtering diorectory> `/home/uprinz/ICnova/build_AV32/qt-embedded-linux-opensource-src-4.5.1/e
xamples/desktop/screenshot'
> mkdir: cannot create directory `usr/examples': Permission denied>> Das hatte ich unter 4.3.x auch schon mal... Ich bin mir fast sicher,> dass da einfach vor dem /usr/examples was fehlt...>> Morgen ist auch noch eini Tag...Gute Nacht.
Keine Ahnung was da schiefgelaufen ist. Die examples habe ich bei mir
weggelassen.
Lass mal die examples weg, die sollten im mitgelieferten qmake.mk mit
1
-nomake examples
2
-nomake demos
dekativiert sein (siehe weiter oben im Thread)
Die Beispiele können später noch einzeln gebaut werden mit qmake. Aber
darauf achten das qmake aus dem buildroot verwendet wird, sonst stimmen
die Pfade im generierten Makefile nicht und es gibt x86 Binaries.
Der Aufruf von des erzeugten Qt Programms mit "file" sollte etwas mit
AVR32 und MSB liefern.
Hi!
Naja, das mit den examples und demos ist nicht wirlich ein Problem. Ich
muss die Dinger halt von Hand auf das ADB kopieren, was dan rootfs via
NFS kein problem ist, ich komme ja vom buildroot-Rechner direkt ans
NFS/rootfs.
Ich wollte ja nur ein / zwei demos, um mal zu sehen, wie es ist und wie
es geht. Die Demos gab es aber nur ganz oder garnicht, weil eben das
qmake manuell nicht ging. Im buildroot ging es aber. Aber man lernt dazu
und ich schau mal nach den gesetzten Pfaden, da sollte das qmake aus dem
buildroot alleine, oder wenigstens vor dem qmake vom Host eingetragen
sein.
Letztendlich löst das aber nicht das Problem mit den 24bpp. Ob das unter
4.5.1. auch noch existiert, werde ich dann ausprobieren, wenn ich zu
Hause bin.
Gruß, Ulrich
Diesmal geht es mit guten Nachrichten weiter:
Qt 4.5.1 funktioniert vollständig.
1) Alle Beispiele wurden ohne Eingriffe in die Makefiles oder *.pro
durch compiliert.
2) Ein Problem war durch ts_calibrate aufgefallen:
Es muss export TSLIB_FBDEVICE=/dev/fb0 heißen, der führende / ist
wichtig :)
3) Zwei Qt-Demos habe ich schon ausprobiert und sie funktionieren
einwandfrei mit 24bpp und Touchscreen. Perfekt!
Folgende Kleinigkeiten vereinfachen das Testen enorm:
Kalibirieren des Touch:
ts_calibrate legt eine /etc/pointercal an. Diese sollte man einfach vom
Board herunter nach .../buildroot/project_build_avr32/oemplus/root/etc
kopieren und danach mit chown auf sich berechtigen. Die Datei wird mit
root:root angelegt und führt dann bei buildroot zu einem permission
denied.
Danach fügt man folgenden Block in /etc/profile ein:
1
### Configure display & touch for use with Qt
2
export TSLIB_TSDEVICE='/dev/input/event0'
3
export TSLIB_FBDEVICE='/dev/fb0'
4
export TSLIB_CONSOLEDEVICE='none'
5
export TSLIB_CONFFILE='/etc/ts.conf'
6
export TSLIB_CALIBFILE='/etc/pointercal'
7
export QWS_MOUSE_PROTO='tslib:/dev/input/event0'
8
export QWS_DISPLAY='LinuxFb:0'
Auch diese Datei kann man, vom rootfs zurück nach
.../buildroot/project_build_avr32/oemplus/root/etc
kopieren und danach user:group auf den Account ändern, unter dem man
buildroot laufen lässt.
So, dann versuchen wir mal QTcreator ans Laufen zu bringen.
Hmmm... Muss da mal noch was untersuchen. Das Modul auf dem ADB1000+
soll ja auch ein + Modul sein. Das wiederum soll 256MB Flash haben und
nicht 64, wie das einfache.
Aber buildroot erstellt nur ein rootf.avr23.ext2 von 64MB. Auch ein df
gibt auf der Konsole nur 60MB für das rootfs an. Da schlummern alo noch
ein paar unerkannte MB vor sich hin.
Aber die letzten Nächte waren eindeutig zu lang. Heute ist mal früher
Schluss!
Vielen Dank schon mal für die ganze Hilfe und Motivation.
Es geht weiter
Ulrich
64MB Mobile SD-RAM (32-Bit)
256MB NAND-Flash (8-Bit)
1MB NOR-Flash (16-Bit)
• In mtdblock0 liegt der Linux-kernel
• In mtdblock1 liegt das Root-Dateisystem
• mtdblock2 ist z.Z. unbenutzt
Hi!
Nein, habe gestern mal einen faulen Abend gemacht :)
Vor heute Abend mach ich auch nicht weiter. Werde zunächst mal die
Größen von mtdblock1 / 2 anpassen. Ich brauche noch etwas mehr Platz für
/usr/bin und den Rest mounte ich vielleicht als home/. Dann kann ich
user-programme installieren für verschiedene Tests. Aber einfacher
sollte es sein, erst einmal nur das rootfs auf die vierfache Größe
aufzurüsten.
Und dann geht es mal ans Oberfläche-Basteln mit Qt. Wenn ich das richtig
verstanden habe, muss ich den QTCreator ja eigentlich nur dazu
überreden, das Projekt in einem buildroot Pfad abzulegen. Dann achte ich
darauf, dass die Pfade für qmake aus dem buildroot kommen. Alles was
dann noch fehlt ist die Sache mit den libraries, denn da müssen ja auch
die aus dem Buildroot angezogen werden. Muss also mal nachsehen, wo
buildroot diese setzt, bevor es sich bei den QT-Demos ans Werk macht.
Übrigens musste ich bei Qt4.5.1 keine Beispiele aus dem build entfernen.
Einige Beispiele wurden automatisch außen vor gelassen, alle anderen
wurden fehlerfrei übersetzt und sind lauffähig. Auch textedit.
Ich sollte IC-board.de mal darüber informieren, falls die nicht ohnenhin
schon mitlesen :)
So, ich werde jetzt mal einen Tag mit der Familie in der Stadt
verbringen, die sind in den letzten Wochen eh zu kurz gekommen. Bis
heute Abend dann!
Einen schönen Samstag Euch allen.
Ulrich
Guten Abend!
Naja, sd-card war auch meine erste Überlegung. Aber es ist so viel
einfacher den Kernel per TFTP zu laden und das rootfs per NFS
einzuhängen. Da muss man einfach nur mal schnell Reset drücken und nicht
erst hin und her kopieren und Karte abmelden u.s.w.
Ich bin noch nicht weiter gekommen. Nachdem das Update auf Ubunut 9.10
auf der Workstation völlig problemlos war, habe ich es auch auf dem
Notebook gemacht. Dort habe ich aber eine Login-Loop... Immer wenn ich
Name / Passwort angebe, macht KDE Anstalten zu staren und dann habe ich
den Login-Screen wieder. Irgendwie habe ich es geschafft das KDE
anzuschießen und mich auf Kommandozeile ein zu loggen und dann das
startx dort gemacht. Nun isser wieder da... Aber neu starten mag ich
nicht, egal das Notebook läuft eh immer.
Also kann es jetzt weiter gehen. Da dieser Fehler schon öfters im Netz
auftaucht und anscheinend alle paar Versionen mal wieder auftaucht, wird
es dafür wohl auch bald eine Lösung geben, hoffe ich.
Werde vielleicht nachher mal einen Versuch in Richtung QTcreator
starten.
Gruß, Ulrich
Interessanter Thread - hat mir schon an ein paar Stellen geholfen.
Hier nun ein paar Anmerkungen von mir:
>Auch diese Datei kann man, vom rootfs zurück nach>.../buildroot/project_build_avr32/oemplus/root/etc>kopieren und danach user:group auf den Account ändern, unter dem man>buildroot laufen lässt.
Unter bzw. mit Hilfe von
/target/device/In-Circuit/icnova_oemplus/device_table.txt kann man das
automatisieren.
>qt-embedded-linux-opensource-src-4.5.1
Scheinst du "von Hand" eingebaut zu haben. Der Kernel+patch der
icnova-buildroot Umgebung lässt sich ganz gut nach buildroot2009.8
portieren, da hat man viele Updates gleich mit drin und so funktioniert
dann auch ...
>Aber buildroot erstellt nur ein rootf.avr23.ext2
... die Erstellung von jffs2. Es ist wohl ein Update der mtd-utils
notwendig !?
>Ich bin noch nicht weiter gekommen. Nachdem das Update auf Ubunut 9.10
Ich musste bei mir den icnova Kernel zusätzlichen patchen, damit bei mir
auch unter Kubuntu 9.10 alles wie vorher unter 9.04 gebaut werden
konnte:
zwei Dateien scripts/unifdef.c bzw. extras/scripts/unifdef.c musste ich
die statische Funktion+Aufruf getline() in get_line() umbenennen.
Viel Spaß noch ! Bin schon auf deine QTCreator Ergebnisse gespannt.
Hi Jens!
Das sind ein paar echt interessante Anmerkungen.
Der Qt Patch war tatsächlich von Hand. Ich hatte mich vor langer Zeit
mal damit beschäftigt auf einer Rittal CMC-PU einen Kernel 2.6.26 zum
Laufen zu bringen, ebenfalls mit buildroot. Daher war das mit dem
Aktualisieren einzelner Pakete kein Problem.
Beim ersten Lauf des Buildroot sind mir etliche Patches aufgefallen, die
dort eingespielt wurden. Da ich nicht weiß, wie man das Patchen mehr
oder weniger automatisiert auf Sinn prüfen kann, war ich davor zurück
geschreckt. Ich hatte keine Lust hunderte Dateien zu vergleichen.
Dagegen ist das Adaptieren der Board spezifischen Dateien kein Problem.
Wie gesagt, das da ganz unten ist mein tägliches Brot auf allem, was
sich programmieren lässt.
Bei Qt ist die Stelle, wo ich auf fremdem Revier wildere :)
Die Anmerkung zu ext2 verstehe ich nicht. Die mtd-utils erstellen brav
ein jffs und ein ext2. Das ext2 verwende ich via loop device um es in
ein Verzeichnis ein zu hängen und dieses wiederum per NFS dem AVR32 zur
Verfügung zu stellen. So kann ich Dateien darin austauschen, oder eben
auf dem ADB1000 generierte Dateien zurück in den buildroot zu
übernehmen. So geschehen mit der conf und Kalibrierung für das
ts-device. Jetzt ist mein Touchscreen nach jedem buildroot durchaluf und
Reboot gleich kalibriert, ein normaler user angelegt und der root hat
ein Passwort.
Fürs Qt bin ich noch was am Suchen. Ich finde in den beiliegenden Demos
nur Dinge, die wohl eher für einen 15" Monitor geschrieben wurden als
für einen 3.5". Im Netz habe ich zwar schicke kleine Oberflächen
gefunden, aber nur in Bildern, keinen Code.
Letztendlich wird das Entwickeln einer Oberfläche nicht mein Job sein,
sollte daraus ein Produkt werden. Dafür gibt es andere. Ich werde
Treiber für Sensoren schreiben, für Funk, Usb, RS422, CAN. Mist, CAN hat
er ja nicht... egal, klebe ich halt einen SJA dazu :)
Die Oberfläche soll nur die Möglichkeiten des Systems aufzeigen und ein
paar trockene Messwerte ansehnlich darstellen. Egal, ich lerne immer
gerne dazu.
Gruß, Ulrich
Ulrich P. schrieb:
> Beim ersten Lauf des Buildroot sind mir etliche Patches aufgefallen, die> dort eingespielt wurden. Da ich nicht weiß, wie man das Patchen mehr
Eigentlich ist nur ein Mega-Patch für den Kernel selbst dabei und dann
noch ein zusätzlicher Patch Pfad definiert (da hab ich aber länger
suchen müssen)
Müsste bei Gelegenheit mal ein Sammel-Patch für icnova->br2009.8
erstellen.
>> Bei Qt ist die Stelle, wo ich auf fremdem Revier wildere :)
Bin da auch noch in Einarbeitung. Momentan versuche ich aber zunächst
eine fertige Applikation zu integrieren.
> Die Anmerkung zu ext2 verstehe ich nicht. Die mtd-utils erstellen brav
Oben stand "erstellt nur ein rootf.avr23.ext2" und da bei mir bei der
icnova Umgebung die jffs2 Erstellung tatsächlich nicht funktionierte,
dachte ich du hättest die gleichen Probleme.
> ein jffs und ein ext2. Das ext2 verwende ich via loop device um es in> ein Verzeichnis ein zu hängen und dieses wiederum per NFS dem AVR32 zur> Verfügung zu stellen. So kann ich Dateien darin austauschen, oder eben> auf dem ADB1000 generierte Dateien zurück in den buildroot zu
So mache ich das auch, für die Entwicklung ist das echt praktisch.
> Letztendlich wird das Entwickeln einer Oberfläche nicht mein Job sein,
GUI Design ist eigentlich auch nicht mein Ding bin aber wissensbegierig
:-)
> sollte daraus ein Produkt werden. Dafür gibt es andere. Ich werde> Treiber für Sensoren schreiben, für Funk, Usb, RS422, CAN. Mist, CAN hat> er ja nicht... egal, klebe ich halt einen SJA dazu :)
Ach mit CAN habe ich sonst genug zu tun, zuhause brauch ich das nich ...
Grüße zurück,
Jens
> Müsste bei Gelegenheit mal ein Sammel-Patch für icnova->br2009.8> erstellen.
Gut, da helfe ich gerne mit, dann lerne ich was von Dir, und kann Deine
Arbeit auch gleich mit testen.
>>>> Bei Qt ist die Stelle, wo ich auf fremdem Revier wildere :)> Bin da auch noch in Einarbeitung. Momentan versuche ich aber zunächst> eine fertige Applikation zu integrieren.
Sowas in der Art wollte ich auch machen. Was fertiges nehmen und
anpassen. So habe ich alle Programmiererei gelernt. Macht man das ein
paar mal auf dem neuen Gebiet, kann man irgendwann auch alles von Anfang
an.
>>> Letztendlich wird das Entwickeln einer Oberfläche nicht mein Job sein,> GUI Design ist eigentlich auch nicht mein Ding bin aber wissensbegierig> :-)
So geht's mir auch :)
>>> sollte daraus ein Produkt werden. Dafür gibt es andere. Ich werde>> Treiber für Sensoren schreiben, für Funk, Usb, RS422, CAN. Mist, CAN hat>> er ja nicht... egal, klebe ich halt einen SJA dazu :)> Ach mit CAN habe ich sonst genug zu tun, zuhause brauch ich das nich ...
Hihi, ja aber viel von dem Zeug, dass ich auf der Arbeit nutze, kann ich
irgendwie auch für meine Basteleien verwenden und umgekehrt. Sind schon
etliche Teile meiner privaten Codesammlung in die Arbeit eingeflossen.
Dafür interessiert es auch keinen, wenn es mal umgekehrt ist.
CAN bietet sich aber für meinen selbstbau DVD fürs Auto an, wenn man
vorhandenes Display oder Lenkradfernbedienung mit verwenden möchte.
Gruß, Ulrich
mmh, als ich gestern den Kernel konfiguriert habe, fiel mir ein
Unterpunkt im linux26-menuconfig auf, der von CAN handelte. Scheinbar
wird da was unterstützt.
> CAN bietet sich aber für meinen selbstbau DVD fürs Auto an, wenn man> vorhandenes Display oder Lenkradfernbedienung mit verwenden möchte
Bist du sicher, dass es sich dabei um CAN handelt? Bei meinem BMW ist
dieser Teil, also alles was Multimedia und Comfort beinhaltet, als IBUS
ausgeführt.
Hi!
Ja, ich habe am Navi zwei CAN, Body-Control und Media-Bus. Body-Control
liefert Geschwindigkeit und vielleicht auch Lenkung / Beschleunigung.
Der Media-Bus oder Comfort-Bus steuert das im Dashboard integrierte
Display und den Satelliten auch Lenkradfernb. genannt.
Im Renault basiert das Navi auf einer modifizierten Becker Cascade
Plattform, die ich recht gut kenne. Von den Nachfolgern Becker
Indianapolis habe ich zwei Geräte. Die haben aber keinen CAN, der IBUS
wird dort für die Wechslersteuerung genutzt, die Lenkradfernbedienung
kann per serieller Schnittstelle angeschlossen werden. Da mir 120€ dafür
zu viel waren, habe ich mir selber was gebaut, das keine 10€ Material
brauchte um die Opel Lenkradfb. an das Inidi anzuschließen.
Im Renault nutzen sie den Vorgänger vom Indi, und obwohl das CD-Laufwerk
MP3 kann, wird das nicht unterstützt. Also möchte ich mir ein defektes
Gerät zulegen, es ausräumen und ein eigenes Board einsetzen. Da die
DVD-V4 Module von Philips APM/ PLDS trotz flacherem Design in den
gleichen Montageplatz passen, wie die CDM-M3 CD-Module, muss am Gehäuse
nichts geändert werden und man gewinnt unterm Laufwerk genug Platz für
ein 2.5" Platte.
Um Videodecodierung muss man sich keine Gendanken machen, das mach das
DVD-Laufwerk ebenso wie MP3/WMA. Also kann der AVR32 sich in diesem
Szenario völlig um GUI und MP3/WMA von Platte kümmern und die Platte per
WLAN Adapter zur Verfügung stellen, damit man zum Bespielen der Platte
das Auto nur in der Einfahrt parken muss.
Das ist aber die Hobby-Seite des AVR32 Projekts. Der kommerzielle
Hintergrund weiter oben ist die Überwachung von Maschinen und
IT-Schränken.
Gruß, Ulrich
Mmh, stolper gerade über ein Toolchain Problem: Sowohl bei der
gelieferten ICNOVA Distribution als auch bei buildroot 2009.11 wird bei
mir der Pfad der SDLlib nicht richtig erzeugt.
Bei mir in
/mnt/ext3data/icnova/build_avr32/staging_dir/usr/lib/libSDL.la
steht ganz am Ende:
# Directory that this library needs to be installed in:
libdir='/mnt/ext3data/icnova/build_avr32/staging_dir/usr/mnt/ext3data/ic
nova/build_avr32/staging_dir/usr/lib'
Der Pfad muss natürlich bei mir lauten :
/mnt/ext3data/icnova/build_avr32/staging_dir/usr/lib
In Folge kann ich Programme mit der cross toolchain nicht linken, die
die SDL lib benötigen ! Ein update auf die letzte SDL-lib hat nicht
geholfen, ebenso von libtool, auch die manuelle Änderung des Pfades
hilft nicht.
Tritt das Problem nur bei mir auf oder steht bei euch auch ein falscher
Pfad und hier gibt es einen echten Bug ?
Hi Leute,
hat jemand von euch schon einmal versucht den UART des AVR32 mit 1Mbps
zu betreiben und den AX-12+ Servo
(http://www.crustcrawler.com/products/bioloid/docs/AX-12.pdf) darüber
anzusteuern? Mir ist leider nicht ganz klar, welche Hardware ich dafür
zusätzlich benötige und wie das Codesegment in C aussehen müsste, um den
UART auf 1Mbps zu setzen.
Gruß,
Sven
Ulrich P. schrieb:
> Aber buildroot erstellt nur ein rootf.avr23.ext2 von 64MB. Auch ein df> gibt auf der Konsole nur 60MB für das rootfs an. Da schlummern alo noch> ein paar unerkannte MB vor sich hin.>
und ... Gast:
>256MB NAND-Flash (8-Bit)>1MB NOR-Flash (16-Bit)>• In mtdblock0 liegt der Linux-kernel>• In mtdblock1 liegt das Root-Dateisystem>• mtdblock2 ist z.Z. unbenutzt
Stolper gerade über die Größe der jeweiligen Blöcke - da mein jffs2
Image relativ groß geworden ist:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00200000 00020000 "kernel"
mtd1: 01000000 00020000 "root"
mtd2: 0ee00000 00020000 "Data"
D.h. Block1 für root ist nur 16MB groß - die restlichen rund 240 MB
liegen also in Block2 ! Darauf sollte man achten bevor man flasht.
Hi,
ich habe auch das ADB1000 in die Finger bekommen habe jedoch Probleme
mit der Toolchain.
Das mitgelieferte buildroot konnte mir zwar ein bootfähiges system
erzeugen, was ja irgendwie für die Funktionalität der compiler und
linker spricht.
Jedoch kann ich die toolchain nicht für eigenen Code benutzen. (Linker
und Compiler beschweren sich über nicht gefundene header datein uvm.)
Durch setzen von CFLAGS und LIBS Optionen (-I -L -rpath-link mit den
Pfaden ins staging_dir) konnte ich ihm zwar zum finden der header und
libs verhelfen jedoch bleibt eine Warnung und der code unausführbar.
"avr32-linux-ld: warning: cannot find entry symbol _start; defaulting to
00001074"
Vielleicht hängt das ganze mit der ubuntu version zusammen die ich
gerade benutze, ich werde es nochmal auf einem andren system versuchen..
Ich habe hier gelesen das es relativ einfach sein soll, die icnova
Komponenten auf ein aktuelleres buildroot zu Portieren. Das würde ich
gerne auch versuchen, jedoch fehlt mir Hintergrundwissen zur
Arbeitsweise von buildroot sowie zu den von icnova verwendeten patches.
Über Hilfe, Anregung oder Querverweise würde ich mich sehr freuen.
Hi!
Ich habe das Kit eine Zeit lang nicht verwendet, werde mich aber die
Tage mal wieder intensiv damit beschäftigen. Obwohl es einige Hinweise
hab, dass die damalige Buildroot Umgebung nur unter Ubuntu 8.04
funktioniert, lief sie bei mir unter 9.04 und 9.10 einwandfrei. Ich habe
vor ein paar Tagen mal auf die aktuelle LTS 10.xx aktualisiert, aber
noch nicht weiter getestet.
Werde mich melden, wenn ich was weiß.
Gruß, Ulrich
Hallo,
habe BR2010.2 für das board unter kubuntu 9.04 erfolgreich zum laufen
gebracht. Derzeit läuft hier gerade unter kubuntu 4.10 ein "make clean
&& make all" bis jetzt ohne Fehler , sieht also ganz gut aus.
Habe BR2010.2 so modifiziert, dass der gleiche Kernel+ UBOOT verwendet
wird + Patches wie die ICNOVA BR Umgebung.Musste aber 2 zusätzliche sehr
einfache Patchs hinzufügen, da es bei den Kernelsourcen mit Ubuntu 9.10
einen Namenskonflikt gab.
Mmh, müsste mal bei Gelegenheit per diff einen Patch bauen und diesen
hier posten.
Gestern ist übrigens BR2010.5 released worden, habe aber keine
Erfahrungen damit.
Hi!
Starte gerade wieder mit dem ADB1000. Um nicht alles noch mal machen zu
müssen, was Du eh schon gemacht hast, kannst Du mir das diff schicken
oder es hier anhängen? Wäre wirklich nett.
Gruß, Ulrich
Hallo Ulrich,
einen aktuelleren Kernel zu bauen, der auch funktioniert(!) ist mir
bisher leider auch nicht gelungen, meine Versuche sind also ebenso
gescheitert.
Ich habe mal irgendwo gelesen mit OpenWRT könne man eine recht aktuelle
Fassung bauen, die zumindest mit dem Grashopper funktioniert. Habe ich
aber selbst noch nicht ausprobiert.
Hi,
bin zunächst mal auf den 2010.5 buildroot zurück, direkt vom Hersteller.
Damit funktionierte es nach ein paar kleinen Korrekturen. Auch unter
ubuntu 9.10.
Muss mal sehen, ob ich das noch weiter ausdehne um die Patches aus
diesem buildroot in den Offiziellen zu übernehmen und dann auch noch für
neuere Kernel auf zu dröseln. Dazu muss ich mal erst sehen, wie viel
Zeit ich dazu finde. Deinen Patch schaue ich mir aber mal im Detail an.
Gruß, Ulrich