Odys Loox/Xpress - RK29 Kernelbau

Hi!

Ich mache mal für exakt dieses Thema einen neuen Thread auf, da es in den anderen Threads zu bunt zugeht. Also hier ein neuenb Thread _nur_ für alles rund um den Kernel.

Der Thread soll zwei Dinge ermöglichen:
1) Reproduktiopn des originalen Kernels
Die originalen Quellen von Odys sollten kompilieren und auf dem Xpress oder Loox geflasht funktionieren.
Update 02.12:
Die Kernelquellen produzieren inzwischen einen lauffähigen Code für das Loox, defconfigs fehlen noch, ob auch Xpress und Cosmo aus diesen Quellen bedient werden können, ist noch nicht getestet.
2) Update auf eine neuere Version um einen Zugang zu Android 3.x oder 4.x zu ermöglichen.
Update 02.12:
Es ist erst einige Aufräumarbeit nötig, um dies zu bewerkstelligen.
Update 04.12:
Wir können inzwischen feststellen, dass wir sowohl über funktionierende 2.6.32.27 Kernel Quellen, al auch funktionierende 3.0.8 Kernel Quellen verfügen. Es gibt zwar noch immer einige Probleme mit der Code Qualität und etwas Arbeit an verschiedenen Stellen, aber es macht sich.

Identifizierte Module
... die auch beim Start des Systems an den Kernel angebunden werden:

LCD
Loox:
Das LCD scheint ein AT070SN02V0 zu sein. Nimmt man dieses als Grundlage, kann man mit angepassten Daten aus der lcd_AT070TNA2.c eine passende Initialisierung erzeugen.
Xpress:
Das LCD im XPress ist ein anderes, kann aber mit identischen Daten problemlos angesteuert werden.

PLL Setup
Der RK2918 besitzt eine Reihe PLLs die die Clocks für verschiedene Sektionen des Chips liefern. Aus diesen Clocks werden dann für einzelne Peripherie-Einheiten die nötigen lokalen Clocks erzeugt.
Es ist daher logisch, dass die PLLs und die Teiler auf vernünftigen Einstellungen stehen müssen, um eine Funktion aller peripheren Module zu garantieren.
Leider ist es so, dass sich mit dem Kernel die Einstellungen der PLLs nur teilweise vornehmen lassen, bzw. der Code an vielen Stellen rund um die PLLs und deren Teiler völlig undurchsichtig ist, da er nur als Object-Code vorliegt, nicht als Quellcode.
Daher liegt aktuell eine viel zu niedrige General PLL (gpll) Frequenz am System an, deren Frequenz auch noch unglücklich gewählt ist. So können die Teiler für z.B. USB und SD-Card Interface keine sauberen Frequenzen für sich erzeugen. Dadurch funktionieren diese Komponenten nur unzuverlässig. Auch I2C ist davon betroffen.
Update 02.12:
PLL Sourcecode ist jetzt identifiziert. Der original Code bremst Loxx und Xpress bei 1080MHz aus. Unsere Kernel schalten da noch einer Stufe mehr frei, also 1150MHz. Darüber werden alle Tablets mit RK2918 instabil.
Unsere Kernel lassen aber ausser 1080MHz und 400MHz auch noch 5..6 weitere Stufen zu, in die sie je nach Last schalten. Und wir gehen runter bis 24MHz.

RTL8188 WLAN Adapter (Realtek)
Tablet: Neuere Loox
Datenblatt: Nur unvollständig verfügbar
Quellen: Treiber bei Realtek vollständig vorhanden incl. Anpassungen für Android
Kommentar: Der Baustein ist am USB1.1 Controller des RK2918 angeschlossen. Jeder Versuch trotz 802.11b/g/n Unterstützung mehr als 12MBit/s Datenrate zu erhalten ist zwecklos. Für Videostreams ergeben sich bei optimalem Empfang etwa 8MBit/s downstream.
Update 02.12:
Sourcen jetzt vollständig vorhanden. Wird im Loox mit dem Treiber des RTL8192 genutzt. Fehlende GPIO Ansteuerung durch SDIO Treiber nun vorhanden.
Status: WORKING

