Grasshopper Inbetriebnahme

Wie wäre es eigentlich mit einem Artikel im Wiki zum Grasshopper? Dann 
könnte man mal so nach und nach alle bisherigen Erkenntnisse 
zusammenfassen...

@phi:

Schreibst Du den Rahmen des Wiki-Artikels? Ich setze meine Tipps usw. da 
gerne rein, nur, um das allgemeine Blah-Blah vorweg ("Der Grasshopper 
ist ein Board ...") zu schreiben habe ich keine Zeit (und keine Lust).

Ich moechte mein rootfs im uboot flashen (im linux geht nich :( )
Aber:
Load address: 0x10400000
Loading: 
#################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #######################################
done
Bytes transferred = 8192000 (7d0000 hex)
ICNova> erase 30000 800000
Erasing sector  10...Erasing sector  11...Erasing sector  12...Erasing 
sector  13...Erasing sector  14...Erasing ses
ICNova> cp.b 10400000 30000 $(filesize)
Copy to Flash... Flash write error at address 0xa0030296: 0x94ce
General Flash Programming Error
ICNova> cp.b 10400000 30000 $(filesize)
Copy to Flash... Flash write error at address 0xa00301da: 0x24a4
General Flash Programming Error

Wie kann ich das Lösen?

> Ab welcher Zeilenlänge?

Das habe ich nicht genauer ausprobiert. Bin mal mit einem ARM-Board auf 
das Problem gestossen und verwende set dem fast nur noch askenv.

Du brauchst nur Herrn Goggle nach "setenv askenv" zu fragen. Die ersten 
zwei Teffer gleich auf AVRFREAKS mit STK1000 und NGW100.

A) Problem von Numen B. kling nach dem Problem #-|
B) Eine Umschreibung meiner Einstellung dazu: Wenn ich weiss dass dass 
ich über die Landstrasse genauso schnell an meinem Ziel bin wie über die 
(freie) Autobahn auf der vor einer Stunde ein Stau gemeldet war, biege 
ich auf die Landstrasse ab. Egal ob die Autobahn 'möglicherweise' frei 
sein könnte.

Ich habe noch garnichts versucht. Ich wollte erstmal wissen, ob es 
grundsätzlich geht. Dann muß ich mich wohl mal ransetzen und versuchen, 
eine Version zu erstellen (ufff.... Linux.. da hab ichzwei linke Hände). 
Habe noch nie mit configure, automake, etc..... gearbeitet. Mit MAKE 
schon :-)

Nun ja, werde es die nächste Woche ab DO evtl. mal probieren.

