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

Eos 400d ( Rebel XTI )

  • 1871 Replies
  • 891303 Views
*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1710 on: 12 / April / 2013, 09:42:44 »
Advertisements
Here is simplified overlay update hook. Finally got rid of gui.S.
    Goes in main.c at startup:
Code: [Select]
(*(int*)0x51C0)= (int)&my_TransferNormalScreen;
    And VRAM hook function:
Code: [Select]
my_TransferNormalScreen(int r0, int r1, int r2, int r3, int a, int b, int c, int d)
{   VramMod((vram_t*)(r3+0x78));  // r3+0x78 is a pointer to VRAM.
    return TransferNormalScreen(r0, r1, r2, r3, a, b, c, d);  //DEF(TransferNormalScreen, 0xFF92D950)
}

http://hostr.co/52MHvJ9CiloB
« Last Edit: 12 / April / 2013, 10:15:52 by Sergei »

Re: Eos 400d ( Rebel XTI )
« Reply #1711 on: 12 / April / 2013, 17:49:47 »
Here is simplified overlay update hook. Finally got rid of gui.S.
    Goes in main.c at startup:
Code: [Select]
(*(int*)0x51C0)= (int)&my_TransferNormalScreen;
    And VRAM hook function:
Code: [Select]
my_TransferNormalScreen(int r0, int r1, int r2, int r3, int a, int b, int c, int d)
{   VramMod((vram_t*)(r3+0x78));  // r3+0x78 is a pointer to VRAM.
    return TransferNormalScreen(r0, r1, r2, r3, a, b, c, d);  //DEF(TransferNormalScreen, 0xFF92D950)
}

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!

Re: Eos 400d ( Rebel XTI )
« Reply #1712 on: 15 / April / 2013, 06:04:27 »
And... we have new version!

*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1713 on: 15 / April / 2013, 06:55:23 »
And... we have new version!
That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1714 on: 15 / April / 2013, 07:07:47 »
Edu, thanks for the great job on the release !
A lot of new stuff :)


That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

Very good, thanks !
I feel a bit shamed now :)

Anyway, have you got the chance to trace all the spots where the Cache is cleared.
I mean, if we hijack some routines at later point of execution, i.e. the Transfer_to_VRAM function (it's just an example, not that we need to hijack it with cache hacks), would it be cleared at some point later ?

My ultimate goal with cache hacks was to port the whole booting procedure (like in ML), so our entry point is one routine that just uses cache-hacks and hijacks all cache-clearing routines, then hijack some init routine to start our code.
If we have this, then we get rid of all copied code from canon.

p.s.
Great job, cache-hacks will give us great powers, thanks to you (for porting them) and to g3gg0 for the idea and implementation in first place!
// AF

*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1715 on: 15 / April / 2013, 07:51:52 »
   Firmware clears caches somewhere in vmBaseGlobalMapInit() at startup. I didn't look too deep in that function. Just disabled it for now. Everything works. I'm using cache hacks to modify original boot process, so no more long copies of code.
  Thanks, 0xAF!
 
« Last Edit: 15 / April / 2013, 07:54:23 by Sergei »

Re: Eos 400d ( Rebel XTI )
« Reply #1716 on: 15 / April / 2013, 08:26:56 »
And... we have new version!
That's great!
I have ported cache hacks to 400d.
Here it is if you want to check if it will be usable in 400plus:
http://hostr.co/PH59nDeigtFK
Look in init.c for EnableCacheHacks().

"Usable in 400plus", you ask? Dear God, that's a gold mine! I just had a look at your code, and you did a fantastic job with the initialization, I liked it very much; it's very clean and smooth now, congratulations.

Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.

Thank you very much!

*

Offline 0xAF

  • ***
  • 220
    • 0xAF
Re: Eos 400d ( Rebel XTI )
« Reply #1717 on: 15 / April / 2013, 08:39:13 »
Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.

May be with the cache hacks, now we can skip the ASM part.
We may link our entry point to the COPY() routine directly, then from the copy call the EnableCacheHacks() which will do the hijcks, then call the original entry point.
// AF

*

Offline Sergei

  • ***
  • 114
Eos 400d ( Rebel XTI )
« Reply #1718 on: 15 / April / 2013, 19:14:33 »
Looks like it is possible. I will check on it when I get time.

*

Offline Sergei

  • ***
  • 114
Re: Eos 400d ( Rebel XTI )
« Reply #1719 on: 17 / April / 2013, 10:44:38 »
Just a question (to both you and 0xAF), please: do we still have to keep that piece of ASM code at "entry.S"? It looks quite "innocent" to my ignorant eyes, and I would love to get rid of all unneeded ASM code.
  I got rid of ASM code in entry.S but can't convert entry.S to entry.c. Missing GCC flags ?
Quote
ld: error: stubs.o uses hardware FP, whereas AUTOEXEC.arm.elf uses software FP
ld: failed to merge target specific data of file stubs.o
Here is the source code:
http://hostr.co/QaDx9TNOxlTi

 

Related Topics


SimplePortal © 2008-2014, SimplePortal