openSUSE 13.2 auf Odys Winpad V10

Einleitung

Ich hab mir ja wirklich viel Zeit gelassen mit dem Kauf eines Tablets, aber irgendwann kommt der Moment, da denkt man sich, dass es vielleicht ja doch gar nicht so unpraktisch ist, wenn man nicht immer ein Notebook mitschleppen muss. Auf der anderen Seite möchte ich aber nicht auf den Komfort einer echten Tastatur verzichten, also musste ein Gerät her, das eine solche Tastatur mit bringt. Das ist ohnehin praktisch, denn sonst benötigt man ja auch einen extra Aufsteller, wenn man das Ding nicht die ganze Zeit in der Hand halten möchte. Also mal ein wenig die Werbeblattl durchgekämmt und schließlich ein Odys Winpad V10 (2in1) bestellt. Das geht recht günstig her. Im Vorhinein hatte ich schon ein wenig gelesen, wie es denn mit der Linuxtauglichkeit aussieht und wusste daher schon, dass es eher mau ist. Aber inzwischen habe ich das Teil einigermaßen benutzbar hinbekommen.

Im Blog von Hack Correlation könnt ihr euch auch ein wenig die Innereien des Tablets ansehen. Außerdem hat sich Odys inzwischen endlich erbarmt auch ein Treiberpaket in seinem Wiki bereit zu stellen, sodass man theoretisch die Recoverypartition auch platt machen kann. Evtl. lassen sich in zukunft aus den Windowstreibern auch Parameter für Linux ableiten, da hab ich mich aber noch nicht tiefer rein gefuchst.

Was geht, was nicht?

Damit ihr gleich abschätzen könnt, ob sich ein Kauf für eure Bedürfnisse lohnt, habe ich diesmal gleich am Anfang eine Tabelle erstellt, in der aufgelistet ist, welche Hardware bisher funktioniert und wo es Probleme gibt:

i2c_hid_get_input: incomplete report (76/8450)

Wenn man also ein Gerät benötigt, das die Grundbedürfnisse (Internet anzeigen, Konsole mit etwas ssh) befriedigt, dann ist das Teil schon Linux-ready wer mehr möchte, muss wohl erst mal bei Windows bleiben.

Kampf mit UEFI

Obwohl der verbaute Prozessor (Intel Atom Quadcore Z3735F, 1,83GHz) eigentlich ein 64 Bit Prozessor ist, wird das Gerät mit einem 32 Bit Windows ausgeliefert. Warum? Ganz einfach, das UEFI-BIOS ist nur ein 32 Bit System, das macht es schwer ein 64 Bit OS zu betreiben. Da das Tablet allerdings eh nur 2 GB Arbeitsspeicher besitzt, ist ein 64 Bit OS auch gar nicht von Nöten. Aber wie bekommt man jetzt das Gerät dazu von USB zu booten? Wenn man Debian oder auch Ubuntu (jeweils 32 Bit) nutzen möchte, ist das kein großes Problem. Beide haben installationsimages, die man einfach z.B. per 'dd if=debian.iso of=/dev/sdb' auf einen Stick kopieren kann. Warum die Frickler bei openSUSE das für ihre 32 Bit Version nicht hinkriegen, ich weiß es nicht.

Daher fangen wir bei den Basics an. Das EFI-System auf dem Tablet sucht sowohl im internen Speicher als auch auf z.B. einem USB-Stick eine EFI-Partition. In dieser müssen ein paar spezielle Dateien liegen. Unter anderem eine Datei mit der Endung .efi. Diese wird dann ausgeführt und beinhaltet den Bootloader. Hat man das System so weit, dass es den Bootloader ausführt ist quasi alles beim Alten. Zunächst muss der USB-Stick also formatiert werden. Leider können die EFI-Systeme in der Regel nur FAT32 lesen. Daher erstellen wir zunächst eine kleine Partition (ein paar 100 MB) in der der Bootloader landet und eine große Partition in der der Inhalt des DVD-Images landet.