Evtl. könntest Du mir Dein Image zur Verfügung stellen? Allerdings habe 
ich keinen CP2102 auf meinem Board. D.h. die Ausgaben laufen dann 
irgendwo hin. :-(

Danke erstmal.
900ss

So nun habe ich versucht, DROPBEAR in Betrieb zu nehmen.
Ich habe die Links angelegt und dann die Keys (SA,DDS) mit dropbearkey 
erzeugt.
Mit dropbearkey -f keyfile -y habe ich mir den private key ausgeben 
lassen.
Diesen habe ich dann PUTTY mitgegeben.

dropbear starte ich dann mit "dropbear -E -s". Das klappt, er meckert
auch nicht, dass er die Keyfiles nicht findet.

Wenn ich PUTTY dann starte fragt er nach Login name, ich sage 'root' und 
dann bricht putty ab mit

1

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.04.29 23:02:39 =~=~=~=~=~=~=~=~=~=~=~=

2

root

3

No supported authentication methods left to try!

Wo ist denn der Fehler? Hat jemand ein Tip?
Vielen Dank.

Kommst Du wenigstens als user "default" rein?

PS: ich weis euch nicht wie es ist, wenn kein Passwort vergeben ist, ob 
man sich da remote anmelden kann. Sollte eigentlich aus 
Sicherheitsgründen nicht zulässig sein (Ausser bei w2k, dort gings 
afaik). Zur Not kannste ja, wenn auch default nicht geht nen 
Passworthash in den Grasshopper (etc/shadow???) kopieren, bei default, 
aber beachte die Syntax.

Im Anhang ist das dropbear Start-Script vom NGW100. Da kann man 
rauslesen welche Schritte zum Start notwending sind.
Noch ein Hinweis.
/usr/sbin/dropbear, /usr/bin/dropbearconvert und /usr//bin/dropbearkey 
sind Softlinks auf /usr/sbin/dropbearmulti .

Kannst ja auch erstmal die Ports scannen, ob ssh überhaupt läuft.

Hallo Christian,
Könntest Du bitte etwas genauer beschreiben, wie Du den JTAG Programmer 
verbunden hast ?

Netterweise hab ich mir meinen Grasshopper geschossen, sodaß ich keinen 
Zugang mehr habe :-(

Gruß Sebastian

Hallo Christian,
Vielen Dank, das reicht mir an Infos, Ich habe nur die 20 Polige JTAG 
Version gefunden und war mir nicht sicher, was ich alles Verbinden muß 
...
Die Software hab ich mir schon runtergeladen und werde mal mein Glück 
versuchen.

Ich hoffe, daß ich damit meinen Hopperchen wiederbeleben kann.

Gruß Sebastian

Mal ne andere Frage: Was brauche ich eigentlich für einen Stecker für 
die externe Spannungsversorgung? Leider ist auf dem Plan mit der 
Bemaßung kein Durchmesser angeben...

Hallo,

Da mein Board wieder läuft habe ich mich ans Programmieren gemacht.

Leider muß ich feststellen, daß mein Wissen doch etwas beschränkt ist.

Als Übung wollte ich mal den Boardinternen Taster abfragen...

Und da fangen die Probleme schon an.

Ich habe das Demoprogramm etwas umgeschrieben, damit mir der Status von
Port A ausgegeben wird.
das klappt wiederum nicht, der Zugriff auf Port A wird 
verweigert(Resource Busy) es kolidiert wahrscheinlich mit den LEDs 
Treibern...

Dann habe ich den Kernel etwas geändert, so wie Christian hier 
geschrieben hat http://forum.embedded-projects.net/viewtopic.php?id=338

Beim laden der Module wird aber nichts in /dev/input eingetragen und 
mknod ergibt für mich auch keinen Sinn, wenn ich nicht weiß welche Major 
u. Minor Nummer ich eintragen muß.

Kann mir jemand einen Tip geben, wo ich mich etwas einlesen kann ?

Gruß Sebastian

Hallo Christian,

danke, zwischendurch hab ich das auch selber rausgelesen, es steht 
irgendwo in der Doku bei Input.

Wird die denn automatisch beim Laden der Treiber erstellt ?
Ich musste sie mit mknod erstellen.

Ein
ls -all /dev/input
ergibt dann

1

crw-r--r--    1 root     root      13,  64 Dec 31  2006 event0

Ich habe dann ein Miniprogramm geschrieben um es zu testen :

1

#include <linux/input.h>

2

#include <stdio.h>

3

#include <stdlib.h>

4

#include <unistd.h>

5

#include <fcntl.h>

6

#include <errno.h>

7

8

int main(void) {

9

  int fd = -1;

10

  char name[256] = "unknown";

11

  if ((fd = open("/dev/input/event0",O_RDONLY)) < 0){

12

    perror("event0 open");

13

    exit(1);

14

  }

15

  if(ioctl(fd,EVIOCGNAME(sizeof(name)),name) < 0) {

16

    perror("event0 ioctl");

17

  }

18

  printf("The device on /dev/input/event0 is %s\n",name);

19

  close(fd);

20

  return 0;

21

}

leider ergibt das folgende Ausgabe

1

event0 open: No such device

Also stimmt hier irgendwas nicht :-(

Woran könnte das liegen ?

Gruß Sebastian

P.S. Ich hoffe, ich nerve nicht mit meinen Fragen,
Ich habe zwar Linuxerfahrungen, aber so "systemnah" hab ich noch nie 
gearbeitet.

Nochwas

1

lsmod

ergibt dann

1

Module                  Size  Used by    Not tainted

2

evdev                  10496  0

3

gpio_keys               4032  0

Hallo Christian,
leider nicht,
ich hänge noch die Ausgabe in /var/log/messages nach dem Einbinden der 
Module an :

1

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio_keys' (c0854e88): kobject_add_internal: parent: 'module', set: 'module'

2

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'holders' (93d7da60): kobject_add_internal: parent: 'gpio_keys', set: '<NULL>'

3

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio_keys' (c0854e88): kobject_uevent_env

4

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio_keys' (c0854e88): fill_kobj_path: path = '/module/gpio_keys'

5

Dec 31 17:04:03 icnova user.debug kernel: bus: 'platform': add driver gpio-keys

6

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio-keys' (93d2a140): kobject_add_internal: parent: 'drivers', set: 'drivers'

7

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio-keys' (93d2a140): kobject_uevent_env

8

Dec 31 17:04:03 icnova user.debug kernel: kobject: 'gpio-keys' (93d2a140): fill_kobj_path: path = '/bus/platform/drivers/gpio-keys'

9

Dec 31 17:04:14 icnova user.debug kernel: kobject: 'evdev' (c085a748): kobject_add_internal: parent: 'module', set: 'module'

10

Dec 31 17:04:14 icnova user.debug kernel: kobject: 'holders' (93d77360): kobject_add_internal: parent: 'evdev', set: '<NULL>'

11

Dec 31 17:04:14 icnova user.debug kernel: kobject: 'evdev' (c085a748): kobject_uevent_env

12

Dec 31 17:04:14 icnova user.debug kernel: kobject: 'evdev' (c085a748): fill_kobj_path: path = '/module/evdev'

haben die Zeilen mit <NULL> was zu sagen ?

Ach so meine rootfs Datei ist die, die nach dem bauen vom Toolchain 
entstanden ist, allerdings mit der Änderung in btn.c

Gruß Sebastian

Hallo Christian,

Nein so ein Ordner habe ich nicht erstellt, es geht auch nicht ein mkdir 
erzeugt "no such file or directory" ???
Darf man da überhaupt was erstellen?
Ich dachte diese Struktur wird beim booten erzeugt ?

Naja, ich habe Event interface und GPIO Buttons fest in den Kernel 
einkompiliert und es wird scheinbar alles richtig gestartet

beim booten:

1

input: gpio-keys as /class/input/input0

in  /sys/devices/platform/ sieht es dann so aus:

1

at32_eic.0        atmel_usart.0     leds-gpio.0       pio.2

2

at32_pm.0         atmel_usart.1     macb.0            pio.3

3

at32_wdt.0        atmel_usba_udc.0  pdc.0             pio.4

4

at32ap700x_rtc.0  dmaca.0           physmap-flash.0   smc.0

5

atmel_pwm.0       gpio-keys         pio.0             systc.0

6

atmel_twi.0       intc.0            pio.1             uevent

und der Zugriff auf die erstellte /dev/input/event0 erzeugt keine Fehler 
mehr.

Hier nochmal der Ausschnitt aus /var/log/messages

1

Jan  1 01:00:02 icnova user.debug kernel: bus: 'platform': add driver gpio-keys

2

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'gpio-keys' (93d46aa0): kobject_add_internal: parent: 'drivers', set: 'drivers'

3

Jan  1 01:00:02 icnova user.debug kernel: bus: 'platform': driver_probe_device: matched device gpio-keys with driver gpio-keys

4

Jan  1 01:00:02 icnova user.debug kernel: bus: 'platform': really_probe: probing driver gpio-keys with device gpio-keys

5

Jan  1 01:00:02 icnova user.debug kernel: device: 'input0': device_add

6

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'input0' (93d59eb0): kobject_add_internal: parent: 'input', set: 'devices'

7

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'input0' (93d59eb0): kobject_uevent_env

8

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'input0' (93d59eb0): fill_kobj_path: path = '/class/input/input0'

9

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'gpio-keys' (90205598): fill_kobj_path: path = '/devices/platform/gpio-keys'

10

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'input0' (93d59eb0): fill_kobj_path: path = '/class/input/input0'

11

Jan  1 01:00:02 icnova user.info kernel: input: gpio-keys as /class/input/input0

12

Jan  1 01:00:02 icnova user.debug kernel: device: 'event0': device_add

13

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'event0' (93d5aad4): kobject_add_internal: parent: 'input0', set: 'devices'

14

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'event0' (93d5aad4): kobject_uevent_env

15

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'event0' (93d5aad4): fill_kobj_path: path = '/class/input/input0/event0'

16

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'gpio-keys' (90205598): fill_kobj_path: path = '/devices/platform/gpio-keys'

17

Jan  1 01:00:02 icnova user.debug kernel: driver: 'gpio-keys': driver_bound: bound to device 'gpio-keys'

18

Jan  1 01:00:02 icnova user.debug kernel: bus: 'platform': really_probe: bound device gpio-keys to driver gpio-keys

19

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'gpio-keys' (93d46aa0): kobject_uevent_env

20

Jan  1 01:00:02 icnova user.debug kernel: kobject: 'gpio-keys' (93d46aa0): fill_kobj_path: path = '/bus/platform/drivers/gpio-keys'

Was mit jetzt auffällt, es sind keine Zeilen mit <NULL> mehr drin ?

Es stellt sich nur die Frage, warum es bei mir mit Modulen nicht klappt 
?

Heut Abend habe ich etwas mehr Zeit, dann versuche ich endlich 
vernünftig die Taste auszuwerten.

Gruß Sebastian

>Du darfst in /sys/* natürlich keine Dateien/Verzeichnisse erzeugen,
>meine Frage war ja, ob sie schon da sind. Der Code in btn.c erzeugt z.B.
>/sys/devices/platform/gpio-keys.

Ja /*Hust*/, dann habe ich Dich falch verstanden ;-)
Hab mich schon etwas gewundert...

Es scheint aber so zu funktionieren, wenn ich cat /dev/input/event0 
ausführe
und auf die Taste drücke erscheinen im Terminal kryptische Zeichen, das 
ist schon ein "gutes Zeichen" ;-)

Andere Frage, klappt das bei Dir mir dem nachladen der Module ?

Gruß Sebastian

Die Auswertung funktioniert :-)

