Hallo Forum,
angeblich (laut http://www.embedded-projects.net/index.php?page_id=237)
soll der Hopper als Netzwerkkarte per USB eingebunden werden. Dies ist
aber nicht der Fall, es wird lediglich eine USB-USART erkannt:
Mar 29 22:45:58 quark kernel: usb 1-4: Manufacturer: Silicon Labs
Mar 29 22:45:58 quark kernel: usb 1-4: SerialNumber: 0001
Mar 29 22:45:58 quark kernel: usb 1-4: configuration #1 chosen from 1
choice
Mar 29 22:45:58 quark kernel: cp2101 1-4:1.0: cp2101 converter detected
Mar 29 22:45:58 quark kernel: usb 1-4: reset full speed USB device using
ohci_hcd and address 3
Ans Netzwerk angesteckt bekomme ich leider ebenfalls keine Verbindung,
stecke ich ihn ein, ist die Link-LED am Switch nicht aktiv.
Wunderbar... wie soll ich das Teil jetzt in Betrieb nehmen? Sind diese
Probleme bekannt?
Gruss,
Michael
Na toll... so ein sch... Teil. Vollkommen unbrauchbar irgendwie. Doku
gibt es auch keine. Naja dann schick ich es halt so wie es ist wieder
zurueck und fertig. Der Schaltplan ist auch unlesbar erstmal, weil das
PDF nicht standardkonform ist und Schriftarten fehlen. Auf der Homepage
vom Hersteller auch null, nichts. Total enttaeuscht von dem Teil.
Schreib halt erstmal ne mail an den Hersteller !
Wollte mir das Teil demnächst auch holen und um ein Farb_LCD
erweitern, um mal n bischen was mit HMI unter uC-Linux zu machen.
Naja an den Hersteller brauch ich nicht schreiben, das kannst vergessen.
Das is ne reine Werbehomepage ohne jegliche Produktinfo. Und aus dem
shop ist das Teil heute entfernt worden, da wirst es nicht mehr
bestellen koennen, sofern es nicht wieder reingenommen wird. Irgendwie
glaub ich nicht so recht an nen Zufall. Im Moment sieht mir das nach ner
Fehlkonstruktion aus.
Deine Probleme damit und die Tatsache, dass es heute aus
dem Shop genommen wurde, lässt nichts gutes ahnen.
So ein Mist, das Board hätte mir voll in den Kram gepasst.
Naja werd ich mir halt doch n Super-H8 Board von Glyn holen müssen ;)
http://shop.embedded-projects.net/index.php?cat=c8_Grasshopper.html
Koennt ja nen Versehen sein der Link im Menue ist noch drinnen aber es
heisst nur "product not found". Naja es gab Probleme mit dem Hersteller
wegen nem fehlerhaften Kondensator, da wurde erstmal nen Rueckruf
gestartet. Benedikt war offensichtlich auch nicht gluecklich mit der
Abwicklung, weil die sich nicht an das Abgemachte gehalten haben.
Naja immo is das Teil halt fuer mich nicht nutzbar. Mir haette es ja
auch in den Kram geasst, Embedded Linux fuer den Preis is doch super.
Nur funktionieren sollte es halt auch noch. Das Prob is ohne Doku kann
ich auch nicht wirklich nachvollziehen wo das Problem liegt. Das Teil
blinkt nach ner gewissen Zeit zyklisch, das koennte jetzt anzeigen dass
es bereit ist aber auch ein Fehlerzustand sein. Ich kann das jetzt
erraten, wunderbar.
Aber selbst wenn das kein Fehler ist, wird das Teil nicht als
Netzwerkkarte erkannt, wie behauptet. Und daran wird auch die
Softwarekonfiguration nichts aendern, weil offensichtlich nicht die
USB-Engine der MCU verwendet wurde sondern ein externer Baustein.
Also das zyklische blinken heißt das es läuft.....bei mir läuft es
einwanderfrei....ich nehme stark an das du nur eine falsche SW Version
drauf hast....schreibe Benedikt Sauter, dann wirst Du schon Hilfe
bekommen...
Was heisst das, wie hast Du das Teil dann in Betrieb genommen? Und was
heisst hier falsche Software-Version, kannst vielleicht mal etwas
genauer werden? Mit solchen Aussagen kann ich in etwa genausoviel
anfangen wie mit der nicht vorhandenen Dokumentation.
Also ein erster guter Ansatz wäre mal ein Screenshot vom RS232 Output.
Hast Du schonmal probiert den zu bekommen? Müssten nur einen
Pegelwandler an RX und TX anschließen und dann an den
PC.....funktioniert auch....
Die LED'S blinken genauso wie bei mir......
Hm hm... naja dazu muss ich erst nen Adapter bauen. Und ich find das is
reichlich ueberfluessig wenn das Ding nicht out of the box funktioniert.
Und die Behauptung, es wuerde sich als Netzwerkkarte identifizieren per
USB ist schlicht und ergreifend falsch. Mich kotzt es einfach nur an
dass das Projekt offensichtlich ueberhaupt nicht dokumentiert wurde bzw.
diese Dokumentation nirgendwo veroeffentlich wurde. Sendet das Ding die
boot-messages per RS232 oder wie seh ich das?
Naja ich denk ich schick das Ding wieder zurueck das is mir echt zu
bloede. Mich hier vorraten.
In punkto Doku kannst du dich aber an die eigene Nase fassen, gewöhnlich
recherchiert man über ein Produkt bevor man es kauft und da sollte so
etwas auffallen. Schade ists trotzdem ...
Ja da liegt wohl noch einiges im Argen...
Ich hatte einen der ersten Grasshopper bekommen und an meinen Router
angeschlossen. Das Teil bekommt eine IP zugeteilt und über die kann ich
mit Telnet drauf zugreifen (jedenfalls nachdem Benedikt die erste
Kurzanleitung veröffentlicht hat, in der der Benutzername 'default'
genannt wurde).
Mit einiger Mühe ist es mir auch gelungen Dateien ins Flash zu bekommen.
Dazu muss auf einem externen Rechner ein FTP-Server installiert werden.
Mit wget lässt sich dann vom Grasshopper aus auf den Server zugreifen.
Aber wie transportiere ich Dateien in die andere Richtung?
Unter Windows an USB angeschlossen, sucht Windows einen Treiber für ein
'RNDIS/Ethernet Gadget'. So einen Treiber konnte ich zwar finden, aber
Windows meldet einen Fehler bei der Installation (Code 10).
Durch die Austausch-Aktion habe ich jetzt eine zweite Platine bekommen,
auf der ist im Gegensatz zur ersten die USB-Bridge CP2101 bestückt! Da
gibts dann keine Netzwerk-Funktion sondern nur RS232.
Das lässt sich aber prinzipiell durch Umlöten zweier winziger
Widerstände ändern.
Das Problem mit dem zu kleine Eingangsspannungsbereich wurde durch
weglassen eines Kondensators gelöst...
Die Toolchain, die veröffentlicht wurde, scheint so nur unter OpenSuSe
10.3 zu laufen. Ich habe es unter ubuntu versucht, da lässt sie sich
nicht übersetzen. Immerhin kann ich unter SuSe Programme für den
Grasshopper übersetzen, auf den FTP-Server schieben und dann zum Board
übertragen. Von Telnet aus starten und siehe da er sagt 'Hello World'.
Auch ein einfacher HTTP-Client lief so auf Anhieb.
Der Kernel wurde auch übersetzt, aber wie bekomme ich den auf das Board?
Dazu muss man ihn wohl auf einen SFTP-Server legen, von dem es sich der
Bootloader holen kann. Den Bootloader muss man über die serielle
Schnittstelle bedienen. Auf dem Board ohne CP2101 braucht man einen
Pegelwandler, mein selbstgebauter USB-Seriellwandler hatte aber Probleme
mit 115200Bps. Das ist jetzt auf dem zweiten Board kein Problem, da man
hier ja einen brauchbaren Wandler hat.
Das Uboot (der Bootloader) meldet beim ersten Board übrigens nur 8MB
SDRAM, beim zweiten 64MB. Das scheint ein Fehler im Bootloader zu sein.
Aber wie tauscht man den eigentlich aus?
Leider sind diverse Portleitungen nicht herausgeführt, das betrifft auch
die DA-Wandler Schnittstelle. Sonst hätte ich jetzt ein Webradio
gebaut...
Ich sehe gerade, auf
http://www.embedded-projects.net/index.php?page_id=237
hat Benedikt seine Anleitung erweitert, aber eine echte Dokumentation
gibt es immer noch nicht.
Im Moment kann man einem Embedded-Linux Neuling wohl wirklich noch nicht
zu diesem Board raten, es gibt noch viel zu erforschen und zu lernen.
Wer davor keine Angst hat, der bekommt hier aber ein nettes kleines
Board mit vielen Möglichkeiten.
Uwe
Uwe Nagel wrote:
> Ja da liegt wohl noch einiges im Argen...> Ich hatte einen der ersten Grasshopper bekommen und an meinen Router> angeschlossen. Das Teil bekommt eine IP zugeteilt und über die kann ich> mit Telnet drauf zugreifen (jedenfalls nachdem Benedikt die erste> Kurzanleitung veröffentlicht hat, in der der Benutzername 'default'> genannt wurde).
Mit anderen Worten heisst das ich darf mir jetzt extra fuer das Ding
einen SMTP-Server aufsetzen in der Hoffnung, dass das dann funktioniert.
Was es wahrscheinlich nicht tut ohne dass ein Link zustande kommt.
> Mit einiger Mühe ist es mir auch gelungen Dateien ins Flash zu bekommen.> Dazu muss auf einem externen Rechner ein FTP-Server installiert werden.> Mit wget lässt sich dann vom Grasshopper aus auf den Server zugreifen.> Aber wie transportiere ich Dateien in die andere Richtung?
HTTP-Server oder etwas in der Richtung laufen lassen.
> Unter Windows an USB angeschlossen, sucht Windows einen Treiber für ein> 'RNDIS/Ethernet Gadget'. So einen Treiber konnte ich zwar finden, aber> Windows meldet einen Fehler bei der Installation (Code 10).> Durch die Austausch-Aktion habe ich jetzt eine zweite Platine bekommen,> auf der ist im Gegensatz zur ersten die USB-Bridge CP2101 bestückt! Da> gibts dann keine Netzwerk-Funktion sondern nur RS232.
Wunderbar, da liegt also der Hase im Pfeffer...
> Das lässt sich aber prinzipiell durch Umlöten zweier winziger> Widerstände ändern.
Mit hellseherischen Faehigkeiten haette man das vielleicht sogar wissen
koennen, jetzt weiss ich es aber immernoch nicht.
> Das Problem mit dem zu kleine Eingangsspannungsbereich wurde durch> weglassen eines Kondensators gelöst...> Die Toolchain, die veröffentlicht wurde, scheint so nur unter OpenSuSe> 10.3 zu laufen. Ich habe es unter ubuntu versucht, da lässt sie sich> nicht übersetzen.
Ich kann das System uebersetzen aber nicht uebertragen, weil dazu ein
Kommando und was weiss ich fuer Hardware fehlt. Sehr hilfreich.
> Immerhin kann ich unter SuSe Programme für den> Grasshopper übersetzen, auf den FTP-Server schieben und dann zum Board> übertragen. Von Telnet aus starten und siehe da er sagt 'Hello World'.> Auch ein einfacher HTTP-Client lief so auf Anhieb.
Immerhin, wenn's denn mal laufen wuerde.
> Der Kernel wurde auch übersetzt, aber wie bekomme ich den auf das Board?> Dazu muss man ihn wohl auf einen SFTP-Server legen, von dem es sich der> Bootloader holen kann. Den Bootloader muss man über die serielle> Schnittstelle bedienen. Auf dem Board ohne CP2101 braucht man einen> Pegelwandler, mein selbstgebauter USB-Seriellwandler hatte aber Probleme> mit 115200Bps. Das ist jetzt auf dem zweiten Board kein Problem, da man> hier ja einen brauchbaren Wandler hat.
OK, das werde ich wohl mal ausprobieren.
> Das Uboot (der Bootloader) meldet beim ersten Board übrigens nur 8MB> SDRAM, beim zweiten 64MB. Das scheint ein Fehler im Bootloader zu sein.> Aber wie tauscht man den eigentlich aus?
Muss ich mir alles erstmal ansehen...
> Leider sind diverse Portleitungen nicht herausgeführt, das betrifft auch> die DA-Wandler Schnittstelle. Sonst hätte ich jetzt ein Webradio> gebaut...> Ich sehe gerade, auf> http://www.embedded-projects.net/index.php?page_id=237> hat Benedikt seine Anleitung erweitert, aber eine echte Dokumentation> gibt es immer noch nicht.> Im Moment kann man einem Embedded-Linux Neuling wohl wirklich noch nicht> zu diesem Board raten, es gibt noch viel zu erforschen und zu lernen.> Wer davor keine Angst hat, der bekommt hier aber ein nettes kleines> Board mit vielen Möglichkeiten.
Hat er aufgrund meiner Mails. Vielleicht sollte sich jemand erbarmen, ne
Doku zu schreiben... ich unterhalt mich mal mit Benedikt.
>> Uwe
Der Hinweis, sich mit nem Terminalprogramm auf den virtuellen seriellen
Port zu verbinden das kam mir gestern schon in den Sinn, da es ja nahe
liegt, leider hab ich mit Minicom nix rausbekommen. Jetzt versuch ich
das mal mit kermit. Hoffentlich mach ich dann bisschen Fortschritte ;)
Juhu ich bin drauf auf dem Teil. Ich sehe jedoch dass das
Netzwerk-Interface down ist. Deswegen bekommt es wohl auch keinen Link.
Einen Versuch, das hochzubekommen ist schonmal gescheitert (ifconfig
eth0 up). Aber wenigstens kann ich jetzt mal anfangen hier.
Ziemlich cool das Teil. Die "gewohnte" Busybox-Umgebung. Tolle Sache,
sogar wget ist mal standardmaeszig mit drauf, das musste ich auf meinem
N810 erstmal compilieren.
Ok das Netzwerkinterface scheint macb0 zu heissen ;) Aber ich loet jetzt
erstmal die Stiftleisten ein hehe. Jetzt ist der Frust verflogen. Aber
gestern ging halt echt garnix.
Hm OK also das Netzwerk scheint nicht richtig konfiguriert zu sein, kein
Modul, kein Device, keine Aktionen im syslog beim Anstecken. Werde da
mal weiterforschen.
Den Bootmeldungen entnehme ich:
eth0: Atmel MACB at 0xfff01800 irq 25 (00:00:00:00:00:00)
eth0: attached PHY driver [Davicom DM9161E] (mii_bus:phy_addr=0:00,
irq=-1)
Sowie
$ cat /proc/interrupts
CPU0
25: 0 intc eth0
An sich ist also alles da, allerdings bekomme ich das Device immernoch
nicht hoch:
$ ifconfig eth0 192.168.0.42 up
ifconfig: SIOCSIFFLAGS: Invalid argument
Hm... mal sehen wo da das Problem liegt.
Hatte ich bei meinem ATNGW100 auch ... da ist keine gültige MAC-Adresse
eingetragen: "(00:00:00:00:00:00)", das kannst du im U-Boot zwar machen,
aber dazu müsstest du rausfinden welche dem Board offiziell zugeteilt
sind.
Ich muss jetzt aber los :(
Christian Erker
Die MAC-Adresse, die das Board offiziell haben soll, steht auf einem
Aufkleber auf der Rückseite der Platine.
Aber diese Meldung zeigt mein Board auch, trotzdem hat es eine gültige
MAC. Auch das Protokoll auf Benedikts Seite zeigt diese Meldung.
Eventuell ist das nur so, wenn kein Netzwerkkabel angeschlossen ist.
Wie hast Du dein Board mit dem Netz verbunden? Bei mir hängt es an der
FritzBox und erhält seine IP via DHCP. Wenn du es mit einem gekreuzten
Netzwerkkabel direkt mit dem PC verbindest, muss der einen DHCP-Server
haben, oder Du musst die IP verwenden, die vom Hersteller fest
vorgegeben ist. Aber welche ist das? Die stand bis Gestern auf der Seite
von Benedikt Sauter....
Uwe
So wie ich sehe, lebt dieses Projekt von der Mitarbeit der User.
Vielleicht sollte jemand, der das Board erfolgreich in Betrieb genommen
hat, einfach mal ein Tutorial schreiben und Benedikt zur Verfügung
stellen.
Also, nachdem es dann ja doch einigermaßen zu funktionieren scheint ohne
dabei
um 10 Ecken gehen zu müssen werd ich mir das Board heute auch noch
bestellen.
Wär glaub wirklich interessant und sinnvoll nen Sammelthread dazu
aufzumachen
und diesen im Forum fest zu nageln.
Das Board ist wieder im shop ;) War wohl doch ein Versehen.
Ich konnte gestern nicht mehr weiterforschen, werd mir das aber heute
nochmal ansehen. Es hat nichts damit zu tun, ob eine Verbindung gesteckt
wird, zumal ich das natuerlich ebenfalls ausprobiert habe. DHCP kann
auch nicht funktionieren, ohne dass erst einmal das device oben ist,
demnach liegt das Problem wohl an einer falschen Konfiguration des
Treibers. Das Interface ist auch nicht bereit so dass beim Einstecken
erst garkein Link zustande kommt. Werde an dieser Stelle weiterforschen.
Die fehlerhafte MAC ist ein guter Ansatzpunkt, mal sehen ob das bei mir
dann was bringt, die einzutragen.
Ansonsten funktioniert die Sache eigentlich schonmal ganz gut, die
Entwicklungsumgebung hab ich auch schon einmal erfolgreich
durchcompiliert, so zum Test. Ist aber keine chroot-Umgebung, wie man es
erwartet haette. Ich war halt auch verwirrt von den Angaben dass sich
das Teil als Netzwerkkarte identifizieren sollte, was uebrigens
zumindest intern noch vorgesehen ist: es gibt ein usb0
Netzwerk-Interface mit besagter IP. Mit der neuen (gefixten) Version des
Boards ist dies aber nicht mehr der Fall, zumindest nicht out of the
box.
Was die Doku angeht: Ich denke ich werde einen zusammenfassenden Text
erstellen und diesen dann auf meiner Homepage zur Verfuegung stellen.
Entsprechende Fallstricke werd ich dort dann auch ansprechen und
entsprechende Hinweise fuer den Einstieg geben. Programmierbeispiele
folgen dann wahrscheinlich spaeter.
Gruss,
Michael
Wenn ich den Schaltplan richtig verstehe (habe mein Board noch nicht),
kann man durch Umlöten zweier Null-Ohm-Brücken auswählen, ob sich das
Board am USB-Anschluss als serielle Schnittstelle oder als Netzwerkkarte
melden soll.
Die Variante mit der seriellen Schnittstelle ist vermutlich sinnvoller,
weil man so ohne großen Aufwand an die Bootmeldungen und vor allem an
den Bootloader (U-Boot) herankommt.
Mit letzterem sollte sich übrigens relativ einfach ein neues Root-FS
flashen lassen, falls man das möchte. Mangels eigenem Board (wie
gesagt), konnte ich das bisher nicht ausprobieren.
Komisch , bei mir is der CP2101 gar nicht bestückt( Zum Glück ;-) )!!
Vielleicht weil ich eins der ersten Boards habe und mich der Umtausch
Aktion "entzogen" habe. Das mit dem Ethernet MAC (macb0) kann ein Bug im
Atmel Ethernet Mac Treiber sein.
Habe ein ähnliches Problem mit einem AT91???9260EK Board, da hilft es in
der Kernel Config den Davicom PHY abzuwählen und im MAC Menu den
"Generic PHY Support" anzuwählen.
Vielleicht wäre es gut wenn wir Grasshopper User das Wiki auf Berlios
anfangen würden zu befüllen?
http://developer.berlios.de/projects/grasshopper/
Würde auf jedenfall Neueinsteigern evtl. einiges erleichtern.
Zwei Foren mit gestückelten Infos, teilweise in Kommentaren zu anderen
Themen versteckt, sind doch etwas unübersichtlich.
Um die Gerüchteküche etwas zu entkräften:
Habe mit Benedikt vor ein paar Tagen über die Verfügbarkeit der
Grasshopper Boards gesprochen. Er meinte die werden noch sehr lange über
seinen Shop zu beziehen sein.
Christian wrote:
> Wenn ich den Schaltplan richtig verstehe (habe mein Board noch nicht),> kann man durch Umlöten zweier Null-Ohm-Brücken auswählen, ob sich das> Board am USB-Anschluss als serielle Schnittstelle oder als Netzwerkkarte> melden soll.
Der Schaltplan ist leider unter SUSE nicht lesbar. Benedikt hat eine
"Alternativersion" online gestellt, die aber genau das selbe Problem
hat.
Claude, danke fuer den Hinweis. Ich hoffe aber ich muss nicht das ganze
Ding dazu neu flashen ;) Aber schonmal gut zu wissen dass das im
Ernstfall ueber den Bootloader funktioniert.
Die Sache ist: Es ist nicht standardkonform, externe Schriftarten zu
verwenden mit nem PDF, sprich der Generator ist Mist. Waere die Font
eingebettet koennte man sie stets anzeigen, das ist ja eben der Sinn von
PDF, hier keine Ansprueche an die Umgebung zu stellen. Ausserdem sind
das sicherlich Schriftarten, die man so aus Lizenzgruenden nicht
mitliefern darf. Aber nun gut das ist mal nen anderes Problem.
>Ausserdem sind das sicherlich Schriftarten, die man so aus Lizenzgruenden >nicht
mitliefern darf.
Die Core-Fonts sind von MicroSoft für die Verbreitung freigegeben.
>Waere die Font eingebettet koennte man sie stets anzeigen
Eingebettete Fonts würden aber jedes Dokument aufblähen und sind somit
auch nicht optimal. Ich mag mich irren, aber ich denke die gewöhnlichen
PostScript-Schriften wie Helvetica brauchen nicht eingebettet werden, da
jeder PDF-Viewer bzw. PostScript-Drucker sie zur Verfügung hat.
Ja aber das ist kein Standardfont.
**** Warning: Fonts with Subtype = /TrueType should be embedded.
But Verdana is not embedded.
**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> [ClibPDF Library 2.01-r2-7] Windows 9x/NT <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
Ich schrieb doch bereits:
>Ja, wäre schon besser gewesen, wenn sie eine andere Schrift verwendet>hätten.
Pluspunkte bekommen die Hersteller für das Verwenden von Verdana von mir
ganz sicher nicht.
Zurueck zum Netzwerkproblem:
ICNova> bdinfo
boot_params = 0x13FA5008
memstart = 0x10000000
memsize = 0x04000000
flashstart = 0x00000000
flashsize = 0x00800000
flashoffset = 0x000159E8
ethaddr = 00:FE:83:F5:00:FE
ip_addr = 0.0.0.0
baudrate = 115200 bps
ethaddr stimmt schonmal nicht mit der MAC-Adresse auf dem Aufkleber
ueberein.
Den Versuch, dhcp auszufuehren:
ICNova> dhcp
macb0: Starting autonegotiation...
macb0: Autonegotiation timed out (status=0x7809)
macb0: link down (status: 0x7809)
Wenn man das Device mit setenv auf eth0 setzt, wird es durch "dhcp"
wieder auf macb0 zurueckgesetzt. Naja wie schon gesagt das Teil bekommt
keinen Link, da stimmt irgendwas nicht. Beim Reset ist das Teil aber
anscheinend mal kurz da, zumindest blinkt die Link-LED kurz. Jetzt
braeuchte man evt. mal den Schaltplan, den ich nicht lesen kann.
Das mit macb0 ist schon ok. Kannst ja mal im Linux unter /proc/network ,
/proc/devices und /proc/interrupts schauen ob alle gut ausschaut. Nimm
mal in /etc/network/interfaces die Zeilen mit macb0 raus, dann machen
die if.up und if.down skripte nix mehr mit dem Interface und du kannst
alles mit ifconfig kontrollieren. Wird eigentlich beim ifconfig eine
hwaddr. angezeigt?
Ups da war ich zu schnell! Bei meinem (eigenen) Kernel heist er macb0 ..
bei dir mit dem Orginal Kernel wahrscheinlich eth0. Aber versuch mal das
mit /etc/network/interfaces ... das hat mich schon ein paar mal gelinkt
Es existiert nicht und damit auch nicht in /proc/devices.
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfff01800 irq 25 (00:00:00:00:00:00)
eth0: attached PHY driver [Davicom DM9161E] (mii_bus:phy_addr=0:00,
irq=-1)
das scheint aber wohl schlicht und ergreifend falsch konfiguriert zu
sein. Das Lustige ist, dass es nen Interrupt gibt:
root@icnova:/home/default> cat /proc/interrupts
25: 0 intc eth0
@linuxgeek
Das ist wirklich komisch. Hattest Du ein Netzwerk Kabel gesteckt als Du
den Output oben kopiert hast? -> Interrupt Count von 0 ist sehr
verdächtig...
Wenn Du einen usbprog oder jtagice mk2 hast kann ich dir mal einen
Kernel von mir schicken.
Claude wrote:
> @linuxgeek> Das ist wirklich komisch. Hattest Du ein Netzwerk Kabel gesteckt als Du> den Output oben kopiert hast? -> Interrupt Count von 0 ist sehr> verdächtig...> Wenn Du einen usbprog oder jtagice mk2 hast kann ich dir mal einen> Kernel von mir schicken.
Claude, ich habe einen jtagice mk2 hier und das Flash bei dem
Grasshopper zerschossen :-( Könntest Du mir einen U-Boot und ein
Linuximage (jffs2) schicken? Man das wäre super :-) Bin noch nicht in
der Lage, mir soetwas
selber zu kompilieren. Muß noch üben :-)
bastler (at) quantentunnel (punkt) de
Danke schön.
Michael G. wrote:
> Na toll das Speichern mit "saveenv" funktioniert leider auch nicht:>> ICNova> saveenv> Saving Environment to Flash...> Un-Protected 1 sectors> Erasing Flash...Erasing sector 9...Erased 1 sectors> Writing to Flash... Flash write error at address 0xa0020002: 0x74dc> General Flash Programming Error> Protected 1 sectors
Vielleicht hilft Dir das:
Beitrag "Re: Grasshopper-toolchain probleme"
Ich hab's jetzt geschafft das device manuell zu konfigurieren, mit der
in "bdinfo" erkannten MAC aber auch mit der aufgedruckten:
root@icnova:/home/default> ifconfig
eth0 Link encap:Ethernet HWaddr 00:1F:E5:00:01:0A
inet addr:192.168.0.42 Bcast:192.168.0.255
Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:25 Base address:0x1800
Das dumme is nur, dass es leider trotzdem nicht funktioniert, ich
bekomme keinen Link :(
Hier das gleiche Problem. Kein Link.
Das scheint ein anderer PHY drauf zu sein.
Aber ich kann den Hersteller nicht erkennen.
Wird auch schon von U-Boot nicht aktiviert wenn ich mit tft booten will.
Mein Internetanschluss läuft über einen NGW100 als Router.
Prinzipiell gehts also ;-)
Aber immer wieder das gleiche. Es wird ein anderes Bauteil als
vorgesehen eingesetzt. Ist zwar Pinkompatibel, aber an die Folgen denkt
keiner.
Wie z.B. der 10V Kondensator (war sicher billiger als der ursprünglich
Vorgesehene). So treiben die Pfennigfuchser die Kosten hoch :-((
Das deckt sich zumindest mit den Kernel messages:
eth0: attached PHY driver [Davicom DM9161E] (mii_bus:phy_addr=0:00,
irq=-1)
Im Schaltplan ist das Bauteil als DM9161A ausgewiesen.
Oh das ist aber mal k*cke! Der DM9161E hat ein anderes Pinout als der
DM9161A. Der Pin 39 ist beim A ein Input (DISMDX) und beim E ein
Versorgungsspannungs Pin (DVDD). Kannst Du mal die Spannung am Pin39 /
R24 messen? Hab ihn in Deinem jpeg mal rot gekennzeichnet.
Na das gibt dann wohl die nächste Umtauschaktion...
Ich habe meinen umgetauschten noch garnicht ans Netz gehängt, nur über
USB angesprochen. Am Netz geht der neue auch nicht. Und der hat auch
einen DM9161E.
Welchen schicke ich nun zurück?
Naja einen TQFP von einem Multilayer zu Pflücken ist
nicht jedermans sache.
Und notfalls reicht es aus R24 mit 0 Ohm zu bestücken.
So langsam wird mir die ganze sache auch unwohl. Das mit der Toolchain /
Docu ist ja noch Ok nach meinem geschmack .Habe da schon schlimmeres bei
10 bis 20 fach teureren Starterkits erlebt -> u.a. großer Hersteller von
Prozessoren aus Finnland wenn man als einer der ersten so ein Starterkit
bekommt (welche auch mal HW Fehler hatten).
Würde aber erst mal auf eine Antwort vom Hersteller / Benedikt Sauter
warten.
Die müssten das mit Davicom direkt regeln, kann ja gut sein daß das Die
in beiden Chips das gleiche ist und der DISMDX eben in der neuren
Revision des Bausteins als VDD gekennzeichnt worden ist. Hab ich auch
schon erlebt.
Der DM9161E ist die ÄLTERE Revision, der DM9161A die neuere (mit Auto
MDI-X). Mit R24 = 0 Ohm sollten beide garantiert funktionieren: Der
ältere bekommt Vdd und der neuere einen logischen High-Pegel an Pin 39.
Ich bin mir aber nicht sicher, ob es wirklich (nur) daran liegt.
Vielleicht versucht einer von den betroffenen mal, Benedikt zu
kontaktieren.
Hm... :/ Na das is ja mal wieder super. Aber immerhin haben wir jetzt
eine potentielle Fehlerquelle entlarvt. Werde heute abend mal messen und
sehen, ob sich der Fehler so beheben laesst. Man muss schon sagen dass
es dann zumindest eine neue Revision geben wird, weil das Teil ja so
erstmal nicht funktioniert. Das mit der Versorgungsspannung toent
plausibel, denn das wuerde die strikte Nicht-Funktion erklaeren und
auch, dass keine MAC erkannt wird. Werde mir auch mal die Datenblaetter
beider Chips ziehen und mit dem Schaltplan vergleichen. Sowas wird man
dann wohl mit etwas rework hinbekommen. Der Chip kostet immerhin
7EUR+Versand, also bestimmt an die 15EUR um es zu bestellen und dann
loetet man mal so nen QFP aus so einer dichten Schaltung aus, ok das
geht schon, aber nen Zustand als Produkt ist das ja nicht wirklich.
Was mir stinkt ist: Sowas haette man gemerkt wenn man mal einen einzigen
kleinen Funktionstest gemacht haette.
Michael
Naja, komplett funktionslos kann der PHY-Chip nicht sein, immerhin wird
seine ID erkannt, sonst würde kaum die korrekte Bezeichnung angezeigt
werden. Daher bin ich mir nicht sicher, ob das mit dem Pin 39 wirklich
die (einzige) Ursache ist.
Datenblätter für die PHY-ICs gibt es übrigens unter
http://www.davicom.com.tw/eng/download/datasheet.htm
Das kurze Aufblitzen der Link-LED, von Du schriebst, ist nur die Meldung
des ICs, dass er gerade resettet wurde.
Die Flash-Fehlermeldung bei "setenv" ist auch rätselhaft. Wenn das
angezeigte tatsächlich der Status wäre, dann würde das lt. Datenblatt
bedeuten, dass Vpp zu niedrig zum Programmieren war. Das kann aber lt.
Schaltplan nicht sein, denn dort ist Vpp mit 3.3V verbunden. Das reicht
aus. Oder wurde etwa auch ein anderer Flash-IC (kein AT49BV642D)
verbaut?
Hat denn schon jemand Benedikt oder die In-Circuit GmbH angemailt?
Christian, immer noch ohne eigenes Board
Die Flash-Fehlermeldung bei "setenv".
Vor dem "saveenv" ein "protect off all" und danach ein "protect on all".
Das dies nicht automatisch geschieht scheint ein Bug im U-Boot zu sein.
Ich hab im Schaltplan mal geschaut gestern: Der LINK/ACTIVE Pin ist mit
der gruenen LED der Ethernet-Buchse verbunden, welche immer leuchtet.
Ein Link am Router kommt jedoch nicht zustande. Aufgeblitzt hat die
Orange LED lediglich mal kurz. Fakt ist aber auch, das der Chip nicht
funktioniert, da nicht ein einziger Interrupt verzeichnet wird und auch
das auslesen der MAC offensichtlich fehlschlaegt. Vielleicht ist der
VDD-Pin der Pin fuer eine weitere Funktionseinheit, so dass der Chip
halt "teilweise" funktioniert.
Das mit dem flashen koennte u.U. am Schreibschutz liegen, jedoch
funktioniert die Benutzung von "protect" am Bootprompt nicht so
wirklich, da kommt nur ein wenig aussagender Hilfetext (Werner danke
fuer den Hinweis). Das war aber mal nicht mein Hauptproblem, ich werde
aber auch hier mal die Typenbezeichnung vom Flash checken. Hat sich da
der Bestuecker entsprechende Freihheiten geleistet?
Christian, dass Du noch kein Board hast gereicht Dir immo nicht wirklich
zuum Nachteil ;)
Ich sehe, es gibt noch weitere Unterschiede zwischen dem DM9161(E) und
dem DM9161A, nämlich die Pins RXEN vs. LEDMODE (31) und SD vs. nichts
(45). Pin 31 sollte keine Probleme machen, da logisch high. Zur Funktion
von Pin 45 muss ich mir nachher das Datenblatt genauer durchlesen.
Ah ja, zur grünen LED. Da sie gegen +3.3V geschaltet ist, leuchtet sie,
wenn der entsprechende Pin des PHY-ICs low ist, also genau dann wenn (ja
nach Konfiguration) KEIN Kabel bzw. KEIN Link erkannt wurde.
Naja da laesst sicher aber jetzt schon recht sicher der falsche Chip als
Fehlerursache ausmachen, VDD und RXEN hoeren sich nach kritischen Pins
an. Jetzt ist nur die Frage: Haben die eventuell die Schaltung
ueberarbeitet deswegen? Sieht zwar nicht so aus, aber wenn wir jetzt
auch noch mit nem nicht mehr aktuellem Schaltplan arbeiten dann gute
Nacht.
OK das mit der LINK-LED ist dann klar, wenn auch unsinnig, hier die
Logik zu verdrehen.
Naja, der Fall von LEDMODE bzw. RXEN ist es allerdings unkritisch,
selbst wenn man die Schaltung nicht ändert. Logisch high ist für beide
Varianten des Chips eine gute Wahl: Beim DM9161E ist dann der Receiver
eingeschaltet, beim DM9161A sind dann Single-Color LEDs ausgewählt.
Die Logik der Link-LED ist auch nur beim DM9161E vertauscht, beim
DM9161A wäre sie richtig, so wie ich das dem Datenblatt entnehme.
Ein Statement vom Hersteller wäre jetzt hilfreich.
OK das spricht fuer die These dass die Schaltung offensichtlich nicht
angepasst wurde. Was wir also tun sollten sind mal die beiden Pins zu
messen und ggfs. dafuer Sorge zu tragen, dass die Versorgungsspannung
korrekt anliegt. Wenn das keine Abhilfe schafft ist es zu ueberlegen,
den Chip vielleicht durch die korrekte Fassung auszutauschen. Benedikt
sollte man wohl mal auf die Problematik aufmerksam machen, denn der hat
dann ja mit weiteren Beschwerden/Ruecklaeufen zu leben. Kann nur gerade
nicht mailen weil mein Server down ist.
Michael
Ich habe unterdessen mal im Grasshopper-Forum gepostet: Wenn dort jemand
mit einem DM9161E auf dem Board das Netzwerk erfolgreich zum Laufen
bekommen hat, dann muss der Fehler wo anders liegen.
Das ist wahr aber derartige Bestrebungen hab ich gestern schon gemacht
weil ich nicht von einem Hardwareproblem ausgegangen bin. Gut eine
Restwahrscheinlichkeit, dass es doch an der SW liegt besteht natuerlich
noch.
Hast Du eigentlich eine Möglichkeit, das Board mal an einem Port zu
testen, der nur 10MBit/s kann? Ich hatte mal den Fall, dass ein Gerät,
obwohl eigentlich 100MBit/s-fähig, nicht am 100MBit/s-Port eines Routers
arbeiten wollte, weil irgendwas mit der Auto-Negotiation schief lief.
Nein ich habe keinen solchen Port, aber ich fuerchte die Zeit, wo man
sowas hat, ist nun wirklich vorbei (Standard bei den meisten Boards ist
schon lange das Gigabit-Ethernet). Ich weiss sowas macht gerne Probleme,
allerdings wirst Du keinen reinen 10MBit-Switch mehr bekommen und ich
habe auch keine 10MBit-Karten mehr im Einsatz fuer einen Crosslink, weil
das nichtmal mehr fuer mein DSL ausreicht. Aber wenn das jemand testen
kann, nur zu.
Wenn Dir mal langweilig sein sollte ;-), kannst Du ja versuchen, das
Register 17 des PHY-ICs auszulesen. Diesem Register sollte u.a. zu
entnehmen sein, ob überhaupt eine Auto-Negotiation versucht wurde.
Anhand der Datenblätter und des Sourcecodes in drivers/net/macb.c bin
ich zu der Meinung gekommen, dass folgende Kommandosequenz in U-Boot
dazu geeignet sein müsste (alle Zahlenangaben ab jetzt hexadezimal):
Zunächst musst Du den "Management Port" einschalten. Dazu musst Du Bit
Nr. 4 im NCR setzen. Du liest also das Register aus, ver-oder-st es mit
10 und schreibst es zurück:
md.l fff01800 1
xxxxxxxx = angezeigter Wert OR 0x10
mw.l fff01800 xxxxxxxx
Dann teilst über das MAN Du mit, dass Du Register 0x11 lesen möchtest:
mw.l fff01834 60460000
Du überprüfst, dass der Vorgang erfolgreich durchgeführt wurde. Dazu
muss im NSR das Bit Nr. 2 gesetzt sein, was Du überprüfen kannst mit:
md.l fff01808 1
Schließlich liest Du das Resultat aus:
md.l fff01834 1
Die unteren 16 (dezimal) Bit enthalten das Register 17 (dezimal) des
PHY-ICs. Alle Angaben ohne Gewähr.
Claude wrote:
> Oh das ist aber mal k*cke! Der DM9161E hat ein anderes Pinout als der> DM9161A. Der Pin 39 ist beim A ein Input (DISMDX) und beim E ein> Versorgungsspannungs Pin (DVDD). Kannst Du mal die Spannung am Pin39 /> R24 messen? Hab ihn in Deinem jpeg mal rot gekennzeichnet.
Ganz offensichtlich ein LOW!
(falsch gemessen)
Also da liegen 3V3 an, das entspricht auch der Schematik, jedoch ist R24
hier 0 Ohm. Man moechte vermuten das ist Absicht so.... scheisse
allerdings dann scheidet das ja als Problemquelle aus :(
Dann Tipp ich wirklich mal auf den Bug im Atmel macb Treiber (habe ich
oben mal beschrieben). Die MAC Einheit des AP7000 ist identisch mit der
des AT91SAM9260 und da hatte ich definitiv vor einer Woche ein Problem
mit dem 2.6.24er Kernel und Davicom Phy (Allerdings im RMMI Mode).
@Claude:
Hast Du einen Link mit mehr Infos zum Bug im macb-Treiber? "Oben" (wo
auch immer das genau ist) finde ich nichts. Ganz und gar inkompatibel zu
Davicom-PHYs kann er ja nicht sein, sonst ginge es auch mit dem DM9161A
nicht. Außerdem: So weit ich das sehe, ist der IC beim Grasshopper im
normalen MII-Mode, oder?
Und der Pin 45, der beim DM9161A und folglich auch beim Grasshopper "not
connected" ist, hat zwar eine Funktion beim DM9161, doch ist diese
offenbar nur für 100Base-FX (Ethernet via Glasfaser) relevant. Das
sollte es also auch nicht sein.
@ Christian
Beitrag "Re: Grasshopper Inbetriebnahme"
Habe den Link nicht mehr. Aber in einer AT91 Mailingliste gefunden
,denke das war die ML von maxim.org.za (wo die AT91 Patches liegen).
@900ss D und andere mit zerschossenem Flash (Und möglichkeit zum
Flashen!)
Habe ein Rootfs gebastelt. Da ich aber keinen usbprog oder ähnliches
besitze
hab ich mich nicht getraut es zu Testen! Also ohne Garantie hier mein
Rootfs:
http://drunken.intershit.com/root.img
Kernel ist mein eigener mit lcdc und mci aktiv.
Ggf. bei eurer Hardware sicherstellen das nix an diese Ports extern
angeschlossen ist was kaputt gehen könnte.
Uboot hab ich schon mehrfach gepostet und ist von
http://drunken.intershit.com/u-boot-1.3.0.grasshopper.tar.bz
zu ziehen.
Der Uboot wurde bis jetzt auf 3 Boards getestet. Erkennt die vollen
64MB.
Und zuletzt noch ein Kernel uImage (wie im Rootfs mit lcdc etc) das man
notfalls auch per ZModem (Uboot) in den RAM des Grasshopper laden kann
um es aus dem Ram zu starten.
http://drunken.intershit.com/uImage
HTH
Gruß Claude
Claude wrote:
> @900ss D und andere mit zerschossenem Flash (Und möglichkeit zum> Flashen!)> Rootfs:>> http://drunken.intershit.com/root.img
Im Flash abgelegt an 0x30000. Dort soll das Org-Image auch liegen.
Nach pwr on findet er kein Image.
> Uboot hab ich schon mehrfach gepostet und ist von
Läuft bei mir auch. Danke :-)
> Und zuletzt noch ein Kernel uImage (wie im Rootfs mit lcdc etc) das man> notfalls auch per ZModem (Uboot) in den RAM des Grasshopper laden kann> um es aus dem Ram zu starten.>> http://drunken.intershit.com/uImage
Geladen an Adresse 0x10000000: crash nach "GO 0x10000000"
Geladen an Adresse 0x10400000: crash nach "GO 0x10400000"
Die letzte Adresse habe ich genommen, weil dort das Originalimage
vom U-Boot hingeladen wurde nach PWR ON.
Danke für die Mühe, finde ich ja nett.
Das mit dem laden ins RAM kannst Du doch
selber probieren, da mußt du doch nichts ins ram schreiben.
Oder hast trotzdem Angst ;-)
Läßt sich das Zeugs auch unter einer Windowsumgebung erzeugen?
Die Toolchain läuft da ja auch. Ich weiß nur nicht, was die
ganzen Skripte da so machen. Meine Linuxerfahrung ~ 0 :-)
Gruß
900ss
Sups jetzt hab ich mich komplett ausgesperrt... wollte die inittab fixen
aufgrund des tollen Tips im Support-Forum (ttyS0 statt tty1) und jetzt
kann ich mich nicht mehr einloggen. console=... hilft auch nix. Das Teil
bringt mich noch um den Verstand.
Nachtrag... ok da hat er gute alte init=/bin/sh trick geholfen.
@Michael:
Mal "init=/bin/sh" probiert? Ich weiß nicht, ob das bei einem
Busybox-basierten System auch geht, aber bei einem Desktop-Linux umgeht
man damit ja bekanntlich init und damit auch die Auswertung der inittab.
@900ss
Der Kernel läuft bei mir problemlos. Allerdings wird er bei mir durch
die fsload Funktion des uBoots in den Ram geladen und von dort
gestartet. Habe jetzt mein Notebook+Grasshopper nicht da und kann das
nicht nachvollziehen.
Aber bisher habe ich Linux Images im uBoot mit "bootm 0x???????"
gestartet. "Go" bezieht sich glaube ich auf Standalone Binaries die
Inherhalb des uBoot Frameworks kompiliert und gelinkt wurden ->
http://www.denx.de/wiki/DULG/UBootCmdGroupExec.
Die Toolchain kannst Du bestimmt auch unter Windows laufen lassen. Meine
Erfahrung bisher war aber das der Cygwin "Quatsch" eher unzufrieden
läuft und der Aufwand den man reinstecken muss in keinem Verhältniss zu
einer nativen Linux Installation steht die nach 30 minuten abgeschlossen
ist. Zur not tut es auch VirtualBox oder VmWare.
Ehrlich gesagt ist ein Embedded Board nicht so eine gute Wahl um in
Linux einzusteigen. Wenn ich heute nochmal von vorne anfangen müsste
würde ich Debian ohne irgendwelche X11 (Grafisch) sachen als Lernbasis
nehmen.
Fedora,XXXbuntu,Suse und co. sind auch schön . Aber als Anfänger wird
man , meiner meinung nach, zu sehr von X11,Gnome,KDE etc. und deren
Wizzards vom eigentlich System abgelenkt.
@Christian
Verhext! Ich finde den Link auch nicht mehr. Ich kann noch mal in der
Arbeit schauen , denke ich habe einen Arbeitskollegen den Link per Email
geschickt. Um so mehr ich mir darüber Gendanken mache um so sicherer
werde ich mir das es nur den RMII betrifft! Wenn mir die Zeit heute
Abend reicht ,und meine Freundin mir nich wieder aufs Dach steigt wenn
ich nach 11h Arbeit noch 3-4 Stunden daheim "Arbeite", werde ich mal ein
paar versuche mit der PHY Auswahl beim Grasshopper machen.
@900ss
Wegen dem Rootfs. Denke der Kernel fehlt im Image! Die JFFS2 Magic
Bitmask "1985" ist an Adresse 0x0 vorhanden d.h. uBoot sollte keine
Probleme haben mit dem Image umzugehen. Den Kernel kann man nach Booten
und Mounten des Rootfs auch einfach in /boot kopieren. Dann sollte auch
fsload vom uBoot mit dem Image als Bootquelle zurecht kommen. Ob dann
meine Binaries im Rootfs laufen ist ein anderes Thema ;-) Aber bisher
hatte ich da keine Probleme mit der Grasshopper Toolchain.
Claude wrote:
> @900ss> Der Kernel läuft bei mir problemlos. Allerdings wird er bei mir durch> die fsload Funktion des uBoots in den Ram geladen und von dort> gestartet. Habe jetzt mein Notebook+Grasshopper nicht da und kann das> nicht nachvollziehen.> Aber bisher habe ich Linux Images im uBoot mit "bootm 0x???????"
Guten Morgen, ich durfte ausschlafen :-)
Und nach dem ersten Kaffee..... tääää tääää
Habe erst nach 0x10000000 gelden, da hat er sich wohl selbst zerschossen
beim entpacken. dann habe ich mir 2MB vor Ende des Rams ausgesucht und
siehe da......
1
ICNova> bootm 0x13e00000
2
## Booting image at 13e00000 ...
3
Image Name: Linux-2.6.24-icnova_base1
4
Image Type: AVR32 Linux Kernel Image (gzip compressed)
5
Data Size: 1427256 Bytes = 1.4 MB
6
Load Address: 10000000
7
Entry Point: 90000000
8
Verifying Checksum ... OK
9
Uncompressing Kernel Image ... OK
10
11
Starting kernel at 90000000 (params at 13fa5008)...
12
13
Linux version 2.6.24-icnova_base1 (claude@Extensa) (gcc version 4.0.4-atmel.0.99.0) #17 Sat Mar 22 19:53:52 CET 2008
Da habe ich dann mal viel rausgeschnitten und dann die letzen Meldungen
des Kernels.....
1
VFS: Mounted root (jffs2 filesystem).
2
Freeing init memory: 80K (90000000 - 90014000)
3
Warning: unable to open an initial console.
4
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Danach geht nix mehr, muß den Resettaster bemühen. Aber die grüne LED
blinkt schön vor sich hin, allerdings schneller, als ich es gewohnt bin.
Hast den Takt geändert?
Hmmmmm.... kann ich noch was tun?
> Die Toolchain kannst Du bestimmt auch unter Windows laufen lassen. Meine> Erfahrung bisher war aber das der Cygwin "Quatsch" eher unzufrieden> läuft
So habe ich das auch erfahren. Die Fehler die ich gesehen habe dann,
konnte ich zwar nicht 100% objektiv beurteilen, da keine Linuxerfahrung,
aber es sah mir so aus, als wenn es eher Probleme durch CYGWIN waren.
und der Aufwand den man reinstecken muss in keinem Verhältniss zu
> einer nativen Linux Installation steht die nach 30 minuten abgeschlossen> ist. Zur not tut es auch VirtualBox oder VmWare.
Ich habe mir vor ein paar Tagen Ubuntu in einer Virtualbox installiert.
Leider läuft das USB bei mir nicht mit Virtualbox, kann der JTAG ICE
nicht nutzen. Darum liegt es jetzt erstmal herum. Aber zum kompilieren
könnte ich es sicher nutzen. VMWare ist ja leider Kaufware.
>> Ehrlich gesagt ist ein Embedded Board nicht so eine gute Wahl um in> Linux einzusteigen.
Denke ich ja auch. Ist wohl eher der Hardcore-Weg.
> Wenn ich heute nochmal von vorne anfangen müsste> würde ich Debian ohne irgendwelche X11 (Grafisch) sachen als Lernbasis> nehmen.
Was soll ich auf der Konsole denn probieren? Ein Betriebssystem zu haben
um an der Konsole zu spielen, da sehe ich keinen Nährwert. Die Mischung
machts denke ich, also als Anwender auf X und die Konsole, wenn es
brennt oder so.
Vielleicht hast Du ja noch ein Tip? Das Flash laden habe ich noch nicht
wieder probiert. Das Rootfs ist deutlich kürzer, als das, was mir
Bebedikt mal geschickt hat, was auch nicht läuft. Aber er bootet es
zumindest und die grüne LED blinkt auch damit, aber langsamer.
Darum hast Du wohl Recht damit, das bei Dir noch was fehlt in deinem
rootfs.
> Den Kernel kann man nach Booten> und Mounten des Rootfs auch einfach in /boot kopieren. Dann sollte auch> fsload vom uBoot mit dem Image als Bootquelle zurecht kommen.räusper Verstehe da eher nur Bahnhof. Ich glaube ich muß mal viel
lesen.
Danke Dir, noch einen schönen Tag.
900ss
@900ss: Der Kernel findet kein Init. Jetzt müsste man wissen, was der
Kernel als Root-FS mountet und ob diesem Image evtl. /sbin/init fehlt.
Übrigens: Warum verwendest Du nicht VMWare Server? Das ist kostenlos und
unterstützt USB.
Christian wrote:
> @900ss: Der Kernel findet kein Init. Jetzt müsste man wissen, was der> Kernel als Root-FS mountet und ob diesem Image evtl. /sbin/init fehlt.>
Habe jetzt das rootfs von Benedikt wieder ins Flash geladen, dann den
Kernel von Claude mit U-Boot an Adresse 0x13e00000 geladen. Danach bootm
0x13e00000.
Das Ergebnis sieht man im Attachment.
Per Telnet meldet sich der Hopper nicht danach. Per Telnet lief es aber
schon mal, als ich den Hopper frisch hatte und das Flash noch nicht
zerschossen.
Bei mir ist übrigens ein DM9161A bestückt.
> Übrigens: Warum verwendest Du nicht VMWare Server? Das ist kostenlos und> unterstützt USB.
Du meinst sicher VMWare Player? Da muß ich erst ein fertiges Image haben
oder nicht? Muß ich mir mal näher anschauen.
Danke
Joachim
Ich habe mir Claudes "Root-FS" mal auf unter meinem Desktop-Linux
angesehen. Da scheint irgendwas gründlich schief gelaufen zu sein. Statt
des üblichen Root-Dateisystems sind dort nur 4 Dateien enthalten:
70274-debian_crystal.xpm.gz
bgnd.png
minicom.log
Packages.gz.part
Kein Wunder, dass der Kernel darin kein Init findet.
Michael G. wrote:
> Koennen wir hier versuchen das Netzwerkproblem zu loesen?
Auch, ja. Oder ist das hier ein Netzwerklösethread?
Was stört Dich denn?
@Christian,
danke für die Tips. Das VMware Server kostenlos ist, wußte ich nicht.
Nun, das ist ein anderes Thema.
Gut auch, dass du eine Erklärung gefunden hast, warum das Image von
Claude nicht laufen kann.
Ja damit ich wieder einen LINUX lauffähigen Hopper habe, da muß
ich wohl etwas warten, damit ich ein Image habe, das so bootet und
das Netzwerk ging bei mir ja auch nur mit den vorinstallierten Images.
Würde gerne jetzt versuchen, mir selber ein Image zu bauen, aber
es gibt noch andere Projekte, die aktuell im Bau sind. Mist!
Aber falls jemand noch einen Tip hat :-)
Erstmal danke jedenfalls an Christian und Claude.
@900ss und Christian
Autsch! Das tut mir leid mit dem rootfs ... gestern abend nur schnell
zusammengehackt und dabei wohl etwas verk***t ;-) Warum weigert sich der
Grasshopper nur mein Debian Desktop Theme zu booten ??? Naja ich werde
es heute abend nochmal versuchen , und danach auch mounten. Mit dem Hex
Editor erkennt man leider nicht auf den ersten Blick ob das nur Debian
Themes drin sind oder was brauchbares.
Kannst Du das rootfs von Benedikt hier hochladen?
Viellicht sollten wir echt einen extra Thread eröffnen.
Würde Dir schon gerne bei der Lösung des Problems behilflich sein ,
denn es ist nur eine Frage der Zeit bis sich mein Flash mal zerbröselt.
Und dann steh ich genauso wie Du da , blos ich hab keine möglichkeit zum
Flashen :-)
@Michael:
> Koennen wir hier versuchen das Netzwerkproblem zu loesen?
Dabei würde ich ja gerne helfen, aber momentan bin ich eher ratlos und
immer noch ohne eigenes Board :-(. Was mich irritiert: Selbst wenn der
Treiber ein Problem hätte, selbst wenn er den PHY-IC gar nicht
ansprechen würde, müsste der PHY-IC von sich aus nach dem Reset
automatisch versuchen, einen Link zu erkennen.
Ich frage mich gerade, ob auf sich der PHY-Seite etwas zwischen DM9161
und DM9161A geändert hat. Z.B. unterscheidet sich im Datenblatt V_ICM
(die RX-Common-Mode-Spannung). Ich habe aber keine Ahnung, was das für
Auswirkungen hat. Ferner ist im Datenblatt des DM9161 (nicht jedoch in
dem des DM9161A) eine Beispielapplikation. Dabei ist die Mittelanzapfung
des RX-Übertragers nur mit einem Koppelkondensator gegen GND verbunden.
Beim Grasshopper ist lt. Schaltplan diese Anzapfung offenbar auf AVDD
gelegt, was zu einer geänderten Common-Mode-Spannung führen dürfte.
Aber das ist alles Rumstochern im Nebel. Ohne Zugriff auf ein Board,
ohne Möglichkeit, die Register des PHY-ICs auszulesen oder mal ein
Oszilloskop dranzuhängen.
Mal schauen, ob sich wie versprochen In-Circuit hier mal meldet.
Claude wrote:
> Viellicht sollten wir echt einen extra Thread eröffnen.> Würde Dir schon gerne bei der Lösung des Problems behilflich sein ,> denn es ist nur eine Frage der Zeit bis sich mein Flash mal zerbröselt.> Und dann steh ich genauso wie Du da , blos ich hab keine möglichkeit zum> Flashen :-)
OK, neuer Thread, damit keiner mehr weint.
Beitrag "Grasshopper Linux Images"> Kannst Du das rootfs von Benedikt hier hochladen?
Sind im neuen Thread.
900ss
AHA!! Ich war schon auf der richtigen Spur! Es ist das Interface zum
Übertrager. Ich habe Dokumente auftreiben können, das die Unterschiede
zwischen DM9161 und DM9161A nennen:
http://www.dacomwest.de/pdf/dm9161x_differences.pdfhttp://www.dacomwest.de/pdf/dm9161_to_dm9161a.pdf
Beim DM9161A sind die Pins 1, 2 und 9 AUSGÄNGE, die 2.5V für die
Mittelanzapfung der Übertrager liefern. So ist das im Schaltplan des
Grasshoppers auch beschaltet.
Beim DM9161(E) sind die Pins 1, 2 und 9 EINGÄNGE, die auf 3.3V gelegt
werden müssen. Die Mittelanzapfung des RX-Übertragers darf dort nicht
mit einer (Versorgungs-)Spannung verbunden werden, die Mittelanzapfung
des TX-Übertragers muss mit 3.3V verbunden werden.
Wenn das beim Austausch der PHY-ICs nicht berücksichtigt worde, KANN das
alles nicht funktionieren.
Sollte das so sein, bleiben nur eine größere Umlötaktion oder ein
Umtausch des Boards.
Testet denn keiner die Boards, wenn man andere Bauteile verbaut?
Danke Christian, hatte gestern auch beide Datenblaetter zur Hand und
auch bissel veraergert darueber, dass das eine DM9161 sich auf die
E-Version bezieht, was aus der Produktseite von denen nicht sofort
hervorgeht - der eine heisst EP der andere AEP. Habe dann allerdings
nicht jeden einzelnen Pin geprueft, sondern nur auf unterschiedliche
Belegung.
Dann wuerde sich ja fast empfehlen, den Chip komplett auszutauschen und
die vorgesehene A-Version einzuloeten. Ansonsten bleibt nur noch das
ganze mit friemeliger Repro-Arbeit wieder hinzubiegen. Angesichts der
Kosten von ca. 15EUR fuer den Chip (mit Versand) ist das fast
angebracht.
Beim hohen C scheint es das Ding nicht zu geben, aber da kann ich mich
aufgrund der Unbrauchbarkeit der Suchfunktion auch irren.
Hier kann man das Teil kaufen: http://shop.embedit.de/product__512.php
Michael
Ehrlich gesagt, wenn die diesen Unterschied nicht beim Board-Design
berücksichtigt haben, dann hielte ich es für angebracht, den Händler mal
auf seine Sachmängelhaftung hinzuweisen. Immerhin hast Du ein Board MIT
Ethernet gekauft, oder? Und 15 Euro sind verglichen mit dem Board-Preis
auch kein Pappenstiel.
Ich habe hier ja ein Board mit dem DM9161A. Wenn ich etwas tun kann,
dann sagt mal Bescheid. Bei mir lief das ganze ja auch schon, bis
ich das Flash zerschossen habe.
Anpingen kann ich den Hopper :-)
900ss
BTW: Wohnst Du außerhalb Deutschlands oder wie kommst Du auf 15 EUR? Bei
Embedit sehe ich 6,14 EUR für den IC plus 3,95 EUR Versandkosten
innerhalb Deutschlands.
Hallo zusammen,
die letze Charge Grasshopper wurde mit dem DM9161EP statt DM9161AEP
produziert.
Das War ein Problem in unserem Einkauf.
Hinzu kam, dass unser Tester den Fehler nicht entdeckt hat, da der nur
auf die Anwesengheit des DM9161 getestet hatte.
Wir haben die Produktionsprobleme beseitigt. Im Einkauf wurden die
Bestell- und Artikelnummern angepasst. Ausserdem ist der Tester
überarbeitet und kann nun den Ethernet-PHY vollständig testen.
Wir bedauern sehr die Startprobleme beim Grasshopper.
Wir bieten jedem unserer Kunden natürlich den kostenlosen Tausch an.
Das eingeschickte Board wird von uns entweder mit dem neuen PHY versehen
oder
wird alternativ gegen ein neues getauscht.
Wir garantieren eine Bearbeitung innerhalb von 24h.
Bitte schreibt uns bei weiteren auch an unter office@in-circuit.de
und seht in das Forum von Benedikt Sauter.
Gruß
Jörg (In-Circuit)
Wieso tauscht Ihr den Hopper nicht um? Wird auch nicht länger dauern,
als ein neues IC besorgen, altes auslöten, neues einlöten (und hoffen,
dass nix kaputt geht dabei).
Hallo nochmal,
wir bieten ja wie gesagt den Austausch des DM9161EP durch den DM9161AEP
durch uns an.
Weiterhin möchte ich noch die Kostenlose Lieferung eines DM9161AEP
anbieten.
Bitte gebt uns dzu Eure Board-Seriennummer + Eure Adresse durch.
Gruß
Jörg
Und wo auf diesem Board finde ich die Seriennummer? Das kam zu mir ohne
Verpackung oder sonstiges. Auf dem Aufkleber mit der MAC? Die Nummer da
ist fast unleserlich. Hab jetzt mal ne Mail geschrieben.
Die Seriennummer steht oberhalb der MAC-Adresse mit auf dem
Aufkleber.
Das sollte bei den Boards mit dem falschen DM9161 eine 011xxxxxx sein.
Gruß
Jörg
So rein vom Schaltplan her sollten die Modifikationen wie im Anhang
beschrieben auch ausreichen, um den DM9161 zu betreiben. Die Pins 1, 2,
9 und die Mittelanzapfung des TX-Übertragers an 3.3V hängen, die
Mittelanzapfung des RX-Übertragers nirgendwo anschließen. Ich weiß
allerdings nicht, wie machbar das auf dem Board ist.
Oh, und es wäre vermutlich noch besser, wenn auch schwer realisierbar,
die Mittelanzapfung des RX-Übertragers an ein paar Nanofarad gegen Masse
anzuschließen.
Christian: Japsi ;) Das seltsame ist allerdings, dass R24 bereits 0Ohm
ist, das legt den Verdacht nahe, dass das ein beabsichtigtes Experiment
war? Ich meine das is ja wohl schon nen komischer Zufall, oder?
Ja, R24 spricht dafür, dass es schon jemandem aufgefallen ist, dass da
nun ein anderer IC bestückt wird. Hat aber trotzdem nichts genützt, denn
die wichtigste Änderung hat man ja offenbar übersehen.
Aus dem Embedded-Projects-Shop ist das Board übrigens mal wieder
verschwunden.
Da wirft sich jetzt die Frage auf, sollte man den 0R durch einen 10k
ersetzen wenn man den kompletten Chip tauscht? Eigentlich duerfte das
kein Problem sein, oder? Hab leider keine Widerstaende in der Groesse
hier.
Ach ja, das is vielleicht auch interessant:
eth0: Atmel MACB at 0xfff01800 irq 25 (00:00:00:00:00:00)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:00, irq=-1)
Jetzt wo er weg is, selbe messages. Das handelt sich hier also nicht
um eine Erkennung und bdinfo gibt immernoch ne MAC aus ;)
Hallo,
ich hab den Artikel entfernt bis ich auch wie Ihr neue habt die
funktionieren. Der Shop zeigt immer nur das an was tatsaechlich
verfügbar ist. Sobald ich neue Hopper hab erscheint der Artikel wieder
im Shop.
Gruss Benedikt
Hallo Benedikt,
ich glaube, wir erwarten jetzt alle eine Stellungnahme bezüglich einer
weiteren Umtauschaktion. Das Board entspricht ja wohl so nicht der
erwarteten Eigenschaften. Falls es keine Umtauschaktion mehr geben
sollte,
bleibt nur die Rücknahme unter Erstattung des Kaufpreises. Ich würde es
sehr schade finden, denn die Idee für so ein Board ist sehr gut.
Grüße mctee
Hallo,
nochmal zur Klarstellung.
Ich habe mich mit Benedikt geeinigt, dass ich ALLE grasshopper je nach
Wunsch
- repariere
- das Board gegen ein neues austausche
- oder einen DM9161AEP zur Reparatur an Euch selbst schicke.
Ihr könnt frei wählen.
Schickt bitte Eure Adressen und ggf. das Board an uns:
In-Circuit GmbH
Königsbrücker Str. 69
01099
Dresden
Falls Ihr nur den Chip wollt reicht eine Email mit Eurer Adresse an
office@in-circuit.de
Gruß
Jörg
Hallo zusammen,
die Grasshopper sind nun in voller Produktion, die PHY-Probleme wurden
gefixt und die Produktion angepasst.
Michael: Simone hatte Dir bereits vorgestern Deine Ersatz-PHYs
geschickt.
Wir haben das Software-Paket noch um ein Demo-Programm mit Sourcecode
zum Schalten der LEDs und ein "hello world" ergänzt. Ebenfalls kann man
per integrierter Internetseite die LEDs schalten.
Anbei hab ich mal die aktuelle HowTo mit ersten Schritten gehangen.
----------------
Da wir die meisten unserer Hardware-Entwicklungen auf Linux-Boards
stützen,
wollen wir nochmal für komplexere Projekte ein etwas größeres board mit
direkten LCD-Anschluss und SDCARD-Halterung bauen.
Für Anregungen weitere sind wir dankbar!
Gruß
Jörg
Ein Hinweis auf die notwendigkeit der MTD Tools auf den Host würde ich
mir in der Doku noch wünschen. Sonst wird in Buildroot nur der Kernel
und kein rootfs erzeugt.
So, hab mir heute mein Board direkt bei in-cicuit abgeholt, und erstmal
ewig Stiftleisten angelötet. Mistarbeit das ;)
Ne Automatische Adresse holt der sich aber nicht, naja per Minicom drauf
und netz gestartet. wenn ich aber nun mit dem Browser drauf gehe kommt
nix, nur in der Kommandozeile kommt
"Data CRC dbabad68 != calculated CRC a25a186a for node at 00508da8"
Heisst das, daß der Flash putt ist? Kommt immer bei jedem versuchten
Webzugriff.
thnx
Ich seh grad im Bootlog steht:
Press SPACE to abort autoboot in 3 seconds
partition changed to nor0,2
### JFFS2 loading '/boot/uImage' to 0x10400000
Scanning JFFS2 FS: ........\ Unknown node type: e002 len 766 offset
0x508da8
done.
### JFFS2 load complete: 1309661 bytes loaded to 0x10400000
Ich würde (bevor ich einen Hardwaredefekt annehme) vermuten, dass - aus
welchen Gründen auch immer - das Root-FS nicht richtig aufgespielt
wurde. Prinzipiell sollte es aus dem U-Boot möglich sein, ein heiles
Root-FS neu ins Flash zu schreiben, wenn Du ein Image davon bekommen
kannst.
Juhu... hab den PHY heute bekommen, eingeloetet und tut :D
Allerdings muss man immernoch manuell die MAC und die IP zuweisen, das
device wird nicht automatisch hochgebracht und auch die MAC wird nicht
automatisch erkannt. Funktioniert dann allerdings einwandfrei, hab mich
mit telnet drauf verbunden.
Gruesse,
Michael
P.S. Weitere Aenderungen waren/sind nicht noetig.
> Allerdings muss man immernoch manuell die MAC und die IP zuweisen, das> device wird nicht automatisch hochgebracht und auch die MAC wird nicht> automatisch erkannt.
Das sollte sich mit einem passenden Startskript (in /etc/init.d/ oder
unter /etc/network/) doch leicht automatisieren lassen.
> nicht automatisch hochgebracht...
In '/etc/network/interfaces' den Kommentar für 'auto eth0' wegmachen.
MAC Adresse sollte im u-boot hinterlegt sein.
Bei "Printenv" als Parameter ethaddr.
Falls nicht vorhanden, mit "askenv ethaddr" anlegen und mit "saveenv"
sichern.
;-)
Leider laesst sich das Environment immernoch nicht speichern:
ICNova> protect off all
Un-Protect Flash Bank # 1
ICNova> saveenv
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...Erasing sector 9...Erased 1 sectors
Writing to Flash... Flash write error at address 0xa00200ac: 0x6ef4
General Flash Programming Error
Protected 1 sectors
Ich mach's jetzt ueber nen Workaround und setze es direkt mit ifconfig.
Nich so schoen, geht aber auch.
Michael
Michael G. wrote:
> Leider laesst sich das Environment immernoch nicht speichern:
Das ist ein Bug, wie mir mitgeteit wurde und es wird dran gearbeitet.
Der einzige Workaround der hilft (bei mir auch) ist, es mehrmals zu
vesuchen bis es geht. Ich habe auch nochmal die "protect off/on all"
noch wieder benutzt. Manchmal geht es aber auch ohne. Nur Geduld ;-)
900ss
Hallo zusammen,
hat eigentlich schon mal jemand die 2. Debugconsole neben den
JTAG-Adapter
erfolgreich ansprechen koennen ? Ich habe ein serielles Kabel mit
integriertem Levelshifter angeschlossen, bekomme aber keine Ausgaben
im Terminal. Ist die Schnittstelle per default eigentlich aktiv oder
muss man ein zusaetztliches getty starten und wenn ja, auf welchem
Device ?
Christian
Bei mir läuft default dieses I/F. Bin allerdings kein Linuxgeek :-)
Es läuft ein process
913 root 1260 S /sbin/getty -L console 115200 vt100
bei mir. Ich denke der ist das mit dem device console.
@900ss:
>> Leider laesst sich das Environment immernoch nicht speichern:> Das ist ein Bug, wie mir mitgeteit wurde und es wird dran gearbeitet.
Weißt Du auch, woran der Bug liegt? Kann ja eigentlich nur was in U-Boot
sein.
@SiO2:
> Scanning JFFS2 FS: ........\ Unknown node type: e002 len 766 offset> 0x508da8
Ich bekomme übrigens bei meinem neuen Grasshopper exakt die gleiche
Meldung. Betroffen ist davon die Datei /var/www/index.html, daher klappt
es auch nicht mit dem Webserver. Ich schätze, das Root-Filesystem ist an
der Stelle defekt.
Hi Chris ;)
Das hoert sich ja garnicht gut an. Hast Du das rootfs denn selber gebaut
oder ist das der Auslieferzustand? Die Probleme mit dem Hopperchen
scheinen ja nicht abzureissen ;p
Gibt es das Linux eigentlich auch als image? Respektive wie erzeugt man
sich sowas ma einfachsten? Würde gerne mittels Uboot das Image übers
Netz laden. (ist jezt allgemein nicht nur für Linux gemeint, wenn man
embedded proggt, kann man dann einfach das generierte binary laden oder
braucht uboot das in nem speziellem Format?)
Das gängige Vorgehen, um so ein Ding über's Netz zu booten, wäre den
Kernel via U-Boot von einem TFTP-Server oder einer NFS-Freigabe zu laden
und das Root-Dateisystem dann als NFS-Freigabe auszuführen. Alternativ
kann man auch eine initrd mit dem Root-FS erzeugen, die dann - auf
Kosten des RAMs auf dem Board - von U-Boot ebenfalls in den Speicher
geladen wird.
Images (sei es vom Kernel oder von Kernel+initrd) für U-Boot erzeugt man
mit dem dazugehörigen Tool mkimage.
o k a y (Ganz viele Fragezeichen erscheinen LOL)
Na ich wollte das über TFTP Server machen, und erstmal aus dem RAM
laufen lassen (sind ja 64mb da) und wenns läuft dann in den FLASH
schreiben, mag zwar erstmal umständlich klingen aber dadurch hab ich
immer ein funktionierendes System fals mal garnix mehr will :)
Kann ich mit dem mkimage auch Programme in ein Image für Uboot wandeln
die "nicht Linux" sind? Wollte mal ein paar Codebeispiele (UART z.B.)
von der ATMEL Seite ausprobieren :)
Wenn Du Linux aus dem RAM laufen lassen möchtest, wirst Du um eine
initrd (initiale Ramdisk) nicht herumkommen. Diese kann theoretisch auch
das komplette System enthalten. Du wirst allerdings einen neuen Kernel
compilieren müssen, denn der, mit dem der Grasshopper ausgeliefert
wurde, unterstützt offenbar keine initrd.
U-Boot kann auch Standalone-Anwendungen (d.h. kein Linux) starten. Damit
habe ich mich allerdings nicht beschäftigt.
Schade, weil sone StandAlone Lösung wie ich die geladen kriege (am
besten aus dem RAm ausführbar) wäre schon was nettes. Ich werde mal
etwas rumwurschten :)
so lädt er auf jedenfall das bezeichnete File und führt es aus... auch
wenn ich das Grasshopper noch nicht zur zusammenarbeit mit dem Atmel
USART Beispiel überreden konnte :-\
Hat das schonmal jemand hinbekommen? Oder machen alle auf "embedded
Linux"?
Achja gibt es schon nen Fix für das speichern des Envoirments?
> so lädt er auf jedenfall das bezeichnete File und führt es aus...
Du hast so eine Standalonelösung laufen lassen? Wenn ja, dann hast Du
Dir das Linkerscript modifiziert oder was hast Du angestellt, dass es ab
Adresse 0x10000000 läuft?
> wenn ich das Grasshopper noch nicht zur zusammenarbeit mit dem Atmel> USART Beispiel überreden konnte :-\
Ich habe den UART in einer Standalonelösung am laufen. Ich habe
folgenden Headerfile eingebunden:
C:\Programme\Atmel\AVR Tools\AVR32 Toolchain\avr32\include\sys\usart.h
Da sind am Ende ein paar Funktionen definiert, mit denen Du den UART
nutzen kannst :-) Du mußt vorher noch der newlib den CPU clock mitteilen
mit set_cpu_hz() in Hz. Zu finden in:
C:\Programme\Atmel\AVR Tools\AVR32 Toolchain\avr32\include\sys\cpu.h
Ich weiß nicht, ob der U-Boot den Clock ändert, sonst läuft das Board
nach Reset mit 25MHz.
> Achja gibt es schon nen Fix für das speichern des Envoirments?
Ich weiß von nix.
Ich hab einfach das BIN File draufgehauen :D
Obs geht kann ich mangels reaktion nicht richtig feststellen, ich hatte
das vorher mit nem
1
while(1);
Programm versucht, da blieb er dan auch "hängen" das Atmel Beispiel lief
durch aber leider ohne Ausgabe auf der Seriellen Konsole.
Ich dachte das Board läuft mit 140Mhz (laut website...) naja das könnte
ich nochmal probieren. Könntest du dein Funktionierendes UART Beispiel
eventuell mal hier hochladen?
Ein einfaches Hallo Welt würde mir ja reichen :)
Das mit dem savenev ist echt d**f weil ich mir jezt dadurch das standard
envoirment zerschossen habe :-\
Und scheinbar meldet sich jezt die USB Bridege nichtmerh als COMPort -->
Ergo ich komm nichtmehr an das Grashopperboard ran :-(
Kann man da mit nem normalem MAX232 rangehen (mit 5V und
Schutzwiderständen) oder geht dann das Board hops?
Läubi Mail@laeubi.de wrote:
> Ich hab einfach das BIN File draufgehauen :D> Obs geht kann ich mangels reaktion nicht richtig feststellen, ich hatte> das vorher mit nem
Wird wohl nicht gehen. Das Standardlinkerscript linkt auf Adrsse 0 und
nutzt nur das SRAM der CPU.
> Ich dachte das Board läuft mit 140Mhz (laut website...) naja das könnte
Wird es wohl auch, wenn Du Linux bootest. Aber nach dem einschalten ist
die PLL der CPU nicht initialisiert, dann läuft die CPU mit Clock1 und
da hängt ein 25MHz Quartz dran. Für 140Mhz mußt du die PLL entsprechend
initialisieren.
> ich nochmal probieren. Könntest du dein Funktionierendes UART Beispiel> eventuell mal hier hochladen?
Das sollte eigentlich bei Benedikt auf der Webseite erscheinen.
Ich kann das auch hier hochladen, allerdings ist das auch auf Adresse 0
gelinkt und dann läuft es nicht mit laden vom U-Boot. Du mußt es dann
ins Flash brennen und dann ist dein U-Boot platt.
> Das mit dem savenev ist echt d**f weil ich mir jezt dadurch das standard> envoirment zerschossen habe :-\
Na ja, dass läßt sich wohl wieder hinbekommen. Soviele Werte sind das ja
nicht.
Schon aber ich komm zur Zeit halt nicht ans Board ran über USB und das
speichern klappt halt auch nicht :(
Hab halt das File welches der Compiler erzuegt bevor es in den Linker
geht benuzt ;)
Hier ist ein Dump des Speichers zwischen 0x20000 und 0x30000, in dem das
Environment zum Zeitpunkt der Auslieferung hinterlegt ist:
http://www.chzsoft.com.ar/storage/uboot.env
Funktioniert denn der "cp"-Befehl in U-Boot, wenn die Zieladresse im
Flash liegt?
Danke für das Envoirment, die Frage ist nur wie komm ich ejzt erstmal an
das Uboot ohne JTAG ran? Hab leider nur nen 5V max, und ich weiß auch
nicht ob das Uboot befehle von beiden UARTS annimmt :-\
900ss D. wrote:
> Du hast so eine Standalonelösung laufen lassen? Wenn ja, dann hast Du> Dir das Linkerscript modifiziert oder was hast Du angestellt, dass es ab> Adresse 0x10000000 läuft?
Also geändert hab ich nix, wie teil ich den dem Linker die geänderte
Startadresse mit?
Mittels go ADRESSE Springt Uboot dann einfach zu der Adresse die man
angibt hin.
Zum JTAG mit 5V: Ganz "dirty" wäre es, einfach Serienwiderstände
(Größenordnung 100 Ohm) vorzusehen und auf die Schutzdioden des AVR32 zu
vertrauen. Wollte ich auch noch mal ausprobieren...
Warum kommst Du denn über USB nicht mehr ans Board ran?
Stichwort JTAG: Was Ihr im Anhang seht, ist wohl der simpelst-mögliche
JTAG-Adapter, der mit dem Grasshopper klarkommt: an der parallelen
Schnittstelle, mit Wiggler-Pinout. Ich habe den Buffer weggelassen und
dafür wegen der unterschiedlichen Spannungspegel 82 Ohm
Serienwiderstände spendiert.
Als Software verwende ich avr32prog aus folgendem Thread:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=53865
Zumindest das Lesen des Flashs klappt einwandfrei. Ihn zu beschreiben
habe ich mich noch nicht getraut.
Bug in "saveenv" gefixt:
So, ich denke, ich habe den Bug gefunden, der in U-Boot ein
erfolgreiches Schreiben in den Flash-Speicher (und damit u.a. ein
"saveenv") verhinderte. Ich habe den Programmieralgorithmus geringfügig
verändert, nun klappt es (zumindest bei mir).
Ein funktionierendes U-Boot habe ich unter
http://www.chzsoft.com.ar/storage/u-boot.bin abgelegt. Dieses lässt sich
übrigens auch von Linux aus installieren, es ist kein JTAG-Adapter
nötig.
Zur Überprüfung der Integrität der Datei kann der MD5-Hash (ermittelbar
mit md5sum) dienen:
9fb4c85cbf3d71d69d6e07cd8a2faffe u-boot.bin
Wer den Source-Code von U-Boot verändern möchte: Es sind zwei Zeilen in
board/in-circuit/icnova/flash.c hinzuzufügen: In der Funktion
flash_erase ein
status = readw(sb);
nach "} while ((status != 0xffff) && !(status & 0x28));"
In der Funktion write_buff ein
status = readw(p);
nach "} while ((status != word) && !(status & 0x28));"
Wenn ich nen Kernel erstellen will, kann ich zwischen "make menuconfig"
und "make linux26-menuconfig" auswählen (vielleicht auch mehr) wo ist da
der Unterschied? Es werden im ersten Menue mehr moeglichkeiten geboten,
aberwas von beiden moeglichkeiten ist besser?
Hi Chrissi,
coole Sache mit dem Fix. Solltest aber vielleicht nen offiziellen Patch
draus machen. Das heisst eigentlich nur den diff-output zu sichern.
Ausserdem solltest die Sache vielleicht den Jungs bei IC-Nova mitteilen.
Am besten aber mit Kommentaren, damit klar wird, was Du geaendert hast.
lg,
Michael
Christian wrote:
> Stichwort JTAG: Was Ihr im Anhang seht, ist wohl der simpelst-mögliche> JTAG-Adapter, der mit dem Grasshopper klarkommt: an der parallelen> Schnittstelle, mit Wiggler-Pinout.
Wuha... das is ja schon nen bissken uebel ;)
@Michael:
> coole Sache mit dem Fix. Solltest aber vielleicht nen offiziellen Patch> draus machen.
Hast Recht. Mal schauen, ob ich morgen Zeit dafür habe. Dann werde ich
das ganze auch bei In-Circuit einreichen.
> Wuha... das is ja schon nen bissken uebel ;)
No risk, no fun. ;-) Ne, ich war auch überrascht, dass das tatsächlich
ohne Probleme funktioniert.
> Koennte mal ne Anleitung gepostet werden, wie man u-boot neu flasht?
Am sichersten natürlich mit einem JTAGICE mkII. Aber Du würdest nicht
fragen, wenn Du den hättest. ;-)
Unter Linux hast Du eine Chance. Zerflashst Du U-Boot dabei, kommst Du
um JTAG (und sei es nur meine obige Bastellösung) nicht herum. Das geht
dann so:
Du musst im alten U-Boot die "bootargs" so ändern, dass das "ro" nach
"0:128k(boot)" entfernt wird. Bei meinem Board wäre das also (alles in
einer Zeile):
setenv bootargs console=ttyS0 root=1F02 rootfstype=jffs2
mtdparts=physmap-flash.0:128k(boot),64k(env)ro,-(root)
Dann bootest Du Linux ("boot"). Als root kannst Du dann die neue Version
von U-Boot laden (z.B. mit wget nach /tmp) und dann mit
dd if=/tmp/u-boot.bin of=/dev/mtdblock0 bs=4k
flashen. Daumen drücken und neu booten.
Danke, aber zu spaet fuer mich :(. Aber fuer andre hoffe ich nicht.
Ich versuche jetzt usbprog zum laufen zu bringen.
Bei embedded-projects gibts extra firmware fuer avr32, ist es egal, ob
ich die nehme oder mk2-firmware?
Danke.
Die Zeile ist korrekt.
Irgendwo ein Zeilenumbruch drin? Das komplette Kommando (von "setenv"
bis "(root)") muss in eine Zeile, mit einem Leerzeichen zwischen "jffs2"
und "mtdparts".
@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).
Christian wrote:
> 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).
Sowas brauchst du gar nicht, das Wiki soll ja kein Lexikon sein. Fang
doch einfach an zu schreiben was dir einfällt: AVR32 Grasshopper
@Werner B.:
> Das "setenv" hat generell ein Problem mit langen Zeilen.
Ab welcher Zeilenlänge? Ich scheine bisher noch nicht an das Limit
gestoßen zu sein.
> 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 wollte eher darauf hinaus: Wenn der Bug noch vorhanden wäre (was er
ja offenbar nicht mehr ist), dann wäre es sinnvoll, ihn zu suchen, zu
fixen und einen Patch dafür zu veröffentlichen.
Hallo,
eine Frage habe ich.
Hat von Euch Linuxgeeks ;-) evtl. Dropbear auf dem Grasshopper zum
laufen bewegt? Wenn ja würde ich mich über ein HowTo freuen.
Geht das überhaupt?
Danke schön.
@900ss:
Ich habe Dropbear einfach im Build-Root mit ausgewählt, compiliert und
die entsprechenden Dateien auf den Grasshopper kopiert. Wo hakt es denn
bei Dir?
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
Christian Z. wrote:
> Es muss ja nicht gleich das Root-FS-Image sein, ich kann Dir auch auch> das Binary von Dropbear zur Verfügung stellen, wenn Dir das lieber wäre.
Als ich mein letztes Posting abgeschickt hatte, ging es mir auch durch
den Kopf. Ich brauche sicher nur ein binary.
haben wollen :-))
Ja wenn Du es mir zu Verfügung stellst, evtl. ein kleines HowTo, wie ich
es in Betrieb nehmen muß?
Ich bin in der Lage, Dateien per wget auf mein Grasshopper zu laden.
Habe mal spaßeshalber eine kleine Webpage nach.../www kopiert um sie zu
testen. Das hat geklappt. Also soviel zu meinen Vorkenntnissen :-)
Danke schon mal.
900ss
Das dropbear-Binary ist momentan unter
http://www.chzsoft.com.ar/storage/dropbearmulti verfügbar. Du musst es
irgendwo hin (z.B. nach /usr/bin) kopieren und dann Softlinks ("ln -s
...") anlegen. Im Binary vorhanden ist Code für den SSH-Client, scp, den
SSH-Server und die Key-Verwaltung.
Eine Anleitung zu dropbear findest Du sicher im Netz.
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
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 .
Guten Morgen,
gähn :-)
Schon Antworten. Danke. Also als default geht es auch nicht.
Danke für das Startscript, es hilft ein wenig, die Installation dann bei
mir zu vervollständigen. Allerdings das Starten u.s.w. von dropbear hab
ich schon richtig gemacht denke ich. Wenn ich mir das Script so ansehe,
dann habe ich wohl keine Fehler gemacht.
Ich habe nur ein Problem mit den Keys. Die liegen zwar an der richtigen
Stelle im Grasshopper, allerdings hab ich da wohl was falsch gemacht mit
den public/private keys die ich dann bei Putty verwende.
Nun vielleicht gibt es da ein schönes Howto? Hab gestern noch viel
Google gefragt aber so wirklich schlau bin ich nicht draus geworden.
Schönen Tag.
Hmmm... nun geht es. Habe es noch nicht so ganz verstanden, aber ich
habe mir jetzt noch einen Key mit puttyge generiert. Den private Key für
Putty genutzt, den Public Key auf den Grasshopper in
root.ssh/authorized_keys gespeichert (als openssh Format). Die
Dateirechte noch auf 744 gesetzt und nun funktioniert es. Ich bin platt.
dropbearkey habe ich auch vorher genutzt um den rsa und dss key zu
erzeugen.
Die Geschichte mit den Keys habe ich nich nicht begriffen. Ich dachte
EIN public key und EIN private key genügen. Kann mir evtl. jemand
erklären, wozu die von dropbear generierten keys sind und dann noch
zusätzlich die von putty generierten keys?
Danke schön.
Edit: Ach ja, danke schön für das dropbear binary an Christian. Sehr
nett :-)
@900ss:
Das ist schon länger her, aber meine Erinnerung sagt mir: Sowohl die
Clients als auch der Server haben jeweils eigene Keys, damit sie sich
gegenseitig authentifizieren können.
SiO2 wrote:
> Kannst ja auch erstmal die Ports scannen, ob ssh überhaupt läuft.
Geht doch schon (s.o.). Bin ganz begeistert. Wollte es hauptsächlich für
Port-Weiterleitung nutzen. Hier wo ich sitze ist der SSH-Port offen :-)
und der Rest außer HTTP/FTP zu.
Und sonst habe ich immer meinen PC laufen lassen. Das kann jetzt der
Grasshopper erledigen.
Frage:
Ist eigentlich /etc/inittab der richtige Ort, um dropbear automatisch zu
starten? Oder ist eine andere Stelle geeigneter?
> Ist eigentlich /etc/inittab der richtige Ort, um dropbear automatisch zu> starten? Oder ist eine andere Stelle geeigneter?
Der saubere Weg wäre ja über ein Skript /etc/init.d/ und einen Link in
/etc/rc.d/.
Danke für de Hinweis. Das inittab ist beim graben nach Infos das erste
gewesen, was mir über den Weg gelaufen ist. Inzwischen bin ich genau da
angekommen, was Du auch geschildert hast. Da ich aber absoluter Linux
Neuling bin, muß ich das Ganze immer doppelt prüfen, damit es dann auch
richtig wird.
Nun, ich werde das mal so probieren. Den Startablauf von Linux habe ich
noch nicht so verinnerlicht.
Der dropbear haut gut hin. Hab ihn heute schon mehrmals von der Ferne
genutzt :-)
Jetzt hab ich auch eine sinnvolle Aufgabe für den Grasshopper und mein
PC darf tagsüber schlafen :-)
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
@Sebastian:
Einen Schaltplan meines JTAG-Adapters habe ich leider nicht. Ich habe
aber die Pinbelegung des Wiggler verwendet (siehe z.B. Abschnitt
"Wiggler" in http://www.mikrocontroller.net/articles/JTAG). Ich habe nur
die Leitungen TMS, TCK, TDI, TRST und TDO verwendet, auf einen Buffer
verzichtet und stattdessen 82 Ohm in Serie geschaltet. GND ist natürlich
durchverbunden.
Den Link zur Software hatte ich ja bereits gepostet, allerdings habe ich
damit den Grasshopper noch nicht beschrieben. (Mit meiner eigenen
JTAG-Software schon, aber die ist nicht veröffentlichungsreif.)
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
Ansonsten hab ich einen JTAG ICE MkII. Ich weiß nur nicht ob Du in
in der Nähe von Bremen wohnst. Dann würde ich ihn Dir wiederbeleben.
Oder per Post.
Falls es mit dem Wiggler klappt, sag mal Bescheid. Finde ich auch
interessant.
Wie gesagt: Ich habe mit meinem Simpelst-Adapter und meiner Software den
Flash des Grasshoppers gelesen, gelöscht und geschrieben. Das klappt.
Wenn man jetzt auch noch das Debug-Interface darüber zum Laufen
bekäme...
Hallo,
ES GEHT !
Der Grasshopper läßt sich bei mir mit avr32prog und dem "MinimalJTAG"
flashen
Es hat zwar etwa 45 Minuten gedauert aber egal...
Das war die gute Nachricht, die schlechte, irgendwas ist dabei
schiefgegengen :-(
Ich wollte den U-Boot, den Christian weiter oben am 18.04.2008 um 18:06
gepostet hat draufladen, der startet auch, funktioniert leider nicht
Hier ist die Kermit ausgabe:
Das ganze wiederholt sich, bis ich den Grasshopper vom Netz trenne.
Jetzt stellt sich die Frage, ist da beim Flashen was schiefgelaufen ?
Sollte ich es nochmal versuchen ?
Kann es sein, daß da irgendwelche Bits gekippt sind ?
@900ss D.,
vielen Dank für das Angebot, leider wohne ich am Niederrhein etwa 350 km
von Bremen entfernt, sonst würde ich das Angebot sofort annehmen.
Gruß Sebastian
Hallo,
Ich habe gerade nochmals versucht den Bootloader draufzuspielen.
Es geht!
Irgendwas muß beim erstem Mal falsch gelaufen sein, das spielt jetzt
keine Rolle mehr, hauptsache ich kann jetzt mit dem Grasshopper
connecten :-)
Vielen dank an Euch, den JTAG Adapter werde ich mir gut aufheben, man
weißt ja nie !
Gruß Sebastian
Hey das ist ja cool. Gut zu wissen. Ich kann mir zwar helfen, aber es
ist immer gut, eine Alternative zu haben. Und ich mag auch solch
einfache Interface.
>Und ich mag auch solch>einfache Interface.
Ja , es taugt aber wirklich nur als Notlösung.
Ich könnte wetten, daß Du mit Deinem JTAG ICE MkII weniger als 40
Minuten fürs U-Boot flashen brauchst ;-)
Gruß Sebastian
Hm, ich schaffe mit dem Simpelst-Adapter beim Schreiben ca. 200 Bytes/s,
damit dürfte U-Boot (128kiB) in gut 10 Minuten geschrieben sein (zzgl.
vorherigem Löschen der Sektoren). Das wäre dann sogar schneller als ein
JTAGICE mkII? Kann ich kaum glauben.
Wie gesagt, habe nicht direkt auf die Uhr geschaut, aber ich meine es
dauerte so lange. Im Moment habe ich gerade andere Prioritäten.
Sonst würde es mal ausprobieren.
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...
Spannungsversorgung: Bei mir passt ein Hohlstecker mit r_a=5,5mm und
r_i=2,5mm. r_i=2,1mm dürfte auch gehen, so dick scheint mir der Stift in
der Buchse nicht. Polarität steht ja auf dem Board drauf.
Vorsicht: Wer noch eines der ersten Boards hat, bei dem C42 bestückt
ist, darf keinesfalls mehr als 10V anlegen.
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
intmain(void){
9
intfd=-1;
10
charname[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
return0;
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.
Also, /dev/input/event0 wird bei mir auch nicht automatisch erzeugt,
soweit kein Problem. Taucht denn in /sys/class/input nach dem Laden der
Module etwas auf?
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
Ist vor dem Laden der Module schon ein Verzeichnis
/sys/devices/platform/gpio-keys vorhanden? Dann sollte angelegt werden,
nachdem btn.c modifiziert wurde.
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
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.
Dein zuletzt geposteter Auszug aus /var/log/messages liest sich auf alle
Fälle ganz gut.
>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:
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?
Swiw ist avr32-gcc die Variante für Standalone-Anwendungen und
avr32-linux-gcc die für Linux-Anwendungen. Nun kenne ich mich mit dem
AVR32 Studio nicht aus, aber kann man das konfigurieren, ob es Linux-
oder Standalone-Anwendungen bauen soll?
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 :-(
Hallo Leute!
Also ich hab mein Grasshopper Board gestern bekommen, und versuche seit
dem verzweifelt es in Betrieb zu nehmen. Ich habe gelesen, daß ich nicht
der einzige bin, bei dem die Virtuelle Schnittstelle auf USB nicht
funktioniert.
Mein Computer findet zwar einen USB Controller aber wie soll ich mich
jetzt mit Putty mit dem Board verbinden?
Ich weiß ja noch nicht einmal, wie die IP des Boards ist!
Zitat : "....hier kann direkt nach dem Einschalten der Boot-Vorgang
beobachtet werden"
Wie denn bitte?
Eine Serielle Schnittstelle bekomme ich auch nicht angezeigt!
Gibt es irgentwo ein Tutorial, das sich mit dem Thema beschäftigt, oder
könnt ihr mir vielleicht helfen?
Hallo,
Ist Putty nicht telnet,ssh Ersatz für Windows ?
Du brauchst ein Terminalprogramm, das auf 115200 Baud 8/N/1 eingestellt
ist.
Dein Computer muß einen Com Port erkennen, nachdem Du den Hopper
angeschlossen hast, und damit verbindest Du Dich auch.
Sonst schau mal unter diesem Link nach
http://www.embedded-projects.net/index.php?page_id=237
viel Glück Sebastian
PuTTY kann auch als serielles Terminalprogramm verwendet werden.
Voraussetzung ist natürlich, dass die serielle Schnittstelle des
Grasshoppers erkannt wird.
Wimre musste ich den Treiber für die USB-seriell-Bridge von Silabs
installieren, damit der Com-Port zur Verfügung gestellt wurde.
Wunderbar! Das Grasshopper läuft! Nachdem ich die Virtual Serial Port
Adapter Software von Eltima aufgespielt habe, kann ich über Putty mit
den in der oberen Beschreibung angegebenen Einstellungen wunderbar auf
das Board zugreifen. Danke leute!
Hat von euch schon jemand einen SD-Kartenslot an das Grasshopper
angebaut oder kann in Bezug auf Erweiterungen etwas empfehlen?
Die Pinleisten an meinem Board sind noch nicht drin, d.h. ich muß die
wohl nachträglich einlöten. Leider.
Ich will außerdem versuchen, das gesamte Board über Hochkapazitätsakkus
am laufen zu halten, am besten wäre es, wenn man die auch gleich über
USB mitaufladen könnte. Hat damit jemand schon Erfahrungen gesammelt?
Hallo Mathias,
Ich habe eine SD Karte am Grasshopper angeschlossen, leider funktioniert
sie noch nicht :-(
Hier Beitrag "Re: I2C am Grasshopper mit 5V" haben wir kurz
drüber gesprochen, vielleicht hilft es Dir weiter, ich bin noch nicht
dazu gekommen weiter zu machen.
Gruß Sebastian
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.
Hallo Werner,
Super, danke für die Antwort.
Könntest Du vielleicht noch kurz beschreiben, wie man "Änderungen für
das andere Buildroot reinfummelt" ?
Das wäre sehr hilfreich und vor allem was hast Du mit Card detect und
Write Enable Pins von der Karte gemacht ?
Ich will mein System garnicht auf der Karte ablegen, sondern die Karte
nur in System mounten als fat oder ext2, sollte doch machtbar sein oder
?
Gruß Sebastian
Also ich werde jetzt erst einmal alle verfügbaren Informationen über das
Grasshopper zusammenzutragen, auch Threadinformationen. Ich will
versuchen, alles zu bündeln, um eine Umfassende Dokumentation zu
erzeugen, damit hier das Rad nicht zwanzigmal erfunden wird.
Ich glaube es würde viele User freuen, wenn sie nicht endlos stöbern
müßten, um an geeignete Infos dranzukommen.
Sozusagen die Essenz über das Grasshopper-Wissen zusammenzutragen.
Das kleine Projekt wird mich jetzt erst mal auslasten, wenn ich fertig
bin, werd ich den Link mal posten.
Mfg
Mathias Unknown wrote:
> Ich will> versuchen, alles zu bündeln, um eine Umfassende Dokumentation zu> erzeugen, damit hier das Rad nicht zwanzigmal erfunden wird.> Ich glaube es würde viele User freuen, wenn sie nicht endlos stöbern> müßten, um an geeignete Infos dranzukommen.
SUPER! Ich freue mich drauf, auch wenn ich erst im Herbst dazu komme,
mit dem Grasshopper weiterzumachen. Vorher steht leider viel anderes auf
dem Zettel :-(
Jetzt schon mal ein großes DANKE dafür.
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
Wo kann man eigentlich günstig an Kleinteile wie z.B. Pins, oder
vielleicht passende Pin-Leisten kommen, die man für den Grasshopper
verwenden kann. Finde im Internet äußerst wenig davon.
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)
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
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'
Hallo,
Die TSLIB-Programme (ts_test...) brauchen ja ein /dev/input/event0. Aber
wie wird der erzeugt? Muss ich da irgendwas mit "mknod /dev/input/event0
..." machen?
An meinen Grasshopper hab ich ein ADS angeschlossen. Ein "cat
/sys/devices/platform/atmel_spi.0/spi0.0/pen_down" sagt mir eine "1"
wenn ich den Touch berühre.
Ein "cat /proc/bus/input/devices" listet:
I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="ADS784x Touchscreen"
P: Phys=spi0.0/input0
S: Sysfs=/class/input/input0
U: Uniq=
H: Handlers=
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=1000003
Wei bekomme ich jetzt ein "/dev/input/event0" Gerät hin?
Grüsse
Uwe