TT S2-6400 - saa716x kompilieren unter 18.04

Hallo

Habe heraus gefunden das es von der .config kommt.

# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.15.18 Kernel Configuration
#

Wo kommt das her?

Beim erstellen hat er die originale .config geholt. Dort steht es richtig drin.

make localyesconfig
using config: '/boot/config-4.15.0-48-generic'

Werde alles noch mal von vorn machen und dann sehen ob sich nach dem

make localyesconfig

wieder die 4.15.18 drin stehen und dann eben von Hand zurück ändern.

Gruß Uwe

Zitat von Luwex

und dann eben von Hand zurück ändern.

Das wird nicht helfen. Es hilft nur, nicht nur die richtige config, sondern auch die richtigen Sourcen zu verwenden...

Hallo S:oren

Unsere Antworten haben sich überschnitten.

Ich arbeite in dem Ordner für Kernel-Sourcen

linux-source-4.15.0

Aus dem entpackt

linux-source-4.15.0.tar.bz2

Installiert mit

sudo apt install linux-source-4.15.0

Oder sehe ich da was falsch?

Danke

Gruß Uwe

Es ist fuer mich schwer nachzuvollziehen, welche Sourcen Du genau wie installiert hast.

Fakt ist, die Module sagen (auch die neu generierte config), es waere ein Kernel 4.15.18. Das wird dann auch so sein.

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Ich weiss auch nicht, wie man bei Ubuntu die Kernel-Sourcen richtig installiert, da muss es aber doch Anleitungen geben!? Falls sonst niemand eine Idee hat, kann ich das heute Abend (?) mal ausprobieren...

Gruss,

S:oren

Hallo

Danke für deine Geduld S:oren.

Die .config wird nach dem

make localyesconfig

umgeschrieben.

Ein händisches ändern der Zeile in der .config bewirkt zumindest, das die erzeugten saa716x... .ko wesentlich kleiner sind.

Das hatte mich das erste mal schon gewundert, das die so groß sind.

Vorher saa716x_core.ko 5,3 MiB

Jetzt 102,6 KiB

Ergebnis aber immer noch das Gleiche

Ich Schaue mal, ob ich noch was finde.

Danke

Gruß Uwe

Hallo S:oren

Warte mal noch mit deinem Test.

Nur um es auszuschließen werde ich das Kbuntu noch mal installieren.

Die jetzige Installation ist eine Lubunt und dann das Kubunt Paket drüber .

Grund war, Lubuntu bietet noch eine Alternate, wo man auf Raid-Partitionen installieren kann.

Das Kubuntu kann das nicht.

Werde Kubuntu mal auf eine normale Partition installieren und dann alles noch mal testen.

Danke für deine Mühe

Gruß Uwe

Hallo

An der Mischung Lubunt / Kubuntu lag es nicht.

.config vor make localyesconfig

# Linux/x86 4.18.0-18-generic Kernel Configuration

.config nach make localyesconfig

# Linux/x86 4.18.20 Kernel Configuration

Dann brauche ich den Rest wohl nicht mehr probieren. .

Gruß Uwe

Du musst Dir mal überlegen, wo Du die Kernel-Sourcen her bekommst.

Das was Du dort hast, sind die falschen. Du musst für den installierten Kernel 4.18.0-18-generic die genau dazu passenden Sourcen besorgen. Wie Du das bei Ubuntu machst, kann ich Dir nicht sagen. Wenn Du nicht die dazu passenden hast, funktioniert das in keinem Falle.

kamel5

Grunsätzlich würde ich es mal hiermit versuchen:

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

1. Schritt: die entsprechenden auskommentierten deb-src Zeilen in /etc/apt/sources.list aktivieren

(bei meinem Bionic wären das deb-src http://de.archive.ubuntu.com/ubuntu/ bionic main restricted und

deb-src http://de.archive.ubuntu.com/ubuntu/ bionic-updates main restricted)

2. Schritt: die passenden Sourcen zum aktiven Kernel holen (z.B. per sudo apt-get source linux-image-$(uname -r))

3. Schritt: Build-Umgebung aufbauen: sudo apt-get build-dep linux-image-$(uname -r)

Und dann entsprechend weiter.

Cheers,

Ole

Zitat von S:oren

Haettest Du wie oben beschrieben 4.15.0 installiert, dann wuerde ich eine Modulsignatur 4.15.0 (oder allenfalls 4.15.0-generic) erwarten, auch noch nicht 4.15.0-48-generic wie benoetigt.

Anscheinend ist bei Ubuntu alles anders, ich "liebe" diese Distribution. Jedenfalls sehe ich auch, dass eine installierte Ubuntu-linux-source in Version 4.15.0-48.51 sich selbst als 4.15.18 bezeichnet. Gruselig.

Folgendes Vorgehen

sudo apt install linux-source-4.15.0
mkdir ~/linux-saa716x
cd ~/linux-saa716x
wget https://github.com/s-moch/linux-saa716x/compare/v4.15...saa716x-4.15.diff
tar xjf /usr/src/linux-source-4.15.0.tar.bz2
cd linux-source-4.15.0/
cp /boot/config-4.15.0-48-generic .config
patch -p1 < ../v4.15...saa716x-4.15.diff
make KERNELVERSION=4.15.0-48-generic localyesconfig
# alles mit N bestaetigen, ausser SAA716X_SUPPORT y, SAA716X_CORE m, DVB_SAA716X_FF m
make KERNELVERSION=4.15.0-48-generic -j6 modules
sudo cp drivers/media/common/saa716x/saa716x_core.ko /lib/modules/4.15.0-48-generic/kernel/drivers/media/pci/
sudo cp drivers/media/common/saa716x/saa716x_ff.ko /lib/modules/4.15.0-48-generic/kernel/drivers/media/pci/
sudo depmod 4.15.0-48-generic

ergibt zumindest mal saa716x-Module, die sich unter einem Kernel 4.15.0-48-generic laden lassen.

Leider (oder zum Glück?) habe ich keinen Ubuntu-Rechner mit S2-6400. Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste...

Gruss,

S:oren

Hallo

Zitat von S:oren

Ob die Module funktionieren, kann ich also nicht testen. Ich hoffe das Beste

Es funktioniert

dmesg | grep -i DVB
[   10.502113] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)
[   11.274008] dvbdev: DVB: registering new adapter (nGene)
[   11.274012] ngene 0000:03:00.0: DVB: registering adapter 0 frontend 0 (STV090x Multistandard)...
[   11.324766] dvbdev: DVB: registering new adapter (nGene)
[   11.324771] ngene 0000:03:00.0: DVB: registering adapter 1 frontend 0 (STV090x Multistandard)...
[   13.165088] dvbdev: DVB: registering new adapter (SAA716x dvb adapter)
[   13.396000] SAA716x FF 0000:02:00.0: DVB: registering adapter 2 frontend 0 (STV090x Multistandard)...
[   13.396496] dvbdev: DVB: registering new adapter (SAA716x dvb adapter)
[   13.451360] SAA716x FF 0000:02:00.0: DVB: registering adapter 3 frontend 0 (STV090x Multistandard)...
[   14.030174] input: TT6400 DVB IR receiver as /devices/pci0000:00/0000:00:03.3/0000:02:00.0/input/input14

Die 4 Adapter werden gemacht.

Danke für die Geduld, auch für die Anleitung alles so Schritt für Schritt i.O.

OleS auch Danke, ich werde deine Variante auf der anderen Installation testen.

Das WE ist gerettet.

Gruß Uwe

Hallo OleS

Ich habe den Versuch mit deiner Anleitung gemacht.

Ich sehe da aber keine Kernel-Soucen am Ende.

Es wird eine Ordner 'ubuntu-kernel-signed' gemacht, der 65KiB groß ist.

Und eine linux-signed-hwe_4.18.0-18.19~18.04.1tar.xz

entpackt auch nicht anders.

Was heist bei dir

Zitat von OleS

Und dann entsprechend weiter.

Das was da auf der Seite steht, oder weiter mit dem Module bauen?

So wie ich es mit meinem sehr begrenzten Englisch lese wird dann der Kernel gemacht?

Folgendes ist mir bei der Abarbeitung aufgefallen.

sudo apt-get source linux-image-$(uname -r)

Als Quellpaket wird »linux-signed-hwe« statt »linux-image-4.18.0-18-generic« gewählt.
.
.
W: Der Download wird als root und nicht Sandbox-geschützt durchgeführt, da auf die Datei »linux-signed-hwe_4.18.0-18.19~18.04.1.dsc« durch den Benutzer »_apt« nicht zugegriffen werden kann. - pkgAcquire::Run (13: Keine Berechtigung)

Wenn hwe statt 4.18.0-18 genommen wird ist das nicht so gut.

Die Warnung weiß ich nicht ob das was zu sagen hat.

Dann weiter:

sudo apt-get build-dep linux-image-$(uname -r)
Als Quellpaket wird »linux-signed-hwe« statt »linux-image-4.18.0-18-generic« gewählt.

Das gleiche.

Gruß Uwe

Ok, das kommt davon, wenn man ewig keinen eigenen Kernel mehr gebacken hat...

Anscheinend wurde bei Ubuntu einiges im Ablauf dafür umgebaut und diese Dokumentation ist nicht mehr aktuell.

WIe und ob das überhaupt noch so einfach möglich ist, kann ich nicht mit Sicherheit sagen, aber so kommst du an

die aktuellen Sourcen: sudo apt-get source linux

root@htpc:~/tmp# ll
insgesamt 162808
drwxr-xr-x  3 root root      4096 Mai  8 14:22 ./
drwx------ 17 root root      4096 Mai  8 14:22 ../
drwxr-xr-x 29 root root      4096 Mai  8 14:20 linux-4.15.0/
-rw-r--r--  1 root root   9030833 Apr  3 23:03 linux_4.15.0-48.51.diff.gz
-rw-r--r--  1 root root      8333 Apr  3 23:03 linux_4.15.0-48.51.dsc
-rw-r--r--  1 root root 157656459 Feb  8  2018 linux_4.15.0.orig.tar.gz

Damit hast du dann den original tarball linux_4.15.0.orig.tar.gz und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches aus linux_4.15.0-48.51.diff.gz.

Anschließend musst du noch deine zu bauenden Module integrieren und dann konfigurieren und bauen, wie es S:oren bereits weiter oben erwähnt hat.

Zitat von OleS

und unter linux-4.15.0/ liegt dann das ganze entpackt und mit eingespielten Patches

Auf den ersten Blick ist das, was unter linux-4.15.0/ liegt, dann identisch zu dem (und genauso "kaputt"), was ich oben mit dem

Zitat von S:oren

tar xjf /usr/src/linux-source-4.15.0.tar.bz2

ausgepackt hatte. Aber wie immer gibt es mehr als einen Weg zum Ziel.

Die "komischen" Versionsnummern in den Sourcen scheinen dann immerhin konsistent zu sein. Den "Trick" mit dem Ueberschreiben der KERNELVERSION habe ich uebrigens auch aus dem Ubuntu-Build-Skript, scheint da so ueblich zu sein...

Gruss,

S:oren

Ich versuche seit ca. 4 Stunden, die Treibermodule für die S2-6400 zu compilieren.

Nachdem ich einige Schritte angepasst habe, hänge ich jetzt am Punkt:

vdr-pc2@vdr-pc2:/usr/src/linux-5.4$ sudo make KERNELVERSION=5.4 localyesconfig          
using config: '.config'
snd_intel_dspcfg config not found!!
#
# configuration written to .config
#

Wenn ich diesen Befehl aufrufe, kann ich die notwendigen Module garnicht auswählen. Der Patch lief anscheinend durch.

Ich habe folgende Verzeichnisse, wobei in linux-5.4 die Kernelsourcen liegen:

vdr-pc2@vdr-pc2:/usr/src$ ls -al
insgesamt 28
drwxr-xr-x  7 root    root    4096 Mär 14 17:31 .
drwxr-xr-x 14 root    root    4096 Feb  1 17:25 ..
drwxrwxr-x 24 root    root    4096 Mär 14 20:09 linux-5.4
drwxr-xr-x 28 root    root    4096 Mär 14 17:28 linux-5.4.0
drwxr-xr-x 24 root    root    4096 Mär 14 17:24 linux-headers-5.4.0-66
drwxr-xr-x  7 root    root    4096 Mär 14 17:14 linux-headers-5.4.0-66-generic
drwxrwxr-x  2 vdr-pc2 vdr-pc2 4096 Mär 13 15:28 linux-saa716x
vdr-pc2@vdr-pc2:/usr/src$

Als Distribution verwende ich

Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-66-generic x86_64)

Wo mache ich einen (Denk-)Fehler ?

Vielleicht passt die Anleitung von 18.04 nicht mehr zu 20.04?

Ansonsten: beim 'make localyesconfig' kann man nichts auswaehlen, nur bei einem anschließenden 'make menuconfig'.

Gruss,

S:oren

ich habe bei menuconfig nun alles was mit dem SAAx zu tun hat aktiviert und die .config dann gespeichert. ausgerechnet diese Module werden nicht erstellt....

Hm, was sagt ein "grep SAA716X .config" ? Bei mir das hier:

CONFIG_SAA716X_SUPPORT=y
CONFIG_SAA716X_CORE=m
CONFIG_DVB_SAA716X_BUDGET=m
CONFIG_DVB_SAA716X_HYBRID=m
CONFIG_DVB_SAA716X_FF=m

Gruss,

S:oren

Positiv - bei mir das gleiche.

in

/usr/src/linux-source-5.4.0

gibt es auch im Unterverzeichnis /drivers/media/common/saa716x/ die ganzen Quelldateien und ein passendes Makefile.

Aber die Module werden nicht gebaut (wenn ich nach der Anleitung von 18.04 vorgehe):

vdr-pc2@vdr-pc2:/usr/src$ sudo make KERNELVERSION=5.4.0-66-generic -j6 modules