mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ADB1003 + SAM9G45 mit OpenEmbedded in NAND flash


Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

auf ein ADB1003 mit SAM9G45 (ARM9) würde ich gerne ein erstelltes 
OpenEmbedded aufspielen.

Dazu habe ich viele Dateien wie:
Angstrom-minimalist-image-eglibc-ipk-next-at91sam9g45ekes.rootfs.jffs2  modules-2.6.30-r6-at91sam9g45ekes.tgz
Angstrom-minimalist-image-eglibc-ipk-next-at91sam9g45ekes-testlab       u-boot-at91sam9g45ekes-2009.11-r1.bin
at91bootstrap.bin                                                       u-boot-at91sam9g45ekes.bin
at91sam9g45df-dataflashcardboot-2.13-r1.bin                             uImage-2.6.30-r6-at91sam9g45ekes.bin
at91sam9g45ek-dataflashcardboot-2.13-r1.bin                             uImage-at91sam9g45ekes.bin
at91sam9g45nf-nandflashboot-2.13-r1.bin                                 Utilities
minimalist-image-at91sam9g45ekes.jffs2

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:
ICnova> setenv ipaddr 10.0.2.80
ICnova> setenv serverip 10.0.2.25
ICnova> tftp 200000 10.0.2.25:uImage
macb0: PHY present at 0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc1e1)
Using macb0 device
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Filename 'uImage'.
Load address: 0x200000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########
done
Bytes transferred = 1718064 (1a3730 hex)
ICnova> bootm
Wrong Image Format for bootm command
ERROR: can't get kernel image!
ICnova>

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

Autor: Oliver Ju. (skriptkiddy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
>
> bootm 0x200000
> 
>
> 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.

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
bootm 0x200000

und
bootm 

identisch.

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
uImage-2.6.30-r6-at91sam9g45ekes.bin
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
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
file uImage

dort müsste dann so was als Antwort kommen
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:
 ICnova> tftp $kernelLoadAddr uImage-2.6.30-r6-at91sam9g45ekes.bin
 ICnova> nand erase $Flashaddr $filesize
 ICnova> nand write.jffs2 $kernelLoadAddr $Flashaddr $Flashblocksize

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.

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
>
>
> uImage-2.6.30-r6-at91sam9g45ekes.bin
> uImage-at91sam9g45ekes.bin
> 


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
>
>
> tftp 0x200000 uImage-at91sam9g45ekes.bin
> 

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
>
>
> file uImage
> 

Antwort ist wie erwartet - auf dem System, wo der tftp-Server läuft:
foo@foo-desktop:/srv/tftp$ file uImage
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:
>
>
>  ICnova> tftp $kernelLoadAddr uImage-2.6.30-r6-at91sam9g45ekes.bin
>  ICnova> nand erase $Flashaddr $filesize
>  ICnova> nand write.jffs2 $kernelLoadAddr $Flashaddr $Flashblocksize
> 
>
> 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.

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
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.

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
>
> 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.
ICnova> print
bootdelay=3
baudrate=115200
ethact=macb0
mtdids=nand0=nand.0
bootcmd=mtdparts default; nand read 0x70400000 nand0,0; bootm
ethaddr=00:1F:E5:00:1F:34
bootargs=root=ubi0:root rootfstype=ubifs ubi.mtd=2
partition=nand0,0
mtddevnum=0
mtddevname=kernel
mtdparts=mtdparts=nand.0:2m(kernel),16m(root),18m(datas)
stdin=serial
stdout=serial
stderr=serial
filesize=1A3730
fileaddr=200000
ipaddr=10.0.2.80
serverip=10.0.2.25

Environment size: 414/131068 bytes

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:
Using macb0 device
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Filename 'uImage'.
Load address: 0x2200000
Loading: #

und läuft nicht weiter ....

Das Board ist ganz genau dieses hier: 
http://www.ic-board.de/product_info.php?info=p105_... 
mit dem ADB1003 aus demselben Shop

(wie auch im Threadtitel steht)

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
ICnova> tftp 0x70400000 uImage
ICnova> bootm

denn bootargs parameter gehen wir dann später an :-)

der wird lauten müssen
ICnova> set console=ttyS0,115200,8n1 root=/dev/nfs/ nfsroot=10.0.2.25/<nfsrootdir> ip=dhcp

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arg war zu schnell muss der nfs boot Parameter muss natürlich
ICnova> set bootargs console=ttyS0,115200,8n1 root=/dev/nfs/ nfsroot=10.0.2.25/<nfsrootdir> ip=dhcp

