AP7000 und ICnova ADB1000: Bisschen wenig?

[Ulrich P. (uprinz)]

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

[... (Gast)]

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.

[Ulrich P. (uprinz)]

Hi!

Klar, dachte ich auch... aber:

BusyBox v1.5.0 (2008-11-24 13:52:40 CET) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# mplayer
-sh: mplayer: not found
# find / -name mplayer
#

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

[... (Gast)]

> Sound? Keine Ahnung ob das ADB1000 einen Videocodec drauf hat

Sorry, sollte natürlich Audiocodec heißen...

[... (Gast)]

> unter Ubuntu

Welches? Du solltest 8.04 nehmen, bei den höheren Versionen gibt es 
Probleme.

[chris (Gast)]

>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?

[Ulrich P. (uprinz)]

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

[chris (Gast)]

>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.

[... (Gast)]

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.

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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:

File transfer via NFS from server 192.168.10.106; our IP address is 192.168.10.80
Filename '/home/ulrich/ICnova/binaries/oemplus/uImage'.
Load address: 0x10400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #########################*** ERROR: Cannot umount
## Booting kernel from Legacy Image at 10400000 ...
   Image Name:   Linux-2.6.28.4
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)
   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....

usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
port 1 high speed
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
cpufreq: AT32AP CPU frequency driver
usb 1-1: new high speed USB device using isp176x and address 2
atmel_mci atmel_mci.0: Atmel MCI controller at 0xfff02400 irq 28, 1 slots
port 1 high speed
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
Sending DHCP requests .<6>eth0: link up (100/Full)
..<7>eth0: no IPv6 routers present
... timed out!
IP-Config: Retrying forever (NFS root)...
ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending DHCP requests ...... timed out!
IP-Config: Retrying forever (NFS root)...
ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending DHCP requests ...... timed out!
IP-Config: Retrying forever (NFS root)...
eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
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

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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 !

[Jens K. (irimi)]

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 ;-)

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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:

ICnova>  printenv
baudrate=115200
ethact=macb0
ethaddr=00:1F:E5:00:0D:5F
ipaddr=192.168.10.80
bootcmdold=mtdparts default; nand read 0x10400000 nand0,0; bootm
bootdelay=3
serverip=192.168.10.106
prjpath=/home/uprinz/ICnova/binaries
bootip=192.168.10.80::192.168.10.106:::eth0:off
bootargs=root=/dev/nfs nfsroot=$(serverip):$(prjpath)/rootfs ip=$(bootip)
bootfile=uImage
bootcmd=run tftpboot
tftpboot=tftpboot $(serverip):$(bootfile);bootm
stdin=serial
stdout=serial
stderr=serial

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:

U-Boot 2009.03-rc1-00001-gab9d96f-dirty (Mär 12 2009 - 11:19:51)

U-Boot code: 00000000 -> 00014950  data: 0001c4f0 -> 00053c28
malloc: Using memory from 0x13f6c000 to 0x13fac000
DMA: Using memory from 0x13f68000 to 0x13f6c000
Flash:  1 MB at address 0x00000000
DRAM Configuration:
Bank #0: 10000000 64 MB
256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   macb0
Press SPACE to abort autoboot in 3 seconds
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0x45e1)
Using macb0 device
TFTP from server 192.168.10.106; our IP address is 192.168.10.80
Filename 'uImage'.
Load address: 0x10400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #########################
done
Bytes transferred = 1459010 (164342 hex)
## Booting kernel from Legacy Image at 10400000 ...
   Image Name:   Linux-2.6.28.4
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)
   Data Size:    1458946 Bytes =  1.4 MB
   Load Address: 10000000
   Entry Point:  90000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel at 90000000 (params at 13f6c008)...

Linux version 2.6.28.4 (uprinz@delli) (gcc version 4.2.2-atmel.1.1.3.avr32linux.1) #1 Fri Oct 30 01:37:24 CET 2009
CPU: AT32AP700x chip revision C
CPU: AP7 [01] core revision 0 (AVR32B arch revision 1)
CPU: MMU configuration: Shared TLB
CPU: features: dsp simd ocd perfctr java
CPU: Running at 140.000 MHz
Physical memory:

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...

Sending DHCP requests .<6>eth0: link up (100/Full)
..<7>eth0: no IPv6 routers present
... timed out!
IP-Config: Retrying forever (NFS root)...
eth0: link down
ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending DHCP requests ...... timed out!

Hier startet jemand IPv6 statt IPv4...

Die Jagd geht weiter :)

Gruß, Ulrich

[... (Gast)]

IPv6 in der Kernelconfig ausschalten?
make linux26-menuconfig
make

[Ulrich P. (uprinz)]

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:

bootargs=root=nfs nfsroot=$(serverip):$(prjpath)/rootfs ip=$(ipaddr):$(serverip)::$(netmask)::eth0:none

Damit bootet er kein IPv6 und auch kein DHCP, aber er nimmt

IP-Config: Unable to set interface netmask (-22).
Looking up port of RPC 100003/2 on 157.0.0.0
eth0: link up (100/Full)

 als EInstellungen... Da stimmt also noch was nicht.

Ich schaus mir heute Abend noch mal an.

Gruß, Ulrich

[Ulrich P. (uprinz)]

Und wieder was gelernt :)

Natürlich kann man bootargs nicht aus Platzhaltern zusammen setzen:

root=nfs nfsroot=$(serverip):$(prjpath)/rootfs ip=$(ipaddr):$(serverip)::$(netmask)::eth0:off

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:

usb 1-1.1: configuration #1 chosen from 1 choice
input:   USB Keyboard as /class/input/input1
generic-usb 0003:1241:1503.0001: input: USB HID v1.10 Keyboard [  USB Keyboard] on usb-isp176x.0-1.1/input0
input:   USB Keyboard as /class/input/input2
generic-usb 0003:1241:1503.0002: input: USB HID v1.10 Device [  USB Keyboard] on usb-isp176x.0-1.1/input1
IP-Config: Complete:
     device=eth0, addr=192.168.10.80, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.10.80, domain=, nis-domain=(none),
     bootserver=192.168.10.106, rootserver=192.168.10.106, rootpath=
Looking up port of RPC 100003/2 on 192.168.10.106
eth0: link up (100/Full)
Looking up port of RPC 100005/1 on 192.168.10.106
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 80K (90000000 - 90014000)
Populating /dev using udev: done
Starting portmap: done
Initializing random number generator... done.
Starting Network Interface Plugging Daemon: eth0.
Starting network time protocol daemon: ntpd.
Starting httpd

nfs: server 192.168.10.106 not responding, still trying
nfs: server 192.168.10.106 not responding, still trying
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

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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

[... (Gast)]

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.

[... (Gast)]

achso, für Sound musst du auch noch den alsamixer installieren.
Hier hat einer ein breakoutboard für einen AT73c213.
Beitrag "Re: grashopper avr32 pwm Kanäle als Audio out?"

[Ulrich P. (uprinz)]

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

[Psykoman (Gast)]

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ß

[... (Gast)]

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.

[Ulrich P. (uprinz)]

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

[Psykoman (Gast)]

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ß

[Ulrich P. (uprinz)]

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:

$>find . -name avr32-linux-gcc
./build_avr32/staging_dir/usr/bin/avr32-linux-gcc

Also haben wir den schon mal...

mkdir test
cd test
touch hello.c

Mit einem Editor Deiner Wahl hello.c mit etwas Code befüllen:

#include <stdio.h>

int main( void)
{
  printf("hello world!\n");
  return 0;
}

Nun compilieren und aufs Target copieren:

..//build_avr32/staging_dir/usr/bin/avr32-linux-gcc hello.c -o hello
cp hello ../binaries/rootfs/usr/bin

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.

#>hello
Hello World!
#>

Fein! Nun habe ich mal, ganz nach Docu des buildroot, den 
avr32-linux-gcc in den Pfad mit aufgenommen:

$>PATH=$PATH:/home/uprinz/ICnova/build_avr32/staging_dir/usr/bin/
$>export PATH

Nun bin ich mal in mein ser2net Verzeichnis gewechselt und habe das neu 
kompiliert:

$>cd ~/avr32test/ser2net-2.6
$>make clean
...
$>./configure --host=avr32-linux
...
$>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

[Ulrich P. (uprinz)]

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

[chris (Gast)]

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?

[Ulrich P. (uprinz)]

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

[... (Gast)]

> 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.

[chris (Gast)]

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?

[Ulrich P. (uprinz)]

> 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

[... (Gast)]

> 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.

[... (Gast)]

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.

[... (Gast)]

Hier eine fertige Demo.

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