Ich gehe im Folgenden davon aus, dass sich der USB-Stick unter /dev/sdX befindet. Müsst ihr natürlich anpassen. Als erstes wird die Partitionstabelle mal komplett geleert und eine GPT-Tabelle angelegt. Dann die beiden Partitionen angelegt:

sgdisk --zap-all /dev/sdX

sgdisk -n 1:2048:413695 -c 1:"EFI System Partition" -t 1:ef00 /dev/sdX

ENDSECTOR=$(sgdisk -E /dev/sdX)

sgdisk -n 2:413696:$ENDSECTOR -c2:"Linux" -t2:8300 /dev/sdX

sgdisk -p /dev/sdX

Disk /dev/sdX: 14950400 sectors, 7.1 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 15C90F5B-96BF-4715-98F9-A9BE2190A46B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 14950366
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          413695   201.0 MiB   EF00  EFI
   2          413696        14950366   6.9 GiB     8300  Linux

Jetzt besitzt der Stick eine GPT-Partitionstabelle, eine EFI- und eine Linux-Partition. Als nächsten Schritt, erstellen wir die Dateisysteme und mounten auch gleich die EFI-Partition:

mkfs.vfat -F32 -s 2 -n GRUB2EFI /dev/sdX1
mkfs.ext2 /dev/sdX2
mount /dev/sdX1 /mnt

Jetzt wird's spannend. Von einem spanischen Blogger gibt es ein ZIP mit der Verzeichnisstruktur und den efi-Bootdateien: usb-pack_efi.zip. Sollte der Link nicht mehr funktionieren, gebt mir bescheid, ich habe die Datei noch lokal.
Nach dem Download geht in das Verzeichnis, in das ihr die ZIP-Datei geladen habt, entpackt sie und kopiert sie auf den Stick. Für die Installation später benötigt ihr außerdem den efibootmgr, den ich aus den Debian-Paketen geklaut habe. Für openSUSE gibt es dieses Programm schlicht nicht in einer 32 Bit Version. Daher kommt der auch mit auf den Stick und muss später auf das SUSE-System kopiert werden

cd ~/Downloads/
unzip usb-pack_efi.zip
rsync -auv usb-pack_efi/ /mnt
cp efibootmgr /mnt/

Ebenfalls mounten wir jetzt das openSUSE-DVD-Image und kopieren es auf die 2. Partition des Sticks.

mount /dev/sdX2 /mnt/iso

mkdir /tmp/loop
mount -oloop openSUSE-13.2-DVD-i586.iso /tmp/loop
rsync -auv /tmp/loop/ /mnt/iso
umount /tmp/loop
rm -r /tmp/loop

Jetzt ist die größte Arbeit geschafft. Der Bootloader muss allerdings noch eingerichtet werden. Dazu habe ich euch mal meine grub.cfg hochgeladen, mit der ihr dann vom Stick booten könnt. Diese einfach herunter laden und die Datei /mnt/boot/grub/grub.cfg damit ersetzen. Leider ist openSUSE wie gesagt nicht in der Lage einen 32 Bit EFI bootloader zu schreiben, deshalb hilft es alles nichts, ihr müsst ein aktuelles Debian (also Jessie) oder Ubuntu booten. Ob ihr da jetzt schnell ein Image für eine VM herunter ladet oder so noch einen Rechner herum stehen habt... dort jedenfalls den Stick anstecken und folgende Zeilen ausführen:

mount /dev/sdX1 /mnt
grub-install --removable --boot-directory=/mnt/boot --efi-directory=/mnt/EFI/BOOT /dev/sdX