Im Anhang ein Programm, das je nach dem , ob innerhalb einer Sekunde die 
Taste gedrückt wurde eine 1 oder eine 0 auf der Konsole schreibt.

Jetzt muß ich das ganze nur noch sinvoll in ein Script packen, und schon 
kann man per Tastendruck den httpd starten/stopen usw.

@Christian,

>Ja, bei mir klappt das mit den Modulen.

Hmm, dann ist bei mir was nicht richtig.

Gruß Sebastian

Hallo

Ich denke jetzt bin ich mit meiner Tastenproblematik Fertig.
Und zwar hab ich das Programm so abgeändert, daß es in einer 
Endlosschleife läuft und bei jedem Tastendruck ein Program/Shellscript 
ausführt.

Im Anhang der Quellcode

Ich freue mich über weitere Anregungen/Kritik (bin leider kein Profi auf 
diesem Gebiet)

Gruß Sebastian

Hier nochmal das Kompilierte Programm für eben ausprobieren.

Es muß eine ausführbare Datei mit dem Namen button in /etc erzeugt 
werden, die bei jedem Tastendruck ausgeführt wird.

Zum probieren hab ich solch ein Script gemacht

1

#!/bin/sh

2

3

i=`cat /sys/class/leds/pwrled\:red/brightness`