... 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....

[Ulrich P. (uprinz)]

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

[... (Gast)]

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.

[... (Gast)]

unter /package/qtopia4/qtopia4.mk editieren:

.....
    -fast \
    -no-rpath \
#    -nomake examples \
#    -nomake demos \
  )
  touch $@
.....

dann make
Damit sollte buildroot auch die demos bauen. Vorher aber die 
Grafikformate aktivieren.

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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...

[... (Gast)]

menuconfig ist im übrigen sehr unübersichtlich. Installiere dir 
"xconfig"

[... (Gast)]

die Farbtiefe kannst du im menuconfig unterhalb von QT ändern.

[Ulrich P. (uprinz)]

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 :)

[... (Gast)]

ja, und andere tauchen erst auf, wenn auch die Treiber für die Hardware 
aktiviert wurden.

[... (Gast)]

> ob die demos des qt übersetzt wurden.
wenn sie übersetzt wurden, dann findest du unter /demos bzw. /examples 
ausführbare Dateien.

[Ulrich P. (uprinz)]

Mal Grundsätzlich...
Ich muss doch für die Verwendung von qt auf dem fb keinen xserver 
starten, oder?

Eine Einstellung der bpp finde ich nicht.

[... (Gast)]

sowas z.B.
Hatte ich gerade übersetzen lassen von buildroot.

[Ulrich P. (uprinz)]

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....

[... (Gast)]

> 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

[Ulrich P. (uprinz)]

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 :)

[... (Gast)]

in /build_avr32/qt-embedded-linux-opensource-src-4.4.3 die Dateien 
.configured und alle .xxx die nach statusmerker klingen löschen, dann 
wieder make

[... (Gast)]

> solidFill_setup(): Screen depth 24 not supported!

also wieder der Farbtiefenfehler, ich denke, da noch mal im menuconfig 
s.o. schauen

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

Ok, da hatte openssh ein problem, also kann ich nun doch wieder 
einsteigen.
Mal sehen ob ein make jetzt noch funktioniert, oder ob's knallt.

[... (Gast)]

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.

[... (Gast)]

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. ;)

[Ulrich P. (uprinz)]

Du machst das öfters, oder?

[Ulrich P. (uprinz)]

Bei mir lief, trotz aller Warnungen, das ganze unter Ubuntu 9.04
Wie viel weiter oben schon gesagt, ist sogar der Kernel einmal neu 
gebaut.

[... (Gast)]

kann sein, dass die die Probleme beseitigt haben, als ich es vor einem 
Jahr aufgesetzt habe, lief es nicht.

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

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.

[... (Gast)]

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

[Ulrich P. (uprinz)]

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!

[... (Gast)]

was mir noch einfällt, welche Farbtiefe hat dein System??
Stell mal QT auf static library und  -depth 24,16,8 und bau es nochmal 
neu.

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

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

[chris (Gast)]

>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 ...

[Ulrich P. (uprinz)]

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 :)

[Ulrich P. (uprinz)]

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.

[... (Gast)]

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 
\

[... (Gast)]

ups..
vergessen und im demos.pro file das gleiche.---> demos_textedit \  in
# demos_textedit \

[Psykoman (Gast)]

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ß

[Axel R. (Gast)]

!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.

[Ulrich P. (uprinz)]

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!

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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!

[Udo S. (udo)]

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.

[Ulrich P. (uprinz)]

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...

[Udo S. (udo)]

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.

[Udo S. (udo)]

bei mir sieht das im menuconfig so aus: siehe Anhang

[Ulrich P. (uprinz)]

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

[Udo S. (udo)]

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.

[Udo S. (udo)]

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.

[Udo S. (udo)]

hier noch das Datenblatt vom ET050000DH6 Display. Auch ein 24bit 
Display.

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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

[Udo S. (udo)]

wie gesagt, mach doch mal einen screenprint von der depth einstellung im 
menuconfig.Die scheint ja anders zu sein als bei mir.

[Ulrich P. (uprinz)]

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

[Udo S. (udo)]

> 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

