Nach jedem Start unterschiedlicher Füllstand des JFFS-Bereiches

[niemand0815]

ihr vergesst immer das wir alle unterschiedliche boxen haben, somit bestimmte sachen sehr wohl sich unterscheiden können.

 

das mit den 51% wundert mich dann aber schon, denn das ist ja der wert den auch die leute mit "normalem" flash haben...

[merkwuerden]

@eraser65

@merkwuerden

Die flashzeit beträgt bei meinen Nokias übers Expertenflashtool im Image schon immer um die 5- 6 min. Das hat sich seit Jahren nicht geändert. In den letzten Monaten habe ich garantiert 40 -50 mal geflasht.

Hm... ich kann nur von meiner Philips ausgehen, da lief das bis zu den letzten 2006er September-Beta-Mods innerhalb von maximal (!) 3 Minuten durch, jetzt mit den 2007er Images dauert das deutlichst länger.

Ich schaue nachher mal, wie lange das wirklich war, mal schnell das 2006er Image raufbügeln...

[merkwuerden]

So, habe jetzt mal paar Sachen ausprobiert, Box wurde vor dem Flashen frisch gebootet.

 

Flashen mit September 2006 V1 Beta6 noHDD:

 

Sectionsd und E*u gekillt: 2:23 Minuten

Sectionsd und E*u aktiv: 2:40 Minuten

 

Oktober 2007 V1 RC3:

 

Sectionsd und E*u gekillt: 2:26 Minuten

Sectionsd und E*u aktiv: 2:38 Minuten

 

Abweichungen also unwesentlich, auf die paar Sekunden kommt es nicht an.

 

Bootmanager: 2:45 Minuten

 

Da die Box aber vor dem Flashen frisch gebootet werden sollte, kann man auch gleich den Bootmanager hernehmen, ist eh sicherer.

 

Vorhin beim Flashen von der Beta23 auf RC3 lief die Box ein paar Stunden, trotz gekilltem Sectionsd und deaktiviertem Piepmatz dauerte das Flashen geschätzte 5-6 Minuten, war deutlich länger, als bei meinen Versuchen eben.

Mit dem 2006er Image konnte ich auch problemlos flashen, nachdem die Box schon tagelang lief, dauerte auch nicht länger als knappe 3 Minuten. Die alten Images scheinen da wohl unempfindlicher zu sein, kommt mir jedenfalls so vor.

 

Fazit: Box unbedingt neu booten vor dem Flashen.

Aber wie geschrieben, dann kann man auch gleich den Bootmanager nehmen und noch 2 Minuten sparen, nämlich die Zeit, die die Box zum Hochfahren braucht, und bis man das Image nach /tmp befördert und sich durchs Menü gehangelt hat.

[schubsi]

jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00160000: 0x5555 instead

 

Solche Meldungen sind mir auch noch in Erinnerung, inklusive eines nachfolgenden Hinweises, dass dies beim nächsten Mal nicht mehr reported werden würde.

 

Ich vermute, es handelt sich um ungenutzte Bereiche des Flash, die in der Image-Datei leer sind, beim Schreiben ins Flasch aber nicht korrekt auf NULL gesetzt werden. Der Kernel scheint die ungenutzten Bereiche nach und nach selbst zu "heilen", habe jedenfalls keine Fehlfunktionen festgestellt.

 

Schreibversuche ins VAR bis kurz vor die "Platz"-Grenze waren ohne Auffälligkeiten, insofern hab ichs irgendwann sein lassen, mir darüber Gedanken zu machen...

 

-==[schubsi]==-

[niemand0815]

@schubsi:

die meldung ist nicht das es in zukunft nicht mehr reported wird sondern da ein ganzer block mit 128k dieses problem hat und pro byte die meldung kommt wird nach den ersten 10 bytes des blockes für diesen block keine weitere meldung ausgegeben.

beim neustarten kommen die wieder.

ist aber wohl ein cvs problem mit sagem boxen wie es lauf dem entwicklerforum ausschaut.

der effekt sind wie gesagt 500kb mehr belegter speicher. und ich würde auch wie snowhead gesagt hat das ganze mal hier ausklammern (bis im cvs eine lösung kommt) und nur einen warnhinweis für alle einfügen beim release:

1) vor dem installieren zusätzlicher komponenten muss die box seit dem flashen mindestens 3 mal gebootet worden sein (belegter var-speicher laut sysinfo muss x% sein)

2) vor dem installieren von komponenten sollte geprüft werden ob genug freier speicher in var vorhanden ist

 

so was in der richtugn denke ich.

[newcode]

@niemand0815

 

Ich denke, eventuelle Warnungen bezüglich des Flashens, kann man auf Sagem 1 Chip Boxen beschränken. Meine 2 Chip hat das Problem nicht.

 

Grüße

[jensemann67]

m.E. sollten wir uns, anstatt irgendwelche Warnungen auszusprechen, mal überlegen, warum der Füllstand nach dem Flashen bei einigen Boxen ungewöhnlich hoch ist und nach zweimaligem Boot wieder auf einen normalen Level sinkt.

 