8686 WLAN Adapter (Marvell)
Tablet: Ältere Loox?
Datenblatt: Nicht Verfügbar, Hersteller Marvell
Quellen: Unbekannt
Kommentar: Dieser Chipsatz wurde durch Zufall gefunden, da der Firmware-Blob im Odys Image vorhanden ist. Zudem gibt es bei z.B. Amazon in den Berichten einen Hinweis darauf, dass ab einem bestimmten Zeitpunkt ein anderer WLAN Chip verbaut ist, da die Empfangsqualität und die Datenrate deutlich schlechter geworden sind.
Dieser Chip ist am SDIO angeschlossen, wird also als SD-Card betrieben. Er kann vermutlich die volle Bandbreite des WLAN ausschöpfen.
Update 02.12:
Module im Kernel anwählbar. Ob auch funktionsfähig, kann erst getestet werden, wenn jemand ein Loox mit diesem Chipsatz hat und uns hilft ein paar Tests zu machen.
Status: TBD

BCM4329 WLAN Adapter (Broadcom)
Tablet: Xpress
Datenblatt: Nicht vollständig verfügbar
Quellen: In mehreren Versionen verfügbar.
Kommentar: Der im Xpress vorhandene Treiber schaltet vermutlich alle Extras in diesem Chipsatz aus. Denn der Chipsatz kann neben WLAN 802.11/b/g/n auch Bluetooth und FM-Radio. Es ist aber fraglich ob die passenden Antennen und die nötige externe Beschaltung am Chip vorhanden ist. Der Chipsatz ist in einem SWL-B33 verbaut. Das SWL-B23 ist in vielen Handies (SWL = Samsung WireLess, Verbaut in Samsung und HTC) und dort für diese Dienste zuständig. Das SWL-B33 ist vermutlich nur mit einem kleineren Bruder des BCM4329 bestückt, der nur WLAN kann.
Dieser Chip ist am SDIO angeschlossen, wird also als SD-Card betrieben. Das SDIO wird mit 25MHz betrieben und ist vermutlich 4-Bit breit. Hier sind also etwa 20MByte/s möglich.
Update 04.12:
Status: WORKING

HYM8563 RTC (Uhr) angeschlossen an I2C Bus 1
Tablet: Loox / Xpress
Datenblatt: scheint baugleich zu diversen 8563 RTCs zu sein, u.A. NXP.
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Status: WORKING

MMA8452 Beschleunigungssensor von Freescale, ebenfalls I2C, Bus vermutlich ebenfalls Bus 1
Tablet: Loox / Xpress
Datenblatt: MMA8452Q Product Summary Page
Quellen: Treiber im Kernel 2.6.32.27 vorhanden, LCD wird entsprechend der Tablet-Ausrichtung gedreht.
Status: WORKING

ALC5621 Multi-Channel-AudioCodec mit Mono 2.3W Ausgang und Stereo Line-Out.
Tablet: Loox
Datasheet: Realtek
Quellen: Treiber im Kernel 2.6.32.27 vorhanden.
Status: WORKING

WM8900 Multi-Channel-AudioCodec Stereo 2.3W Ausgang und Stereo Line-Out.
Tablet: Xpress
Datenblatt: CODECs | WM8900 | Wolfson Microelectronics
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Status: WORKING

OV7675 Front Kamera
Tablet: Loox / Xpress
Datasheet: OmniVision
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Kommentar: Cam wird erkannt und liefert video. Es gibt noch ein paar Fehlermeldungen bzgl. des Bildformates.
Status: WORKING

OV2655 Rear Kamera
Tablet: Xpress
Datenblatt: OmniVision
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Kommentar: Noch nicht getestet
Status: WORKING

ANX7150 HMAC HDMI Media Access Controller, nur im Xpress bestückt.
Tablet: Xpress
Datenblatt: Analogix
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Status: WORKING

LZ300MSF Resistive-Touch-Controller
Tablet: Loox
Datenblatt: Unbekannt
Quellen: Treiber im Kernel 2.6.32.27 vorhanden, im 3.0.8 vorhanden.
Kommentar: War viel Arbeit, vor allem von fr3ts0n. Nun auch mit funktionierender Kalibrierung.
Status: WORKING