[Udo S. (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

[Udo S. (udo)]

zu deiner Frage auf avrfreaks bezüglich QTcreator:
Du kannst bei QTcreator unter Tools/Options/QT4 den Pfad zu qmake 
einstellen.

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

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

# ls
images     interview  styledemo
# ./styledemo -qws
solidFill_setup(): Screen depth 24 not supported!
Aborted

Also wie immer. Nun gut, versuchen wir mal was anderes:

# fbset -match
# export
export DMALLOC_OPTIONS='debug=0x34f47d83,inter=100,log=logfile'
export EDITOR='/bin/vi'
export HISTFILESIZE='1000'
export HISTSIZE='1000'
export HOME='/root'
export HOSTNAME='ADB1000'
export INPUTRC='/etc/inputrc'
export LOGNAME='root'
export OLDPWD='/root'
export PAGER='/bin/more '
export PATH='/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/bin'
export PS1='# '
export PWD='/usr/examples'
export SHELL='/bin/sh'
export TERM='vt100'
export USER='root'
# fbset -fb /dev/fb0

mode "320x240-60"
    # D: 6.363 MHz, H: 15.596 kHz, V: 59.525 Hz
    geometry 320 240 320 240 24
    timings 157158 34 20 9 4 34 9
    hsync high
    vsync high
    rgba 8/0,8/8,8/16,0/0
endmode
# ./styledemo -qws
solidFill_setup(): Screen depth 24 not supported!
Aborted

Auch nix, also weiter mit weniger bpp:

# fbset -depth 16
# ./styledemo -qws
solidFill_setup(): Screen depth 15 not supported!
Aborted

Auch nix, aber manchmal ist weniger eben mehr:

# fbset -depth 8
# ./styledemo -qws
# ./interview -qws

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....

[Udo S. (udo)]

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.

[Udo S. (udo)]

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.

[Ulrich P. (uprinz)]

Nein, Tslib fehlte... Kommt gerade rein :)

[Ulrich P. (uprinz)]

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...

[Ulrich P. (uprinz)]

Das ist alles nicht besonders groß, icnova hat das aber gegenüber atmel 
beim STK1000 auf mehr Dateien verteilt... Hängt einfach mal alles an.

[Ulrich P. (uprinz)]

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.

[Udo S. (udo)]

was ist denn in dem letzten Ordner?......./boards/icnova

[Ulrich P. (uprinz)]

?? 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:

TFTP from server 192.168.10.106; our IP address is 192.168.10.80
Filename 'uImage'.
Load address: 0x10400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####
done
Bytes transferred = 1355535 (14af0f hex)
## Booting kernel from Legacy Image at 10400000 ...
   Image Name:   Linux-2.6.28.4
   Image Type:   AVR32 Linux Kernel Image (gzip compressed)
   Data Size:    1355471 Bytes =  1.3 MB
   Load Address: 10000000
   Entry Point:  90000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel at 90000000 (params at 13f6c008)...

Linux version 2.6.28.4 (uprinz@delli) (gcc version 4.2.2-atmel.1.1.3.avr32linux.1) #3 Wed Nov 4 00:29:11 CET 2009
CPU: AT32AP700x chip revision C
CPU: AP7 [01] core revision 0 (AVR32B arch revision 1)
CPU: MMU configuration: Shared TLB
CPU: features: dsp simd ocd perfctr java
CPU: Running at 140.000 MHz
Physical memory:
  10000000-13ffffff
Reserved memory:
  10000000-10181b11: Kernel code
  10181b12-1023cdb7: Kernel data
Exception vectors start at 90014000
CPU: Paging enabled
Node 0: start_pfn = 0x10000, low = 0x14000
Node 0: mem_map starts at 9023f000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
Kernel command line: root=nfs nfsroot=192.168.10.106:/home/uprinz/ICnova/binaries/rootfs ip=192.168.10.80:192.168.10.106::255.255.255.0::eth0:none
PID hash table entries: 256 (order: 8, 1024 bytes)
avr32_comparator: irq 0, 140.000 MHz
Console: colour dummy device 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62608k/62672k available (1462k kernel code, 2864k reserved, 146k data, 80k init)
Calibrating delay using timer specific routine.. 282.94 BogoMIPS (lpj=470313)
Mount-cache hash table entries: 512
net_namespace: 296 bytes
smc smc.0: Atmel Static Memory Controller at 0xfff03400
NET: Registered protocol family 16
pdc pdc.0: Atmel Peripheral DMA Controller enabled
at32_eic at32_eic.0: External Interrupt Controller at 0xfff00100, IRQ 19
at32_eic at32_eic.0: Handling 4 external IRQs, starting with IRQ 64
AVR32 AP Power Management enabled
ICnova: 5 Leds
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
ICnova: registering NAND-Devices
registring isp176x
audit: initializing netlink socket (disabled)
type=2000 audit(1167609600.397:1): initialized
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 122
alg: hash: Chunking test 1 failed for md5-generic
00000000: 55 15 45 ef 07 a8 00 e7 38 09 0b 01 7c 85 a3 36
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler cfq registered (default)
atmel_lcdfb atmel_lcdfb.0: 225KiB frame buffer at 13980000 (mapped at b3980000)
Console: switching to colour frame buffer device 40x30
atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0xff000000 (mapped at ff000000), irq 1
atmel_usart.0: ttyS0 at MMIO 0xffe00c00 (irq = 6) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xffe01000 (irq = 7) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xffe01400 (irq = 8) is a ATMEL_SERIAL
atmel_usart.3: ttyS3 at MMIO 0xffe01800 (irq = 9) is a ATMEL_SERIAL
nbd: registered device at major 43
eth0 (macb): not using net_device_ops yet
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfff01800 irq 25 (00:1f:e5:00:0d:5f)
eth0: attached PHY driver [Davicom DM9161A] (mii_bus:phy_addr=0:00, irq=67)
NAND device: Manufacturer ID: 0x20, Chip ID: 0xda (ST Micro NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 3 MTD partitions on "atmel_nand":
0x00000000-0x00200000 : "kernel"
0x00200000-0x01200000 : "root"
0x01200000-0x10000000 : "Data"
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xffe00000 (irq 3)
isp176x isp176x.0: NXP ISP1760 USB Host Controller
isp176x isp176x.0: new USB bus registered, assigned bus number 1
isp176x isp176x.0: bus width: 32, oc: digital
isp176x isp176x.0: irq 64, io mem 0x04000000
isp176x isp176x.0: USB ISP 1761 HW rev. 1 started
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver libusual
ads7846 spi0.2: touchscreen, irq 144
input: ADS784x Touchscreen as /class/input/input0
at32_wdt at32_wdt.0: AT32AP700X WDT at 0xfff000b0, timeout 2 sec (nowayout=0)
leds-gpio: probe of leds-gpio.0 failed with error -16
dw_dmac.0: DesignWare DMA Controller, 3 channels
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
port 1 high speed
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
cpufreq: AT32AP CPU frequency driver
usb 1-1: new high speed USB device using isp176x and address 2
atmel_mci atmel_mci.0: Atmel MCI controller at 0xfff02400 irq 28, 1 slots
port 1 high speed
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address b368
mmcblk0: mmc0:b368 UD    970 MiB
 mmcblk0:<7>device: '1-1': device_add
 p1
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
usb 1-1.1: new low speed USB device using isp176x and address 3
usb 1-1.1: configuration #1 chosen from 1 choice
input:   USB Keyboard as /class/input/input1
generic-usb 0003:1241:1503.0001: input: USB HID v1.10 Keyboard [  USB Keyboard] on usb-isp176x.0-1.1/input0
input:   USB Keyboard as /class/input/input2
generic-usb 0003:1241:1503.0002: input: USB HID v1.10 Device [  USB Keyboard] on usb-isp176x.0-1.1/input1
IP-Config: Complete:
     device=eth0, addr=192.168.10.80, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.10.80, domain=, nis-domain=(none),
     bootserver=192.168.10.106, rootserver=192.168.10.106, rootpath=
Looking up port of RPC 100003/2 on 192.168.10.106
eth0: link up (100/Full)
Looking up port of RPC 100005/1 on 192.168.10.106
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 80K (90000000 - 90014000)
Populating /dev using udev: done
Starting portmap: done
Initializing random number generator... done.
Starting system message bus: done
Starting network time protocol daemon: ntpd.
Starting httpd
Starting sshd: OK
Starting telnetd
Starting network management services: snmpd.
Starting NFS statd: done
Starting NFS services: done
Starting NFS daemon: Installing knfsd (copyright (C) 1996 [e-mail]).
done
Starting NFS mountd: done

Welcome to Astralix AP7000
ADB1000 login: root

BusyBox v1.13.2 (2009-11-01 23:53:23 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Bei den LEDs gibt es ein Problem mit den Ports, aber der SPI ist aktiv. 
Naja, er funktioniert ja auch beim lite-demo.

[Udo S. (udo)]

> 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?

[Udo S. (udo)]

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.

[Ulrich P. (uprinz)]

Habe mal mit den ts_* herum gespielt:

# ls -l /usr/bin/ts_test
-rwxr-xr-x    1 root     root        12624 Nov  4  2009 /usr/bin/ts_test
# ts_test /dev/input/event0
/dev/touchscreen/ucb1x00: No such file or directory

Das sieht doof aus, aber wenn ich nun folgendes mache:

# ts_finddev /dev/input/event1 10
Probe device /dev/input/event1, Please Touch Screen Anywhere in 10 seconds! ...

# ts_finddev /dev/input/event0 10
Probe device /dev/input/event0, Please Touch Screen Anywhere in 10 seconds! ...

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:

export PWD='/usr/examples'
export QWS_MOUSE_PROTO='Tslib:/dev/input/event0'
export SHELL='/bin/sh'

[Udo S. (udo)]

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.

[Udo S. (udo)]

kopier dir mal die Dateien in dein /usr/bin/ Ordner.

[Woody P. (woody)]

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:
>

> # ts_finddev /dev/input/event1 10
> Probe device /dev/input/event1, Please Touch Screen Anywhere in 10
> seconds! ...
> 
> # ts_finddev /dev/input/event0 10
> Probe device /dev/input/event0, Please Touch Screen Anywhere in 10
> seconds! ...
>

> 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

# ts_test 
tslib: Unknown event type 0
1167610157.433086:    169    127   1342
1167610157.438374:    167    125   1342
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:
>

> export PWD='/usr/examples'
> export QWS_MOUSE_PROTO='Tslib:/dev/input/event0'
> export SHELL='/bin/sh'
>

Ich habe in /etc/profile eingetragen

export TSLIB_TSDEVICE='/dev/input/event0'
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_CONSOLEDEVICE=none
export TSLIB_CONFFILE=/etc/ts.conf
export QWS_MOUSE_PROTO='Tslib:/dev/input/event0'

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.

Package Selection for the target  --->
  Graphic libraries and applications (graphic/text)  --->  
    Mouse drivers  --->


[*] tslib

Package Selection for the target  --->
  Graphic libraries and applications (graphic/text)  --->  
    Graphics drivers  ---> 

[*] Linux Framebuffer
[*] Transformed
[*] Qt Virtual Framebuffer
[ ] VNC
[ ] multiscreen

Es müsste Linux Framebuffer reichen. Transformed wird benötigt um den 
Bildschirm zu drehen.

[Ulrich P. (uprinz)]

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.

[Woody P. (woody)]

fbset -i liefert bei mir

# fbset -i

mode "320x240-60"
    # D: 6.363 MHz, H: 15.596 kHz, V: 59.525 Hz
    geometry 320 240 320 240 24
    timings 157158 34 20 9 4 34 9
    hsync high
    vsync high
    rgba 8/0,8/8,8/16,0/0
endmode

Frame buffer device information:
    Name        : 
    Address     : 0x13980000
    Size        : 230400
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 0
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 960
    MMIO Address: 0xff000000
    MMIO Size   : 4096
    Accelerator : No

also 24 Bit Farbtiefe

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

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.

[Ulrich P. (uprinz)]

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
>
>

> # ts_test
> tslib: Unknown event type 0
> 1167610157.433086:    169    127   1342
> 1167610157.438374:    167    125   1342
> 1167610157.438374:    167    124   1342
>

>
> 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
>
>

> export TSLIB_TSDEVICE='/dev/input/event0'
> export TSLIB_FBDEVICE=/dev/fb0
> export TSLIB_CONSOLEDEVICE=none
> export TSLIB_CONFFILE=/etc/ts.conf
> export QWS_MOUSE_PROTO='Tslib:/dev/input/event0'
>

>
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.
>
>

> Package Selection for the target  --->
>   Graphic libraries and applications (graphic/text)  --->
>     Mouse drivers  --->
> 
> 
> [*] tslib
>

Habe da auch noch den qvfb, aber das sollte ja nicht stören. Touch geht 
ja, nur Qt mag ihn nicht.

>
>

> Package Selection for the target  --->
>   Graphic libraries and applications (graphic/text)  --->
>     Graphics drivers  --->
> 
> [*] Linux Framebuffer
> [*] Transformed
> [*] Qt Virtual Framebuffer
> [ ] VNC
> [ ] multiscreen
>

>
> 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 :)

[Woody P. (woody)]

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

Package Selection for the target  --->
  Graphic libraries and applications (graphic/text)  --->  
    Pixel depths  ---> 

*** Deselecting each option leads to Qt's default (8,16,32) ***  
[ ] All supported depths
[ ]   1 bpp, black/white     
[ ]   4 bpp, grayscale      
[*]   8 bpp, paletted 
[ ]   12 bpp, rgb 4-4-4  
[ ]   15 bpp, rgb 5-5-5   
[*]   16 bpp, rgb 5-6-5  
[*]   18 bpp, rgb 6-6-6
[*]   24 bpp, rgb 8-8-8
[*]   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.

[Ulrich P. (uprinz)]

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 :)

[Ulrich P. (uprinz)]

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...

[Ulrich P. (uprinz)]

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 :)