4

5

if [ $i -eq 1 ]

6

then

7

`echo 0 > /sys/class/leds/pwrled\:red/brightness`

8

else

9

`echo 1 > /sys/class/leds/pwrled\:red/brightness`

10

fi

Damit läßt sich schön die Powerled toggeln.

Nochwas es müssen die Module

gpio-keys
evdev

geladen werden.

Eigentlich soll das Problemlos funktionieren, bei mir hat das leider 
nicht geklappt und ich habe die Treiber fest in den Kernel eingebunden.

Noch ein Tip :

Hat man den Hopper am Router mit Internetzugang dran kann man sich mit

/usr/sbin/rdate time.fu-berlin.de

die Systemzeit einstellen.
Leider stimmt die Zeitzone noch nicht.
Das wird erledigt, indem man

CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

in /etc/TZ

einträgt



Gruß Sebastian

Hallo,
ich habe mal ein paar Fragen zum Grasshopper:
Hat schon mal jemand den U-Boot von Christian getestet? Ich möchte 
nämlich einen neuen U-Boot ohne Bug aufspielen, falls das Linux nicht 
mehr booten sollte...
Und wie kann ich die mit 'make' erstellte AVR32 Toolchain zum 
Kompilieren eigener Programme nutzen?
Was benutzt ihr für ein Netzteil für euren Grasshopper?

