Hallo grasshopper Freunde,
unter http://forum.embedded-projects.net/viewtopic.php?id=458 wurde ein
patch für Buildroot von Atmel v2.2.0 vorgestellt. Auf dieser Basis habe
ich für die am 08.10.2008 freigegebene Version 2.2.1 eine Version
erstellt. Ich habe sie zunächst unter TFTP/NFS gebootet (das habe ich
nach dem Desaster - siehe NFS mit grasshopper / AVR32 - voll im
Griff :-), getestet und für sehr schön befunden. Anschließend habe ich
sie unter Linux ins Flash geschrieben und kann bisher nichts negatives
vermelden.
Zu Installation:
1. Buildroot von http://www.atmel.no/buildroot/buildroot-src.html
downloaden und auspacken.
2. Den Patch drüber kopieren
3. make grasshopper_defconfig ausführen
4. make ausführen
5. lange warten
Folgendes ist anzumerken:
1. In Ermangelung einer Hardware, die mir ein Zurück im Falle eines
Fehlers ermöglicht, konnte ich U-Boot nicht testen. Da sich hier seit
der letzten Version (jetzt wird U-Boot 1.3.4 verwendet) eine Menge
geändert hat, würde mich nicht wundern, wenn U-Boot nicht ordentlich
funktioniert (ich habe auch die Teile für LCD-Ausgabe aus der STK1000
eingepflegt). Für Tests, Rückmeldungen oder Korrekturen wäre ich sehr
dankbar.
2. Ich habe an einigen Stellen 'aufgeräumt': Die Unterstützung des
'großen' ICNova ist weitgehend raus geflogen, weil ich keine Infos zu
diesem Board gefunden habe. Nebenbei würde ich ein Buildroot-Update von
In-Circuit / embedded-projects als service erwarten - aber das ist
vielleicht naiv.
3. An einigen Stellen habe ich Hardware-Unterstützung vorbereitet. Die
konnte ich bisher auch noch nicht testen (da muss ich erst mal den
Lötkolben schwingen).
4. Interssanter weise findet sich schon die Unterstützung des aus
Gerüchten bekannten AP7200 (USB-Host?). Auch finden sich schon teilweise
Patches für Kernel 2.6.27 (ich habe gehört, der bekommt eine gesonderte
Verwaltung für das interne RAM...).
Es bleibt spannend...
Als ursprünglicher Autor des Patches auf Embedded Projects möchte ich
mich bei Andreas für die "Fortführung des Patches" bedanken und
folgendes zu U-Boot anmerken.
Ich bin im Kampf mit einem Patch für U-Boot v1.3.4. Die
DRAM-Initialisierung tut nicht so wie ich will. Sobald ich auf 32-bit
Busbreite umstelle bekomme ich im U-Boot ca. jede Minute einen Reset
bzw. NMI. Mit dem U-Boot für das NGW100 (mit einem kleinem Patch für
Ethernet) läuft er Problemlos, dann allerdings nur mit 32MB Ram da nur
16-Bit breit angebunden. Hat jemand eine Idee dazu?
1. Deine Vorlage war Gold wert!!!
2. Wahrscheinlich hast Du Dich bereits umgesehen: die STK1002
Implementierung ist auch 32 Bit breit. Vielleicht hilft das weiter.
3. In Deinem buildroot hattest Du in
1
make linux26-menuconfig
unter 'System Type and features'->'Atmel AVR32 AP options'->'AT32AP700x
static memory bus width (16 bit)' angegeben (ich habe jedoch keinen
relevanten Verweis auf die Variable AP700X_32_BIT_SMC finden können)
4. Hast Du mal meine Überarbeitung ausprobiert?
Hallo Andreas,
> die STK1002 Implementierung ist auch 32 Bit breit.
Laut Schaltplan sogar mit den gleichen SRAM Chips. Doch sobald ich auch
nur die Parametertabelle des STK1002 verwende (und die zusätzlichen Pins
reserviere) passiert es. Allerdings habe ich noch nicht die Zeit
gefunden mir den Code der DRAM Initialisierung anzusehen. Schalten die
bei 32Bit den Watchdog ein???
Zu AP700X_32_BIT_SMC: Vom Linux wird verwendet was der U-Boot
konfiguriert. Darum ist dieser Schalter vollkommen wirkungslos (soweit
ich herausfinden konnte).
Zum Testen deines Patches bin ich noch nicht gekommen.
Werner
>Doch sobald ich auch nur die Parametertabelle des STK1002 verwende (und die >zusätzlichen Pins reserviere) passiert es.
Das alleine reicht nicht: In der Funktion board_early_init_f ist der 1.
Parameter in portmux_enable_ebi die Busbreite. Hast Du hier 32 Bit?
gibt es eigentlich einen Grund, dass das Board nicht direkt in den
Kernel eingepflegt wird?
Also wieso kein Patch an die Mailingsliste geschickt wird, sodass das
Board automatisch wie auch das ATNGW100 bzw. STK1000 oder inzwischen
auch direkt verfügbar ist?
@gast
Frag mal Atmel Norwegen, ob die daran Interesse haben, den grasshopper
einzubringen bzw. zu pflegen.
@Werner:
1. Mein letzter Post war wohl etwas übereilt...
2. Welchen Schaltplan hast Du? Die einzigen, die ich von Atmel gefunden
habe sind die STK1000 und STK1002. In der STK1000 finde ich nur einen
Baustein mit 8MB (optional 16MB) RAM 32 Bit breit.
@Adreas,
während der Rechner im Hintergrund compiliert, habe ich mir einmal
deinen U-Boot Patch angesehen. Im wesentlichen entspricht er meiner
Version.
Was auf jeden Fall fehlt ist der Reset des Ethernet PHY. Da bin ich
damals auch erst darauf gestoßen als ich das Board am nächsten Morgen
wieder unter Spannung gesetzt habe .... das Netzwerk ging nicht (mehr).
Warum der Reset des PHY nicht einfach mit am normalen CPU Reset
angeschlossen ist ???
Vor macb_eth_initialize(0, ... muss noch rein
1
#define PHY_RESET_PIN GPIO_PIN_PB(29)
2
3
/* Grasshopper/ICNova specific */
4
gpio_set_value(PHY_RESET_PIN,0);
5
udelay(100);
6
gpio_set_value(PHY_RESET_PIN,1);
7
udelay(1000);
Da gerade eben noch Übersetzt wird konnte ich noch nicht testen, aber
es könnte sein dass die folgenden Headerfiles dann ebenfalls noch
benötigt werden...
Suuuper (Froi).
Dein u-Boot Patch mit meinem PHY Reset Patch funktioniert :-))
Allerdings musste ich den PHY Patch ein wenig überarbeiten.
Das gpio2.h ist im Anhang zu finden.
@Werner
ja ich gebe zu es ist nicht zwingend notwendig aber...
Ich habe Deinen Patch auf den Stil umgebaut, wie ich ihn in anderen
Implementierungen gefunden habe. Dadurch wird er etwas schlanker und
gpio2.h überflüssig.
1
#ifdef CONFIG_CMD_NET
2
intboard_eth_init(bd_t*bi)
3
{
4
/* Grasshopper/ICNova: the PHY reset Pin is controlled by PORTB[29]!!! */
Kannst Du den mal testen? Hierbei die Bitte, folgende Funktionen zu
testen (ich denke, das ist der minimale Satz an Befehlen, den ich
brauche, um wieder zu einem Linux zu kommen - wenn Du noch weitere
testen kannst, schadet das sicherlich nichts...):
setenv
printenv
tftp und/oder dhcp
bootm
Sollte Dein Test erfolgreich sein, kann ich es wagen, den Bootloader
unter Linux zu flashen, weitere Test machen, einen neuen Patch
vorzubereiten und mal die Fühler ausstrecken, was zu tun ist, damit
Atmel/DENX den grasshopper in ihre Quellen aufnehmen.
Hallo Andreas,
> ...Stil umgebaut...
ist so OK. Ich hätte nur gerne die "29" als #define. Man sieht somit
sofort dass die (1<<29) und die 29 im pio_set_output_value()
zusammengehören und nicht nur zufällig den geleichen Wert haben. Zudem
"wenn jemand auf die Idee kommt den Pin zu verlegen" muss man nur an
einer Stelle ändern.
U-Boot ist auf meiner Seite in dieser Form OK.
setenv/askenv: OK, aber nicht bis auf die 64kB des ENV ausgereizt.
printenv: OKI, zeigt sogar noch die "Ur-"Einstellungen aus der Fabrik
(soweit nicht geändert).
dhcp, tftp und nfs getestet, und ohne bootm würde ja gar nicht laufen
;-)
Das einzige das "Müll" anzeigt ist bdinfo. Das tut es aber beim NGW100
auch.
Und wenn du im Linux die Einstellung von
CONFIG_MMC_BLOCK=m
in
CONFIG_MMC_BLOCK=y
änderst, kann man auch von einer SD Karte booten.
P.S.
Vielleicht kannst du auch noch mein MAC aus der grasshopper_defconfig
rausnehmen. Sonst hat irgendwann fast jeder GH die gleiche MAC. ;-)
PPS.
Im Anhang der linux-2.6.27.grasshopper.1.patch. Hier schon mit
CONFIG_MMC_BLOCK=y ;-)
>CONFIG_MMC_BLOCK=y
Ist drin
>Vielleicht kannst du auch noch mein MAC aus der grasshopper_defconfig>rausnehmen. Sonst hat irgendwann fast jeder GH die gleiche MAC. ;-)
Geändert (das ist sicherlich nicht im Sinne der Erfinder, dass ein Rudel
von Geräten die gleiche MAC haben...)
>Im Anhang der linux-2.6.27.grasshopper.1.patch. Hier schon mit>CONFIG_MMC_BLOCK=y ;-)
Habe ich im angehängten Patch mit rein genommen, kompiliert und unter
TFTP/NFS gebootet - sieht gut aus. Nachteil hieran ist, dass die Atmel
Patches wg. der geänderten Versionsnummer fehlen. Wenn Atmel das
Buildroot mit dem neuen Kernel rausgibt haben wir das schon mal...
Die Atmel Patches fließen schon seit längerem direkt in die
Kernelentwicklung ein. Da der Final 2.6.27 erst wenige Wochen alt ist
dürfte es nur sehr wenige neue Patches geben.
Jedenfalls ist im 2.6.27 ein (im Vergleich zum 2.6.25.10-Atmel) neuer
Patch drin mit dem man endlich auch große Files auf SD schreiben kann
ohne dass sich die MCI Schnittstelle abhängt. ;#)
Hallo (ich schon wieder),
habe mal mit dem Kernel 2.6.27 rum gespielt (Boot aus Flash oder
TFTP/NFS -> gleiche Symptome):
1. Im Verlauf des Boot-Vorgangs fängt die LED2 asynchron zu LED1 an zu
blinken. Zunächst habe ich das für ein Feature gehalten aber
2. Im Verlauf von Debug-Sitzungen mit AVR32Studio (Standard wie in
Application Note AVR32015 beschrieben-SSH/FTP) schmiert der kleine
gnadenlos ab.
Mein Fazit: So (noch) nicht zu empfehlen.
Das Problem kann ich hier nicht nachvollziehen.
A) Ich vermute mal du hat nicht alles von vorne herein mit dem Kernel
2.6.27 "gebaut". Ich habe nach "grasshopper_defconfig" schon vor dem
ersten Build mit "menuconfig" auf Kernel Version 2.6.27 umgestellt. (
B) Oder es fehlen einfach die Pull-Up's an den SD-Karten Pins. Da du
dort nichts angeschlossen hast, solltest du die Unterstützung dafür in
deinem Kernel doch besser deaktivieren.
A) habe ich genauso gemacht
B) ich habe bisher nur den nackten grasshopper. Werde mal die SD-Karten
Untertützung deaktivieren. Was mich allerdings wundert: Den 'alten'
Kernel habe ich auch mit SD-Karten-Unterstützng getestet...
Hast Du wirklich keinen weiteren Patch verwendet?
Hallo Sebastian,
ist schon seltsam...
Es sollte eine Datei Makefile.orig (oder so ähnlich) erstellt worden
sein. Auch hilfreich ist die Datei '.applied_patches_list' Kannst Du die
mal als Anhang posten?
Wird in Deinem Buildroot versucht, U-Boot Version 1.3.4 zu erstellen?
P.S. Liege in den letzten Zügen beim Patch für buildroot 2.3.0-rc1. Bin
ja mal gespannt...
Mir kamen die Fehlermeldungen auch sehr komisch vor. Daraufhin habe ich
nochmals neu entpackt und make über Nacht laufen lassen. Heute morgen
war der build dann vollständing.
Ich vermute das beim Entpacken etwas schief gegangen ist. Modifiziert
habe ich keine der Dateien.
Bis dann,
Sebastian
Hallo alle,
Ich habe mich an einem Patch für buildroot 2.3.0 versucht, nur leider
scheitere ich an der verzwickten Ordnerstruktur. Ich habs geschafft
defconfig usw anzulegen und auch herausgefunden wie ich den Kernel
soweit anpasse -> Andreas' Datein nach
project_build_avr32/..-./linux-xx/arch/board/grasshopperxxx/ und
Makefiles angepasst. Ich glaub das habe ich noch alles "richtig"
gemacht. Aber wie erstelle ich jetzt den Patch um ihn als kernel-patch
im target/device.../kernel-patch unterzubringen?
Hallo Michael,
zu Deiner Mail:
Bitte poste in Zukunft die Anfragen ins Forum, weil
1. es sicherlich eine Menge Leute gibt, die von der Sache deutlich mehr
verstehen als ich (hatte im August meinen ersten Linux-Kontakt)
2. Diejenigen, die das gleiche Problem haben, auch davon profitieren
3. ich zu meiner Schande gestehen muss, dass ich z.Zt häufiger in den
Foren nach sehe, als meine Mails zu lesen (bitte kein Kommentar).
Ich vermute, Du hast die Kernelkonfiguration mit dem Namen
grasshopper_devel_config nicht in der Patch Datei für den Kernel (bei
V2.2.1 war das linux-2.6.27.grasshopper.1.patch) eingetragen. Dann weiß
buildroot nicht, wie es den Kernel konfigurieren soll und motzt. Das
ganze passiert bei UBoot, weil der zuerst kompiliert wird (wie gesagt
alles Vermutung).
Zu Deiner jetzigen Anfrage: Ich habe den Eindruck, wir machen beide das
gleiche, weil ich für 2.3.0 zwei defconfigs vorgesehen habe:
1. So wie bisher
2. mit LCD/keyboard/PWM/mplayer/samba
Das dumme ist nur, dass die zweite konfiguration noch komische Dinge
macht (kompilieren ist OK aber der Hüpfer 'humpelt' anstatt zu hüpfen)
Michael
ich hatte Deine letzte Frage nicht wirklich beantwortet:
1. Schau Dir den Inhalt von target/device/Atmel/grasshopper/*.patch mit
einem Texteditor an
2. man diff
3. Wenn ich eine neue Datei in einen vorhandenen Patch einfügen will,
gebe ich folgendes an: diff -rupN /dev/null NeueDatei > aaa. Den Inhalt
der Datei kopiere ich dann mit überarbeitetem Header in den vorhandenen
Patch (wenn jemand weiß, wie das einfacher geht bitte melden)
Hallo Andreas,
das mit dem PN und Forum ist immer so ein zweischneidiges Schwert.
Gerade wenn es so eine "spezielle" Frage ist finde ich ist eine PM
angebrachter.
Ja wir machen wahrscheinlich das selbe :) Habe im freaks-Forum schon
gesehn das du dran bist. Trotzdem wollte ich es "einmal" für mich
durchmachen um es dann für weitere Projekt bereits zu können.
Eventuell wäre es von Vorteil, wenn das Wiki dahingehend versucht wird
so zu erweitern um alle nötigen Schritte nachvollziehen zu können.
Die "defvonfig" usw anzulegen ist ja relativ straight forward. Aber
sobalds am Kernel frickeln geht wirds ungut. Woher hast du deine Infos
genommen?.
Gerade das mit dem Patch verstehe ich ned, so wie ich den Patch lese
veränderst du das atngw100 Verzeichnis. Kann das sein?
Danke schonmal für die Antwort mit dem Patch, soweit ich das verstehe
kann man das mit quilt "relativ" einfach lösen.
Gruß
Michael
Hallo Michael,
also:
Die einzigen Änderungen am Kernel finden sich am Ende des Patches: In
KConfig (für kernel menuconfig: die Doku zu menuconfig findet sich in
buildroot-avr32-v2.3.0-rc1/project_build_avr32/grasshopper/linux-2.6.27.
6/Documentation) und Makefile (damit der Compiler die board abhängigen
Dateien auch kompiliert - eine einführende Doku findet sich in
SelfLinux) wird der grasshopper in buildroot eingeklinkt.
Alle anderen Dateien werden unterhalb des Verzeichnisses
project_build_avr32 erzeugt. Eine Datei, die erzeugt wird erkennt man
daran, dass im Datenbereich nur '+' Einträge zu finden sind ('-' heißt
entfernen / ohne Vorzeichen findet eine Stelle in einer Datei).
Lass Dich nicht durch die NGW Verweise verwirren: Du könntest da
beliebige Verzeichnisse eintragen. Diese Information sagt nur, wie der
Patch (ursprunglich) erstellt worden ist.
Und damit kommen wir auch gleich dazu, woher ich meine Info habe: Den
wesentlichen Teil des Patches hat werner (siehe weiter oben) erstellt.
Frag den mal :-)
Ach - bevor ich's vergesse: Rudimentär beschreibt 'AVR32005 AVR32 AP7
How to add a custom board to Buildroot' wie wo was einzutragen ist.
Hallo an alle,
So bin gerade nochmal dazugekommen mir das mit dem Patch erstellen
anzusehen.
jetzt hab ich es begriffen glaub ich :)
Mir hat http://www.linuxchix.org/content/courses/kernel_hacking/lesson9
sehr gut auf die Sprünge geholfen. Jetzt kann ich mich an den schweren
Part machen, das wirkliche anpassen der Kernel Datein.
Vielen Dank nochmal Andreas.
Bei mir funktioniert buildroot 2.2.1 zusammen mit dem Patch 0.0.3 nicht.
Nach einer Weile wird libglib entpackt, das kompilieren schlägt fehl.
Und das, obwohl libglib eindeutig nicht benötigt wird und auch nicht
angewählt ist unter "select packages for the target".
Fehlermeldung:
echo "#ifndef __G_MARSHAL_H__" > xgen-gmh \
&& echo "#define __G_MARSHAL_H__" >> xgen-gmh \
&& /usr/bin/glib-genmarshal --nostdinc --prefix=g_cclosure_marshal
./gmarshal.list --header >> xgen-gmh \
&& echo "#endif /* _G_MARSHAL_H_ */" >> xgen-gmh \
&& (cmp -s xgen-gmh gmarshal.h 2>/dev/null || cp xgen-gmh gmarshal.h)
\
&& rm -f xgen-gmh xgen-gmh~ \
&& echo timestamp > stamp-gmarshal.h
/bin/bash: line 2: /usr/bin/glib-genmarshal: No such file or directory
Alles nur Vermutung :-)
Buildroot erstellt zunächst die Umgebung, um cross-compilieren zu
können. Es wird mindestens ein gcc (und vieles mehr) erzeugt. Dazu ist
allerdings eine gcc mit allerlei Tools auf deinen Entwicklungsrechner
notwendig.
Ich vermute Buildroot braucht glib auf deinem Entwicklungssystem (es
wird ja auch '/usr/bin/glib-genmarshal: No such file or directory'
angemeckert).
Befrag mal Deinen Paketmanager...
Mit apt-get install libglib2.0-dev geht's erstmal weiter, mal sehen, wie
weit...
Das Insekt kann einen wirklich in Atem halten.
Demnächst geht's bei mir mit dem ABDAC weiter, da hört man ja auch schon
von einigen Problemen mit einem aktuellen Kernel.
Hi,
Auszug aus ner Mail aus Liste:
>PPS! Users of AC97 and ABDAC must stay at Buildroot for AVR32 v2.2.1>since this release does not support these sound devices with the new>kernel 2.6.27.6.atmel.1. We have changed to the real deal DMA>framework, and still have some work to do with the sound drivers.>Hopefully I will have something ready early next year. The good side>is that the sound drivers will be ready for submission into upstream>Linux.
Wenn du bei 2.2.1 bleibst und nicht auf den neuen Kernel updatest
solltest du keine Probleme bekommen
Thread beobachten
Seitenaufteilung abschalten