Das ganze sollte ohne Fehler abschließen. Jetzt ist der Stick bereit für den ersten Test. Steckt ihn in das Adapterkabel ein, schaltet das Pad ein und sobald sich die Hintergrundbeleuchtung erhellt, drückt mehrmals die ESC-Taste. Es erscheint ein Auswahlbildschirm mit der Option "Boot Manager", die kann man sogar mit der Maus anwählen. Das nächste Menü ist nicht mehr ganz so bunt, aber neben "Windows" und "Windows Recovery" sollte auch der USB-Stick erscheinen. Auswählen und hoffen, dass der Grub-Bootloader geladen wird. Das wäre geschafft - wie es weiter geht, nach der nächsten ... ach ihr wisst schon.

Installation und weiterer Kampf

Die Installation läuft abgesehen von fehlendem Netzwerk eigentlich ganz normal. Beim Partitionieren aufpassen! Nicht die EFI-Partition löschen! Ich habe mich außerdem dazu entschlossen die 5 GB Recovery-Partition zu erhalten. Evtl. wechsel ich ja doch wider zurück zu Windows. Die ca. 25 GB große Windows-Partition musste dran glauben und Linux Platz machen

Bei der Bootloadereinrichtung ist der Installer fest der Meinung er müsste den Bootloader für Secure Boot einrichten, was ihm aber ohnehin nicht gelingt, denn ich habe es ja schon ein paar mal erwähnt, openSUSE hat keinen support für 32 Bit EFI. Deswegen wird die Installation des Bootloaders ohnehin fehlschlagen und wir müssen uns händisch darüber her machen.

Den Fehler also einfach ignorieren und beim ersten Neustart des Systems wieder vom Stick booten und diesmal das Rescue-System booten. Dort als root anmelden und das System vorbereiten, um in eine chroot-Umgebung zu wechseln. Bei meinem System habe ich eine root-Partition und eine home-Partiton, die sich unter /dev/mmcblk0p5 und /dev/mmcblk0p6 befinden. Die EFI-Partition muss ebenfalls eingebunden werden, sie ist als /dev/mmcblk0p1 vorhanden. Mit fdisk -l /dev/mmcblk0 könnt ihr euch aber auch den Inhalt des Flashspeichers anzeigen lassen.

Nach dem Wechsel in's chroot können wir den Stick mit dem efibootmgr mounten und in das Dateisystem kopieren. Da noch Pakete vom DVD-Image benötigt werden, mounte ich die zweite Partition vom Stick gleich auch noch.

mount /dev/mmcblk0p5 /mnt
mount /dev/mmcblk0p6 /mnt/home
mount /dev/mmcblk0p1 /mnt/boot/efi
for i in proc sys dev; do mount -obind /$i /mnt/$i; done
chroot /mnt
mount /dev/sda1 /mnt
mount /dev/sda2 /mnt/iso
cp /mnt/efibootmgr /sbin/
rpm -Uvh /mnt/suse/i586/grub2-i386-efi-2.02~beta2-20.5.1.i586.rpm
grub-mkconfig -o /boot/grub2/grub.cfg
grub-install.unsupported /dev/mmcblk0

Die Installation des Bootloaders sollte ohne Fehler abschließen. Da ich mich nicht mehr genau erinnere, ob das grub-efi-Paket zusätzliche Abhängigkeiten hatte, müsst ihr die ggf. selber auflösen. Mit find sollten sich die Pakete finden lassen.

Jetzt noch schnell die grub.cfg etwas anpassen, damit das Gerät auch bootet. Folgende Parameter müssen an die linuxefi-Zeile hinzugefügt werden:

nomodeset sdhci.debug_quirks=0x8000

Da ein Suspend to RAM oder Disk nicht funktionieren, rate ich euch die resume=-Option zu entfernen. Und jetzt heißt es sich aus der chroot-Umgebung auszuloggen (exit eintippen), das rescue-System zu verlassen (reboot) und Daumen drücken. Es sollte jetzt automatisch der Grub-Bootloader starten und kurz darauf auch euer Linux-System. Puh.

WLAN-Treiber

