Linux auf dem x300t geht mit Bild und Ton !

Started by Hoernchen, 19. May 2009, 15:48

previous topic - next topic
Go Down

Hoernchen

Nur damits auch wirklich jeder mitbekommt ;)
Ausser für Bastler die sich auch in tonnenweise C-Code zurechtfinden ist das aber noch nicht weiter interessant, mangels irgend einer grafischen Oberfläche oder sonstigem Schnickschnack.
bringer of linux, conqueror of hdmi, jack of all trades.

pcgeil

hi,

also gibt es genauere Informationen wie Bild und Ton erreicht wurde?

Auf jeden Fall,

coole Sache :-)

Hoernchen

#2
19. May 2009, 17:30 Last Edit: 19. May 2009, 17:34 by Hoernchen
Durch Verwenden einer relativ alten "prod"-version der mrua package, an unseren WinCE-Boxen ist nicht wirklich was anders, ausser das aus irgend einem grund der Chip keinen "facsprod"-irqhandler (= linux) frisst, sondern nur die "prod"-version. Hatte mir das noch mal genauer angeschaut nachdem ich neue Infos zum Chip erbeuten konnte.
bringer of linux, conqueror of hdmi, jack of all trades.

smplasma

Klasse Leistung. RESPEKT.
Ich hätte nicht gedacht, das es mit Linux klappt.
Daumen hoch für alle die daran Beteiligt waren.

bdn

Hi,
Wundert mich warum so ein Durchbuch so leise vor sich murmelt. Ich hoffe es ist nur oberflächlich. 
@Hoernschen: Mein Respekt und Respekt  :)
Fragen:
wie sieht es aus mit DVB-T unter Linux? Schlecht?
"somewhere"?

Hoernchen

#5
26. May 2009, 23:53 Last Edit: 26. May 2009, 23:54 by Hoernchen
Siehe http://www.t-hack.com/wiki/index.php/X300t_tuner
Prinzipiell ist das ganze relativ einfach, die Tuner sind direkt an die Demuxengine des SMPs angeschlossen, das heisst um sie zu benutzen muss man lediglich die Tuner via i2c kofigurieren und dann der Demuxengine (via simplem Kommandozeilenparameter) sagen das sie ihre Daten vom Tuner holen soll, und schwupps is das DVB-T-Bild da.
Soweit zur Theorie. In der Praxis war das wohl der komplexeste Demodulatorchip den es damals grad so gab, samt eigener Firmware und hundert Einstellungsmöglichkeiten, wenn man mal die nötige Konfiguration des Tuner<->smp8634-Interfaces die WinCE benutzt mitsnifft sollte das aber machbar sein - wenn denn jemand Lust hat.
bringer of linux, conqueror of hdmi, jack of all trades.

bdn

Hi,

ich denke es gehört zu Thema: bei Versuch Toolchain zu "make'en":

Code: [Select]
make[2]: Entering directory `/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2-initial/gcc'
gcc  -DUSE_UCLIBC -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long    -DHAVE_CONFIG_H    -I. -I. -I/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2/gcc -I/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2/gcc/. -I/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2/gcc/../include   \
-DTARGET_MACHINE=\"mipsel-linux-uclibc\" \
-c /*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2/gcc/collect2.c -o collect2.o
In function 'open',
    inlined from 'collect_execute' at /*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2/gcc/collect2.c:1535:
/usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
make[2]: *** [collect2.o] Error 1
make[2]: Leaving directory `/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2-initial/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2-initial'
make: *** [/*/*/*/smp86xx_toolchain_2.8.0.1/toolchain_build_mipsel_nofpu/gcc-3.4.2-initial/.compiled] Error 2


Weiß jemand was könnte das Verursachen?

Ich benutze Ubuntu 9.04 mit gcc 4.

Hoernchen

Wie das schon direkt am Anfang herumheult mag es nicht von gcc4 kompiliert werden, also entweder jedesmal wenn dieser Fehler auftritt nach schema F wie z.b. hier http://wiki.elphel.com/index.php?title=ElphelSoftwareKit#Install_needed_packages erwähnt den open-aufruf ergänzen oder gcc 3.4 installieren und dann via export CC=gcc-3.4 && make kompilieren.
bringer of linux, conqueror of hdmi, jack of all trades.

bdn

Hi,

clean(!) "export CC=gcc-3.4 && make" funktionierte  :).
Jetzt habe ich zlib-dev Problem bei rootfs-2.7.127.0  ::).Obwohl es eigentlich nicht sein sollte...

Hoernchen

Das rootfs is eh nur relevant wenn man kein nfsroot oder ubstickroot benutzen will, der nfsroot-tarball von http://www.t-hack.com/wiki/index.php/Setup_NFS-Root-Filesystem eignet sich im Zweifelsfall auch als rootfs.
bringer of linux, conqueror of hdmi, jack of all trades.

bdn

Hmm,

ok :)
ich gehe ganz einfach WIKI durch, ohne es (noch ???) so richtig zu verstehen.
dann eben muss ich ein bisschen weiter studieren... bis demnächst...

andi

hi,

ich würde gerne nochmal die dvb geschichte aufgreifen: da ich sowieso kein dvb-t habe bin ich eher an dvb-s interessiert. hier wäre es womöglich prima, auf das "normale" linux framework zu setzen und dann evtl. dvb-s(2) usb boxen zu nehmen.
der aktuelle kernel 2.6.15 ist da aber zu alt um die neue api zu unterstützen. ich habe gelesen, dass manche smp-basierten boxen schon 2.6.22 oder ähnlich einsetzen. wie groß ist denn die chance die sourcen für 2.6.22 zu bekommen?
das wäre bestimmt ne super sache, eine idee, wie man mono dazu überreden könnte den stream zu zeigen habe ich auch schon :-)

cheers
andi

Hoernchen

2.6.22 wurde von Sigma selber wieder zurückgezogen... je neuer der Kram desto beschissener, wies scheint.
bringer of linux, conqueror of hdmi, jack of all trades.

pcgeil

Die Prüfungszeit geht nun so langsam wieder bei mir dem Ende zu und ehrlich gesagt, juckt mich die X300T wieder total.

Nun, prinzpiell müsste man doch ein Image von der Popcorn Box nehmen können, den Kernel austauschen und eben die passenden Codes laden.
Hat das jemand schonmal probiert und bin ich total auf dem Holzweg?
(Natürlich JTAG Enabled und Bootloader Patch vorausgesetzt!)

Ich finde hierzu verdammt wenig Informationen und weiß nicht, ob das nun gut oder schlecht ist.

Hoernchen

#14
07. Jul 2009, 19:27 Last Edit: 07. Jul 2009, 19:36 by Hoernchen
Die ucodes/irqhandler sind fest mit einer einzigen mrua-Version verbunden, d.h. die pch-fw würde nur funktionieren wenn man das mrua-kernelmodul gegen unseres tauscht, und dann muss man halt schauen was man an der Software alles zurechtbiegen muss um die Unterschiede zwischen dem pch-mrua version 2.7.176.0 und unserem mura version 2.7.127.0 auszugleichen. Die PCH-mruaversion ist ja auch uralt, da dürften die Interface-Unterschiede zu unserem mrua hoffentlich nicht soo gross sein.
Prinzipiell könnte man also einfach mal unser mrua bauen und die pch-firmware damit füttern und dann schauen was alles schiefgeht bzw. was alles für Fehler ausgegeben werden, aber vorsicht, die Firmware schreibt etwas wahllos im Flash herum wenn ich mich richtig erinnere.
bringer of linux, conqueror of hdmi, jack of all trades.

Go Up