Eos 400d ( Rebel XTI )

eduperez

Sergei wrote:
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.

eduperez

eduperez wrote:

Sergei wrote:
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?

eduperez

Sergei wrote:
try this one:
https://lh.rs/3uvQzJ3NP7OP

eduperez

eduperez wrote:

Sergei wrote:
try this one:
https://lh.rs/3uvQzJ3NP7OP

Got it, I'm reviewing the code right now; many thanks!

eduperez

0xAF wrote:

Sergei wrote:
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.

eduperez

Sergei wrote:

0xAF wrote:

Sergei wrote:
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.

eduperez

0xAF wrote:

Sergei wrote:
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.

eduperez

Sergei wrote:

0xAF wrote:

Sergei wrote:
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.

eduperez

0xAF wrote:

Sergei wrote:
Great! Thank you very much! I will try to understand how it works.

g3gg0 made them (cache-hacks) quite simple for usage, though it's big voodoo magic in first look.

it should be simple as this:
1. lock the caches, so nothing will change them anymore: cache_lock();
2. poison the I cache and change any instruction you want:
cache_fake(0xFFB40340, NOP_INSTR, TYPE_ICACHE); // change the instruction at this address to NOP
or
cache_fake(0xFFB40344, BL_INSTR(0xFFB40344, &my_super_special_routine), TYPE_ICACHE); // change the original BL call with our BL call

as long as the caches stays locked, it will work... but if the caches gets unlocked, our poison will be replaced very quickly... so we must be sure nothing unlocks or clears the caches once we poison them...

i've been working on these things on my 5D,
to do this i had to read the ARM ARM (ARM Architecture Reference Manual) about the caches, to see the all possible ways to clear them...
then i've looked at the firmware to see where are the caches cleared or unlocked... and replaced all instructions that are going to stop us...
some with NOPs, some i had to make a helper routines to do what's needed, since they were changing the control register 15, and we cannot nop this instructions easily...

https://bitbucket.org/0xAF/magic-lantern-5dc-port-wip/src/9900ee745965978b31f302d94a54dcf6f17ebd4f/platform/5DC.111/init.c?at=unified#cl-211
this is the code i've been doing some time ago for 5D
you can see the helper functions before that routine, but for 400d i will have to inspect the firmware again...

as it turns out, for all ML cameras there were 2-3 instructions which needs to be NOPed, so the cache stays locked and intact...
but on 5D it seems there are quite more... something like 25-30 instructions in random places in the firmware... it is not that easy to catch all of them... the main reason was that the original VxWorks code did a lot of cache stuff... and the newer cameras with Canon's DryOS do not touch the caches...

i only hope 400d to get fewer instructions, so it will be easier to port the cache-hacks... it is still a vxworks camera, but it's newer firmware and newer api than 5D...
and 40d is vxworks camera, but ML guys made it with few instructions only ....

i guess i made all this too much confusing already ...
hope this will help you (both) in understanding the initial process of the porting of the cache hacks...

just keep in mind that the most cache clear instructions are in the moment of initializing the camera ...
once its booted and runs, there are just few instructions that needs to be replaced...

if you are going to try to port them, drop a line, i can give some techniques that will help you...

another option is to wait for me to get some time (hope this week or the next one)
and do it ...

eduperez

Sergei wrote:
I will study it. Not sure if I will be able to port cache hacks to 400plus, at least not for long time. One question I have, does it make camera noticeable slower since cache locked?
I'm not sure how big the cache is and how often it updates. On every new GUI window execution? Or only at boot time?

eduperez

0xAF wrote:

Sergei wrote:
I will study it. Not sure if I will be able to port cache hacks to 400plus, at least not for long time. One question I have, does it make camera noticeable slower since cache locked?
I'm not sure how big the cache is and how often it updates. On every new GUI window execution? Or only at boot time?

The theoretical slowdown is about 5%, but it's not noticeable.
If the cache is locked, then it wont replace any content in it. If it's unlocked (like the normal operation), then it updates on every instruction which is executed. The idea of the cache is, if you have some code that executes frequently, it gets cached and used there, but in our case the firmware have no such code... so it wont matter...

0xAF

0xAF wrote:
The theoretical slowdown is about 5%, but it's not noticeable.

Keep in mind that i'm talking from memories here and i think we've discussed this with g3gg0, so it really doesnt matter... the slowdown is not noticeable at all.

repeater

Purely out of interest, as I don't understand what you guys are discussing, what is the advantage / use of VRAM? What does it do or what will it allow you to do?

Hope you don't mind me being nosey!

eduperez

repeater
Purely out of interest, as I don't understand what you guys are discussing, what is the advantage / use of VRAM? What does it do or what will it allow you to do?

Hope you don't mind me being nosey!

Writing to VRAM means writing directly to the display, instead of asking the firmware to write something. The main advantage is that we can write whatever we want, not just what Canon decided to put in the firmware; the main disadvantage is that the firmware does not expect anybody else writing to the display, and can overwrite our work.

It's just like ordering the waiter something from the menu, or entering to the kitchen and cooking it yourself.

repeater

Ok - I think I get it. Thanks for the response Edu.

0xAF

eduperez
It's just like ordering the waiter something from the menu, or entering to the kitchen and cooking it yourself.

I like that comparison. 😀

@repeater, the reason we want VRAM, is that it will allow us to write our notifications or texts over the screen. And/or some day we may write our icons and our windows there. The way we are using it now is to ask canon's API to write something for us. Think of our menu system, it looks like canon's but with different texts. With direct writing to VRAM, we are able to write some specific texts/icons to the screen (pretty useful for notifications).

eduperez

There is a new beta available, that fixes all defects reported:

* Reduced the flickering in the main display.
* Fixed a defect using multi-spot metering with custom modes.
* Improved BULB mode when AutoISO is active.

eduperez

There is a third beta available, which fixes the named custom color temperatures menu, and adds Danish translation.

Sergei

Here is simplified overlay update hook. Finally got rid of gui.S.
Goes in main.c at startup:

(*(int*)0x51C0)= (int)&my_TransferNormalScreen;

And VRAM hook function:

 my_TransferNormalScreen(int r0, int r1, int r2, int r3, int a, int b, int c, int d)
{   VramMod((vram_t*)(r3+0x7😎);  // r3+0x78 is a pointer to VRAM. 
    return TransferNormalScreen(r0, r1, r2, r3, a, b, c, d);  //DEF(TransferNormalScreen, 0xFF92D950)
}

http://hostr.co/52MHvJ9CiloB

eduperez

Sergei
Here is simplified overlay update hook. Finally got rid of gui.S.
Goes in main.c at startup:
[code](*(int*)0x51C0)= (int)&my_TransferNormalScreen;[/code]

And VRAM hook function:
[code] my_TransferNormalScreen(int r0, int r1, int r2, int r3, int a, int b, int c, int d)
{ VramMod((vram_t*)(r3+0x7😎); // r3+0x78 is a pointer to VRAM.
return TransferNormalScreen(r0, r1, r2, r3, a, b, c, d); //DEF(TransferNormalScreen, 0xFF92D950)
}[/code]

http://hostr.co/52MHvJ9CiloB

After releasing three betas, I did not want to change our code before the next release; but this was too tempting...
I've just integrated this code into 400plus, and it works perfectly.

Many thanks!

« Previous Page Next Page »