Wie bereits geschrieben, es gibt einen Treiber für WLAN und er funktioniert auch. Allerdings nicht mit dem mitgelieferten Kernel, der ist zu alt. Deswegen sucht euch aus den User-Repos einen 4er Kernel und installiert diesen (mit kernel source, devel, macros, usw.). Außerdem empfehle ich den Treiber direkt aus dem Git-Repo auszuchecken (ihr könnt natürlich auch das Zip von github herunter laden). Um den neuen Kernel und den Treiber zu bekommen, habe ich einfach einen USB-WLAN-Stick angeschlossen. Damit am besten auch gleich ein Update fahren, damit Pakete auf den aktuellen Stand kommen. Kompiliert wird dann eigentlich ganz easy (make, gcc, etc. müssen natürlich auch installiert werden):

git clone https://github.com/hadess/rtl8723bs.git
make
sudo make install
sudo depmod -a
sudo modprobe r8723bs

Im ifconfig bzw. auch iwconfig taucht dann bereits ein wlan0-Adapter auf und der Netzwerkmanager sollte sich nach einem Neustart auch darüber mit eurem Funknetzwerk verbinden können.
Wenn es Probleme beim Kompilieren gibt, dann habt ihr wahrscheinlich nicht alle devel-Pakete zum Kernel passend installiert. Am besten ihr schmeißt alles raus, bis auf die Pakete für den aktuellen Kernel. Das Internet sollte aber ebenfalls weiter helfen.

Wichtig ist natürlich auch, dass ihr eure grub.cfg anschließend an die neue Kernelversion anpasst. Das muss händisch geschehen - openSUSE mag einfach nicht mit 32 Bit EFI.

Touchsensor patchen

Zum Schluss widmen wir uns noch dem Touchsensor. Wäre ja auch zu blöd, wenn man den nicht verwenden könnte. Wie in der Tabelle oben bereits beschrieben, gibt es einen Patch, der die Probleme mit dem Touchsensor löst. Ich habe ihn noch ein wenig angepasst, da bei meinem 4.2er Kernel, den ich derzeit installiert habe, die i2c_hid.c noch eine zusätzliche if-Abfrage enthält. Den Patch also erstmal herunter laden: i2c_hid_winpad.patch.

Dann heißt es die Kernelsourcen vorzubereiten, den Patch einzuspielen und schließlich das Modul zu kompilieren und zu installieren. Hier habe ich das ganze mal am Beispiel meines 4.2er Kernels durchexerziert, ihr müsst das entsprechend für eure Version anpassen.

cd /usr/src/linux

# Module symvers kopieren, damit Module zum Kernel passen:
cp ../linux-obj/i386/desktop/Module.symvers .

# Alte konfiguration übernehmen
make oldconfig

# Alles vorbereiten
make prepare
make modules_prepare

# Patch einspielen
patch drivers/hid/i2c-hid/i2c_hid.c /home/user/Downloads/i2c_hid_winpad.patch

# Modul kompilieren und installieren
make modules SUBDIRS=drivers/hid/i2c-hid/
cp drivers/hid/i2c-hid/i2c-hid.ko /lib/modules/4.2.0-4-desktop/kernel/drivers/hid/i2c-hid/
depmod -a

# Modul neu laden
rmmod i2c_hid
modprobe i2c_hid

Damit funktioniert der Touchsensor jetzt einwandfrei.

Soundversuche

ACHTUNG: Soeben habe ich eine E-Mail erhalten, dass der Linuxtreiber die Soundkarte oder sogar das komplette Gerät irreperabel zerstören kann! Mit den falschen Mixereinstellungen kommt dann der magische weiße Rauch aus dem Gerät! Ich empfehle also dringend auf keinen Fall Soundversuche durchzuführen, bis das geklärt ist! Auf der Kernel Mailing List ist auch ein weiterer Beitrag von einem Betroffenen: Bug 86581 - Baytrail-T: there is no sound with ASUS T100TAF.

