sectionsd Patches committed

[dwilx]

Warum die Chipinfos nicht gleich vom Kernel aus nach /proc schieben und die Infos dann einfach abholen. Im ULC war doch mal ein Patch dafür.
http://ulc.tuxbox-cvs.sourceforge.net/i ... tory=Diffs&
Wäre das nicht am einfachsten?

[seife]

@seife

funktioniert soweit, nur das nach einem Neustart der EPG nicht automatisch auf ein geht.
Du hast die variable "scanning" nicht mit im ENV gespeichert setzt die nach dem Restartauf auf 0. Und dann liest du die Variablen ein und diese werden von der Main-Routine gleich wieder überschreiben ... da solltest du noch mal drüber schauen ....

Das ist Absicht. "Restarts in paused mode".
Die Idee ist, daß man vor der Aufnahme den sectionsd restartet, er aber nicht losläuft, um nicht sofort wieder Speicher zu belegen, und er nach Beenden der Aufnahme wieder gestartet wird.

Ansonsten hast du im Imageinfo die Routine zum Flash-Type erkennen geändert.

Und das hat mit "sectionsd Patches committed" was zu tun?

Ich finde die Lösung so nicht ok, weil ich und andere ein anderes Flashlayout nutzen, wo es den BR-Bootloader nicht mehr drinnen gibt, sowas z.B:

Code: Alles auswählen

dev:    size   erasesize  name
mtd0: 00020000 00020000 "U-Boot (flfs)"
mtd1: 006a0000 00020000 "root (squashfs)"
mtd2: 00120000 00020000 "var (jffs2)"
mtd3: 007e0000 00020000 "Flash komplett"

Das habe ich im CVS nicht gefunden. Wenn ich gewußt hätte, daß es das gibt, hätte ich entsprechend flexibler gemacht. Zeig mir doch mal die Stelle im Code, wo das gemacht wird.

Die Erkennung kann man auch über das flfs machen :

Code: Alles auswählen

string CImageInfo::getChipInfo()
{
                FILE* fd = fopen("/dev/mtd/0", "r");
                if(fd)
                {
                        char buffer[20];

                        for ( int i=0;i<=10;i++)
                                buffer[i]=fgetc(fd);

                        if(buffer[2] == 0x03 && buffer[3] == 0x01 && buffer[4] == 0x00 && buffer[5] == 0x3F )
                                        chiptype = "1xI";
                        else if(buffer[4] == 0x03 && buffer[5] == 0x01 && buffer[8] == 0x00 && buffer[9] == 0x7E )
                                        chiptype = "2xI";
                        else
                                        chiptype ="n/a";

                        fclose(fd);
                }
                else
                         chiptype ="Error";

        return chiptype;
}

was, wenn nicht mtd0 das flfs ist?

Ist auch nicht komplizierter, aber einfacher an die Images anzupassen ....

Kroki

Welches Image hat das denn so? Weder meine oldmake-Tests, noch meine newmake-Images haben das so.

[DrStoned]

Warum die Chipinfos nicht gleich vom Kernel aus nach /proc schieben und die Infos dann einfach abholen. Im ULC war doch mal ein Patch dafür.
http://ulc.tuxbox-cvs.sourceforge.net/i ... tory=Diffs&
Wäre das nicht am einfachsten?

Offtopic On:

Eventuell behebt das den Fehler, wenn man die Meldungen aus /proc abholt, dass nach einer gewissen Laufzeit der Box die Meldungen nicht mehr abholen kann, da sie nicht mehr zur Verfügung stehen. Vor kurzem ist mir das mal aufgefallen, als ich bei meiner Schlafzimmerbox über Dbox-Taste -> Service -> Image Information, die Imageinfos anschauen wollte. Die Box lief zu dem Zeitpunkt über 45 Tage und es waren einige Meldungen nicht verfügbar, nach neu Flashen der Box ging wieder alles. Dies musste ich tun, da das FFFS2-Dateisystem der Box defekt war. Kann aber auch sein, dass es daran lag, dass das JFFS2 Dateisystem geplatzt war. Kanns momentan nicht nachvollziehen, da die Box nach dem neu flashen erst wieder 4 Tage läuft.

Offtopic off:

Greetz von DrStoned

[seife]

Genau das wird damit gefixt. Der dmesg-buffer läuft relativ schnell über (16kByte glaube ich), dann sind die Infos vom Booten weg. So, genug OT