Eos 400d ( Rebel XTI ) - page 170 - DSLR Hack development - CHDK Forum
« previous next »
Pages: 1 ... 165 166 167 168 169 [170] 171 172 173 174 175 ... 188   Go Down

Eos 400d ( Rebel XTI )

  • 1871 Replies
  • 892495 Views
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1690 on: 28 / March / 2013, 06:32:53 »
Advertisements
Quote from: 0xAF on 26 / March / 2013, 06:47:15
Quote from: Sergei on 26 / March / 2013, 05:38:31
eventproc_TransferNormalScreen sets the pointer 0x51C0 to 0xFF92D950 function. Edu sets this pointer to my_UpdateGUI() which calls 0xFF92D950 or "UpdateGUI()" and enqueue_action(display_overlay) .
   Something sets the pointer one time at boot and every GUI window uses it to update vram. I could be wrong, but window instance has section of RAM which looks like a copy of vram. I think the function in 0x51C0 updates it and then copies it to vram. My idea was to find which subroutine does the copy. Maybe BlinkTimer uses it to write to vram.

I see.
Then this simplifies the whole stuff, we just register at this pointer with our routine, then on every call, we "poison" the vram with our content, then call the original routine.
Am I thinking right ?

BTW, why would you need to find what exactly copies the FB to VRAM ? What is it good for ?

Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1691 on: 28 / March / 2013, 06:33:12 »
Quote from: Sergei on 26 / March / 2013, 15:53:30
Quote from: 0xAF on 26 / March / 2013, 06:47:15
Quote from: Sergei on 26 / March / 2013, 05:38:31
eventproc_TransferNormalScreen sets the pointer 0x51C0 to 0xFF92D950 function. Edu sets this pointer to my_UpdateGUI() which calls 0xFF92D950 or "UpdateGUI()" and enqueue_action(display_overlay) .
   Something sets the pointer one time at boot and every GUI window uses it to update vram. I could be wrong, but window instance has section of RAM which looks like a copy of vram. I think the function in 0x51C0 updates it and then copies it to vram. My idea was to find which subroutine does the copy. Maybe BlinkTimer uses it to write to vram.

I see.
Then this simplifies the whole stuff, we just register at this pointer with our routine, then on every call, we "poison" the vram with our content, then call the original routine.
Am I thinking right ?

BTW, why would you need to find what exactly copies the FB to VRAM ? What is it good for ?

  In theory it should work already. But it doesn't. Something is blocking overlay writes time to time. And it not consistent. I thought if I find what writes original screen and put a filter there, so it never overwrites our overlay, it may stop the flicker.
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1692 on: 28 / March / 2013, 06:33:32 »
Quote from: Sergei on 27 / March / 2013, 04:24:37
  Ok, I finally spotted that "vram copy" routine! No more flickering.
Look in main.c for "UpdateGUI", in gui.S for  "my_TransferNormalScreen" and "VramMod", in display.c for "VramMod" and "bmp_printf" to get an idea.
https://lh.rs/ycJ2bZHHEwRy
 We probably can invert screen colors for night mode now too.
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1693 on: 28 / March / 2013, 06:34:15 »
Quote from: eduperez on 27 / March / 2013, 04:31:33
Quote from: Sergei on 27 / March / 2013, 04:24:37
  Ok, I finally spotted that "vram copy" routine! No more flickering.
Look in main.c for "UpdateGUI", in gui.S for  "my_TransferNormalScreen" and "VramMod", in display.c for "VramMod" and "bmp_printf" to get an idea.
https://lh.rs/ycJ2bZHHEwRy
 We probably can invert screen colors for night mode now too.

BRAVO!!! May I kiss you???  :-*

I get a "404-Not found" when I try to access that link... could you upload it again, please?
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1694 on: 28 / March / 2013, 06:34:39 »
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1695 on: 28 / March / 2013, 06:35:04 »
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1696 on: 28 / March / 2013, 06:35:24 »
Quote from: 0xAF on 27 / March / 2013, 05:09:54
Quote from: Sergei on 27 / March / 2013, 04:24:37
  Ok, I finally spotted that "vram copy" routine! No more flickering.
Look in main.c for "UpdateGUI", in gui.S for  "my_TransferNormalScreen" and "VramMod", in display.c for "VramMod" and "bmp_printf" to get an idea.
https://lh.rs/ycJ2bZHHEwRy
 We probably can invert screen colors for night mode now too.

Looks quite interesting... You've gone deeper to reach this.
In this case the cache-hacks would be very useful.
Though you've did a great job on this, I think there should be easier way to handle the flickering, but i'm not in position to talk about it, since i have no time to do any experiments.
On the other hand, you've mentioned inverting the colors, which would be interesting feature and for such feature, your great work is most appreciated.

Good job.
Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1697 on: 28 / March / 2013, 06:35:45 »
Quote from: Sergei on 27 / March / 2013, 05:30:51
Quote from: 0xAF on 27 / March / 2013, 05:09:54
Quote from: Sergei on 27 / March / 2013, 04:24:37
  Ok, I finally spotted that "vram copy" routine! No more flickering.
Look in main.c for "UpdateGUI", in gui.S for  "my_TransferNormalScreen" and "VramMod", in display.c for "VramMod" and "bmp_printf" to get an idea.
https://lh.rs/ycJ2bZHHEwRy
 We probably can invert screen colors for night mode now too.