[Udo S. (udo)]

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.

[Ulrich P. (uprinz)]

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 :)

[Udo S. (udo)]

liste mal dein Verzeichnis /dev/input/

[Ulrich P. (uprinz)]

# ll /dev/input/
crw-r--r--    1 root     root      13,  64 Dec 31 17:00 event0
crw-r--r--    1 root     root      13,  65 Dec 31 17:00 event1
crw-r--r--    1 root     root      13,  66 Dec 31 17:00 event2
crw-r--r--    1 root     root      13,  67 Dec 31 17:38 event3

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.

[Udo S. (udo)]

du könntest mit cat /dev/input/inputx |hexdump mal schauen welcher input 
auf die Mouse anspricht.

[Ulrich P. (uprinz)]

event3 reagiert wild und entschlossen :)
(1115 Pakete werden installiert, 29% abgeschlossen....Uff!)

buildroot kompiliert noch fleißig an Qt 4.5.1 herum

[Udo S. (udo)]

export QWS_MOUSE_PROTO='/dev/input/event3'
mal versuchen?

[Ulrich P. (uprinz)]

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 :)

[Udo S. (udo)]

lol,
Gute Nacht, ich bin auch weg.

[Ulrich P. (uprinz)]

Ja, gute Nacht, Morgen gehts dann mit Qt 4.5.1 weiter.
Das Ubunut Update hat gewonnen. Ist fertig. Buildroot ist noch 
fleißig...

Gruß, Ulrich

[Ulrich P. (uprinz)]

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.

[Woody P. (woody)]

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

-nomake examples
-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.

[Ulrich P. (uprinz)]

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

[Ulrich P. (uprinz)]

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:

### Configure display & touch for use with Qt
export TSLIB_TSDEVICE='/dev/input/event0'
export TSLIB_FBDEVICE='/dev/fb0'
export TSLIB_CONSOLEDEVICE='none'
export TSLIB_CONFFILE='/etc/ts.conf'
export TSLIB_CALIBFILE='/etc/pointercal'
export QWS_MOUSE_PROTO='tslib:/dev/input/event0'
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.

[Ulrich P. (uprinz)]

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

[... (Gast)]

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

[Udo S. (udo)]

Und hast du das Problem mit QTcreator gelöst?

[Ulrich P. (uprinz)]

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

[... (Gast)]

ich packe immer alles auf die SD-Karte und boote von da.

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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.

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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

[Ulrich P. (uprinz)]

> 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

[... (Gast)]

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.

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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 ?

[Sven A. (psykoman)]

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

[Jens K. (irimi)]

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.

[Jens K. (irimi)]

Jens K. schrieb:
> gelieferten ICNOVA Distribution als auch bei buildroot 2009.11 wird bei
> mir der Pfad der SDLlib nicht richtig erzeugt.
>
>
> Tritt das Problem nur bei mir auf oder steht bei euch auch ein falscher
> Pfad und hier gibt es einen echten Bug ?

Ein Bug ! Ein Patch der Abhilfe schaft ist zu finden unter
http://armadeus.git.sourceforge.net/git/gitweb.cgi?p=armadeus/armadeus;a=blob;f=patches/buildroot/078-sdl-correct_libdir_path_in_libSDL.la.patch;h=c455834241d222b72865032c333c83630bd571b0;hb=HEAD

[Henry B. (henry_b)]

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.

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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.

[Ulrich P. (uprinz)]

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

[Jens K. (irimi)]

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.

[Ulrich P. (uprinz)]

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