Ich kann das hier leider nicht nachvollziehen, meine Philips macht alles so, wie es soll, aber normal ist das nicht!

 

Im tuxbox-Forum finde ich da auch nichts zu, was auf einen Fehler im CVS schließen ließe, also kann es doch eigentlich nur mit den kw-Modifikationen zu tun haben, denke ich mal.

 

Noch eine allgemeine Anmerkung zu irgendwelchen Warnungen in "readme´s":

 

Ihr wisst doch sicher, wie sehr die gelesen und beachtet werden, oder? Wie sieht dieses Forum aus, wenn etliche Leute auf einmal ein geplatztes Image haben und wir hier immer nur antworten: "Jaja, hättest Du mal die readme gelesen".

 

Noch was konstruktives:

 

Kann mal jemand von denen, mit einer prozentual höheren Auslastung nach dem Flashen ein ganz normales Standard-CVS-Dietmarw-Image testen? Tritt das Problem da auch auf, liegt es am CVS, wenn nicht, muss unsere eigene Nase herhalten :-)

[eraser65]

Kann mal jemand von denen, mit einer prozentual höheren Auslastung nach dem Flashen ein ganz normales Standard-CVS-Dietmarw-Image testen? Tritt das Problem da auch auf, liegt es am CVS, wenn nicht, muss unsere eigene Nase herhalten :-)

Das hat wonderdoc schon durchexessiert, bei einem originalen DietmarW Img. Dort tritt der Fehler nicht auf.

Hier entlang-selber Thread .

 

gruß eraser65

[jensemann67]

Das hat wonderdoc schon durchexessiert, bei einem originalen DietmarW Img. Dort tritt der Fehler nicht auf.

 

Ja, aber vielleicht könnte der ein oder andere mal das Ergebnis verifizieren. "Ein Vogel macht noch keinen Sommer, aber viele Vögel, die mach schon ganz viele .... Vögel ... "

[niemand0815]

du kannst davon ausgehen das wenn es einer macht es bei allen so ist.

der fehler ist eindeutig reproduzierbar und kein zufall.

btw:

weiter oben steht ein link zum dev-forum in dem dieses phänomen auch beschrieben wird. es kann wohl auch wieder verschwinden.

dort wird z.B. vermutet das es ein timingproblem beim flashen sein könnte.

 

da wir ja wissen das die boxen wohl unterschiedlich stark auf die laufzeit reagieren und sehr empfindlich mit parallel laufenden prozessen sind haben wir ja auch schonmal per bootmanager geflasht.

dort war aber der selbe effekt zu sehen.

 

es ist wohl zufall ob und bei welchen blöcken das passiert, es könnte aber denke ich auch mit der beobachtung zusammenhängen das manche boxen manchmal ewig zum flashen brauchen :-)

 

hier ist das denke ich zzt kein nötiges diskussionsthema ausser im sdk kommt ein fix dafür den wir von snowhead einbauen lassen müssten.

 

ansonsten sollten wir für diese diskussion und die test einen eigenen thread aufmachen da man sonst vor lauter flashmeldungen die eigentliche thematik nicht mehr sieht :-)

 

@mods:

könntet ihr wenns nicht zu viel aufwand ist die entsprechenden posts in einem thread zusammensammeln? ansonsten fangen wir einfach neu an damit.

[merkwuerden]

Ich nehme an, das Problem mit den Sagems 1xI liegt am Verpacken des /var Bereiches beim Image erstellen. Dort sollte angesetzt werden, denn auch beim Ausmisten von Plugins dürfte das eigentliche Problem mit den Macig bitmasks trotzdem nicht behoben werden.

Das eigentliche Übel liegt meiner Meinung nach nicht am Füllstand des Images, sondern an der Verpackung des /var Bereiches für 1xI.

[warbeastmv6]

Ich bin zwar kein Betatester aber vielleicht kann ich in der Überlegung mal helfen:

 

Da bei manchen wie ich sehe die Speicherlast bei ca 70 % ist und nach 1 bis 2 Neustarts sich das Problem beseitigt und runter auf 55% ist, stellt sich die Frage: "Was passiert genau bei einem Shutdown bzw. Start"

 

Dateien können ja nicht kleiner werden ? Also kann der Fehler doch nur am Dateisystem liegen, das während dem Flashen ne Macke bekommt.

 

Kann es vielleicht am Tool liegen welches die Speicherlast ausliest, eventuell hilft es ja eine art Re-Initialisierung der Dateien. (Einlesen der Dateigrößen) ?

 

Gruß

 

Edit: Testet doch mal ein Frischgeflashtes Image mit angeblichen "72% Füllstand wieviel noch reingeht an Plugins. Und beobachtet ob es Platzt. Normalerweise sollte es ja nicht, wenn es real nur ca 55% Füllstand hat. Wenn es ja nur ein Anzeigefehler ist sollte nichts passieren. Weil ich denke jeder hat erstmal 2-3 Neustarts bevor jeder seine persönlichen Einstellungen hat.