Mein Beileid an Thomas und gleichzeitig mein Dank für diese Warnung!

Meine Versuche die Soundkarte zum Leben zu erwecken sind leider bisher noch nicht erfolgreich gewesen. Ich glaube zwar, ich bin auf der richtigen Spur, allerdings ist jetzt der Moment gekommen, wo ich wohl einen Bugreport erstellen muss. Nur weiß ich leider gar nicht, an wen sich der richten soll. Die Entwickler von SUSE können mir wahrscheinlich wenig sagen, da ich einen 4.2er Kernel laufen habe, am ehesten evtl. die Entwickler bei ALSA.

Unter SUSE werden die Bay Trail Treiber standardmäßig nicht mitgeliefert. Deswegen müsst ihr die händisch erstellen. Ist aber nicht weiter schwer. Nach dem Kompilieren des i2c_hid-Moduls sind die Kernelsourcen ja schon soweit vorbereitet. Über menuconfig braucht ihr nur noch die Module auswählen, kompilieren und installieren. Ihr findet sie unter 'Device Drivers' -> 'Sound Card Support' -> 'ALSA' -> 'ALSA for SoC audio support' -> 'ASoC suport for Intel SST'. Dort dann den Bay Trail Treiber auswählen. Außerdem rate ich euch im Menü davor sämtliche USB, PCI, PCMCIA-Treiber abzuwählen, denn die wollt ihr ja nicht auch noch kompilieren.

Nach der Auswahl speichern und die Menuconfig verlassen. Als nächstes können die Module kompiliert und installiert werden. Die Installation habe ich in mein /home-Dir vorgenommen, da ich anschließend nur die SoC-Treiber nach /lib/modules kopieren will. Wie gesagt vom installierten Kernel ist ja alles schon vorhanden.

cd /usr/src/linux
cp Module.symvers sound/

make menuconfig # hier die Treiber auswählen und speichern

make modules_prepare

make modules SUBDIRS=sound

mkdir /home/user/modules

make modules_install INSTALL_MOD_PATH=/home/user/modules/ SUBDIRS=sound/

cd /home/user/modules/lib/modules/4.2.0-4-desktop/extra/
mkdir -p /lib/modules/4.2.0-4-desktop/extra/core
cp -Rp soc/ /lib/modules/4.2.0-4-desktop/extra/
cp -p core/snd-compress.ko /lib/modules/4.2.0-4-desktop/extra/core/

depmod -a

mkdir /lib/firmware/intel

Zum Schluss müsst ihr euch noch die Firmware für die Soundkarte besorgen. Im Kerneltree gibt es eine passende Firmware, bzw. so ganz passt sie eben nicht, denn damit wird immer noch keine Soundkarte erkannt. Auf dubiosen Pfaden bin ich zu einer Firmware gelangt, die auch ordentlich lädt, allerdings wird aus irgend einem Grund der IRQ der Soundkarte nicht bedient und das Modul segfaultet. Die Links zu den Firmware-Images:

• fw_sst_0f28.bin-48kHz_i2s_master von kernel.org
• BYT_LSP_3.10_LTSI_LPE_Firmware.tar.bz2 von Intel

Die Datei fw_sst_0f28.bin-48kHz_i2s_master muss in den zuvor erstellen /lib/firmware/intel-Ordner.

Hier mal ein Auszug aus meiner dmesg:

