mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche AT91SAM9260EK - Problem mit (Telit GE863-Pro³)


Autor: Matthias K. (fmann2000)
Datum:

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

Autor: Imon (Gast)
Datum:

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

Autor: Matthias K. (fmann2000)
Datum:

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

Autor: Imon (Gast)
Datum:

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

Autor: Matthias K. (fmann2000)
Datum:

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

Autor: Imon (Gast)
Datum:

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

Autor: Matthias K. (fmann2000)
Datum:

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

Autor: Imon (Gast)
Datum:

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

Autor: Matthias K. (fmann2000)
Datum:

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

Autor: Imon (Gast)
Datum:

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

Autor: Matthias K. (fmann2000)
Datum:

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

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.