Kernel 2.6

[Npq]

Also um mal Enttäuschungen vorzubeugen. Der 2.6er-Treiberzweig ist mehr oder weniger experimentell. Er läuft - aber mit Abstrichen. Der Kernel-MMU-Zweig für den 823 ist noch nicht fertig portiert, so daß es Oopse beim Debuggen gibt. Im Normalbetrieb läuft es, seit den letzten Änderungen sogar präemptiv. Ab dem 2.6.10er ist der 823 wieder broken, also funktioniert momentan nur der 2.6.9_linuxppc.

Aber: Die Treiber werden nicht besser dadurch und die Frontendtreiber sind nicht komplett. Daher wäre es fatal, einfach umzustellen. Das würde nur zu schwarzen Bildschirmen und gefrusteten Benutzern führen.

Nochmal: der 2.6er ist keine magische Angelegenheit, die alle Schwächen im System kuriert. Darüber hinaus ist er momentan ca. 100-200kB größer als der 2.4er, so daß das für einige auch ein Platzproblem werden könnte (ich kenne mich mit den Images jetzt nicht aus ).

Speziell die Frontends sind ein Problem weil diese meiner Meinung nach nur richtig von denjenigen portiert und getestet werden können, die sie auch besitzen. Darüber hinaus gibt es laut Berichten auch noch Probleme mit dem Frontprozessor (reagiert nicht auf Fernbedienung)

Ich selber habe nur 2 ves1x93-Boxen, so daß alle anderen FEs bei mir außen vor bleiben.

Wer testen möchte, kann die vorhandenen Patche nutzen und muß sich dann nur um die Anpassung der Skripte kümmern.

Wer Lust hat, die Frontendtreiber zu portieren ist natürlich ebenfalls herzlich eingeladen, sich daran zu beteiligen.

[mash4077]

Oh, das finde ich aber sehr nett, dass Du hier so interessante Infos preisgibst.

Gruß
mash

[gmo18t]

Hi,

@npq: leider kenn ich mich mit den Linux DVB Sachen noch nicht besonders gut aus, aber mal zum Verständnis eine Frage:

Der Frontend Treiber z.B. "ves1820.c" wurde doch 1:1 aus "linuxtv-1.1.1" genommen, also enthält keine Anpassungen für ppc oder speziell die dbox. Das Teil läuft also auf PC basierenden Systemen genauso wie auf der dbox im 2.4er-Kernel Umfeld.