[DrStoned]

Hi,

 

eventuell sollten wir doch nen paar plugins rausnehmen um so auch den var Bereich etwas mehr platz zugeben.

 

So ist trotz eines Hnweiß für sagem 1x chips auch ein puffer gegeben für die leute die die readme nicht sofort beachten und einen eXX installieren gleich nach dem flashen !

 

Weil einige der jetzt im Image vorhanden Plugins können auch nach belieben nachträglich eingefügt werden.

 

z.b: Bildschirmschoner, Bildschirmuhr,Logomasken,Werbezapper usw eventuell können wir uns da ja einigen was raus soll und was drin bleiben kann.

 

MFG

Ich würde die Plugins drin lassen, so einfach wie jetzt auf Knopfdruck deinstalliert werden können, gabs das vorher in noch keinem anderen Image. Wer Vögel haben will, soll welche installieren, wer Plugins haben will, aber nicht weiss, wie er sie installieren soll, hat sie so wenigstens gleich drin. Das rausschmeißen ist auch sehr einfach geworden zumindest funktioniert das auch, auch wenn die Box nicht am Internet hängt.

 

P.S.: Wegen der magic bitmasks, würde ich mir keine Gedanken machen. Das JFFS2-Dateisystem für das /var gibt nicht zugeordnete Blöcke wieder von selbst frei, sowie der Kernel bemerkt, dass sie nicht belegt sind. Ausserdem werden bei diesem Dateisystem, die Blöcke variabel gespeichert, damit bei Änderungen im Flash nicht immer die gleichen Speicherzellen neu beschrieben werden, was der Haltbarkeit der Flash-Chips nicht sehr zuträglich wäre. Deswegen darf das /var auch nicht komplett vollgeschrieben werden, da es zur Organisation einige freie Blöcke braucht. Tut man das nicht, kommt es zum berühmten Imageplatzer. Ihr könnt Euch das ähnlich wie eine Defragmentierung vorstellen, nur dass diese bis zu einem gewissen Füllstand bei dem JFFS2-Dateisystem von selbst geschieht. Erst wenn keine freien Zwischenspeicher mehr da sind, platzt das Image. Bedenkt dass jede Lautstärkeänderung oder sonstige Einstellung spätestens beim Runterfahren im /var gespeichert werden. Bei Timern werden diese sofort im /var gespeichert, auch eingestellte Tonspuren werden sofort durch zapit in der

audioPIDs.data gespeichert. Durch das JFFS2-Dateisystem wird versucht, die Schreibzugriffe auf die einzelnen Speicherzellen so gleichmässig wie möglich zu verteilen.

[niemand0815]

die plugins können genausoeinfach installiert werden wie deinstalliert :-)

insofern diese auf dem server bereitstehen.

optimal für mich persönlich wäre natürlich ein leeres image bei dem man alles einfach nachinstallieren kann wie mans braucht.

 

@merkwürden

gemeint war folgendes: wenn du ein problematisches flash hast mit 76% belegt nach installation und wie viele sofort ein e*u installierst landest du bei 96%. das ist definitiv ein fast-platzer.

ein wenig rumgespielt und das ding ist geplatzt, dann hilft auch nicht mehr das nach dem booten die bereiche das flashs die eigentlich leer sein sollten erased werden (vermute ich mal, habs noch nicht getestet).

das lässt den schluss zu das wir ohne warnung zig threads bei release bekommen mit useranfragen zu geplatzten images. ziemlich lästig.

 

@all bezüglich der meldungen:

das der speicher beim booten mehr wird hat in dem fall wie man an meinen logs sieht folgende bewandtnis:

offensichtlich kann beim flashen ein teil des flashs nicht ordentlich geleert werden. beim booten wird das vom os überprüft und dann bereinigt.

warum 1 boot nicht dafür reicht? keine ahnung.

aber es schaut von den logs her so aus als ob neutrino merkt das ein bereich zum löschen geflagt ist und daten enthält bzw ein bereich der leer sein sollte eben nicht leer ist (gibt es einen bereich der beim booten immer leer sein sollte und der auf diese weise geprüft wird?).

vielleicht stimmt auch was in der shutdown prozedur nicht so das bei einigen boxen einfach ein speicherbereich nicht geleert wird und da noch müll der vorherigen installation drinsteht.

 

aber die diskussion gehört wie oben erwähnt evtl in einen eigenen thread da sie NICHT nur beim kw-image sondern auch bei ganz normalen auftritt.

 

btw:

was mir grad einfällt: wo ist denn tmp? im flash oder im ram?

wenn tmp im flash ist und immer beim booten gelöscht wird, könnte das dann genau der bereich sein der eben plötzlich nicht richtig geleert wurde und als voll dann var zugeschlagen wird?

irgendwann reinigt vielleicht das os sich dann selbst und löscht den bereich richtig.

