Im Prinzip ist mir auch klar, wofür die Dateien so jeweils da sind... -
vorallem werde ich das .jffs2 und das uImage brauchen.
So recht weiß ich aber gar nicht, wie ich das nun in den NAND Flash
einspielen kann - auf die U-Boot Konsole komme ich rauf und kann dort
Dateien per TFTP laden.
Aber woher weiß ich nun mit welchen Parametern genau ich mit "nand
write" die Daten schreiben kann?
Probiert hatte ich auch den neuen Kernel (uImage) schonmal zu booten,
und dazu nacheinander ausgeführt in der U-BootKonsole:
1
ICnova> setenv ipaddr 10.0.2.80
2
ICnova> setenv serverip 10.0.2.25
3
ICnova> tftp 200000 10.0.2.25:uImage
4
macb0: PHY present at 0
5
macb0: Starting autonegotiation...
6
macb0: Autonegotiation complete
7
macb0: link up, 100Mbps full-duplex (lpa: 0xc1e1)
8
Using macb0 device
9
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Das wird mir dann aber nur quittiert mit der Fehlermeldung unten.
So recht finde ich dazu nicht wirklich eine Anleitung, hat jemand
vielleicht einen Tipp?
Beste Grüße
Sven G. schrieb:> Das wird mir dann aber nur quittiert mit der Fehlermeldung unten.
Das Kommando "bootm" will noch wissen, an welcher Addresse sich das
uImage befindet. Da du es an 0x200000 geladen hast, sollte der Befehl
zum Starten des Kernels folgendermaßen aussehen:
1
bootm 0x200000
Damit solltest du schon einmal den Kernel booten können. Der wird aber
ne Panic werfen, wenn er kein rootfs findet.
Gruß Skriptkiddy
Skript Kiddy schrieb:> Das Kommando "bootm" will noch wissen, an welcher Addresse sich das> uImage befindet. Da du es an 0x200000 geladen hast, sollte der Befehl> zum Starten des Kernels folgendermaßen aussehen:>
1
> bootm 0x200000
2
>
>> Damit solltest du schon einmal den Kernel booten können. Der wird aber> ne Panic werfen, wenn er kein rootfs findet.
Leider bleibt der Fehler mit dem Parameter derselbe.
Dass es tatsächlich ein "wrong Format" ist kann ich schwer glauben, da
das gleiche passiert, wenn ich den vorinstallierten Kernel nehme (an den
ich ja rankomme und aus dem System auf den TFTP-Server kopieren kann,
wenn ich es normal boote vom Flash).
Am besten wäre es halt, wenn ich den von mir erstellten Kernel / Image
auf das Board aufspielen kann - am besten ohne, dass dann gar nichts
mehr geht.
Skript Kiddy schrieb:> Das Kommando "bootm" will noch wissen, an welcher Addresse sich das> uImage befindet.
Nein so klug ist das Kommando gerade noch das es die Adresse des letzen
Befehl nimmt wenn nichts angegeben ist. in denn fall ist also
Sven G. schrieb:> tftp 200000 10.0.2.25:uImage
was zum Geier lädst du da ?
laut deines Beitrages ist dein uImage eines von denn beiden
1
uImage-2.6.30-r6-at91sam9g45ekes.bin
2
uImage-at91sam9g45ekes.bin
außerdem hätte ich kannst du die Adresse des Server weglassen
die hast du schon mit set serverip eingespielt.
Ich hätte so was als TFTP Kommando erwartete
1
tftp 0x200000 uImage-at91sam9g45ekes.bin
Sven G. schrieb:> Wrong Image Format for bootm command> ERROR: can't get kernel image!
damit sagt dir uboot was immer du da geladen hast ist kein uImage,
deshalb will er es nicht starten.
sage mal auf dein Server im TFTP Verzeichnis
1
file uImage
dort müsste dann so was als Antwort kommen
1
uImage: u-boot/PPCBoot image
kann es sein das du von anderen versuchen irgendwas im auf den TFTP
server hast das uImage heißt aber was anderes ist ?
Generell finde ich dein Ansatz recht gut denn Kernel via TFTP zu laden
und gleich zu booten.
Erst wenn er beim Booten einen Ops wirft weil er kein rootfs hat dann
solltest du dir gedanken machen wie es weiter geht, nfsroot ist beim
etnwickeln schneller und du musst dich nicht mit solchen unwichtigen
Dingen wie platz auf denn Nand Flash rum schlagen ;-).
Das Schreiben in denn Nandflash macht IMHO erst dann sinn wenn du was
hast das auch mit TFTP und NFS schon geht.
Wie du das schreiben in denn NAND-Flash machst kann mn mit
unterschiedlichen Strategien machen,
aus den SAM-BA aus denn uboot oder sogar erst aus den laufenden Linux (
das via TFTP und NFS gebootet wurde.
aus den Uboot würde das Schrieben in den nand so gehen:
Analog dazu das jffs2 Filesystem. Wichtig das write.jffs2 beim Kernel
ist kein Fehler sondern Absicht damit der uboot prüft ob die
Speicherzelle Kaputt ist und diese ggf überspringt. die Namen die mit $
Anfangen musst du mit geigneten werten von dein System ersetzen.
Danke für deine Ausführung!
Imon schrieb:> Sven G. schrieb:>> tftp 200000 10.0.2.25:uImage>> was zum Geier lädst du da ?>> laut deines Beitrages ist dein uImage eines von denn beiden>>
1
> uImage-2.6.30-r6-at91sam9g45ekes.bin
2
> uImage-at91sam9g45ekes.bin
3
>
Ja, da hast du natürlich recht. Ich habe die Datei auf dem TFTP
entsprechend umbenannt, um etwas Tippen zu sparen ..
> außerdem hätte ich kannst du die Adresse des Server weglassen> die hast du schon mit set serverip eingespielt.> Ich hätte so was als TFTP Kommando erwartete>>
1
> tftp 0x200000 uImage-at91sam9g45ekes.bin
2
>
wunderbar, noch ein bisschen mehr Tippen sparen ;)
> Sven G. schrieb:>> Wrong Image Format for bootm command>> ERROR: can't get kernel image!>> damit sagt dir uboot was immer du da geladen hast ist kein uImage,> deshalb will er es nicht starten.>> sage mal auf dein Server im TFTP Verzeichnis>>
1
> file uImage
2
>
Antwort ist wie erwartet - auf dem System, wo der tftp-Server läuft:
1
foo@foo-desktop:/srv/tftp$ file uImage
2
uImage: u-boot/PPCBoot image
> kann es sein das du von anderen versuchen irgendwas im auf den TFTP> server hast das uImage heißt aber was anderes ist ?
ich denke nicht, da ich die uImage-at91sam9g45ekes.bin einfach per cp in
den Ordner des TFTP kopiert habe - und dort dann nur uImage genannt
habe.
> Generell finde ich dein Ansatz recht gut denn Kernel via TFTP zu laden> und gleich zu booten.
Finde ich auch... gern würde ich auch komplett per NFS erstmal booten
und den Flash so belassen wie er ist.
> Das Schreiben in denn Nandflash macht IMHO erst dann sinn wenn du was> hast das auch mit TFTP und NFS schon geht.> Wie du das schreiben in denn NAND-Flash machst kann mn mit> unterschiedlichen Strategien machen,> aus den SAM-BA aus denn uboot oder sogar erst aus den laufenden Linux (> das via TFTP und NFS gebootet wurde.>> aus den Uboot würde das Schrieben in den nand so gehen:>>
>> Analog dazu das jffs2 Filesystem. Wichtig das write.jffs2 beim Kernel> ist kein Fehler sondern Absicht damit der uboot prüft ob die> Speicherzelle Kaputt ist und diese ggf überspringt. die Namen die mit $> Anfangen musst du mit geigneten werten von dein System ersetzen.
Danke, werde ich mir merken ... aber würde erstmal gerne den Kernel per
tftp laden und direkt booten mit nfsroot....
Es ist definitiv ein uImage, was ich da per tftp lade.
Ich habe auch das Original-uImage zur Verfügung, auf das ich zugreifen
kann, wenn ich das vorinstallierte LInux boote - auch dieses führt zum
selben oben genannten Fehler, wenn ich es auf selbem Weg per tftp laden
& booten möchte.
Sven G. schrieb:> Danke, werde ich mir merken ... aber würde erstmal gerne den Kernel per> tftp laden und direkt booten mit nfsroot....
Eine gute Wahl die du da triffst
>> Es ist definitiv ein uImage, was ich da per tftp lade.>
Okay schade es hätte ja mal einfach sein können.
> Ich habe auch das Original-uImage zur Verfügung, auf das ich zugreifen> kann, wenn ich das vorinstallierte LInux boote - auch dieses führt zum> selben oben genannten Fehler, wenn ich es auf selbem Weg per tftp laden> & booten möchte.
Mh okay das rückt den Uboot und dein Netzwerk in den Mittelpunkt der
Betrachtungen.
Bist du sicher das die RAM Adresse 0x200000 richtig ist ? meine was von
von 0x2200000 oder so im Hinterkopf zu haben was das Atmel Ek Board
angeht, kann aber bei dir anders sein. kannst du mal dein uboot Env
ausgeben. und uns mitteilen.
1
ICnova> print
vielleicht findet sich hier ein Hinweis wie dein Board so was
normalerweise macht. Ausserdem interessiert mich bei der Gelegenheit was
du in der bootargs Variablen zu stehen hast. das wird sicher die nächste
Baustelle.
Imon schrieb:> Mh okay das rückt den Uboot und dein Netzwerk in den Mittelpunkt der> Betrachtungen.> Bist du sicher das die RAM Adresse 0x200000 richtig ist ? meine was von> von 0x2200000 oder so im Hinterkopf zu haben was das Atmel Ek Board> angeht, kann aber bei dir anders sein. kannst du mal dein uboot Env> ausgeben. und uns mitteilen.>>
1
> ICnova> print
2
>
>> vielleicht findet sich hier ein Hinweis wie dein Board so was> normalerweise macht. Ausserdem interessiert mich bei der Gelegenheit was> du in der bootargs Variablen zu stehen hast. das wird sicher die nächste> Baustelle.
So sieht das dann aus ... die 18m datas Partition bei mtdparts ist schon
mein Ergebnis vom Probieren/Experimentieren, das war vorher nicht so.
Sollte mit dem tftp/nfsboot aber denke ich wenig zu tun haben.
Interessant ist auch noch, dass es sich hier um ein UBIFS handelt....
aber im Moment klappts ja noch nichtmal mit dem Kernel, erst dann könnte
man sich ja ums rootfs kümmern.
Ich hoffe nicht, dass an der Hardware etwas defekt ist.
Nachtrag: Wenn ich 0x2200000 als Adresse verwende wie vorgeschlagen
bleibt das Laden hängen:
1
Using macb0 device
2
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Sven G. schrieb:> bootcmd=mtdparts default; nand read 0x70400000 nand0,0; bootm
da habne wir doch was , das board selber packt den Kernel welchen es
starten will nach 0x70400000, Porbiere also mal folgendes
1
ICnova> tftp 0x70400000 uImage
2
ICnova> bootm
denn bootargs parameter gehen wir dann später an :-)
der wird lauten müssen
1
ICnova> set console=ttyS0,115200,8n1 root=/dev/nfs/ nfsroot=10.0.2.25/<nfsrootdir> ip=dhcp
ICnova> set bootargs console=ttyS0,115200,8n1 root=/dev/nfs/ nfsroot=10.0.2.25/home/foo/icroot.2 ip=dhcp
22
ICnova> bootm
23
## Booting kernel from Legacy Image at 70400000 ...
24
Image Name: Angstrom/2.6.30/at91sam9g45ekes
25
Image Type: ARM Linux Kernel Image (uncompressed)
26
Data Size: 1718000 Bytes = 1.6 MB
27
Load Address: 20008000
28
Entry Point: 20008000
29
Verifying Checksum ... OK
30
Loading Kernel Image ... OK
31
OK
32
33
Starting kernel ...
Hier bleibt es dann leider hängen .... aber nur mit dem "eigenen"
Kernel.
Nachtrag: Vielleicht werden die Ausgaben auf eine falsche / nicht
sichtbare Konsole umgelenkt?
Mit dem Originalkernel kommen die ganzen Kernelmeldungen, und es bleibt
etwas später hängen:
1
....
2
NET: Registered protocol family 17
3
atmel_mci atmel_mci.0: Using dma0chan0 for DMA transfers
Root-NFS: Unable to get nfsd port number from server, using default
15
Looking up port of RPC 100005/1 on 0.0.0.0
Die Daten fürs nfsroot scheinen noch nicht zu passen mit 0.0.0.0 . aber
gäbe einen Ansatz zum Suchen.
Im Prinzip möchte ich ja aber ein selber erstelltes OpenEmbedded
nehmen...
Da scheint das at9121m9g45ekes nicht zum SAM9G45 zu passen? Ich hätte da
jetzt nicht allzu große Inkompatibilität zwischen vermutet.
Besten Dank, dass du dir die Zeit nimmst ;)
Sven G. schrieb:> ICnova> bootm> ## Booting kernel from Legacy Image at 70400000 ...> Image Name: Angstrom/2.6.30/at91sam9g45ekes> Image Type: ARM Linux Kernel Image (uncompressed)> Data Size: 1718000 Bytes = 1.6 MB> Load Address: 20008000> Entry Point: 20008000> Verifying Checksum ... OK> Loading Kernel Image ... OK> OK>> Starting kernel ...>> Hier bleibt es dann leider hängen .... aber nur mit dem "eigenen"> Kernel.
gut das ist der Punkt wo die Ausgaben vom Linux Kernel Kommen,
vielleicht ein falsches tty ? eingestellt
Sven G. schrieb:> IP-Config: Got BOOTP answer from 0.0.0.0, my address is 10.0.2.82
das BOOTP ist kommisch bei mit kommt die Meldung mit DHCP, kann es sein
das
du keinen DHCP Server hast, der rest könnte ein folgefehler hiervon
sein.
Sven G. schrieb:> Da scheint das at9121m9g45ekes nicht zum SAM9G45 zu passen? Ich hätte da> jetzt nicht allzu große Inkompatibilität zwischen vermutet.
DAS at91m9g45ekes ist das ATMEL Evalboard, SAM9G45 das ist von ic-board,
ich bin sicher die haben sich das AMTEL Board geschnappt und es an Ihre
Bedürfnisse angepasst. Flash RAM PHY und display sind die Heißen
Kanidaten
welche bei solchen aktionen gerne mal getauscht werden, denn RAM kannst
du ignorieren denn sollte der uboot für dich initialisieren. Phy scheint
auch unkritisch du kannst via TFTP booten,
Die beiden EKs sollten also zum großen teil Deckungsgleich sein
im zweifel von deinen Rechten gebrauch machen, die dir Die GPL einräumt
und dir von ic-board eine Patchqueue mit deren Änderungen an den ATMEL
Kernel geben lassen.
Imon schrieb:> Sven G. schrieb:>> ICnova> bootm>> ## Booting kernel from Legacy Image at 70400000 ...>> Image Name: Angstrom/2.6.30/at91sam9g45ekes>> Image Type: ARM Linux Kernel Image (uncompressed)>> Data Size: 1718000 Bytes = 1.6 MB>> Load Address: 20008000>> Entry Point: 20008000>> Verifying Checksum ... OK>> Loading Kernel Image ... OK>> OK>>>> Starting kernel ...>>>> Hier bleibt es dann leider hängen .... aber nur mit dem "eigenen">> Kernel.>> gut das ist der Punkt wo die Ausgaben vom Linux Kernel Kommen,> vielleicht ein falsches tty ? eingestellt>
habe einige durchprobiert .... also TTYSx mit verschiedenen x ... so
einfach ists leider nicht.
Am Rest bin ich erstmal dran und schaue was ich tun kann.
> DAS at91m9g45ekes ist das ATMEL Evalboard, SAM9G45 das ist von ic-board,> ich bin sicher die haben sich das AMTEL Board geschnappt und es an Ihre> Bedürfnisse angepasst. Flash RAM PHY und display sind die Heißen> Kanidaten> welche bei solchen aktionen gerne mal getauscht werden, denn RAM kannst> du ignorieren denn sollte der uboot für dich initialisieren. Phy scheint> auch unkritisch du kannst via TFTP booten,>> Die beiden EKs sollten also zum großen teil Deckungsgleich sein> im zweifel von deinen Rechten gebrauch machen, die dir Die GPL einräumt> und dir von ic-board eine Patchqueue mit deren Änderungen an den ATMEL> Kernel geben lassen.
hmm.. mal umschauen. Schade, dass das nicht so klappt.
Hallo,
vielleicht weiß nochmal jemand weiter oder hat einen guten Rat ...
vom Hersteller des SAM9G45 habe ich inzwischen die Info, dass
ungepatchte Kernel von OpenEmbedded auf diesem Board nicht lauffähig
sind... Daher dachte ich nun einfach den Originalkernel zu nehmen, aber
das Filesystem, das OpenEmbedded erzeugt als RootFS zu nehmen, also als
NFSroot zu mounten.
Ob das so recht geht, ... gerade am ausprobieren. Leider crasht das
ganze in kernel panic ziemlich direkt nach "Freeing init memory... "
Hätte jemand eine Idee, wo man die Ursache suchen könnte?
Es scheint als würde /sbin/init direkt crashen.
Die Datei an sich scheint i.O. zu sein, "file sbin/init" sagt dann
1
ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.16, dynamically linked (uses shared libs), stripped
Alle Meldungen:
1
ICnova> setenv ipaddr 10.0.2.80
2
ICnova> setenv serverip 10.0.2.25
3
ICnova> tftp 0x70400000 uImage
4
macb0: PHY present at 0
5
macb0: Starting autonegotiation...
6
macb0: Autonegotiation complete
7
macb0: link up, 100Mbps full-duplex (lpa: 0xc1e1)
8
Using macb0 device
9
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Thread beobachten
Seitenaufteilung abschalten