Warum müßte nun die 2.6.9er Variante des "ves1820.c" bei der dbox Kernel Portierung überhaupt angepackt werden.
Ist da nun aufeinmal eine hardwaretechnische Abhängigkeit reingekommen (Sollte doch auch auf pppc/dbox gehen wenn's auf i386-System läuft) ?

- GMo -

[Npq]

Hmm, dann ist das "#if defined (CONFIG_DBOX2)" direkt am Anfang der ves1820.c wohl nur eine Einbildung von mir.

Mal im Ernst, da sind schon noch Anpassungen für die dbox2 drin, die Treiber sind ja auch teilweise durch das Tuxbox-Projekt entstanden.

Aber es sind nicht alle Frontends drin, tda8044/tda80xx (Philips Sat) sind nicht vorhanden. stv0297 war glaube ich die Kabel-Philips-Entwicklerbox und sqc6100 war für die DVB-T-Entwicklerboxen.

Eigentlich fehlen somit für die "normalen" Boxen nur die Treiber für die Philips. ves1820 (Kabel Nokia) und at76c651 (Kabel Sagem) sind drin aber ungetestet.

[HEAD]

Aber es sind nicht alle Frontends drin, tda8044/tda80xx (Philips Sat) sind nicht vorhanden.

ves1x93.c und tda80xx.c sind in kernel 2.6.10 vorhanden.

[gmo18t]

ups, doppelt gepostet - sorry !

- GMo -

[gmo18t]

Hmm, dann ist das "#if defined (CONFIG_DBOX2)" direkt am Anfang der ves1820.c wohl nur eine Einbildung von mir.

Mal im Ernst, da sind schon noch Anpassungen für die dbox2 drin, die Treiber sind ja auch teilweise durch das Tuxbox-Projekt entstanden.

ja sind Anpassungen für dbox2 drin -> die wurden aber in den 2.6er Kernel mitgenommen und im Falle des ves1820 sind die dbox-Spezifika nur minimal...
Also könnte es doch mit ein wenig Glück auch wieder laufen.

Beim at76c651 gibt's überhaupt kein "#if defined (CONFIG_DBOX2)" -> da sieht's doch auch schon prima aus. Andere Frontends hab ich noch nicht untersucht. Aber wenn's dort ähnlich ist, sollten die Frontends zumindestens vom Portierungsaufwand kein Problem sein.

Tests müssen in jedem Fall gemacht werden. Und wenn's soweit ist, finden sich vielleicht schon ein paar Kandidaten, die sich das jeweilige Frontend vornehmen (ich z.B. den "at76c651").

@HEAD: ves1x93.c ist bereits im 2.6.9er drin. Die Frontend Sourcen aus dem 2.6.10er sind - glaub ich - nicht zu gebrauchen, da dort bereits eine Designänderung vorgenommen wurde ...

- GMo -

[Npq]

Ja, bei der neusten dvb-core wurde der Adapter(dbox2)-spezifische Kram doch mal rausgenommen und einige Sachen verbessert/überarbeitet.

Direkt reinkopiert kompilieren diese 3.1er API-Treiber nicht in einem alten 3.0er Stand.

[woglinde]

Hi,

hab am WE mal 2.6.11-rc2 probier weil ein paar mpc8xx patche eingeflossen
sind, reicht aber noch nicht die Box resetet unregelmaessig beim kernelstart.

gruss woglinde

[mash4077]

Aber: Die Treiber werden nicht besser dadurch...

Nochmal: der 2.6er ist keine magische Angelegenheit, die alle Schwächen im System kuriert.

- make avia watchdog less intrusive (no more interrupts, just watch the
situation every 2 secs and listen to buffer overflow / stream
error interrupt)

Steht das im Widerspruch zueinander?

Gruß
mash

[Npq]

Hmm, nicht wirklich, da der Commit nicht vom Kernel 2.6 selber kam.

Die Aussage sollte nur heißen, daß sich nicht jeder unbedingt auf den 2.6er stürzen muß weil allein durch das OS sich noch nicht viel ändern wird, sondern die Hauptproblematik an den Treibern hängt und wenn die im 2.4er Probleme bereiten werden sie das im 2.6er auch tun und gepaart mit den nötigen Änderungen (und dadurch sicherlich einfließenden Bugs) sind sie sogar als weniger stabil zu bezeichnen.

[Houdini]

Moin,

ich habe eine cdk version für 2.6 angelegt und eine yadd für 2.6.10 mit den Treibern für 2.6 kompiliert.
Jetzt bin ich dabei, das Laden der Kernelmodule anzupassen.
Folgende Probleme:
- Busybox insmod findet die .ko files nicht. Ich muß immer den vollen Pfad angeben.
- Wie in aller Welt bringe ich die Module dazu, die Firmware Files (cam-alpha etc) zu laden.
Den Parameter gibt es nicht mehr und gemeldet wird nur cam-alpha.bin nicht gefunden.
Ich hab nur noch nicht rausbekommen wo nach der Firmware gesucht wird.
Oder muß man die im Userspace über /sys/class/firmware reinnudeln.

Any comments welcome
Houdini

[gmo18t]

Moin,

ich habe eine cdk version für 2.6 angelegt und eine yadd für 2.6.10 mit den Treibern für 2.6 kompiliert.
Jetzt bin ich dabei, das Laden der Kernelmodule anzupassen.
Folgende Probleme:
- Busybox insmod findet die .ko files nicht. Ich muß immer den vollen Pfad angeben.

ist normal (nur modprobe geht ohne Pfad). Du hast ja auch dran gedacht busybox mit 2.6er Module support zu übersetzen ...

- Wie in aller Welt bringe ich die Module dazu, die Firmware Files (cam-alpha etc) zu laden.
Den Parameter gibt es nicht mehr und gemeldet wird nur cam-alpha.bin nicht gefunden.
Ich hab nur noch nicht rausbekommen wo nach der Firmware gesucht wird.
Oder muß man die im Userspace über /sys/class/firmware reinnudeln.

die Firmware wird über den Hotplug-Mechanismus geladen. Du must explizit das Script "hotplug"
aus "/apps/tuxbox/tools/hotplug" nehmen und nach "/sbin" kopieren.
Die Firmware files müssen im selben Verzeichnis, wie es auch beim 2.4er verwendet wird, liegen.
Die Module benötigen nicht mehr die Angabe der Firmware als Parameter -> das wird jetzt "intern",
automatsich geregelt...

- GMo -

[Houdini]

Du hast ja auch dran gedacht busybox mit 2.6er Module support zu übersetzen ...

yep

Mein 2.4 busybox insmod finded die Module aber immer ohne Pfad.

Also wird die Firmware nicht mehr beim Laden des Moduls sondern später eingespielt, ok.
Aber trotzdem sagt es mir das er cam-alpha.bin nicht findet.
Muß ich das Skript direkt nach dem Laden des Moduls ausführen?

Ich check es heut abend

Danke
Houdini

[gmo18t]

Mein 2.4 busybox insmod finded die Module aber immer ohne Pfad.

macht ja nix, wenn Du jetzt halt den Pfad mitangibst (stärkt den Tippfinger )

Also wird die Firmware nicht mehr beim Laden des Moduls sondern später eingespielt, ok.

doch, doch - beim Laden wird die Firmware reingezogen automatisch über den Hotplug Mechanismus, d.h. der Kernel führt dann beim "Modul-Load" das Script "/sbin/hotplug" aus. Und dieses Script, welches ich Dir ja oben genannt habe (und nur das) hilft dann beim Laden der Firmware ...
Den Namen des vom Kernel auszuführenden Hotplug-Scripts, kann man übrigens über "/proc/sys/kernel/hotplug" einstellen -> "/sbin/hotplug" ist halt eben default !

- GMo -

[Houdini]

Ahh jetzt ja,

das ist doch mal ne gute Erklärung thnx

[Houdini]

So, geschafft
Kernel 2.6.10 bootet, Neutrino läuft, die ganze Sache ist aber noch etwas absturzwillig
(Nullpointer access in input_event beim Laden von event.ko, bzw Hänger beim Zappen).

Zur Info falls jemand auf die selben Probleme stösst:
Für die Firmware musste ich das /sys Verzeichnis erstellen und mounten und das hotplug binary?! mit dem hotplug skript ersetzen.
Die Filenamen der Firmware werden in den Modulen selber zur Verfügung gestellt, man brauch also /proc/sys/kernel/hotplug nicht einstellen.
Dann hab ich ne Weile gebraucht um herauszufinden dass ein Modul gefehlt
hat (dbox2_napi) und deshalb die /dev/dvb devices nicht erzeugt wurden.

Vielen Dank
Houdini

[gmo18t]

@houdini:
wie sieht es bei Dir mit der CPU-Last beim Netzwerk I/O aus, z.B. TS file abspielen ?

Hast Du neutrino und Co. auch mit den 2.6.10er includes (link: linux -> linux-2.6.10) und Treiber-Include von den 2.6er Treibern (driver/dvb/include/linux/dvb) neu gebacken - oder hast Du ein vorhandenes neutrino (vom 2.4er build) genommen ?

Die cdk (gcc, glibc usw.) bekomm ich aber nur auf Basis des 2.4er Kernels gebaut, deshalb switch ich erst nach "make .deps/bootstrap" auf den 2.6er um !

Einige Sachen von neutrino (libcramfs, flashtool, misc-tools, outdoor-plugin u.ä.) lassen sich ja nicht so ohne weiteres mit einer 2.6er include Konfiguration compilieren ?!

Da ja jetzt DVB API 3.1 benutzt wird, hat sich auch eine Kleinigkeit des Interfaces (apps <-> DBox-Treiber) geändert...

Was für'ne Box mit welchem Frontend hast Du ?

- GMo -

[Houdini]

Uii viele Fragen.

- Also ich habe ein junkfräulichen cdk snapshot vom 31.1.2005 genommen,
den 2.6 driver Tag ausgecheckt und als driver_2_6 Verzeichnis benannt.
- Makefile.am oder rules.mak o.ä. (weiss nicht mehr) auf linux.2.6.10 umgestellt.
- Die letzten 2.6.10 diffs/configs benutzt
- configure mit --with-driverdir=driver_2_6 aufgerufen
- make gestartet und targets, die ich nicht brauche 'weggetouched'
- Bei libcramfs hab ich ein define aus linux/include/asm/?? ins libcramfs.c file kopiert (i.e. #define pgoff_t unsigned long)
(keine Ahnug warum das define aus dem include file nicht gefunden wurde, genaueres heute abend)
- Bei den mtd Kram hab ich ein link auf das verzeichnis gesetzt, wo sich
mtf-user.h befinded.
d.h. das Verzeichnis mtd kann jetzt über dbox/cdkroot/include/mtd erreicht werden bzw. wird dorthin 'exportiert'.
- rc.S angepasst, /sys angelegt und sys in die fstab aufgenommen
- hotplug skript ins /sbin gelegt

Compiler/glibc lassen sich problemlos kompilieren.
CPU Last hab ich noch nicht getestet, da mein top nicht funktionierte und das busybox top nix ordentliches anzeigte.
Den Fehler im dma_alloc_init (oder so) ganz am Anfang hab ich auch.

Wie gesagt das war aus der Erinnerung aufgezählt, heute Abend mehr.
Sagem 2*I Avia600 mit ves1x93 (glaub ich) zum spielen.
Nokia 2*I Avia500 mit ??? zum gucken.

Neutrino TV und Radio hat soweit grundsätzlich funktioniert, da kann die
API Änderung auf 3.1 nicht soviel ausmachen.

Houdini

Hey, carjay hat den input event oops gefixed suuper

[Houdini]

Was mir noch einfällt,
linux/include/asm war nicht gelinkt, da hab ich aus dem cdk makefile noch ein weiteres target aus dem kernel makefile angezogen
.. und zwar unter .deps/linuxdir
$(MAKE) -C linux-2.6.10 include/asm \
ARCH=ppc

[Houdini]

zum 3.
@gmo18t

wie sieht es bei Dir mit der CPU-Last beim Netzwerk I/O aus, z.B. TS file abspielen ?

Also ich habe mal NetzwerK IO mit ftp gemacht, und zwar die libc.a per ftp auf den PC geholt (sozusagen PC - NFS - DBOX - ftp - PC, hehe)
Ich glaube es waren so 110 MB.
Top (mit TERM=vt100 gehts auch) zeigte im Schnitt eine Systemlast von <30% an und in.ftpd hatte weitere ~17%
Sieht für mich nicht so dramatisch aus.

Vielleicht hilfts Dir
Harald

[gmo18t]

Also ich habe mal NetzwerK IO mit ftp gemacht, und zwar die libc.a per ftp auf den PC geholt (sozusagen PC - NFS - DBOX - ftp - PC, hehe)
Ich glaube es waren so 110 MB.

bei mir ist die libc.a (im cdkroot) aber nur ca. 2.5 MB gross. wie kommst Du auf 110MB ?

Welches top hast du benutzt - das von busybox oder das von procps-010114.tar.gz oder noch was anderes ?

- GMo -

[Houdini]

Das busybox top zeigt mir keine % an (bzw alles 0)
Also es war das aus dem procps paket aus dem cdk

[gmo18t]

Das busybox top zeigt mir keine % an (bzw alles 0)
Also es war das aus dem procps paket aus dem cdk

ok, aber ich hatte noch was gefragt - wie kommst Du auf 110 MB ???

- GMo -

[Houdini]

Ich meine mich zu erinnern dass die sie wirklich 110 MB hat, da sind wahrscheinlich noch debug infos drin.
Ich kann heute abend noch mal genau schauen,die libm.a hatte glaub ich auch 10MB.

So, hab nochmal geschaut, es sind wirklich 110MB mit viiiiel Debug infos
Houdini