führt mich wieder zu der frage oben: gibt es einen bereich des flashs der bei jedem booten leer sein muss bzw gelöscht wird?

[DrStoned]

Habe in meinem vorherigen Beitrag, noch eine Erklärung zur Funktion des JFFS2-Dateisystem hinzugefügt. Ist zwar nicht Dozentenreif, aber ich hoffe jeder kapiert, was da so abgeht.

Das /tmp/ ist eine RAM-Disk, die einen Teil des RAM-Speichers variabel belegt. Es kann aber nicht der komplette RAM-Bereich verwendet werden, da auch der Kernel und das OS (hier Neutrino) noch einen Teil des RAM's als Variablenspeicher benötigen. Auch sectionsd der wohl größte Speicherfresser, lagert seine Tabellen im RAM aber nicht in /tmp/. Versuch mal 2 Komplettimages direkt nach /tmp/ zu kopieren. In der Regel wird das nicht gehen, es sei denn man lagert auf SWAP (TMPFS) aus. Löscht man die Images wieder, hat man plöztlich eine Menge RAM-Speicher frei den sich der sectionsd und Neutrino, Kernel etc. aber nach einer Weile wieder holen. Wird der RAM-Speicher überfüllt, wird die Box langsam, da der Prozessor ständig Daten hin und herschieben muss, um das ganze noch halbwegs zu organisieren. Im schlimmsten Fall crasht die Box oder hängt sich auf.

 

 

Zu den Plugins:

 

Es gibt halt Leute, die die Box nicht ständig am Internet haben, aber trotzdem gern in den Genuss einiger Plugins kommen wollen, die das Internet nicht benötigen. Gehe mal nicht von den Experten und Betatestern aus, die in der Regel wissen, was auf der Box abgeht. Für diese Leute versuchen wir ja ein vernünftiges Image zu erstellen, das sie so einfach wie möglich bedienen können.

 

Ich hoffe Du hast heute auch wieder was gelernt. :D

[niemand0815]

ich lerne immer und jederzeit :-)

nur so macht's spass *g*

 

aber ontopic:

das mit den plugins sehe ich eine, deswegen hab ich ja ich geschrieben *g*

 

zum filesystem:

das mit tmp hab ich mir schon gedacht. aber wenn die box swapt, geht das dann ins flash?

wenn ja wohin? nach var? wenn ja könnte es genau das sein was nicht richtig gelöscht wird beim neuflashen und somit reste des alten images (den alten swapbereich) enthält?

oder bin ich da komplett auf dem holzweg?

 

mich wundert warum die box beim flashen, das ja den kompletten flash beschreibt, bereicht als "erase" markiert. offensichtlich soll da was beim booten gelöscht werden und das schafft die box nicht (kommt beim shutdown der powerdown bevor das flashen wirklich abgeschlossen ist? sind da vielleicht noch "aufräumarbeiten" am werk?).

[windows64bit]

Hi,

 

@ SnowHead & DrStoned

 

ok hab es verstanden

 

@ sagem 1x nutzer

 

Was ich gerade Wonderdoc schon geschrieben habe und was mich interessieren tut !

 

Was ist wenn ihr das image flasht und dann 2x neustarten tut damit die 51% erreicht werden. Dann macht ihr ein Backup des Image und zieht es auf den rechner und richtet eure Box spasseshalber mal ein + nen paar mal zappen und dann das Backup flashen, ist dann der fehler auch noch vorhanden ?

 

Kann das ja leider nicht testen da ich keine sagem 1x habe interessiert mich nur weil dies ja von euch noch nicht getestet worden ist.

 

MFG

[wonderdoc]

@windows64bit

 

So, RC3 mal gesichert(md4) und gleich wieder geflasht.

Füllstand bleibt unverändert.

Die Erase-Meldungen tauschen nach dem Flashen nicht auf.

 

mfg

Wonderdoc

[DrStoned]

das mit tmp hab ich mir schon gedacht. aber wenn die box swapt, geht das dann ins flash?

Nein, das geht nur in die SWAP-Partition auf HDD oder MMC. Sonst wäre das Chaos perfekt. Ich schiebe den Fehler eher auf eine nicht abgeschlossene Reorganisation der JFFS2-Partion, die durch das Flashen des Images über die Expertenfunktionen der Box zu Stande kommt. Da die Box nach dem Flashen unvermittelt rebootet wird, ist beim nächsten Neustart der Box nach dem Flashen das JFFS2 noch leicht durcheinander. Eventuell wird sogar dem Kerneldämon, der das JFFS2 verwaltet, der Saft abgedreht, sprich die nötige Rechenzeit entzogen, das Dateisystem zu reorganisieren. Wie ja sich jetzt schon rausstellt, durch einige Versuche, tritt der Fehler offensichtlich nach sofortigem Flashen nach Neustart der Box, bzw. beim Flashen mit dem Bootmanager nicht auf. Ich könnte mir jedoch auch vorstellen, dass der RAM-Speicher knapp wird, das das JFFS2 zur Reorganisation natürlich auch Buffers (Zwischenspeicher) im RAM benötigt.

 

