Eos 400d ( Rebel XTI ) - page 171 - DSLR Hack development - CHDK Forum

Eos 400d ( Rebel XTI )

  • 1871 Replies
  • 891276 Views
VRAM
« Reply #1700 on: 28 / March / 2013, 06:36:53 »
Advertisements
   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 ...
 

VRAM
« Reply #1701 on: 28 / March / 2013, 06:37:15 »
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?   

VRAM
« Reply #1702 on: 28 / March / 2013, 06:37:40 »
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...


*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1703 on: 28 / March / 2013, 08:32:38 »
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.
// AF

Re: Eos 400d ( Rebel XTI )
« Reply #1704 on: 28 / March / 2013, 14:47:19 »
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!

Re: Eos 400d ( Rebel XTI )
« Reply #1705 on: 28 / March / 2013, 17:11:45 »
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.

Re: Eos 400d ( Rebel XTI )
« Reply #1706 on: 28 / March / 2013, 18:34:33 »
Ok - I think I get it. Thanks for the response Edu.

*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1707 on: 29 / March / 2013, 03:28:35 »
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).
// AF

New beta available
« Reply #1708 on: 31 / March / 2013, 15:37:41 »
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.

Third beta available
« Reply #1709 on: 07 / April / 2013, 17:20:52 »
There is a third beta available, which fixes the named custom color temperatures menu, and adds Danish translation.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal