[WILL_NOT_FIX] Exotisches Kernelmodul (Kamera, Intel ISP) kompilieren

[chmeyer]

Hallo zusammen,

in einem Anflug von Übermut habe ich mir ein gebrauchtes Lenovo Thinkpad Tablet 10 (Gen 1) aus dem Jahr 2013 gekauft und bin sehr begeistert wie viel der Hardware out-of-the-box mit Debian Bullseye funktioniert (32bit UEFI, Rotation, Helligkeit, WLAN, BT, GPS, Touchscreen, Sound, ...).

Lediglich mit der eingebauten Kamera habe ich noch Probleme.
Laut Windows und Nicole Färber handelt es sich um einen "Intel Imaging Signal Processor 2400", für den es offenbar kein fertiges Kernelmodul gibt.
Damit wäre das Thema eigentlich zu Ende.

Eigentlich. Wenn da nicht auf Nicoles Seite der Quellcode für diesen ISP von Intel verlinkt wäre.
Dummerweise habe ich (in den 15 Jahren seit ich Debian benutze) noch nie einen Kernel oder ein Kernelmodul kompiliert.
Gut. Dafür gibt es HowTo's und Schritt-für-Schritt-Anleitungen, und vielleicht würde ich das im Idealfall auch "irgendwie" hinbekommen.

Jetzt kommt das eigentliche Problem:
Die Kernel-Patches (aus dem Jahr 2014 und 2015) sind für die Betriebssysteme Tizen bzw. Fedora 18, auf jeden Fall aber für Kernel 3.10 LTSI. Naja und das passt ja nicht wirklich zum Bullseye-Kernel, und auch nicht zu meinem Defizit an Kernel-Wissen.

Kann mir hier bitte jemand behilflich sein:
- Warum gibt es keinen offiziellen Treiber resp. Kernelmodul?
- Gibt es vielleicht irgendwo fertige Treiber?
- Kann man (=ich?) diese Module aus den vorhandenen Quelle bauen?
- Gibt es evtl. ein HowTo oder Hintergrundinformationen?

[CH777]

- Gibt es vielleicht irgendwo fertige Treiber?
- Kann man (=ich?) diese Module aus den vorhandenen Quelle bauen?
- Gibt es evtl. ein HowTo oder Hintergrundinformationen?

Soweit ich weiß, leider alles nein.
Es gibt Hinweise, dass es mal unter Fedora funktioniert haben könnte, konnte aber auf die Schnelle nichts weiter dazu finden...
Intel hat ja jetzt eine eigene Linux-Distribution, Clear Linux. Vielleicht geht es ja damit?

[chmeyer]

Hallo CH777,

Danke für Deinen Tipp mit Clear-Linux.
Das hat sich zuerst ziemlich gut angehört, ist aber dann daran gescheitert, dass mein Gerät ein 32-bit UEFI mit 32-bit Atomprozessor hat.
Clear-Linux gibt es aber nur als 64-bit Version, sprich es bootet noch nicht einmal. Klar habe ich es auch ausprobiert, war aber nichts zu wollen.
Schade. War aber eine gute Idee.

Mit dem aktuellen Fedora habe ich es auch probiert, das konnte auch immerhin einige Geräte zum Laufen bringen, die bei Debian Buster still geblieben waren.
Nach einem Update auf Testing (Bullseye) steht dem Debian aber in nichts nach.
Die Webcam blieb aber leider auch beim aktuellen Fedora funktionslos.

Immerhin habe ich jetzt einen alten Schriftwechsel im Kernel-Bugzilla gefunden:

The atomisp driver was removed from the Kernel. It was on a really very bad shape, and we don't even have reports that it actually works with the latest upstream version of it.

Ah, ja: Es gibt auch ein (wohl totes) Git-Repo für eine Atom-ISP-TestApp. Das basiert aber auch nur auf der Tizen-Version für Kernel 3.10 LTSI.

Sehr bedauerlich. Aber immerhin erklärt es die Situation.
Jetzt könnte man natürlich anfangen Geld für die nötigen Aufräumarbeiten zu sammeln, aber ich glaube, das wird nicht reichen. ...