Als ich vor 15 Monaten anfing, mit dem IDE Interface zu experimentieren als Beta-Tester für Riker (Imagebauer JtG-Image) habe ich mir ein paar Kommandozeilen für das Flexmenü zusammengehackt, mit denen ich mittels des cat-Befehls Images oder auch einzelne Partionen von der Platte mittels Flexmenü auf die Platte und auch wieder zurückflashen wollte. Das Ganze ging auch gut, sofern ich die Box nach dem Flashen über den Affengriff an der Box direkt neu gestartet habe. Als ich jedoch den reboot-Befehl hintendrangehängt habe, hatte ich beim Runterfahren jedesmal auch derartige Meldungen im Bootlog. An sich auch logisch, da durch das komplette neu Flashen des Images und vorbei am Betriebssystem, beim Runterfahren über reboot versucht wird, dass einige Deamons, die noch laufen, versuchen ihre Daten noch auf dem Flash zu plazieren. Da jedoch die Speicherorganisation nicht mehr mit der Tabelle übereinstimmt, kommt es dann zu solchen Fehlern. Bei 2-3 mal neustarten der Box war dann das /var/ auch wieder kleiner.

 

Der Reset über das Flashen der Expertenfunktionen macht das anders. Beim JtG-Image werden vor dem Flashen zuerst die Daten der Deamons abgespeichert, und nach dem Flashen wird ein Befehl erteilt, der den Prozessor anweist, direkt einen Reset, (wie der Reset-Griff an der Box) auszuführen. Das Ganze, mit dem Flashen über das Flexmenü, hatte auch funktioniert, wenn ich am Com-Terminal nach dem Flashen den Befehl go 10000100 eingeben hatte, also den gleichen Befehl wie zum Abschluss der Nokia 2x Intel Boxen mit Bmon1.0 nach der MHC-Methode.

[SnowHead]

@niemand0815

 

Es wird nicht in den Flash geswappt. Das wäre tödlich. Geswappt

wird entweder auf die HDD (ideal), Lan-Mount (langsam) oder die

MMC (nicht gut für die Karte und auch langsam).

Da ein Bit im Flash-Speicher beim Programmieren immer nur von

1 auf 0 gesetzt werden kann, muß der komplette Speicher vor dem

Programmieren gelöscht (also auf 1) gesetzt werden. Mehr steckt

nicht hinter dem Erase. Kann ein Bereich nicht gelöscht werden,

treten beim Programmieren Fehler auf, da ein eventuell noch auf 0

stehendes Bit nicht auf 1 gesetzt werden könnte, falls das an dieser

Stelle erforderlich wäre.

[wonderdoc]

@niemand0815

 

So,

ich habe mal das org RC3 1xI neu geflasht und 3 Reboots durchgeführt.

Danach habe ich es als md4 ausgelesen.

Es treten aktuell keine Voltage und Erase Meldungen auf.

init started: BusyBox v1.7.2 (2007-11-12 20:07:04 CET)

 

 

##### Image-Version: Keywelt_Okt2007_V1_RC3 #####

 

Mon Nov 12 20:23:00 UTC 2007

event: $Id: event.c,v 1.12 2003/09/30 05:45:38 obi Exp $

Detected STB:

  Vendor: Sagem

  Model: D-BOX2

Könntes du dieses mal bei dir flashen und prüfen, ob im Bootlog noch Fehlermeldungen nach dem Flashen bei dir auftreten?

 

Image ist unverändert und hat nun folgene Daten:

/dev/mtdblock/3           2176      1124      1052  52% /var

 

mfg

Wonderdoc

[niemand0815]

wenn ich das jetzt mache bekomme ich ärger mit meiner frau, vielleicht später *g*

 

aber was anderes:

beim shutdown des images kommen 2 meldungen die besagen das er sowohl var als auch tmp nicht unmounten konnte weil die busy waren. könnte das der grund sein für solche effekte?

[wonderdoc]

@SnowHead

Sind die bereitgestellten betas/RCx Versionen eigentlich frisch kompelierte Images oder waren sie bereits einmal geflasht?

 

@niemand0815

OK, Link habe ich dir per PN gesendet, hast du es dir bereits runter geladen.

Teste es bitte dann später mal, würde mich echt mal interessieren.

Sichere deins aber vorher.

 

mfg

Wonderdoc

[SnowHead]

@wonderdoc

 

Die Images sind frisch compiliert. Die Preconfiguration funktioniert

nämlich nur beim ersten Start.

[dietz]

Unmounting -f 'ext2' on '/hdd'

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS

debug: BMon V1.2  mID 03

debug: feID 00    enxID 03

debug: fpID 52    dsID xxxxxxxxxxxxxxx

debug: HWrev 61  FPrev 0.23

debug: B/Ex/Fl(MB) 32/00/08

WATCHDOG reset enabled

