Hallo Elektronik-Freunde, ich versuche derzeit verzweifelt einen Kernel für ein GE863-Pro³ zu compilieren. Ich habe es soweit hinbekommen, dass er Kernel startet und eine Console zum Login funktioniert. Als root-fs bzw. Distribution benutze ich derzeit Angstrom. Jetzt habe ich allerdings das Problem, dass beim Start von größeren Anwendungen das System plötzlich ohne jegliche Ankündigung neu startet. Netzwerk und der Zugriff auf die SD/MMC funktionieren. Hat evtl. jemand eine Idee woran es liegen könnte? Evtl. ist hier ja jemand der mit sein altes AT91SAM9260EK von Atmel zur Verfügung (Leihweise oder Kauf) stellen kann. mfg Matthias
Matthias K. schrieb: > Hallo Elektronik-Freunde, > ich versuche derzeit verzweifelt einen Kernel für ein GE863-Pro³ zu > compilieren. Ich habe es soweit hinbekommen, dass er Kernel > startet und eine Console zum Login funktioniert. Fein, hast du einen vorhanden Kernel vom Bord Hersteller Modifiziert oder von null begonnen. wenn du nicht von null bekonnen hast, was passiert wenn du den original Kernel bootest. Hast du mal beim Hersteller nach eventuell vorhanden patchs gefragt, die der Kernel noch braucht ? > > Als root-fs bzw. Distribution benutze ich derzeit Angstrom. > Erst mal egal, denke ich, ob Angstorm, oder was anderes, viel interessanter ist das Medium auf denn dein rootfs liegt, Flash, SD-Card, USBStick, Netzwerk via NFS-Root. Das letztere würde ich zum Entwickeln empfehlen. Außerdem wäre die Art des Filesystem interessant, jffs2,ext3,logfs,vfat ? > Jetzt habe ich allerdings das Problem, dass beim Start von größeren > Anwendungen das System plötzlich ohne jegliche Ankündigung neu startet. nur beim start von großen anwendungen oder auch wenn es eine Zeit einfach vor sich hin arbeitet? dann könnte es der Watchdog sein, aber das ist ohne die Oben genannten Information mehr als geraten, ausserdem brauchen wir noch die Information von dir, welche Kernelversion, welche Start parameter, wie viel RAM, und was sind große Anwendungen, in dein Zusammenhang, Ausserdem hast du was an den bord modifiziert? wenn nicht dann nutz denn Kernel von denn bord Hersteller, der Hersteller gibt da sicher support, wenn der dann läuft hast du eine Basis. Setze ein git repro auf und taste dich von dort an deine Änderungen ran, bis alles läuft, oder du weist in welcher ecke der Fehler zu finden ist. > Netzwerk und der Zugriff auf die SD/MMC funktionieren. > > Hat evtl. jemand eine Idee woran es liegen könnte? > watchdog,ram,flash, Amok läufender Treiber, Userspace ist eher unwahrscheinlich. btw, was gibt eigentlich cat /proc/cpuinfo und /cat/proc/meminfo aus, und lass dir mal die console in eine Datei mitloggen. um zu sehen ob nicht doch kurz vor den Reset eine wichtige Information kommt. > Evtl. ist hier ja jemand der mit sein altes AT91SAM9260EK von Atmel zur > Verfügung (Leihweise oder Kauf) stellen kann. > > mfg > > Matthias
Danke für die schnelle Antwort! Imon schrieb: > Matthias K. schrieb: >> Hallo Elektronik-Freunde, >> ich versuche derzeit verzweifelt einen Kernel für ein GE863-Pro³ zu >> compilieren. Ich habe es soweit hinbekommen, dass er Kernel >> startet und eine Console zum Login funktioniert. > > Fein, hast du einen vorhanden Kernel vom Bord Hersteller Modifiziert > oder > von null begonnen. wenn du nicht von null bekonnen hast, was passiert > wenn du den original Kernel bootest. Hast du mal beim Hersteller nach > eventuell vorhanden patchs gefragt, die der Kernel noch braucht ? Ich habe dem Support bereits geschrieben aber noch keine Antwort erhalten. Patches wären natürlich hilfreich... Ich arbeite derzeit mit der Version 2.6.30.10 und dem AT91 Patch. Man könnte sagen, dass ich von Null begonnen habe. Der Original-Kernel ist ein 2.6.24 (scheinbar mit einer RT Erweiterung). die wichtigste Änderung musste ich feststellen ist in der board datei at91sam9260_initialize(6000000); Alle devices die ich nicht unbedingt brauchte hatte ich im Kernel-Code und in der Board-Datei deaktiviert. > >> >> Als root-fs bzw. Distribution benutze ich derzeit Angstrom. >> > Erst mal egal, denke ich, ob Angstorm, oder was anderes, viel > interessanter ist das Medium auf denn dein rootfs liegt, Flash, SD-Card, > USBStick, Netzwerk via NFS-Root. Das letztere würde ich zum Entwickeln > empfehlen. Außerdem wäre die Art des Filesystem interessant, > jffs2,ext3,logfs,vfat ? > >> Jetzt habe ich allerdings das Problem, dass beim Start von größeren >> Anwendungen das System plötzlich ohne jegliche Ankündigung neu startet. Ich arbeite mit einer microSD Card in einem MMC Adapter. FS ist ext2. > nur beim start von großen anwendungen oder auch wenn es eine Zeit > einfach vor sich hin arbeitet? dann könnte es der Watchdog sein, aber > das ist ohne die Oben genannten Information mehr als geraten, ausserdem > brauchen wir noch die Information von dir, welche Kernelversion, welche > Start parameter, > wie viel RAM, und was sind große Anwendungen, in dein Zusammenhang, Das Baord läuft ohne Probleme stundenlang, der Fehler tritt nur beim ausführen von Anwengungen auf. > Ausserdem hast du was an den bord modifiziert? wenn nicht dann nutz denn > Kernel von denn bord Hersteller, der Hersteller gibt da sicher support, > wenn der dann läuft hast du eine Basis. Setze ein git repro auf und > taste dich von dort an deine Änderungen ran, bis alles läuft, oder du > weist in welcher ecke der Fehler zu finden ist. > >> Netzwerk und der Zugriff auf die SD/MMC funktionieren. >> >> Hat evtl. jemand eine Idee woran es liegen könnte? >> > > watchdog,ram,flash, Amok läufender Treiber, Userspace ist eher > unwahrscheinlich. > > btw, was gibt eigentlich cat /proc/cpuinfo und /cat/proc/meminfo aus, > und lass dir mal die console in eine Datei mitloggen. um zu sehen ob > nicht doch kurz vor den Reset eine wichtige Information kommt. Dieses werde ich mal schauen und hier dann posten. > >> Evtl. ist hier ja jemand der mit sein altes AT91SAM9260EK von Atmel zur >> Verfügung (Leihweise oder Kauf) stellen kann.
Matthias K. schrieb: > Danke für die schnelle Antwort! [..] > Ich habe dem Support bereits geschrieben aber noch keine Antwort > erhalten. > Patches wären natürlich hilfreich... > > Ich arbeite derzeit mit der Version 2.6.30.10 und dem AT91 Patch. > Man könnte sagen, dass ich von Null begonnen habe. > Der Original-Kernel ist ein 2.6.24 (scheinbar mit einer RT Erweiterung). hast du die Sourcen für denn 2.6.24 Kernel wenn ja, können wir ggf. daraus die benötigten patches generieren. RT Erweiterungen gibt es zum Glück nur zwei in freier wildbahn, preempt rt und xenomai, ich tippe auf das erste. aber egal kann man beide im Internet laden. also wenn der support sich nicht rührt und du die quellen hast in das verzeichnis gehen und mit make kernelversion, die exakte kernelversion heraus bekommen. in einen anderen verzeichnis git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git denn öffizellen kernel laden. dannach mit git checkout -b my-devel-2.6.24 v2.6.24 in einen neuen branch weseln der denn öffizellen 2.6.24 entspricht. Sollte bei make kernelversion sowas herausgekommen sein 2.6.24.y und y ist eine Zahl braucht du noch denn patch für die Version von ftp://ftp.kernel.org/pub/linux/kernel/v2.6/patch-2.6.24.y.gz wobei du y durch die entsprechende nummer ersetzen müsst. as commites du dann.Auf denn branch nun die sam4linux patchs für denn 2.6.24 applizieren, änderung commiten. nun denn preempt-rt patch für 2.6.24 applizieren auch die änderung commiten. nun alles die quellen des 2.6.24 Kernel vom bord hersteller in das verzeichnis kopieren und ggf vorhandenes überschreiben. mit git status kannst du dir nun ansehen welche datein der bord hersteller angefast hat und mit git diff <dateiname> was er gmacht hat. Mit etwas glück sind das nur eine handvoll Änderungen. > die wichtigste Änderung musste ich feststellen ist in der board datei > at91sam9260_initialize(6000000); > > Alle devices die ich nicht unbedingt brauchte hatte ich im Kernel-Code > und in der Board-Datei deaktiviert. > gut, vielleicht zuviel deaktiviert ? >> >>> >>> Als root-fs bzw. Distribution benutze ich derzeit Angstrom. >>> >> Erst mal egal, denke ich, ob Angstorm, oder was anderes, viel >> interessanter ist das Medium auf denn dein rootfs liegt, Flash, SD-Card, >> USBStick, Netzwerk via NFS-Root. Das letztere würde ich zum Entwickeln >> empfehlen. Außerdem wäre die Art des Filesystem interessant, >> jffs2,ext3,logfs,vfat ? >> >>> Jetzt habe ich allerdings das Problem, dass beim Start von größeren >>> Anwendungen das System plötzlich ohne jegliche Ankündigung neu startet. > > Ich arbeite mit einer microSD Card in einem MMC Adapter. FS ist ext2. > hast du mal versucht, das rootfs via NFS zu booten, mach das bitte mal wenn dann die Anwendungen starten ist der MMC Treiber schuld, und wir wissen wo wir suchen, müssen. > >> nur beim start von großen anwendungen oder auch wenn es eine Zeit >> einfach vor sich hin arbeitet? dann könnte es der Watchdog sein, aber >> das ist ohne die Oben genannten Information mehr als geraten, ausserdem >> brauchen wir noch die Information von dir, welche Kernelversion, welche >> Start parameter, >> wie viel RAM, und was sind große Anwendungen, in dein Zusammenhang, > > Das Baord läuft ohne Probleme stundenlang, der Fehler tritt nur beim > ausführen von Anwengungen auf. > schade, hatte irgendwie gehofft du das nur ein watchdog der auslöst, gehe die programme der busybox, wenn ja starte top und sehe dir das system beim start deiner Anwendung an, veilleicht via ssh wenn das läuft. wenn vorhanden kannst du auch ein paar mal die Anwendung unter strace staren um zusehen wo sie denn neustart auslöst, vielleicht kann man den fehler so ein grenzen. > >> Ausserdem hast du was an den bord modifiziert? wenn nicht dann nutz denn >> Kernel von denn bord Hersteller, der Hersteller gibt da sicher support, >> wenn der dann läuft hast du eine Basis. Setze ein git repro auf und >> taste dich von dort an deine Änderungen ran, bis alles läuft, oder du >> weist in welcher ecke der Fehler zu finden ist. > > > >> >>> Netzwerk und der Zugriff auf die SD/MMC funktionieren. >>> >>> Hat evtl. jemand eine Idee woran es liegen könnte? >>> >> >> watchdog,ram,flash, Amok läufender Treiber, Userspace ist eher >> unwahrscheinlich. >> >> btw, was gibt eigentlich cat /proc/cpuinfo und /cat/proc/meminfo aus, >> und lass dir mal die console in eine Datei mitloggen. um zu sehen ob >> nicht doch kurz vor den Reset eine wichtige Information kommt. > > Dieses werde ich mal schauen und hier dann posten. cat /proc/cmdline und cat /proc/version von dein und denn Orginal kernel auch bitte. > >> >>> Evtl. ist hier ja jemand der mit sein altes AT91SAM9260EK von Atmel zur >>> Verfügung (Leihweise oder Kauf) stellen kann.
I > hast du die Sourcen für denn 2.6.24 Kernel wenn ja, können wir ggf. > daraus die benötigten patches generieren. RT Erweiterungen gibt es zum > Glück nur zwei in freier wildbahn, preempt rt und xenomai, ich tippe > auf das erste. > aber egal kann man beide im Internet laden. > > also wenn der support sich nicht rührt und du die quellen hast in das > verzeichnis gehen und mit make kernelversion, die exakte kernelversion > heraus bekommen. > > in einen anderen verzeichnis git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > denn öffizellen kernel laden. > dannach mit git checkout -b my-devel-2.6.24 v2.6.24 in einen neuen > branch weseln der denn öffizellen 2.6.24 entspricht. > Sollte bei make kernelversion sowas herausgekommen sein 2.6.24.y und y > ist eine Zahl braucht du noch denn patch für die Version von > ftp://ftp.kernel.org/pub/linux/kernel/v2.6/patch-2.6.24.y.gz > wobei du y durch die entsprechende nummer ersetzen müsst. > as commites du dann.Auf denn branch nun die sam4linux patchs für denn > 2.6.24 applizieren, änderung commiten. nun denn preempt-rt patch für > 2.6.24 applizieren auch die änderung commiten. nun alles die quellen des > 2.6.24 Kernel vom bord hersteller in das verzeichnis kopieren und ggf > vorhandenes überschreiben. > > mit git status kannst du dir nun ansehen welche datein der bord > hersteller angefast hat und mit git diff <dateiname> was er gmacht hat. > Mit etwas glück sind das nur eine handvoll Änderungen. OMG! Mit diff habe ich auch schon einige Dateien verglichen, aber da waren einige Änderungen zu erkennen. Da dachte ich das AT91 wäre "schuld" gewesen. Nach der Kernel-Config Datei ist es 2.6.24-rc5-rt1 Und ja, ich denke es ist die preempt-rt Erweiterung. CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y # CONFIG_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_RCU_BOOST=y Die Sourcen liegen zum Glück vor. Gibt es denn für einen aktuelleren Kernel auch diese Erweiterung? Ich frage mich ob es überhaupt ohne diese Erweiterung funktioniert...
Matthias K. schrieb: > OMG! Mit diff habe ich auch schon einige Dateien verglichen, aber da > waren einige Änderungen zu erkennen. Da dachte ich das AT91 wäre > "schuld" gewesen. > > Nach der Kernel-Config Datei ist es 2.6.24-rc5-rt1 > Und ja, ich denke es ist die preempt-rt Erweiterung. > warg, ein Release Kanidaten als Kernel rauszugeben, das ist übel, na ja dann eben checkout -b my-devel-2.6.24-rc5 v2.6.24-rc5 und weiter wie oben besprochen. > CONFIG_PREEMPT_RT=y > CONFIG_PREEMPT=y > CONFIG_PREEMPT_SOFTIRQS=y > CONFIG_PREEMPT_HARDIRQS=y > CONFIG_PREEMPT_BKL=y > # CONFIG_CLASSIC_RCU is not set > CONFIG_PREEMPT_RCU=y > CONFIG_PREEMPT_RCU_BOOST=y > > Die Sourcen liegen zum Glück vor. > schön dann gehe auf den kernel 2.6.33 für den gibt es die rt patches ( http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.6-rt26.gz ) und eine sam4linux Patch unter http://maxim.org.za/AT91RM9200/2.6/2.6.33-at91.patch.gz das dann auf 2.6.34 oder 35 zu bringen, geht auch machen wir aber erst wenn es mit 2.6.33 läuft. > Gibt es denn für einen aktuelleren Kernel auch diese Erweiterung? > Ich frage mich ob es überhaupt ohne diese Erweiterung funktioniert... kann gut möglich sein das diese der knakpunkt ist un du rt brauchst, für denn v2.6.33 gehst du in git verzechnis wie oben sagst git checkout -b my-devel-v2.6.33 v2.6.33 jetzt hast du analog zu denn 2.6.24 ein offizellen 2.6.33 branch in denn du arbeiten kannst, preempt patch einspielen commiten, sam4 patch einspielen commiten.Änderungen in borad config übernehmen. commiten (lieber zu oft commiten als zu selten) .config datei vom Herseller in das verzeichnis Kopieren, make ARCH=arm CROSS_COMPILE=<deine kompiler suite>- oldconfig, um eine akutelle Konfig zu generieren. neuen Kernel testen.
Imon schrieb: > Matthias K. schrieb: >> OMG! Mit diff habe ich auch schon einige Dateien verglichen, aber da >> waren einige Änderungen zu erkennen. Da dachte ich das AT91 wäre >> "schuld" gewesen. >> >> Nach der Kernel-Config Datei ist es 2.6.24-rc5-rt1 >> Und ja, ich denke es ist die preempt-rt Erweiterung. >> > warg, ein Release Kanidaten als Kernel rauszugeben, das ist übel, > na ja dann eben checkout -b my-devel-2.6.24-rc5 v2.6.24-rc5 > > und weiter wie oben besprochen. > >> CONFIG_PREEMPT_RT=y >> CONFIG_PREEMPT=y >> CONFIG_PREEMPT_SOFTIRQS=y >> CONFIG_PREEMPT_HARDIRQS=y >> CONFIG_PREEMPT_BKL=y >> # CONFIG_CLASSIC_RCU is not set >> CONFIG_PREEMPT_RCU=y >> CONFIG_PREEMPT_RCU_BOOST=y >> >> Die Sourcen liegen zum Glück vor. >> > schön dann gehe auf den kernel 2.6.33 für den gibt es die rt patches > ( > http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.6-rt26.gz > ) > und eine sam4linux Patch unter > http://maxim.org.za/AT91RM9200/2.6/2.6.33-at91.patch.gz > > das dann auf 2.6.34 oder 35 zu bringen, geht auch machen wir aber erst > wenn es mit 2.6.33 läuft. > >> Gibt es denn für einen aktuelleren Kernel auch diese Erweiterung? >> Ich frage mich ob es überhaupt ohne diese Erweiterung funktioniert... > > kann gut möglich sein das diese der knakpunkt ist un du rt brauchst, > > für denn v2.6.33 > > gehst du in git verzechnis wie oben sagst git checkout -b > my-devel-v2.6.33 v2.6.33 jetzt hast du analog zu denn 2.6.24 ein > offizellen 2.6.33 branch in denn du arbeiten kannst, preempt patch > einspielen commiten, sam4 patch einspielen commiten.Änderungen in borad > config übernehmen. commiten (lieber zu oft commiten als zu selten) > > > .config datei vom Herseller in das verzeichnis Kopieren, make ARCH=arm > CROSS_COMPILE=<deine kompiler suite>- oldconfig, um eine akutelle Konfig > zu generieren. neuen Kernel testen. Also ich zähle noch mal auf: Den kompletten 2.6.33.6 herunterladen, dann das rt Patch und dann das AT91 Patch Was ist eigentlich mit der Toolchain, das wollte ich beim letzten Mal schon fragen. Ich verwende die von Angstrom, bisher ohne Probleme beim kompilieren. (Das was da raum kam lief bloß nie ;-) ) Oder welche Alternative gibt es da noch. Ich habe den Kompiler immer mit EABI (glaub so ists richtig) und Thum Support kompiliert... Danke für deine Unterstützung!
Matthias K. schrieb: > Also ich zähle noch mal auf: > Den kompletten 2.6.33.6 herunterladen, dann kommt drauf an wenn du das git repro nuzt dann dast du die quellen schon in den git repro, deshalb ja in den git tree,
1 | git checkout -b my-devel-v2.6.33 v2.6.33 |
das ist äquivalent zum kernel 2.6.33 runter laden.das eingentlich der 2.6.33.6 aktuell ist würde ich erstmal ignorieren, denn sowohl der sam4linux als auch der rt patch werden gegen denn 2.6.33 erstellt wurden sein. Kiss prinzip, und denn update machst du dann wenn erstmal was läuft. geht mit git dann recht einfach, und eine Versions verwaltung schadet nie, also nutz git in denn fall, weil der ganze kernel so entwickelt wird, bei fragen wird dir gerne geholfen. > das rt Patch und dann das AT91 Patch > die reihenfolge ist willkürlich um ehrlich zu sein ich bin mir nicht sicher was sinnvoller als erste appliziert werden sollte, Instinktiv würde ich die Reihenfolge so wahlen, kann sein das ich damit zweiter Sieger bin ;-) > Was ist eigentlich mit der Toolchain, das wollte ich beim letzten Mal > schon fragen. Ich verwende die von Angstrom, bisher ohne Probleme beim > kompilieren. (Das was da raum kam lief bloß nie ;-) ) > Oder welche Alternative gibt es da noch. > > Ich habe den Kompiler immer mit EABI (glaub so ists richtig) und Thum > Support kompiliert... klingt Vernünftig, ich nutze zwar eine eignen Entwicklung,aber würde wohl auch auf die von dir genannte zurück greifen wenn die Eigenentwicklung nicht zur verfügbar wäre.
Also...
Ich habe noch einmal über alles gründlich nachgedacht, habe noch einige
Dinge probiert und siehe da:
Ich nehme z.Zt. an, dass es der Watchdog-Timer ist der aufgrund deutlich
veränderten Systemfrequenz nicht richtig tickt.
Ich habe dann im Kernel den Haken bei AT91SAM9X / AT91CAP9 watchdog
[*] Disable watchdog shutdown on close
*** Watchdog Device Drivers ***
< > Software watchdog
<*> AT91SAM9X / AT91CAP9 watchdog
*** USB-based Watchdog Cards ***
< > Berkshire Products USB-PC Watchdog
gesetzt. Die war bei dem RT Kernel nicht gesetzt, warum auch?!?
Jetzt bekam ich bei jedem Reset der aufgetreten ist die Meldung
"AT91SAM9 Watchdog: I will reset your machine !"
Eigentlich ziehmlich eindeutig, der blöde Hunde ist also schuld, dann
habe ich die Konstanten angepasst, das Verhalten hat sich gebessert, ist
aber noch nciht OK. Wo kann bzw. muss ich da noch ansetzten?
Die Systemfrequenz ist wie schon geschildert 6 MHz.
Wo wird eigentlich bei einem Std. 9260 System der Zähler wieder
zurückgesetzt?
at91sam9_wdt.c
/* Hardware timeout in seconds */
#define WDT_HW_TIMEOUT 10
/* Timer heartbeat (500ms) */
#define WDT_TIMEOUT (HZ/2)
/* User land timeout */
#define WDT_HEARTBEAT 100
Hier die Infos:
root@mkd1:~# cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 99.73
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
Hardware : Atmel AT91SAM9260-EK
Revision : 0000
Serial : 0000000000000000
root@mkd1:~# cat /proc/meminfo
MemTotal: 62824 kB
MemFree: 53396 kB
Buffers: 572 kB
Cached: 4264 kB
SwapCached: 0 kB
Active: 2696 kB
Inactive: 2780 kB
Active(anon): 764 kB
Inactive(anon): 0 kB
Active(file): 1932 kB
Inactive(file): 2780 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 24 kB
Writeback: 0 kB
AnonPages: 672 kB
Mapped: 980 kB
Slab: 3392 kB
SReclaimable: 1308 kB
SUnreclaim: 2084 kB
PageTables: 88 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 31412 kB
Committed_AS: 2120 kB
VmallocTotal: 956416 kB
VmallocUsed: 80 kB
VmallocChunk: 956268 kB
root@mkd1:~# cat /proc/version
Linux version 2.6.30.10 (root@debian01) (gcc version 4.2.4) #18 Thu Jul
29 18:35
:21 CEST 2010
root@mkd1:~# cat /proc/cmdline
console=ttyS0,115200 mem=64M root=/dev/mmcblk0p1 rootdelay=2
root@mkd1:~#
Matthias K. schrieb: > Ich habe dann im Kernel den Haken bei AT91SAM9X / AT91CAP9 watchdog > > [*] Disable watchdog shutdown on close > *** Watchdog Device Drivers *** > < > Software watchdog > <*> AT91SAM9X / AT91CAP9 watchdog > *** USB-based Watchdog Cards *** > < > Berkshire Products USB-PC Watchdog > > gesetzt. Die war bei dem RT Kernel nicht gesetzt, warum auch?!? > Jetzt bekam ich bei jedem Reset der aufgetreten ist die Meldung > > "AT91SAM9 Watchdog: I will reset your machine !" > > Eigentlich ziehmlich eindeutig, der blöde Hunde ist also schuld, dann > habe ich die Konstanten angepasst, das Verhalten hat sich gebessert, ist > aber noch nciht OK. Wo kann bzw. muss ich da noch ansetzten? > Mh etwas komisch ist das schon, denn eigentlich sollte der Watchdog ja gar nicht laufen, vielleicht hat dein Bord Hersteller den uboot so modifiziert das der Automatisch startet, schön jedenfalls das wir nun einen Übeltäter wahrscheinlich kennen. > Die Systemfrequenz ist wie schon geschildert 6 MHz. > Wo wird eigentlich bei einem Std. 9260 System der Zähler wieder > zurückgesetzt? wie bei jeden linux watchdog indem du in die Datei /dev/watchdog was irgendwas schreibst. Dann fängt der watchdog wieder von vorne an. 'V' ( hexcode 0x42) hat im allgemeinen die Sonder rolle das es, verbunden mit ein close danach, Denn Watchdog sagt schalte dich ab. Das watchdog Interface ist ziemlich stabil hat sich nach meiner Kenntnis seit Linux 2.2 nicht mehr geändert. Im Linux Magazin war mal eine gute Beschreibung dazu drin hier Online lesbar http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/05/Kern-Technik
> wie bei jeden linux watchdog indem du in die Datei /dev/watchdog was > irgendwas schreibst. Dann fängt der watchdog wieder von vorne an. > 'V' ( hexcode 0x42) hat im allgemeinen die Sonder rolle das es, > verbunden mit ein close danach, Denn Watchdog sagt schalte dich ab. > > Das watchdog Interface ist ziemlich stabil hat sich nach meiner Kenntnis > seit Linux 2.2 nicht mehr geändert. > > Im Linux Magazin war mal eine gute Beschreibung dazu drin > hier Online lesbar > > http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/05/Kern-Technik Interessant wäre noch wie ich das Ding evtl. ganz abschalten kann. Aber evtl. finde ich ja in dem linux-magazin Infos. Gut, werde ich heute Nachmittag mal ausprobieren. Ich habe mich jetzt für den 2.6.32 entschieden weil das ein LTS Kernel ist bzw. werden soll. Aber ich glaub dafür gibts keine RT Erweiterung. Ich frage mich ob das wohl ohne größe Probleme laufen wird. Ich bin schon ganz gespannt und werde, denke ich am Wochenende die RT Erweiterung für einen relativ aktuellen Kernel testen. Ich befürchte derzeit noch kleine "Timing" Probleme meiner Anwendungen. Im Moment bin ich noch die 400 MHz vom 9G20 gewohnt ;-)
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.