www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bootvorgang hängt bei "Freeing init memory: 80K"


Autor: Ade Phi (thadaeus)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hiho,

ich versuche ein ICnova ADB1000 mit ICnova AP7000 OEM in Betrieb zu 
nehmen.
Im Moment will ich ein neues Image aufspielen und dafür per NFS booten 
um es zu flashen.
Der Bootvorgang funktioniert bis zur Zeile
Freeing init memory: 80K (90000000 - 90014000)
und bleibt dort auf unbestimmte Zeit (>24h) hängen.

(vollständige Ausgabe des Bords über die UART in der angehängten Datei)

Einstellungen des bootloaders sind:
bootdelay=3
baudrate=115200
ethact=macb0
ethaddr=00:1F:E5:00:0A:87
ipaddr=192.168.1.8
bootcmd=nfs 0x10400000 $(serverip):/srv/icnova/boot/uImage;bootm
serverip=192.168.1.105
bootargs=nfsroot=192.168.1.105:/srv/icnova/ 
ip=192.168.1.8:192.168.1.105::255.255.255.0::eth0:none
stdin=serial
stdout=serial
stderr=serial

Host ist bei mir ein Ubuntu 9.04. In dem Zusammenhang hab ich im 
Internet gefunden das es möglicherweise daran liegt, das Ubuntu /bin/sh 
auf dash anstatt auf bash verlinkt. Dies habe ich ohne Erfolg geändert.