dbox2:root> debug:

BOOTP/TFTP bootstrap loader (v0.3)

debug:

debug: Transmitting BOOTP request via broadcast

debug: Given up BOOTP/TFTP boot

boot net failed

 

Flash-FS bootstrap loader (v1.5)

 

Found Flash-FS superblock version 3.1

Found file /root/platform/sagem-dbox2/kernel/os in Flash-FS

debug: Got Block #0040

 

will verify ELF image, start= 0x800000, size= 162920

verify sig: 262

Branching to 0x40000

 

 

U-Boot 1.2.0 (Tuxbox) (Nov 11 2007 - 14:35:44)

 

CPU:  PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache

Board: DBOX2, Sagem, BMon V1.2

      Watchdog enabled

I2C:  ready

DRAM:  32 MB

FLASH:  8 MB

Scanning JFFS2 FS: ... done.

FB:    ready

LCD:  ready

In:    serial

Out:  serial

Err:  serial

Net:  SCC ETHERNET

 

Options:

  1: Console on null

  2: Console on ttyS0

  3: Console on framebuffer

Select option (1-3), other keys to stop autoboot:  0

### FS (squashfs) loading 'vmlinuz' to 0x100000

### FS load complete: 669733 bytes loaded to 0x100000

............................................................... done

Un-Protected 63 sectors

## Booting image at 00100000 ...

  Image Name:  dbox2

  Image Type:  PowerPC Linux Kernel Image (gzip compressed)

  Data Size:    669669 Bytes = 654 kB

  Load Address: 00000000

  Entry Point:  00000000

  Verifying Checksum ... OK

  Uncompressing Kernel Image ... OK

Linux version 2.4.35.3-dbox2 (image@Server) (gcc version 3.4.4) #14 So Nov 11 14

:36:16 CET 2007

On node 0 totalpages: 8192

zone(0): 8192 pages.

zone(1): 0 pages.

zone(2): 0 pages.

Kernel command line: console=ttyS0 root=/dev/mtdblock2 rootfstype=squashfs

Decrementer Frequency = 247500000/60

m8xx_wdt: active wdt found (SWTC: 0xFFFF, SWP: 0x1)

m8xx_wdt: keep-alive trigger installed (PITC: 0x2000)

Console: colour dummy device 80x25

Calibrating delay loop... 65.74 BogoMIPS

Memory: 30828k available (1144k kernel code, 336k data, 60k init, 0k highmem)

Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)

Inode cache hash table entries: 2048 (order: 2, 16384 bytes)

Mount cache hash table entries: 512 (order: 0, 4096 bytes)

Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)

Page-cache hash table entries: 8192 (order: 3, 32768 bytes)

POSIX conformance testing by UNIFIX

Linux NET4.0 for Linux 2.4

Based upon Swansea University Computer Society NET3.039

Initializing RT netlink socket

Starting kswapd

devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)

devfs: boot_options: 0x1

JFFS2 version 2.2. (NAND) © 2001-2003 Red Hat, Inc.

squashfs: version 3.0 (2006/03/15) Phillip Lougher

i2c-core.o: i2c core module version 2.6.1 (20010830)

i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)

CPM UART driver version 0.04

ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2

pty: 256 Unix98 ptys configured

eth0: CPM ENET Version 0.2.dbox2 on SCC2, 00:50:9c:3b:90:08

loop: loaded (max 8 devices)

D-Box 2 flash driver (size->0x800000 mem->0x10000000)

D-Box 2 flash memory: Found 1 x16 devices at 0x0 in 16-bit bank

Intel/Sharp Extended Query Table at 0x0031

Using buffer write method

cfi_cmdset_0001: Erase suspend on write enabled

Creating 6 MTD partitions on "D-Box 2 flash memory":

0x00000000-0x00020000 : "BR bootloader"

0x00020000-0x00040000 : "FLFS (U-Boot)"

0x00040000-0x005e0000 : "root (squashfs)"

0x005e0000-0x00800000 : "var (jffs2)"

0x00020000-0x00800000 : "Flash without bootloader"

0x00000000-0x00800000 : "Complete Flash"

Linux video capture interface: v1.00

mice: PS/2 mouse device common for all mice

NET4: Linux TCP/IP 1.0 for NET4.0

IP Protocols: ICMP, UDP, TCP

IP: routing cache hash table of 512 buckets, 4Kbytes

TCP: Hash tables configured (established 2048 bind 4096)

NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

VFS: Mounted root (squashfs filesystem) readonly.

Mounted devfs on /dev

Freeing unused kernel memory: 60k init

init started: BusyBox v1.7.2 (2007-11-11 14:40:22 CET)

 

 

Chip reports voltage low on erase: status 0xa8

Erase at 0x00180000 failed immediately: errno -5

##### Image-Version: Keywelt_Okt2007_V1_RC2 #####

 

Sun Nov 11 14:55:00 UTC 2007

Chip reports voltage low on erase: status 0xa8