sein.

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Imon schrieb:
> Arg war zu schnell muss der nfs boot Parameter muss natürlich
>
>
> ICnova> set bootargs console=ttyS0,115200,8n1 root=/dev/nfs/
> nfsroot=10.0.2.25/<nfsrootdir> ip=dhcp
> 
>
> sein.



Wow, das half tatsächlich - einen Schritt weiter - Danke:

So sieht die ganze AUsgabe nun aus:
Hit any key to stop autoboot:  0
ICnova> setenv ipaddr 10.0.2.80
ICnova> setenv serverip 10.0.2.25
ICnova> tftp 0x70400000 uImage
macb0: PHY present at 0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc1e1)
Using macb0 device
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Filename 'uImage'.
Load address: 0x70400000
Loading: #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    ###########
done
Bytes transferred = 1718064 (1a3730 hex)
ICnova> set bootargs console=ttyS0,115200,8n1 root=/dev/nfs/ nfsroot=10.0.2.25/home/foo/icroot.2 ip=dhcp
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.

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:
....
NET: Registered protocol family 17
atmel_mci atmel_mci.0: Using dma0chan0 for DMA transfers
atmel_mci atmel_mci.0: Atmel MCI controller at 0xfff80000 irq 11, 1 slots
Sending BOOTP requests . OK
IP-Config: Got BOOTP answer from 0.0.0.0, my address is 10.0.2.82
IP-Config: Complete:
     device=eth0, addr=10.0.2.82, mask=255.255.0.0, gw=10.0.0.1,
     host=10.0.2.82, domain=.lan, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
Looking up port of RPC 100003/2 on 0.0.0.0
eth0: link up (100/Full)
rpcbind: server 0.0.0.0 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
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 ;)

Autor: Imon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven G. (jordinar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.16, dynamically linked (uses shared libs), stripped

Alle Meldungen:
ICnova> setenv ipaddr 10.0.2.80
ICnova> setenv serverip 10.0.2.25
ICnova> tftp 0x70400000 uImage
macb0: PHY present at 0
macb0: Starting autonegotiation...
macb0: Autonegotiation complete
macb0: link up, 100Mbps full-duplex (lpa: 0xc1e1)
Using macb0 device
TFTP from server 10.0.2.25; our IP address is 10.0.2.80
Filename 'uImage'.
Load address: 0x70400000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #############
done
Bytes transferred = 2062552 (1f78d8 hex)
ICnova> set bootargs console=ttyS0,115200,8n1 root=/dev/nfs nfsroot=10.0.2.25:/home/foo/icroot.2 ip=10.0.2.80:10.0.2.25::::eth0:none init=/sbin/init
ICnova> bootm
## Booting kernel from Legacy Image at 70400000 ...
   Image Name:   Linux-2.6.33-rc4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2062488 Bytes =  2 MB
   Load Address: 70008000
   Entry Point:  70008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
.... gekürzt
....
IP-Config: Complete:
     device=eth0, addr=10.0.2.80, mask=255.0.0.0, gw=255.255.255.255,
     host=10.0.2.80, domain=, nis-domain=(none),
     bootserver=10.0.2.25, rootserver=10.0.2.25, rootpath=
Looking up port of RPC 100003/2 on 10.0.2.25
Looking up port of RPC 100005/1 on 10.0.2.25
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 152K
eth0: link up (100/Full)
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[<c0032748>] (dump_backtrace+0x0/0x10c) from [<c03054b4>] (dump_stack+0x18/0x1c)
 r7:c7815c40 r6:c7815c40 r5:c781fee4 r4:00000004
[<c030549c>] (dump_stack+0x0/0x1c) from [<c03054f4>] (panic+0x3c/0x128)
[<c03054b8>] (panic+0x0/0x128) from [<c0048040>] (do_exit+0x6c/0x5c8)
 r3:c03e1c40 r2:60000093 r1:c781fd24 r0:c0385f8a
[<c0047fd4>] (do_exit+0x0/0x5c8) from [<c004862c>] (do_group_exit+0x90/0xc4)
[<c004859c>] (do_group_exit+0x0/0xc4) from [<c0052fa4>] (get_signal_to_deliver+0x2e8/0x320)
 r4:00000004
[<c0052cbc>] (get_signal_to_deliver+0x0/0x320) from [<c0031168>] (do_notify_resume+0x60/0x5f0)
[<c0031108>] (do_notify_resume+0x0/0x5f0) from [<c002eee8>] (work_pending+0x1c/0x20)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.