[   11.579525] iTCO_vendor_support: vendor-support=0
[   11.579951] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   11.580047] iTCO_wdt: Found a Bay Trail SoC TCO device (Version=3, TCOBASE=0x0460)
[   11.580357] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   11.602475] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered
[   11.678845] baytrail-pcm-audio baytrail-pcm-audio: FW version: 04.05.12.02
[   11.678851] baytrail-pcm-audio baytrail-pcm-audio: Build type: 2
[   11.678854] baytrail-pcm-audio baytrail-pcm-audio: Build date: Jan 16 2014 18:17:00
[   11.739354] byt-rt5640 byt-rt5640: rt5640-aif1 <-> baytrail-pcm-audio mapping ok
[   12.812653] irq 6: nobody cared (try booting with the "irqpoll" option)
[   12.812659] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.2.0-4-desktop #1
[   12.812661] Hardware name: AXDIA International GmbH WINPAD V10/Type2 - Board Product Name, BIOS AD1012.1.03.017 11/21/2014
[   12.812669]  00000000 00000000 f582df50 c080ecdd f5b3d500 f582df70 c02abab9 c09c9bfc
[   12.812676]  00000006 00000000 f582df6c f5b3d500 00000006 f582df94 c02abf49 f582df94
[   12.812682]  c05f400c fffb9282 00000000 f5b3d500 f5b3d570 00000000 f582dfd0 c02a9a53
[   12.812684] Call Trace:
[   12.812694]  [] dump_stack+0x48/0x69
[   12.812700]  [] __report_bad_irq+0x29/0xd0
[   12.812704]  [] note_interrupt+0x1c9/0x210
[   12.812710]  [] ? add_interrupt_randomness+0x15c/0x190
[   12.812714]  [] handle_irq_event_percpu+0xa3/0x1c0
[   12.812717]  [] handle_irq_event+0x33/0x50
[   12.812721]  [] handle_fasteoi_irq+0x75/0x130
[   12.812724]  [] ? handle_simple_irq+0x70/0x70
[   12.812728]  [] handle_irq+0x71/0x90
[   12.812735]    [] do_IRQ+0x3c/0xd0
[   12.812739]  [] common_interrupt+0x33/0x38
[   12.812744]  [] ? cpuidle_enter_state+0xaf/0x2e0
[   12.812748]  [] cpuidle_enter+0x14/0x20
[   12.812752]  [] call_cpuidle+0x33/0x70
[   12.812756]  [] cpu_startup_entry+0x25e/0x320
[   12.812760]  [] rest_init+0x7b/0x80
[   12.812765]  [] start_kernel+0x456/0x45d
[   12.812769]  [] ? set_init_arg+0x52/0x52
[   12.812773]  [] i386_start_kernel+0x13a/0x13d
[   12.812774] handlers:
[   12.812787] [] sst_byt_irq [snd_soc_sst_baytrail_pcm] threaded [] sst_byt_irq_thread [snd_soc_sst_baytrail_pcm]
[   12.812788] Disabling IRQ #6

cat /proc/asound/cards 
 0 [bytrt5640      ]: byt-rt5640 - byt-rt5640
                      byt-rt5640

Interessant ist hierbei die Zeile "(try booting with the "irqpoll" option)". Dies hatte ich schon mal mit einem älteren Kernel versucht, der sich darauf hin aufgehängt hat. Mit dem gerade installierten 4.2er Kernel sieht das ganze jedoch schon besser aus. Das Kernelmodul segfaultet nicht mehr und im alsamixer kann man die Soundkarte tatsächlich konfigurieren. Ihr könnt also in eurer grub.cfg die Option irqpoll ebenfalls noch als Kernelparameter eintragen.

Ich habe im ALSA-IRC-Channel eine ganze Weile mit der dortigen Hilfe das Problem analysiert. Bei den SoC-Soundkarten wird der Sound zwischen mehreren Stationen hin und her geroutet. Es gibt also z.B. einen Output-Verstärker, auf den man das Signal von den diversen DACs (Digital-Analog-Converter) routen muss. Dafür gibt's im Alsamixer ungefähr drölfzig Schalter mit so dubiosen Namen wie "RECMIXL HPOL" oder "SPOL MIX DAC L1". Spielt man an diesen herum kann man durchaus hören, wie Einzelne Geräte der Soundkarte zu- oder abgeschaltet werden. Teilweise fiept oder rauscht es auch.
Als Versuch habe ich noch das alsa-statefile eines ASUS T100 geladen, das ebenfalls auf der Baytrail-Architektur beruht: t100_B.state. Ein Statefile beinhaltet Voreinstellungen für die Mixergeräte und sollte im Idealfall alles so einstellen, dass der Ton auf den Lautsprechern ankommt. Das lädt man einfach durch ein alsactl -f t100_B.state restore. Allerdings hat dmait noch kein Sound funktioniert. Ich hoffe also, dass ich irgendwie die richtigen Switchstellungen finde, um den Sound auch tatsächlich zu den Speakern zu routen. An sich lässt sich die Soundkarte aber mit der Firmware direkt von Intel schon ansprechen. Es liegt wohl wirklich nur noch am Routing!

Update 11.11.2015: Das lesen einiger Bugreports hat noch ein bisschen Licht ins dunkel gebracht. Es gibt zwei verschiedene Bay-Trail-Treiber für diese Soundkarte. Einen etwas älteren und einen neueren, der den alten wohl auch ablösen soll. Bei mir wurde immer der alte geladen, weswegen er sich mit einigen Modulen des neueren ins Gehege gekommen ist. Wenn man den alten blacklisted, dann wird der neue geladen. Dieser wiederum verlangt eine andere Firmware und das ist, wo ich gerade hänge. Wenn ihr das selber probieren wollt, dann steckt das Modul in die Blacklist und holt euch die Firmware aus dem Kernel-Tree:

echo "blacklist snd-soc-sst-acpi" > /etc/modprobe.d/49-baytrail.conf
cd /lib/firmware/intel
wget "https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/plain/intel/fw_sst_0f28.bin?h=byt"
wget "https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/plain/intel/fw_sst_0f28_ssp0.bin?h=byt"

Jetzt sollte anstatt des snd-soc-sst-acpi das snd-intel-sst-acpi Modul geladen werden. Nach dem Download der Firmware mit wget müsst ihr den Dateinamen ggf. noch anpassen. Mit dieser Konfiguration erhalte ich nun ein paar andere Kernel-Meldungen. Meine Vermutung ist jedoch, dass die Firmware nicht zum SSP-Kanal passt und daher kein Sound zu hören ist. Ich bleib dran...

Abschließendes

Wenn es bis hier hin alles geklappt hat, wow, Linux läuft auf der Kiste - mehr oder minder. Wenn ihr neues herausfindet, bitte immer her damit. Sound wäre die nächste große Verbesserung.

Das bockige Touch-Display ist Dank Patch nun auch zu gebrauchen.

Ein wichtiger Hinweis noch: Versucht nicht das Gerät in den Suspend to RAM oder Disk zu schicken! Es wollte sich danach partout nicht mehr einschalten lassen. Ich habe dann das Stromkabel gezogen, dann ging es wieder. Ich weiß nicht, was passiert, wenn man das im Batteriebetrieb macht. Evtl. wacht es dann gar nicht mehr auf!

Hier noch eine Liste von Internetseiten über die ich meine Informationen bezogen habe:

• Installing Debian On Asus X205TA
• Realtek SDIO Wi-Fi driver
• IIO accelerometer sensor to input device proxy
• How to Create a EFI/UEFI GRUB2 Multiboot USB drive to boot ISO images
• Asus X205TA hardware support in Ubuntu
• Realtek rtl8723bs sdio adapter
• [PATCH 2/3] HID: i2c-hid: Read wMaxInputLength of input report instead of bufsize
• Issue #10 hadess/rtl8723bs
• An sgdisk Walkthrough
• AlsaInfo
• Fedlet a Fedora remix for bay trail tablets
• Ubuntu (or other Linux) on the Asus Transformer Book T100
• Bay Trail Tablet - Status Report
• [alsa-devel] Intel Baytrail Linux Audio