SIS809 Capacitive-Touch-Controller
Tablet: Xpress
Datenblatt: Vorhanden
Kommentar: Der gemeldete Chip ist gelogen, in dem ganzen gerät gibt es keinen SIS809. Stattdessen ist dort ein Raydium RM31060 Touch Screen Controller mit SPI Interface verbaut. Dahinter auf der gleichen Anschlussfolie ist ein kleiner Controller, der SPI in Si2C übersetzt. Der Treiber, der ursprünglich mal für den SIS809 gedacht war, wurde gerupft und nicht umbenannt.Status: TBD
Status: WORKING

BQ27510 Battery-Manager
Tablet: Andypad Pro
Datenblatt: Bei TI hier zu finden
Quellen: Treiber im Kernel 2.6.32.27 vorhanden
Kommentar: Wird erkannt und ohne weitere Meldungen eingebunden. Allerdings habe ich das Tablet wegen dauerndem Flashen immer am Netzteil und kann noch nicht sagen, ob er auch vom System korrekt verwendet wird. Der Baustein ist eine 'Fuel Gauge' also eine reine Füllstandanzeige für den Akku. Die Ladeschaltung ist vermutlich diskret aufgebaut. Jedenfalls gibt es ein paar SMD Bauteile in der Umgebung, deren Code auf OPs hinweisen.
Status: Ongoing

ADC RK2918 ADC Eingänge
Tablet: Loox
Für das LiPo Management wird im Loox kein BQ27510 verwendet, sondern einer der ADC Kanäle vom SOC. Dabie wird ausschliesslich die Spannung gemessen, was jegliche Art der Kapazitätsanzeige zu einem reinen Lotteriespiel macht. Wenn wenigestens der Strom noch gemessen werden würde... Schade...
Status: WORKING

PWM RK2918 PWM Ausgang
Die LED Hintergrundbeleuchtung wir über eine PWM-Stufe des RK2918 gesteuert. Port/Pin und Anpassungsmöglichkeiten sind inzwischen bekannt.
Status: WORKING

TASTEN
Die Tasten am Tablet werden scheibar bei vielen Herstellern gleich belegt. Sie sind daher i.d.R. ansprechbar und werden korrekt ausgewertet.
Quellen: Board spezifische Dateien fehlen, daher ist hier raten angesagt. Die in den meisten Quellen vordefinierte Belegung scheint aber zu stimmen.
STATUS: WORKING

RK2918 CPU
Datenblatt: Unvollständig, kein Programmers-Manual verfügbar
Quellen: Im Kernel 2.6.32.27 zum grossen Teil vorhanden.
Kommentar: Im Kernel fehlen einige wichtige Sourcen um das DDR RAM zu initialisieren, die PLLs zu konfigurieren und ein paar andere Dinge. Stattdessen wurden uu-komprimierte .o Dateien mitgeliefert, die teilweise als Blob geladen werden. Diese Blobs werden beim Start zuerst in das interne SRAM des RK2918 kopiert. Erst dann werden sie verwendet.
Status: Er funktioniert... mehr kann man vorläufig nicht sagen

RK2918 GPU
Quellen: Im Kernel Code sind entsprechende uu-komprimierte Object-Dateien vorhanden, die Video-Beschleunigung zur Verfügung stellen (sollen).
Kommentar: Die sog. VPU relevanten Codes liegen nicht im Source vor, sondern sind als uu-comprimierte .o Dateien mitgeliefert. Interessant wird es, wenn man auf einen neueren Kernel umsteigt. Ausserdem sind bereits neuere Versionen dieser Dateien aufgetaucht, die vermutlich für ICS4 erforderlich sind.
Status: TBD

RK2918 VPU
Quellen: Im Kernel Code sind entsprechende uu-komprimierte Object-Dateien vorhanden, die Video-Beschleunigung zur Verfügung stellen (sollen).
Kommentar: Augenscheinlich funktionieren diese nicht im Source verfügbaren Dateien aber gut, denn das Xpress erreicht erstaunliche Laufzeiten bei reinem Videostreaming.

KERNEL
Quellen, die einen funktinonierenden Kernel für das Loox erzeugen sind inzwischen vorhanden. Die Qualität des Codes ist teilweise zweifelhaft.
Einige Dinge, u.A. CPU Speed, sind noch genauer zu untersuchen.
Einiges sollte überarbeitet werden, da z.B. beim Loox ebenso wie beim Xpress zwei Kameras eingebunden werden, obwohl das Loox nur eine besitzt. Ausserdem scheint das Kamera Interface vom RK28 abgeleitet worden zu sein, der nur eine Kamera unterstützt. Der Treiber ist jedenfalls so aufgebaut, dass er ein Device inbstalliert, welches aus zwei Kameras besteht, die sich nur in den GPIOs unterscheiden. Seltsamerweise wurde vergessen, die I2C Bus Konfiguration zu berücksichtigen. Dadurch wird auf dem Loox eine nicht existierende Kamera aktiviert.