Hallo gast (Gast),

ja ich nutze den U-Boot von Christian, der funktioniert problemlos, 
leider mußte ich mir dafür den minimal JTAG bauen, weil ich mir den 
ganzen Flash geschossen habe ;-)

>Und wie kann ich die mit 'make' erstellte AVR32 Toolchain zum
>Kompilieren eigener Programme nutzen?

Unter ICnova_base/build_avr32/staging_dir/bin findest Du alles was Du 
brauchst.
Ich hab mit noch das AVR32Studio installiert.

>Was benutzt ihr für ein Netzteil für euren Grasshopper?

Ich habe hier ein Steckenetzteil von der Müllkippe, achte aber darauf, 
daß Du nicht mehr als 10 V anlegst.

Gruß Sebastian

[quote]Unter ICnova_base/build_avr32/staging_dir/bin findest Du alles 
was Du
brauchst.
Ich hab mit noch das AVR32Studio installiert.[/quote]
Hast du vielleicht ein funktionierendes Makefile? Schließlich müssen ja 
auch der Pfad für die Libraries und Includes stimmen...

Nein, Makefile habe ich nicht.
Ich habe mir einfach die $PATH Variable um den Pfad zu den avr32-gcc 
erweitert und schon findet avr32Studio alles, was es braucht ;-)

Gruß Sebastian

Ich habe mir mal das AVR32 Studio für Linux heruntergeladen, aber leide 
rfindet er die nötigen Executables nicht, obwohl ich 
ICnova_base/build_avr32/staging_dir/bin zum Pfad hinzugefügt habe. In 
ICnova_base/build_avr32/staging_dir/bin sind bei mir folgende Dateien:

1

avr32-linux-addr2line               avr32-linux-uclibc-addr2line

2

avr32-linux-ar                      avr32-linux-uclibc-ar

3

avr32-linux-as                      avr32-linux-uclibc-as

4

avr32-linux-cc                      avr32-linux-uclibc-cc

5

avr32-linux-c++filt                 avr32-linux-uclibc-c++filt

6

avr32-linux-cpp                     avr32-linux-uclibc-cpp

7

avr32-linux-depmod26                avr32-linux-uclibc-gcc

8

avr32-linux-gcc                     avr32-linux-uclibc-gcc-4.0.4-atmel.0.99.0

9

avr32-linux-gcc-4.0.4-atmel.0.99.0  avr32-linux-uclibc-gccbug

10

avr32-linux-gccbug                  avr32-linux-uclibc-gcov

11

avr32-linux-gcov                    avr32-linux-uclibc-ld

12

avr32-linux-ld                      avr32-linux-uclibc-nm

13

avr32-linux-ldconfig                avr32-linux-uclibc-objcopy

14

avr32-linux-ldd                     avr32-linux-uclibc-objdump

15

avr32-linux-nm                      avr32-linux-uclibc-ranlib

16

avr32-linux-objcopy                 avr32-linux-uclibc-readelf

17

avr32-linux-objdump                 avr32-linux-uclibc-size

18

avr32-linux-ranlib                  avr32-linux-uclibc-strings

19

avr32-linux-readelf                 avr32-linux-uclibc-strip

20

avr32-linux-size                    makedevs

21

avr32-linux-strings                 mkimage

22

avr32-linux-strip

Und hier ist die Fehlermeldung vom AVR32 Studio:

1

avr32program: <not found> (Need version 3.0 or newer)

2

avr32gdbproxy: <not found> (Need version 3.0 or newer)

