Hallo,
ich versuche gerade, wie hier
Beitrag "AVR32 grasshopper patch für ATMEL buildroot 2.3.0"
beschrieben den buildroot zu kopilieren. Leider schlägt es fehl.
Leider weiß ich nicht, wo ich ansetzen muss zu suchen, da hier keine
Fehlerbeschreibung ausgegeben wird, die mir hilft.
ein erneutes make brachte folgende Ausgabe:
Kann mir jemand sagen, wo ich nach einer Lösung suchen sollte?
(ich nutze Arch-Linux, schließe deshalb einen Konflikt durch
unterschiedliche Pfade nicht aus.)
Bereits vorgenommene Änderungen:
ich musste bereits in der
./buildroot-avr32-v2.3.0_patched_grasshopper/toolchain_build_avr32/uClib
c-0.9.30/extra/scripts/unifdef.c
die Methode getline(void) in die Methode parseline(void) umbenennen, da
ein Konflikt mit der lib vorlag.
Weiterhin musste ich per ln den /bin/install auf /usr/bin/install legen.
Es wäre lieb, wenn jemand eine Idee hat!
Danke
Markus
wenn du schon Probleme mit Arch-Linux erkannt hast, warum wechselst du
nicht auf Ubuntu 8.04 (nicht die neueren Versionen nehmen, damit soll es
auch Probleme geben) ? Das wird von Atmel so vorgeschlagen und hat bei
mir immer gut funktioniert. Ok, ein paar Pakete müssen mit apt get
nachgeladen werden, aber das sagt dir dann buildroot.
Atmel hat ihren buildroot auf die Belange von Ubuntu zugeschnitten.
Sicher werden andere Pakete auch gehen, dann würde ich aber auf das
upstream-buildroot ausweichen. Das kannst du auch für den GH nehmen.
Musst im Kernel eben nur die Besonderheiten vom GH einstellen.
ok, danke, das hat mit ubuntu soweit funktioniert.
Ich habe den Grasshopper mittels NFS gestartet und wollte nun das neue
Image in den Flash schreiben. Leider wurde ich mit folgenden Problem
konfrontiert:
root@grasshopper:/tmp# dd if=rootfs.avr32.jffs2-root of=/dev/mtdblock2
bs=65535
dd: writing '/dev/mtdblock2': Operation not permitted
1+0 records in
0+0 records out
Ich weiß jedoch auch nicht, ob mein Vorgehen richtig ist.
In dem verlinkten Thread wird eine Wiki-Seite angegeben, die folgende
Angaben enthält:
Sind diese Werte richtig?
Ich dachte, das U-Boot-Environment käme direkt nach der
U-Boot-Pratition?
0x000000 - 0x01FFFF U-Boot partition. You'll need a JTAGICEmkII if
you corrupt this
0x020000 - 0x7EFFFF Linux root partition. (This is what we'll update
with this guide)
0x7F0000 - 0x7FFFFF U-Boot environment area. Handled by U-Boot.
ich habe im U-Boot einmal, bevor ich das nfs-System gestartet habe,
"protect off all" eingegeben, es blieb jedoch ohne Ergebnis.
Entweder per
> "protect off all"
Damit wäre ich vorsichtig. Wenn du dir uboot überschreibst brauchst du
einen JTAG-Brenner.Obwohl ich mir nicht sicher bin ob die Option "all"
funktioniert, ich kenne nur "adr1" bis "adr2"
Die Werte von der avrfreaks-Wiki beziehen sich auf das NGW100.
Hier hat sich schnitzeltony über NFS ausgelassen:
Beitrag "NFS mit grasshopper / AVR32"
Evtl. auch bei dir ein Rechteproblem? Unter wen hast den build gebaut?
Unter root?
>Ich dachte, das U-Boot-Environment käme direkt nach der>U-Boot-Pratition?
Beim Grashopper - Ja.
Beim NGW100 - Nein, da ist das Environment am Ende des Flash.
Ich habe immer versucht, alles als User zu kompilieren.
Die Dateien, die im nfs liegen, waren dann allerdings immer als root
erstellt.
Ich versuche jetzt einmal, das ganze als root zu kompilieren. Wieso ist
das eigentlich notwendig bzw. ist es das überhaupt?
kann mir jemand bitte die korrekten Einstellungen für den protect-Befehl
im uboot aufschreiben, ehe ich hier noch etwas falsch mache? Wäre echt
nett!
Danke schonmal!
Die Verwendung war mir schon klar, die Doku kannte ich auch, mir geht es
nur um die richtige Adresse - wann der Schutz aufhören sollte, damit ich
das Linux-Dateisystem einspielen kann, aber am uboot nichts kaputt
machen kann.
Ich zitiere mal aus dem AVR32-Grasshopper-Artikel:
"Die 8 MiB Flash-Speicher auf dem Board sind in drei Bereiche
aufgeteilt: In den untersten 128 kiB befindet sich der Bootloader
U-Boot. Der Bereich von 128 - 192 kiB ist für die Umgebungsvariablen
(environment) des Bootloaders reserviert. Das JFFS2-Dateisystem mit der
Linuxumgebung (root file system) belegt den Rest."
Ja, danke, aber das ist ja dann noch lange nicht die Adresse des
Speichers.
Meine Rechnung wäre
192*1024=196608 Byte
macht Hexadezimal 0x030000
Stimmt das?
Übrigens: altes Problem mit der per root kompilierten Umgebung.
Das ist auch nicht die neueste Version von uboot. Ich meine, die letzte
Version ist 1.3.4 .
Buildroot erstellt dir aber auch immer eine uboot.bin als aktuellste
Version.
Es wäre gut, die erst mal zu flashen. Aber Vorsicht, wenn dabei etwas
schief geht brauchst du einen JTAG. Die Anleitung dazu findest du in dem
Artikel von diesem Forum.
Du kannst natürlich auch das JFFS2-Dateisystem mit uboot flashen. Auch
die Anleitung dazu steht in dem Artikel.
hm, naja, uboot flashen - da traue ich mich nicht so richtig heran.
ich habe jetzt versucht per nfs das image in dn RAM zu laden
- per nfs wie vorher schon beschrieben - ERROR: Cannot umount
- per loadb:
1
SEND-class command failed.
2
Packets sent: 2
3
Retransmissions: 11
4
Timeouts: 0
5
Damaged packets: 0
6
Fatal Kermit Protocol Error: Too many retries
Ich gebe es bald auf - und das alles nur, auf der Suche nach einer
Lösung, ein magic paket versenden zu können!
sorry, verstehe ich jetzt nicht.Der GH wird doch schon fertig mit einem
bootfähigen Linux- build geliefert. Wolltest du jetzt noch zusätzliche
Pakete in deinen build einkompilieren?
Ja, genau, ich hatte versucht php einzukompilieren, weil das z.b. diese
Funktion erfüllt.
Mir würde es schon reichen, wenn etherwake oder ähnliches auf dem
grasshopper läuft.
Hallo,
> Markus Klemm (klemmi) wrote:> Datum: 03.09.2009 00:53> ICnova> setenv bootargs root=nfs nfsroot=192.168.2.102:/nfs> ip=192.168.2.5:192.168.2.102::255.255.255.0::eth0:none> ICnova> boot> [...]> root@grasshopper:......
Zu diesem Zeitpunkt hast du doch dein neues Filesystem über NFS
gebootet.
Also das klappt doch!
Du könntest jetzt deine Anwendungen starten.
Aber wenn du dein neues Fs ins flash brennen willst, müsste die
Befehlsfolge so aussehen:
Nach dem nächsten Reset ist protect wieder ON.
Mit dem brennen des neuen Fs ins flash würde ich aber warten, bis alles
so funktioniert, wie du dir das vorstellst.
Gruß
Udo
hm, das verstehe ich gerade nicht.
Wieso soll ich das root-fs als reedonly remounten?
Das liegt doch eh im nfs-Share oder ahbe ich jetzt einen Querdenker?
ne, sorry, du hast recht. Jetzt komm ich schon selbst durcheinander.
Irgendwas stimmt mit der Freigabe nicht. Evtl gibt uboot trotz "protect
off all" nicht alles frei. Ich würde uboot mal updaten.
Gruß
Udo
nach den ganzen Problemen, die ich beim falshen des normalen Linux schon
habe, habe ich irgendwie Skrupel davor, an uboot heranzugehen - ist das
wirklich die einzige Möglickeit?
Nein, sorry, auch das hat keinen Effekt.
Gibt es eine Möglichkeit Etherwake per Cross Compiler zu kompilieren und
auf den grasshopper zu kopieren?
avr-libc, avr-gcc?