Anmerkungen:
Für den Kernel selbst sollte es erst einmal uneerheblich sein, welcher Compiler genutzt wird. In vielen Foren wird jedoch darauf hingewiesen, dass man die Makefiles um einige Optionen ergänzen muss. Diese Hinweise beziehen sich auf gcc <= 4.4.x mit einem originalen Kernel.
Der von Odys gepatchte und um den RK29 erweiterte Kernel 2.6.32.27 wurde bereits um diese Modifikationen ergänzt. Die Mühe kann man sich also sparen.

Ich kompiliere den Kernel mit arm-linux-gnueabi mit einem gcc der Version 4.5.2.

Im Folgende ein paar Dinge, die dem geneigten Entwickler helfen können
-----------------------------------
Hier ein komplettes BootLog vom Odys Kernel selbst, also dem der auch startet:
In cap=512MB OUT BUILD[0006]=====374723 GetRemapTbl flag = 0 OK! Boot ver: - Pastebin.com

Habe mal ein vollständiges Bootlog eines selbst gebauten Kernels hier hin gestellt:
LooxBootLog_AstralixKernel - Pastebin.com

U9 Kernel 3.0.8 Bootlog auf dem Loox:
U9 Kernel on OdysLoox Bootlog - Pastebin.com
-----------------------------------
Grüsse
Astralix

Update:
Treiber für A060SE02 und S1D1352 kompiliern nicht.

Update:
Treiber für AT070TNA2 kompiliert und zeigt einen kleinen zerfranzten blau verfärbten Pinguin in der Ecke oben links...
Nachdem ich den Treiber lcd_AT070TNA2.c auf 800x600 modifiziert habe, ist der Pinguin so, wie er sein soll.
Aber danach wird das LCD schwarz und nichts rührt sich mehr. Allerdings ist das Loox nun mit ADB erreichbar. Irgendwas funktioniert also noch.

In der init.rc und init.rk29board.rc läßt sich ein wenig über die Hardware auslesen:

BCM4329B1 combo chip for WLAN/BT
bq27510 Batterymanagement
mma8452 3-Axis, 12-bit/8-bit Digital Accelerometer
akm8975 Rotationssensor
anx7150 HDMI
rk1000_TVOUT

Die Schnittstellen zu den Bildgeräten sind ja im SoC:

Camera Sensor
EPD driver (Touchscreen)
LCD controller

Android als sozusagen letzte Instanz wird wohl recht haben, mit dem was es da einbindet ;-)


Nachtrag: die genannten Geräte werden in den inits als services gestartet.
Im Android blog gibt es folgenden Hinweis zur init-Language und dem Befehl services:
What is provided in the system goes a long way and often it may be better to add something to the
Android runtime instead of using the native services.

Verstehen tue ich es nicht wirklich, aber es gefällt mir nicht. Wo sind denn die Android-Spezis ?????

Wer selber mal was probieren möchte:
Ich habe hier: [TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets - Page 2 - xda-developers den Quellcode des rkflashtools für linux heruntergeladen und nach der Anleitung compiliert.

Dann habe ich mir meinen eigenen Kernel gebaut:
export CROSS_COMPILE=arm-linux-gnueabi-
make menuconfig
... einiges passend eingestellt...
make kernel.img

Dann mit
adb reboot bootloader
das Loox in den Bootloader geschossen. Allerdings kapiert der das dann nicht und startet das Loox einfach wieder neu. Daher muss man:
1) Stromversorung anstecken
2) M Taste halten
3) adb reboot bootloader /oder/ RESET Taste drücken

Nun kann man mit
sudo ./rkflashtool w 0x4000 0x4000 < kernel.img
das Image flashen.
Um zu testen, ob es auch wirklich so funktioniert, habe ich aus dem Odys Update den originalen Kernel auch wieder geflasht und siehe da, es funktioniert wieder.

So, nun gehe ich mal weiter kompilieren...

