Hi, I need a little discussion that my conclusions are right - and maybe ideas what I could try in addition.
Here is the core of the unlocking test sequence to enables the panel:
echo g0000 >dcs # write address shift register echo gff128301 >dcs # write FF00h
echo g0000 >dcs # write address shift register echo gff12 >dcs # write FF00h echo g0001 >dcs # write address shift register echo gff83 >dcs # write FF01h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo more panel commands >dcs
This sequence makes the panel work. If the panel would not be unlocked by this sequence, I would see some flickering because its unflashed default is not optimal.
So I have a simple visual feedback if the unlock command was ok or failed.
The theory behind this command sequence is that any multi-byte command can be split up into separate single-byte write commands (with “manually” incrementing the register address). And that it does not harm to unlock twice (for testing).
Now here some results from modifying the sequence:
echo g0000 >dcs # write address shift register echo gff128301 >dcs # write FF00h
If I remove or change any bit of the sequence above, the panel flickers indicating that the unlock key was not written correctly and the second command can’t “repair” it.
Moving this code behind the following three write commands remains ok.
Removing it completely makes the panel flicker, indicating that only this 3-byte sequence works but not if split into three.
echo g0000 >dcs # write address shift register echo gff12 >dcs # write FF00h echo g0001 >dcs # write address shift register echo gff83 >dcs # write FF01h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h
If I change any bit of the byte behind “ff” the panel flickers, indicating that I have successfully overwritten the enable key in register 0ff00 .. 0ff02
If I write a 00 to FF02h the panel flickers, even if I try to overwrite it with 01 again. This means once locked I can’t unlock by writing a single byte.
If I change any upper 8 bits of an address (e.g. ff to fe) the panel does not flicker, because I don’t overwrite the unlock register.
So my conclusion is: * before the panel is unlocked, it is not possible to split commands and write single bytes. * maybe, because even the address shift command is locked (which is something we would have to consult the ORISE VHDL,,,)
As a consequence the unlock command must be a multi-byte sequence - which we are not able to pass through the ssd2858.
So do you agree with my conclusions? Or am I missing some test or idea?
Since I have now built up and tested 3 units of the prototypes it coul even be possible to share one set to someone with an OMAP5432EVM for doing his own experiments - if there is interest.
I am so persistent to find an answer (even if we decide to completely work around this problem by flashing the panel) because I always want to know why it fails :)
BR, Nikolaus
Am 26.03.2015 um 10:25 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Hi, I need a little discussion that my conclusions are right - and maybe ideas what I could try in addition.
Here is the core of the unlocking test sequence to enables the panel:
echo g0000 >dcs # write address shift register echo gff128301 >dcs # write FF00h
echo g0000 >dcs # write address shift register echo gff12 >dcs # write FF00h echo g0001 >dcs # write address shift register echo gff83 >dcs # write FF01h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo more panel commands >dcs
This sequence makes the panel work. If the panel would not be unlocked by this sequence, I would see some flickering because its unflashed default is not optimal.
So I have a simple visual feedback if the unlock command was ok or failed.
The theory behind this command sequence is that any multi-byte command can be split up into separate single-byte write commands (with “manually” incrementing the register address). And that it does not harm to unlock twice (for testing).
Now here some results from modifying the sequence:
echo g0000 >dcs # write address shift register echo gff128301 >dcs # write FF00h
If I remove or change any bit of the sequence above, the panel flickers indicating that the unlock key was not written correctly and the second command can’t “repair” it.
Moving this code behind the following three write commands remains ok.
Removing it completely makes the panel flicker, indicating that only this 3-byte sequence works but not if split into three.
echo g0000 >dcs # write address shift register echo gff12 >dcs # write FF00h echo g0001 >dcs # write address shift register echo gff83 >dcs # write FF01h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h echo g0002 >dcs # write address shift register echo gff01 >dcs # write FF02h
If I change any bit of the byte behind “ff” the panel flickers, indicating that I have successfully overwritten the enable key in register 0ff00 .. 0ff02
If I write a 00 to FF02h the panel flickers, even if I try to overwrite it with 01 again. This means once locked I can’t unlock by writing a single byte.
If I change any upper 8 bits of an address (e.g. ff to fe) the panel does not flicker, because I don’t overwrite the unlock register.
So my conclusion is:
- before the panel is unlocked, it is not possible to split commands
and write single bytes.
- maybe, because even the address shift command
is locked (which is something we would have to consult the ORISE VHDL,,,)
As a consequence the unlock command must be a multi-byte sequence - which we are not able to pass through the ssd2858.
So do you agree with my conclusions? Or am I missing some test or idea?
Since I have now built up and tested 3 units of the prototypes it coul even be possible to share one set to someone with an OMAP5432EVM for doing his own experiments - if there is interest.
I am so persistent to find an answer (even if we decide to completely work around this problem by flashing the panel) because I always want to know why it fails :)
Well, it looks as if the ORISE datasheet indeed contains all information to explain why it can not work :(
1. the address shift function is controlled by the EXTC bit 2. the EXTC bit is in register 0xff02 3. this is activated by the 0x01 of the unlock key 4. there is no mention of an auto-increment of the address shift register and I have done another test which seems to confirm that an address set once stays as it is 5. I assume that addresses are only auto-incremented if we use a multi-byte packet but it does not change the address shift register
This means we have a deadlock: * because EXTC=0 initially we can’t set the address shift register * because we can’t set the address shift register to 0x02 we can’t write the EXTC bit to 1 * because address-autoincrement is only available in multi-byte commands we are locked out unless we can use the multi-byte command
BR, Nikolaus
On Thu, Mar 26, 2015 at 1:47 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
This means we have a deadlock:
- because EXTC=0 initially we can’t set the address shift register
- because we can’t set the address shift register to 0x02 we can’t write the EXTC bit to 1
- because address-autoincrement is only available in multi-byte commands we are locked out unless we can use the multi-byte command
I can only think of 2 things to try:
- write to register ff 3 times without writing to address shift, hoping there actually is autoincrement and it would work:
echo gff12 >dcs # write to FF00h echo gff83 >dcs # hope to write FF01h echo gff01 >dcs # hope to write FF02h
- write 2 bytes at a time, which SSD would allow I suppose?
echo gff1283 >dcs # write to FF00h and FF01h echo gff01 >dcs # hope to write FF02h
But looking at the docs this looks very unlikely to work. Maybe sending the MIPI packets in rapid succession could also have effect on this (your userspace method should be causing significant delays between commands at least because of system call overheads), but that's also kind of unlikely.
The doc mentions i2c/SPI, how feasible would it be to connect that?
Gražvydas
Hi Notaz,
Am 26.03.2015 um 13:59 schrieb Grazvydas Ignotas notasas@gmail.com:
On Thu, Mar 26, 2015 at 1:47 PM, Dr. H. Nikolaus Schaller hns@goldelico.com wrote:
This means we have a deadlock:
- because EXTC=0 initially we can’t set the address shift register
- because we can’t set the address shift register to 0x02 we can’t write the EXTC bit to 1
- because address-autoincrement is only available in multi-byte commands we are locked out unless we can use the multi-byte command
I can only think of 2 things to try:
- write to register ff 3 times without writing to address shift,
hoping there actually is autoincrement and it would work:
echo gff12 >dcs # write to FF00h echo gff83 >dcs # hope to write FF01h echo gff01 >dcs # hope to write FF02h
I already had though into this direction but did not try this exact sequence. So I might have reset the low byte address pointer (the whole scheme remembers a little of the 6502 :).
I will give it a try asap.
- write 2 bytes at a time, which SSD would allow I suppose?
Yes, it should allow.
echo gff1283 >dcs # write to FF00h and FF01h echo gff01 >dcs # hope to write FF02h
Yes, that should work - if addresses are autoincremented internally.
But looking at the docs this looks very unlikely to work. Maybe sending the MIPI packets in rapid succession could also have effect on this (your userspace method should be causing significant delays between commands at least because of system call overheads), but that’s also kind of unlikely.
Yes, I also doubt that it has an effect. In this mode they are sent as low speed packets (~10 MBit/s) and no other communication mixed in between.
The doc mentions i2c/SPI, how feasible would it be to connect that?
Unfortunately the controller chip can speak SPI but the panel has not wired these lines to the connector.
BR and thanks, Nikolaus
Hi,
According to SSD manual:
ff 00 -> all subsequent commands go to SSD ff 01 -> all subsequent commands go to retransmit ff ff * -> retransmit *this* packet as ff *
It is not specified what happens on other ff * variants. Maybe when retransmit mode is on, it will just retransmit them? Do we already know what it does with those packets?
Gražvydas
Am 26.03.2015 um 14:53 schrieb Grazvydas Ignotas notasas@gmail.com:
Hi,
According to SSD manual:
ff 00 -> all subsequent commands go to SSD ff 01 -> all subsequent commands go to retransmit ff ff * -> retransmit *this* packet as ff *
It is not specified what happens on other ff * variants. Maybe when retransmit mode is on, it will just retransmit them? Do we already know what it does with those packets?
No, but Solmon was very open and helpful. So they would have said if it were possible to use that mode.
I will ask.
BR, Nikolaus