Erase at 0x00160000 failed immediately: errno -5

event: $Id: event.c,v 1.12 2003/09/30 05:45:38 obi Exp $

Chip reports voltage low on erase: status 0xa8

Erase at 0x00140000 failed immediately: errno -5

Detected STB:

  Vendor: Sagem

  Model: D-BOX2

Chip reports voltage low on erase: status 0xa8

Erase at 0x00120000 failed immediately: errno -5

insmod: warning: kernel-module version mismatch

        /lib/modules/2.4.35.3-dbox2/misc/dvb-core.o was compiled for kernel vers

ion 2.4.34-dbox2

        while this kernel is version 2.4.35.3-dbox2

[i2c-8xx]: mpc 8xx i2c init

[i2c-8xx]: adapter: 0

insmod: warning: kernel-module version mismatch

        /lib/modules/2.4.35.3-dbox2/misc/dbox2_fp_input.o was compiled for kerne

l version 2.4.34-dbox2

        while this kernel is version 2.4.35.3-dbox2

$Id: cam.c,v 1.30 2004/01/10 16:36:34 alexw Exp $

$Id: avia_napi.c,v 1.18 2003/11/24 09:53:01 obi Exp $

DVB: registering new adapter (C-Cube AViA GTX/eNX with AViA 500/600).

dvb_i2c_bridge: enabled DVB i2c bridge to PowerPC 8xx I2C adapter

$Id: cam_napi.c,v 1.8 2003/09/30 05:45:34 obi Exp $

 

KEYWELT Pre-Configuration

 

insmod: warning: kernel-module version mismatch

        /lib/modules/2.4.35.3-dbox2/misc/avia_av.o was compiled for kernel versi

on 2.4.34-dbox2

        while this kernel is version 2.4.35.3-dbox2

avia_av: $Id: avia_av_core.c,v 1.99 2006/01/08 21:36:22 carjay Exp $

avia_av_core: Starting avia_av_wdt thread.

avia_av_event: $Id: avia_av_event.c,v 1.11 2003/10/26 16:32:51 obi Exp $

avia_av_proc: $Id: avia_av_proc.c,v 1.14 2004/01/21 20:02:29 carjay Exp $

avia_gt_core: $Id: avia_gt_core.c,v 1.48 2004/12/20 01:01:22 carjay Exp $

avia_gt_core: autodetecting chip type... eNX

avia_gt_enx: $Id: avia_gt_enx.c,v 1.21 2003/09/30 05:45:35 obi Exp $

avia_gt_accel: $Id: avia_gt_accel.c,v 1.19 2003/09/30 05:45:35 obi Exp $

avia_gt_dmx: $Id: avia_gt_dmx.c,v 1.210 2004/06/26 16:08:15 carjay Exp $

avia_gt_ucode: loaded ucode v0014

avia_gt_ucode: ucode section filters disabled.

avia_gt_dmx: warning, misaligned queue 0 (is 0xFD200, size 65536), aligning...

avia_gt_gv: $Id: avia_gt_gv.c,v 1.39 2004/08/28 16:44:56 carjay Exp $

avia_gt_gv: set_input_size (width=720, height=576)

avia_gt_pcm: $Id: avia_gt_pcm.c,v 1.29 2004/01/29 19:38:20 zwen Exp $

avia_gt_pcm_set_rate(44100)

avia_gt_capture: $Id: avia_gt_capture.c,v 1.32 2003/09/30 05:45:35 obi Exp $

avia_gt_pig: $Id: avia_gt_pig.c,v 1.40 2003/09/30 05:45:35 obi Exp $

avia_gt_vbi: $Id: avia_gt_vbi.c,v 1.26 2003/08/01 17:31:22 obi Exp $

avia_gt_core: Loaded AViA eNX/GTX driver

avia_gt_fb: $Id: avia_gt_fb_core.c,v 1.54 2004/03/17 18:42:18 zwen Exp $

avia_gt_gv: set_input_mode (mode=2)

avia_gt_gv: set_input_size (width=720, height=576)

avia_gt_gv: set_input_mode (mode=2)

avia_gt_gv: set_input_size (width=720, height=576)

avia_gt_gv: set_input_mode (mode=2)

avia_gt_gv: set_input_size (width=720, height=576)

Console: switching to colour frame buffer device 82x32

avia_gt_fb: fb0: AViA eNX/GTX Framebuffer frame buffer device

avia_av_core: Starting avia_gt_wdt thread.

lcd.o: init lcd driver module

lcd.o: found KS0713/SED153X lcd interface

avia_gt_lirc: $Id: avia_gt_lirc.c,v 1.14 2003/09/30 05:45:35 obi Exp $

avia_gt_ir: $Id: avia_gt_ir.c,v 1.30 2003/09/30 05:45:35 obi Exp $

avia_oss: $Id: avia_gt_oss.c,v 1.26 2004/05/31 22:56:02 carjay Exp $

avia_gt_pcm_set_rate(44100)

