Am 01.03.2015 um 08:54 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Am 01.03.2015 um 01:34 schrieb Grazvydas Ignotas grazvydas.ignotas@openpandora.org:
Hi,
On 02/26/2015 10:15 PM, Dr. H. Nikolaus Schaller wrote:
Hi, finally I succeeded in flashing the first panel controller.
The reason why we need that is that the BOE panels come unprogrammed.
Which means that we have to send a specific programming sequence through DCS/generic packets to the panel or it would not set up its gamma curves, and some other internal things.
The most noticeable effect of an unprogrammed panel controller is a vertical flickering stripe in the middle of the panel (which is better than with other panels which don’t show anything with unprogrammed controller).
Although I had already added that to our panel driver [1] and it works, we have a problem as soon as we want to operate the panel behind the rotator chip. The SSD2858 has a very unfortunate limitation that prohibits us sending the panel controller setup through the rotator.
*sigh* I wish it just had a pin for the passthrough mode, which we could connect to OMAP’s GPIO.
There is a pass-though bit for the SSD2858. But they just missed to add 8 flipflops to pass through longer packets.
The easiest solution appears to be to program the NVRAM/OTP default values of the panel controller. So that we simply do not have to send any programming command through the ssd chip.
This is what I have now set up. I use the omap5-panel interface board with bridged ssd chip. And I have added a DC/DC converter to produce 7.5V programming voltage plus a transistor which can be controlled by a spare gpio signal. This allows to program the controller through the MIPI interface and issue a “NVRAM write” command to copy the setup to NVRAM.
For the code [2], I use the panel-mipi-debug driver where a shell script can control almost everything of the MIPI interface (reset line, power, video stream, send/receive DCS and generic packets).
Anyways, this is only of temporary need. ED already has a batch of unprogrammed panels, while for series production he was promised to get them programmed at the factory.
Unfortunately this whole setup brings back bad memories of what we have with pandora nubs, where the microcontrollers are only readable and not programmable. If OMAP could reflash the micros, we could have updated them after release, and maybe it would made sense to start an reverse engineering project to create alternative firmware. As it is now absolutely nothing can be done to improve the nubs on pandora.
Yes, we are in a similar situation. If the panels are factory programmed to work behind the SSD censor, we can’t modify settings.
It's not good if we won't be able to program the panel, like updating gamma curves, something we already do on pandora. Or is that just for the init sequence that has problems?
No, any sequence. Including gamma.
Indeed we program some gamma curve into the NVRAM. Or get some gamma curve programmed in the factory.
So what are our options:
- live with fixed gamma curves
- use a different panel (with a different controller chip that is not limited by the SSD)
- use the OMAP5 for rotation to get rid of the rotator chip
- maybe we could add some analog switch chip to bridge the ssd MIPI signals
something like http://www.ti.com/lit/ds/symlink/ts3a5223.pdf but that chip is limited to 80MHz. There may be others but we need research So we add more and more cost to fix a bug/limitation of the combination of this specific panel and the SSD chip. 5. I remember some hint that the panel NVRAM could be programmed in a way that there is no need to send the censored command sequence through the SSD. But I have not completely understood if that works or if our programming setup does it correctly. But I could try to find out.
I have done this test but it does appear to fail.
What I have done: a) connect the (programmed) panel w/o SSD to the OMAP b) power up, remove reset, enable DCS c) try to read “ORISE2” registers -> failed d) enabled CMD2_ENA1 through the censored command, and I could read some ORISE2 register
The idea is to set the CMD2_ENA1 and CMD2_ENA2 registers as “enabled” through OTP so that we never need to send this problematic sequence. But it appears that it is not.
Unfortunately the data sheet is a little contradicting itself. It is not clear if this register can be read back. And what the “default” value from OTP means.
Maybe something we can ask BOE again.
BR, Nikolaus