3

avr32-gdb: <not found> (Need version 6.7 or newer)

4

avr32-g++: <not found> (Need version 4.2 or newer)

5

avr32-gcc: <not found> (Need version 4.2 or newer)

6

avr32-as: <not found> (Need version 2.17 or newer)

7

avr32-nm: <not found> (Need version 2.17 or newer)

8

9

You are using the Linux version of the AVR32 Utilities and AVR32/GNU Toolchain.

10

11

There are multiple problems with dependent executables or path settings. Please consult the user guide for details.

12

13

The actual search path used is: /usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/mount/share/bin:/usr/sbin/:/sbin/:xxxxxx/icnova_base_cd/ICnova_base/build_avr32/staging_dir/bin/

Wo liegt das Problem? Warum findet er die Toolchain nicht?

Hallo  gast (Gast),

Christian hat recht, die Dateien, die angemeckert werden brauchst Du 
nicht.

Klicke die Fehlermeldung einfach weg, erzeuge Dir ein neues Linuxprojekt 
und schreib zum Testen ein "Hello World" Programm .

Gruß Sebastian

Danke für eure Antworten! Das Kompilieren funktioniert mit AVR32 Studio 
völlig problemlos, die fehlenden files werden anscheinend wirklich nur 
für standalone Applikationen benötigt...

