[09] Die Reise zu einem arbeitendem Display


Terran

Active Member
Joined
Oct 30, 2009
Messages
527
Age
32
EvilDragon [Englischer Beitrag] said:
Well, as you know from yesterday's post, we got the display to work.
However, as promised, we want to be as open and in-depth as possible, so here's an explanation of what we did during the last weeks (well, mostly Nikolaus...)

You will also see some more pictures attached to the post.
Enjoy :)

The following text is directly from Nikolaus (gta04)
5 weeks of treasury hunt have finally lead to a successful "game over". The MIPI interface does no longer woe.

Firstly we did have some hardware bugs (e.g. swapped wires - due to a misprint in a data sheet).
After fixing this we quickly did have a first success: we were able to send some commands and read values back from the display.
But the display stayed dark when sending the initialization sequence.

For some lengthy time we did suspect the OMAP5 and/or Linux drivers and tried to understand/modify/fix/improve it.
But the display stayed dark.

And measuring experiments with an oscilloscope did not show obvious deviations from what we could expect. We were even tempted to rent a better oscilloscope or a commercial MIPI-DSI tester.

Well, it became obvious that our treasure map (data sheet) for the panel was an incomplete excerpt of the data sheet of the controller (it did not have the full command list of the panel). After knocking on many doors, I received a copy of the original treasure map on Tuesday morning :)

It did list all commands and gave a better understanding of everything. But some commands still did not work. I was not even able to read out the chip id code...

Then, I did measure directly on the panel to verify the voltages to exclude another hardware bug.
The result was interesting: the voltages were in coincidence with the default settings according to the data sheet.
But they were not matching the values that should have been set by sending the initialization sequence to the panel.
So it became clear that for some reason the panel did ignore some (not all) of the commands sent to the panel.

After browsing again and again I suddenly found a small footnote on page 244...

We simply have to send the manufacturer specific commands in a slightly different way (it is roughly comparable to use either TCP vs. UDP).

With this knowledge it was also possible to decrypt one table in the panel data sheet... But that is common for such games - afterwards you know which redundant deviations you have taken...

After fixing our kernel driver it worked almost immediately to read back the correct chip id code. Then, it was only a small final step to enable and see a test pattern.
And even the OMAP5 DSS subsystem was initialized correctly, so there was the Linux Tux and some xterm.

If I look at the photos I must say that I am really impressed. Seeing a full web page in a readable manner is amazing.

So let's take the next challenging treasure hunt :)

Übersetzung said:
Wie ihr von dem gestrigen Post wisst, haben wir das Display zum laufen gebracht.
Wir haben versprochen, so offen wie möglich zu sein, darum eine Erklärung, was wir in den letzten Wochen getan haben (hauptsächlich Nikolaus...).

Auch habe ich weitere Bilder für euch.
Geniest es :).

Der folgende Text ist von Nikolaus (gta04)
Fünf Wochen der Schatzjagt hat uns zu einem erfolgreichen "Game Over" geführt.
Das MIPI Interface funktioniert nicht mehr.

Anfangs hatten wir einen Hardwarefehler (bsp. getauschte Leitungen aufgrund falscher Datenblätter).
Nach den Ausbesserungen hatten wir schnell einen ersten Erfolg - wir konnten Kommandos senden und Daten von Display auslesen.
Der Display blieb aber schwarz, wenn wir die initialisations Sequenz schickten.

Für eine lange Zeit dachten wir es sei der OMAP5 und/oder der Linux Treiber und versuchten es zu verstehen/modifizieren/fixen/verbessern.
Schwarzes Display.

Messungen mit einem Oszilloskop zeigte keine offensichtlichen Abweichungen, von dem was wir erwarteten.
Wir dachten schon daran ein besseres Oszilloskop oder ein MIPI-DSI Tester uns zu besorgen.

Es wurde offensichtlich, dass unsere Schatzkarte (Datenblatt) für das Panel keinen vollständigen Auszug des Controllers hatte (keine komplette Kommandoliste).
Nach anklopfen an vielen Türen, habe ich am Donnerstag Morgen eine Kopie der originalen Schatzkarte bekommen.

Die vollständige Kommandoliste hat uns ein besseres Verständnis gegeben.
Einige Befehle wollten immer noch nicht funktionieren, ich konnte nicht mal den Chip ID Code auslesen...

Ich habe am Panel direkt die Spannung gemessen, um einen weiteren Hardwarebug auszuschliesen.
Das Ergebnis war interessant - die Spannung war gleich wie die Standardeinstellung laut dem Datenblatt, aber es hätte den Wert haben sollen, den wir mit der initialisations Sequenz gesetzt haben.
Damit wurde klar, aus irgendeinem Grund ignoriert das Panel einige (nicht alle) der Kommandos.

Nach langer Suche habe ich eine kleine Fußnote auf seite 244 gefunden...

Wir mussten spezielle Kommandos anderst versenden (ungefähr vergleichbar mit TCP vc. UDP).

Mit diesem Wissen konnten wir eine Tabelle im Datenblatt entschlüsseln - das ist üblich für solch ein Spiel, nachher weiß man welche unnötigen Umwege genommen wurden.

Nachdem wir den Kerneltreiber gefixt haben, funktionierte es fast gleich geklappt, den richtige Chip ID Code zu lesen.
Es war nur noch ein kleiner Schritt, um das Testbild zu bekommen.
Auch das OMAP5 DSS Subsystem wurde korrekt initialisiert - der Linux Tux und xterm waren da.

Wenn ich mir die Photos ansehe, bin ich beeindruckt.
Eine Webseite in einer lesbaren Darstellung ist unglaublich.

Lasst uns die nächste herausvordernde Schatzjagd machen :).

Bilder:
post-1-0-86961300-1394161632.jpeg

post-1-0-08301000-1394161634.jpeg

post-1-0-45038800-1394161635.jpeg

post-1-0-57509300-1394161636.jpeg

post-1-0-51253900-1394161637.jpeg

post-1-0-59244000-1394161638.jpeg


Blog
Quelle
 
Back
Top