Ich habe einen Kernel laufen ... na ja, das Display wurde dann auch schwarz, ein Recovery fing an, das war es dann ...

Der Displaytreiber scheint zu gehen.

Thomas.

Jetzt habe ich gerade in den anderen Thread geantwortet, also der Vollständigkeit halber noch mal hier:

WLAN: BCM4329B1 combo chip for WLAN/BT
1) Der BCM Chipsatz ist definitiv nicht im Loox. Stattdessen ist ein Realtek RTL8188 darin zu finden.
2) Der BCM code im Kernel compiliert nicht. Habe die einzelnen Fehlermeldungen aber noch nicht ausgewertet, sondern WLAN einfach daktiviert.

Akku: bq27510 Batterymanagement
Es gibt einen Akku-management Chip, aber der stimmt in Pinning aund Aufdruck nicht mit dem BQ27510 überein. Vielleicht verhält er sich aber so. China... man weiss nie

ACCEL: mma8452 3-Axis, 12-bit/8-bit Digital Accelerometer
Möglicherweise, aber auch hier: Gehäuse passt, Aufdruck nicht.
akm8975 Rotationssensor
Da ist ein nicht bestücktes Feld neben dem MMA, wahrscheinlich war der hier mal vorgesehen.
anx7150 HDMI
Im Loox nicht vorhanden. Leeres Plätzchen für den Chip ebenso wie für den Mini-HDMI Stecker.
rk1000_TVOUT
??

fluxflux schrieb:

Ich habe einen Kernel laufen ... na ja, das Display wurde dann auch schwarz, ein Recovery fing an, das war es dann ...

Der Displaytreiber scheint zu gehen.

Thomas.

Zum Vergrößern anklicken....

Ich habe den Treiber etwas modifiziert, dann lieferte er einen Pinguin in den richtigen Farben. Dann war auch Schluss.
Komm mal in den Chat, dann ist es einfacher.

Könnte das eventuell weiterhelfen ?
Hier geht es um das SmartPad 810c in etwa die gleiche Hardware wie unser Loox,nur Kapatzitiver Bildschirm.
verwendet wird auch das http://www.odys.de/downloads/softwar...SourceCode.zip,

[GUIDA] Compilare il kernel RK2918 - Forum Android Italiano

Mediacom SmartPad 810c - Forum Android Italiano

Hi satwilli!

danke für den Link. Google Translate zerlegt das ganze schön kryptisch...

Aber die installieren da noch was, was uns wahrscheinlich fehlt... mal senen was das mit dem Android ist, dass man da noch verlinken muss.

fluxflux schrieb:

Ich habe einen Kernel laufen ... na ja, das Display wurde dann auch schwarz, ein Recovery fing an, das war es dann ...

Der Displaytreiber scheint zu gehen.

Zum Vergrößern anklicken....

Schau mal in der default.prop (liegt in root), ob da die richtige Hardware eingetragen ist.

Ich denke, dass nur der richtige Touchscreentreiber fehlt, denn das System scheint zu booten, nur das Display schaltet aus dem Framebufferbereich raus und kann danach den korrekten Treiber nicht finden ... ich habe jetzt mal dem Kernel die CMDLINE übergeben, es passiert auch nicht mehr.

Wenn z. B. nach Erreichen des "Blackscreens" etwas warte und einen Kartenleser an den USB-Host anschließe, dann wird die SD-Karte darin initialisiert, also nicht nur mit Strom versorgt. Das System sollte also doch laufen???

Thomas.

Ich habe jetzt in der config auf Verdacht ein paar Touchscreentreiber aktiviert, jetzt bleibt der kleine Pinguin im linken oberen Eck und schaltet sich nicht mehr weg, das System bootet aber trotzdem nicht.

Ich bin für meinen Teil damit wohl durch ...

Thomas.

Eine Idee noch: In der boot.img wird mit der init.rc ein Kernelmodul rk29nand__ko.ko geladen.

Könnte nun sein, dass dieses inkompatibel zum neuen Kernel ist und nicht geladen wird und damit der Bootprozess stehen bleibt, da die Partitionen nicht gefunden werden?

Thomas.

Hi!

Der Bootprozess geht definitiv soweit durch, dass ADB läuft. Die default.prop enthält bei mir auf dem laufenden original Image keine besonderen Infos, ausser ein paar Settings für ADB.
Da ich das rootfs durch den Kernel nicht ersetze, sollte die gleiche default.prop genutzt werden.