Hallo,
könnte bitte jemand eine Kopie von dem U-Boot ohne Bug von Christian 
anhängen? Der Link oben (http://www.chzsoft.com.ar/storage/u-boot.bin) 
funktioniert leider nicht mehr :-(

Grasshopper mit SD-Karte funktioniert, aber nicht mit Kernel den das 
mitgelieferten Buildroot erzeugt. Das habe ich auch versucht, bin aber 
über das laden des Kernels mit dem aktualisierten U-Boot nicht 
hinausgekommen. Das Linux erkennt die SD-Karte nicht.
Also habe ich mir den aktuellen Release Cadidate vom "offizellen" Atmel 
Buildroot 2.2.0-RC4 ( http://www.atmel.no/buildroot/source/ ) 
installiert, für das NGW100 konfiguriert und dann bauen lassen. Dann im 
Verzeichnis 
buildroot-avr32-v2.2.0-rc4/project_build_avr32/atngw100/linux-2.6.25.6/a 
rch/avr32/boards/atngw100  "nur" noch die Änderungen für den Grasshopper 
eingepflegt (Ok, das ICNova Verz. aus dem ICNova Buildroot genommen und 
Änderungen für das andere Buildroot reingefummelt). Nach einem "make 
linux26-menuconfig" (ohne Änderungen, nur um den rebuild anzustoßen) 
baut man sich dann den neuen Kernel.
Da der Grasshopper nur 8MB Flash hat, habe ich das gesamte System auf 
der SD Karte liegen.

Im U-Boot

set bootcmd 'mtdparts default;chpart nor0,2;mmcinit;ext2load mmc 0:1 
0x10400000 /boot/uImage;bootm'

set bootargs 'console=ttyS0 root=/dev/mmcblk0p1 rootdelay=1 
mtdparts=physmap-flash.0:128k(boot)ro,64k(env)ro,-(root)'

Die bootargs sind so kompliziert weil das Layout des Boot-Flash beim 
Grasshopper anders ist als beim NGW100 (U-Boot:ENV:Root statt 
U-Boot:Root:ENV).

Das "neue" Board-Verzeichnis habe ich angehängt.

Ein "Diry Hack" aber es geht hervorragend.

Der wp- und detect Pin bleiben unbenutzt.

1

static struct mci_platform_data __initdata mci0_data = {

2

  .detect_pin = GPIO_PIN_NONE,

3

  .wp_pin = GPIO_PIN_NONE,

4

};

Das "alte" Buildroot und das Atmel Buildroot 2.2 verwenden verschiedene 
uClibc Versionen. Diese sind leider inkompatibel zueinander. Mit einem 
aus dem Atmel Buildroot 2.2 gebauten uImage werden die im Flash 
existierenden Programme vermutlich nicht zusammenarbeiten. darum 
benötigt man das zugehörige Root Image. Das vom Buildroot 2.2 gebaute 
Root Image enthält aber kein /usr Dateisystem, da das beim NGW100 in 
einem anderen Flashbaustein liegt den es auf dem Grasshopper nicht gibt. 
Das Umzubauen erfordert viel mehr Auswand als einfach die paar 
Anpassungen an den Konfigurationsfiles  auf der SD Karte, so wie es 
meine momentane "Lösung" macht.

P.S.
Wie man dem U-Boot die SD Karten beibringt findet ihr in
http://forum.embedded-projects.net/viewtopic.php?id=401

Hallo leute,
auch ich musste bitter dafür büßen dass ich mein grasshopper wegen der 
10V Kondensatoren zurückgeschickt hab (HTTP hat funktioniert, als ersatz 
bekam ich ein board mit dem falschn PHY ic drauf....

Da ich nicht auf in-circuit warten wollte hab ich mein board wie von 
Christian (Gast) beschrieben umgebaut:

bootscreen auszug:

1

eth0: Atmel MACB at 0xfff01800 irq 25 (00:1f:e5:00:01:29)

2

eth0: attached PHY driver [Davicom DM9161E] (mii_bus:phy_addr=0:00, irq=-1)

als ich dann zum ersten mal das LAN- kabel einsteckte erschien folgende 
Meldung:

1

$ eth0: link up (100/Full)

.... und siehe da... ich kann meinen Router anpingen freu

1

$ ping 192.168.2.1

2

PING 192.168.2.1 (192.168.2.1): 56 data bytes

3

64 bytes from 192.168.2.1: seq=0 ttl=64 time=2.6 ms

4

64 bytes from 192.168.2.1: seq=1 ttl=64 time=0.9 ms

auch ich musste die richtige mac einmalig mit U-boot setzen und mehrmals 
versuchen den saveenv befehl erfolgreich auszuführen...

Vill. hilfts dem ein oder anderen seinen mut zu sammeln und.......... 
:-)

Mit freundlichem Gruß
Mainster

Hallo!

Was muss ich machen bzw. in buildroot selektieren damit ich für die 
tslib /dev/input/event0 bekomme?

LG Max

Ich hoffe das es echt bald eine richtige Doku für den Grasshopper gibt, 
mir raucht schon der Kopf vom suchen :)

Hab derzeit das Problem das ich PortD nicht richtig ansteuern kann.

pin_mask: 0xffffffff
oe_mask: 0xffffffff

wenn ich nun in /dev mit "echo 0xfffffff > gpio0" meine angeschlossenen 
test LEDs anschalten will gehen zwar ein paar an aber nicht alle.

Oder kann man gar nicht 4Bytes gleichzeitig übergeben?

Würde mich freuen wenn mir jemand sagen kann wie ich den Kompletten Port 
auf High setzen kann :)

LG Benedict

Nach langem rumprobieren hab ich es geschafft die Pins anzusteuern, aber 
nur mithilfe eines C Programmes.

Was mich wundert, der zugriff mit C Streamfunktionen funktioniert 
einwandfrei. Mit C++ Streamfunktionen hab ich es allderings nicht 
hinbekommen.

Im Anhang befindet sich mein Code, vllt kann mir jemand sagen warum es 
nicht funktioniert.

LG Benedict

AH vielleicht ist mein Problem auch hier besser?!
Ich hab wegen dem Touchcontroller die atmel_spi.c und atmel_spi.h im 
Linux-Driver Ordner ersetzt. Leider habe ich jetzt folgenden Fehler beim 
kompilieren. :(

1

drivers/spi/atmel_spi.c: In function 'atmel_spi_probe':

2

drivers/spi/atmel_spi.c:768: error: 'struct spi_master' has no member named 'mode_bits'

3

make[3]: *** [drivers/spi/atmel_spi.o] Fehler 1

4

make[2]: *** [drivers/spi] Fehler 2

5

make[1]: *** [drivers] Fehler

siehe: Beitrag "AVR32 grasshopper patch für ATMEL buildroot 2.3.0"

einmal posten reicht auch.....