Autor: Soeren A. (abraxa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt fuer mich danach, als wuerde /sbin/init nicht gefunden. Existiert 
es?

Ansonsten wuerde ich bspw. mal 
http://www.avrfreaks.net/index.php?name=PNphpBB2&f... 
durchlesen, vielleicht ist etwas davon fuer dich hilfreich.

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
erstmal danke

/sbin/init existiert und verlinkt auf /bin/busybox

laut deinem link liegt es an den zugriffsrechten.
ich hab die mal komplett auf 777 geändert. Bringt leider keine 
Besserung.

Autor: Soeren A. (abraxa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich hab die mal komplett auf 777 geändert.

Nur zur Sicherheit: die des symlinks, von busybox oder beide?

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ganz brachial. mit komplett meinte ich alle dateien des images.
(ich weiß das das net schön ist, war nur ein test)

Autor: Soeren A. (abraxa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann weiss ich leider auch nicht mehr weiter, hab' noch nichts mit NFS 
gemacht :(

Weiter googeln bzw. auf mailing lists fragen ist wohl der beste Tip, den 
ich noch geben kann.

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nuja, trotzdem Danke ;-)

Das mit dem googeln versuch ich nu schon seit 3 Wochen. Aber dann schaun 
ich mal nach ner Mailinglist.

Und nochmal Danke.
Gruß
Ade

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne mich zwar mit arm nicht aus, aber etwas mit root over nfs....

Reagiert die kiste noch auf ping?
exestiert /srv/icnova/dev/console auf dem Server?
Zeig mal /etc/exports des Servers.
Was sagt der kern.log des Server beim mounten vom NFS root?
ls -l /srv/icnova/sbin/init hätte ich auch gerne mal gesehen.

In den commandline Parametern vom Kernel habe ich kein console= 
gefunden...

Um zu Prüfen ob Init überhaupt ausgeführt wird, könnest du ja
mal mit init=/sbin/reboot die kiste zum "auto" neustart animieren.
Sollte er neustarten, funktioniert zumindest mal das NFS root.

Fast vergessen: /srv/icnova/etc/inittab solltest du auch noch posten.

Autor: Benjamin A. (beni0664)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Also für mich sieht es auf den ersten Blick so aus als würdest du deinem 
Bootloader sagen, er soll über NFS booten...

Ich hatte den Grasshopper und habe immer vom Flash gebootet...

Nur irritiert mich dass du in deinem Config File in folgender Zeile:

ip=192.168.1.8:192.168.1.105::255.255.255.0::eth0:none


anscheinend dem Interface none die server IP zuweist...


Korrigiert mich falls ich mich irre!

mfg beni

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich will über NFS booten.

Die Angaben zum NFS Booten kommen auch direkt so von In-Circuit
auch die Zeile die Benjamin seltsam findet (find ich auch ein wenig 
seltsam).

Die Hinweise von Tim werd ich morgen mal nach der Arbeit testen.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Syntax ist das ok:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
ip=192.168.1.8:192.168.1.105::255.255.255.0::eth0:none
http://www.kernel.org/doc/Documentation/filesystem...

Die von der Kernel benutzte Netzwerk config sollte funktionieren:
IP-Config: Complete:
     device=eth0, addr=192.168.1.8, mask=255.255.255.0, gw=255.255.255.255,
     host=192.168.1.8, domain=, nis-domain=(none),
     bootserver=192.168.1.105, rootserver=192.168.1.105, rootpath=

root mount geht auch noch:
Looking up port of RPC 100003/2 on 192.168.1.105
eth0: link up (100/Full)
Looking up port of RPC 100005/1 on 192.168.1.105
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 80K (90000000 - 90014000)
Ab hier sollte init die Kontrolle übernehmen...
Nur das tut er nicht. Oder man sieht es nicht.
Ich Tippe mal auf 2. und würde zu console=ttyS0,115200n8 raten.
Zwar erwähnt die Kernel das sie ttyS0 automatisch als console verwendet,
aber ich weiss nicht, ob das beim starten von init abgeschaltet wird.

Sollte console=... nix bringen ist vermutlich /dev kaputt.

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hiho,

zu Tims Anregungen von gestern.

  Reagiert die kiste noch auf ping?
--> Nein

  exestiert /srv/icnova/dev/console auf dem Server?
--> ja, existiert

  Zeig mal /etc/exports des Servers.
--> /srv/icnova                  *(rw,sync,no_root_squash,subtree_check)
--> im normalen betrieb kann ich auch das verzeichnis mounten,
--> beim booten gibt er zudem ja auch die meldung aus, das er gemountet 
--> hat.

  Was sagt der kern.log des Server beim mounten vom NFS root?
--> wo sollte die kern.log liegen?

  ls -l /srv/icnova/sbin/init hätte ich auch gerne mal gesehen.
--> lrwxrwxrwx 1 root root 14 2009-10-04 16:12 /srv/icnova/sbin/init -> 
../bin/busybox

  In den commandline Parametern vom Kernel habe ich kein console=
  gefunden...
--> Auf was sollte console gesetzt werden?

  Um zu Prüfen ob Init überhaupt ausgeführt wird, könnest du ja
  mal mit init=/sbin/reboot die kiste zum "auto" neustart animieren.
  Sollte er neustarten, funktioniert zumindest mal das NFS root.
--> bleibt an selber stelle hängen

  Ich Tippe mal auf 2. und würde zu console=ttyS0,115200n8 raten.
  Zwar erwähnt die Kernel das sie ttyS0 automatisch als console 
verwendet,
  aber ich weiss nicht, ob das beim starten von init abgeschaltet wird.
--> Wo genau was einstellen? Tapp an der stelle grad im dunkeln.

Vielen Dank bis dahin

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hiho,

also im Moment glaub ich, daß die mitgelieferte CD von icnova nen Schlag 
hat. Hab mir die Dateien von der CD mal genauer angeschaut und ein 
ganzer Haufen wird da net ordentlich kopiert. Auch bei dem erzeugte 
Image sind haufenweise Dateien dabei, die 0byte als Größe haben. Bei nem 
neuen Image das ich gemacht habe auch die /dev/console und ein paar 
andere.

Insofern geh ich mal davon aus, dass Tims Vermutung das mit dem Image 
was net stimmt in die richtige Richtung geht.

Ich schau mal das ich ne neue CD bekomm.
Also nochmal Danke. Hat mir sehr weitergeholfen ;-)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Reagiert die kiste noch auf ping?
>--> Nein
Ganz schlecht. Spricht dafür das die kernel vor/beim starten von
init abschmiert.

>  exestiert /srv/icnova/dev/console auf dem Server?
>--> ja, existiert
ok.

>  Zeig mal /etc/exports des Servers.
>--> /srv/icnova                  *(rw,sync,no_root_squash,subtree_check)
Sollte funktionieren.

>--> im normalen betrieb kann ich auch das verzeichnis mounten,
>--> beim booten gibt er zudem ja auch die meldung aus, das er gemountet
>--> hat.

hmm... "im normalen betrieb" heist booten vom flash?
Dann könntest du ja mal via flash booten und das
nfs root filesystem nach /mnt mounten. Danach testweise
die /mnt/bin/sh oder gar /mnt/sbin/init starten.
sofern der chroot Befehl vorhanden ist könntest du auch chroot /mnt
testen. Dann wüste man zumindest mal ob das rootfs vom server ok ist.


>  Was sagt der kern.log des Server beim mounten vom NFS root?
>--> wo sollte die kern.log liegen?
Unter /var/log/ auf dem Server. Je nach syslog Konfiguration
kann die Datei auch anders heißen.

>  ls -l /srv/icnova/sbin/init hätte ich auch gerne mal gesehen.
>--> lrwxrwxrwx 1 root root 14 2009-10-04 16:12 /srv/icnova/sbin/init ->
>../bin/busybox
ok.

>[init=/sbin/reboot]
>--> bleibt an selber stelle hängen
Schade. Deutet wie ping auf einen kernel crash.
Andere Kernel versuchen?

>[console=...]
>--> Auf was sollte console gesetzt werden?
>--> Wo genau was einstellen? Tapp an der stelle grad im dunkeln.

Als kernelparameter im uboot (wie init=...).
console=ttyS0,115200n8 legt als default console ttyS0 (=1. Serielle
Schnittstelle) mit 115KBaud 8Bit und ohne Parity fest.
Das selbe scheint auch uboot zu verwenden.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>also im Moment glaub ich, daß die mitgelieferte CD von icnova nen Schlag
>hat. Hab mir die Dateien von der CD mal genauer angeschaut und ein
>ganzer Haufen wird da net ordentlich kopiert. Auch bei dem erzeugte
>Image sind haufenweise Dateien dabei, die 0byte als Größe haben. Bei nem
>neuen Image das ich gemacht habe auch die /dev/console und ein paar
>andere.

0 Byte unter /dev sind OK. Aber es sollten sogenannte Gerätedateien
sein. Zeig mal (auszugsweise) ls -l von diesem /dev

0 Byte in /bin /sbin /usr/bin /usr/sbin ist auch ok, sofern das
symbolische links auf die busybox sind und diese die entsprechenden
befehle auch unterstützt.

>Insofern geh ich mal davon aus, dass Tims Vermutung das mit dem Image
>was net stimmt in die richtige Richtung geht.

Per Flash hochziehen, nfs mounten und per chroot testen.

>Also nochmal Danke. Hat mir sehr weitergeholfen ;-)

Bitte, aber noch klappts nicht....

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so,

von flash gebootet, versucht zu mounten, bekomme als Ausgabe einen 
BusError, den hatte ich früher schon mal, wenn ich versucht hab über NFS 
zu booten, hab ihn dort aber wegbekommen, weiß nu aber nicht mehr, ob 
durch setzen von zugriffsrechten oder durch was anderes.

Ausgabe über die UART ist folgende:

######################################################################## 
##

Oops: Unhandled exception in kernel mode, sig: 7 [#1]
chip: 0x01f:0x1e82 rev 2
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat
PC is at nsm_get_handle+0x1b8/0x260
LR is at ktime_get_ts+0x34/0x40
pc : [<900ad1bc>]    lr : [<9002a8e4>]    Tainted: G        W
sp : 93ae3cc8  r12: 939d7169  r11: 000000ec
r10: a24fde1e  r9 : 00000000  r8 : 13fe2e1e
r7 : 939d70c0  r6 : 939d7159  r5 : 939d70d4  r4 : 93a4cc0c
r3 : 0000000d  r2 : 00000000  r1 : 939d70c0  r0 : 93ab1fc0
Flags: qvnzc
Mode bits: hjmde....g
CPU Mode: Supervisor
Process: mount [929] (task: 93a33400 thread: 93ae2000)
Stack: (0x93ae3cc8 to 0x93ae4000)
3cc0:                   00000010 000003f8 13fe2e1e 900aa590 93ab1fc0 
00000000
>[...Ausgabe von mir gekürzt...]
3fe0: 2ab04e58 7feb5950 00000000 7feb5950 0004f34c 00000021 00000000 
7feb5e92
Call trace:
 [<900aa590>] nlm_lookup_host+0x1f4/0x388
 [<900aa876>] nlmclnt_lookup_host+0x76/0x90
 [<900a93fc>] nlmclnt_init+0x28/0x38
 [<9008d978>] nfs_start_lockd+0x50/0x6c
 [<9008e766>] nfs_create_server+0x1d6/0x3e0
 [<9012ce20>] sock_recvmsg+0x60/0x74
 [<9012d9b2>] sock_common_recvmsg+0x0/0x30
 [<90057c42>] __d_lookup+0x66/0xa0
 [<90052bb0>] do_lookup+0x10/0xe8
 [<90052bc8>] do_lookup+0x28/0xe8
 [<90053d0e>] __link_path_walk+0x53a/0x81a
 [<90053f26>] __link_path_walk+0x752/0x81a
 [<9009bd84>] nfs_v3_clientops+0x0/0x90
 [<90094f7a>] nfs_get_sb+0x3c8/0x5da
 [<9004336e>] kstrdup+0x1e/0x30
 [<9004f552>] vfs_kern_mount+0x2e/0x58
 [<90094bb2>] nfs_get_sb+0x0/0x5da
 [<9004f5aa>] do_kern_mount+0x1e/0x8c
 [<9005b538>] do_mount+0x448/0x47c
 [<9005b5c0>] sys_mount+0x54/0x84
 [<90013130>] syscall_return+0x0/0x12

atmel_lcdfb atmel_lcdfb.0: atmel_lcdfb_pan_display

######################################################################## 
##

hab das image mal auf ne sd card kopiert (nur um das image überhaupt mal 
verifizieren zu können) und kann dort auch sh ausführen, landet dann 
halt wieder am prombt, was für mich zumindest logisch ist.

bei sbin/init bekomme ich folgende ausgabe.

->$ init
->BusyBox v1.5.0 (2008-11-24 13:52:40 CET) multi-call binary
->
->Usage: init [-c n] [-n]

chroot würd ich gern testen, nur wie stüzrt ich das zurück, wenn was 
schiefgeht. Hab keinen Flash programmer da um mir ein image neu 
aufzuspielen, wenn icd das aufm board zerschiessen sollte.

>  Was sagt der kern.log des Server beim mounten vom NFS root?
Im kern.log sehe ich nichts, was mit dem board zu tun haben könnte.
Zu den Zeiten als ich über NFS-Boot versucht habe zu mounten, oder nach 
einem Flash Boot. Ist nichts eingetragen worden.

Also letzter Stand:

Booten von Flash:
Beim versuch zu mounten kommt "Bus Error" als Ausgabe auf der Konsole.
(das ging aber auch mal fehlerfrei)

Booten von NFS:
Immer noch: Freeing init memory: 80K (90000000 - 90014000)

Update: Bei booten von Flash bekomme ich jetzt nach ca 10 Sekunden der 
Freeing... Nachricht ein "nfs: server 192.168.1.101 not responding, 
still trying" Die Meldung ist auch nichts neues, hatte ich auch schonmal 
und auch wegbekommen. Kann mich aber leider auch grad nicht mehr 
erinnern wie.

würde versuchen, das Image auf der SD-Karte mit chroot einzubinden, wenn 
mir wer sagt, wie ich das wieder rückgängig machen kann, wenns 
schiefgeht.

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, da scheints den Kernel ja wohl wirklich zu zerlegen.
Mit denen im Oops angegebenen Informationen kannst du aber mit 
erstaunlicher Genauigkeit auf die entsprechende Codezeile zeigen.
Die Funktion in der es schiefgeht, kennst du schon: nlm_lookup_host

Falls dir bei der noch nix ins Auge springt, gibt es hier eine recht 
abgefahrene Anleitung:
http://kerneltrap.org/mailarchive/linux-kernel/200...
Funktioniert wirklich!
Du kannst aber auch den gdb über vmlinux schrubbeln lassen, falls der 
Kernel mit Debugsymbolen kompiliert wurde.

Hugh!

Autor: ozo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pardon, nlm_lookup_host ruft nsm_get_handle und da knallts dann.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ausgabe über die UART ist folgende:
>Oops: Unhandled exception in kernel mode, sig: 7 [#1]

Oh, die kernel schmiert ab. Dann sollte man dem mal hinterher steigen.

>hab das image mal auf ne sd card kopiert (nur um das image überhaupt mal
>verifizieren zu können) und kann dort auch sh ausführen, landet dann
>halt wieder am prombt, was für mich zumindest logisch ist.

jo. ergo scheint die busybox ja zu funtionieren und damit auch init.

>bei sbin/init bekomme ich folgende ausgabe.

auch ok.

>chroot würd ich gern testen, nur wie stüzrt ich das zurück, wenn was
>schiefgeht. Hab keinen Flash programmer da um mir ein image neu
>aufzuspielen, wenn icd das aufm board zerschiessen sollte.

chroot startet /bin/sh unter dem angegebenen neuen root filesystem.
root (/) wird nur für diese /bin/sh umgehangen. Nach beenden
landest du wieder am alten prompt.
Also SD-Karte unter /mnt einhängen, dann chroot /mnt.
Der Prompt der dann kommt läuft vollständig von der SD-Karte.
Nur mit beenden der shell kommst du da wieder raus.

>>  Was sagt der kern.log des Server beim mounten vom NFS root?
>Im kern.log sehe ich nichts, was mit dem board zu tun haben könnte.
>Zu den Zeiten als ich über NFS-Boot versucht habe zu mounten, oder nach
>einem Flash Boot. Ist nichts eingetragen worden.

Sorry, mein Fehler. Das gesuchte sollte sich in /var/log/syslog finden.


>Booten von Flash:
>Beim versuch zu mounten kommt "Bus Error" als Ausgabe auf der Konsole.
>(das ging aber auch mal fehlerfrei)
>Booten von NFS:
>Immer noch: Freeing init memory: 80K (90000000 - 90014000)

Ergo du hast ein dickes NFS Problem.
Versuch doch mal no_auth_nlm als option in /etc/exports.
Sollte da nicht helfen und der syslog nichts brauchbares auswerfen,
musst du mal dem crash nachgehen....

>Update: Bei booten von Flash bekomme ich jetzt nach ca 10 Sekunden der
>Freeing... Nachricht ein "nfs: server 192.168.1.101 not responding,
>still trying" Die Meldung ist auch nichts neues, hatte ich auch schonmal
>und auch wegbekommen. Kann mich aber leider auch grad nicht mehr
>erinnern wie.

ip= und/oder nfsroot= noch im uboot gesetzt? root= fehlt?

>würde versuchen, das Image auf der SD-Karte mit chroot einzubinden, wenn
>mir wer sagt, wie ich das wieder rückgängig machen kann, wenns
>schiefgeht.

Wie gesagt, der neue fs-root gilt nur für das von chroot gestartet 
programm (/bin/sh) (und dessen Kinder). Der rest des Systems bleibt
so wie er ist.

Autor: Ade Phi (thadaeus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hiho,

hat leider ein wenig gedauert, war übers Wochenende nicht da.

Dann schau mer mal...

chroot hab ich gemacht, Ausgabe ist

$ chroot /mnt/sd/
BusyBox v1.13.2 (2009-10-07 18:25:24 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off

Als weiteres hab ich dann mal die "no_auth_nlm"
 in die exports geschrieben und dazu noch ins syslog geschaut, wenn das 
board versucht zu mounten (flash gebootet)

Oct 12 18:22:17 freya mountd[3041]: authenticated mount request from 
192.168.1.106:647 for /srv/icnova (/srv/icnova)
Oct 12 18:22:31 freya mountd[3041]: authenticated mount request from 
192.168.1.106:648 for /srv/icnova (/srv/icnova)

Board stirbt mit BusError

Dann nochmal versucht über NFS zu booten. Folgende Einträge im Syslog:

Oct 12 18:24:55 freya mountd[3041]: authenticated mount request from 
192.168.1.8:1000 for /srv/icnova/boot (/srv/icnova)
Oct 12 18:25:04 freya mountd[3041]: authenticated mount request from 
192.168.1.8:950 for /srv/icnova (/srv/icnova)

(Nicht wegen den IPs wundern, bootet board von flash bekommt es die per 
dhcp, bei NFS geht DHCP nicht und es bekommt fest die 8 vergeben.)

>ip= und/oder nfsroot= noch im uboot gesetzt? root= fehlt?
Aufgrund der Zeile poste ich gleich mal alle envs, die mir uboot mit 
printenv ausgibt. Vielleicht hab ich da ja was verbrezelt. root= 
entdecke ich da zum Beispiel nirgends. muss das allgemein gesetzt werden 
oder nur, wenn der Pfad von / abweicht?

bootdelay=3
baudrate=115200
ethact=macb0
ethaddr=00:1F:E5:00:0A:87
mtdids=nor0=physmap-flash.0
ipaddr=192.168.1.8
serverip=192.168.1.101
bootargs=nfsroot=192.168.1.101:/srv/icnova 
ip=192.168.1.8:192.168.1.101::255.255.255.0::eth0:none
bootcmd=nfs 0x10400000 $(serverip):/srv/icnova/boot/uImage; bootm
stdin=serial
stdout=serial
stderr=serial

@ozo:
du springst mir ein paar ecken zu weit. ich seh nicht den Zusammenhang 
zwischen vmlinuz debuggen und meinem problem. Bin Embedded Linux 
anfänger.
Aber ich les mich mal in vmlinuz ein, dann wirds vielleicht klarer. 
Danke jedenfalls.

Autor: Jens K. (irimi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ade Phi schrieb:
> so,
>
> von flash gebootet, versucht zu mounten, bekomme als Ausgabe einen
> BusError, den hatte ich früher schon mal, wenn ich versucht hab über NFS
> zu booten, hab ihn dort aber wegbekommen, weiß nu aber nicht mehr, ob
> durch setzen von zugriffsrechten oder durch was anderes.
>
> Ausgabe über die UART ist folgende:
>
> ######################################################################## ##
>
> Oops: Unhandled exception in kernel mode, sig: 7 [#1]
> chip: 0x01f:0x1e82 rev 2


Das gleiche Problem hatte ich auch und dürfte ein Bug des bereits 
installierten icnova kernels auf dem oemplus board sein. Jedenfalls 
tritt bei mir mit einem anderen Kernel das Problem nicht mehr auf und 
ich kann nun nfs mounten.

Abhilfe:
1. neuen Kernel bauen mH der gelieferten icnova buildroot Umgebung;
cp oemplus.config .config
make
2. nur den Kernel per bootloader/nfs laden :
nfs 10400000 $(serverip):/nfs/uImage
bootm
3. anschließend funktioniert dann auch ein
mount -t nfs [serverip]:/nfs /mnt/nfs
4. Dann am besten den neuen Kernel flashen mit
dd if=/mnt/nfs/uImage of=/dev/mtdblock0 bs=131072

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.