Magic Lantern's cache hacks on PowerShots? - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: [1] 2   Go Down

Magic Lantern's cache hacks on PowerShots?

  • 13 Replies
  • 4773 Views
*

Offline srsa_4c

  • ******
  • 4323
Magic Lantern's cache hacks on PowerShots?
« on: 01 / January / 2013, 14:14:11 »
Advertisements
This topic may never get any replies, but it's worth a try.

cache_hacks.h

I tried to use it (with slight modifications due to missing integer types) on a VxWorks and a DryOS camera, almost without any visible effect. The only exception was when I "replaced" a few early subroutine calls in the startup process with which I successfully crashed the camera.
I have used cache_fake() calls (as seen in some ML src files).

Since I'm no expert in ARM, I have a few questions...

- What could be the reason of my failure? Is there something which needs to be done differently on "our" DIGICs?
- Is it to be expected that some camera routines unlock and flush the whole (I, D) cache, thereby erasing the faked content? If so, do those routines need a rewrite or can they be simply made "nullsub"s?
- For how long does the faked cache content last? Is this method suitable for altering tasks other than the one which calls cache_fake()?

The only promising place I've seen larger number of these cache_fake() calls is the 40D code, but since I don't have the 40D ROM, I don't know which firmware routines are hacked/replaced there.
« Last Edit: 01 / January / 2013, 17:30:40 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 12878
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #1 on: 01 / January / 2013, 15:10:17 »
Quote from: srsa_4c on 01 / January / 2013, 14:14:11
- What could be the reason of my failure? Is there something which needs to be done differently on "our" DIGICs?
Unlikely. Digic ARM seems to be a very vanilla ARM.
Quote
- Is it to be expected that some camera routines unlock and flush the whole (I, D) cache, thereby erasing the faked content? If so, do those routines need a rewrite or can they be simply made "nullsub"s?
Well, CHDK does for modules http://chdk.setepontos.com/index.php?topic=2509.msg91703#msg91703 so you would probably need to restore the hacks whenever it executes. It would probably be good to disable interrupts while doing all this too, so you don't get task switched with the hook missing (actually the arm docs say you must disable interrupts to use lockdown). The canon firmware manipulates the caches on startup (you need to set up your hooks *after* all the CP15 stuff in boot.c), but I'd be somewhat surprised if it messed with the instruction cache after that under normal circumstances. That's only a guess though, they could conceivably use lockdown themselves for performance reasons, and this could be different between P&S and DSLR.
Quote
- For how long does the faked cache content last?
Since this is using cache lockdown, it should last until the conditions mentioned in the ARM documentation cease to apply. The relevant document should be "ARM946E-S Technical Reference Manual" section 3.4
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4323
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #2 on: 01 / January / 2013, 17:28:55 »
Thanks, I forgot that module related cache magic. But that could not have been the cause of the failure, as CHDK hasn't touched modules at the time those code parts were executing. I still suspect some evil firmware routines. On VxWorks, some of those are identified with descriptive names (by signatures), but I have no idea when they are used.
Logged
*

Offline srsa_4c

  • ******
  • 4323
Magic Lantern's cache hacks on PowerShots.
« Reply #3 on: 04 / September / 2015, 18:47:40 »
A bit embarrassing to continue, but anyway.

My issue was that I did not call the lockdown routine. After doing that, things do behave much better, but.

On my a3200 (DryOS):
Faked cache content gets erased randomly (it sticks for a few milliseconds, sometimes for a few seconds). The lockdown status does not seem to change.
Started investigating the possible reasons and found a library (adjacent functions) in firmware that manipulates CPU cache (sort of like the CHDK cache routines).
- one function is used by the flash ROM writer routines
- another one is used by SD card DMA routines
- another one used by exmem_free, AllocateUncachedMemory and AdditionAgentRAM
There might be other such functions, did not check further yet.

If high reliability is not required, cache_fake() can be called from the keyboard task to refresh faked content.

However, I'm not sure what would be the optimal way for high reliability.
Some of the above mentioned fw cache functions don't disable interrupts until they clean things, some do.
I suspect that they need to be completely rewritten to skip over 'our' locked down cache segment, because the other way (let them do their stuff and put our faked content back when they are finished) doesn't seem really reliable. A modified version needs to be included in CHDK source, and the ROM routines need to be redirected there. I'm a bit confused that ML does not seem to do this, though.

I've attached a version of cache_hacks.h, in case somebody wants to play with this.
The source is cache_hacks.h and arm-mcr.h from ML, licence is the same as the ML licence (GPL v2). I had to make slight adjustments to make it work on CHDK.
Logged
*

Offline srsa_4c

  • ******
  • 4323
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #4 on: 01 / March / 2016, 13:41:52 »
After seeing "This patch was overwritten, probably by Maxwell's demon." in their source, I finally found the reason why ML has no problems with fake cache content.

I have located the cache library used in EOS cameras (fw used is 550d), and found that it's the same as the one used in Powershots. However, the EOS and PS firmwares use the library differently.
The key seems to be the routine I mentioned above
Quote from: srsa_4c on 04 / September / 2015, 18:47:40
- another one used by exmem_free, AllocateUncachedMemory and AdditionAgentRAM
which is unused in EOS. Their supposed AllocateUncachedMemory equivalent (ML calls it _alloc_dma_memory) calls a routine instead that is unused in PS firmwares (last routine of the library, 0xff8109a4 in a3200 100d).

I guess the next step would be substituting this
Quote
- another one used by exmem_free, AllocateUncachedMemory and AdditionAgentRAM
with the library's last routine and see if the camera is still usable. Have not tried that yet...
Logged
*

Offline Ant

  • ****
  • 443
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #5 on: 06 / November / 2016, 13:44:32 »
Have you tried it on Digic 6 cameras?
AFAIK Magic Lantern disables cache clearing using the same cache_fake function...
Logged
*

Offline srsa_4c

  • ******
  • 4323
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #6 on: 06 / November / 2016, 20:05:36 »
Quote from: Ant on 06 / November / 2016, 13:44:32
Have you tried it on Digic 6 cameras?
No, because according to its documentation, the Cortex R4 does not support CPU cache manipulation. I have noted this here.
Quote
AFAIK Magic Lantern disables cache clearing using the same cache_fake function...
I have not found evidence of that, if you have, please show me where it's done.
Logged
*

Offline Ant

  • ****
  • 443
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #7 on: 07 / November / 2016, 01:08:44 »
Quote from: srsa_4c on 06 / November / 2016, 20:05:36
I have not found evidence of that, if you have, please show me where it's done.

For VxWorks models it's there and there

Maybe this can be used on Digic 6?
« Last Edit: 07 / November / 2016, 11:54:45 by Ant »
Logged
*

Offline srsa_4c

  • ******
  • 4323
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #8 on: 07 / November / 2016, 20:24:12 »
Quote from: Ant on 07 / November / 2016, 01:08:44
For VxWorks models it's there and there
I remember seeing that on one of the Vx ports, but I meant an official port (which are all DryOS). CPU cache handling is likely different on VxWorks and DryOS.

Quote
Maybe this can be used on Digic 6?
I have the impression that it is about a hardware interface, and of no use for the end user. L2 interface
Logged
*

Offline Ant

  • ****
  • 443
Re: Magic Lantern's cache hacks on PowerShots?
« Reply #9 on: 09 / November / 2016, 00:55:55 »
I've managed to get values of some debug registers on EOS M3:
Code: [Select]
Debug ID Register 0x77040013
  (raw value)          0x77040013 1996750867
Debug ROM Address Register 0xA0000003
  (raw value)          0xA0000003 -1610612733
Debug Self Address Offset Register 0x00007003
  (raw value)          0x7003 28675
Debug Status and Control Register 0x02000002
  (raw value)          0x2000002 33554434
But Debug ROM Address looks strange...
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics