NHD2 - Bug - Liste

[mohousch]

Danke, na OK war keine gute Idee den Tuner zu locken ;_(

[DboxOldie]

Na ja, wichtig ist ja das man recorden kann und den anderen Tuner gleichzeitig nutzen.
Beim Streaming ist auch ´ne 7105er Box reichlich ausgelastet, insbesondere bei HD und codiert.

[BPanther]

Denke mal, daß ist beim streamen normal, da hier alles versucht wird direkt zu streamen was gerade läuft. Multi wird da nicht gehen. Selbst wenn man die UFS910 oder gar DBox2 nimmt ist ein Umschalten beim streamen fatal und führt oft dann zum Tunerabsturz oder anderen Phänomenen.

[Grabber66]

Hi,

ich habe mal eine Frage. Weil ich gar nicht sagen kann ob es ein Bug ist oder nicht ?
Und zwar habe ich jeweils das gleiche Image, für die cuberevo und die mini_2 gebaut.
In beiden wird ein swapfile genutzt, und es läuft auch die identische cam drauf. Auch
die Settings sind soweit identisch, bis auf die ip-adresse. Channellist ist auch gleich.
Das einziege was anders ist, ist das die Cuberevo via hdmi an nem flat hängt und
die mini_2 via scart an ner alten Röhre. Bei beiden boxen habe ich den Standbymodus an.
Sie laufen nun schon seid 2 Tagen so. Aber die Cuberevo musste ich schon mehrfach
neu starten, da sie nach 4-5h dermassen träge wird, das ich sie nicht mehr bedienen kann.
Der aufbau der Channellist dauert dann ca. 4-5 sec. Dabei ist es egal ob ich die logos
an habe oder nicht. Auf der mini_2 sind sie an ? Minitv ist bei beiden auch aus.

Kann ich da irgentwas loggen, nachschauen etc. Denn ich wüsste nicht was. Laufen
tuts ja alles, nur halt super träge ?

[mohousch]

etwas raubt den RAM weg, ich weiss nicht ob die partition für graphic und video vom Kernel her für beiden Boxen Modellen unterschiedlich sind, vielleicht liegt daran dass der gfx oder lmi_vid Bereich schnell an seinen Grenzen kommt?

[Matze2002]

@Grabber66 : Genau das hab ich bei der UFS910 auch...
Hast du was mit Radio oder Videotext gemacht ?? Denn da läuft wohl irgendwas nicht ganz rund. Wenns eine zeitlang auf Radiomodus läuft und dann wieder zurück in TV mode geht, wird die Box immer träger und es dauert sehr lange bis die Box dann reagiert..

[mohousch]

wie sieht es mit epg-Einstellugen aus? der ist auch ein RAM Fresser.

[Grabber66]

@matze
In der richtung habe ich nichts gemacht. Hab eben nochmal probiert.

@mohousch
Wegen dem videoram ich hab da nichts geändert.
Auszug aus dem "linux-sh4-cuberevo_setup_stm24_0211.patch"

Code: Alles auswählen

+// 32MB flash
+#define WINDOW_ADDR	0xA0000000
+#define WINDOW_SIZE	0x02000000
+
+#define BOOT_SIZE	0x040000	// boot loader
+#define WELCOME_SIZE	0x020000	// welcomeboot config
+#define KERNEL_SIZE	0x220000	// kernel size
+#define ROOT_SIZE	(WINDOW_SIZE-WELCOME_SIZE-KERNEL_SIZE-DB_SIZE-BOOT_SIZE)
+#define DB_SIZE	0x800000

Wegen dem EPG muss ich mal schauen, ich hatte da mal umgestellt auf epg speichern, habs dann aber wieder rückgängig gemacht.
Ich flashe einfach nochmal neu und schaue dann was passiert.

[DboxOldie]

Da ist ja die Flash Partitionierung...

Frag mal ab im Telnet: cat /proc/bpa2

Video Ram ist die Ecke im Setup: ( ist aber Spark2 )

Code: Alles auswählen

const char *LMI_IO_partalias[] = { "v4l2-coded-video-buffers", "BPA2_Region1", "v4l2-video-buffers" ,
                                    "coredisplay-video", "gfx-memory", "BPA2_Region0", "LMI_VID", NULL };

/*
0x40000000 - 0x403FFFFF - cocpu 1 ram (4mb)
0x40400000 - 0x407FFFFF - cocpu 2 ram (4mb)
0x40800000 - 0x49FFFFFF - linux   (152mb)
0x49E00000 - 0x4B0FFFFF - bigphys ( 19mb)
0x4B100000 - 0x4FFFFFFF - lmi_io  ( 78mb)
*/
static struct bpa2_partition_desc bpa2_parts_table[] = {
    {
 	    .name  = "bigphysarea",
	    .start = 0x49E00000,
	    .size  = 0x01300000, /* 19 Mb */
 	    .flags = 0,
 	    .aka   = NULL
    },
    {
 	    .name  = "LMI_IO",
	    .start = 0x4B100000,
	    .size  = 0x04F00000, /* 78 Mb */
 	    .flags = 0,
 	    .aka   = LMI_IO_partalias
    },
 };

[Grabber66]

Hast recht, hier mal der passende Auszug:

Code: Alles auswählen

 #define MB442_PIO_SMC91X_RESET stm_gpio(2, 6)
 #define MB442_PIO_FLASH_VPP stm_gpio(2, 7)
 
+const char *LMI_VID_partalias[] = { "BPA2_Region1", "coredisplay-video", "gfx-memory", "v4l2-video-buffers", NULL };
+const char *LMI_SYS_partalias[] = { "BPA2_Region0", "bigphysarea", "v4l2-coded-video-buffers", NULL };
+ 
+#ifdef CONFIG_32BIT
+static struct bpa2_partition_desc bpa2_parts_table[] = {
+	{
+		.name  = "LMI_VID",
+		.start = 0x81000000,
+		.size  = 0x07000000,
+		.flags = 0,
+		.aka   = LMI_VID_partalias
+	},
+	{
+		.name  = "LMI_SYS",
+		.start = 0,
+		.size  = 0x05000000,
+		.flags = 0,
+		.aka   = LMI_SYS_partalias
+	}
+};
+#else
+static struct bpa2_partition_desc bpa2_parts_table[] = {
+	{
+		.name  = "LMI_VID",
+		.start = 0x10800000,
+		.size  = 0x03800000,
+		.flags = 0,
+		.aka   = LMI_VID_partalias
+	},
+	{
+		.name  = "LMI_SYS",
+		.start = 0,
+		.size  = 0x02600000,
+		.flags = 0,
+		.aka   = LMI_SYS_partalias
+	}
+};
+#endif /* CONFIG_32BIT */

Wobei ich nun seid 2h das Image komplett neu aufgespielt habe und es bislang klappt.
Ich werde es mal wie üblich im standby lassen und morgen wieder nachschauen.
Vielleicht war es ja wirklich was an den EPG einstellungen. Wobei es mich wundert
das es dann nicht nach zurücksetzen auf "nicht speichern" nicht besser geworden ist.

[BPanther]

Hmm, warum sollte "speichern/nicht speichern" was daran ändern? Ich meine, das wirkt doch eh nur beim Start/Standby/Box abschalten und nicht direkt im laufenden Betrieb, da nur dann die Daten geladen/gespeichert werden. Von daher sollte es eigentlich keinen Unterschied machen.

[Grabber66]

Ist es auch nicht gewesen. Box läuft jetzt nicht mehr so wie sie soll.
Irgentwie dauert es nun etwas länger, aber irgentwann nach ein paar stunden
ist sie wieder sehr träge...

[Grabber66]

Ich wollte jetzt mal testeweise was an den kerneleinstellungen ändern.
Für die mini_2 wurde da ja mal was geändert. Vielleicht komme ich ja damit weiter....
https://gitorious.org/~max10/open-duckb ... 0211.patch

Aber wenn ich da was ändere, muss ich dann noch was an einer anderen Stelle ändern, damit ich auc ein lauffähiges
Flashimage bekomme.

[BPanther]

Wenn Du die Part-Größen des Flash (nicht LMI, der ist egal) änderst, dann auch im NOR-Flash-Script (flash_part_w_fw.sh, Zeilen 70-72) mit anpassen.

[Grabber66]

Ich hab jetzt mal den LMI Bereich der cuberevo und der mini_2 verglichen:
Cuberevo

Code: Alles auswählen

+static struct bpa2_partition_desc bpa2_parts_table[] = {
+	{
+		.name  = "LMI_VID",
+		.start = 0x10800000,
+		.size  = 0x03800000,
+		.flags = 0,
+		.aka   = LMI_VID_partalias
+	},
+	{
+		.name  = "LMI_SYS",
+		.start = 0,
+		.size  = 0x02600000,
+		.flags = 0,
+		.aka   = LMI_SYS_partalias
+	}
+};

Mini_2:

Code: Alles auswählen

+static struct bpa2_partition_desc bpa2_parts_table[] = {
+	{
+		.name  = "LMI_VID",
+		.start = 0x10800000,
+		.size  = 0x03800000,
+		.flags = 0,
+		.aka   = LMI_VID_partalias
+	},
+	{
+		.name  = "LMI_SYS",
+		.start = 0,
+		.size  = 0x01300000,
+		.flags = 0,
+		.aka   = LMI_SYS_partalias
+	}
+};

Bei der Cuberevo ist der LMI_SYS Part ja doppelt so groß wie bei der mini_2.
Ich hatte eigentlich vorher gedacht ich erhöhe mal den LMI_VID, aber wenn
ich das so sehe, könnte mir nicht auch ne verkleinerung des SYS-Parts evtl. eher helfen?

Und in den "alten" stm22 configs die ich hier noch auf der Platte hatte steht folgendes:

Code: Alles auswählen

+static struct bpa2_partition_desc bpa2_parts_table[] = {
+	{
+		.name  = "LMI_VID",
+		.start = 0x10800000,
+		.size  = 0x03800000,
+		.flags = 0,
+		.aka   = LMI_VID_partalias
+	},
+	{
+		.name  = "LMI_SYS",
+		.start = 0,
+		.size  = 0x01600000,
+		.flags = 0,
+		.aka   = LMI_SYS_partalias
+	}
+};
+#endif