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.
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&file=viewtopic&t=81292 durchlesen, vielleicht ist etwas davon fuer dich hilfreich.
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.
> ich hab die mal komplett auf 777 geändert.
Nur zur Sicherheit: die des symlinks, von busybox oder beide?
ganz brachial. mit komplett meinte ich alle dateien des images. (ich weiß das das net schön ist, war nur ein test)
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.
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
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.
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
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.
Laut Syntax ist das ok:
1 | ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf> |
2 | ip=192.168.1.8:192.168.1.105::255.255.255.0::eth0:none |
http://www.kernel.org/doc/Documentation/filesystems/nfsroot.txt Die von der Kernel benutzte Netzwerk config sollte funktionieren:
1 | IP-Config: Complete: |
2 | device=eth0, addr=192.168.1.8, mask=255.255.255.0, gw=255.255.255.255, |
3 | host=192.168.1.8, domain=, nis-domain=(none), |
4 | bootserver=192.168.1.105, rootserver=192.168.1.105, rootpath= |
root mount geht auch noch:
1 | Looking up port of RPC 100003/2 on 192.168.1.105 |
2 | eth0: link up (100/Full) |
3 | Looking up port of RPC 100005/1 on 192.168.1.105 |
4 | VFS: Mounted root (nfs filesystem) on device 0:12. |
1 | 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.
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
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 ;-)
> 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.
>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....
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.
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/2008/1/8/546884 Funktioniert wirklich! Du kannst aber auch den gdb über vmlinux schrubbeln lassen, falls der Kernel mit Debugsymbolen kompiliert wurde. Hugh!
Pardon, nlm_lookup_host ruft nsm_get_handle und da knallts dann.
>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.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.