avia_gt_v4l2: $Id: avia_gt_v4l2.c,v 1.12 2003/09/30 04:54:03 obi Exp $

insmod: warning: kernel-module version mismatch

        /lib/modules/2.4.35.3-dbox2/misc/at76c651.o was compiled for kernel vers

ion 2.4.34-dbox2

        while this kernel is version 2.4.35.3-dbox2

DVB: registering frontend 0:0 (Atmel AT76C651A with TUA6010XS)...

avia_av_napi.c: $Id: avia_av_napi.c,v 1.33 2004/03/11 15:30:27 derget Exp $

avia_gt_napi: $Id: avia_gt_napi.c,v 1.203 2005/01/05 05:49:56 carjay Exp $

 

Please press Enter to activate this console. $Id: sectionsd.cpp,v 1.249 2007/10/

30 08:48:23 seife Exp $

[sectionsd] Caching max 6000 events

[sectionsd] Caching 14 days

[sectionsd] Caching 6 hours Extended Text

[sectionsd] Events are old 60min after their end time

/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory

/var/tuxbox/config/mybouquets.xml: No such file or directory

[ConfigFile] Unable to open file /var/tuxbox/config/timerd.conf for reading.

/var/plugins/operations camd_init

/var/plugins/operations cardserver_start

$Id: zapit.cpp,v 1.403 2007/11/08 19:32:15 Kroki & Worschter & SnowHead Exp $

[zapit] MAX_SOCKETS=3

[zapit] PMT update enabled

[frontend] uncommitted_switch_mode 0

/var/plugins/operations camd_start

insmod: warning: kernel-module version mismatch

        /var/modules/multicam.o was compiled for kernel version 2.4.34-dbox2

        while this kernel is version 2.4.35.3-dbox2

DBox2 Multicam Driver v1.01 skars & doz21

starte camd2

[camd2] EMM : active

[camd2] Socket=/tmp/camd.sock02

[camd] ca system id: 1702

[getservices] /var/tuxbox/config/zapit/myservices.xml  found.

[getservices] dup transponder id 3 onid 85

[getservices] dup transponder id 11 onid 85

[getservices] dup transponder id 2 onid 85

[getservices] dup transponder id 4 onid 85

[getservices] dup transponder id 1 onid 85

/tmp/currentservices.xml: No such file or directory

$Id: controld.cpp,v 1.127 2007/07/01 08:40:13 dbluelle Exp $

 

[controld] Boxtype detected: (3, Sagem D-BOX2)

[controld]: ROUTEVIDEO v1 = 0 a1 = 0 v2 = 0 a2 = 0 fblk=1

[yhttpd] Webserver nhttpd/3.1.3 (yhttpd_core/1.2.0)

[LCDFONT] initializing core...

[LCDFONT] adding font /share/fonts/micron.ttf...OK (Micron/Regular)

[LCDFONT] adding font /share/fonts/micron_bold.ttf...OK (Micron/Bold)

[LCDFONT] adding font /share/fonts/pakenham.ttf...OK (Pakenham/Regular)

[LCDFONT] Intializing font cache...

[sectionsd] getUTC: read: Connection timed out

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[yhttpd] Webserver starting...

/var/plugins/operations epg_reinit

neutrino: /lib/libpng12.so.0: no version information available (required by neut

rino)

starting /bin/neutrino

[neutrino] frameBuffer Instance created

812k video mem

avia_gt_gv: set_input_mode (mode=2)

avia_gt_gv: set_input_size (width=720, height=576)

[neutrino] Software update enabled

[neutrino] enable flash

[neutrino] Loading of scan settings failed. Using defaults.

[lcdd] time-skin not found -> using default...

[lcdd] weekday-skin not found -> using default...

[lcdd] date-skin not found -> using default...

[lcdd] month-skin not found -> using default...

[LCDFONT] initializing core...

[LCDFONT] adding font /share/fonts/12.pcf.gz...OK (Fix12/Regular)

[LCDFONT] adding font /share/fonts/14B.pcf.gz...OK (Fix14/Bold)

[LCDFONT] adding font /share/fonts/15B.pcf.gz...OK (Fix15/Bold)

[LCDFONT] Intializing font cache...

[LCDFONT] FTC_Face_Requester (Fix15/Bold)

[LCDFONT] FTC_Face_Requester (Fix14/Bold)

/dev/input/event1: No such file or directory

[neutrino] menue setup

[neutrino] registering as event client

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[basicsocket] send_data: Resource temporarily unavailable

[frontend.cpp:setFrontend:211] ioctl(fd, FE_SET_FRONTEND, feparams): Invalid arg

ument

[neutrino] initialized everything

[frontend.cpp:setFrontend:211] ioctl(fd, FE_SET_FRONTEND, feparams): Invalid arg

ument

zap failed!

[sectionsd] getUTC: read: Connection timed out

[sectionsd] getUTC: read: Connection timed out

 

So siehts bei mir aus beim flashen der rc3 zum Vergleichen

var 75%