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.
Die LED blinkt zwei mal kurz und dann eine laengere Pause. Vielleicht hilft das ja was. Lustiges Raetselraten.
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
Also die ip von der Website war 192.168.93.1. Und nun hört auf so dolle zu schimpfen, wächst doch alles.
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.
@SiO2: Im welchem Shop gibt's das nicht mehr? http://shop.embedded-projects.net/product_info.php?info=p12_Grasshopper-AVR32--AP7000--Board.html
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.
>Der Schaltplan ist leider unter SUSE nicht lesbar. Meinst Du diesen? http://www.ixbat.de//files/admin/projekte/grasshopper/grasshopper_schematic.pdf Unter Gentoo-Linux zeigt der Betrachter Evince alles korrekt an (und ich habe keinerlei Zusatzschriften oder ähnliches installiert.)
o.g. link zum PDF lässt sich unter Debian auch nicht richtig anzeigen... Die Schrift "Verdana" konnte nicht erstellt werden! (AcroReader)
http://de.wikipedia.org/wiki/Verdana Ja, wäre schon besser gewesen, wenn sie eine andere Schrift verwendet hätten.
stefan@AMD64-X2 ~ $ emerge --search corefonts
Searching...
[ Results for search key : corefonts ]
[ Applications found : 1 ]
* media-fonts/corefonts
Latest version available: 1-r4
Latest version installed: [ Not Installed ]
Size of files: 3,842 kB
Homepage: http://corefonts.sourceforge.net/
Description: Microsoft's TrueType core fonts
License: MSttfEULA
Hätte mich auch gewundert, wenn Gentoo standardmäßig die Corefonts
installiert hätte. Scheinbar haben sie jene irgendwie ersetzt,
vermutlich durch Bitstream Vera Sans.
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.
Probier's mal mit dem Schaltplan im Anhang.
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
@claude: Warum nen extra forum. Es gibt doch schon was dafuer http://forum.embedded-projects.net/viewforum.php?id=16
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
Vergiss es das bringt nix... auch wenn ich versuch das Device als statisches (ohne DHCP) zu konfigurieren.
@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.
Das mit dem Linux Image könnte schwer werden , versuche aber morgen mal meins mit dd zu ziehen. Den Uboot (Binary und Source) kannst Du von http://drunken.intershit.com/u-boot-1.3.0.grasshopper.tar.bz ziehen.
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 *soifz
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.
Hm OK dann kann ich zumindest einen defekt ausschliessen, wenn Du das selbe Problem hast. Das nervt mich grad ziemlich muss ich sagen...
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 :-((
Ja das is toll das bringt mir nur nichts jetzt. Ich muss den Link hinbekommen.
Angehängte Dateien:
-
grasshopper-phy.jpg
41 KB
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.
Angehängte Dateien:
-
grasshopper-phy_vdd.jpg
55 KB
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.
Da könnte man nen DM9161A nachbestellen: http://shop.embedit.de/product__512.php Ggf. dann halt selbst umlöten. Gruss, Benedikt Köppel
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
Hab Benedikt ne Mail geschrieben und ihn auf den Thread aufmerksam gemacht.
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.
uiuiuiuiui klingt alles nicht so gut. Hab gerade In-Circuit bescheid gegeben. Da wird sich einer morgen hier melden. Gruss Benedikt
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!
Low is gar nicht gut! Mal die Rambo Methode versuchen -> Überbrücken ?
(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 :(
Und zum Uboot Flash Problem :
1 | protect off all |
2 | saveenv |
3 | protect on all |
Bei meinem Board Funktioniert das. AT49BV642D ist Bestückt.
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?
Also sind wir wieder am Anfang :( Das mit dem High an RXEN ist, soweit ich beurteilen kann, auch OK.
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: Hmm, ich finde nichts. Ich weiß allerdings auch nicht so recht, wonach ich da suchen soll, um besagten Bug zu finden.
Das ist jetzt irgendwie alles unbefriedigend :(
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.
Jau... siehe oben. Aber das alte Netzwerkproblem besteht immernoch... leider :(
@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.
Koennen wir hier versuchen das Netzwerkproblem zu loesen?
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
@900ss: Ich meine den kostenlosen VMWare Server. Damit kann man eigene Images anlegen.
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.pdf http://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.
Achso: Keine Gewähr, denn ich selber kann es ja nicht testen. Beschwert Euch bitte nicht, falls die Modifikation doch keinen Erfolg hat.
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.
Oh diesmal is sogar der Link aus dem Menue weg!
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.
Angehängte Dateien:
-
phy-footprint.jpg
42 KB
Sollte eigentlich, weil's ja nen Eingang ist. So nu isser wech, hab mich entschlossen den Chip komplett auszutauschen.
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 ;)
> [Generic PHY]
Naja, es wird kein PHY mehr erkannt. Die MAC-Adresse ist auch nicht im
PHY hinterlegt.
Ah right... hast recht, vorher hat er den noch erkannt.
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
@mctee: Ich gehe mal davon aus, dass auch über Benedikt erworbene Boards bei In-Circuit repariert bzw. getauscht werden können. Irre ich mich?
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
Du bekommst dann ja schon das gefixte ;P Hast Du eigentlich ICQ? hehe
Prinzipiell habe ich einen ICQ-Account, bin aber seltenst damit online? Wieso?
Naja das is dann doch eher unbrauchbar... *soifz
Gut beschrieben ;) Das war genau das, was ich gemacht habe hehe... ;p
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.
@Michael:
> Leider immernoch keinen PHY :(
Du hast immerhin ein Board bekomme. Ich nicht.
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.
Nein, wo der Bug liegt, weiß ich nicht. Es war eine Auskunft von In-Circuit, dass sie nach dem Bug suchen. 900ss
Übrigens, gerade gesehen: Es gibt jetzt online ein 10-seitiges Howto zum Grasshopper: http://www.ic-board.de/data/datasheet/icnova-base_welcome_(deutsch).pdf Hilft dem einen oder anderen vielleicht bei der Erstinbetriebnahme...
@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
Da Haargenau dergleiche Fehler auftritt, ists wohl nur nen kleines Fileproblem. Ich denke ich schaff es heute mal mir nen neues Rootfs zu starten.
Könnte man denn das Problem beheben indem man die datei sich (voher?) per wget neu lädt? Bei mir tuts der Webserver leider auch nicht :-\
Das Problem bestand schon mit dem ausgelieferten Root-FS. Ich habe es bekanntlich gefixt und unter http://www.chzsoft.com.ar/storage/root3.fs online gestellt. Eine funktionsfähige, gepackte index.html findet sich unter http://www.chzsoft.com.ar/storage/index.html.gz
Danke Christian, hab deine Datei geladen und es geht :)
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 :)
1 | set bootfile <Binary File>; |
2 | set serverip <IP des TFTP Servers>; |
3 | set ipaddr <ip fuer das board>; |
4 | tftpboot <SDRAm Adresse 0x10000000>; |
5 | go 0x10000000; |
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?
Läubi Mail@laeubi.de wrote:
>1 | > set bootfile <Binary File>; |
2 | > set serverip <IP des TFTP Servers>; |
3 | > set ipaddr <ip fuer das board>; |
4 | > tftpboot <SDRAm Adresse 0x10000000>; |
5 | > go 0x10000000; |
6 | > |
> 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 :-\
Mehrmaliges saveenv hats dann wieder gerichtet :-\ Ist das eventuell nen Timingproblem??
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?
der PC wollte die USB Bridge nichtmehr erkenne.. Strom wurde aber geliefert. Nach einmal ausstecken neue Anstecken gings plötzlich wieder... naja
Angehängte Dateien:
-
jtag-grasshopper.jpg
63 KB
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.
Chrissi: Meld Dich doch mal an hier, dass Du nen Nutzernamen hast? lg, Michael
> 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.
Christian: Kanns sein, dass in der Zeile nen fehler ist? Bei mir bringt uboot dann immer Unknown command 'k(env)ro,-(root)' - try 'help' Gruss Flo
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".
Das "setenv" hat generell ein Problem mit langen Zeilen. Alternative ist "askenv <variable>".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.