Jetzt bliebe noch die Frage, ob jemand eine Idee (bzw. Erfahrung) hat, die Kamera ähnlich wie mit "NdisWrapper" oder mit Treibern in einer Windows-VM, z.B. auch unter wine zum Leben zu erwecken. ...

Vielen Dank für die Hilfe.

[MSfree]

Das hat sich zuerst ziemlich gut angehört, ist aber dann daran gescheitert, dass mein Gerät ein 32-bit UEFI mit 32-bit Atomprozessor hat.

32Bit UEFI und 32Bit Atom-CPU schlessen sich praktisch aus. Die einzigen 32Bit Atome ware die Diamondvilles und Silverthornes von 2008. UEFI kam erst einiges später. Die damaligen Netbooks hatten jedenfalls alle noch ein traditionelles BIOS.

2013 habe die keine 32Bit Atome mehr verbaut, das ist also mit 99.9% eine 64Bit CPU.

[chmeyer]

Tatsache, Du hast Recht:
es ist ein Z3795 Quadcore, aber nur mit 1,8 GiB RAM und da ist ein "lm" in

Code: Alles auswählen

cat /proc/cpuinfo

Scheinbar habe ich das mit dem UEFI noch nicht so ganz kapiert. Heisst das, dass ich mit 32bit UEFI doch auch den 64-bit Kernel von Clear-Linux starten kann?
Mit dem Bootloader der ISO geht es nämlich nicht, der ist nur für 64bit.

[MSfree]

Scheinbar habe ich das mit dem UEFI noch nicht so ganz kapiert. Heisst das, dass ich mit 32bit UEFI doch auch den 64-bit Kernel von Clear-Linux starten kann?

Normalerweise scheitert ein Linuxboot an Secure Boot, das sollte man aber im UEFI normalerweise abschalten können.

Ein 64Bit Linux wird aber dein Kemaraproblem nicht lösen. Wenn die Kamera nicht vom uvcvideo-Modul (das kennt praktisch alle gängigen Webcams) unterstützt wird, sehe ich wenig Chancen.

Aber mit 1.8GB RAM lohnt sich eine 64Bit Version ohnehin nicht wirklich.

[Tintom]

Immerhin habe ich jetzt einen alten Schriftwechsel im Kernel-Bugzilla gefunden:

The atomisp driver was removed from the Kernel. It was on a really very bad shape, and we don't even have reports that it actually works with the latest upstream version of it.

Das Kernelmodul hängt (noch) im Staging-Bereich des Kernels: https://git.kernel.org/pub/scm/linux/ke ... af819bfdb6

Auf meinem System (Stretch) wird das Modul allerdings nicht mitgeliefert. Qualität zu schlecht? Die ToDo-Liste liest sich jedenfalls so.

[chmeyer]

Normalerweise scheitert ein Linuxboot an Secure Boot, das sollte man aber im UEFI normalerweise abschalten können.

Ein 64Bit Linux wird aber dein Kemaraproblem nicht lösen. Wenn die Kamera nicht vom uvcvideo-Modul (das kennt praktisch alle gängigen Webcams) unterstützt wird, sehe ich wenig Chancen.

Das Booten von Debian 10 und Fedora per LiveCD klappt beides. Auch meine Installation (Bullseye - testing) startet prima von der internen "Festplatte". Allerdings nur in der 386er-Version.
Natürlich hast Du auch Recht mit dem Sinn von 64bit auf diesem Tablett im Allgemeinen. Es ging ja aber darum, die spezielle Intel-Distro zu testen um das "nicht-uvcvideo"-Kernelmodul zu testen. Naja und das ClearLinux bootet wegen dem 32bit UEFI eben nicht (zumindest nicht out-of-the-box).

Das Kernelmodul hängt (noch) im Staging-Bereich des Kernels: https://git.kernel.org/pub/scm/linux/ke ... af819bfdb6
Auf meinem System (Stretch) wird das Modul allerdings nicht mitgeliefert. Qualität zu schlecht? Die ToDo-Liste liest sich jedenfalls so.

Wow, das hört sich ja interessant an.
Den ganzen Debian-Kernel durch den Upstream-Kernel zu ersetzen, das scheint mir ein wenig zu ambitioniert, aber vielleicht könnte man ja daraus ein (wahrscheinlich unstabiles) Modul kompilieren, das mit dem Debian-Kernel harmoniert?

Hat vielleicht jemand einen Link für mich, wo erklärt wird wie man nachträglich ein zusätzliches Debian-Kernelmodul aus dem Staging-GIT-Repo bauen kann?

Viele Grüße
Christian

[Tintom]

Hat vielleicht jemand einen Link für mich, wo erklärt wird wie man nachträglich ein zusätzliches Debian-Kernelmodul aus dem Staging-GIT-Repo bauen kann?

Du könntest in dem Fall den Debiankernel mit dkms probieren: https://wiki.debian.org/KernelDKMS
Falls das nicht hilft bleibt nur der vollständige Neubau des Kernels.

[CH777]

vielleicht könnte man ja daraus ein (wahrscheinlich unstabiles) Modul kompilieren, das mit dem Debian-Kernel harmoniert?

Eher nicht. Soweit ich das hier verstehe, ist das Modul 2018 aus dem Kernel geflogen, weil es Schrott war:

The atomisp driver has a long list of todo items and little has been done
to address these lately while more has been added. The driver is also not
functional. In other words, the driver would not be getting out of staging
in the foreseeable future. At the same time it consumes developer
resources in order to maintain the flaky code base. Remove it.

[Tintom]

Stimmt. Mein Link oben zeigt nicht auf master, ich habe wohl einen alten Stand verlinkt. Im aktuellen Kernel ist das Modul nicht mehr enthalten.

[chmeyer]

Danke für die Info. "Irgendwie" stand das ja auch zu erwarten und meine ursprüngliche Einschätzung bewahrheitet sich offenbar:

Damit wäre das Thema eigentlich zu Ende.

Trotzdem. Mal angenommen ich möchte mir die blutige Nase selbst holen und sehe die verlorene Zeit als "Weg der Erkenntnis" :
Mit GIT komme ich an den alten Code aus dem Staging-Bereich des Kernels. So weit, so gut. Und dann?

Zwei Arten von Anleitungen habe ich gefunden:
- Baue den kompletten Kernel (mit Modulen oder monolithisch) selbst. Quellcode kommt wahlweise von kernel.org oder von Debian (deb-src).
Klar "könnte" man die Version des Kernels von Mitte 2019 aus-checken und sich einen historischen kompletten Vanilla-Kernel (naja, mit staging ja eher nicht, aber immerhin ohne Debian) bauen. Davor habe ich aber zu viel Respekt und der Debian-Kernel ist ja sonst tadellos, sprich: ich hole mir nur Ärger dabei.
- Verwende die Quellen aus dem Debian-Repo (deb-src). Dort ist atomisp aber nicht enthalten.

In den gängigen DKMS-HowTo's steht, man möge vor dem Einsatz von DKMS die Module zunächst "von Hand" bauen, und auch hier geht es AFAIK auch nur um die modules, die per deb-src ohnehin schon zur Verfügung stehen.

Aber wie funktioniert das Bauen von Kernel-MODULEN bei Debian ( "von Hand" und ohne die deb-src) aus dem "offiziellen" (historischen und buggy) Kernel-Staging-GIT?
Oder lassen sich die "Build a single Kernel Module" Anleitungen auch hier anwenden? z.B.:
https://debian-administration.org/artic ... nel_module
https://askubuntu.com/questions/168279/ ... nel-module
https://stackoverflow.com/questions/874 ... nel-module
Damit habe ich nämlich das Gefühl allzuviel "durcheinander" zu bringen.

[CH777]

Mit GIT komme ich an den alten Code aus dem Staging-Bereich des Kernels. So weit, so gut. Und dann?

Dann müsstest du ihn erstmal neu programmieren, damit er überhaupt funktioniert...