Ein rk29nand_ko.ko sehe ich jetzt nicht...
In meinem Kernel wird auch keines gebaut.... Ich muss wohl mal die Serielle Console aktivieren und sehen, ob die MTD Partitions korrekt initialisiert werden. Per default sind da einige Features im Kernel deaktiviert... Guter Ansatz.

Wollte aber in meinem Tablet jetzt noch nicht löten, weil ich Odys mal über den Zustand des Tablets informiert habe. Klar, ich konnte dden Zustand nur durch Öffnen und damit Garantierverletzung herausfinden, aber vielleicht kommen Sie mir beim Kernel ja entgegen.

Das rk29nand__ko.ko liegt in der boot.img und wird von dort direkt in der init.rc geladen:

Ich habe versucht, dieses Modul zu bauen, scheitert aber ...

Thomas.

P. S.: Diese Info noch:

Also ich habe im Kernel das "RK29 NAND Flash Controller Driver with FTL" aktiviert. Der sollte also dabei sein.
Eventuell ist der jetzt im boot.img zu viel.
Also doch serielle...

Kann natürlich ein Problem sein:
Wenn das init-Script keine Fehler abfängt, dann bricht es beim ersten Fehler ab und läuft nicht durch. Damit würde Android garnicht starten.

Nachtrag:
Habe mal ein vollständiges Bootlog des selbst gebauten Kernels hier hin gestellt:
http://pastebin.com/dTPFTRE1

Nachtrag2:
Hier mal ein komplettes BootLog vom Odys Kernel selbst, also dem der auch startet:
http://pastebin.com/zYXYd4QE

So wie sich das bei den Italienern anhört verwenden die aus den Odys Kernel Quellen nur die ".config"
Der Kernel wird dann aber aus den anypad Quellen gebaut.

Versteht Ihr das auch so ?

Ich bekomme die Quellen von Paulobrien aber nicht "ausgecheckt" (git clone https://bitbucket.org/paulobrien/android_kernel_andypad.git). Sagt mir immer "error: The requested URL returned error: 403".

Hat das schon mal jemand erfolgreich hinbekommen ?
Wenn man unter https://bitbucket.org/paulobrien/android_kernel_andypad/src schaut sieht man aber die Quellen...

@Astralix: gehe ich recht in der Annahme, dass Du das Log von ttyS1 hast ?

Während der bootende Kernel den Touchscreen initialisiert schaltet der nicht bootende die GPU ab!?

Thomas.

Also ich habe die Sourcen vom git bekommen, aber die kompilieren nicht, sondern brechen mit ein paar Fehlern ab. Habe daher da erst mal nicht weiter gemacht.

Die Odys Quellen kompilieren, aber es fehlen ein paar Treiber, bzw. die chips identifizieren sich anders, als sie in den Quellen heissen.
z.B. ist der AC97 Codec in den Quellen ein ALC5621, aber der bootende Kernel meldet dann einen RT5621. Der beim Boot laufende Debug ist zwar etwas unterschiedlich, aber immerhin initialisiert er da was.

Den Touch kann ich aktuell noch nicht finden, das ist im Odys Kernel ein lz300, den es im Kernel aber so erst mal nicht gibt.

Ein Unterschied ganz zu Anfang ist das Clock Setup. In meinem Kernel werden da am Ende /37/150/150/37MHz angezeigt, im Odys /37/144/144/36MHz.

Das kann z.B. dazu führen, dass in meinem Kernel beim USB eine krumme Clock heraus kommt, die der Kernel selbstständig auf 48MHz korrigiert.
Kann aber auch der Grund dafür sein, dass es beim I2C schon mal ein paar mehr Fehler gibt, obwohl die Bausteine richtig detektiert werden.

Muss mir also die rk29_clock.c oder ähnlich mal ansehen.

Es geht aber weiter

fluxflux schrieb:

Während der bootende Kernel den Touchscreen initialisiert schaltet der nicht bootende die GPU ab!?
Thomas.

Zum Vergrößern anklicken....

Wie meinst Du das? Gib mal [Zeit] aus den kernel-logs.

Ach so, ja, die beiden pastebin dateien sind via Dongle von der Seriellen ttyS1 gezogen.