Looks quite interesting... You've gone deeper to reach this.
In this case the cache-hacks would be very useful.
Though you've did a great job on this, I think there should be easier way to handle the flickering, but i'm not in position to talk about it, since i have no time to do any experiments.
On the other hand, you've mentioned inverting the colors, which would be interesting feature and for such feature, your great work is most appreciated.

Good job.
  I don't know anything about "cache-hacks". Something about changing CPU cache to swap pointers to functions? If you remember any links to information about cache-hacks please send them to me.
   Thanks.

Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1698 on: 28 / March / 2013, 06:36:02 »
Quote from: 0xAF on 27 / March / 2013, 05:52:57
Quote from: Sergei on 27 / March / 2013, 05:30:51
  I don't know anything about "cache-hacks". Something about changing CPU cache to swap pointers to functions? If you remember any links to information about cache-hacks please send them to me.
   Thanks.

The idea behind cache-hacks was developed by g3gg0 from ML.
There are 2 cache lines in ARM. One for DATA and one for INSTRUCTIONS.
When code is executed from ROM (or RAM) the internals of the CPU (the caches) are checking if the instruction at this address already exists in the I cache. If it is in the cache, then it's not read from the ROM, but it is executed directly from the cache.
Same is happening for the Data.

lets say we have this instruction:
ROM:0x12345678      LDR     R12, =dword_ABCD

the following will happen when the execution take place:
1. Check I cache of we have 0x12345678 already in the cache
1.1. If yes - then execute from there
1.2 If no - then read the instruction from ROM and execute (and cache it in I cache)

2. Check the D cache if we have =dword_ABCD already
2.1. If yes - then get the data from D cache
2.2. If no - then read the data from ROM and cache it in D cache.


The good thing of the I/D caches is that we can change their content and lock them, so nothing changes after that. (the caches are separated in several blocks and we can put our stuff in 1 block and lock only this block)

What we are going to do is the following.
We "poison" the cache and put another instruction for the address 0x12345678, then when the code is executing from ROM and the execution gets to 0x12345678, the caches will execute our instruction instead of the real one.
Very handful to replace B/BL calls for example.

D cache is not so interesting once we can poison I cache.


This is the implementation for cache-hacks written by g3gg0 for ML:
https://bitbucket.org/hudson/magic-lantern/src/1f347d21f1599ee6bc49f2ea0cc829735a79e9c3/src/cache_hacks.h?at=unified

It may look scary when you first see it, but if you read the ARM ARM (ARM Architecture Reference Manual), it gets quite clear how it works... Though it took me some good time to understand it fully.

But my idea was to port it in 400Plus (which should be relatively easy) and i will do it some time soon.


Hope this explains enough on how the cache-hacks works.

Logged
*

Offline eduperez

  • ****
  • 426
VRAM
« Reply #1699 on: 28 / March / 2013, 06:36:26 »
Quote from: Sergei on 27 / March / 2013, 06:05:08
Quote from: 0xAF on 27 / March / 2013, 05:52:57
Quote from: Sergei on 27 / March / 2013, 05:30:51
  I don't know anything about "cache-hacks". Something about changing CPU cache to swap pointers to functions? If you remember any links to information about cache-hacks please send them to me.
   Thanks.

The idea behind cache-hacks was developed by g3gg0 from ML.
There are 2 cache lines in ARM. One for DATA and one for INSTRUCTIONS.
When code is executed from ROM (or RAM) the internals of the CPU (the caches) are checking if the instruction at this address already exists in the I cache. If it is in the cache, then it's not read from the ROM, but it is executed directly from the cache.
Same is happening for the Data.

lets say we have this instruction:
ROM:0x12345678      LDR     R12, =dword_ABCD

the following will happen when the execution take place:
1. Check I cache of we have 0x12345678 already in the cache
1.1. If yes - then execute from there
1.2 If no - then read the instruction from ROM and execute (and cache it in I cache)

2. Check the D cache if we have =dword_ABCD already
2.1. If yes - then get the data from D cache
2.2. If no - then read the data from ROM and cache it in D cache.


The good thing of the I/D caches is that we can change their content and lock them, so nothing changes after that. (the caches are separated in several blocks and we can put our stuff in 1 block and lock only this block)

What we are going to do is the following.
We "poison" the cache and put another instruction for the address 0x12345678, then when the code is executing from ROM and the execution gets to 0x12345678, the caches will execute our instruction instead of the real one.
Very handful to replace B/BL calls for example.

D cache is not so interesting once we can poison I cache.


This is the implementation for cache-hacks written by g3gg0 for ML:
https://bitbucket.org/hudson/magic-lantern/src/1f347d21f1599ee6bc49f2ea0cc829735a79e9c3/src/cache_hacks.h?at=unified

It may look scary when you first see it, but if you read the ARM ARM (ARM Architecture Reference Manual), it gets quite clear how it works... Though it took me some good time to understand it fully.

But my idea was to port it in 400Plus (which should be relatively easy) and i will do it some time soon.


Hope this explains enough on how the cache-hacks works.

   Great! Thank you very much! I will try to understand how it works.
Logged
Pages: 1 ... 165 166 167 168 169 [170] 171 172 173 174 175 ... 188   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal