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
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
