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.
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.
So he will send me this batch and they will be programmed in quite a short time. Then, we can use them for our hardware prototypes.
This means nobody of you will see an unprogrammed panel (unless I forget one) and we can remove lines 129 - 315 of [1] again. And the programming code.
BR, Nikolaus
[1]: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/video/fbdev/om... [2]: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/4.0-rc1
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.
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.
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?
Grazvydas
On Sun, 1 Mar 2015, Grazvydas Ignotas wrote:
# *sigh* I wish it just had a pin for the passthrough mode, which we could # connect to OMAP's GPIO.
Overkill perhaps, but a pass through buffer chip? .. so that you can have a GPIO to enable/disable the buffer, and otherwise have some GPIOs bitbang (or another video channel?) through to the panel?
jeff
-- If everyone would put barbecue sauce on their food, there would be no war.
Am 01.03.2015 um 05:07 schrieb skeezix skeezix@skeleton.org:
On Sun, 1 Mar 2015, Grazvydas Ignotas wrote:
# *sigh* I wish it just had a pin for the passthrough mode, which we could # connect to OMAP's GPIO.
Overkill perhaps, but a pass through buffer chip? .. so that you can have a GPIO to enable/disable the buffer, and otherwise have some GPIOs bitbang (or another video channel?) through to the panel?
Well, the panel needs clock and data in MIPI signal levels to send commands. This is not compatible to GPIOs and GPIOs are too slow (10 MHz clock).
And, we can’t fiddle additional signals through the display cable.
So the ideal solution would just use the existing ones.
BR, Nikolaus
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:
1. live with fixed gamma curves 2. use a different panel (with a different controller chip that is not limited by the SSD) 3. use the OMAP5 for rotation to get rid of the rotator chip 4. 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.
BR, Nikolaus
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
Am Sun, 1 Mar 2015 15:18:35 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, we can switch to the Success panel, a Linux driver exists and it's cheaper.
However, we'd need to...
1. Redesign the case 2. Take care once again of the touchscreen 3. Have the risk that the panel production is not consistent (as Success simply took over the production line, they don't know what they're doing). This was an issue with the Pandora: Each batch had different colors, gamma and even touchscreen...
With BOE, we've got great support so far and we know that the panels will stay consistent as they don't sell their production lines. They're the biggest panel delivery service for Samsung. If you got a Samsung Galaxy Note, you've got a BOE panel...
So we could switch to OLED when the technology is right when BOE is already our partner - those would be great advantages.
Some questions:
* If I understood correctly, the issue is the 0xff sequence. Can this be changed with flashing as well? Maybe we could change it to something different. Or is that a non-configurable option of the Orise?
* Would it be possible to program the Panel through the SSD? Or does the programming sequence also start with 0xff? If it's possible, how complicated would it be to make the Panel flashable from Pyras hardware?
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 01.03.2015 um 18:17 schrieb Michael Mrozek mrozek@openpandora.org:
Am Sun, 1 Mar 2015 15:18:35 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Well, we can switch to the Success panel, a Linux driver exists and it's cheaper.
However, we'd need to...
0. make it work on our setup.
- Redesign the case
- Take care once again of the touchscreen
- Have the risk that the panel production is not consistent (as
Success simply took over the production line, they don't know what they're doing). This was an issue with the Pandora: Each batch had different colors, gamma and even touchscreen...
With BOE, we've got great support so far and we know that the panels will stay consistent as they don't sell their production lines. They're the biggest panel delivery service for Samsung. If you got a Samsung Galaxy Note, you've got a BOE panel…
Well, there might be the option to use the other BOE panel we initially did have. I think it was a 680l and I don’t know why they switched it. It has a different controller and connector, but otherwise it looked to be the same to me. At least from the data sheet.
So we could switch to OLED when the technology is right when BOE is already our partner - those would be great advantages.
Some questions:
- If I understood correctly, the issue is the 0xff sequence.
only the 0xff 12 83 01 sequence is too long for the ssd to forward it to the panel. A 0xff 18 80 or a 0xfe 12 83 01 sequence could be forwarded.
Can this be changed with flashing as well?
No.
Maybe we could change it to something different. Or is that a non-configurable option of the Orise?
I think we already clarified.
Neither with ORISE nor with Solomon it is possible to change it (or they would have to redesign their chips). They just happened to use the same “escape” sequence code.
- Would it be possible to program the Panel through the SSD?
No. Or we would not have these problems.
Basically we just can’t switch the panel to programming mode (the 0xff 12 83 01 sequence) if it is connected behind the ssd.
If we remove the ssd and do OMAP rotation we have the cheapest variant and it works. Although it drives up processing load of the OMAP.
Or does the programming sequence also start with 0xff?
Yes. See above.
If it's possible, how complicated would it be to make the Panel flashable from Pyras hardware?
Quite complicated. You need a hardware bypass for MIPI signals (~400 MHz). This is not that easy and costs additional money.
And, if we have this bypass, we do not even have to flash the panel, because we can reprogram it on every boot.
The flashing approach is just to get rid of *any* panel programming so that we never have to send the 0xff 12 83 01 sequence. But if we want to be able to program the panel, it might not be the solution.
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Am Sun, 1 Mar 2015 19:08:06 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- make it work on our setup.
Well, they got it working under Linux with the Raspberry Pi, so it shouldn't be THAT much different, but I'd like to prevent that.
With BOE, we've got great support so far and we know that the panels will stay consistent as they don't sell their production lines. They're the biggest panel delivery service for Samsung. If you got a Samsung Galaxy Note, you've got a BOE panel…
Well, there might be the option to use the other BOE panel we initially did have. I think it was a 680l and I don’t know why they switched it. It has a different controller and connector, but otherwise it looked to be the same to me. At least from the data sheet.
That panel is out of production and has been replaced by the one we're using now, so I doubt we can use that.
So we could switch to OLED when the technology is right when BOE is already our partner - those would be great advantages. Some questions:
- If I understood correctly, the issue is the 0xff sequence.
only the 0xff 12 83 01 sequence is too long for the ssd to forward it to the panel. A 0xff 18 80 or a 0xfe 12 83 01 sequence could be forwarded.
So is this only needed for the initialization routine? Or does this affect changing the gamma curve, bit depth, etc. as well?
- Would it be possible to program the Panel through the SSD?
No. Or we would not have these problems. Basically we just can’t switch the panel to programming mode (the 0xff 12 83 01 sequence) if it is connected behind the ssd.
Ah, okay. The programming mode is also a sequence too long.
If we remove the ssd and do OMAP rotation we have the cheapest variant and it works. Although it drives up processing load of the OMAP.
Which doesn't work properly as we already clarified, so that is not useful for us.
The flashing approach is just to get rid of *any* panel programming so that we never have to send the 0xff 12 83 01 sequence. But if we want to be able to program the panel, it might not be the solution.
The question is: Is that programming sequence needed for ALL settings or just for the basic ones?
Changing something like the bit depth, etc. can usually be done on-the-fly, does that need a full reprogramming as well?
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
Am 01.03.2015 um 19:41 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sun, 1 Mar 2015 19:08:06 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
- make it work on our setup.
Well, they got it working under Linux with the Raspberry Pi, so it shouldn't be THAT much different, but I'd like to prevent that.
With BOE, we've got great support so far and we know that the panels will stay consistent as they don't sell their production lines. They're the biggest panel delivery service for Samsung. If you got a Samsung Galaxy Note, you've got a BOE panel…
Well, there might be the option to use the other BOE panel we initially did have. I think it was a 680l and I don’t know why they switched it. It has a different controller and connector, but otherwise it looked to be the same to me. At least from the data sheet.
That panel is out of production and has been replaced by the one we're using now, so I doubt we can use that.
So we could switch to OLED when the technology is right when BOE is already our partner - those would be great advantages. Some questions:
- If I understood correctly, the issue is the 0xff sequence.
only the 0xff 12 83 01 sequence is too long for the ssd to forward it to the panel. A 0xff 18 80 or a 0xfe 12 83 01 sequence could be forwarded.
So is this only needed for the initialization routine?
Would be nice…
Or does this affect changing the gamma curve, bit depth, etc. as well?
Yes, it is the key to change anything within the panel.
- Would it be possible to program the Panel through the SSD?
No. Or we would not have these problems. Basically we just can’t switch the panel to programming mode (the 0xff 12 83 01 sequence) if it is connected behind the ssd.
Ah, okay. The programming mode is also a sequence too long.
If we remove the ssd and do OMAP rotation we have the cheapest variant and it works. Although it drives up processing load of the OMAP.
Which doesn't work properly as we already clarified, so that is not useful for us.
The flashing approach is just to get rid of *any* panel programming so that we never have to send the 0xff 12 83 01 sequence. But if we want to be able to program the panel, it might not be the solution.
The question is: Is that programming sequence needed for ALL settings or just for the basic ones?
All.
Changing something like the bit depth, etc. can usually be done on-the-fly, does that need a full reprogramming as well?
Hm. I am not sure if you can change the bit-depth at all. MIPI always has 24 bit (or even 32 bit?) RGB. Since all the panel timing is calculated for that. So you can’t even change it on the fly. You have to stop the MIPI video stream, change parameters and restart…
The only thing that IMHO makes sense to change inside the panel are the gamma curves. Maybe some parameters for automatic backlight level calculations.
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Sun, 1 Mar 2015 20:46:41 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
So is this only needed for the initialization routine?
Would be nice…
Or does this affect changing the gamma curve, bit depth, etc. as well?
Yes, it is the key to change anything within the panel.
Do we have a list of all commands that can be used to change anything inside of the panel? In that case, we could check if there's anything we really eed.
Changing something like the bit depth, etc. can usually be done on-the-fly, does that need a full reprogramming as well?
Hm. I am not sure if you can change the bit-depth at all. MIPI always has 24 bit (or even 32 bit?) RGB. Since all the panel timing is calculated for that. So you can’t even change it on the fly. You have to stop the MIPI video stream, change parameters and restart…
Hm, if MIPI is basically fixed with frequency, bit-depth, etc., then there's not much that could go wrong here.
The only thing that IMHO makes sense to change inside the panel are the gamma curves. Maybe some parameters for automatic backlight level calculations.
If there's a hardware gamma setting in the OMAP5, then that should work as well.
And doesn't the SSD have some backlight settings as well? It even has settings to improve the visibility in daylight, etc.
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am 01.03.2015 um 21:48 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sun, 1 Mar 2015 20:46:41 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
So is this only needed for the initialization routine?
Would be nice…
Or does this affect changing the gamma curve, bit depth, etc. as well?
Yes, it is the key to change anything within the panel.
Do we have a list of all commands that can be used to change anything inside of the panel?
Yes. It is in the data sheet of the ORISE controller.
In that case, we could check if there's anything we really eed.
Changing something like the bit depth, etc. can usually be done on-the-fly, does that need a full reprogramming as well?
Hm. I am not sure if you can change the bit-depth at all. MIPI always has 24 bit (or even 32 bit?) RGB. Since all the panel timing is calculated for that. So you can’t even change it on the fly. You have to stop the MIPI video stream, change parameters and restart…
Hm, if MIPI is basically fixed with frequency, bit-depth, etc., then there's not much that could go wrong here.
The only thing that IMHO makes sense to change inside the panel are the gamma curves. Maybe some parameters for automatic backlight level calculations.
If there's a hardware gamma setting in the OMAP5, then that should work as well.
And doesn't the SSD have some backlight settings as well? It even has settings to improve the visibility in daylight, etc.
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Well, before we can do that, the SSD should work at all :)
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
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
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Sun, 1 Mar 2015 22:04:22 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Yes, it is the key to change anything within the panel.
Do we have a list of all commands that can be used to change anything inside of the panel?
Yes. It is in the data sheet of the ORISE controller.
Okay, just checked that. Doesn't seem there's that much interesting there except for the gamma curves and maybe the PWM settings (for the backlight).
Those two need the Orise mode enabled (not the one you mentioned earlier).
With quick browsing, I couldn't find how to switch to Orise mode - do you know that?
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Well, before we can do that, the SSD should work at all :)
Yes, sure :) Did you try playing with the new commands we received on Friday?
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
> 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 > > _______________________________________________ > Kernel mailing list > Kernel@pyra-handheld.com > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
ICQ: 15691903 MSN: EvilDragon1717@hotmail.com eMail: info@openpandora.de
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am 01.03.2015 um 22:31 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sun, 1 Mar 2015 22:04:22 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
Yes, it is the key to change anything within the panel.
Do we have a list of all commands that can be used to change anything inside of the panel?
Yes. It is in the data sheet of the ORISE controller.
Okay, just checked that. Doesn't seem there's that much interesting there except for the gamma curves and maybe the PWM settings (for the backlight).
Those two need the Orise mode enabled (not the one you mentioned earlier).
With quick browsing, I couldn't find how to switch to Orise mode - do you know that?
Yes, by this magic 0ff 12 83 01 sequence. The data sheet is a little confusing what „Orise mode“ is. And that was the problem why we initially did not understand how to program the panel.
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Well, before we can do that, the SSD should work at all :)
Yes, sure :) Did you try playing with the new commands we received on Friday?
I tried to get the SSD to respond, but did not see anything. So there might be something broken in my current setup. Haven’t analysed deeper. Maybe, the timing of the OMAP is sufficient for the direct panel connection but not for the SSD. AFAIR, there were some changes after the last real SSD experiments.
With a little luck we will have 3 more SSD boards by end of next week.
Basically I asked BOE if we can have the panel boot up as if the 0xff 12 83 01 sequence were already sent.
Let’s wait for their answer.
> >> 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 >> >> _______________________________________________ >> Kernel mailing list >> Kernel@pyra-handheld.com >> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel >> > > > -- > Mit freundlichen Grüßen, > > Michael Mrozek > > ----------------------- > OpenPandora GmbH > Geschäftsführer: Michael Mrozek > > Schäffbräustr. 11 > 85049 Ingolstadt > Deutschland > Tel.: 0841 / 13 177 33 > http://www.openpandora.de/ > HRB 4879, Amtsgericht Ingolstadt > ----------------------- > ICQ: 15691903 > MSN: EvilDragon1717@hotmail.com > eMail: info@openpandora.de
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Sun, 1 Mar 2015 22:47:19 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
With quick browsing, I couldn't find how to switch to Orise mode - do you know that?
Yes, by this magic 0ff 12 83 01 sequence. The data sheet is a little confusing what „Orise mode“ is. And that was the problem why we initially did not understand how to program the panel.
Okay, so both of them will only work when we can switch the panel to Orise mode automatically on power-up, understood.
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Well, before we can do that, the SSD should work at all :)
Yes, sure :) Did you try playing with the new commands we received on Friday?
I tried to get the SSD to respond, but did not see anything. So there might be something broken in my current setup. Haven’t analysed deeper. Maybe, the timing of the OMAP is sufficient for the direct panel connection but not for the SSD. AFAIR, there were some changes after the last real SSD experiments.
With a little luck we will have 3 more SSD boards by end of next week.
Oh, not even a response at all? You can't even read registers or use the debug information?
That's a bummer... but wasn't that working before? Or didn't you try that before?
The hardware wiring is done correctly?
Am 02.03.2015 um 00:53 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Sun, 1 Mar 2015 22:47:19 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
With quick browsing, I couldn't find how to switch to Orise mode - do you know that?
Yes, by this magic 0ff 12 83 01 sequence. The data sheet is a little confusing what „Orise mode“ is. And that was the problem why we initially did not understand how to program the panel.
Okay, so both of them will only work when we can switch the panel to Orise mode automatically on power-up, understood.
We should check how well the stuff from the SSD works, what features the panel has and then decide what we really need.
Well, before we can do that, the SSD should work at all :)
Yes, sure :) Did you try playing with the new commands we received on Friday?
I tried to get the SSD to respond, but did not see anything. So there might be something broken in my current setup. Haven’t analysed deeper. Maybe, the timing of the OMAP is sufficient for the direct panel connection but not for the SSD. AFAIR, there were some changes after the last real SSD experiments.
With a little luck we will have 3 more SSD boards by end of next week.
Oh, not even a response at all? You can't even read registers or use the debug information?
yes. No response.
That's a bummer... but wasn't that working before?
yes. It was no problem reading/writing registers.
Or didn't you try that before?
The hardware wiring is done correctly?
There is no change in hardware - except that it might be broken now and was working before. Well, it is not ESD protected and it did go through many hands…
Or: some solder joint is broken by mechanical stress.
Or: we did build two boards and I might have had the other one working. It is too long ago to remember such details :)
Or: there is a subtle difference (e.g. sequence of reset vs. clock enabling) when using the panel-mipi-debug driver and some echo commands instead of the integrated ssd2858 driver.
But that are all hypotheses - only the experiment can show. Unfortunately it is not possible to do such experiments in parallel to building the missing prototypes or PCB layout. So I have put it on the ToDo list that is processed one step after the other.
BR, Nikolaus
-- Mit freundlichen Grüßen,
Michael Mrozek
OpenPandora GmbH Geschäftsführer: Michael Mrozek
Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 13 177 33 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt
eMail: mrozek@openpandora.org
Am Mon, 2 Mar 2015 06:55:29 +0100 hat "Dr. H. Nikolaus Schaller" hns@goldelico.com geschrieben:
Hi,
With a little luck we will have 3 more SSD boards by end of next week.
Oh, not even a response at all? You can't even read registers or use the debug information?
yes. No response.
That's a bummer... but wasn't that working before?
yes. It was no problem reading/writing registers.
Okay, then I'm not scared, I thought there was something fundamentally wrong :)
But that are all hypotheses - only the experiment can show. Unfortunately it is not possible to do such experiments in parallel to building the missing prototypes or PCB layout. So I have put it on the ToDo list that is processed one step after the other.
I'm sending you the one I've got here today, together with the panels.
Hi,
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.
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?
The main usage for the Solomon chip is not the rotation but powersaving and color correction features. So while we can't program the panel, we can use the chip to correct gamma curves, etc.
On 03/01/2015 06:03 PM, Michael Mrozek wrote:
Hi,
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.
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?
The main usage for the Solomon chip is not the rotation but powersaving and color correction features. So while we can't program the panel, we can use the chip to correct gamma curves, etc.
There are plenty of possibilities for this to fail, like having some important setting wrong, for example setting the panel to 16bit mode and not noticing it (just an example, I don't know if such mode actually exists). There is nothing Solomon would be able to do if such thing happened to improve the color depth, as the panel would be destroying parts of incoming data. Or some tolerance issue like we had with pandora's audio where most boards worked fine, but some did not, which turned out to be wrong clock edge setting that I could fix in the kernel. Imagine if it wasn't possible to fix it in software, many boards would have to be thrown away...
I don't think we have the resources to prove that the settings we choose are 100% correct. Although maybe BOE can help with that, I don't know...
Grazvydas
Am Sun, 01 Mar 2015 18:26:09 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hi,
The main usage for the Solomon chip is not the rotation but powersaving and color correction features. So while we can't program the panel, we can use the chip to correct gamma curves, etc.
There are plenty of possibilities for this to fail, like having some important setting wrong, for example setting the panel to 16bit mode and not noticing it (just an example, I don't know if such mode actually exists). There is nothing Solomon would be able to do if such thing happened to improve the color depth, as the panel would be destroying parts of incoming data. Or some tolerance issue like we had with pandora's audio where most boards worked fine, but some did not, which turned out to be wrong clock edge setting that I could fix in the kernel. Imagine if it wasn't possible to fix it in software, many boards would have to be thrown away...
Well, I can't think of much except for timing (but that would be visibile directly in the software), frequency (I think the panel is fixed to 60Hz, I don't think it can do 50Hz, sadly), resolution and bit depth.
That's something I can test before we send the final flashing data to BOE.
I don't think we have the resources to prove that the settings we choose are 100% correct. Although maybe BOE can help with that, I don't know...
BTW: Are you sure you're actually settint Pandoras gamma curve in the setting? Changing the Gamma also affects the TV Out, so my guess is you're using the OMAPs color correction features to change the gamma.
That should also work with the SSD, as that setting would happen before the actual MIPI signal.
On 03/01/2015 08:00 PM, Michael Mrozek wrote:
BTW: Are you sure you're actually settint Pandoras gamma curve in the setting?
Yes I'm sure, I wrote the driver, remember? It's the "Manage Gamma (Advanced)" option in the menus you did, or op_gammatool from command line. Although I agree it's probably not used much...
Changing the Gamma also affects the TV Out, so my guess is you're using the OMAPs color correction features to change the gamma.
That's separate from the above.
Am Sun, 01 Mar 2015 20:37:41 +0200 hat Grazvydas Ignotas grazvydas.ignotas@openpandora.org geschrieben:
Hi,
On 03/01/2015 08:00 PM, Michael Mrozek wrote:
BTW: Are you sure you're actually settint Pandoras gamma curve in the setting?
Yes I'm sure, I wrote the driver, remember?
Ah, well I don't know for every part what sourcecode we got and what part you wrote :)
It's the "Manage Gamma (Advanced)" option in the menus you did, or op_gammatool from command line. Although I agree it's probably not used much...
Ahh, was that the later gamma settings we introduced?
Changing the Gamma also affects the TV Out, so my guess is you're using the OMAPs color correction features to change the gamma.
That's separate from the above.